Ситуация вышла из под контроля и FastDepends перевалил за 1_000_000 установок в месяц!🥳

Кажется, нужно туда хотя бы закоммитить😅

Yet another Celery killer moment - товарищ устал ждать развития arq и запилил свое видение проекта - https://github.com/python-arq/arq/issues/437#issuecomment-2675789579

Над неймингом я бы еще поработал - https://github.com/tastyware/streaq

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

Чтож, пришло время подвести итоги моего 2ухмесячного тура по TDD. Краткие выводы - я не понимаю, как вообще писал код до этого😅

Основной мой тезис, что любая разработка УЖЕ ВЕДЕТСЯ ПО TDD, и мы этого не осознаем. Просто это Manual TDD. Как мы пишем код для решения задачи Х?

1) Изучаем задачу
2) Формируем требования к коду, который будет ее закрывать
3) Пишем код
4) Проверяем, что сформированные в П.2 требования выполняются (мануально)
5) Пишем тесты???

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

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

Если ты фиксируешь требования к новому коду через тесты, то

1) Ты гораздо лучше формируешь сами требования. Они превращаются из абстрактных хотелок в твоей голове в конкретный API с конкретными инвариантами. В итоге часто случается, что картинка API нового модуля из твоей головы, в процессе написания теста оказывается неверной - и рождается новый дизайн.

2) Тест является для тебя определенной ступенькой на пути к полной реализации (см. One Step Test), ниже которой ты не можешь провалиться. Ты как альпинист, который по мере поднятия на вершину, переносит страховочные крепления все выше и выше. Начиная с самого тривиального теста, ты докидываешь новые и новые проверки инвариантов без страха, что предыдущие отвалятся. Такое тестовое покрытие прямо в процессе дает коллосальное чувство спокойствия, позволяет держать меньше деталей в голове, и сконцентрироваться только на задаче, решаемой в эту секунду.

3) Если альпинист не может поставить страховку выше того места, где он находится, то в случае с тестами мы можем это сделать! (см Fake It). Красный тест - это цель, к которой натянута веревка - нам будет очень тяжело отклониться от нее. Наличие красного теста буквально за руку ведет нас к реализации функционала. Писать код становится в разы проще.

4) Скорость разработки также кардинально увеличивается. Запустить тест - это гораздо быстрее, чем мануально проверить выполнение логики. Если ты не пишешь все идеально с первой попытки, то такие проверки-перепроверки придется совершить N раз. Сложная логика также требует сложных мануальных манипуляций. Напиши тест! - он выполняется за 0.1 секунды.

Экстремальные адепты TDD даже юзают утилиты, которые сразу запускают тесты при изменении в любых файлах - https://pypi.org/project/pytest-watcher/

5) Наличие тестового покрытия на основные инварианты из коробки банально повышает качество итогового программного продукта. За него не нужно биться или "обеспечивать" - оно уже есть.

6 - бонусный пункт от меня) Написание тестов - отличный способ борьбы с прокрастинацией. Вот надо тебе съесть слона - и ты сидишь и думаешь, с какого бока к нему подступиться. Напиши тест, а лучше два (см. Триангуляция) - это уже будет маленький шажок на пути к ожидаемому результату. Или у тебя просто есть 15 минут между созвонами и ты физически не можешь воткнуть туда полноценное решение задачи - напиши тест! Это занимает 2 минуты, требует околонулевых мозговых затрат, зато приближает тебя к итоговой цели.

7 - бонусный пункт от меня) TDD идеально сочетается с AI-DD, т.к. подразумевает итеративные атомарные изменения кода, где у AI остатется мало пространства для галлюцинаций. А наличие тестов позволяет быстро отлавливать такие галлюцинации.

TDD - это не просто инструмент или конкретный подход. Это целая идеология. Ты можешь готовить ее множеством способов. Не нравится писать много юнит-тестов, т.к. фича слишком проста, чтобы тратить на это время? - увеличивай шаги, пиши высокоуровневые красные тесты (см Fake It, Obvious Implementation).

#TDD

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

Тема TDD показалась мне очень близкой и интересной, поэтому я выпущу еще 2 заметки - о цикле TDD и о конкретной моей практике его использования (с прикладными примерами). А пока - рекомендую всем и каждому почитать Кент Бека и понять, почему ему стоит хотя бы попробовать писать тесты вперед кода.

#TDD

Угадайте, кто снова будет спикером на PiterPy?🌚
Жду всех на свой доклад (неожиданно про FastStream)! Будем всем залом копаться в кишочках и проектировать фреймворк заново😅

https://piterpy.com/talks/6ccc5d2b87a9495a94dcf03ce3468f17

