FastNews | Никита Пастухов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://t.me/artemshumeiko/361

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

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

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

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

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

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

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

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

ССЫЛКА

FastStream + Cursor

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

Я уже жаловался на качество сгенерированных нейронкой Cursor Rules для публичных проектов. А что будет, если такие правила напишет РУКАМИ эксперт технологии? Или даже ее автор?

Наш промпт

Generate FastStream NATS application, that consumes messages by "logs.{log-level}" subject and logging consumed message and log-level from subject pattern.

Message should be JSON with {user: str, user_id: int} structure

Буквально за 30 минут я заставил нейронку стабильно генерировать код со второго скрина (вместо невалидной лапши с первого).

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

#AI #cursor

К слову о "Celery головного мозга"

Просто посмотрите на динамику поисковых запросов в Google trends.
Люди на порядок чаще ищут Celery, нежели способы работы с RMQ / NATS из python напрямую.

Но при этом запросы по Kafka держатся на уровне с Celery. Это связано с тем, что Celery не матчится с кейсами Kafka. И пользователи Kafka это прекрасно понимают! Поэтому и не ищут обходные пути, а работают со своим брокером напрямую.

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

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

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

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

Отклонено, как и ожидалось😢
Ладно, попробуем еще... Чуть позже🌚

Я сегодня разослал 70 писем (спамер, ага) по разным почтовым ящикам крупных компаний – попробуем собрать красивый лендинг со всякими "нас использует Google"😅

Попытка применения практик Ильяхова №1. Напишите в комментах, какой вариант вам больше нравится.

БЫЛО

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

СТАЛО (итерация 2😂)

Первый релиз Celery вышел аж в 2010 году. С тех пор его затащили сотни тысяч проектов. На одном Github Celery использует 180k публичных репозиториев.
Люди же мыслят паттернами – они пытаются решить любые задачи знакомыми инструментами. Поэтому, когда речь заходит о брокерах сообщений, люди машинально тянутся к родному сельдерею.
Я нахожу это печальным. Event-driven архитектура дает нам множество возможностей. Мы же насильно ограничиваем себя паттернами конкретного инструмента...
Поэтому в докладе мы обсудим разницу между событийно- и задача-ориентированными архитектурами, разберемся какие преимущества несет каждый из подходов. Я покажу вам альтернативы, и вы сможете осознанно принять решение об инструменте, подходящим для вашей системы.

Кстати, если хотите послушать этот доклад, залетайте на митап в Нижнем Новгороде 18 июля –https://pytho-nn.timepad.ru/event/3412736/ 🌚

Любители курсора уже нафигачили правил для генерации на все либы, фреймворки и языки:

https://github.com/sanjeed5/awesome-cursor-rules-mdc/blob/main/rules-mdc/fastapi.mdc

Как вам такие правила для FastAPI? Следовали бы им сами?

В этой истории меня больше всего раздражает то, что большая часть этих рулов не написана вручную со знанием дела, реальными best practices и антипаттернами, а сгенерированы чем-то вроде – https://cursor.directory/generate

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

7.1 Recommended Development Tools

* IDE: VS Code, PyCharm, or other IDE with Python support.
* Virtual Environment Manager: `venv`, `conda`, or `poetry` for managing project dependencies.
* Package Manager: `pip` or `poetry` for installing and managing Python packages.
* Debugger: `pdb` or `ipdb` for debugging Python code.
* Profiler: `cProfile` or `py-spy` for profiling Python code.

Ну нахера нейронке это знать, когда она генерирует вам код для FastAPI!? Ох уж эти вайбкодеры...

Та самая фабрика русских троллей по мнению Торвальдса: https://github.com/torvalds/linux/pull/1261

За ссылку спасибо @tapeline_tg

Короткопост о книге в дорогу

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

В общем, жду фидбека от вас

Всем привет! Совсем недавно прошел PiterPy 2025, где я снова рассказывал про FastStream – теперь про внутреннее устройство.

Конфа получилась супер-улетная! Я отстрелялся первым в первый же день – и ходил кайфовал с других докладов. Получил много классный инсайтов от MLщиков (конфы с разными треками❤️), да и питонисты не отставали – программа получилось сочная.

А еще был целый турнир!!! По настолке Ship It от Никиты Соболева, где я наконец-то проникся всей духотой задумки😅

В общем, у меня для вас мега-приватный инсайд – запись моего доклада уже на YouTube, но доступна только по этой ссылке:

https://youtu.be/cjTZxwTK6PQ

У кого нет доступа к записям PiterPy – можете посмотреть тут (публично запись появится только перед следующей конфой). Напишите в комметах, как вам доклад, чтоли😅

Надеюсь, увидемся с Питером и в следующем году😊

#доклад