Давно бьюсь с любителями замокать все подряд. Я бы сказал Mock Driven Developer’ами. Оказывается уже 6 лет как написана статья Робертом С Мартином, который сказал “Mock across architecturally significant boundaries, but not within those boundaries”. Не добавить не убавить. http://blog.cleancoder.com/uncle-bob/2014/05/10/WhenToMock.html

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

https://stringconcat.com/ru/work-for-faang-ru-2/

Заключительная статья из цикла о работе в конторах уровня FAANG. Про деньги, оценки эффективности и перспективы трудоустройства после. Ну, и главный вывод из всего цикла: поработать хорошо, но неведомого чуда не произойдёт.
https://stringconcat.com/ru/work-for-faang-3-ru/

Боже, это просто чудесная утренняя история: исследователь безопасности заметил в статье сотрудника PayPal упоминание нескольких внутренних пакетов, в т.ч. analytics-paypal. И для эксперимента разместил пакет с таким же названием в публичном репозитории. И что вы думаете, конечно же часть внутреннего софта от PayPal собралась с использованием его пакета, который "стучал на землю" ему в сервера.

Как следствие исследователь провернул совершенно аналогичную атаку на почти все крупные айти компании-гиганты. И если подумать, я знаю где у меня совершенно такие же проблемы, пойду чинить https://www.bleepingcomputer.com/news/security/researcher-hacks-microsoft-apple-more-in-novel-supply-chain-attack/

Никогда такого не было и вот опять!

Интересный пост от Владимира Хорикова о DDD-трилемме. Не совсем согласен с выводом о том, что нужно предпочитать чистоту (мне больше по душе инкапсуляция), имхо всё-таки некоторые внешние операции допустимы, правда их совсем немного. Но такая трилемма действительно имеет место быть.
https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/

Хорошая подборка бесплатных и условно-бесплатных сервисов для разработчиков. CI/CD, мониторинг, управление логами, бесплатные опции крупных облачных провайдеров и другое.

https://free-for.dev

Если вы только собираетесь создавать новый проект на java\kotlin\scala, то я для вас нашел отличный репозиторий. Из него можно позаимствовать gradle\maven конфигурацию, с подключенными и настроенными тулзами типа линтеров, jococo и всех прочих.

Если же не собираетесь стартовать — просто почитайте его readme файл, уверен что вы найдете не одну best практику, которую стоит использовать.

https://github.com/binkley/modern-java-practices

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

https://stringconcat.com/ru/coding-interview-ru/

Вышел свежий техрадар. Рекомендую походить по расхлопам, почитать мотивационную часть и референсы. Также обратите внимание на тренд той или иной техники или платформы.

На что я обратил внимание
- пара ссылок на книгу Team Topologies (в когнитивной нагрузке и платформенных командах);
- облачные песочницы, даешь дев-стенды разработчикам!
- захолдили SAFe и GitOps.
- захолдили пулл-реквесты как инструмент peer review (недавно делал пост со схожими мыслями).

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

Знакома ли вам ситуация, когда ответом на любой вопрос является "так исторически сложилось"?
-Почему у нас здесь микросервисы?
-так сложилось. Всегда были.

-почему мы используем кафку?
-не знаю, вроде нормально ведь.

Чтобы не попадать в такие ситуации придуманы architectural decision records. Это фиксация принятых архитектурных решений с обоснованием почему. Если хотите начать использовать, то вам в помощь прекрасный шаблон ведения таких записей.

https://github.com/adr/madr

Да, это хорошая идея вести запись прямо в репозитории

Одно дело, когда политик спрашивает «Как ваши дела?», и совсем другое, когда ваша мама спрашивает «Как ваши дела». Они имеют ввиду совершенно разные вещи.

Таким образом, 2 семантически одинаковые фразы имеют совершенно разное значение в зависимости от контекста. И вот тут то мы пришли к определению Bounded Context из DDD.

Как определить, что мы наткнулись на 2 контекста? Ответ прост: когда одна фраза (или сущность) не может быть понята однозначно без знания контекста.

