Вот запись. Как обычно, какое-то время рендериться будет.

https://youtu.be/2GpRSQN0lTE

Через 10 минут стартану вторую серию про data-star. Скорее 1.5, потому что придётся наверстать то, что в прошлый раз не записалось. Но потом продолжу эксперименты дальше.

Вторая часть приключений с data-star. Напоминает о том, что не попало на "плёнку" в прошлый раз по прихоти OBS.

https://youtu.be/1N9V3gZhR60

По итогам экспериментов могу сказать, что data-star выглядит наименее магично по сравнению с HTMX и прочими turbolinks. Хорошо использовать такие штуки, когда хочешь иметь максимум контроля.

Отдельно понравилось то, что в data-star приходится думать о том, как происходит восстановление состояния view при переподключении SSE, которое происходит, например, при деактивации вкладки в браузере — вы, ведь, хотите экономить батарейку и трафик 😉

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

Эх, OpenAI купили Astral. Это прям для меня печаль на ближайшие дни...

With Astral joining OpenAI, we’ll continue to support these open source projects while exploring ways they can work more seamlessly with Codex—enabling AI systems to operate across the full Python development workflow.

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

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

Сначала Anthropic купили bun, теперь эта покупка. OpenSource не зарабатывает и оказывается в активах гигантов. А там уже все эти заявления про "в дальнейшем будет поддерживать разработку" проверку временем не проходят.

Сегодня постримлю пораньше — через 10 минут, в 11:00 GMT+4

Планирую поковырять prek — новый blazingly fast мультитул для Git hooks — в связке с poe, uv, ruff.

Кажется, получилось неплохо! Заодно дал некоторую вводную про то, что же за вещь такая — эти наши Git hooks.

https://youtu.be/oeca7fvjDf4

just a little thingy in #tic80

Внимание: там всё мигает, имейте в виду, если для вас это критично

Через 5 мин стартану стрим про cozy programming & stuff

Вот запись моего сегодняшнего монолога про Cozy Programming:

https://youtu.be/QVmCLRrunoc

В программе:

- Ностальгия по BASIC (тут про такое уже было)
- PICO-8, про который тут есть и в количествах
- TIC-80 — его открытый аналог, см анимацию выше
- Железки вроде GameShell и PlayDate (про обе писал, смотрите ссылки)
- DrRacket как уютный способ порисовать картинки кодом (пост про это — тут)

Также коснулся особенностей графики ZX Spectrum, палитровой анимации, вспомнил про Amiga Workbench — всё это вскользь, но в контексте.

Стартанул стрим по моему сетапу для Clojure по просьбам трудящихся

Вот запись: https://youtu.be/LusYWxmwWX0

Ничего уникального, просто Emacs и Cider, но зато показываю на примере кода для Babashka 😎

Сегодня попробую вечером постримить. Где-то в 18-19 GMT+4.

Можете заявки накидать, могу высказаться по заданным темам — попробовать такой формат для разнообразия 😎

Поехали, сюда заходите: https://www.twitch.tv/astynax2hs

Буду ковырять рандомный код на Python и разглагольствовать про permacomputing.

В голосовой канал дискорда заходите, если захочется присоединиться https://discord.gg/gqkRbJqU

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

В любом случае спасибо всем, кто заглядывал!

Стримлю один паттерн, который неплохо лёг на одну задачку с Rosetta Code.

https://www.twitch.tv/astynax2hs

А вечером буду подкастик делать в основном голосовой, ближе к делу напишу.

А вот и запись

- задачка на Rosetta Code
- больше про паттерн тоже применительно к Python можно прочитать в этой статье

В ролике я показал, как можно использовать паттерн Active Enum вместо ветвления с помощью if/match и получить "более идиоматичный для ООП" код — по-SmallTalk-овски более идиоматичный, конечно же 😎. Суть паттерна: варианты перечисления обладают закреплённым поведением, в идеале — каждый своим.

Похожего результата с использованием Active Enum можно добиться в Scala, там тоже синтаксис для перечислений легковесный и позволяет прикладывать данные к вариантам, а затем эти данные уже можно использовать в коде, не прибегая к условиям или сопоставлению с образцом.

В Kotlin есть свои enum classes и там прикрепление поведения к вариантам тоже делается элементарно. Отдельно приятно использовать в качестве вариантов объекты вместо классов, когда закреплённое поведение реализуется методами, а полей как таковых нет.

В Java традиционные перечисления умеют только быть собой и именовать варианты, не более. Но нынче есть и sealed classes, которыми можно описать то же множество значений с поведением, да ещё и в одном файле можно хранить и базовый класс, и варианты — да, не нужно иметь по файлу на классик из трёх строк! Правда, остаётся возможность где-то указать в качестве типа класс-вариант, что идёт несколько в разрез с идеей "варианты — всегда значения типа-перечисления."

В Rust нормальные алгебраические типы и закрепить поведение за вариантами перечисления легко, само собой.

