Ура, мой первый PR в CPython смержили!

Хотел сделать мемный +1 (это даже круче, чем +1/-1), но в CI падало 2 теста, поэтому пришлось сделать +2😢

https://github.com/python/cpython/pull/135766

Спасибо Никите Соболеву и @opensource_findings_python за строчку CPython Contributor в резюме😂

FishITStream – разговоры о Python на рыбалке🤯

(да, аллюзия на FastStream)

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

Кто будет на связи:
– Коля Хитров — Python-блогер и серийный спикер
– Никита Соболев — CPython core developer, безработный
– Роман Пожарнов — автор asgi-monitor, спортивный рыбак, говорит на рыбьем языке
– я — автор FastStream, галерный гребец, филантроп

О чем поговорим:
– Развитие языка Python: как развивается язык, и почему Python всё ещё лучше Go!
– Какую прикормку лучше всего брать на карася
– Конференции и нетворкинг: зачем идти слушать и выступать, как найти тему для доклада
– И, конечно же, мы не оставим без внимания OpenSource: развитие продуктов, мотивация людей и правильное использования OSS
– А еще всякое про карьеру и прочее

Время: 29 июня, 12:00 МСК

ССЫЛКА

Жуткая правда о FastStream выяснилась сегодня. На самом деле – это тайный проект FastAPI🤯

А Никита Пастухов – просто псевдоним Sebastian Ramirez'а🌚

Опа, первый видос по FastStream в ру сегменте за долгое время. И второй – за все😢

Нужно наращивать объем контента, так что накидайте комментов. Чтобы Артем продолжение делал🌚

https://t.iss.one/artemshumeiko/361

Ребят, важный опрос!

Хочется понимать свою аудиторию, поэтому выбирайте, какой брокер(ы) используете в своих проектах! Если не используете FastStream – брокер все равно отмечайте. Если используете что-то другое – отпишите в комменты.

У нас тут подходящая аудитория, чтобы найти самый любимый питонистами брокер😅

Почему ЭКСПЕРТОВ нужно душить в зародыше? – применимо не только к разработке

Посмотрел провокационный доклад от Егора Бугаенко: https://youtu.be/1-NJc2Q5a0U?si=GFbiIig6ExH_Aye-

Основной тезис: В проекте не должно быть людей, которые накапливают все знания

Идея очень здравая, и я полностью ее поддерживаю. Люди, которые знают о проекте ВСЕ, делают его unmaintainable. Им не нужно поддерживать документацию в актуальном состоянии, они и так все помнят. Другие члены команды полагаются на ЭКСПЕРТА во всех решениях – он должен подробно объснить им что нужно делать и как. В итоге вся команда скатывается в зависимость от эксперта. А он только укрепляет свою власть за счет беспомощности других. У людей просто нет других каналов получения информации, кроме "спросить лично у эксперта". Это самораскручивающаяся спираль.

Но выводы из таких предпосылок у Егора очень смелые – запретить митинги!

Каждое решение, отраженное в проекте, должно иметь публичную мотивацию. Должен быть заведен тикет, все обсуждения – в рамках него. Не понятно, почему коллега сделал именно так? – не иди в чат – заводи Issue! Пусть пишет документацию, переделывает понятно или объясняет там! Другие люди с таким же запросом должны найти ваше обсуждение, а не дергать ЭКСПЕРТА повторно. Тогда каждая часть вашего проекта будет иметь какую-то мотивацию за собой, которую можно легко найти самостоятельно.

Это буквально то, как работает OpenSource, но тут есть свои нюансы. Это банально сложно.

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

Проблемы FastStream сейчас
– нет публичного таск-треккера (кроме Issue, но это немного другое)
– нет публичного родмапа
– плохой гайд по онбордингу
– часть задач проходит в обход Issue
– часть коммуникаций идет в чатах телеги вместо публичного обсуждения на гите
– нет внутренней документации модулей
– появились созвоны для развития экспертизы только тех людей, что есть на проекте сейчас

Все эти проблемы я осознаю и стараюсь закрыть. Но часть решений я не могу назвать провальными. Есть тонкий баланс между развитием агентности контрибуторов и их мотивацией. Если ставить перед людьми слишком широкий круг задач без полной поддержки – они просто дропнут эти задачи. А "полная" поддержка не умещается в рамках только Github.

Такое себе оправдание, конечно... Ну и ладно, будет работать над собой и становиться лучше!

В полку AI IDE прибыло –Amazon выпустили своего конкурента Cursor https://kiro.dev/

