​Начинаем через 15 минут

Как и обещал, в прямом эфире будем докеризировать Django-приложение, разбирая каждый шаг — https://youtu.be/t8gZD0lwu2k

Продолжаю рассказывать об аккуратном коде в «советах» — в прошлый четверг вышел совет о заменяемости. Кто знает — это L из SOLID, кто не знает — читайте и разбирайте примеры.

Чек-лист: на что смотреть, когда затягиваешь новую библиотеку

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

Кроме очевидного способа минимизировать проблемы от зависимостей (поменьше их притаскивать, кек), есть ещё простая гигиена, которая помогает упростить жизнь. Прежде чем набрать npm install или что там у вас, найдите репозиторий зависимости в Гитхабе и проверьте его:
— Не смотрите на количество лайков.
— Есть ли тесты? Понятно ли написаны?
— Посмотрите 5 минут на код. Удаётся ли понять, как он работает?
— Были ли значимые (не «version bump») коммиты в последние полгода?
— Подходит ли лицензия вашему проекту?
— Не смотрите на количество лайков.
— Растёт или падает количество скачиваний (можно найти в npm/pypi).
— Сколько висит неотвеченных пулл-реквестов?
— Какие issues обсуждают?
— Понятно ли написано ридми, много ли документации?

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

Есть что добавить в чек-лист? Напишите на fedor@borshev.com

Органы чувств

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

Думаю, в такой ситуации был каждый опытный бэкендер. Я — точно несколько раз.

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

Подойдёт что угодно — datadog, newrelic, можете даже Графану с Прометеусом поставить: главное, чтобы у вас были глаза и уши.

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

Вот, что интересного было в последнее время:
— Стоит ли уходить из агентства в продуктовую разработку?
— Что делать, если разработчик начал фейлить из-за карантина
— Как найти удалённую работу на полставки
— ООП или ФП?
— Как оценить успешность или неуспешность фичи после релиза
— Почему ты работаешь стоя?

Чтобы получить публичный ответ на свой насущный вопрос, нужно написать мне на fedor@borshev.com, конфиденциальность гарантирую.

Говори только с тем, кто принимает решения

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

Типичная история — в понедельник к вам приходит менеджер, вы договариваетесь о планах на неделю, а в среду прибегает он же: «Слушай, я тут поговорил с руководством, давай всё менять». Это самый плохой вид менеджера — медиатор, он же «передаст»: человек, чья роль — доносить мнение людей, которые принимают решения, до голов тех, кто эти решения выполняет.

Договорённости, заключённые с такими людьми, скорее всего, не сработают — они же не управляют ситуацией: вроде вы и договорились, а потом приходит настоящий ЛПР и делает всё так, как считает нужным.

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

Письмо с зарплатой

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

Для нанимателя такое письмо — чек-лист, все ли важные вещи он проговорил на берегу. Для сотрудника — справочник и страховка: с зафиксированными договорённостями работается гораздо спокойнее.

Ловите шаблон:

- Ты выходишь к нам на испытательный срок с зарплатой ХХ рублей.
- Испытательный срок продлится до 2 месяцев.
- По окончании испытательного срока твоя зарплата составит YY рублей.
- Критерии окончания испытательного срока — такие-то. Или: критерии окончания испытательного срока мы с тобой обсудим ХХ июня.
- Деньги переводим тебе на ИП / ГПХ / в пенсионный фонд / что там у вас.
- 25 числа каждого полного месяца получаешь аванс, 8 — расчёт за прошлый месяц.

#вопрос как прокачивать скиллы, будучи интровертом?

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

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

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

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

Я пока не до конца понимаю те механизмы, которые стоят за этой магией, но подозреваю, что именно они описаны в «Шкуре на кону» Талеба — нужные скиллы просто сами появляются.

100500 плохих сигналов

Почти все больные системы мониторинга, которые я видел, объединяет одна черта — они шлют бесполезные алёрты.

