Привет всем!

Для тех, кто не знает, я:
– Python (и не только) разработчик
– автор и мейнтейнер фреймворка FastStream
– мейнтейнер фреймворка AG2
– вольный контрибутор разных других OpenSource проектов
– немного автор на Habr
– немного спикер: PiterPy 2024, PiterPy 2025, Podlodka Python Crew

В этом канале я буду:
– делиться полезными новостями, статьями и докладами, что мне встретятся
– публиковать ссылки на свои свеженькие статьи и выступления
– закидывать интересные факты о разных OpenSource проектах (в т.ч. и FastStream)
– закидывать рандомные мысли об IT, OpenSource, карьере, управлении проектами и продуктивности

В общем, если вам такое интересно – welcome!

Ссылки на чатики:
– @fastnewsdev_comments – чатик для спама и оффтопа в рамках канала
– @python_faststream – чатик по FastStream

Также вы можете поддержать мои начинания и/или выразить мне свою благодарность не словом, но делом рублем! Или если вы хотели угостить меня, например, пивом - вы можете просто оплатить его)

Навигация по каналу осуществляется через теги

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

Ну а теперь - специальный контент

Я поднял старые записи, пошерстил интернет снова - и собрал для вас специальную подборку "убийц" FastStream! Так что, если проект вам не нравится, вы можете присмотреть альтернативу где-нибудь здесь

* Kombu - дед жив и деда надо уважать. Один из идейных вдохновителей FastStream и просто титан, на чьих плечах стоит Celery 2.9K звезд (мы его уже обогнали🤯)
* Eventiq - самый живой аналог FastStream. Имеет целую экосистему с OpenTelemetry, Prometheus, AsyncAPI и прочим фаршем. Автор даже регулярно коммитит. 1 звезда (+ 10 в архивном репозитории)
* Aio-bunny - автор жив, коммитит. Приятный API, который что-то напоминает. 6 звезд!
* RAMQP - ничего не напоминает? А интеграция с FastAPI?🌚
* Mognet - идиологически то, но функционально ближе к Celery
* Hatter - смотрите-ка, кто-то писал FastStream еще 3 года назад
* Panini - NATS-based фреймворк с похожей концепций, хотя ребята еще и Celery хотят одним махом прибить
* WASPy - 8!!! лет назад люди уже регистрировали колбеки для сообщений через роутеры, а мы до сих пор на "сырых" клиентах сидим
* NatsAPI - еще один NATS-фрейморк. С декораторами, роутерами - все как положено. Иногда даже коммитят
* Tomodachi - ужасающий комбайн, который пилят аж с 2017 года. Умеет все, в т.ч. и брокеры
* Async-worker - еще один проект с похожей концепцией. Пилят с 2021 года, последний коммит год назад
* Aiocarrot - проект создали месяц назад, а я его уже нашел. Зато стабильный 1.0.0 релиз!
* Kstreams - живой проект, товарищи пилят его для внутреннего использования. Скорее убийца Faust, но API крайне похож

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

Вывод, который я сделал для себя в свое время, когда только-только написал Propan и был окружен десятком таких же проектов с 0-10 звезд на гите: написать код - это 10% успеха проекта. Чтобы твоим "идеальным" кодом пользовались, люди должны о нем знать. Если ты не готов как полоумный бегать и везде "продавать" свой проект, то лучше сразу смириться, что ты пишешь код в стол. Чего стоят твои гениальные идеи, если ими никто не пользуется?

А еще - в одиночку ты не сможешь сделать что-то стоящее. Именно поэтому я сразу же обошел половину этих репозиториев (из живых) и предложил их мейнтейнерами сотрудничество и совместную работу над общим проектом. Сложилось с AIRT (FastKafka) - а дальше вы знаете😅 Чтож, возможно, пришло время обойти их второй раз и напомнить, что FastStream все еще открыт для идей, и в нем всегда рады талантливым разработчикам с теми самыми горящими глазами🔥

