В разработке цветет культ Карго. Многие программисты полагаются на слова, которые сказал какой-то очень уважаемый автор десятки лет назад. Они продолжают разрабатывать код, опираясь на подходы, которые либо не актуальны, и даже сам автор уже давным-давно поменял свою точку зрения. И сегодня мы поговорим о некоторых очень распространенных принципах программирования, которые не так однозначны, как может показаться на первый взгляд.

Меня зовут Кирилл Мокевнин, и я — сооснователь школы программирования Хекслет. За последние пару лет я провел собеседования с более чем 400 человек, потенциальными наставниками по совершенно разным направлениям в разработке. В результате у меня собралась большая выборка наблюдений, которые мы и разберем в этой статье.

"Читатель проживает тысячу жизней, прежде чем умрет.. Человек, который никогда не читает, проживает только одну "

- Джордж Р.Р. Мартин.

Многим, кто работает с MySQL, известно, что команда EXPLAIN используется для оптимизации запросов, получения информации об использованных и возможных индексах. Большинство разработчиков и администраторов СУБД этой информацией и ограничивается. Я же предлагаю изучить команду EXPLAIN максимально подробно.

Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).

Обычный, теневой, виртуальный, инкрементальный… Как получилось, что простой программный интерфейс доступа к элементам веб-страниц обзавелся таким количеством «родственников»? Чем современные фреймворки не устраивает стандартная объектная модель документа или просто DOM? Что и как на самом деле отрисовывает браузер в процессе рендера веб-страницы?

Всем привет, это Макс Кравец из Holyweb. Помните сцену из Матрицы, в которой один из юных кандидатов в Избранные наставляет Нео: «Не пытайся согнуть ложку. Первое, что ты должен понять — ложки не существует!»? Давайте переформулирую: «Не пытайся изменить DOM...». А вот о том, что прячется под многоточием, мы сегодня и поговорим.

Эта статья подходит для тимлидов и их подопечных, а также для всех, кто оценивает проекты и задачи. Я расскажу, как и почему мы делаем ошибки из-за когнитивных искажений. Попадаем в них мы почти все, просто потому что мы живые люди. И на примере одного дня из жизни тимлида я хочу показать, в какие искажения чаще всего влетают в IT, и  — самое полезное  —  как из них можно выходить.

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

Как известно, с ростом размера кода приложения его становится все сложнее и сложнее поддерживать. Рассмотрим подход, как с наименьшими усилиями структурировать код Symfony приложения так, чтобы снизить затраты на внесение в него изменений и упростить переиспользование или замену его частей. По каким принципам разбивать функционал на модули, как обобщать, как называть, разберем на примере. У нас будет цельное приложение, но если понадобится, выделить нужный компонент мы сможем с минимальными усилиями.

Привет, Хабр! Меня зовут Сергей Радченко, и мы с командой профессионально занимаемся тестированием уже несколько лет. Сегодня я посчитал количество автотестов, которые мы подготовили для веб-интерфейсов, десктопных приложений, API, систем двухфакторной авторизации и так далее (их оказалось более 5000). И мне захотелось рассказать о нашем опыте создания экосистемы для автоматизированного тестирования. В этом посте вы найдете описание полезных для комплексного тестирования фреймворков, а также исходный код некоторых дополнительных методов, которые мы дописали самостоятельно, чтобы написание тестов происходило быстрее, и тестирование приносило больше пользы. 

Привет, Хабр! Немного запоздало (ко дню программиста) делюсь подборкой бесплатных книг по программированию. Все они полезные, уровень скорее профессиональный, хотя и для развития от базового тоже подойдет, но, к сожалению, на английском. Среди тем книг: .NET, Алгоритмы, Android, iOS, Angular, C, C++, C#, JS, Linux, Python. В целом, найдется почти любая тема, которая приходит в голову.

Дисклеймер. Все эти книги взяты с одного ресурса, который существует за счет донейшенов. Получить книги можно без осуществления донейшенов, ресурс полностью бесплатный, пожертвования опциональны. Все книги написаны на основе контента со StackOverflow и являются код-ориентированными. Книги со временем обновляются. По ссылкам -- книги, актуальные на 15.09.2021.

Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

Цель этой статьи показать и объяснить многообразие дистрибутивов Линукс. Показать основные сходства (они же все почему то называются "Линуксы" или даже правильнее "GNU/Linux") и основные различия (если бы не было различий их бы столько не существовало).

Плюс рассмотрим несколько наиболее задаваемых новичками вопросов:
- Сколько их (Linux-дистрибутивов)? Зачем так много?
- Основанный на другом дистрибутиве" - не пиратство ли это?
- Платный Linux - Как можно продавать то, что по определению распространяется бесплатно?
- Что такое "отечественный Linux"?

Эта статья является переводом материала «Domain model isolation».

Термин «изоляция модели предметной области» уже давно используется, но его значение может быть не таким очевидным, как многие думают. В этом посте автор оригинала попытается описать, что значит правильно изолировать модель предметной области и почему это важно.

Тема изучения английского вызывает недоумение. С одной стороны, действенные рецепты крайне просты и доступны каждому. С другой стороны, информационное поле до отказа набито стереотипами, мнениями, обещаниями и другими видами шума. По удаленности этих сторон друг от друга она может сравниться, наверное, только с темой похудения (хотя науке решение этой проблемы прекрасно известно).

Когда-то давно я вышел из школы, так же как и большинство соотечественников, совершенно не зная английский. Сейчас я свободно им владею, постоянно пользуюсь и это сильно помогло мне в жизни. Дорога между этими двумя точками была совсем не оптимальной, так же как дорога многих людей вокруг меня. Поэтому хочу поделиться своим разнообразным опытом изучения английского, опытом моих знакомых, за которыми я наблюдал последние 15 лет, а также дать простые рекомендации и инструменты для начинающих и продолжающих.

SOLID критикует тот, кто думает, что действительно понимает ООП
© Куряшкин Виктор

Я знаком с принципами SOLID уже 6 лет, но только в последний год осознал, что они означают. В этой статье я дам простое объяснение этим принципам. Расскажу о минимальных требованиях к языку программирования для их реализации. Дам ссылки на материалы, которые помогли мне разобраться.