Какая разница, что места на сервере осталось 20 гигов или что выросло количество соединений в состоянии TIME_WAIT? Человек, которого PagerDuty отрывает от пикника с друзьями, хочет знать ответ на простой вопрос — надо ли прямо сейчас всё бросать и чинить проблему? Метрики с железок на такой вопрос никогда не ответят.

Чтобы ответить, нужно смотреть на бизнесовые метрики. Они у каждого свои, но в роли базовых стоит использовать 4 золотых сигнала, о которых я недавно писал: время ответа, запас по CPU, количество запросов и количество ошибок. Если все 4 параметра в норме, то в бизнесе, скорее всего, всё ок. И наоборот, если какой-то параметр выбивается — нужно лечить.

P.S. Мой вебинар об автоматизации уже в эту субботу! Там будет целая секция про мониторинг и devops, приходите.

Что делать, если меня отстраняют от дел?

В бюрошных советах вышел мой ответ на очень интересный вопрос — что делать техдиру, если пришёл новый генеральный и потихоньку выкидывает его из команды?

Почитайте тут — https://bureau.ru/soviet/20200521/.

Полезно получилось ответить?

Если пора спать — значит, пора спать

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

Сколько бы мы ни посмотрели фильмов про хакеров и как бы романтично ни выглядела работа за двумя мониторами под покровом ночи, гигиену труда никто не отменял. Любому человеку нужно регулярно спать. Кому-то — 6, кому-то — 8 или даже 10 часов. Почитайте «Здоровый сон», если не верите.

Если разработчик нарушает это правило — значит, он у кого-то крадёт время. Либо у себя и своих близких (к примеру, сидит как овощ на семейных завтраках или вообще на них не ходит), либо у меня — тем, что за час пишет столько кода, сколько в рабочем состоянии написал бы за 10 минут.

Если пора спать — ложитесь спать.

Проверить через два дня

Многим программистам (и менеджерам) не хватает простого навыка — проверить через два дня.

— Сделал кнопку — проверь через два дня, нажимают ли ее вообще? Что видят, когда нажали?
— Сделал интеграцию — проверь через два дня, сколько пришло данных? Пришли ли вообще?
— Сделал новое уведомление — проверь логи. Что уходит пользователям? А много вообще ушло?

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

Кто должен проверять через два дня, если задачу делали впятером? Конечно ты.

Смеяться в коде

Обожаю смеяться в коде. Самый распространённый товар в тестах ГдеМатериала у нас назывался «Камаз Отходов». Иногда он трансформировался в «Камаз Овец» или «Камаз Гвоздей». Большинство прорабов звали «Львовичами» («Петрович» не хотелось по понятным причинам).

Чтобы аккаунты программистов в системе отличались от аккаунтов обычных пользователей, каждый придумал себе псевдоним, который начинался на «Отец О»: Отец Олексей, Отец Олег, Отец Онотолий.

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

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

Научи ловить рыбу

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

Неопытные программисты в ответ на просьбу по-быстрому что-нибудь сделать обычно что-нибудь делают. Продвинутые даже выстраивают системы реагирования, типа «Сегодня Вася делает все задачи по-быстрому, а завтра — Федя».

Опытные же, наоборот, — не дают рыбу, а учат её ловить: они не сбрасывают пароль, а делают кнопку для сброса пароля; не меняют телефон, а делают поле в админке; не делают выгрузки, а ставят Metabase или PowerBI. В ГдеМатериале у меня вообще было правило, что разработчик никогда не участвует в операционке, что бы ни произошло: так мы тратим время разработчика не на решение задачи, а на фичу, которая нужна, чтобы подобные задачи больше никогда не приходили.

​Запись вебинара об автоматизации разработки

2 часа разговоров про построение рабочего места, мониторинг, хостинг, запуск проектов в одно лицо и (самое главное) про огородики и дизайн.

В честь первого дня продаж, цена — 1800 рублей.

