Аргумент как продавать мониторинг

Недавно убеждал одну команду установить себе нормальный APM. Основной аргумент против был «у нас есть <отечественный сервис-пинговалка>, если что-то случится, он нам сообщит».

Нормальный мониторинг по сравнению с пинговалками (не важно, отечественными или нет) — это как превентивный медосмотр против сообщения «поздравляем, вы умерли».

Мониторинг показывает проблемы в приложении задолго до того, как они выстреливают: если у вас 20% пользователей получают 500 ошибку, то с пинговалкой вы об этом не узнаете, пока она не попадёт в эти 20%. Если у вас потихоньку растёт latency у базы, вы не узнаете об этом, пока пинговалка, вместе с нормальными пользователями, не начнёт отваливаться по таймауту. Datadog, к примеру, позволяет даже не настраивать никакие триггеры — просто запускаете в нём watchdog, и он сам напишет, если что-то не так.

В общем сбор данных — это про проактивность, а алёрты «сайт упал» — про реактивность. Если у вас на работе всё ещё настроены пинговалки вместо нормального мониторинга — обязательно поговорите с CTO об этом.

В этот четверг проводим с Антоном Давыдовым стрим про будущий курс «Анализ Систем».

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

Если сомневаетесь, стоит ли покупать курс — приходите 4 мая в 19:00. Ссылку на трансляцию выложим сюда. Записи не будет.

Достоин ли я асинхронной коммуникации?

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

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

Попробуйте честно ответить для себя — а достойны ли вы асинхроннной работы? Не нужно ли вас пинать, чтобы вы делали задачи вовремя? Когда вы говорите «сделал» это означает «создал пул-ревест» или «код работает на проде и влияет на метрики»? Достаточно ли ваших знаний находятся в общем пространстве, или коллегам без вас ничего не понятно?

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

#вопрос Почему ты делаешь из vim IDE, хотя есть готовые IDE, в которые можно вставить vim?

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

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

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

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

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

Это был традиционный ответ на вопрос по понедельникам. Задать свой — fborshev@pm.me

Анализ систем: стартуем в пятницу!

12 мая, в эту пятницу, мы стартуем новый курс с Антоном Давыдовым — Анализ Систем.

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

На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникации, работать со стейкхолдерами и писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков. Отдельная гордость Антона — несколько сотен ссылок на дополнительные материалы, если захотите углубиться в какую-то из тем. Хватит на год вперед.

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

Стартуем в пятницу, есть ещё одно VIP-место с личной обратной связью и консультацией.

Смотреть программу →

Марьяна завела себе прикольную традицию — одной строкой рассказывать, как у неё в проектах идут дела, что нового\интересного случилось. Давайте попробуем это здесь?

— С Саматом доросли до двух ключевых клиентов и 20 человек в компании. За год мы выросли в два раза и не упали в качестве. Хоть и прощаемся сейчас с одним из клиентов — будем расти дальше.
— Запустили обучение на выстраданном курс «Анализ Систем». Материалами я доволен, хотя и недоволен количеством усилий, которое мы на них потратили: за год над текстами поработало 6 (!) человек, для нас это очень много.
— LMS: новая LMS в школе работает офигенно — у студентов нет вопросов, материалы рендерятся приятно глазам. Конечно огрехи есть, но они понятные, и их список — конечен.
— Недавно мы со своим хождением в приватное API ноушена стали попадать под капчу клаудфлера. Справились быстро, немного посомневались в идее юзать ноушен как бекенд для LMS, но решили что всё делаем правильно. Сейчас планируем ещё ряд продуктовых доработок.
— Сделал бухгалтерское открытие — оказывается в нашей стране электронный документооборот работает не только для юрлиц. Внедряем Контур.КЭДО, чтобы без бумаг обмениваться документами с сотрудниками. Горжусь что спрятал от команды ещё один бюрократический препон.

Тимлидская папка

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

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

#вопрос часто используем в работе headless cms для небольших проектов. Как относишься к такого рода продуктам?

Отношусь хорошо — мы и сами собрали несколько медиа-проектов на sanity. Риски у headless cms такие же, как и у любых других вендорских проектов:

— Точки интеграции: понятное ли API? Гибкое ли? Легко ли на нём выполнять требования бизнеса? Идеально при принятии решения накидать прототип, который показывает вашу таксономию, фильтры и подборки (читают так же/ похожие/что там у вас).
— Владение данными: понятно ли как доставать данные из вендора? Достаточно их, чтобы мигрировать к конкуренту?
— Quality of life: кайфовые ли технологии? Легко ди тестировать? не требует ли какого-нибудь экзотического дерьма для разработки? Может у вас все линуксоиды, а тестовый сервер поднимается только под виндой
— Сапорт. Хотят ли люди на той стороне решать ваши проблемы?
— Юрисдикция. Какие шансы, что вас заканселят?


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

Это был традиционный вопрос по понедельникам. Задать свой — fborshev@pm.me

Поменял мнение: Нужен ли докер в продакшене? Да

