Фёдор Борщёв

Заметки с тегом «Программирование»

Кроме управления разработкой, я ещё пишу код. Под тегом «программирование» я выкладываю заметки связанные с разработкой ПО — пишу про технологии, фреймворки, тесты, железки и всё такое.
Новее

Органы чувств в инфраструктуре

Вот упал у вас прод, вы заходите по ssh и видите, что Load Average в 10 раз больше, чем количество ядер. Люди не могут воспользоваться сервисом, партнёры задают вопросы, а всё, что вы знаете, — это то, что нагрузка выше номинальной. Где именно, из-за чего всё это случилось — непонятно.

Вы залезаете в консоль, ищете по логам (медленно, сервер-то перегружен), запускаете ps и strace, совершаете другие шаманские действия. Чувствуете, что двигаетесь по тёмному лесу с закрытыми глазами, как бегуны из старого клипа Pendulum.

Четыре золотых сигнала — время ответа, количество запросов, рейт ошибок и запас нагрузки

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

Чётко видна авария с 16:00 до 18:00

ТОП-10 запросов декомпозирует проблему из «упал прод» в «у нас тормозит эндпоинт деталей товара». Теперь легко локализовать источник — если увеличилось количество запросов, то ищем, того, кто их делает. Если запросов столько же, а нагрузка выросла — ищем, что поменялось в коде, или какие проблемы у нас могут быть на внешних ресурсах: базе данных, кеше или партнёрских API. Во втором случае здорово помогает разобрать поток выполнения — у каждого запроса, который обработал сервер, мы записываем трейс, в котором видно, сколько времени приложение потратило на каждую активность, а затем визуализируем это примерно вот так:

Flame graph показывает, что PostgreSQL отвечал чуть меньше, чем 30мс: отличный результат

Такая работа с цифрами и статистикой называется APM — App Performance Management. Мой любимый сервис для APM — Datadog. Я выбрал его когда-то за хороший дизайн: Datadog не просто даёт инструменты, которые собирают цифры, но и подсвечивает и объясняет самые важные из них.

Дефолтный борд Датадога для PostgreSQL

Если у вас есть хоть какой-то продакшн, который до сих пор не обложен цифрами — прикрутите к нему APM. Не хотите Датадог —  есть куча конкурентов: New Relic, AppDynamics, AppOptics, Elastic APM.

Почему я открыто делюсь исходным кодом (и +2 открытых проекта на Django)

Разработчики, которые приходят на мои проекты, часто удивляются, почему я с такой лёгкостью открываю свои наработки — добавляю в репозитории в гитхабе, даю доступ на сервера и передаю документацию. Ведь обычно все прячут исходный код за семью печатями — не делятся доступами, присылают странные zip-архивы без папки .git и т.д. Я где-то даже видел команду, которая обфусцировала код, прежде чем выложить на гитхаб.

Я так делаю потому, что у меня есть большая цель (только не смейтесь) — я хочу, чтобы как можно больше программистов радовались своей работе. Если программисты не просто делают свою работу, а радуются — они работают гораздо быстрее. Если бы все программисты в мире работали быстрее — многое поменялось бы для человечества в целом: быстрее бы появлялись и умирали новые стартапы, проверялось бы больше гипотез, а значит росло бы количество цифровых продуктов. Представляете, сколько та же яндекс-лавка сэкономила москвичам времени на походах в магазин? А если бы нас посадили на карантин в 2015 году, когда её не было? А ведь уже тогда были доступны все технологии, на которых она работает. Уверен, даже идеи были. Надо было только напрогать.

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

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

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

На прошлой неделе я открыл два важных проекта на Django:

education-backend: это активный коммерческий проект — бекенд, которым я пользуюсь чтобы брать деньги вебинары.

f213/django — мой стартер проектов на django с батарейками: pytest, 12-факторностью, кучей линтеров и ещё много чем.

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

Я надеюсь, что мои исходники послужат кому-то примером того, что можно писать коммерческий код для удовольствия.

Если вам нравится, что я делаю, меня легко отблагодарить — посоветуйте друзьям мой блог, поставьте звёзду на гитхабе или поддержите мою деятельность на патреоне.

Какие технологии выбрать для нового проекта? (версия для программистов)

Это — заметка для программистов. Если вы менеджер — почитайте версию для менеджеров.

Многие ребята, выбирая инструменты для нового проекта, начинают строить длинные таблицы, сравнивая фичи. Серьёзно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.

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

Какие технологии выбрать для нового проекта?

А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта сейчас. Подумайте лучше о том, каким будет ваш фреймворк потом. Удержит ли он комьюнити в ближайшую пару лет? Успеет ли за быстроизменяющейся средой? Будет ли адекватным предложение на рынке труда?

Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends. И да, если вы выбираете фреймворк для фронтенда, то берите любой — всё равно протухнет через год.

Мой сетап

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

Я использую MacBook Pro 14" 2022 года. Когда я работаю дома, ноутбук подключён к монитору LG UltraFine 4K прошлого поколения — кажется это единственный монитор с честной ретиной и нативным для мака DPI. Поколение монитора важно — подробнее см. обзор на «Вёрдже».

Я не использую два дисплея, поэтому ноутбук работает Clamshell mode. Единственное исключение — стримы: для них я открываю на ноутбуке Open Broadcaster Software.

Рабочий стол с двумя дисплеями (редкое состояние)
Мой рабочий стол

В качестве органов управления я использую Happy Hacking Keyboard и Magic Trackpad. Мои пальцы не могут изогнуться, чтобы воспользоваться странной клавишей, которую засовывают в русских раскладках между левым шифтом и z, поэтому я всегда покупаю американские клавиатуры, вот — клавиатура ноутбука:

Клавиатура ноутбука c «длинным шифтом». Видно отключенный тачбар
Клавиатура ноутбука c «длинным шифтом». Видно отключенный тачбар

Полный список железок:

  • MacBook Pro 14" 2022, Apple M1 Max, 64Gb RAM
  • Монитор LG UltraFine 4k на кронштейне Ergotron LX Desk Monitor Arm
  • Клавиатура Happy Hacking Keyboard Pro Hybrid Type-S
  • Внешний тачпад Magic Trackpad 2
  • Веб-камера Razer Kiyo Pro
  • Микрофон Shure SM7B со штангой Blue Compass
  • Микрофонный предусилитель Art Tube PAC
  • Звуковая карта Focusrite Clarett+ 2Pre
  • Наушники Sony MDR-7506

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

Большая стоимость обусловлена тем, что все высокие столы на рынке — регулируемые: у дешевых столешница поднимается вручную, у дорогих — с помощью электромоторов. Здраво рассудив, что регулировкой высоты я воспользуюсь ровно один раз — при установке стола — я просто пошёл на лайвмастер и заказал стол под свой рост. Получился красивый и надёжный предмет мебели (который до сих пор пахнет деревом!), по цене ниже икеи.

Софт

Я не люблю IDE, и в роли редактора кода использую neovim. Долгое время я сидел в Visual Studio Code, но конце 2021 года я устал бороться с увеличивающимся количеством скрепышей фич, плюнул и перешёл на neovim в терминале iTerm2:

Так выглядит экран во время разработки

Основные плагины:

  • coc для автодополнения, которое понимает язык (LSP)
  • fzf для быстрого открытия файлов
  • nerdcommenter, чтобы быстро комментировать куски кода
  • vim-vinegar, когда нужно походить по файловой системе

В качестве оболочки я использую прекрасный fish. Если хотите так же — посмотрите на мои файлы конфигурации на гитхабе.

Старее