Как-то я несколько озадачен текущей ситуацией со спецификациями OpenAPI / AsyncAPI

С одной стороны - все запросы на поддержку MQTT и прочих вариантов транспорта в OpenAPI закрываются со словами "не очень понятно, как это сделать, юзайте AsyncAPI" - https://github.com/OAI/OpenAPI-Specification/issues/553#issuecomment-620477276

С другой стороны - AsyncAPI стемится быть настолько generic, чтобы дать возможность описать все, что угодно - в том числе и HTTP. Однако, настолько широкая специализация делает ее слишком вербозной и недостаточно удобной для написания руками - https://github.com/OAI/OpenAPI-Specification/issues/55#issuecomment-1052572818

Казалось бы - проблемы нет? Пишем AsyncAPI спеку на асинхронные сервисы и OpenAPI - на HTTP. Но все упирается в то, что HTTP сервисы часто имеют поддержку SSE / Websockets, которую сейчас нельзя выразить в рамках OpenAPI (и не предвидится возможным). В итоге, чтобы описать один сервис, нам нужно иметь сразу две спецификации? - звучит сомнительно.

У автора AsyncAPI есть видение - он предлагает ссылаться из AsyncAPI прямо на OpenAPI - https://github.com/OAI/OpenAPI-Specification/issues/55#issuecomment-1057220490

Как будто бы это единственный вариант, но насколько он рабочий?

В моем представлении, если мы хотим максимально полное описание нашего сервиса в спецификации - нужно юзать AsyncAPI . C Code-first инструментами (типа FastStream) тут даже нет проблемы - их вербозность никак не мешает сгенерировать валидную спеку из кода, которая красиво отрисуется в HTML. А что делать Specification-first страдальцам? Писать руками AsyncAPI для HTTP - сомнительное удовольствие...

Я еще поиграюсь с тем, как работают референсы из AsyncAPI на OpenAPI - в этом может быть ответ, но пока будущее спецификаций туманно

Время пришло и проект Propan переходит в публичный архив - https://github.com/Lancetnik/Propan

Хотя работы над ним не велись с момента релиза FastStream, но все равно как-то грустно отправлять свое авторское детище в дальний ящик. Чтож, посмотрим, какие еще интересные проекты нас ждут в будущем - пока я сосредоточусь на развитии FastStream и FastDepends. Авантюра с Propan зашла значительно дальше, чем я ее планировал😅

По многочисленным заявкам немногочисленного Андрея попытаюсь изложить практические аспекты идологии TDD

Коротенько не получилось, поэтому вот ссылка на фул.

Краткие тезисы для ЛЛ:

1) Цикл TDD: красный тест – зеленый тест – рефакторинг, повторяем
2) Держим фокус решаемой задачи. Красный тест должен быть один. Все мысли вне скоупа этого теста – на бумажку, вернемся к ним на следующем витке цикла
3) Движемся вперед – микроскопическими шагами. Пишем тупые реализации, говнокодим по полной – лишь бы тест стал зеленым. Рефачим уже на этапе "рефакторинг", либо даже на следующем витке цикла.
4) Чувствуешь силы – ускоряйся, пиши реализации не так тупо. Знаешь как правильно – пиши правильно сразу. Но чуть какие проблемы – переходим на "пониженную передачу"
5) Тесты проверяют наши ожидания и формируют интерфейсы будущего кода. Проверять детали реализации они НЕ ДОЛЖНЫ!

https://telegra.ph/Ideologiya-TDD-03-07

В следующий раз приведу реальные примеры уже из реального проекта

#TDD

Никита Соболев запустил новый канал, куда мейнтейнеры могут дропать Good First Issues.

Если вы ищете возможность контрибутить в CPython, FastStream, dishka, taskiq и другие OSS проекты – обязательно подпишитесь!

Я совершенно точно буду дропать туда простые/интересные задачки! Уже совсем скоро будет первый дроп😅

https://t.me/opensource_findings_python/6

Хо-хо-хо, нашел для вас (и себя) топ-контент. Это целое мок-интервью на позицию CTO.

Думаю, всем, интересно узнать, что требуют от руководителей такого уровня?) А кому-то может быть даже пригодится🌚

В общем, пошли смотреть

https://youtu.be/UAuHACFTw5E?si=q4ziHLA79NbRV26_

#карьера

Наконец-то дочитал самую базированную в современных ИТ-реалиях книгу – Цель. Еще в 1984 году Голдратт опубликовал свою теорию ограничений в виде художественного романа. Эта методология выросла как теоретическая база над практическим чудом Генри Форда (1920е) и Тайити Оно (1960е). Именно теория ограничений была заложена в основу современных методик аля Scrum, Canban, Agile, Devops и тд.