Нашли такую фразу? Поздравляю! Вы нашли bounded context. И два значения одного и того же термина.

💀 Тем, кто устал

Айти — постоянная гонка, от которой можно и приуныть в конце-концов. Сегодня поговорим о том, как выжить, когда уже сил не осталось.

Наш каток прагматического гуманизма пройдёт по порочным практикам накопления приёмчиков и коллекционирования фреймворков, чтобы подготовить ровную площадку для ясной системы знаний. А ещё немного пошутим о наболевшем.

Приходите читать!

https://stringconcat.com/ru/get-sane/

Не всюду разработчику хорошо. Бывает, с виду всё нормально, но на деле проект оказывается полон особенностей. День за днём они грызут душу и тело, люди выгорают и отправляются на мороз, общаться с психоаналитиком.

Чтобы избавить вас от подобного опыта, мы составили тест на оценку кровавости энтерпрайза. Отправьте потенциальному работодателю или покажите текущей команде, но лучше пройдите сами.

https://bloody-enterprise.stringconcat.com/#/

Только-только вышла в свет вторая версия Микросервисов от Сэма Ньюмана. Судя по доступному сэмплу он уж больше рассказывает о технических подробностях реализации, таких как распределенная трассировка, агрегатор логов. Но самое интересное - это книга не агитирует "за" микросервисы, но и не агитирует "против". Обещается очень здравый подход с описанием альтернатив микросервисам. Книга сейчас доступна только в версии для Kindle. На английском само собой https://www.amazon.com/Building-Microservices-Sam-Newman-ebook-dp-B09B5L4NVT/dp/B09B5L4NVT/ref=mt_other?_encoding=UTF8&me=&qid=1628333621

Послезавтра проводим митап уходящего лета. И программа получается несколько монолитной) Первый докладчик – Олег Федосеев (@olegfedoseev) из Циан расскажет про вторую жизнь монолита:

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

Очень актуальная тема на наш взгляд. Ссылка на митап https://www.youtube.com/watch?v=5Adgq-4KJoo, вопросы можно задать тут - https://app.sli.do/event/3xzwxrro

Проводим очередной вебинар по Clean Architecture. Если кто ещё не видел — подключайтесь!

https://youtu.be/lQMWGWA9FYs

Robert Laszczak из Three Dots Labs написал на английском про тёмные века софтверной разработки: https://threedots.tech/post/software-dark-ages/

Роберт описывает классическую ситуацию: все хорошие практики уже давно придуманы, но в компаниях про них не слышали и продолжают поклоняться идолищам. Изменения выкатываются месяцами, микросервисы тонут в зависимостях, никто не знает, какую проблему решает. Ну, всё то, о чём мы сами рассказываем (и во что вляпываемся).

Автор наглядно объясняет, как такая ситуация возникает:

1. Не поняли, что нужно → получили унылое и дохлое.
2. Повторяем 1 пункт, пока не надоест.

Еще Роберт пишет, что делать и почему этого ещё не сделали и, конечно же, проповедует благое DDD.

А Женя из @dddevotion вдруг взял и перевёл статью специально для тех, кому лень читать по-английски. За что ему большое спасибо!

Нил Форд, автор fundamental of software architecture, опубликовал новую книгу “The hard parts of software architecture”. В ней он говорит в сущности о трех вещах:
— каждое ваше архитектурное решение это компромисс
— о том, насколько большими должны быть сервисы
— о коммуникации между сервисами

Послушать о книге можно в подкасте Thoughtworks:
https://www.thoughtworks.com/en-sg/insights/podcasts/technology-podcasts/the-hard-parts-of-software-architecture

Книга доступна только в электронном виде, ну и, конечно, только на английском:
https://www.amazon.com/Software-Architecture-Parts-Neal-Ford-ebook-dp-B09H2H5QKC/dp/B09H2H5QKC/ref=mt_other?_encoding=UTF8&me=&qid=1634275068

На самом деле очень сложно найти хорошую книгу по архитектуре. И “Fundamentals of Software Architecture” я прочитал на одном дыхании, а кое-что даже ни один раз. Полагаю, новая книга станет бестселлером!