Ну чтож, отправил заявку в AsyncAPI на включение меня в список амбассадоров.
FastStream привлекает достаточно внимания к AsynAPI спеке, так что у них есть повод показать, что OpenSource все еще вне политики и включить в свой список амбасадоров человека из России🌚 А я буду ходить светить AsyncAPI мерчем на всех конференциях😂

К слову, кто из вас узнал о существовании AsyncAPI только после знакомства с FastStream?😅

https://github.com/asyncapi/community/pull/1608

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

Что-то у меня сегодня мелонхоличное настроение. Поэтому будет вечер вопросов в пустоту.

- Прочитать (и усвоить) фундаментальный толмут в кратчайшие сроки?
- Прочитать больше всего кирпичей?
- Выучить больше всего паттернов?
- Потыкать больше всего инструментов?
- Решать задачи на leetcode каждый день?
- Собирать красивые графики ежедневных коммитов?
- Может быть пройти больше всего собесов?
- Красноглазить самому себе поставленные дедлайны до 3ех утра?

А какие еще проявления Hustle Culture и токсичной продуктивности в разработке вы можете припомнить? "Быстрее, выше, сильнее" стало "умнее и эрудированнее", но лучше ли это... Сколько спортсменов получают травмы во время тренировок, пытаясь выйти за грань своих физических возможностей? А сколько разработчиков выгорают, потратив весь свой ресурс?

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

Но ведь умные парни не идут на поводу у инфоцыган. Умные парни знают, что нельзя стать синьором за 2 недели, нужно усердно работать чтобы добиться результата. Умные парни обитают, например, в чате @fastapi_ru. Там они вдохновляются примерами действительно опытных разработчиков - и идут в усердно ботать все упоминаемые там даже вскользь книги. Однако, делает ли яростное изучение всей возможной мукулатуры и ревностное следование "тем самым правилам" показателем синьористости? Вопрос риторический... Почему-то за шорами новичков всегда остается опыт людей, на которых они равняются.

Мб переформулируем? "Если синьор с 20летним опытом прочел Фаулера и я прочту, то я тоже стану синьором!" - что вы думаете о такой формулировке? Не кажется ли она вам очередной попыткой "срезать углы" на карьерных поворотах?

Не спорю, какой-то процент людей может выдержать такую бесконечную гонку. Но дай бог 1%. Остальные просто полягут, пытаясь их догнать (да и зачем?)

Помните басню про зайца и черепаху? Карьера - это не 100метровка, и даже не марафон. Это путь длиною в жизнь. Если вы будете бежать, выбиваясь из сил - вы просто быстрее устанете. А пока вы переводите дух, какие-нибудь спокойные, но целеустремленные пешеходы вас обгонят. Главное - не стоять и не плыть по течению.

Стабильный путь - он всегда срединный. Буддисты не просто так это придумали еще 3000 лет назад. Здоровый интерес к своей деятельности, открытость новому и современным тенденциям, незашоренность взглядов, умение расти над собой и способность перенимать чужой опыт - достаточные гаранты отличной карьеры в какой угодно области. Для этого не надо марафонить ночами книги или литкод. Просто не убегайте от вызовов на работе, почитывайте чатики/форму и периодически ходите на конфы (чтобы быть в курсе), ну и пета какого-нибудь "для души", где можно все новое потыкать - и не успеет оглянуться, как пройдет 5 лет, а вы - топовый специалист в своей теме🤷 Ну или нет (а оно вам надо?).

В общем, "гори, но не сгорай". Всем хорошего вечера!

#продуктивность

Хотпост по мотивам срачей об архитектуре.

Все совпадения персонажей с реальными действующими лицами - случайны, а все факты взяты с потолка.

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

Вот тот же дядя Боб. Мужик с 40+ лет стажем, написал кучу кода, создал кучу систем, работал консультантом за большие деньги в важных компаниях. Ну и написал пару книг с советами, исходя из опыта (и осмысления тейков других важных дядь).