Забавно, что перед этим я как раз прочитал Проект Феникс, который явяется буквально современным рерайтом "Цели", но с приземлением на ИТ (что дает нам в итоге DevOps практики). Но Феникс оказался слишком практическим для меня, поэтому саму идеологическую суть получилось ухватить только при обращении к оригиналу.

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

"Проток" – это количество полезного действия системы в единицу времени (для производства – деньги, для ИТ – фичи). При перекладывании на ИТ это все выливается в идею, что нет смысла мерить кто быстрее запилит функционал – фронт за 2 дня или бек за 4, если фича осядет в тестировании на 3 недели. В итоге все должно выкручиваться в угоду Time To Market.

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

А вот тут самое интересное. Бутылочным горлышком в случае ИТ может быть:
– архитектор-диктатор, без совета с которым не реализуется ни одна система
– тимлид-контролер, без ревью которого катиться нельзя, а снизойдет он до тебя через неделю
– синьорный синьор. Только он знает как работает система и 90% тасок может выполнить только он, а обучать других членов команды у него нет времени
– аналитик. Идея фичи есть, а на ТЗ разработке его еще никто не перевел.
– хер знает что еще

Основная мысль в том, что работа до 90% времени выполнения может дожидаться чего-то еще (ручки на беке еще не подвезли – фронт курит, ждем ревью по 2 недели, когда там devops'ры нам стенд запилят?). Если такое происходит – это является ограничением в рабочем процессе, которое нужно устранять.

В общем, рекомендую всем прочитать и "Цель", и "Проект Феникс". Можно в произвольном порядке, но для понимания, за что мы тут все воюем – точно стоит)

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

Черт, у нас тут новый HTTP QUERY метод, оказывается, нарисовался. И даже тулзы потихоньку запиливают его поддержку...
Что он делает – не знаю, зачем нужен – пока не понял. Но плотно держу вас в курсе

https://github.com/fastapi/fastapi/issues/12965

UPD: черт, да это же GET с телом🤯

https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html

Класс, с выходом Pydantic 2.11 в FastAPI сломалась рисовалка OpenAPI Payload для случая использования descriminator. А это на секундочку любимая игрушка всех Rust-водов и прочих любителей алгебраических типов данных.

Казалось бы, проблема в Pydantic, т.к. они нарушают обратную совместимость в минорном релизе, но нет – FastAPI опирается на непубличные части Pydantic, где обратная совместимость не гарантируется, да еще и использует их не совсем верно (не так, как предполагали в pydantic) – отсюда и проблема.

К слову, фиксить их не планируют, т.к. это нарушит совместимость с PydanticV1.

https://github.com/fastapi/fastapi/pull/13314

В общем, так и живем😢 А мне пока пришлось воткнуть очередной switch для "особого" поведения тестов с FastAPI

Наконец-то мой доклад про FastStream на PiterPy 2024 выложили в открытый доступ! Я уже шарил это ссылку, но всем, кто не видел – обязательно стоит посмотреть. А еще скинуть всем сомневающимся – в рамках доклада я разбираю фичи FastStream, которые нужны в почти любом современно сервисе.

https://www.youtube.com/watch?v=33bugga930w&t=1s&ab_channel=PiterPy

Кстати, на этом PiterPy я снова буду расскзаывать про FastStream – но уже про кишочки и в интерактивном с залом режиме. Так что обязательно приходите!

https://piterpy.com/talks/6ccc5d2b87a9495a94dcf03ce3468f17

#доклад

У меня для вас есть большая и важная новость! FastStream – все😢

Точнее airt/faststream – все. Теперь у нас будет ag2ai/faststream!

Дело в том, что компания AG2 (AutoGen2)

– https://ag2.ai/
– https://github.com/ag2ai

Выкупила Airt (которым и принадлежал FastStream) вместе со всеми сотрудниками и проектами. Теперь мы все большой и дружной командой будем трудиться над светлым мультиагентным будущим!

Long story short: жил-был фреймворк microsoft/autogen и горя не знал. Но потом его главный идеолог, разработчик и CPO разошелся в видении будущего проекта с микромягкими – и пошел делать свой стартап (AG2, ага), дернув за собой половину своей же команды из Microsoft, пару ребят из OpenAI и Airt на сдачу прихватил.

Что это значит для сообщества? – для FastStream теперь открыта дорога в "большую лигу". Инструменты AG2 во всю используются в компаниях MAANG уровня, а я сейчас как раз занимаюсь внедрением асинхронного транспорта на базе FastStream (и NATS) в ядро AG2.

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

Но, к сожалению, мне самому тоже придется в ключится в движню над другими проектами компании и около – ag2, MCP Protocol, ну и самим FastStream (естественно).

