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

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

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

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

Только посмотрите, как 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. Изначально я вообще не планировал сюда что-то постить кроме этого, но потом что-то пошло не так...