Как же это хорошо! Нашел целую хвалебную оду YAML формату. С каждого, кто так же любит YAML – лайк, кто не любит – два😄

https://noyaml.com/

А если серьезно, YAML имеет оооочень много подводных камней и проблем, только часть из которых описана на данном ресурсе. К счастью, у меня пока ни разу не выстреливали баги с YAML. Может быть это потому что я о них знаю, может быть – слишком мало работал с ним. Но факт остается фактом – с этой штукой нужно быть аккуратным.

К слову, в Python есть замечательная либа, которая позволит вам чуть более безопасно парсить ямлики – https://github.com/crdoconnor/strictyaml

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

А еще прилагаю спец выпуск про языки конфигурации моего любимого подкаста: https://podlodka.io/323

Там проблемам YAML уделено достаточно времени)

Вот тут я уже развивал мысли про нейроининтерфейсы и AI-IDE. Сейчас же появились какие-то подтверждения, что работа в этом направлении ведется.

Не знаю, насколько новость достоверная, но прогресс идет и нам нужно адаптироваться под новые реалии

https://t.me/PushEnter/9211

В общем, с интересом ждем, что нас ждет уже в ближайшие 5-10 лет

Так и посту­пай, мой Луци­лий! Отво­юй себя для себя само­го, бере­ги и копи вре­мя, кото­рое преж­де у тебя отни­ма­ли или кра­ли, кото­рое зря про­хо­ди­ло. Сам убедись в том, что я пишу прав­ду: часть вре­ме­ни у нас отби­ра­ют силой, часть похи­ща­ют, часть уте­ка­ет впу­стую. Но позор­нее всех поте­ря по нашей соб­ст­вен­ной небреж­но­сти. Вглядись-ка при­сталь­ней: ведь наи­боль­шую часть жиз­ни тра­тим мы на дур­ные дела, нема­лую — на без­де­лье, и всю жизнь — не на те дела, что нуж­но.
Ука­жешь ли ты мне тако­го, кто ценил бы вре­мя, кто знал бы, чего сто­ит день, кто пони­мал бы, что уми­ра­ет с каж­дым часом? В том-то и беда наша, что смерть мы видим впе­ре­ди; а бо́льшая часть ее у нас за пле­ча­ми, — ведь сколь­ко лет жиз­ни мину­ло, все при­над­ле­жат смер­ти. Посту­пай же так, мой Луци­лий, как ты мне пишешь: не упус­кай ни часу. Удер­жишь в руках сего­дняш­ний день — мень­ше будешь зави­сеть от зав­траш­не­го. Не то, пока будешь откла­ды­вать, вся жизнь и про­мчит­ся.
Все у нас, Луци­лий, чужое, одно лишь вре­мя наше. Толь­ко вре­мя, усколь­заю­щее и теку­чее, дала нам во вла­де­нье при­ро­да, но и его кто хочет, тот и отни­ма­ет. Смерт­ные же глу­пы: полу­чив что-нибудь ничтож­ное, деше­вое и навер­ня­ка лег­ко воз­ме­сти­мое, они поз­во­ля­ют предъ­яв­лять себе счет; а вот те, кому уде­ли­ли вре­мя, не счи­та­ют себя долж­ни­ка­ми, хотя един­ст­вен­но вре­ме­ни и не воз­вра­тит даже знаю­щий бла­го­дар­ность.

Сенека. "НРАВСТВЕННЫЕ ПИСЬМА К ЛУЦИЛИЮ" - 62-64г н.э.

Смотри-ка, в Риме тоже шарили за #продуктивность

Как отправить жопу мейнтейнера в космос. Краткий гайд от вайбкодеров.

У нас тут first-time-contributor притащил в FastStream прикольную фичу – поддержку HTTP в AsyncAPI.

Сначала код выглядел достаточно чистенько, но с косяками. Я подробно описывал, что поправить – в несколько итераций. В общем, обычный процесс ревью. В итоге пришли к финальной версии, где все норм. Я пошел проверять и кое-что править (а то я и так чувака заебал своими правками) – и оказалось, что его правки в AsyncAPI схему тупо не соответствуют спецификации – он их сам придумал. Схема не валидна и не рисуется...

