12 факторов: явные зависимости

Все зависимости вашего приложения должны быть варажены явно. И я говорю не только о списке зависимостей из package.json, Pipfile, Cargo.toml или что там у вас — нужны именно все зависимости.

Если вашему приложению, чтобы запуститься, нужна установленная русская локаль, древняя версия openssl или elasticsearch, слушающий на 9000 порту, и вы не нашли способ понятно выразить это в репозитории, вам будет очень грустно всякий раз, когда придётся сталкиваться с девопсом. Вы будете чертыхаться всякий раз, поднимая окружение для CI, разворачивая проект на локальной машине или добавляя новую тачку в парк серверов.

В README такие требования описывать глупо — никто не будет их там искать: люди обычно не читают документацию. А даже если и читают, то вряд ли вы найдёте в себе силы актуализировать там версии зависимостей. Описывать их имеет смысл на языках, которые позволят автоматически воспроизводить нужный вашему приложению контекст. В худшем случае это какая-нибудь виртуалка на Vagrant (надеюсь никогда больше его не увидеть), чуть получше — плейбуки Ansible. Норм — это Dockerfile и docker-compose.

Утренние ритуалы 3: кофе

За 3 года в Студии Лебедева я привык, что в моментальном доступе от моего рабочего места всегда есть вкусный капучино, флетвайт, харио или аэропресс. Когда я начал работать из дома, первым делом научился варить кофе. Увы, я не знаю ни одного способа приготовить дома эспрессо, хотя бы чуть-чуть сравнимый с тем, что подают в кофейнях, поэтому выбрал альтернативу.

Сейчас я пью по 3–5 чашек кофе в день. Завариваю в воронке V60, кемексе или аэропрессе в зависимости от настроения. Кофе я пью не для того, чтобы взбодриться — если хочется бодрости, я лучше пойду посплю. Кофе — это ритуал: способ выдохнуть, получить вкусовое наслаждение, помедитировать в процессе заварки.

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

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

А вы любите кофе? Какой пьёте?

​Тимлидам: отдельные дни для кода, отдельные — для управления

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

Получалось плохо: в первом случае я не мог смотреть в редактор и ненавидел всё человечество, а во втором проходило минут 30, пока я включался в контекст встречи и начинал инициировать, а не реагировать.

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

Так что совет начинающим тимлидам: если вы всё ещё пишете код, выделите для этого отдельный день, в который больше ни с кем не встречайтесь. Коллегам так и объясните, для чего этот день — обычно все понимают.

12 факторов: одна кодовая база — много деплоев

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

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

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

#вопрос Проект начинает надоедать из-за его длительности и неразнообразия в технологиях. На работе я получаю весьма важные навыки понимания бизнеса и того, как его правильно перевести в цифровую плоскость качественно и быстро. При этом мне очень не хватает роста в техническом плане — фреймворки, high-load / распределение трафика, безопасность сайта, оптимизация и т. д.

Стоит ли мне работать на многообещающий проект и при этом потерпеть ещё некоторое время с профессиональным ростом или же найти себе новую работу с новым проектом в IT-компании вместо бизнес-компании?

—————

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

А потом посмотрите, станете ли вы получать от этой работы больше, если пробудете там ещё год? Вырастет ли ваша зарплата? Научитесь ли вы делать новые вещи? Будут ли у вас задачи, которые можно положить в портфолио?

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

Задавайте свои вопросы на fedor@borshev.comfedor@borshev.com

​Сервисы: super.sosuper.so

Ноушен — офигенный, по крайней мере, пока не вырос Craft. На ноушене приятно делать веб-странички: от вакансий до целых лендосов. Не надо парится с хостингом, конструкторами сайтов и всем остальным — просто делаете страницу и даёте всем ссылку.

Если часто делаете простые страницы — посмотрите на super.so. За $12 в месяц он позволяет за пару кликов прикрутить домен к вашему ноушену.

Если хотите красивый домен к корпоративной базе знаний или собственное портфолио без админки — отличная идея.

Математика делегирования

Допустим, я могу своими руками запилить фичу за один день. Или могу отдать эту же фичу другому разработчику, который сделает ее за два дня и 20 000 ₽.

Теперь считаем: а стоит ли мой освободившийся день эти 20 000 ₽? Может, у меня есть в беклоге еще одна фича, которая принесет мне 60 000 ₽? Или я этот день побездельничаю и отдохну. Готов ли я заплатить 20 000 ₽ за право отдохнуть?

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

———————
Это отрывок из почтового курса «Самому не проще», где мы с Маряьной простым языком рассказываем о делегировании для тимлидов, программистов и менеджеров.

