Многие из нас используют в работе несколько компьютеров. И, конечно, используют если не одинаковые, то пересекающиеся наборы приложений и инструментов, которые требуют одинаковой конфигурации на всех машинах:
gitvim/nvimtmuxeditorconfigkarabinerzshОбычно, конфигурационные файлы называются дотфайлами (dotfiles) — их имена начинаются с точки (.), что в мире
unix-подобных систем делает файл скрытым.
Один из моих подписчиков подсветил проблему, что исходный код решений, которые мы реализуем на стримах не был доступен публично. Признаться честно, я не думал, что он может быть кому-то полезен вне контекста стрима — мы показываем процесс решения проблемы, трансформируя его в приемлемый результат. Оказалось, что моё мнение ошибочно, и исходники всё же представляют интерес.
С недавнего времени я перестал стесняться и осуществил свою давнюю задумку — запустил канал на youtube. Мне всегда хотелось показывать и рассказывать о подходах к разработке без кликбейтных картинок и заголовков, говорить по делу и передавать свой опыт другим людям.
В скором времени мне потребуется расширить свой стек ещё одним языком программирования — Kotlin. Меня не беспокоит
процесс погружения в синтаксис, это самое простое, что может быть. Как и всегда, во главу угла я ставлю вопрос о простоте, скорости и воспроизводимости развёртывания, особенно локального окружения разработчика — в команде я буду
работать не один, и важно, чтобы версии компиляторов совпадали у моих коллег до миллибитов.
Наши команды активно используют ansible для создания шаблонов и финальной
конфигурации виртуальных машин. Поэтому перед нами встаёт вопрос обеспечения
работоспособности и корректности сценариев развёртывания.
В этой заметке будет рассказано об имитации systemd внутри docker-контейнера
и валидации финального результата с помощью фреймворка testinfra.
Technical Breadth — определение, которое я впервые услышал в английском
варианте от архитектора Марка Ричардса (Mark Richards). Если грубо переводить
его на русский язык, оно означает “технический кругозор”. Аналогом этого
слова у дизайнеров является “насмотренность”.
Что делать с этим понятием и как расширять свой технический кругозор?
Semantic Workspace — это просто красивое название, которое я придумал полгода
назад для ряда простых принципов организации каталога с проектами на локальной
машине.
Все наши сервисы полностью соответствуют 12 факторам. Но в этой заметке речь
пойдёт только об одном из них — конфигурации через переменные окружения, а точнее про недооцененный инструмент direnv, позволяющий автоматически
загружать переменные окружения при переходе в каталог с проектом.
В этом посте речь пойдёт про организацию очереди отложенных задач в базе данных. На практике выяснилось, что очень большое количество разработчиков эту идею принимают с большим трудом, сразу же выражают обеспокоенность искусственно созданной нагрузкой. С одной стороны, это грамотное замечание. С другой — это тот барьер, через который надо научиться переступать, наблюдать за вашим приложением и грамотно настраивать базу.
В своей работе мы постоянно используем различные инструменты: protoc,
golangci-lint, allure и многие другие.
Чтобы избежать ситуации, в которой версия или конфигурация инструмента у одного
разработчика отличается от того, что уже установлено у другого, или от того, что настроено в CI, наши инструменты “запечены” в контейнеры.