А вероятнее даже их придумал не он, а LLM. У меня сейчас складывается картинка, что чувак просто закинул кодбазу + Issue в LLM, а вывод закинул как PR. Я же ревьюил код нейронки, а он просто кидал мои комменты обратно в LLM. А в итоге все вообще превратилось в тыкву, которая с самого начала была чьими-то галлюцинациями.

Ебаные блять вайб-фармеры-коммитов-в-OpenSource. Я трачу свое время на сопровождение PR, а он тупо в LLM все закидывает

https://github.com/ag2ai/faststream/pull/2142

Fun Fact: а вы знали, что FastStream добавлен в список RabbitMQ клиентов прямо у них в документации?

https://www.rabbitmq.com/client-libraries/devtools

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

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

Самый важный шаг на пути продуктивности – самодиагностика. Нельзя помочь тому, кто не знает, что ему нужна помощь. Если у вас нет петли обратной связи от организма и нервной системы, то вы в заднице – загоняя себя бесконечно вы просто окажетесь в состоянии выгорания, откуда выбраться значительно сложнее, чем предотвратить. Хорошая новость том, что выгорание – это отличный маркер, что нужно что-то менять. Никакая самодиагностика тут уже не нужна. Как раз мой случай😅

Когда я понял, что нужно что-то менять, я решил обратиться к книгам (Джедайские техники и Атомные привычки), которые я уже когда-то читал. Просто интуитивно посчитал, что они мне помогут – так и случилось. Знания из книг помогли мне взглянуть на свою ситуацию со стороны и понять, что нужно менять. А менять нужно было много😢

Основные проблемы, которые я для себя выделил:
– у меня есть система задач, но я ею не пользуюсь
– трачу очень много времени впустую (телеграм, чатики, ютуб, сериалы)
– прокрастинирую многие задачи
– постоянное чувство усталости, разлада и бардака по всем фронтам
– фрустрация из-за незакрытых целей

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

Спойлер: буквально за 2 недели я смог выбраться из своего загнанного состояния (в котором я находился с ноября), сдвинул с мертвой точки кучу задач, что висело надо мной месяцами и даже что-то уже закрыл.

Давайте сегодня расскажу вам о важности системы.

Суть в том, что на удержание информации в голове тратится ресурса не сильно меньше, чем на полезную деятельность. Если вы держите в голове список из 100 дел на ближайшие 2 месяц – вы больше ничего не сможете сделать🤷 Решение тут простое: нужно вынести весь этот список во внешний источник (об этом говорят и Дорофеев, и Хартман, и много-много кто еще). Что я благополучно и делаю уже последние 5 лет – весь мой список всегда на бумаге со мной. Писать-то я пишу.... Но так сложилось, что последний год я слишком занят, чтобы туда смотреть... В итоге, я просто записываю туда все-все-все, а потом все также держу в голове весь список на день (или больше), а вечером синхронизирую выполненное со списком. Вроде как даже работает – задачи в список вносятся, вечером – вычеркиваются... Но подвох вы поняли😅 А еще я по какой-то неведомой причине вел список задач только на +1 день вперед. А вот информацию о том, что у меня концерт через 2 недели держал в голове😂

Поэтому вот список изменений, которые я ввел в свою систему в первую очередь:

– часто смотрю в список. Буквально каждый раз, когда возникает мысль "а что делать следующим". Это должно быть на уровне привычки. А еще составляю мини-списки (как список покупок в кармане) на ближайшие пару часов и иду за новым в большой список, когда мини кончился.

– заношу в список вообще все. Даже самое мелкое, что раньше считал слишком мелким для внесения в список. Бумага стерпит, а голова мне еще пригодится.

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

– НАЧАЛ ПОЛЬЗОВАТЬСЯ КАЛЕНДАРЕМ. Заношу туда любые задачи, связанные со временем – созвоны, поездки, посиделки с друзьями на след выходных, концерты, музеи, кино, занятия с менти, конференции и тд и тп. Если событие подразумевает какую-то подготовку, то я заранее накидаю россыпью задач на какие-то дни на всем промежутке до этого события. Например, если у меня выступление на конфе, то за 3 недели до конфы я накину себе задач на подготовку доклада 2 раза в неделю. Да, поэтому я вас достаю о конкретных датах.

