У меня часто спрашивают о саморазвитии, а точнее как именно им заниматься, какой самый эффективный способ. Да и я тоже на собеседованиях всегда спрашиваю кандидатов как он развивается. Что удивительно этот вопрос очень часто, я бы даже сказал слишком часто, ставит людей в тупик. Ответы следуют вроде "читаю Хабр" или "читаю доки". Но что последнее из изученное им больше всего запомнилось никто вспомнить толком не может.

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

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

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

https://youtu.be/Pl0p3Kc2Bwg Захватывающая визуализация изменений в коде на одном из наших проектов за 2020 год. Подготовлено в программе https://gource.io/

Наш коллега Денис Черносов начал записывать серию небольших видео по архитектуре. Сейчас уже доступно несколько выпусков https://www.youtube.com/watch?v=-bxLHDu16cM&list=PLSXqHdiNX_qnbEL1WbvzeJqDSuklepXa0 и в ближайшем будущем ожидается продолжение, включая практические рецепты для архитекторов ПО

В роликах из предыдущего поста отличная мысль Дениса о сложности. То, с чем часто сталкиваются архитекторы, начиная от непонимания команды и заканчивая непринятие объема от бизнеса. Мы последнее время много спорили и анализировали возможность внедрения в проект практик CQRS на предмет решит ли это наши проблемы и какие другие привнесет. Вопрос действительно сложный и места для экспериментов тоже нет. Нельзя просто так сказать "теперь мы делаем вот так". То, что одному человеку очевидно, другим людям может быть совсем не понятно и наоборот.
Как известно любая архитеткура это набор компромиссов и само проектирование это меньше половины работы, так как затем начинается сложный процесс внедрения, особенно когда в команде не 3-5 разработчиков а 50+ и кодовая база уже накопилась немаленькая.

Внезапно целый чей-то проект, рабочий, коммерческий, в открытом доступе на гитхабе https://github.com/automagistre/automagistre

История о поиске решения для распреденных кронов

В прошлом месяце искали решение для распределенного запуска кронов. Задача: три отдекльных, но при этом идентичных кластеров проекта, на которые балансируется весь трафик и каждая крон таска должна запускаться только один раз в одном кластере. Вначале казалось что все достаточно просто: делается где-то лок и проблема решена. Начали искать непосредственно то самое "где-то" для хранения локов.
Посмотрели первым https://dkron.io/, который выглядел очень интересно. Однако у него нужный функционал федерации оказался только в платной версии (750$ в год). Но дело даже не в платности, а (внезапно!) отсутствии триала. То есть просто взять и потыкать нельзя, необходимо сначала заплатить. Такая агрессивная политика разработчика немного оттолкнула.
Далее был рассмотрен вариант запуска через очереди, который вроде бы очень просто выглядит: при срабатывании крона мы не запускаем процесс, а ставим его в очередь. Однако, при более детальном рассмотрении начали всплывать нюансы. Все равно требовался лок с обеспечением атомарности между кластерами.
И тут вспомнили про Consul и про наличие у него замечательной фичи https://www.consul.io/commands/lock специально для такой задачи и разработанной. Consul хорошо работает в распределнных системах, имеет простой АПИ, готовые клиенты под наш стэк, и что самое главное не потребует масштабных переписываний всех команд, как в предыдущих случаях.
Пока еще тестируем и пробуем это решение, но выглядит оно очень много обещающе. До конца марта обкатаем в проде и расскажем о результатах.

https://github.com/jasontaylordev/CleanArchitecture Хоть и на шарпах, но разобраться не проблема. Сейчас как раз пытаюсь текущий проект повернуть в сторону чистой архитектуры. Главные проблемы как ни странно не с пониманием всей командой проекта (50+ иразработчиков) ценностей и принципов. Главная сложность как это контролировать, как не допустить расползания и скатывания в Big Ball of Mud от ошибочных действий.
Думаю через какое-то время родится история как это в итоге работает в продакшене 🙂

Мой коллега Денис Черносов продолжает делать полезные видосы

Следующее видео от Дениса. На этот поговорит о PlantUML https://youtu.be/85jKCusr6tk

Первый выпуск GoLang дайджеста от нашего коллеги Вадима Тимофеева 👍
https://habr.com/ru/company/vseinstrumenti/blog/541612/

Напоминаю, что завтра пройдет митап про MySQL, нагрузкам и асинхронности https://habr.com/ru/company/vseinstrumenti/news/t/540566/ В программе мероприятия два доклада и дискуссия на тему асинхронности в PHP и будущего этого направления в языке.
Для наиболее активных участников подготовлены приятные подарки в виде слонов 👆

Начало 12 февраля в 17:00 Ссылка на регистрацию https://vi-tech.timepad.ru/event/1546475/

Сходил на запись подкаста "Между скобок" про работу архитектора https://soundcloud.com/between-braces/12-anton-gubarev-rabota-arkhitektora

https://habr.com/ru/company/vseinstrumenti/blog/544640/ Подъехал очередной выпуск Golang дайджеста

Перевозим сайт на распределнную работу в 3ДЦ. Казалось бы простая задача с запуском cronjob в независимых кластерах вылилась в пробы нескольких вариантов. Consul, DKron, чуть ли не база. В итоге решение нашлось на удивление простое - использовать Redis SETNX. В очередной раз убеждаюсь, что надо думать проще изначально. https://news.1rj.ru/str/vseins_tech/15

Тем временем у кого-то сгорел делый ЦОД https://habr.com/ru/news/t/546264/ Хотя в голове не укладывается как такое могло произойти. Это же не сарай чтобы раз и все. Там серверов на столько денег, что проще нули считать сразу. И при таких рисках вложения в противопожарную безопасность должны быть максимальными казалось бы. Но видимо где-то просчет оказался.

Каеф

Deptrac https://github.com/qossmic/deptrac Жизненно важная тулзовина для контроля архитектуры проекта. Позволяет настраивать правила, по которым проверяет зависимости между директориями или неймспейсами. Правил достаточно много разных и можно формировать их по имени класса, имени директории, родителям или интерфейсам. И конечно же можно использовать регулярки.
Пример. Мы разделяем наш код на бандлы, которые взаимодействуют между собой через контракты, такой антикоррупционный слой. Проверка deptrac-ом внедрена в CI, и он смотрит чтобы не было обращений между бандлами только по контрактам.
Попутно разделяем бандлы на слои. И опять deptrac позволяет мониторить соблюдение этого правила и отсутствия прямой зависимости, например, домена от инфраструктуры или от приложения.
Его наличие дает возможность спать спокойно и не бояться, что завтра вся архитектура проекта начнет расползаться и трещать по швам. Особенно когда ваш репозиторий на несколько десятков человек.

Как-то незаметно прошло мимо появления такой необходимой штуки как https://www.asyncapi.com/ Это как OpenApi только для асинхронных сообщений например очередей, событий и т.д. В довесок уже идут готовые инструменты: парсеры, генераторы и даже actions для github. Очень и очень интересная инициатива с уже большой дорожной картой.

Нашлось уже несколько появлений в эфире упоминания этой спецификации

https://linuxfoundation.org/en/press-release/linux-foundation-will-host-asyncapi-to-support-growth-and-collaboration-for-industrys-fastest-growing-api-spec/

https://engineering.salesforce.com/asyncapi-and-openapi-an-api-modeling-approach-db9873695910

Интересный разбор различных способов объединения массивов в PHP в плане скорости работы и потребления памяти от нашего коллеги Алексндра Зубарева http://zualex.com/posts/php-array_merge-performance-in-a-loop/