(Разделил публикацию на две, а то опять в одну Телеграм не захотел умещать. Читайте выше начало)​​

А ещё Winamp 2 жив в виде Webamp — открытой реализации большей части функций оригинала с помощью Web-технологий. Появился Webamp году в 2014, так что проект это достаточно взрослый. Даже визуализации музыки показывать умеет силами WebGL — да-да, тот самый MilkDrop, только прямо в браузере! И, конечно же, шкурки поддерживаются оригинальные, у проекта даже есть целый музей: Winamp Skin Museum — вот тут-то вы точно сможете найти ту самую вашу любимую шкурку с Сакурой, собирательницей карт или с Бредом Питтом в золоте. И мало того, что любой экспонат можно рассмотреть, так все они ещё и действующие, благодаря всё тому же Webamp!

Недавно вышел выпуск подкаста "Подлодка" про creative coding. Выпуск хорош и для тех, кто давно знаком с темой, и как точка входа тоже сработает.

Мне самому эта тема достаточно близка: я картинки кодом рисую года с 1995, тогда на QBASIC, потом на всём подряд. И тут про generative art писал — уже про Racket и его библиотеку с рисующими комбинаторами. Мне в целом нравится такое вот комбинирование примитивов, потому что очень хорошо сочетается с ФП и рекурсией в частности. А рекурсия — это уже первый шаг к фракталам, не требующий при этом какой-то особой математики (комплексные числа точно вспоминать не приходится, это вам не визуализация множества Мандельброта)

В упомянутом в начале подкасте описывается рисование с помощью Kotlin. В том числе некоторое количество времени уделено фреймворку OPENRNDR. Если кому-то это о чём-то скажет, то это быстрый и мощный аналог Processing (про последнего тоже в покасте можно услышать). Я, памятуя о том, что в Processing чаще всего всё рисуется по координатам как в старом добром BASIC, не надеялся особо на то, что в OPENRNDR найдётся похожая на любимые мною комбинаторы машинерия.

Так и вышло. Всё рисуется от лица Drawer, который умеет "нарисовать кружок по смещению с использованием текущих заливки и обводки". НО, при этом на сам Drawer можно накладывать трансформации вроде сдвига и поворота. И трансформации повлияют на то, где фактически будет отображены элементы, которые мы попросим Drawer для нас нарисовать! И если мы вдруг захотим получить рисунок с помощью рекурсии, укладывая составные части коллажа, скажем, по спирали, то нам достаточно будет рисовать "голову" и применять трансформацию на "остаток спирали".

Вот только если в рекурсивном процессе подразумевается какое-то ветвление, то неплохо бы иметь возможность запомнить состояние Drawer перед запуском отрисовки очередной "ветви", а потом это состояние восстанавливать. И для этого есть готовое средство: стеки трансформаций, стилей, проекций (да, такие тоже есть). Вы делаете pushTransformation(), рисуете ветвь, потом выполняете popTransformation() и Drawer готов к рисованию новой ветви — и вам не нужно высчитывать, на сколько в итоге сдвинулся базис координат и на сколько повернулись оси.

И, раз уж я об этом пишу, логично было бы предположить, что я уже что-то порисовал. Да, порисовал! Взял одну свою старую работу, похожую на достаточно удачный пример для проверки возможностей, и реализовал на OPENRANDR. Результат приложу в виде картинки отдельным постом, но в реальности картинка у меня даже анимированная получилась — мигает "точками" в кубиках. Значимая часть выглядит так — это вся программа, включая описание приложения, за скобками остался Gradle-проект, который я по шаблону сделал, так что там ничего интересного.

Отдельно отмечу то, что в коде означает oliveProgram: это не намёк на оливковый цвет, а указание на то, что программа должна быть "live". Такие программы в OPENRANDR отслеживают изменения в соответствующем файле с кодом и без перезапуска применяют эти изменения — и это в компилируемом языке! Да, есть у этой горячей загрузки ограничения: применяются изменения только из той части кода, которая является "телом" oliveProgram, внешние по отношению к блоку функции, например, не подменяются. Но даже такие ограничения позволяют сразу видеть результат, поскольку холодный перезапуск — совсем не быстрый.

В будущем я планирую поглубже поковырять эту штуку. Попробую реализовать любимые мной комбинаторы в каком-то приближении. Может быть постримлю процесс. А вы сходите на сайт фреймворка — там есть примеры, гораздо более впечатляющие, чем мои картинки :)

