Техлидошная | Golang Infra Dev | Project Leading

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

Я нашел тут ту самую нишу, которая мне всегда была близка и интересна - платформенная разработка https://habr.com/ru/company/avito/blog/527400. Никакого больше бизнесового фиче-конвеера. Только кубер, service mesh, инфраструктура, golang и вот это все. Ну и контент будущий от меня тоже будет с этими темами чаще всего связан )

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

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

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

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

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

Unit-тесты

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

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

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

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

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

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

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

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

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

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

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

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

Как перенести 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). При этом почти не трогаем код, риски поломать что-то минимальны, не усложняем систему, не завязываемся на еще одно стороннее решение как в первом варианте.

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

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

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

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

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

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