Вообщем, мне паттерн нравится — тем, что позволяет размять мозги и взглянуть на задачу иначе. А не потому что он для мира ООП, хе-хе 😉

Ладно, подкаст не вышел пока :) Будем думать 🙈

mumble://0xdd.org.ru — в мамбл заходите просто поболтать

В жизни программиста на языке с объектами наступает момент, когда этот программист решает, что пора написать свой DI Container.

Я тоже был там лет цать назад, году в 2014 😎 Мы тогда делали платформу, в которой БД, API и Web GUI генерировались на лету (метапрограммирование в рантайме, не кодогенерация) из одного JSON-файла. И всё это добро склеивалось из кусочков с помощью DI контейнера за моим авторством. Я даже на PiterPy катал с докладывать про дела с DI в Python в целом и про свою поделку в частности, вот тут есть запись того доклада.

При этом и тогда нельзя было сказать, что я такой уж любитель ООП, так что, нет, мой yadic (Yet Another DI Container) не был следствием того, что я прочитал книжку про паттерны проектирования 😜 Просто в той платформе была реальная польза от использования контейнера.

Кода у меня, кстати, получилось совсем немного, пара-тройка страниц в одном файле. Даже скрипт, который брал JSON с конфигурацией и выводил .dot-файл, пригодный для отрисовки с помощью Graphwiz — и тот больше строк кода занимал, как не странно 🤓 Этим визуализатором структуры мы даже нашли пару протечек абстракции, когда стрелочки перепрыгивали через слой в нашей лазаньи (вместо спагетти, кек).

Так вот, вспомнил я себя из того времени, когда на новой работке увидел DI container за авторством моего лида. Тоже самодельный, конечно же, в лучших традициях велосипедостроения! Но тоже нужный, потому что LiveKit не предоставляет никаких средств поинжектить подключения к Redis в ваш код без лишней связанности. И да, лид мой примерно в том же возрасте, в котором я свой yadic писал, и этот факт меня отдельно позабавил 😁

И да, у меня к этому контейнеру есть претензии, конечно же. Например, мне не нравился, что он таки ничего не инжектирует, а только лишь (UPD: таки инжектирует и даже на основе аннотации типов у конструкторов) позволяет по интерфейсу добыть реализацию. И то, что фаза настройки не выделена чётко, а в разных местах кода вызывается метод регистрации реализаций. Я-то выступаю за то, чтобы конфигурировалось всё статически и строго в одном месте максимально близко к точке входа в программу! Да, иногда не хочется все ресурсы создавать сразу, но этим как раз можно управлять посредством ленивости — явной, как части конфигурации. Есть, над чем стоит поработать, проще говоря 😎

P.S. Всё ещё считаю, что DI может очень сильно запутывать код, если вам не дали достаточно богатый набор инструментов, позволяющих посмотреть на то, что, куда и откуда инжектируется. У моего yadic на старте был визуализатор, который использовался прямо со старта. IntelliJ IDEA понимает Spring, без этого понимания мне лично было бы тяжко, как минимум, во время знакомства с новыми проектами — да, это закрытая и платная функция, но она того стоит (в совокупности со всем тем, что ещё IDEA умеет делать).

Если кого-то ещё удивляет else: у питоновского for (помню, как я про это писал в уроке для Hexlet), то вы просто мало языков видели 😎

> {FIRST { "(".print }; LAST { ")".print }; .print; ",".print if 1 ff^ 10 } for [1..10]; "".say
(1,2,3,4,5,6,7,8,9,10)

А вообще вот статейка хорошая про циклы.

Update:

Кто-то испугался. А зря! У того же Golang есть defer, который освобождает ресурсы даже в случае ошибки. Raku всего лишь обобщает такие "действия до/после/в случае" и разрешает использовать в любых блоках. Называются такие штуки phasers, потому что привязаны к фазам. Даже фазеры специфичные только для циклов (как тот самый FIRST) используют всё тот же синтаксис, просто у циклов набор фаз шире, чем у обычных блоков.

Единственное, что в том примере выше действительно страшновато, так это flip-flop оператор ff^ — эти друзья в Raku действительно очень своеобразные! Но в моём примере как раз тот самый случай, когда я хочу в рамках цикла что-то сделать не на каждой итерации, а только в поддиапазоне, и тут flip-flops как раз к месту 😎

Update #2:

Конечно же, я знаю про макрос loop в Common Lisp, практикую периодически. И циклы с состоянием в Racket тоже пользую 😎

Ну что, постримлю чутка. Clojure и парсинг.

Тут смотреть: https://www.twitch.tv/astynax2hs
Сюда приходить поговорить: mumble://0xdd.org.ru

UPD:

Опять грабли, стрим был в 360p, запись тоже, так что имеет смысл только слушать 🙈

Но если вдруг кому интересно, то речь шла про начало реализации интерпретатора языка Knight, который "проще некуда", а парсить я решил на своей реализации парсер-комбинаторов — потому что могу.

Продолжать я всё равно буду, скорее всего. Надеюсь в следующий раз наступить не на эти грабли по крайней мере 🌚