Опять поправил разметку, а Телеграм отрезал картинку. Так что это очередная "картинка в догонку" к записи выше.

Выложил таки то, что должно было стать материалом для книги про разные "*Scripts". Опубликовал мою часть, которая рассказывает про ClojureScript. Материала там не сильно много и в целом я не пытался написать книгу для новичков — предполагалось что-то вроде "Семи языков за семь недель", где от читателя тоже требовались известные навыки по поиску источников и некоторая самостоятельность.

Читайте, критикуйте, может быть и вырастим совместными усилиями что-то пристойное :)

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

Идею я сначала отложил до момента, когда хватит времени на то, чтобы засесть за Kotlin+OPENRANDR (см.выше). А сегодня утром внезапно захотелось уже прототип опробовать и я вспомнил про черепаху питоновскую. Да, она медленная и рисует без сглаживания, но зато REPL у IPython достаточен, чтобы прямо сразу результат прогона видеть.

Результат вы видите. Мне кажется, неплохо получилось для кода в пол-экрана :)

А ещё, поскольку turtle имеет состояние, можно прерывать рисование с помощью Ctrl-C и просить прямо от места останова построить новое дерево! Вот это сходу с чистыми L-systems сделать не получится, например. Зато это отличный способ добавить немного случайности в генеративное искусство!

​​Так уж вышло, что я нынче опять на Python разрабатываю. И опять Web. Но, внезапно, на Pyramid! Да, бывает и такое!

Для тех, кто не застал (для этого нужно было удивительный мир питонов начинать изучать, как я, лет цать назад): это такой Web-фреймворк, который всегда был известен своей инаковостью, мол, "мы вам ничего не диктуем, делайте на нашей основе свою платформу!". По сути вам давали только маршрутизацию и систему прав (которая User Access Control), но, как говорится, "зато какие!". Сходите на домашнюю страничку проекта и почитайте хотя бы лозунги авторские — очень пафосно!

Так вот, если система контроля прав там развесистая, но в целом понятная, то маршрутизация сделана "максимально мощно". Никаких вам регулярок, каждый фрагмент пути, это некий ресурс, который решает, как обрабатывать дальнейшие фрагменты. Всё сделано на основе перегрузки протокола Mapping, то есть ресурсу скармливается фрагмент пути как ключ (resource['users']), а тот либо возвращает новый ресурс, либо выбрасывает KeyError и маршрутизация останавливается (возвращается статус 404).

В простейшем случае вы можете все маршруты описать словарём. Однако, пирамидоголовые (можно ли их так называть?) любят строить настоящий динамический роутинг и гордятся своими постройками. А потом приходится, дабы понять, куда ведёт очередной PUT /v1/users/105/pets/4/barf, вызывать специальную программку pviews, которая выполнит маршрутизацию с хождением в базу и остальными побочными эффектами, возможными в пути, и вернёт ресурс и view, которые находятся в конце пути. Никакой PyCharm вам этого знания не даст, так и придётся в терминале спрашивать, а порой ещё и внутри Docker-контейнера. "Зато гибко!".

Я действительно могу видеть несколько потенциально оправданных применений такой маршрутизации. Например, в случае, когда путь описывает фактические файлы и директории, а система прав регулирует доступ к оным. Или если вы пишете штуку вроде Kinto — Generic JSON Storage, где возможны какие-то на лету создаваемые иерархии сущностей (Kinto — интересный проект, кстати, в том числе и как self-hosted штучка для непитонистов). А вот обычные CRUD делать на Pyramid не то чтобы как-то особенно удобно (точно не удобнее, чем на Django).

Я вообще сторонник того, чтобы можно было все маршруты увидеть разом. И даже если их скрипт выводит, пусть делает это без раскочегаривания подключений к базе и прочим шинам! И OpenAPI со Swagger тоже не заточены на динамическую маршрутизацию. Так что пусть /users/1/pets/2/barf говорит 404, если второй питомец у первого пользователя — не собака. Но маршруты /meow, /quack пусть у всех /pets/ будут!

Вообще у меня нынче имеется стойкая тяга к фреймворкам: хочу типовые задачи решать типовыми же способами, в идеале (полу)автоматически. И мощь соотношу с покрытием рядовых случаев, а не с гибкостью для DIY (впрочем, потенциал для потенциальной модификации я тоже ценю). По крайней мере ощущаю такое в отношении CRUD backends.