UPD: я упустил еще одну IDE'шку https://www.trae.ai/🤯

Теперь у нас есть на выбор Cursor, Windsurf, Kiro, Trae, Codebuddy, Claude Code, Aider.

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

Например, вот тут
https://research.google/blog/ai-in-software-engineering-at-google-progress-and-the-path-ahead/

Google репортит, что уже около 50% их кодовой базы пишется AI – либо через автокомплиты (они меряют рейт принятия комплитов от AI и попадания этого кода в финальный коммит), либо полностью агентами.

Я думаю, время быть скептичным прошло. А вы уже ускоряете свои процессы с помощью AI?

К слову, отмазы про "у нас тут NDA и мы не дадим коду утечь" тоже больше не работают. На днях релизнули Kimi K2

https://moonshotai.github.io/Kimi-K2/

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

AI держит меня в заложниках. Теперь официально.

На выходных послушал свой любимый подкаст Podlodka – и там снова говорили про AI (гостем был @denissexy)

Но на этот раз не для написания кода, а... Черт его знает. Просто AI для всего на свете. Там и про советы в путешествиях, и AI-медицинский ассистент, и контент-мейкер, и заказывальщик БАДов. В общем, я снова вдохновился и пошел пробовать всякое.

Например, Google AI Studio. Оказалось, это действительно оч крутой инструмент. Закинул в него всю выгрузку с канала с простым запросом: "Проанализируй контент, определи стиль автора, основные темы и предложи контент-план для роста". Словил пару инсайтов, но ничего такого, чего я не знал ("продолжай писать о FastStream и продуктивности", ага).

Но с одного пункта я прям выпал

Контент-план на 5 постов

Пост 1: Практическое применение TDD (Экспертный / Программирование)

Цель: Выполнить обещание, данное в постах №53, 54, 58, и предоставить аудитории ценный практический материал.

Кажется, у меня уже нет выбора... Андрей, ты там как, ждешь пост с практикой по TDD?😂 Или кто там нейронку подговорил?

Мне пора начинать писать пост про TDD, пока мой AI-ассистент не начал ставить задачки в Jira😱

UPD: часть поста сгенерирована в Google AI Studio. Попробуете угадать, какая?🌚

#AI #aistudio

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

Эффективность = Результат / Затраты

Казалось бы, очевидно. Но дьявол, как всегда, в деталях.

Что такое "Результат"?
Это не просто "сделанная задача". Это ценность и влияние, которое она принесла. Запилить фичу за час — круто. Но если этой фичей никто не воспользуется, ее ценность, а значит и ваш результат, равны нулю. Эффективность тоже.

Что такое "Затраты"?
И вот тут главный инсайт. Мы привыкли мерить затраты только временем. Но это лишь верхушка айсберга. На самом деле мы тратим:

🧠 Мыслетопливо (привет, Дорофеев!)
💪 Физические силы
🧘‍♂️ Эмоции (привет, выгорание!)
🎯 Внимание
💰 Деньги

Главная ошибка, на которой попадаются все: мы отчаянно пытаемся уменьшить знаменатель (в основном время), забывая про числитель. Мы учимся делать бесполезные вещи очень быстро, сжигая все свое мыслетопливо. Итог - выгорание и нулевой результат.

Как быть эффективным на самом деле?

1. Прокачать числитель (Результат):
- Спрашивать "Зачем?": Постоянно задавать себе вопрос, какую реальную ценность принесет эта задача. Это тот самый навык, который отличает синьора от джуна
- Бить в самое важное: Применять правило Парето. Находить те 20% действий, которые дадут 80% результата, и фокусироваться на них

2. Уменьшить знаменатель (Затраты):
- Автоматизировать рутину: Все, что можно автоматизировать, должно быть автоматизировано.
- Не делать лишнего: Самый эффективный способ сделать задачу - понять, что ее делать не нужно.
- Выгружать все из головы: Использовать внешние системы (календарь, таск-менеджер), чтобы не тратить драгоценное мыслетопливо на запоминание.

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

В общем, всячески рекомендую оригинал к прочтению: https://bryzgalova.ru/effectiveness

#продуктивность #карьера #Дорофеев

Перебирал заметки по "Джедайским техникам" и наткнулся на фразу, которая мне безумно нравится своей очевидностью:

"Почему все тянут до последнего, чтобы сделать через жопу? Если сделать через жопу сразу, то останется время все улучшить"

