Фёдор Борщёв

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

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

Как выучить любой язык программирования

Если вы только собираетесь войти в ИТ, и выбираете куда пойти учиться и какой курс купить, вот вам краткая инструкция:

  1. Покупаете хорошую книгу по выбранному языку программирования. «Хорошая» означает, что её кто-нибудь кому-нибудь советовал в группах/форумах больше 5 раз. К примеру по питону это Марк Лутц — «Изучаем питон».
  2. Изучаете её всю, от корки до корки, делая все домашние задания.
  3. Выбираете самый популярный фреймворк. «Самый популярный» означает «чаще всего упоминается на тематических сайтах». В питоне под веб это Django.
  4. Изучаете всю официальную документацию к фреймворку, от корки до корки. Проходите официальные обучалки. Гугите <framework> best practices, изучаете их.
  5. Делаете свой пет-проект. Блог, сайт, исследование аномалий в парковке под окном, что угодно — зависит от выбранного языка.
  6. Ищете команду с высокой инженерной культурой, которая возьмёт вас джуниором. Дальше учитесь у них.
  7. На сэкономленные на курсе деньги езжайте на недельку или две в Питер (если живёте в Питере — в Калининград).

И не благодарите.

Как переименовать приложение в Django

Как-то на бекенде для инфобизнеса меня перестало устраивать название приложения в Django. Всё просто — когда я начинал проект, я продавал только курсы, и приложение с моделями курсов называлось courses. Потом появились записи этих курсов (record) и наборы (bundles). Конечно мне захотелось переименовать приложение courses в products, чтобы уменьшить когнитивную нагрузку при чтении кода.

К сожалению, я не нашёл ни одного решения, кроме стрёмного django-rename-app, который предлагал мне выполнять management-команды в консольке на проде. Кроме того, что это ломает любые пайплайны CI\CD, там ещё и код был не очень понятный. Так что в итоге я решил сделать это сам. Оказалось сложно, поэтому я написал эту инструкцию.

Исходные условия:

  • CI\CD пайплайн, который запускает миграции при каждом деплое.
  • Данные терять нельзя.
  • Мы не стесняемся править старые миграции.

Все изменения я делал на живом проекте, так что примеры будем брать прямо из пулл-реквестов.

  • Подменяем имя приложения в истории миграций: ./manage.py makemigrations <some-other-app> -n RenameOldApp --empty. Коммит.
  • Деплоим миграцию на прод. После этого шага ничего нельзя деплоить до конца.
  • Делаем новый пулл-реквест.
  • Переименовываем папку с приложением: git mv courses products
  • Заменяем все упоминания старого приложения в миграциях. Коммит.
  • У всех моделей в новом приложения в Meta прописываем db_table с именем старого приложения. В моём случае, если модель называется bundle и лежала в приложении courses, нужно прописать db_table = 'courses_bundle'. Коммит.
  • В старых миграциях, которые используют операцию CreateTable, добавляем новую db_table в options. Коммит.
  • Меняем упоминания приложения в коде, можно автозаменой. Коммит.
  • Проверяем, ./manage.py makemigrations --check. Новых автоматических миграцией был не должно, ошибок тоже.
  • Деплоим на прод.

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

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

Вот упал у вас прод, вы заходите по 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-факторностью, кучей линтеров и ещё много чем.

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

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

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