Сейчас опять про Python будет, но не только лишь про него.

Посмотрел на днях запись доклада "Async Django: The practical guide", чтобы слегка синхронизировать своё понимание темы с тем, как там оно сейчас. С одной стороны ничего нового лично я для себя не вычленил: сам фреймворк отлично себя чувствует в синхронной ипостаси, а любые штуки вроде поддержки WebSockets всё ещё прикручиваются сбоку через channels — я не говорю, что это плохо, кстати. А вот тем, кто именно ждёт подробностей о реализации или использовании, одного этого доклада может не хватить.

Чем же доклад интересен в том числе и для тех, кто с Python не работает? Тем, что взято в качестве примера, вокруг которого всё повествование строится. Докладчик показывает, как сделать Web Chat и добиться получения клиентом свежих сообщений аж четырьмя разными способами! Рассматриваются:

1. Обычные запросы обновлений по таймеру
2. Long polling
3. Server-Sent Events (SSE)
4. WebSockets

С первым пунктом всё понятно, и меня лично позабавило лишь то, что и в этом докладе про Django упоминается HTMX. Это вообще заметная и приятная лично для меня) тенденция — активно осваивать HTMX, применять в проектах на Django и рассказывать о своём опыте!

Long Polling — это уже классика, старая школа, ностальгия по Dial­Up. С использованием HTMX, опять же, делается легко и приятно. В довесок к Django уже нужны django-channels, но реализация всё ещё простая и прямолинейная.

SSE тоже сделаны через channels и тут было забавно посмотреть на то, как порции HTML освобождаются от переводов строк. Потому что SSE иначе не умеет, кроме как слать по строчке за раз. Unix shell style, практически!

С WebSockets всё понятно: нормальная посылка сообщений без дополнительной подготовки. Канал дуплексный, опять же, хоть в примере это свойство WS не используется.

И мне лично понравилось то, как автор предлагает слушателям, которым вдруг понадобится "чат написать", подумать, где на этой оси "синхронно и просто — асинхронно и сложно" остановиться! Не всем нужен дуплексный канал, кому-то и long polling хватит, третьих в принципе устроит обновление по таймеру, зато реализация будет простой и предсказуемой! Вот такие доклады я люблю :)

Прочитал "Untyped Python: The Python That Was" от Армина нашего Ронахера. Рекомендую сходить и почитать — и не только тем, кто с Python сталкивается. Во мне, как говорится, "отзывается"!

И перекликается с гремовской "Beating the Average" — там тоже было про "мощь всего мира в наших руках!". Ронахер даже пишет: "the exceptional developer experience these languages offered" и "It required a bit of restraint and it required a slightly different way of programming, but it was incredibly productive." — ну очень по-­лисперовски!

Интересно было бы почитать, что бы Армин написал, если бы в своё время нырнул в Clojure или даже в CL? И не подхватил бы он в этой временной ветви The Lisp Curse? :)

Возвращаясь к статье, отмечу несколько мест, которые прямо таки зацепили.

Without doubt I was able to understand everything between the code that I wrote, and the code that ran end to end.

Это предложение завершает абзац о том, что в те времена можно было в голове удержать то, как работает интерпретатор Python, потому что оный тогда был относительно небольшим и простым. Понимаемо!

---

I had a module that allowed me to attach remotely to the running interpreter and execute Python code on the fly to debug it.

Тут Армин про свой Werkzeug говорит, наверняка. Лисперов такой штукой не удивить, но тогдашнего условного джависта, думаю, очень впечатляло!

---

Modern Python can at times be impossible to comprehend for a developer. In a way in some areas we are creating the new Java. We became the people we originally displaced. Just that when we are not careful we are on a path to the world's worst Java.

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

---

Наконец, продублирую ронахеровский PS:

Python is in a spot now where the time spent for me typing it, does not pay dividends. TypeScript on the other hand tilts more towards productivity for me. Python could very well reach that point. I will revisit this.

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

---

P.S. (этот уже мой): статья не утверждает, что типы плохи или хороши, в Python или где-­либо ещё. Это запись в личном блоге, статья о личных же переживаниях. Мне понравилось читать и сопереживать. Как-то так.

​​В понедельник закончился очередной Advent of Code. И я во второй раз добрался до конца вовремя, без пропусков и задержек!

По ощущениям задачки этого года были проще в среднем, чем задачи двух-трёх предыдущих лет. И нельзя сказать, что я просто руку набил — реально простые попадались даже на третьей неделе.

