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/

Еще одна статья от автора разбора кишков array_merge. На этот раз пережовывается один из способов управлением памятью в PHP. В статье приводятся примеры и объяснения, что такое copy-on-write https://zualex.com/posts/copy-on-write-php/

Вчера на Highload Олег Бартунов рассказывал про будущее jsonb в postgres. Доклад получился очень углубленным и обязателен для тех кто использует jsonb. Но главное что стало понятно - проделана огромная работа и предстоит проделать ещё больше.

История из жизни коллеги, пример как можно красиво отшить 🙂 Уже как только не мониторят кандидатов. Скоро ситуация будет как с банками, запустят холодный обзвон роботами.

Поучаствовал в пилотном backend выпуске на канале Отсобеседование https://www.youtube.com/watch?v=0QwxcSAzEQw

Еще один челендж, который прошел на работе с текущим проектом. Перевоз хранения файлов с NFS на S3 не поломав ничего.

Как перенести 3Тб файлового хранилища с локальной ФС сервера на S3? При этом у вас легаси проект на ~4 млн строк кода. По всему репозиторию раскиданы многочисленные fopen(), fwrite(), file_exists() и тд. Вся логика много лет строилась на работе с локальным хранилищем и отрефакторить займет возможно неделя или месяцы.

Первый рассмотренный вариант был примаунтить S3 как локальную ФС и жить дальше не меня кода. Готовое решение [https://github.com/s3fs-fuse/s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) Заманчиво. Но коллеги админы, которые успели хапнуть горя с подобным подходом, отговорили от этого. Есть серьезные проблемы с fuse, которые приводят даже к зависанию ноды и необходимости ее ребута, что скорее всего будет равно недоступности проекта. Рисковать так не хотелось. конечно же

Второй вариант. Реализовать на коленке watching файлов. Любой появившийся в локальной ФС новый файл или измененный сразу попадает в S3 с помощью дополнительной утилитки. На golang это делается буквально за несколько часов. Благо готовых решений хватает, например [https://github.com/fsnotify/fsnotify](https://github.com/fsnotify/fsnotify). Но это подразумевает дополнительный контейнер в каждом поде с приложением. Усложняет систему. Еще одна точка отказа. Вариант, но можно подумать еще.

Третий вариант. Самый "в лоб". пишем аналоги php функций для работы с файлами. Вместо fopen - fopens3(), которая файлик стягивает с S3 и кладет в локальную ФС контейнера а потом уже выполняет fopen(). Для fwrite пишем fwrites3 который копирует файл в хранилище. И так далее для всех остальных используемых функций. После чего поиском и заменой заменяем нативные функции на аналоги для s3. Заливаем все хранилище в S3 как есть, какой-нибудь утилитой вроде [https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html](https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html). При этом почти не трогаем код, риски поломать что-то минимальны, не усложняем систему, не завязываемся на еще одно стороннее решение как в первом варианте.

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

Сегодня вышел очередной выпуск отсобеседования https://www.youtube.com/watch?v=wOe0UF_5S7k В этот раз очень харизматичный и активный разработчик с широким кругозором. Когда занимаюсь наймом в команду, то всегда учитываю фактор увлеченности работой для миддлов и джунов. Нанимая такого человека всегда очень высокий шанс получить сеньора через полгода-год и кучу интересных предложений по рабочим задачам (конечно всему есть разумная граница 🙂 )