– прикрепляю к событию в календаре все необходимые артефакты. Если это "доставка СДЕК" на 25ое, то я закину туда код отправления, код заказа в магазине и сайт магазина. Если это квартирник с друзьями – то список покупок и код от домофона. Если это бухич в баре – точку на карте и на чье имя бронь. Теперь я всегда знаю, где искать инфу по событию. А голова чиста😊

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

– активно пользуюсь отложенными сообщениями. Обычно мне приходит в голову, что нужно "уточнить у Х завтра У". Зачем писать это в ежедневник, если можно написать отложенку прямо сейчас?

– записываю задачи для обезьянки. Я не должен думать ни секунды, глядя в список. Взял пункт – пошел делать. Очень часто такое составление формулировок приводит к тому, что первый шаг можно сделать уже сейчас, а не вносить в список (например, написать отложенку)

– упрощаю формулировки подвисших задач до первого шага. Не "сделать фичу" (это не очень понятно), а "уточнить требования у продакта" (ага, попались! Что за требования? Тут тоже думать надо) – "мы можем сделать Х или У в зависимости от ожиданий пользователя. Обсудить это с продактом и реализовать выбранный вариант" – о, так мб мне сразу ему написать / кинуть встречку? Смотри-ка, процесс пошел

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

– не пытаюсь запомнить, что меня просят. Совсем. Записываю + прошу напомнить. Так надежнее

Это только часть изменений, который я внес. Также было много изменений, которые направлены на работу с мотивацией, устранением других энергетических паразитов, улучшение самочувствия. Но внедрение этих пунктов позволило мне стряхнуть тяжесть нависших надо мной задач, перестать трястись над ними, и начать ДЕЛАТЬ!

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

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

Забавно, я стартанул этот канал в декабре 2024го без какого-либо плана на его развитие.
Первое время я вообще хотел кидать сюда только анонсы релизов FastStream и какие-то новости о нем. Но быстро оказалось, что мне есть чем еще с вами поделиться😅

Anyway, заниматься развитием канала я все еще не думал, но на всякий случай поставил годовую цель "набрать 400 подписчиков", т.к. ее можно было добиться на фоне. Небольшая цель, которая держит минимальный уровень мотивации хоть что-то сюда писать. Чтож, цель достигнута, поэтому постов до конца года больше не будет🎉🥳

А если серьезно – цели на развитие у меня все еще нет, но есть путь. Оказалось, что мотивации писать сюда у меня достаточно и без всяких целей, поэтому в ближайшее время ждите новые посты🌚 С меня уже стребовали темы:
– закрыть TDD практическими примерами
– развитие продукта и OpenSource как продукта
– еще больше продуктивности
– больше разработки

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

В общем, спасибо за ваш позитивный фидбек! Остаюсь на связи

И снова всем привет! Как вы знаете, я очень люблю две вещи: OpenSource и душнить. Про OpenSource мне рассказывать надоело, поэтому на митапе @nkhitrov_blog (уже в этот четверг 5го июня, Москва) я буду с САМЫМ ДУШНЫМ ДОКЛАДОМ ПРО ПИВО!🍺🍻

Митап уже на этой неделе, да и количество мест ограничено – поэтому быстрее регистрироваться!

https://peer2beer.timepad.ru/event/3394193/

Как и следовало ожидать, мне пришел официальный отказ😢

https://github.com/asyncapi/community/pull/1608#issuecomment-2936149623

Неофициальный, к слову, тоже пришел: Lukasz (Executive Director of AsyncAPI) пришел аж ко мне в личную телегу, мы долго и плодотворно обсуждали мой вклад в AsyncAPI, то как они являются заложниками политики Linux Foundation, как мы сможем коллаборировать в текущих условиях, и как мы вернемся к этом диалогу позже.

На самом деле – впечатления очень позитивные, несмотря на отказ. Ребята демеджконтролят как надо. Могли прислать регулярную корпоративную отбивку, а тут – человеческое лицо, полноценная коммуникация, признание заслуг, планы на совместную работу (я предложил, как всегда😅).

Из хорошего – мы договорились о том, что мейнтейнер AsyncAPI React component поможет мне реализовать некоторые прикольные планы по веб-представлению доки, а еще поможет актуализировать FastStream по поддерживаемым фичам!

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

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

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

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

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

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

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!? Ох уж эти вайбкодеры...

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

БЫЛО

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

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

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

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