​Вопрос: какой софт используешь для Pomodoro? Синхронизируешь ли с календарём и другими приложениями?

Я использую Tomato One.

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

Есть вопрос? Напишите мне на fedor@borshev.com

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

В первом совете из цикла рассказал о зацеплении — показателе того, насколько один класс зависит от другого.

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

​Запись вебинара об удалённой работе

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

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

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

free-for.dev

Давно хотел вам посоветовать крутейший источник знаний об окружающем мире — free-for.dev. Это каталог сервисов, которые предоставляют бесплатные тарифы для программистов. Ценность этого каталога — не в халяве (хотя наверное это кому-то тоже важно), а в его таксономии. Просто читаете, какие сервисы существуют, и узнаёте много нового о современном контексте разработки.

К примеру именно из free-for.dev я когда-то давно узнал, что в мире существуют такой класс сервисов, как APM, или что можно просто скормить все логи в papertrail, а не поднимать свой ELK-стек.

Каждый раз, когда собираетесь притащить что-нибудь новое в свою инфраструктуру — посмотрите на free-for.dev, наверняка это уже есть в виде облачного сервиса за $10 в месяц.

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

Мы с Саматом ищем рубистов в iGooods. Вы придёте в самую сложную и интересную фазу проекта — мы забрали код от аутсорсеров, и теперь приводим его в порядок: покрываем тестами API, разбиваем лишние связи, строим нормальный CI/CD. Из последних достижений — выдернули user-facing фронтенд из монолита и запустили SPA на React/TSX, унесли тестовые стенды на DigitalOcean, внедрили Rails::Engine и прямо сейчас внедряем паттерн Repository, чтобы избавиться от толстых моделей.

Проект — автоматизация службы доставки из магазинов: задания для сборщиков товаров и курьеров, управление персоналом (сколько и куда выводить людей), интеграции с разными сервисами, начиная от разбора списка товаров от сотен офлайн-магазинов и заканчивая собственной системой аналитики на ClickHouse. По технологиям — Rails 4 (скоро поправим), DRY-стек, тесты пишем на RSpec. Код и CI на Гитлабе, задачи в Джире. Лежит всё на железках в Селектеле, но мы активно виртуализуемся и контейнеризуемся.

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

Работа из офиса на Технологическом институте, один день в неделю — дома. Зарплата — от 150k для мидлов и 250к+ для синьоров. Если вы — джуниор и покажете проект с тестами на гитхабе, возьмём вас на 80k и прокачаем до мидла.

За рекомендацию мидла, который пройдёт испытательный срок, бонус 80 000 рублей.

Вопросы и отклики пишите руководителю бекенда Жене Зубаирову @MindCufk.

Вопрос: почему ты работаешь стоя? Весь день вообще не садишься?

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

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

Другие вопросы — #вопрос. Задать свой — fedor@borshev.com

Срочно в номер: завтра ваш сертификат letsencrypt может превратится в тыкву

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

Баг выглядит как не очень страшный, но есть большая проблема — letsnecrypt отзывает часть сертификатов, которые мог затронуть этот баг, причём отзывает их срочно, прямо завтра.

Это ощутимо задело ГдеМатериал — половину сертификатов пришлось перевыписывать.

Почитайте почту и проверьте свои сервисы вот тут.

​От 0 до 150 000 строк кода не жертувя качеством

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

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

Несмотря на все проблемы, получилось круто, так что смотрите, но не смейтесь :-)

Второй совет про аккуратный код: связность

Вышел второй совет об аккуратном коде, где я простым языком рассказываю о принципе единой ответственности (S из SOLID).

Опять прошу от вас обратной связи — понятно ли это для людей, которые не сильно разбираются в программировании?

#вопрос: объектно-ориентированный стиль или функциональный?

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

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

Уверен, что я такой не один, поэтому жёстко приходить в команду с тем, что «мы теперь пишем только ООП» я бы не стал. Если бы я, как CTO, был уверен, что у нас вся команда хочет писать в функциональном стиле, функциональный стиль подходит ко всем нашим core-библиотекам, и мы сможем нанимать неограниченное количество новых людей, которые будут это поддерживать — я бы, наверное, согласился.

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

