Класс, с выходом 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) Четко продуманный набор действий дает нам иллюзию контроля над неопределенностью – и мы перестаем закладываться на непредвиденные обстоятельства, которые обязательно случатся по ходу следования плану. И тут с нами играет злую шутку эффект выпрямления сроков

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

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

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

Только посмотрите, как FastStream замечательно смотрится в документации FastAPI!

К слову, это может стать правдой, если Tiangolo не пошлет нас нахер😅

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

В общем, дискуссия под PR может получится знатной

Недавно размышлял о том, чем же отличается хороший API библиотеки от плохого. Пытался сравнить свои субъективные ощущения от Litestar и FastAPI. Почему Litestar мне не нравится, и в чем феномен успеха FastAPI при всем его минимализме?

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

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

Т.е. задача хорошего продукта (а API – это тоже продукт) – закрыть потребность пользователя минимально необходимым набор фич. Но очень многие это не понимают. Часто сталкиваюсь с утверждением "больше = лучше". Давайте воткнем больше информации в UI, давайте запилим 5 способов сделать то же самое. И в итоге получаются монстры, которыми просто невозможно пользоваться. Чтобы этого не случилось как раз и нужны UX / DX специалисты.

Но как закрыть потребность меньшим набором фич, чем у конкурентов? Тут дело в СИНЕРГИИ

Хороший API – это синергирующий API.

Представим, что у нас есть фича X1, которая закрывает потребность Y1. И фича X2, закрывающаю Y2.

Тогда синергиющий API дает нам следующую формулу:

X1 + X2 = Y1 + Y2 + Y3 (сумма двух фич позволяет закрыть потребность Y3, которую фичи не закрывают по отдельности).

Плохой дизайн – это когда сумма X1 + X2 = Y1 + Y2. Т.е. на каждую потребность пользователя у нас есть своя фича, которую пользователю нужно освоить. Именно этим мне и не нравится Litestar – там слишком много уникальных механизмов и зон ответственности, куда он лезет.

Ужасный дизайн – когда фича X1 = 0.8Y1. Т.е фича даже не закрывает кейс, ради которого была создана, а ломается на краевых ситуациях и вынуждает костылить.

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

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

1. Эффект мегакреативности - мы генерируем множество идей по кругу, т.к. они постоянно вылетают у нас из головы. Надо было фиксировать, что мы там надумали
2. Эффект дырявого стека - мы держим в фокусе только последние задачи, старые просто вытесняются. Надо было фиксировать
3. Нелинейная зависимость времени от сложности - сложные задачи человек более склонен прокрастинировать (задача на 2 часа делается за 2 часа, задача на 6 часов делается за 2 дня). Надо формулировать задачи проще и делать понятными частями
4. Неэкономия масштаба - мыслетопливо тратится на удержание списка дел в голове, а не его выполнение. Больше список - больше "утечек". Надо выгружать память на внешние носители и концентрироваться на работе, а не списке дел
5. Выпрямление сроков - отклонения от сроков всегда происходят "вверх". Люди прокрастинируют время, отложенное "про запас". А когда что-то идет не так, сроки срываются, т.к. "про запаса" больше нет. Надо было делать по чуть-чуть сразу
6. Бракованный день - мы считаем, что все наши задачи требуют много времени и поэтому прокрасинируем недостаточно большие отрезки, когда "тут я ничего не успею сделать". А надо было формулировать задачи так, чтобы они укладывались в пятиминутки.

Отсюда же и следуют основные рецепты продуктивности – не держим в голове лишнее, выгружаем все-все во внешнюю систему (которой мы ДОВЕРЯЕМ и ПОЛЬЗУЕМСЯ!). Ну и делаем... хотя бы по чуть-чуть, но постоянно.

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

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

Самый главный инсайт из книги Дорофеева для меня – это как раз история про то, что большие дела действительно можно делать небольшими подходами. Например, сам Дорофеев начинал писать свою книгу подходами по 30 минут 2 раза в неделю (и за пару месяцев до окончания перешел на ежедневную работу над книгой). То, что буквально 20-30 минутные подходы к "слону" дают результат на долгосроке – это, конечно, логично. Но моя психика просто отказывается это воспринимать... Всегда хочется найти этак часа 3-6 одним куском и "ух, как поработаю". А таких кусков нет – и ты прокрастинируешь все 20-40минутные "огрызки"😢

А еще – мы все неэффективны. Даже те, кто сильно старается. Даже те, кто учит быть эффективными других. Пресловутые "Джедайские техники" (книга об эффективности) были написаны с 3го раза. Так как первые 2 загубила прокрастинация🤷

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

Всем привет! У меня неожиданная новость – Вячеслав ("Программирование и иже с ним")

– https://www.youtube.com/@programming_etc
– https://www.twitch.tv/vyachek_proger
– @pythons_boys

Пригласил меня на стримчик в

Это воскресенье 27 апреля, в 13:00 МСК – Twitch

Пообщаться за программирование и иже с ним. Планируется неформальные ламповые посиделки на часик-другой-третий (возможно с пивом), где будем общаться на темы ИТ и отвечать на вопросики из чата (но вопросы из донатов в приоритете). Так что, всех заинтересованных – welcome! Не забудьте добавить напоминалку в календарь🌚

Вячеслав уже показывал на своих стримах работу с FastStream в реальных приложения, так что я тоже не мог упустить возможность пообщаться с реальным пользователем своего фреймворка😅

