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

40 минут говорили о будущем Django, про асинхронщину в питоне и о том, стоит ли учить ей джунов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода:

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

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

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

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

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