Как-то незаметно прошло мимо появления такой необходимой штуки как 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 завтра, сегдня для патронов.

#18 Сеньор в 23? Собеседование Middle Backend разработчика

Новый выпуск уже доступен на патреоне: https://www.patreon.com/otsobes

За последний месяц прошёл несколько собеседований. Хотел изучить рынок, узнать чего хотят, сколько платят. Пробежался по компаниям, о которых слышали не только вы но и ваши родители и знакомые. Получил кучу полезной информации, которой поделюсь в понедельник на стриме. Приходите) https://youtu.be/_7qEgYQWF9Q

https://github.com/emirpasic/gods Полезная реализация алгоритмов и структур данных для гоферов

https://github.com/vulcand/oxy Отличный двиг для тех кто пишет свой прокси. Кстати говоря используется в traefik

Unit-тесты

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

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

На картинке, которую я так долго искал, как раз мой взгляд на юнит тесты.

Они тоже конечно нужны и никто не призывает от них отказываться, ни в коем случае. Вопрос только в приоритезации.