Такой переход не обошелся без некой доли корпоративного булшита от микромягких (например, всем контрибуторам нужно подписать CLA), но расширение комьюнити пользователей + поддержка более крупной компании с сильными техническими специалистами – это ведь круто, правда?😅

Посмотрел вот этот вот классный доклад и снова убедился, что разработка сплошь и рядом состоит из трейдофов, на которые постоянно приходится идти – https://youtu.be/wi6h9ox1wwM?si=lMNIw2G7J8g4X2s6

Серебряной пули как всегда нет, а даже дефолтные проверенные решения таят много опасностей.

Например, обычная limit-offset (paging) пагинация очень непроизводительна. Дело в том, что select(Model).order_by(Model.field).offset(10).limit(10) внутри БД не берет "10 записей" магическим образом, а получают всю выборку со страницы, фильтрует ее, сортирует, а потом итерируется с первой записи полученной подвыборки до позиции offset. И только после чего берет limit записей. Как вы понимаете, такое поведение на больших данных оооочень медленное. И это совсем не то, что мы ожидаем.

Как решение придумали Keyset пагинацию. Суть очень простая – мы прям с фронта передаем индекс последней записи, откуда выдавать новую порцию select(Model).where(Model.id > last_id).limit(10). Но такую пагинацию уже надо готовить с учетом специфики ваших данных, типовых запросов к приложению и тд. Как минимум без правильно сваренных индексов ее не реализуешь. Но работает она действительно быстро и не деградирует по мере продвижения к концу выборки.

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

Вот и получается, что мы выбираем между

Offset Pagination
+ легко реализовать
+ доступ к произвольной странице
- сильно деградирует по мере продвижения в глубину

Keyset Pagination
+ работает быстро вне зависимости от раздела
- сложнее реализовать
- не поддерживает произвольный доступ в принципе (infinite scroll теперь наш лучший друг)

А казалось бы – ЭТО ПРОСТО ПАГИНАЦИЯ! Ладно еще трейдофы вокруг JWT и Session-based авторизации, но тут-то все было просто😢

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

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

Поэтому сейчас я сел перечитывать эту великолепную книгу (а заодно и Талеба, Канемана и Клира по всей видимости). А заодно вдохновился всеми "правильными" практиками чтения книг – и стал вести конспекты в Obsidian. Чтобы через 5 лет не перечитывать все заново, а просто подглядеть в конспект.

В общем, ближайшее время буду спамить сюда инсайтами по эффективности из конспектов с моим осмыслением🌚

Инсайт дня от Дорофеева – "заставлялка себя" – тоже антихрупка. Она тратится на бытовые дела, занятия спортом, борьбу с соцсетями, видосиками и сериальчиками. А самое главное – она нужна, чтобы делать дела, которые очень хочется прокрастинировать. Хорошая новость в том, что она тренируется. Именно поэтому один из первых советов по эффективности – займись спортом. Т.е. буквально "иди тренируй заставлялку". Плохая новость – ее можно сорвать. Как мышцы, которым нужен отдых, так и заставлялке нужно время, чтобы восстановиться и окрепнуть для новых нагрузок. Именно тут и срывается большая часть вкатунов в эффективность – нельзя записать 500 дел, а потом разом заставить себя их все выполнить. После этого твоя заставлялка откажет – и ты еще полгода будешь лежать бревном.

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

Оп, вот такие активности от хабра мне нравятся! Надеюсь на большое количество ламповых статей об OSS в следующем месяце – с удовольствием буду заходить почитывать)

Ну и, конечно же, сам поучаствую в конкурсе!

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

https://habr.com/ru/specials/898552/

Я нашел лучшую лицензию для Open Source ever!

https://en.wikipedia.org/wiki/Beerware

Лицензия гласит, что вы обязаны угостить автора используемого вами проекта пивом, если вы когда-либо встретитесь. Жаль, менять лицензию на FastStream уже поздно😢

Инсайт дня от Дорофеева

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

Буквально основная идея MVP, которая выросла из метода рационального фланера, сформулированного Талебом в "Антихрупкости".

Очень часто мы грешим тем, что придумываем какое-то идеальное решение проблемы сидя на берегу, а потом ревностно следуем ему. Проблема в том, что сидя на берегу мы не имеем достаточно информации для принятия оптимального решения. Максимум – мы можем построить приблизительный набор шагов и наметить промежуточные цели. Но мы же строим ПЛАН и в таком случае:

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

2) Мы превращаем выполнение задачи в слона, которого больше хочется прокрастинировать, чем реализовывать

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

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

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

И веселая иллюстрация из книги в догонку