А потом рандомный 18летнений парень из чата, который прочитал всю возможную литературу говорит, что "Боб ошибался, т.к. написал Х, а это не так, потому что [умные слова]". И вот так получается, что каждый из ВЕЛИКИХ авторов в том или ином месте ошибался, но ты прочитал всех и схватил шизу преисполнился, познал святой Грааль и теперь точно знаешь, как надо писать код ПРАВИЛЬНО

А потом делаешь глобальный контейнер зависимостей, который нельзя подменить в тестах и херишь все преимущества АРХИТЕКТУРЫ

Получается что? Зубрежка кирпичей не гарантирует идеальной кодовой базы? ИМХО, раз уж ВЕЛИКИЕ авторы противоречат друг другу и не смогли прийти к единой картине мира о том, КАК ПИСАТЬ КОД, то нам остается только писать его как-то. Нормально пиши - нормально будет. Если при прочтении кодовой базы соседа ты понимаешь, что и почему там написано - то это good enough кодовая база. Ну и SOLID, конечно же.

А если дядя Боб неправильно трактовал Фаулера, то кто ТЫ, блять, такой, чтобы правильно его трактовать?

#архитектура #программирование

Последнее время я часто говорю про какой-то "реекспорт" и меня никто не понимает. Обидно...

Поэтому накидаю свои мысли на этот счет постом, чтобы на него потом ссылаться.

Какие у нас вводные?
1.1) Есть два разных контекста кода, которые схожи друг с другом, но не должны пересекаться по реализации из сообрежений SRP.

ИЛИ

1.2) Есть внешний код, который закрывает нашу потребность (пока что), но в перспективе наши требования могут заставить нас отказаться от этого объекта и спрятать его за свой адаптер.
2) Мы не хотим писать много кода уже сейчас. Поэтому мы не против чуть-чуть накинуть грязи с понятной стратегией ее уборки.

Т.е. у нас есть кусок кода и нам нужно изобрести свой второй пока что такой же (ключевое слово пока что, т.к. таким же он быть не может из-за SRP), но дублировать его мы не хотим (DRY же, да?)

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

Приведу пример из исходинов FastStream 0.6.0: у нас есть 2 модуля генерации документации

* faststream.specification.asyncapi.v2_6_0
* faststream.specification.asyncapi.v3_0_0

Соответственно, это разные мажорные версии спецификации и даже общие куски между ними представляют собой мнимое дублирование. Т.е. мы не можем создать какой-нибудь shared модуль, куда вынесем общие классы для этих спецификаций. А что делать? Ну, конечно же, заводить полное дерево объектов для каждого из подмодулей. Т.е. v3_0_0 и v2_6_0 модули имеют внутри себя набор всех необходимых для их работы объектов и не могут импортировать какие-то объекты друг из друга.

Но ведь код полностью дублировать не хочется?😉

Ну, поэтому мы просто делаем одинаковые деревья файлов в этих модулях, пишем полную v2_6_0 реализацию, а в v3_0_0 начинаем "лайфхачить"

Например, какой-нибудь v3_0_0.servers.ServerVariable может на уровне реализации выглядеть вот так

from faststream.specification.asyncapi.v2_6_0.schema import ServerVariable

__all__ = (
    "ServerVariable",
)

Или какой-нибудь ChannelBinding может наследоваться от своей же версии из v2_6_0

from faststream.specification.asyncapi.v2_6_0.schema.bindings.amqp import (
    ChannelBinding as V2Binding,
)

class ChannelBinding(V2Binding): ...

Сами по себе такие приемы нарушают SRP и вообще ай-ай-ай. Т.е. у нас контекст знает об объектах из совершенно другого контекста. И даже выставляет их за свою реализацию! Или наследует! Ужас, в общем.