Прошло уже несколько лет, и пора признать, что я поменял мнение. Раньше я был уверен, что если вы задаёте себе вопрос «нужен ли докер в продакшене?», то докер вам брать не стоит. Сейчас я уверен, что стоит: любое приложение нужно паковать в докер таким образом, чтобы его можно было запустить там же в проде.

Я не вижу каких-то глобальных изменений в окружающих технологиях: k8s так и остался переусложнённым продуктом от программистов для программистов (и FAANG-ов). Dokku, Rancher или CapRover так и не определились, кто из них главный, и каждый продолжает развиваться в своём направлении. Наверное самое главное, что изменилось — появился MRSK, но в продакшен я его тащить пока не готов.

Возможно поменялся я — было довольно обидно в марте 2022 экстренно съезжать с хероку. Может быть и не из-за этого, а потому, что за прошедший год я развернул несколько продакшенов на нашей заготовке swarm+ansible и процесс мне показался не таким уж и сложным.

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

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

Довольно странные чувства я испытал, когда в прошлом году доступ к курсу «Вы приняты» попросил один из наших ведущих фронтендеров (привет, Миша!). Ну что я могу сказать — курс работает так же, как и остальные: Миша переехал в Германию и теперь работает в Джетбрейнсе.

В списке ожидания накопилось много запросов, так что мы запускаем третий поток. Если вы программист и ищете (или думаете искать) работу за рубежом — приходите, стартуем 16 июня. Главный эксперт курса — Дима Рожков, живет в Германии с 2014 года и сам прошел весь путь поиска работы за рубежом. Нанимает со всего мира, консультирует по переезду и собеседованиям.

Курс длится три недели. Первая посвящена поиску компании и оценке офера, вторая — линкедину, сопроводительным письмам и резюме, а третья — подготовке к собеседованиям. Для тех, кто купит курс до понедельника действует скидка 10% по промокоду AGRIMOTOR.

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

Данные нужны только фронту?

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

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

Если данные существуют — значит они нужны бизнесу. Вот представьте: вы делаете классифайд, у которого все параметры объявлений, кроме таксономии, хранятся в Elasticsearch. Для фронта хватает — поиск работает, дерево категорий строится, отдаётся все быстро, рендерится красиво. И тут вам прилетает задача — сделать выгрузку самых качественных объявлений в формате XML для какого-нибудь маркетплейса. Качественные объявления — это у которых чётко изображён предмет на фотке, у которых нет мата в описании, указан бренд, и ещё куча всего. Представьте, как весело будет перелопачивать все эти данные в момент выгрузки? Особенно, учитывая что Bosch можно обозвать Bosh, Boshc, Бош или Бошь?

Или вам нужно начать стримить объявления в микросервис на расте, который по супер-алгоритмам проверяет их на уникальность. Или перегружать их в BigQuery для аналитиков. Или пессимизировать в выдаче объявления со слишком длинным или слишком коротким содержимым?

Может для программистов NoSQL и выглядит красиво, но в реальной жизни всё для чего он годится — это специфичные read-модели в CQRS.

Управленческий долг

Развивал мысль про асинхронную коммуникацию, и задумался, что настраиваю бизнес по тем же алгоритмам, по которым раньше писал код — поддерживаю высокий cohesion внутри команд/отделов и низкий coupling между ними; стараюсь сделать происходящее понятным всем участникам без комментариев; ввожу метрики, которые показывают здоровье компании (в аутсорсе это в первую очередь runway). И конечно везде слежу за количеством управленческого долга.

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

Кажется мне здорово повезло с этой программистской привычкой к порядку: каждый раз ужасаюсь, когда встречаю управленцев, которые постоянно сидят на связи и разруливают ВНЕЗАПНО выстреливший управленческий долг

Readme driven development

У разработчиков библиотек есть классный способ проектировать API — Readme driven development. Смысл в том, что стартовать нужно не с кода, а с документации, которую пользователи увидят на гитхабе — написать текст, из которого будет ясно для чего нужна библиотека, привести самые яркие примеры задач, которые она решает, написать про ограничения.

Такой подход работает примерно как TDD — заставляет программиста думать не о реализации, а об окружающем мире, в котором эта реализация будет жить.

Readme driven development помогает, даже если вы скромно шлёпаете формы или лабаете CRUD-ы. Начиная сложную задачу — представьте, что вы её уже закончили и пишете коллегам, как пользоваться результатом вашей работы. Расскажите, где найти вашу новую форму и что туда вбить, чтобы увидеть самые интересные варианты поведения. Опишите, какие ошибки ваш CRUD выдаёт в каком случае, как можно в нём авторизоваться, чтобы проверить разные уровни доступа и т.д. В общем всё, что посчитаете важным для коллег.

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

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

Если сомневаетесь стоит ли вообще искать работу за рубежом — посмотрите первый урок: засомневаетесь ещё больше (правда).

Если не сомневаетесь, но не уверены стоит ли покупать курс — приходите сегодня в 18:00 MSK на стрим: с Димой ответим на вопросы о курсе и, если успеем, — о поиске работы. Ссылку скину сюда ближе к делу. Записи не будет.

https://www.youtube.com/watch?v=yIJU-B3kp90

