Как по мне достаточно важная, хотя и холиварная тема. Думаю каждый из нас задавал себе вопросы: "можно не дублировать проверки?", "а не усложняю ли я?", "да как же это сделать нормально?!".

Эта статья аккумулирует в себе те практики, которые мне близки и которых я придерживаюсь в разработке.

Текст рассчитан не на новичков, потому нормально, если по ходу чтения какие-то понятия будут вам неизвестны, я постарался коротко раскрыть их здесь, а также указал ссылки на посты в моём телеграм канале Beer::PHP ​, которые могут чуть подробнее раскрыть то или иное понятие.

Начнем мы сразу с доменного слоя нашего приложения, то есть с бизнес логики нашего приложения.

Основной посыл этого поста - рассказать о развитии своей старой идеи, которая переделывалась несколько раз, и прошла путь от простой кривой WinForm до полноценного кросс-платформенного приложения на Electron'e.

У меня нет цели прорекламировать программу (хоть она бесплатная, без подписок и рекламы), поэтому я не буду оставлять ссылки на скачивание, просмотр, но если это разрешено - отвечу на подобные вопросы в комментариях.

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

Проблема неполной индукции

Знаменитый древнегреческий философ Аристотель в своем трактате «Аналитика» выделяет два вида возможных умозаключений - индуктивное и дедуктивное.

Дедуктивное умозаключение - это логический вывод о частных случаях исходя из общего правила. Индуктивное умозаключение - это логический вывод об общем правиле исходя из частных случаев.

Классическим примером дедукции, которую сам Аристотель называл силлогизм, является следующее рассуждение: все люди смертны (общее правило), Сократ - человек (частный случай), следовательно Сократ смертен (дедуктивный вывод).

Индукцию Аристотель делил на два вида: полную и неполную. Полная индукция - это вывод общего правила на основе свойств всех элементов множества, а неполная - это предположение об общем правиле на основе части элементов множества.

Недавно вышел Angular 12, а вместе с ним в шаблоны подвезли оператор нулевого слияния (??). Но что еще умеют шаблоны Angular, о чем вы, возможно, и не слышали? Давайте разберемся!

Здравствуйте, меня зовут Дмитрий Карловский и раньше я тоже использовал Perl для разработки фронтенда. Только гляньте, каким лаконичным кодом можно распарсить, например, имейл:

/^(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,})|("(?:((?:(?:([\u{1}-\u{8}\u{b}\u{c}\u{e}-\u{1f}\u{21}\u{23}-\u{5b}\u{5d}-\u{7f}])|(\\[\u{1}-\u{9}\u{b}\u{c}\u{e}-\u{7f}]))){0,}))"))@(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,}))$/gsu

Тут, правда, закралось несколько ошибок. Ну ничего, пофиксим в следующем релизе!

Некоторые любят ездить велосипедах, а некоторые любят их изобретать. Я отношусь к тем, кто изобретает велосипеды, чтобы на них ездить. Пару лет назад я уже писал на Хабр про этот свой "велосипед" - контейнер внедрения зависимостей (DI container) для JavaScript. Последующее обсуждение принципов работы DI-контейнеров и их отличие от "Локатора Сервисов" достаточно сильно продвинуло меня в понимании работы моего собственного "велосипеда" и вылилось не только в ряд статей на Хабре (раз, два, три, четыре), но и в значительной доработке самого "велосипеда".

Под катом - описание работы DI-контейнера (@teqfw/di) по состоянию на текущий момент. Ограничения: контейнер написан на чистом JavaScript (ES2015+), работает только с ES2015+ кодом, оформленным в ES-модули с расширением *.mjs . Преимущества: позволяет загружать и использовать одни и те же модули как в браузере, так и в nodejs-приложениях без дополнительной транспиляции.

Какой самый популярный стиль организации кода вы встречали в корпоративных кодовых базах? Лично я чаще всего видел решение, подразумевающее группировку всех файлов по их типу. Таким образом, к примеру, в системе MVC все контроллеры, все сервисы, все репозитории, все POJO и так далее находятся вместе. Давайте назовем такое решение "стековым" стилем организации кода.

Сразу хочу успокоить. Сегодня SCRUM это уже не так страшно как десять лет назад. Современная медицина достигла невероятных высот. Люди со SCRUM живут полноценной жизнью. Остаются активными членами общества. Главное -  своевременно подобрать правильный режим лечения.

* В данной статье примеры будут на TypeScript

Краткое предисловие

Что такое DDD (Domain Driven Design) вопрос обширный, но если в кратце (как Я это понимаю) — это про перенос бизнес логики, как она есть, в код, без углубления в технические детали. То есть в идеале, человек, который знает за бизнес процессы, может открыть код и понять, что там происходит (так кстати часто бывает в 1С).

