Сходил на запись подкаста "Между скобок" про работу архитектора 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 В этот раз очень харизматичный и активный разработчик с широким кругозором. Когда занимаюсь наймом в команду, то всегда учитываю фактор увлеченности работой для миддлов и джунов. Нанимая такого человека всегда очень высокий шанс получить сеньора через полгода-год и кучу интересных предложений по рабочим задачам (конечно всему есть разумная граница 🙂 )

https://healthchecks.io/ Хелсчеки по push модели. Ваше приложение отправляет хелсчеки на этот сервис, а он контролирует что они приходят с нужной периодичностью. Например, по окончании работы вашей крон утилиты отправляете что все прошло ок. Как только "ок" не придет вы получите уведомление об этом. А если ваш чек все же отработал, но с ошибкой, то можно отправить в сервис информацию что случилась ошибка.

Проект открытый и можно поставить себе и пользовать без ограничений, либо за небольшую плату использовать "облачную" версию (есть бесплатный тарифный план). Есть куча интеграций с телегой, слаком, ватсапом и прочими каналами уведомлений, включая смс и телефонные звонки. Можно даже отправлять в OpsGenie, где уже настроить эскалирование инцидента.
А еще автор на странице about выкладывает информацию сколько приносит денег его проект, сколько пользователей, сколько платящих. Но главное в этом то, что ему удалось сделать то, что несколько раз пытался сделать я. Он свой хобби проект превратил в способ заработка. Белая зависть 🙂

Очередная архитектурная полезняшка от Дениса

Наш коллега Денис Черносов записал видео "Принцип подстановки Барбары Лисков геометрическая интерпретация" https://www.youtube.com/watch?v=BwuiNEyegTc , который попал в свежий PHPDigest.
Для многих по отзывам этот самый непонятный приниц стал теперь более понятным. Спасибо!

https://github.com/direnv/direnv Когда работаете с сервисами, у которых не предусмотрена работа с .env файлами.

Строим веб сервис в новом выпуске отсобеседования. Никаких теорий, только практические задачки из реальной (почти) жизни.
Выпуск выдет на youtube завтра, сегдня для патронов.