Записи

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

Строя облачные сервисы, мы в своей работе постоянно используем виртуальные машины. В продакшине — гипервизоры первого типа, которые, говоря простым языком, ставятся на “голое железо”; на своих локальных машинах — второго типа, это привычные нам всем VirtualBox, qemu и, возможно, Parallels Desktop.

К большому сожалению, несмотря на наличие продвинутых систем сборок, нам всё ещё приходится использовать утилиту make и писать Makefile-⁠ы руками.

Передо мной встала задача по составлению справки по целям сборки в текущем Makefile проекта. Из коробки древняя утилита не позволяет получить список целей сборки и их описание, которого не предполагалось.

Вся техническая документация наших проектов пишется в формате Markdown. Это простой и удобный формат, который можно читать даже в сыром виде без постобработки.

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

Чтобы не выделять отдельный проект в общем Sentry, предпочитаю разворачивать собственную локальную копию.

Процесс развёртывания занимает некоторое время, для “старого” ноутбука, процедура может занять минут десять.

Многие команды для обсуждения и ведения ADR используют инструменты, подобные Confluence и Wiki. Все мы прекрасно понимаем, что это подход “write once, read never”.

ADR — Architecture Decision Record.

Часто сталкиваюсь с недооценкой использования ADR в разных командах разработки.

asdf — менеджер версий рантаймов.

С его помощью можно заменить nvm, rbenv , pyenv, gvm и ещё массу менеджеров версий одним общим.

jo — конструктор json для командной строки.

Часто вижу, как коллеги в чатах перекидываются фрагментами запросов или примерами вызовов API, передавая json в виде экранированных строк.