А давайте поговорим?

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

Ссылку на стрим опубликуем прямо здесь в пятницу.

Сервисы: cloudflare zero trust

Недавно открыл для себя гениальную вещь — cloudflare zero trust: замену рабочего VPN для 2023 года.

Обычно всякие внутренние админки прячут не только за логины\пароли, но и за фаерволы. В общем-то логично — если сольют пароль, фаервол — это ещё один рубеж безопаснсоти. Чтобы пройти через эти фаерволы, пользователи и программисты вынуждены ставить себе корпоративные VPN-клиенты вроде tunnelblick, все как один — кривые.

Zero Trust убирает необходимость в фаерволлах и VPN — вместо настроек IP-адресов и портов, мы начинаем думать на уровень выше: настраиваем доступы пользователей к приложениям. Подключиться к продовому постгресу, авторизовавшись через корпоративный гитхаб? Пожалуйста. Разрешить доступы в your-app/admin/ только для пользователей с почтой @your-app.com? Пара кликов мышки.

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

Если прямо сейчас проектируете новую корпоративную сеть — горячо рекомендую заменить VPN на Zero Trust, до 50 живых пользователей система работает бесплатно. Правда лендос у них состоит из какого-то корпоративного буллшита — чтобы понять, что эта штука умеет, нужно региться и ковырять интерфейс, но оно того стоит.

Начинаем! Го на ютуб — https://www.youtube.com/live/DNwt6GqPPRU?feature=share

Срочный контент

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

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

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

Я почти всю жизнь обходился без срочного контента — просто не интересовался новостями. Это не было осознанным шагом — мне просто было не интересно. Ковид в 2020 году и война в 2022 довольно сильно поменяли мой формат потребления — начиная с обзоров политологов я к концу 2022 года скатился в чтение коммерсанта и даже периодически заходил на медузу. Осознав эту фигню, я осознанно взялся за формат потребления и наглухо заблокировал все медиа через /etc/hosts (тг-каналов, к счастью, у меня не было). Вот уже 4 месяца, как я не прочитал и не услышал ни одной единицы срочного контента.

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

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

Анализ систем и распил монолитов

Оглядываясь на прошлое лето, когда мы решили сделать продолжение «Асинхронной Архитектуры», я чувствую себя продюсером «Безумного Макса 4». И не потому, что у нас в качестве эксперта выступает Том Харди (уверен, Антон разбирается в архитектуре лучше), а потому, что мы делали этот курс почти год.

Причина простая — задумали слишком много: хотели так же, как «Стать Тимлидом», сделать курс «Стать Архитектором». Мы не учли, что этим двум профессиям нужно учить по-разному: тимлидам нужно дать практический фреймворк для развития и немного попинать, а вот архитекторам нужна ТЕОРИЯ в огромном количестве. Собственно, весь год мы и пробовали разные подходы, чтобы отжать и упаковать ТЕОРИЮ так, чтобы её можно было прочитать и не умереть.

В итоге остановились 5 уроках, в ~50 страниц A4, построенных на «кругах профессионализма» — каждый новый урок учит решать ту же задачу, что и предыдущий, но на новом уровне и для бизнеса с новым скейлом, с учётом предыдущих ошибок. Получается, как прогрессивный джипег: можно прочитать и половину курса, и уже стать сносным архитектором для не очень сложных систем. Чтобы мысли Антона легко воспринимались в тексте, мы позвали Тимура Зарудного: это первый раз, когда мы зовём пишущего редактора, до этого были только корректоры, а редактировали мы с Марьяной.

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

Стартуем 12 мая, 5 уроков, 4 круга профессионализма, Q&A, чатик с Антоном и десяток котов в каждом уроке. Если дойдёте до конца — получите достаточно знаний и инструментов, чтобы проектировать системы для большинства крупных работодателей.

До 26 апреля действует промокод K1F3N на 10% скидки. C 1 мая — повышаем цены.

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

#вопрос вот бывает пишешь какому-нибудь занятому чуваку, типа CEO, а он не отвечает. Как тактично напомнить о себе?

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

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

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

Так что если вам не отвечают — первым делом перечитайте письмо. Как можно сделать ваше предложение более интересным? Как можно сделать ответ на ваше письмо более простым? И только после этого — напоминайте.

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

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

Недавно убеждал одну команду установить себе нормальный 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 на стрим: с Димой ответим на вопросы о курсе и, если успеем, — о поиске работы. Ссылку скину сюда ближе к делу. Записи не будет.