Кто не может задать вопросы в ютубе — пишите в комменты, я буду смотреть

Преждевременное старение

В айтишечке (думаю и везде) есть понятие дедов — это чуваки, которые знают и умеют ТАК МНОГО, что имеют право с высоты взирать на происходящее, будь то новый статически типизированный язык, очки виртуальной реальности или новый способ разработки мобильных приложений. Деды знают, что технологии развиваются по спирали и ни за что не сядут ни на один хайптрейн (разве что за 2х).

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

Самый главный грех деда — отсутствие любопытства. Первые деды, которых я встретил в карьере, не признавали веб-фреймворки и считали, что это никчёмная обёртка над веб-скриптами с роутером. Потом были деды, которые не видели смысла в react.js (всё ж можно самому написать), в блокчейне, в SaaS. Где-то по дороге потерялись деды, которые не верили в сенсорные интерфейсы.

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

Лично я хочу оставаться любопытным как можно дольше. В жизни это получается довольно легко — всё-таки предпринимательство заставляет постоянно учиться новому. А вот в технологиях получается хреново: непонятно как отличать здоровый скепсис от преждевременного старения. Правда ли нет смысла переходить на новую macos, или это я старпёрю? Правда ли async в питоне не нужен? Правда ли кубернетис — раздутое говно? Может зря я не ношу Apple Watch?

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

А вы беспокоитесь о преждевременном старении? Как предотвращаете?

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

Лет через 5 я дошёл до этого принципа сам, а ещё через 3 года смог даже что-то реализовать. Объяснить этот принцип нормально нормально не могу до сих пор, но недавно нашёл эмоциональный пример.

Наткнулся на историю чувака, который купил себе древнюю БМВ, чтобы ездить по работе. За время владения вложил в неё 2.4 миллиона рублей и неподдающееся учёту количество времени. Работа у чувака, насколько я понял, — не хитрая: развозить запчасти для этих самых БМВ.

Так вот — что было бы, если бы чувак купил себе вместо БМВ жигули-четвёрку, взял оставшиеся от покупки деньги, добавил бы те же 2.5 миллиона, и за пару лет открыл бы собственный такой же бизнес по доставке запчастей? Сейчас бы ездил на такой же БМВ, только новой. А свободное время тратил бы на развитие бизнеса, семью, или на оживление какой-нибудь ещё более древней БМВ в качестве хобби.

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

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

Летний набор на Асинхронную Архитектуру

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

Сейчас мы объявляем летний набор на «Асинхронную архитектуру». Это — самый долгоживующий наш курс: запускаем набор уже в пятый раз. Обучение стартует 28 июля — будет легче взять отпуск для обучения. Курс полезен всем, кто имеет дело с продакшен-проектами, в которых больше одного репозитория. Даже если вы джун, который пилит монолит в маленьком стартапе, курс вам поможет: мышление проектировщика позволяет писать более понятный и изолированный код.

Обратите внимание — теперь у нас два курса о проектировании систем. Курс, на который мы открыли набор, посвящён проектированию распределённых систем, а недавно запущенный «Анализ систем» — более общий: он про стратегически анализ бизнеса и работу с требованиями. Говоря грубо — на «Асинхронной архитектуре» мы строим систему на event-driven архитетктуре, а на «Анализе систем» — учимся выбирать между 7 разными архитектурными стилями. Если не знаете с чего начать или хотите просто познакомиться с распределёнными системами — идите на «Архитектуру». Если ищете фундаментальных знаний по проектированию ПО — записывайтесь в список ожидания следующего потока «Анализа», надеемся он будет в этом году.

Обучение стартует 28 июля. До 1 июля действует цена для ранних пташек. Потоков в этому году больше не будет.

Смотреть программу и отызывы →

The fast way vs the hard way

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

В вайтишной тематике первая крайность представлена книгами из серии Learning X: the Hard Way. Книги запрещают даже копипастить примеры, мотивируя это тем, что пока не научишься набирать текст без ошибок — не научишься кодить (кек, как им наверное стало грустно после появления GPT-powered кодинг-ассистентов). Вторая крайность — условный скиллбокс, который обещает из кого угодно сделать питониста за 3 месяца.

Раньше я безусловно топил за hard way — типа нафига учить питон, если не понимаешь как устроен компилятор и зачем нужен ассебмлер? Как в школе — не будут же дети писать сочинение, пока не пройдут алфавит, не научатся писать чёрточки, затем буквы, затем слова и предложения.

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

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

Сейчас я по прежнему считаю, что учиться надо через hard way, используя быстрые результаты так, чтобы взрослый не сбежал. Даёшь ученикам неделю теории — дай возможность за пару часов на ней что-нибудь собрать. Полтора часа играешь гаммы на гитаре— потрать 10 минут и сыграй что-нибудь кайфовое для себя.

Привычные страдания

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

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

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

Вокруг нас горы таких страданий, ставших привычными — работать на нелюбимой работе; писать код на ноутбуке марки Асер; сидеть в слаке и корячить себе на десктоп «Стахановца»; юзать электрон вместо нормального ПО; <вставьте своё>.

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