В начале 2018 года в опросе от Stack Overflow поучаствовало более 100000 респондентов, что сделало этот опрос разработчиков крупнейшим в мире.

Самые интересные ответы — под катом.

Microsoft довольно своеобразно отреагировал на свалившуюся на него со всех сторон критику по поводу слежки за пользователями: как пишет сайт Techrepublic, новый апдейт популярной ОС позволит пользователям блокировать мониторинг, но только в Enterprise (корпоративной) версии. Об этом радостном событии было объявлено 12 ноября этого года.

В EDISON часто обращаются инженеры, желающие добавить сотрудников в команду. Хочется «по-быстрому склепать задачку», воспользовавшись десятком дополнительных разработчиков. Работает ли подобный подход? К сожалению, не всегда. В программировании, как в физике, есть законы.


Собрать толковую команду — настоящее искусство

Скажем прямо, русскому человеку планировать тяжело. Люди в России сильны импровизацией и умением собираться в критический момент, выдавая поразительные результаты. Но жизнь показывает, что команда программистов на подобной идеологии далеко не уедет. Героические усилия в одно время не смогут компенсировать пофигизм в другое.


Что общего у зомби-апокалипсиса и разработки ПО? Простые правила помогают пережить и то, и другое

Мы продолжаем цикл статей, в которых рассматриваем методологические вопросы создания программного обеспечения. Методология — это, прежде всего, владение стратегией через использование тех или иных принципов разработки. Знание принципов позволяет сделать работу более сознательной, предсказуемой и менее подверженной рискам. Управлению последними и посвящена статья.

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.

Архитектурные ошибки