Увы, нельзя сказать, что какое-то из заданий запомнится, как бывало в раньше. И опять же, это не следствие того, что я натренировался: встречались задачки на обычный поиск пути, казалось бы, но с интересным поворотом во второй части (лабиринт в форме тора с телепортами на другие слои реальности). А в этом году даже простых клеточных автоматов не было, не говоря уж о "Жизни", которая учитывала соседей в будущем и прошлом!

Зато в этот раз были две задачи, которые решались на Python, скажем, в десяток строк, включая разбор входных данных, просто потому, что для языка есть готовые библиотеки, делающие graph clustering или находящие решение для системы из девяти уравнений с шестью неизвестными. Ещё всякие Mathematica и Wolfram Alpha подходили, вот только это уже не "of Code" какое-то, на мой взгляд…

Я в этом году решал задачки на Scala — набивал руку, раз уж в работе теперь использую. С одной стороны ленивость Haskell местами бы очень пригодилась да и парсеры на megaparsec я писать умею хорошо, с другой отладчиком в Intellij Idea было приятно пользоваться. В целом я обошёлся стандартной библиотекой, комбинаторный парсер один раз только применил, но это обычное дело для AoC — давать возможность обходиться без специфичных решений. И тем больше меня расстроили те самые две задачки, которые я выше упоминал.

В любом случае AoC — уже привычная часть моей жизни. А это приятно — иметь что-то, что точно порадует под конец года!

​​Мои первые компьютеры (оба от "Электроники", МС-1502 и БК 0010-01) имели встроенный интерпретатор BASIC. А вообще с BASIC я познакомился даже раньше, чем у меня появилась техника, позволяющая на нём писать: мама купила книжку со сказками про блоху PSET, колобка CIRCLE, злого колдуна CLS — прямо в тексте вперемешку с прозой приводились программки, анимирующие соответствующие сценки.

Где-то в то время, когда у меня уже были БК и МС и BASIC я более-менее освоил, мне в руки попались ксерокопии ксерокопий какой-то книги с играми, листинг каждой из которых не превышал пару страниц. Увы, какие-то страницы в копии отсутствовали и использованный диалект BASIC был не самым стандартным. Но кое-как я и через это продирался, вводил и отлаживал многие игры, заимствовал авторские приёмчики. Уже сильно позже я узнал, что тогда в моих руках была копия книги "BASIC Computer Games".

Все игры работали в текстовом режиме, но кое-какие умели таки показывать интерфейс. Одной из самых продвинутых была игра Super Star Trek), известная и за пределами упомянутой книги. Эту игру воплощали буквально для любых систем, настолько концепция была удачна. Были даже коммерческие реализции. Недавно смотрел ролик про одну из таких реализаций: EGA Trek. Это достаточно продвинутая версия с приличным количеством дополнений к базовой игре, очень советую посмотреть, во что играли люди когда-то :)

Кстати, в сами игры из книги нынче можно в браузере поиграть: https://github.com/coding-horror/basic-computer-games/ — вот тут народ воспроизводит их на разных языках.

P.S. Когда смотрел обзор EGA Trek подумал, что именно в таком виде игру можно было бы воплотить "в железе": светодиодные матрички, семисегментные индикаторы, аналоговые "показометры", никаких ЖК-экранов, Arduino вместо мозгов.

Попиарюсь немного: буду в апреле про питон нескучное рассказывать в Черногории в рамках выездного лагеря! Вот так это звучит:

Code Retreat — выездной лагерь в Черногории для разработчиков, которым нужна перезагрузка!
Утром: хайкинг и потрясающие виды. После обеда: актуальное и полезное обучение. После заката: новые друзья и посиделки у костра

Планирую потыкать и что-то ещё сравнительно новое, но уже реализованное, вроде pattern matching (с кишками и перегрузкой for fun and profit) и типиков. Покопаем всякое около "пакетирования по-новому" (Rye, uv). Экстеншны-ускорялки попишем (на Rust возможно даже). Код на лету погенерируем — как я без этого могу? Словом, выглянем за рамки того, что каждый день типичный джангист делает.

Собственно, предлагаю тем, кому такое интересно, присоединяться. И будет классно, если ещё и/или пораспространяете среди знакомых питонистов!

Сабж: https://coderetreat.me/python