Это просто квинтэссенция борьбы с перфекционизмом в нашей работе.

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

А ведь можно было сделать "хоть что-то" в самый первый день. К слову, TDD так и работает. Мы идем маленькими шагами по улучшению системы от самых тупых кусков кода к космолету.

Да, это был бы неидеальный код. Возможно, с парой "тупых" решений.

Но у нас было бы главное:
- Рабочий прототип. Что-то, что можно пощупать и показать.
- Обратная связь. От коллег, от системы, от самого себя.
- Время на итерации. Целая неделя, чтобы превратить решение "через жопу" в элегантное и надежное.

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

Возможно, наш главный враг — это не технический долг, а страх создать его на время?

#программирование #продуктивность #tdd #дорофеев

Сегодня совершенно неожиданно для меня вышли сразу два видоса по FastStream!🤯

От Никиты Соболева: https://www.youtube.com/watch?v=Qf4r8xV-YNk

От Сурена: https://youtu.be/GqC29YuuuGk?si=ZPip3SZbzQU2aYB5

С каждого обязательно по просмотру и лайку! И огромное спасибо самым народным ютуберам за интерес к проекту❤️

Наконец-то снова техническая тема. Переслушивал доклад про NATS – и это натолкнуло меня на размышления, которыми хочу поделиться с вами.

Back Pressure: почему упасть иногда важнее, чем работать

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

Чтобы этого не происходило, умные системы используют механизм обратного давления (back pressure). Это не просто ограничение, это встроенный в протокол или архитектуру способ для потребителя сказать производителю: "Эй, я не успеваю, притормози!".

Это фундаментальный принцип построения отказоустойчивых систем. Давайте посмотрим на два примера.

⚡️ Back Pressure в HTTP: паттерн Circuit Breaker

В мире синхронных HTTP-запросов для обеспечения back pressure принято использовать паттерн Circuit Breaker ("Автоматический выключатель").

Представьте, Сервис А вызывает Сервис Б по HTTP. Сервис Б начинает тормозить или отвечать ошибками из-за нагрузки или сбоя в базе данных.

Что сделает наивный Сервис А?
Он будет долбиться в Сервис Б снова и снова, возможно, с ретраями. Если экземпляров Сервиса А много, они создадут "грозовую толпу" (thundering herd), которая окончательно добьет больной Сервис Б, не давая ему ни шанса на восстановление.

Как работает Circuit Breaker?

На самом деле это очень простой переключатель с тремя состояниями:

- Closed (Замкнут): Все хорошо, запросы свободно уходят в Сервис Б.

- Open (Разомкнут): Счетчик ошибок превысил порог (например, 5 ошибок за 10 секунд). "Пробка вылетает". В течение следующих 30 секунд Сервис А даже не пытается отправить запрос в Сервис Б, а сразу возвращает ошибку. Это и есть back pressure! Мы даем Сервису Б время на восстановление, не заваливая его запросами.

- Half-Open (Полуоткрыт): Через 30 секунд выключатель переходит в это состояние и пропускает один-два "пробных" запроса. Если они проходят успешно — цепь замыкается (Closed). Если нет — снова размыкается (Open) еще на 30 секунд.

🌊 Back Pressure в брокерах: NATS JetStream

Представьте, у вас есть сервис, который генерирует события (например, клики пользователей), и второй сервис, который их обрабатывает (считает аналитику, отправляет в БД). Продюсер может генерировать 10 000 сообщений в секунду, а консьюмер — разгребать только 1000.

Что произойдет без back pressure?
Сообщения будут копиться в очереди брокера, потребитель не будет успевать их разгребать. Отставание в обработке будет накапливаться – минуты, час, дни. В итоге вся система будет выполнять уже не актуальную работу и приносить ровно 0 пользы. А потом и память брокера переполнится – и умрет совсем все

Как решает проблему NATS JetStream?
У стримов в NATS есть две важные опции: max_msgs (`max_bytes`) и DiscardPolicy. Используя эти настройки можно добиться разного поведения, но здесь нас интересует DiscardPolicy.NEW

from faststream.nats import DiscardPolicy, JStream

stream = JStream(
    "stream",
    discard=DiscardPolicy.NEW,
    max_msgs=1000,
    # max_bytes=1024 * 1024 * 1024,
)

Когда стрим заполняется до указанного предела, продюсер при попытке сделать publish() получит ошибку. Это и есть наш back pressure!