Всё это сопровождается кучей разных рекомендаций по технической реализации вопроса.

Для лучшего понимания статьи советую прочитать материалы, касающиеся DDD.

Статья об одном неудачном решении, которое распространено при переходе на микросервисы. Несмотря на то, что Microsoft и другие компании в своих руководствах рассматривают возможность создавать Entity Services, есть все основания считать его антипаттерном. Далее мы поговорим о том, что такое Entity Service и какими свойствами он обладает для конечной системы в целом.

Роберт Мартин представил принципы SOLID в 2000 году, когда объектно-ориентированное программирование стало настоящим искусством для программистов. Каждый хочет создать что-то долговечное, которое можно использовать повторно, насколько это возможно, с минимальными изменениями, которые потребуются в будущем. SOLID - идеальное название для этого.

Фактически, объектно-ориентированное программирование работает лучше всего, когда мы можем отделить то, что останется, от того, что изменится. Принципы SOLID помогают разделять это.

Мне лично нравится идея, лежащая в основе принципов SOLID и я многому из нее научился.

Сколько людей в стране не любят свою работу и вообще ненавидят свою жизнь? Три года назад мне в руки попало одно очень занятное исследование Google: Barriers, motives & triggers of entrepreneurship. Три тысячи респондентов, очищенная выборка, больше ста российских городов, интервью дольше 20 минут. Там были несколько чисел, которые меня, мягко говоря, ошеломили.

Генри Форд чуть не прогорел на своей фразе про пятьдесят оттенков черного. General Motors стала предлагать разноцветные модели Chevrolet, Pontiac, Buick, Oldsmobile и Cadillac — и не прогадала. Глядя на это, даже упрямый Форд изменил свое мышление  — и разработал новый Ford A, вернувший его на автомобильный Олимп. Бывают времена, когда парадигма мышления должна стать новой — ибо человек умирает тогда, когда перестаёт меняться ©Генри Форд. 

Пришло время и для разработчиков. Command Query Responsibility Segregation (CQRS) и Event Sourcing (ES) уже не миф — они реально работают. Конечно, не для всех задач — как и классический черный цвет Форда, PHP никуда не исчез и нужен по-прежнему. Но теперь уже есть задачи, где мы встречаемся с CQRS и ES чаще, чем нам кажется. Антон Шабовта на PHP Russia 2021 расскажет, как смена парадигмы и взгляд с другой стороны помогают разработчикам. А перед конференцией мы расспросили Антона подробнее о его новых взглядах на разработку, PHP и, конечно, о CQRS и ES.

Функциональное программирование может отпугивать сложностью и непрактичностью: «Я далек от всех этих монад, пишу на обычном C#, в докладе про функциональщину ничего не пойму. А если даже напрягусь и пойму, где мне потом это применять?»

Но когда объясняет Скотт Влашин, все совершенно не так: его доклад о композиции с конференции DotNext 2019 Moscow — пример того, как можно доносить функциональные идеи простыми словами. Он за час перешел от бананов к монадам так, что второе кажется немногим сложнее первого. А в конце объяснил, почему осмыслить композицию полезно даже тем, кто не собирается покидать мир ООП. Примеры кода в докладе как на F#, так и на C#.

Уже завтра начнется новый DotNext, где я помогу Скотту выступить с другим докладом, а пока что публикую перевод его выступления про композицию. Далее повествование будет от лица Скотта.

Одна из отличительных особенностей Верхней Пышмы – в отличие от многих промышленных городов население в нём растёт с 1959 года за редким исключением. Если в 1959 году в городе жили 30 тысяч человек, то в 2020 году в Верхней Пышме насчитывается 72 тысячи человек.

Возможно, одна из причин этого – Верхнюю Пышму сознательно развивают. Одним из инструментов для создания стратегии стал анализ школьных сочинений: то есть у тех людей, которые будут строить будущее этого города, просто спросили, что им нужно.

В этом посте – об истории образования города и его стратегии развития, которая предусматривает рост населения до 120 000 человек к 2035 году.

У функционального программирования есть одна большая проблема — о нем очень непросто рассказывать. Попытки донести людям что-то с использованием терминов типа «зигохистоморфный препроморфизм» легко сводят неподготовленного слушателя с ума.

Марк Симан — автор популярной книги Dependency Injection in .NET, автор бесчисленных блог-постов. На DotNext 2017 Moscow Марк рассмотрел применение dependency injection в классическом объектно-ориентированном дизайне и объяснил, почему его необязательно (даже нежелательно) использовать в функциональном программировании. Следом за этим он наглядно показал, как использование приемов функционального программирования устраняет необходимость в использовании моков и стабов в модульном тестировании и позволяет полностью выбросить мусор из прямого перечисления зависимостей.

Под катом — перевод доклада и видео. Далее повествование будет от лица Марка.