Статья была навеяна новостью о том, что вышел очередной мажорный релиз WinRAR. Будет "мемуарно" и "налюбительско", сразу предупреждаю :P

Я уже писал о том, что приличная часть моей жизни оказалась связана с Windows, которую я умел обживать, подстраивать на свой вкус, расширять. Да, по сравнению с Linux, степеней свободы у WinXP было сильно меньше, но всё равно достаточно для меня образца тех лет. Да мне и не с чем сравнивать было тогда, наслаждался тем, что имел. И уж точно чувствовал себя владельцем моей машины, потому что мог делать для себя то, чего мне не хватало — делать на Delphi, конечно.

Сколько-то приложений я даже доделал до того состояния, когда ими уже можно делиться. Не то чтобы я делился, правда. Но, например, способами инсталляциии я интересовался. В Windows 95 и более поздних в стандартную поставку входил генератор инсталляторов для .CAB-файлов, но Wizard получался простенький, да и .CAB­-файлы не то чтобы очень компактные получались. А ещё у нас был WinRAR, умеющий делать самораспаковывающиеся архивы. И, что меня лично радовало, имелась достаточно простая возможность поднастроить интерфейс распаковщика — поменять пиктограмму, картинки, даже расположение элементов управления в окнах!

Модуль распаковщика среди файлов WinRAR найти было несложно, дальше в дело вступал редактор ресурсов: так уж вышло, что в Windows многие программы хранили изображения, иконки, макеты окошек в открытом виде в виде этих самых "ресурсов" и специальные программы позволяли данные ресурсы подменять. Именно таким образом я сделал себе пару вариантов распаковщика на свой вкус с градиентными иконками кислотно зелёного цвета (такая "идентика" у меня была тогда).

Однако изменение вида окон — это только пол­дела. Хотелось и ярлыки на Рабочем Столе и Меню "Пуск" создавать, и запускать что-то после окончания распаковки. WinRAR такого делать не позволял, а расширить возможности не позволяла закрытость самого продукта. Вот я и довольствовался собственным оформлением.

В какой-то момент моей жизни на Windows я пересел с WinRAR на 7zip, который тоже умел самораспаковывающиеся архивы делать. И вот у 7zip возможность выбрать модуль-­распаковщик при создании архива уже позволяла более просто настраивать внешний вид. А потом я открыл для себя проект 7zSFX — это готовый модуль распаковки, которые можно заставить с помощью конфигурационного файла делать всё то, что умеют делать штуки вроде NSIS или Inno Setup. Вот уж тут я развернулся! Готов был "развернуться, когда потребуется", если быть точным :P В любом случае возможности будоражили воображение, что само по себе было приятно!

Ещё одним этапом виндоводства у меня было увлечение portable software. Уже тогда у меня была флешка с настроенным на портативность TotalCommander и ворох софта, вызываемого из TC — всякие register cleaners и прочие disk doctors в основном. И не все программы честно умели не оставлять следов в системе. Но я такие программы отучал пачкать (пытался, по крайней мере). Например, у меня были маленькие программки на Delphi (консольные, без окошек), воссоздающие нужные данные в реестре, запускающие программу, а по завершении работы оной, подчищающие всё тот же реестр.

И эти самые программки-­уборщики я запускал из 7zip SFX­-модуля, настроенного на молчаливый режим, распаковку во временную директорию с запуском моей программки оттуда и подчисткой после её завершения. Получалась та ещё матрёшка, но оно работало!

В итоге я, конечно, на Linux перелез и забыл про всё это. Но воспоминания остались. Ни о чём не жалею, было весело!

​​IDEA Conf

Поскольку я в последнее время пользую IntelliJ IDEA для тех же Scala и Kotlin, я подписан и на рассылку тематическую. А на днях ещё и конференция IntelliJ IDEA Conf 2024 случилась. Поскольку я имел удовольствие поработать в JetBrains, то за продуктами я с тех пор слежу, вот и на конференции виртуально поприсутствовал.

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

День первый

5:16–1:00:22 – Let’s Set the Records Straight by Dr. Venkat Subramaniam

Докладчик задорно рассказал про то, как можно жить с records в Java и как начать двигаться в сторону Data Oriented Programming — для многих джавистов это настоящий paradigm shift, я уверен. Да, для меня, видевшего рекорды и pattern matching много где и уже много лет, откровений никаких не последовало. Но общая эргономика того же pattern matching в Java меня радует. Как минимум, в Python всё сильно более печально.