Качество ведения проекта

Понять, насколько хорошо менеджер ведёт проект, легко после его завершения. Всё просто — если менеджер успел в срок с хорошим качеством и не угробил команду, значит, молодец. Не успел — не молодец. Но как быть, когда проект ещё не завершён, а измерять качество уже надо?

Мой любимый способ — посмотреть на прозрачность. Насколько извне проекта видно, как идут дела? Публичны ли еженедельные планы? Как часто проводятся демо?

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

Фабрика фич и просранное время

Когда в компании появляется быстрая разработка (а такое бывает, да), возникает большой соблазн превратить команду разработки в фабрику фич. Фабрика фич — это маленький заводик по клепанию фич без оглядки на реальность, когда никто не прогнозирует и не замеряет воздействие на бизнес. Такой подход быстро превращает продукт в болото из ненужного кода, в котором никто, включая разработчиков и QA, не знает, как должна работать та или иная фича.

Чтобы вылечить такие ситуации, я внедряю цикл Шухарта, когда вместо больших фич мы делаем маленькие гипотезы, замеряем их воздействие на бизнес, а потом уже делаем большие задачи, точно так же замеряя их денежный выхлоп. Типичная проблема с внедрением — когда бизнесовым ребятам пофиг на все эти продуктовые циклы: у них прямо сейчас фича горит, надо просто сделать и, вообще, нет времени объяснять.

Специально для таких ребят я придумал статус задачи «просранное время». Туда мы переводим все задачи, которые сделали в обход полноценного цикла проверки гипотез и которые при этом не оказали никакого воздействия на деньги. Такая «доска позора» где-нибудь в Трелло здорово мотивирует думать головой вместо того, чтобы давить на продуктовую команду.

Очень важно — в «просранное время» ни в коем случае нельзя переводить гипотезы, которые прошли по продуктовому циклу, но не выстрелили — если вы сели, придумали, как быстро проверить гипотезу, проверили и она не выстрелила, вы молодцы, и никакого времени мы не просрали.

#вопрос
Почему в твоей письменной/печатной речи так много грубых слов типа «говно» и так далее?

Если программисты себя считают элитой, то почему их общение (не только твоё) скатилось до смеси сленга с быдлятиной?

И второй, про сленг. Тебе правда нравится изобилие сленга и слов типа «фейлить», «факапить» и прочих в твоих текстах?

————
#ответ

Сленг складывается помимо нашей воли. Идти против сленга — глупо. Представьте себе дальнобойщика, который по рации скажет «Вижу засаду ГИБДД» вместо «машинка работает», или кладовщика, который назовёт рохлю «вилочным погрузчиком» — поймёте, о чём я.

Любая речь легко воспринимается только в случае, если соответствует контексту подачи. В электронной почте никто не ожидает стикеров с зелёной лягушкой или сообщений из одного слова «привет» — так же, как в Телеграме никто не ожидает красиво оттипографленных лонгридов. Я хочу, чтобы мои сообщения читались легко, поэтому и стараюсь, чтобы тексты не выходили за рамки привычного сообщения в чат — как по объёму, так и по форматированию и матюкам.

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

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

Лайв-девопс: поднимаем кластер на docker swarm для W1D1

На прошлом стриме о докере вы просили рассказать, как запускать контейнеры не только на своей машине, но и в продакшене.

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

Сейчас бэкенд у W1D1 состоит из кучки микросервисов на ноде, которые поднимаются руками. Пора наводить порядок — проверить приложения по чек-листу 12 факторов, настроить централизованное логирование, описать инфраструктуру.

Ребята любезно разрешили мне сделать это публично, так что приходите на ютуб в 14:00 воскресенья — будем поднимать маленький кластер на docker swarm при помощи моего любимого Ansible. Как обычно, всё будет в лайве и без репетиций, так что никто не знает, получится ли у меня вообще что-нибудь.

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

Полезно получилось?