Записи

В скором времени мне потребуется расширить свой стек ещё одним языком программирования — Kotlin. Меня не беспокоит процесс погружения в синтаксис, это самое простое, что может быть. Как и всегда, во главу угла я ставлю вопрос о простоте, скорости и воспроизводимости развёртывания, особенно локального окружения разработчика — в команде я буду работать не один, и важно, чтобы версии компиляторов совпадали у моих коллег до миллибитов.

Наши команды активно используют ansible для создания шаблонов и финальной конфигурации виртуальных машин. Поэтому перед нами встаёт вопрос обеспечения работоспособности и корректности сценариев развёртывания.

В этой заметке будет рассказано об имитации systemd внутри docker-⁠контейнера и валидации финального результата с помощью фреймворка testinfra.

Technical Breadth — определение, которое я впервые услышал в английском варианте от архитектора Марка Ричардса (Mark Richards). Если грубо переводить его на русский язык, оно означает “технический кругозор”. Аналогом этого слова у дизайнеров является “насмотренность”.

Что делать с этим понятием и как расширять свой технический кругозор?

Semantic Workspace — это просто красивое название, которое я придумал полгода назад для ряда простых принципов организации каталога с проектами на локальной машине.

Все наши сервисы полностью соответствуют 12 факторам. Но в этой заметке речь пойдёт только об одном из них — конфигурации через переменные окружения, а точнее про недооцененный инструмент direnv, позволяющий автоматически загружать переменные окружения при переходе в каталог с проектом.

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

В своей работе мы постоянно используем различные инструменты: protoc, golangci-lint, allure и многие другие.

Чтобы избежать ситуации, в которой версия или конфигурация инструмента у одного разработчика отличается от того, что уже установлено у другого, или от того, что настроено в CI, наши инструменты “запечены” в контейнеры.