2:01:31–3:01:47 – Developer Productivity With IntelliJ IDEA by Trisha Gee

Тут всё в целом традиционно и нацелено на новичков, но всё равно по диагонали было интересно посмотреть на то, например, как меняется работа с VCS в последнее время. Я не успел долго попользовать старое "отдельное окно", которое многие любят, так что мне нормально живётся в новом панельном интерфейсе — да, не Magit, но всё равно вполне удобно.

3:02:27–3:54:28 – Working With Databases in IntelliJ IDEA by Maxim Sobolevskiy

Тут мне захотелось посмотреть, как работают настоящие DBA. Посмотрел, впечатлился. Запомнил, что теперь можно сделать запрос по одной базе, получить выхлоп в виде таблички, а потом "вставить" эту таблицу в другую БД: будет создана новая талица в целевой БД и схема этой таблицы будет отражать выборку. Вьетнамский флешбек случился даже: вспомнил людей, которые в PgAdmin вставляли данные из Excel, включая строку "Всего: 100500" :)

5:01:27–6:01:18 – Bootiful Spring Boot 3.x by Josh Long

На Spring не пишу, но доклады иногда смотрю — ребята умеют в автоматизацию, отдаю им должное. Видео приятное, показывает и степень интеграции фреймворка в среду разработки, и просто даёт представление о том, как сейчас джависты готовят сервисы. Позабавило то, как docker compose прячется под плагином к Spring так, что достаточно нажать "Run" в Idea и вы получите docker-compose up, а дальше сервер будет перезапускаться сам после каждого изменения кода — это тоже история про интеграцию инструментария, люблю такое.

(продолжение к тому, что выше)

День второй

1:02:01–2:01:22 – Building and Testing Applications With Micronaut and Testcontainers in IntelliJ IDEA by Graeme Rocher

На Micronaut поглядываю, как на явление. Тут и compile time DI, что сильно ускоряет загрузку, и возможность собрать native executable с помощью Грааля. Не все фишки в Kotlin пока доступны в таком виде, чтобы код не выглядел как вынужденный interop, а на чистой Java я писать пока не хочу (впрочем, records и pattern matching уже сильно радуют, ещё бы Null Safety дождаться).

В докладе хорошо показан и bootstraping проекта, и добавление ручек. А ещё работа с БД по-микронавтовски демонстрируется, и это отдельное веселье с генерацией в compile time запросов для методов с именами вида getUserNameIfAgeGreaterThan — вы буквально объявляете метод без реализации, а компилятор следит и за соответствием типов, и за генерацией самих запросов.

4:01:53–5:00:22 – To Java 22 and Beyond! by Billy Korando

Тут я просто проверил, что в основном речь пойдёт о structured concurrency и легковесных потоках — да, в основном о них и рассказывалось. Можно посмотреть, если вдруг пропустили.

5:01:07–5:53:11 – Back to the Stdlib: Making the Most of Kotlin’s Standard Library by Sebastian Aigner

Себастьян любит рассказывать про Котлин и делает это со вкусом. А я смотрю такие видео для развлечения: каждый раз жду моментов, когда IDE предлагает цепочку из общих методов заменить на частный случай вроде takeWhileNotNullOrNull. Да, название метода говорящее, но без IDE все подобные говорящие имена просто не запомнить. Вот бы как в micronaut генерить компилятором код, реализующий подобные методы, тогда можно было бы не помнить, а придумывать имена под задачу :Р

​​Случился вчера очередной маленький emacs moment. Вздумалось мне вчера прикрепить картинку из интернета к записи в заметочницу (org roam). Но картинка оказалась слишком большой как в плане разрешения, так и в плане размер на диске — мне просто обидно тратить много места на картинку в 500 пикселей в высоту. Кроме того Emacs у меня не очень-то красиво отображает картинки, если те слишком велики. Решено было ужать картинку.

Чтобы сделал типичный пользователь Obsidian или любой другой не облачной программы? Пошёл бы менять размер картинки с помощью того, что у него есть под рукой, всё же нынче любое типичное Default Preview App умеет разрешение изображения уменьшить. Вариант "взять за уголок и уменьшить визуально" я не рассматриваю: я так документ Word, по которой я дипломную работу делал, ужал в три раза, просто откадрировав и отмасштабировав несколько снимков экрана — предыдущий автор просто вставил и "уменьшил за уголок" как раз :Р