Но суть в том, что об этом за пределами файла с реализацией никто не знает. Весь остальной код притворяется, что использует полноправную самостоятельную реализацию v3_0_0.bindings.ChannelBinding класса. А это открывает нам возможность маневра по удалению этого нарушения SRP очень простыми способами в дальнейшем (когда оно начнет стрелять нам по ногам)

1) Мы можем патчить и дорабатывать реализацию другого модуля через наследование, о котором никто не узнает
2) Мы можем спрятать реализацию другого модуля за фасад
3) Мы можем удалить "реекспорт"/наследование и написать в файле полностью самостоятельную реализиацию

В общем и целом, никто не знает, что там происходит внутри файла, поэтому никто не узнает, что SRP нарушен, а это значит, что ему это не навредит🌚

Однако, тут есть один подводный камень - если мы "реекспортируем" / наследуемся от реализации из другого контекста, то пользователь нашей реализации может завязаться на те методы, которые пришли из исходной реализации и не предпологаются в API текущей. Тогда, при устранении нарушения SRP мы столкнемся с тем, что часть кода пользователя отваливается из-за несовместимости новой реализации API старой. Поэтому в *идеальном мире* мы должны прятать такие "реекспорты" хотя бы за адаптер. Но на практике это излишне.

#программирование

Самое интересное: я тут написал какую-то муть про организацию кода библиотек или оно применимо в реальных приложениях? Ну, конечно же применимо! Например, подобным образом вы можете прятать *не очень красивые* Repository из Litestar за своими "красивыми" протоколами и реализациями

# author_repo_protocol.py
from typing import Protocol

class GetAuthorRepo(Protocol):
    async def get(self, author_id: int, /) -> Author:
        ...

class DeleteAuthorRepo(Protocol):
    async def delete(self, author_id: int, /) -> None:
        ...

class AuthorRepo(GetAuthorRepo, DeleteAuthorRepo):
    pass

# author_repo_impl.py
from litestar.contrib.sqlalchemy.repository import SQLAlchemyAsyncRepository

class AuthorRepository(SQLAlchemyAsyncRepository[Author]):
    model_type = Author

Если все ссылаются на ваш "правильный" протокол, а реализация подмешивается не из litestar модуля, а вашего, собственного!!!, то никто и не узнает, что вы ничего и не писали, а взяли грязь из Litestar и выдали ее за свою. И никто даже не заметит, когда вы ее замените на нормальную реализацию

#программирование #litestar

Изначально я планировал публиковать тут информацию только по FastStream, но кажется, мне есть что сказать и в отрыве от него. Поэтому я создал отдельный канал чисто для FastStream - @faststreamrelease

Там будет техническая информация о релизах. И, может быть, какие-то отдельные заметки о планах на будущее, касающиеся только FS. Что-то интересное будет репоститься и сюда, но основная техническая информация - там

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

Наконец-то я выполнил свое обещание перед Андреем и выпустил на Habr статью про FastAPI, DI и dishka!

Она лежала в загашнике полгода, добить ее до выпуска силы нашлись только сейчас.

Чтож, надеюсь, это немного поможет в популяризации dishka и культуры разработки в FastAPI сообществе в целом.

https://habr.com/ru/articles/867040/

#программирование #dishka #fastapi

Тем временем холивары внутри mypy, которые я невольно спровоцировал, продолжаются. И даже вышли на новый круг эскалации - https://github.com/python/mypy/pull/18270#issuecomment-2551709475

За этим интересно наблюдать и крайне интересно, к какому решению в итоге придут мейнтейнеры😅 Жду с нетерпением, чтобы тоже чуть-чуть покопаться в mypy и поправить другие места на основе решения этого PR

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

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

Интересно, это Сбер так рекламирует свою HR платформу или просто баги на прод завезли?

Кто-нибудь понимает, как мержат проекты в этот ваш awesome-python?

У меня просто мозг взрывается от того, что туда до сих пор не добавил uv (который буквально уже везде используется, даже в самом cpython) - https://github.com/vinta/awesome-python/pull/2605

К слову, FastStream туда тоже так и не добавили😢