Я все пробовал-пробовал для себя uv, чтобы собрать больше фидбека, набить больше шишек и рассказать вам о своих впечатлениях о проекте.

Но все нюансы разобрали уже без меня и гораздо лучше: https://habr.com/ru/companies/otus/articles/903578/

Если кому-то все еще интересно мое мнение на тему uv – он просто работает. Причем работает великолепно. Быстрее, выше, сильнее pip. Самый топ для меня, что я могу воткнуть uv в любой проект через uv pip install – и он поставит все 100500 зависимостей за пару секунд. Ну и бустрапинг чистого проекта тоже приятный.

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

Обновил описание канала. А то как будто на него натыкаются люди, которые не знают, куда попали... А тут дичь полным ходом без описания даже😅

Как думаете, стоит делать еще навигацию по темам? Где TDD обсуждали, где продуктивность, где ссылки на выступления и тд

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

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

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

Если приложить эту идею к карьерным грейдами, то мы получаем следующую картину:

Переходы с грейда на грейд обусловлены выполнением задач совершенного разного масштаба и степени неопределенности

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

Переход с грейда на грейд зависит от твоей способности выполнять задачи нового масштаба и более высокой степени неопределенности.

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

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

Напоследок приведу пример задач разного уровня:

– "Закрой багу Х"
1) воспроизведи проблему
2) напиши красный тест для стабильного воспроизведения
3) локализуй проблему
4) реши проблему (может быть декомпозирована еще)
5) проверь, что остальные тесты не сломались
6) пуш, ревью, релиз, профит

– "Реализуй поиск в нашем маркетплейсе" - как???
– "Повысь конверсию поисковой выдачи" - чего???
– "Повысь качество поисковой выдачи" - что значит "улучшить качество" вообще!?
– "Повысь размер среднего чека / количество успешно доведенных до продажи сессий" - WTF!?

Естественно, люди, способные решать задачи из списка со звездочкой, значительно ценнее для бизнеса. Что выражается в их позиции, зоне ответственности и денежной компенсации.

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

Что как, заканчиваем на этом с продуктивностью и возвращаемся к программированию?😅 А то я тут уже следующую книгу перечитывать начал. Да и по Дорофееву хотелось бы еще разобрать основные проблемы с продуктивностью.

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

Очень классно и душевно пообщались с Вячеславом! Про OpenSource почти не было, но классно поговорили за ИТ, путь в разработке, разработчиков / программистов, выгорание и многое-многое другое. Хотя по итогу 3 часа даже как будто мало😅 Надеюсь, экспромт удался

Запись можно посмотреть на youtube

Звук немного шакалит (микрофон я уже заказал, на днях приедет), прошу прощения😢

Вот тут я упоминал эффект синергии для продуктовых фич (и пользовательского API как продукта). А теперь давайте попробуем взять правило Парето, концепцию T-shape, обучения и синергии – и скрестим все вмести.

Допустим, у нас есть знание x, принадлежащее области деятельности X. Допустим, это знание соответсвует правилу Парето и 20% знаний позволяет закрывать 80% задач из этой области. Или, если коротко:

∃x∈X: 0.2x → 0.8X, x → X

Тогда, возьмем две такие области знаний и изучим их обе на 20%:

0.2x + 0.2y = 0.8X + 0.8Y + N,
где N∈[0, 1) - эффект синергии знаний x и y

А теперь давайте вычтем наше получившееся уравнение из следующего базиса

x = X

Получаем что-то такое

x - 0.2x - 0.2y = X - 0.8X - 0.8Y - N
Или
0.8x - 0.2y = 0.2X - 0.8Y - N

Теперь, если считать скорость изучения знаний x и y сопоставимой, то мы можем произвести следующую замену: x = y = t (время изучения).
И получим

0.6t = 0.2X - 0.8Y - N
Или
0.2X = 0.8Y + N + 0.6t

Получается, что не слишком глубокое (чисто по правило Парето) изучение разных синергирующих областей дает вам существенный буст как в рамках объема накопления знаний, так и возможного поля действий и решаемых задач.

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

Но очевидно, что поверхностное изучение смежных тем позволит вам значительно быстрее (и за меньшие трудозатраты) расширить базу доступных вам знаний и круг решаемых вами задач. В этом и есть концепция T-Shape.

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

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

Ура-ура-ура! Работа от Astral над новым mypy на Rust кипит!
Уже есть плейграунд, где можно с ним поиграться

https://playknot.ruff.rs/

Пысы: ссылку стащил в @cpython_notes

На самом деле, это прям та штука, которую я больше всего жду в экосистеме Python сейчас (ну и нормальный web-фреймворк, ага)

Совершенно случайно наткнулся на грейдовку Avito, которая лежит в публичном доступе на гите:

https://github.com/avito-tech/playbook/blob/master/developer-profile.md

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

Лично я себя оценил где-то между E6 и E8, что как раз и получается E7 в среднем (но на деле, конечно, ниже)🌚 Anyway, точную калибровку сам себе ты провести не можешь, да и не важно это на самом деле.

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

UPD:
Статья о грейдировании KTS – https://habr.com/ru/companies/kts/articles/862348/
Подкаст Podlodka о грейдах в F(M)AANG – https://www.youtube.com/watch?v=zzuOvQzerFk&ab_channel=Podlodka

#карьера