Продюсер вынужден либо сбросить темп, либо отложить отправку, либо сбросить часть данных. Но главное – он знает, что с другой стороны не успевают. Потребитель защищен на уровне инфраструктуры.

🛡️ Итог

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

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

#архитектура #распределенные_системы #backend #nats #devops

НАКОНЕЦ-ТО! Этой ночью мы смогли релизнуть FastStream 0.6.0 (пока как release candidate) – https://github.com/ag2ai/faststream/releases/tag/0.6.0rc0

Это была огромная работа и мой публичный позор как разработчика, мейнтейнера, руководителя😢

Вот этот PR: https://github.com/ag2ai/faststream/pull/1779

- 23 контрибьютора приняли участие в подготовке этого релиза
- было сделано 400+ коммитов (а это еще были сквоши при мерже)
- затронуто 2000+ файлов
- больше 60 000 изменений кодлайнов
- почти ГОД работы!

Мы переписали проект изнутри практически целиком (снова). Нет ни одной строчки кода, которую мы бы не затронули. Обновили документацию, тесты, CONTRIBUTING гайд, мигрировали на новые подходы к работе с репой как локально, так и в CI... Практически удвоили тестовое покрытие фреймворка.

Изменения не должны быть такими большими. Они не должны доставляться до потребителя ТАК ДОЛГО.

За это я прошу у вас прощения🙏

Но также это большая радость и облегчение для меня – теперь мы снова разблокируем добавление новых брокеров! На очереди поддержка MQTT и SQS! А еще новая структура проекта позволит нам добавить еще больше классных и нужных фич. Постараемся делать следующие релизы гораздо быстрее (попробую уложиться в сроки до 3ех месяцев на мажор). Но пока я хотел бы взять небольшую паузу и просто выдохнуть.

До 1.0.0 осталось совсем немного вещей, которые мне хотелось бы добавить во фреймворк. Теперь ломающий изменений почти не остается.

Также хочется сказать спасибо команде контрибуторов, которая активно помогала мне дотащить этого гиганта до вас. Ребята супер-красавчики, я буквально каждому обязан❤️ Большая часть из них уже имеет права в репозитории, так что процессы также будут трансформироваться.

А пока – я прошу вас установить

faststream==0.6.0rc0

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

А с обновленной документацией вы можете ознакомиться тут:

https://faststream.ag2.ai/0.6/

И в догонку – сегодня подошли результаты Kaicode. FastStream занял первое место и выиграл 2k$🥳

https://www.kaicode.org/2025.html

Это конкурс Open Source проектов, где оценивается качество проекта: код, работа с Issue, CI, документация и тд.

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

Поэтому рекомендую всем подавать свои фреймворки / библиотеки / библиотечки. Даже если не выиграете, то получите ценный фидбек от опытных членов жюри.

Наверное, подам на следующий год другой свой проект https://github.com/Lancetnik/FastDepends 😂

Ребят, последние дни я вспомнил, что я – автор (и мейнтейнер) крупного фреймворка.

FastStream, если кто не в курсе🌚

(А то все про продуктивность, да разработку говорили)

Для меня это уже норма жизни, но мб кому-то интересен именно этот аспект?

Что бы вы хотели спросить у меня:

- как продвигать проект? какие каналы работают, какие - нет?
- как вырабатывать идеи?
- как много времени у меня на это уходит?
- что я с этого имею?
- какие типовые задачи я решаю в Open Source'е в течении дня? Недели? Квартала?
- как вообще выглядит планирование в OSS?
- как помогает сообщество?

В общем, накидайте вопросов в комменты – обсудим. А что-то мб выльется и в отдельный пост / статью / доклад.

У меня есть идея подготовить доклад на следующий сезон "Люди и Open Source" – про поиск пользователей, поиск контрибуторов, их (и свою) мотивацию, виды задач в OSS и всякое такое.

Но мб идея тухлая и ваши вопросики направят меня в нужную сторону.

OpenSource не помогает найти работу!

А потом тебе пишут на почту с предложением работы в зарубежном стартапе на очень вкусные цифры...

Оказывается, появилась целая платформа для HR, где мониторится топ-перформеров на гите🤯

https://algora.io/profile/Lancetnik

UPD: оказывается, там есть еще и Issue-баунти. Компании назначают вознаграждение за PR'ы. Как вам 3.500$ за MCP?

В общем, бежим коммитить!

Btw, на неделе закину историю другого человека, кто нашел работу благодаря Open Source🌚 И нет, он не мейнтейнер / топ-перформер или что-то вроде