Коридорное тестирование

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

Есть ребята, которые под коридорным тестированием понимают «взять макеты и побегать с ними по коридору». То есть не тестируют прототипы, а просто показывают макеты разным людям и спрашивают «что думаешь?».

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

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

См. также «Одна задача — один ответственный»

Небольшое реалити-шоу про меня

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

Последний, 15-й эпизод в этом сезоне. Уходим на месяц каникул и вернемся со вторым сезоном, ещё интереснее первого. Спасибо замечательной команде — Андрею Борзенко, Юле Яковлевой, Павлу Цурикову, Павлу Боровкову и Полине Агарковой. Вы лучшие!

Спасибо вам большое, что слушаете! Пожалуйста, пишите в личку, что вы думаете о подкасте — даже (особенно) если вы не довольны и хотите что-то поменять.

Три абзаца

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

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

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

В общем, если ты написал длинное письмо — стирай его нафиг и назначай встречу.

См. также Длинные ТЗ не работают

#тупое_правило

Больше не работаю в ГдеМатериале

ГдеМатериал — классный проект, который работает на очень интересном рынке. Привести в порядок рынок стройки так же, как Яндекс привёл в порядок рынок такси — это сверхзадача.

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

Ну а у меня впереди то же самое, что я сделал в ГдеМатериале, только умноженное на 10. Если вы хотите, чтобы мы с Саматом сделали в вашем бизнесе продуктовую разработку, которая внимательно слушает бизнес и не проёбывает дедлайны — пишите.

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

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

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

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

Если второе — прямо сейчас перестаньте читать новости и займитесь делом.

​​Тесты снимают когнитивную нагрузку

Чтобы соответствовать бизнес-требованиям, нужно постоянно с ними сверяться (написал и почувствовал себя инфобизнесменом — покупайте мои курсы, кек).

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

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

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

А не чтобы убедиться, что не сломали все нафиг.

Сейчас очень горячие времена для всех служб доставки — люди сидят дома и делают в 2–5 раз больше заказов, чем обычно. Растёт нагрузка и на ИТ — всех этих юзеров нужно обслуживать: показывать сайты/каталоги/лендинги, принимать заказы, управлять курьерами. Уверен, пуканы горят не только у нас в iGooods — закрывались Окей и Утконос, вводят ограничения другие службы доставки.

Сегодня мы переменным успехом пролежали почти полдня. Сейчас заскейлились с пятикратным запасом, выдохнули и пишем пост-мортемы. Причины падений кажутся очевидными (надеюсь из-за послезнания), но я всё равно поделюсь парой советов, что делать, чтобы не быть как мы.
— Научитесь понимать, что происходит. Мастхев — APM, дешборды с нагрузкой по каждому серверу, количеством тасков в очередях и внутренними метриками приложения. Идеально подходит Датадог. Дешборды не должны быть «номинальными», в них нужно смотреть.
— Собирайте артефакты. Пусть логи буду доступны всегда в одном месте (лучше — в том же датадоге). Настройте контроль ошибок с помощью Sentry или Bugsnag, и приучитесь туда ходить.
— Сделайте приложение 12-факторным. Если приложение не может запуститься одной командой на вашей домашней тачке — вы не заскейлитесь.
— Проверьте, насколько ваша инфраструктура способна к горизонтальному масштабированию. Проведите лёгкий мысленный эксперимент — возьмите каждый сервер, который у вас есть и представьте, что рядом стоит второй такой же. Сможете его нагрузить?
— Заведите «план побега» на случай выросшей нагрузки. Пусть вся команда знает, какие сервисы нужно сохранять в любом случае, а какими можно на время пожертвовать. Мы в iGooods к примеру сразу сфокусировались на внутренних интерфейсах, чтобы сначала отвезти уже сделанные заказы, а потом принимать новые.

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

Живые советы в следующую среду

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

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