​Выбросьте свой гитлаб

Осторожно — дальше ничем не обоснованное личное мнение

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

Наверное такие команды выбрали гитлаб потому, что сделали табличку, в которой сравнили его с гитхабом по количеству фич, и увидели, что у гитлаба их больше и они бесплатнее. К сожалению, такие таблички не показывают, что большинство фич гитлаба недоделаны и не дотягивают до конкурентов:
— CI поощряет писать шелл-скрипты, как в двухтысячных. Хотите собирать в докере — пилите свой образ с бойлерплейтом вроде apt-get --no-install-recommends install git
— Бесплатный облачный CI не работает — ваш проект просто висит в очереди и не билдится.
— Реестр контейнеров глючит, разрывает соединение и вообще не работает.

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

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

Если вы цените время своих коллег — мигрируйте на гитхаб прямо сейчас, это бесплатно.

#вакансия #работамечты

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

На беке у нас REST и Django, на фронте пока нет ничего. По технологиям хотим vue.js, больше никаких ограничений нет.

Работа удалённая, команда отличная, заказчик американский, оплата в долларах.

Присылайте пару строк о себе и ссылку на гитхаб на [email protected]

PostgreSQL anonymizer

Нашёл классный экстеншн для постгреса — PostgreSQL anonymizer — он простым декларативным синтаксисом вырезает из базы всё, что связано с персольной информацией пользователей.

Им можно вырезать имена из ночных дампов или прямо из базы.

Если вы всё ещё не на auth0 и сами вынуждены работать с персональными данными — мастхев.

P.S. Осталось два дня до повышения цены на мой вебинар об автоматизации разработки. Приходите — поговорим ещё о десятке таких нужных инструментов и о том, как их внедрять

Вебинар об автоматизации разработки переносится на 30 мая

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

Новая дата — 30 мая, суббота, 14:00.

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

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

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

В таких вопросах придерживаюсь agile: считаю, что важнее не выстраивать чёткую оргуструктуру, а делать так, чтобы каждый человек был на своём месте.

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

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

​Учим докер

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

9 мая в 14:00, приходите на стрим

Уровень ЗП зависит от ответственности

В разных командах по разному определяют рост зарплаты — где-то есть грейды, где-то до сих пор входу выслуга лет, где-то просто прикидывают на глазок. У меня есть любимый способ определять уровень ЗП — по количеству ответственности. Я здесь не расскажу всех формул (да их и нет), а поделюсь общим принципом.

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

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

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

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

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

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

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

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

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

Есть что добавить в чек-лист? Напишите на [email protected]

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

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

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

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

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

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

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

Чтобы получить публичный ответ на свой насущный вопрос, нужно написать мне на [email protected], конфиденциальность гарантирую.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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