В итоге я просто "провалился" в картинку в Emacs — открыл как самостоятельный файл, вызвал term и выполнил mogrify -scale 50%. И всё! ImageMagic всё ещё справляется с типичными задачами отлично и наименее интерактивно. Если бы мне надо было десяток файлов обработать, я бы цикл прогнал. А вот в графической программе я бы помучился, не имей я по-старинке на машине что-то вроде IrfanView умеющее в batch file processing.

Да, местячково и не оправдывает в целом использование Emacs для ведения заметок, если вы уже не умеете им пользоваться. Но в мою копилочку монетка упала :)

P.S. Прикрепил ту самую картинку из интернетов. Забавная, мне кажется!

Прочитал буквально час назад докладик про то, как в Racket делают Web-приложения, хранящие состояние в продолжениях (continuations). Тема меня давно зацепила, а тут довелось ещё и поделиться своими впечатлениями. Всё же не каждый день можно встретить использование continuations не под капотом слоя абстракции, а в конечном коде да ещё и в такой насущной области, как Web!

Видео тут можно посмотреть: https://www.youtube.com/watch?v=ESh4wzRBtls Ссылки на код и на документацию к использованной библиотеки (искоробочная web-server-lib), как водится, в описании.

​​Виталий Брагилевский опубликовал статью Polyglot Programming Is a Thing в блоге Fleet, а я её прочитал.

Красивое, с картинками. И размышлениями о том, насколько часто приходится жить с несколькими языками программирования в одном проекте. Мне, как человеку, интересующемуся ЯП давно и широко, точно было интересно почитать!

В какой-то момент содержание статьи смещается в сторону того, насколько Fleet хорош как раз в многоязычных проектах — на то и в блоге Fleet статья опубликована. Такой вот образчик developer advocacy, которого Fleet не хватает, как мне кажется. И я рад, что Виталий за это взялся!

Сам-то я в Emacs играюсь с разными языками — он тоже "много с чем как-то да работает". И дальше будет только лучше, ибо LSP в народ пошёл даже среди имаксеров, да и вокруг Tree Sitter потихоньку надстраивают экосистему пакетов.

Однако, поскольку во Fleet сколько-то моего кода всё ещё работает (хочется надеяться), то определённую гордость за функциональность этого продукта и я тоже испытываю!

P.S. Надо будет как-нибудь найти силы и написать о том, какую "весёлую дичь" я во Fleet запилил с пользой для дела и удовольствием для себя. Код буду вспоминать, так что коммерческая тайна не должна пострадать, по идее (хе-хе, косвенное упоминание Idea)

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

Могу поменторить ваших джунов — питонистов, кложуристов, котлинистов, скалистов. Туториалы напишу для ваших продуктов, ролики обучающие сделаю. Open Source ваш посопровождаю. Иными словами что-то на стыке developer advocate / mentor / tech writer. На фуллтайм не претендую, могу на "пол-ставки". И да, хотелось бы удалённо пользу наносить. Или очно в Ереване.

Лично кого-то поменторить тоже могу, опыт есть и вполне положительный!

Тут потихоньку описываю, что я делал кроме программирования: <https://astynax.me/devrel_cv_ru.html>

P.S. Код читать и отсматривать (Code Review) тоже могу, но пилить фичи для продукта каждый день в режиме эджайла больше не хочется.

P.P.S. В Linkedin пробовал с этим вопросом зайти, но я не умею им пользоваться, как выяснилось.

Буквально сегодня будет интересная трансляция: "Automatic Backend with PostgREST. Xiana + PostgREST shared JWT token". Организатором выступает Flexiana

> Flexiana is a remote-first community, full of open-minded, autonomous craftsmen with a passion for developing software.

В описании мероприятия среди тегов числятся Functional Programming и Clojure — на Clojure/ClojureScript во Flexiana и разрабатывают (хотя на сайте у них "25 languages" упомянуты, в том числе и Haskell). У компании даже микрофреймворк свой есть — тот самый Xiano из названия трансляции, вот его использование в действии и будут демонстрировать.

Мне же лично было забавно увидеть Clojure в одном контексте с PostgREST — этот-то на Haskell написан! Впрочем, PostgREST не требует знания Haskell для использования, как и Hasura — это в чём-то подобный проект, только про "автомагический GraphQL для вашей БД", тоже на Haskell написанный.

Вот такое вот перекрёстное опыление между разными функциональными штуками!