12 факторов: приложение — это не демон

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

Классический подход к разработке ПО подразумевает, что вы напишете один демон, который будет обрабатывать всё это у себя внутри. Неважно, будут ли это отдельные процессы или отдельные треды внутри королевского процесса, как в JVM, — главное, что будет одна точка входа типа /usr/bin/myapp.

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

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

Масштабируйтесь через увеличение количества воркеров.

Критикуя — улучшай

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

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

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

И ещё #вакансии

Ищу ребят в свои команды:
—Двоих питонистов на Django, работать над бекендом с DRF и Postgres, без легаси-кода, всё как на моих стримах.
— Двоих фронтендеров vue.js/nuxt.js. Работать либо над snob.ru, либо над личным кабинетом в upmarket.cc

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

ЗП обсудим в зависимости от вашей квалификации: от 100к для джунов и до 250к. Базовые требования — интересоваться хорошим кодом и уметь писать тесты. В идеале — понимать, что такое пирамида тестирования и уметь в py.test для питонистов или в jest+@vue/test-utils для фронтендеров. Всему остальному, если надо, научим.

Если заинтересовало — напишите пару строк о себе на fedor@borshev.com

no-code — это техдолг

No-code-решения бывают клёвыми: приятно же без программистов повесить на сайт форму подписки или настроить новое оповещение клиентам через плагин к AmoCRM. Однако, решая задачи быстро, бизнес часто забывает, что задачи имеют стоимость владения — мало просто запилить фичу, нужно ещё сделать, чтобы она не падала, а если упала — не сильно задевала бизнес. И тут no-code проигрывает по всем фронтам.

Вот повесили вы форму подписки на сайт, а через месяц смотрите — а вёрстка поехала: ошмётки формы вылезают на страницу корзины, пользователи путаются, конверсия падает. Если бы у вас был программист, который отвечает за сайт, он бы это быстро исправил — сам накосячил, сам и чини. А если вы это сделали на no-code — ещё придётся сначала понять, какая именно из очередных фич привела к такой проблеме. Или если ваша  система no-code уведомлений сошла с ума и начала спамить настоящих клиентов? Придётся бросать все дела и бросать самому.

Вообще, лёгкость прикручивания новых фич раздувает софт — в одной команде мы как-то отдали бизнесу полный контроль над Google Tag Manager, и через несколько месяцев скорость загрузки контента у нас упала до нескольких секунд — ребята просто ставили новые теги, забывая о старых. В результате Intercom конфликтовал с CarrotQuest, а три системы коллтрекинга подвешивали браузер.

Я не призываю совсем отказаться от no-code-решений, но помните: если решаете задачу на no-code, вы говнокодите, и этот долг придётся рано или поздно выплачивать.

Главное дело дня

Главное ежедневное дело менеджера и тимлида — делать обзор. Это когда садишься и полчаса приводишь в порядок список дел:

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

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

- Какой следующий шаг? Что можно сделать сегодня, чтобы продвинуть проект вперёд?
- Что может произойти сегодня? Как сделать, чтобы это случилось не внезапно?

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

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

Сегодня в 21:00 говорим с Ильёй Бирманом в Клабхаусе о том, как нанимать программистов в Эгею.

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

https://www.joinclubhouse.com/event/MzjLwk0p

Апдейт: попробуем говорить и в клабхаусе и в телеге. Если не получится — будем говорить только в телеге.

​Стать Тимлидом: II поток

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

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

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

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

Новый поток стартует 20 апреля и продлится до 23 мая. До понедельника включительно действует скидка 10% по промо-коду TL2START

Лайвкодинг в воскресенье: Личный кабинет на vue.js + django

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

Начнём с личного кабинета — места, куда каждый ученик сможет зайти и указать своё имя в том виде, в котором хочет увидеть его на дипломе. Сейчас кода ЛК нет совсем, так что это отличная возможность посмотреть, как начинаются проекты на vue.js (v2, т.к. v3 пока сыровата) и как можно подружить их с django.

Встречаемся на ютубе в это воскресенье, в 14:00 MSK.

P.S. Весь код нашей школы мы храним в опенсорсе — вот тут, к примеру, лежит бекенд, который обрабатывает покупку курсов: цены, промо-коды, интеграции с банками и мейлчимпом.

Можно жить и без привычек

После моих постов об утренних ритуалах (ссылки: 1, 2, 3) в комментах было много мнений о том, что я робот, живущий по ритуалам. Хочу это опровергнуть.

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

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

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

Начинаем через 15 минут — https://youtu.be/QkhozMsCCe0

Марьяна немного рассказала, что нового будет во втором потоке