​​Приступ ностальгии по беззаботным временам программирования на BASIC привёл к тому, что я накидал пару программок, которые артистично заполняют экран терминала. Не совсем уж простых вроде 10 PRINT LOL; GOTO 10, посложнее, но тоже исключительно ради развлечения.

В процессе вспомнил, зачем нужен косинус, в кои-то веки применил deque, поигрался с ECMA-48 codes, чтобы в рамках одного print() накладывать несколько "спрайтов" на одну строку вывода.

Итак, косинус нужен для сглаживания переходов от одной случайной точки к другой. Конечной длины deque позволяет накопить "хвост", следующий за блуждающей "головой". Среди escape codes есть один подходящий, который перемещает курсор в нужную колонку в пределах текущей строки, в том числе и туда, куда что-то уже было выведено ранее.

Приложу гифку, которую записал как "текстовый screencast" с помощью asciinema, а потом сконвертировал в GIF с помощью agg. Вдруг кто-то захочет и свои поделки терминальные позаписывать, а про эти программки ещё не знает.

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

В принципе я всем доволен, даже то, что Apple Terminal не умеет в TrueColor, пока не жмёт, надо сначала наиграться с 256-цветным режимом. Потом в Kitty, Wezterm, Ghostty схожу, если упрусь именно в нехватку цветов, но тут у меня есть стимул покомбинировать цвет текста и фона вместе с символами вроде ░▒▓ и получить промежуточные оттенки — не практичности ради, а удовольствия для.

Имеется и доля фрустрации: я пока не встречал ни одной библиотеки, которая выступает как "виртуальный принтер" текста с ANSI codes в HTML и при этом поддерживает перемещение курсора хотя бы в пределах строки. Я ещё могу понять нежелание выше по тексту перемещаться, всё же мы поточно генерировать HTML хотим по строчке за раз, а тут придётся эмулировать "экран". Но хотя бы перемещения в рамках строки можно было бы сделать 😠

Ну ладно, а что там в Расте, подумал я, ведь пишут нынче всякие TUI на нём?

Сходил, увидел десяток либ для работы с ANSI codes. И каждая чем-то да лучше остальных — классика NIH. Ну да ладно, вроде сейчас побеждает anstyle, вокруг неё уже экосистемка организовалась, есть и "принтер" в SVG и HTML — anstyle_svg. Но этот тоже умеет только раскрашивать текст, но не поддерживает нужные мне перемещение в рамках строки.

Пробовал воспользоваться библиотечкой ansi-cut — эта позволяет вычленять подстроки из текста с кодами с сохранением раскраски. Делается это всё ценой парсинга строки с кодами и отделения собственно кодов от чистого текста. Потом подстрока клеится из кусков чистого текста с обратной вставкой стилей. С другими библиотеками ansi-cut не дружит, поэтому получается, что весь glue code работает в терминах String: раскрасил с помощью anstyles, запёк всё в String, отдал ansi-cut, та распарсила коды обратно, нарезала, опять запекла своими силами — дорого, неэффективно, хоть и blazing. И самое главное, возможность нарезать цветной текст я хотел использовать, чтобы эмулировать запись поверх — думал вырезать перекрываемые участки и вклеивать на их место патчи. Вот только упёрся я в то, что ни одна из либ, которые я потрогал, не умеет считать длину цветного текста в видимых символах, шах и мат (#@$)!

Да, я понимаю, что хочу имитировать графическую канву в терминале, но почему-то не спрыгиваю сразу на подход с абстрагированием "видеопамяти", которая только на этапе вывода на экран запекалась бы в непрерывные строки без прыжков. Можно было бы даже RLE-сжатие использовать для атрибутов, тоже весело такое делать!

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

Вот тут всего лишь пара синусов, ANSI-коды для прыжка вверх и прыжка в рамках текущей строки, пяток цветов из 256-цветной палитры. Попахивает демосценой, можно переписать на no_std Rust и сделать boot sector demo, но мне лень :)

На тильде, где у меня есть аккаунт (про это всё я как-то писал) среди прочего ПО, на котором держится местный уютно минималистичный intranet, есть софтина под названием TTBP, и которую сейчас называют "Feels Engine".

ttbp stands for "tilde.town blogging platform"

Концептуально это приложение, позволяющее через набор текстовых меню — я напоминаю, на тильдах почти всё делается в сессии SSH, то есть в тестовом виде — писать о своих переживаниях (feels, почти как reels). То есть, можно сказать, публиковать "статусы". Если не хочется писать самому, то можно почитать "feels" соседей по машине.

Кроме поддержки интранета чувств, система позволяет часть feels, которые вы отметили как публичные, оформить как простенького вида website — простота нарочитая, так надо! Полученные сайтики раздаёт единый на всю систему Web-сервер, а контент лежит у всех в ~/public_html — старая школа!

Так вот, код TTBP открыт, написан одним человеком, находится в статусе вечной beta. Посмотреть можно тут: https://github.com/modgethanc/ttbp

Чем же этот проект интересен, раз я про него пишу? Тем, что это идеальный образчик "smol software"/minimal software/permacomputing/etc — кода немного, зависимостей минимум, всё написано настолько просто, насколько это вообще было возможно. А ещё код максимально авторский, вы только на этот кусочек посмотрите — мы в индустрии поотвыкли от такого, все любят причёсывать даже то, что и в лохматом виде неплохо смотрится. Мне самому часто сложно перестать делать "как положено" (кам-то, не мной) — сейчас, по крайней мере.

Вот этот абзац в руководстве для контрибьюторов тоже очень милый:

Please do not open PRs for cosmetic changes to the codebase if we haven't had a prior discussion about it. Cosmetic changes include things like whitespace, commenting/documentation, naming conventions, and other aspects of the codebase that would not affect end users if changed. I am cautiously open to receiving respectful feedback about my general coding style, but I'm not generally interested in unsolicited style critiques, or for coding conventions dictated to me. Thank you in advance for your understanding!

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

В эфире рубрика "Кто о чём, а он опять о ритритах!". Новая смена через месяц, три трека: один просто хайковый, ещё один по Data Science (UPD: ок, про Data Engineering), и третий — мой, про *роботов* 🤖!

Идея такая: разбиться на команды и запрогать самобеглые тележки с датчиками линии и УЗ-дальномерами, чтобы тележки эти гоняли по трассе с препятствиями на скорость!

На борту у телег Arduino, как водится, так что это повод приобщиться для тех, кто ещё не. Паять ничего не придётся (надеюсь), но DIY составляющая всегда подразумевается — любительская робототехника даже в виде наборов часто требует доработки и отладки 😅

Собственно, я пишу сюда, чтобы зазвать народ. Потому что именно так мы и продвигаем себя, пока маленькие и не имеем возможности пойти ко глыбам вроде AlexGyver 👨‍🔬 за нативной интеграцией. Но надежда есть когда-нибудь дорасти. Прошлогодний заход с программированием BBC Micro:bit вышел очень удачным, нужно дальше про железки собираться!

Прочитал такую статейку: Toolbox languages (прочитал давно, но только сейчас напистать о ней руки дошли).

Автор описывает свой набор языков-на-каждый-день, которые

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

У автора набор языков таков: AutoHotKey, Python, Raku, J, Frink, Picat.

AHK я когда-то использовал и могу понять, чем он автору нравится: в Windows очень многое хочется заскриптовать и AutoHotKey тут очень хорош. Язык сам странноватый, но возможности платформы выходят далеко за пределы горячих клавиш, хотя изначально проект про это был, что видно по названию. В AHK даже GUI можно скриптовать простенькие, если больше не на чем (у меня тогда Delphi был) — тут уже можно вайбы Tcl/Tk словить, и это тоже вполне себе toolbox language!

С Python всё понятно, он и так у многих под рукой. Освоив uv, можно очень удобно дописывать себе полезняшки даже с использованием внешних пакетов. Я так и делаю. Плюс всегда имеется venv с ipython и plumbum: когда нужно разово что-то сделать с файликами и папками — эта связка работает замечательно!

Raku, по идее, в той же нише находится, где и Python, но автор а) любит максимальную краткость, б) вспоминает о Rakudo Star. Последний проект — это "готовый набор всего, что может понадобиться" — тут я могу вспомнить Scala Toolkit и Haskell Platform. И по моему опыту такие наборы хорошо работают до тех пор, пока не начинают работать плохо, хе-хе. Впрочем, набор того, что в Babashka "запекли", мне пока что нравится, а тот же Scala CLI тоже умеет притаскивать зависимости для одиночных скриптов.

Про Frink и Picat я до этого не слышал. Но на последний глянул — авторы обещают многое, но пока что экосистема крохотная. Зато логический язык, иногда такое бывает интересно. У автора обсуждаемой статьи есть заметка Picat is my favorite new toolbox language — интересное чтиво в дополнение к текущему предмету обсуждения.

В статье ещё отдельно упоминается, что toolbox language должен быть предельно краток. И вот тут я не соглашусь, лично я — за "достаточную лаконичность". И тот же Raku слишком code-golf'y на мой вкус. А при наличии REPL с неплохим автодополнением даже Java в лице Java Shell позволяет удобно какие-то вещи делать и инcтрументарий вокруг Streams достаточно богат.

https://github.com/turboblack/HamsterCMS - миленькое!

Сам бы я такое не осмелился писать: мне подавай много маленьких файлов, все структурировано, отделённые представление и логика. Да тут даже проверка пароля сделана простым сравнимым входящей строки и константы в файле, ничего не хэшировано и не посолено — дёшево и не очень сердито.

WYSIWYG редактор имеется в виде JS на 2000 строк без минификации. Страшно такое поддерживать? Мне — сейчас уже да. А раньше бы я не парился, у меня и подлиннее Unit1.pas бывал 😎 "Зато работает", да и косяки сразу видны, если что-то ломается — визуальные редактор, ведь.

PHP-код я даже весь прочитал по диагонали — кода этого мало и у меня настроение было подходящее. Да, так не носят. Но в целом и не ужасно — simple software, вот это вот. Рассчитано на тех, кто не будет пытаться сломать систему, защитного кода минимум, только самая база вроде "пишем в файл, если не вышло, просто выводим сообщение — руками поправят, если что". В итоге CMS работает, пока мы явно не накосячим. А потом за починкой ходим по SSH/FTP.

Собственно, наткнулся я на эту CMS, когда гулял вокруг Small Web, Gemini и прочих Gopher, и зашёл на https://web1.0hosting.net — один из островков, где старая школа нынче обретается! Я лично уже не застал такой интернет — как автор, а не как читатель. Я уже статические сайты генерировал из Markdown в Git, никакого заливания HTML по FTP не практиковал — "перед пацанами стыдно" было плюс мода другая была уже. Зато сейчас, вот, смотрю и умиляюсь.

На днях снова заглянул в пузырь SmolWeb, в подпузырь мелких протоколов (про Gemini я писал тут и под тегом #gemini). Обнаружил для себя, что нынче ещё есть и протокольчик NEX (да-да, название смешное для тех, кто в теме) — Nightfall City's Express Transportation System, система транспорта в Nightfall City.

Сам городок Nightfall City — во многом типичный Smol Web сайт, но автор с никнеймом m10o заморочился и сделал так, чтобы читать и писать в рамках портала можно было буквально из любого терминала, если у вас под рукой есть GNU Netcat (он же nc) или любой другой способ работать в текстовом виде через TCP.

Как в описании протокола сказано, минимальный клиент выглядит так:

echo nex/specification.txt | nc nightfall.city 1900 | less

Ну не прелесть ли? Вот и мне понравилось. Только я решил сделать чуть удобнее, но всё ещё smol. И обернул nc в TUI на базе... FZF! 🤓 "Это же выбиралка элементов из списка!", скажете вы? Но список строк на экране терминала — тоже список, который fzf умеет листать так, что даже PAGER не понадобится!

Так-то я думал над тем, чтобы просто пропускать текст через скрипт и нумеровать ссылки, которые, к слову, выглядят как в Gemini:

=> ../foo/bar.txt

Потом, по выходу из less, я бы спрашивал номер ссылки для перехода.

Но мне показалось, что как-то совсем уж аскетично и не интерактивно. Вот и заменил less на fzf, получив возможность выбирать ссылки через поиск или "стрелочками". Заодно сделал так, чтобы отмена выбора трактовалась как ":q" и означала бы выход из браузера 😎

Ну и напоследок добавил "панель навигации" в виде контекстнозависимых ссылок на "/", "./" и "../" — тоже классика! Можно было и хоткеев в fzf досыпать с кастомными действиями — он такое позволяет. Но оставил как задел на будущее.

Исходники можно посмотреть тут, хоть там и кода-то кот наплакал. Постарался остаться в рамках POSIX, поэтому shell script должен быть максимально портируемым. А ведь мне надо было каноникализировать пути на своей стороне, например, чтобы ссылки вида "../foo/../bar/" превращались в абсолютные! В процессе пришлось отказаться от realpath и написать нормализатор с нуля. Зато было весело!

P.S. Смысла в моём браузере мало, я просто развлекался. Если сильно захочется нырнуть в микропротоколы, то стоит попробовать что-то вроде Alhena — так вы получите поддержку и Gopher с Gemini, и всякого прочего.

Недавно воплощал одну свою идейку вокруг jq в браузере (кратко писал о сабже в побочном канале: см тут и далее). Сделал MVP, пока подвисло только встраивание WASM-бинаря прямо в HTML. Потом пошёл смотреть в awesome-jq, насколько мой велосипед вторичен 🌚 Да, готовых "jq-в-браузере" существует штук пять уже, но именно в "самодостаточную HTML-страницу" никто пока не упаковал, так что буду продолжать. Подводку заканчиваю, в том же списке я нашёл проектик jqp — proxy для JSON, применяющий на лету jq. И вот тут у меня возникла новая идея — шаблонизатор-как-сервис!

Собственно, добавить шаблонизацию я хотел ещё в свой WJQ, и я сделаю это когда-нибудь путём запекания в HTML ещё и чего-то вроде mustache-js. Но новая идея моя крутилась уже вокруг Smol Web, поэтому я решил сделать CGI application. У меня уже и своя песочница есть для таких микро-веб-приложений, могу написать про это статейку, если кто-то проявит интерес. CGI-apps должны быть blazingly fast, поэтому я в этот раст решил взять Rust 🦀

С CGI есть одна небольшая проблемка: нужен какой-то сервер, который бы ваши программки запускал. Писать ещё и раздатчик CGI я не захотел, ткнулся по памяти в питоновский http.server, коли он "уже есть на каждой системе", но узнал, что такую раздачу CGI уже выпилили 🙈 Плюнул и взял из соседней песочницы программку на Go — да, ужасно, но уж больно в Go проста в использовании батарейка для этой задачи. И оно даже завелось сходу! А затем я захотел ещё и статику раздать и это уже означало, что на Go придётся написать ещё сколько-то кода. Плюнул ещё раз, расчехлил lighttpd, раз уж моя основная песочница для CGI и так на нём сделана.

Лайти многим хорош, но он достаточно педантичен в плане следования стандартам и best practices. Например, не раздаёт ничего, если в конфигурационном файле указать относительный путь вместо абсолютного. Хорошо, пусть. Берём Makefile в руки, генерируем конфиг подстановкой $HOME. envsubst слишком глупый, ломает синтаксис конфигурации. sed работает, но как-то скучно опять регулярками дыры затыкать. Взял m4 — древнющий macro engine из середины 70х, который, опять же, есть везде и неплохо подставляет переменные. Это мой первый опыт реального его использования, ранее я про m4 только читал. А тут не без удовольствия применил 🤓

Итак, запускать есть чём, нужна болванка CGI app. Берём cgi crate. Использование тривиальное, я прямо таки порадовался. До первого спотыкания. Оказалось, что в крейте http, призванном описать "один раз для всех и навсегда" всё, что касается HTTP, в какой-то момент выпилили парсинг query strings! Ох, как я взнегодовал! Выдохнул, добавил в проект крейт url. Не сразу, но получилось достать не самым убого выглядящим способом параметры запроса. А ведь я от такого отвык — фреймворки-то обычно всё приносят на блюдечке!

Сваял приложение, понимающее запросы вида

GET <host>/?t=<URI_шаблона>&d=<URI_данных>

Добавил index.html с формой, которая бы отправляла соответствующие параметры с правильным url-encoding. MVP готово!

Продолжение следует...

Прождолжение про шаблонизатор. Начало — выше.

Итак, у меня есть CGI-app, который уже работает. Вот только толстоват он получился. Посмотрел я на зависимости, и взгрустнулось мне из-за того, сколько всего reqwest за собой тащит. Да, он мощный и универсальный, но мне не нужна вся эта мощь! Заменил на ureq — и как же удобно под присмотром компилятора делать такие изменения! Теперь уже сносно получилось, ни убавить, ни прибавить.

Сел думать, что бы ещё улучшить. Прикинул, что шаблоны обычно статические, а вот данные бывают параметризованы и не всегда только в query string, как бы мне при запросе данных ещё и JSON-body передавать. Пошёл прикручивать получение ещё одного параметра с url-encoded JSON c перенаправлением оного в качестве body по адресу для запроса данных (уже POST вместо GET). Реализовал. В тестовый index.html добавил формочку, посылающую GET и дающую приложить доп.нагрузку в виде url-encoded JSON. Изначально захотелось посылать запрос на https://httpbin.io/post, а потом полученный JSON уже в шаблон загонять. Вот только это зависимость от внешнего сервиса, а у меня уже есть CGI-сервер, вот он! Написал echo.cgi:

#!/bin/sh
echo ""
cat

Чуете мощь? Я чую! Можем дёргать GET, который пошлёт POST, мы прекрасны! Продолжаем улучшения!

Вводить payload в <input> показалось неудобно. Переделал на <textarea>, захардкодил многострочный пример входящего JSON, нажал в первый раз submit и... проиграл 🙊 Lighttpd не хочет принимать запросы, содержащие в query string коды перевода строки — самолично возвращает "Bad request". Оказалось, что нынче так не носят, поскольку query injections и вот это вот всё. Ещё одна шишка набита, урок выучен, учимся дальше.

Бросился добавлять поддержку POST в свою программку на Rust. Но, написав уже пару экранов кода, спросил себя, не распухает ли излишне моя поделка, призванная изначально быть маленьким и простым крипичиком для комбинирования с другими детальками? Откатил.

Решил сделать прослойку в виде get2post.cgi — CGI-скрипта на shell. Оный бы принимал POST-запрос с x-www-form-urlencoded параметрами, превращал JSON-тело в обычный url-encoded и дальше бы hb.cgi (так называется мой проект, потому что язык шаблонов у меня — Handlebars) ходил бы на полученный адрес через GET и не пробрасывал бы входящий JSON сам. Ну и дичь, подумаете вы, наверняка. А мне так захотелось.

Сел писать разбор query string на shell. Реализация вышла наивная и injectable, но заработала. GET к скрипту возвращал HTML с формой, где JSON был уже закодирован в URI для запроса данных — при генерации HTML опять пригодился m4, кстати. Но и этот вариант не завёлся. Потому что newlines из входного JSON опять оказывались в query string, которую затем не пропускал lighttpd 🙈 Но мосты уже горят, решил добить таки этот скрипт и выкрутиться упаковыванием payload в Base64 — ну что тут может пойти не так?

Да много чего! Например, пришлось отучать base64 не переносить строки в выхлопе, а то я получал бы обратно всё те же переводы строки проклятые! И тут я отдельно побился о то, что в MacOS утилиты все BSD, а не GNU, и флага, который запрещает при кодировании переносить строки, в BSD-версии кодека нет. Воспользовался gbase64, благо таковая имеется и это таки GNU-версия.

Теперь у меня был CGI-скрипт, который принимает

GET <host>/get2post.cgi?u=<URI_данных>&b=<Base64_encoded_body>

И делает POST за меня. Удобно, композабельно! Только Base64 blob может быть большим, поэтому поддежку POST я в свой Rust app всё равно добавил 🌚 Но при этом я обошёлся без добавления нового параметра для payload, только лишь разрешил всё те же два изначальных URI передавать как x-www-form-urlencoded и application/json. Чтобы понять, что мне подали на вход, я решил смотреть на Content-Type, как водится. И ударился о то, что lighttpd добавляет префикс "x_cgi_" к заголовкам перед передачей оных скриптам! Ок, это уже мелочи, добавил поддержку и такой дичи, если уж так принято.

Окончание начатого тут и тут.

Сейчас всё, что я успел наделать, лежит здесь.

Ещё предстоит добавить сборку релиза CGI app для Linux, чтобы моя песочница его переварила, но это уже скучная история 😅

https://github.com/astynax/hb.cgi

Рекомендаций пост: рекомендую почитать про Web Numbers. Там опять про Small Web говорится, да, но в контексте владения собственным адресом в том или ином виде. Вообще очень вдохновляющее чтиво, особенно если читатель пока не успел обжечься с "владением" чего-либо.

Идея использовать белые IP-адреса, которые выдаёт VDS-хостинг, напрямую и иметь в закладках адресную книгу малых сайтиков интересная. Но слабым местом всё ещё остаётся доверие провайдеру виртуалок. И я тут даже не о рисках утекания ваших данных говорю, а о том, что провайдер может решить перестать иметь дело с вами лично. И вы потеряете свой IP-адрес.

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

Так что проблема с "получением уникального личного имени раз и навсегда" всё ещё не решается. И не будет решена, пока законодательно этот вопрос не урегулируют тоже раз и навсегда, без пространства для лазеек — а уж в это вообще слабо верится.

С другой стороны, иметь ещё один способ поименовать себя в сети — неплохая идея. Можно иметь одновременно IP, домен, поддомен на small-web.org (см.статью) — три разные корзины лучше, чем одна, хе-хе. А использование SSL-сертификатов для IP-адресов позволит хотя бы отозвать таковой сертификат, если IP у вас отобрали. Что послужит для респондентов сигналом найти вас по альтернативному пути.

Вопрос о том, как эти самые альтернативные пути до респондента доносить, пока остаётся открытым. Тут как раз можно попробовать через OpenNIC (тоже в статье упомянут) завести себе домен, на нём поставить редирект на актуальный домен/IP. OpenNIC, кажется, не должны просто так лишать людей адресов направо и налево. Но стоит помнить, что, поскольку OpenNIC не дружит с HTTPS (см.сноску в статье, там описано, почему), доверять редиректам таким можно только с большой натяжкой: ну, вы знаете, MITM и проч.

И да, есть всякие децентрализованные способы заиметь адрес. В IPFS так IPNS-имена работают (тут можно почитать). Но это всё очень далеко от обычных людей, к которым поближе автор заглавной статьи хочет быть. Увы и ах.

Вчера на такого зверя наткнулся: https://agregore.mauve.moe

Этот тоже в Gemini умеет, хотя микровеб — и не основная функция софтины. Изначально это браузер для децентрализованного p2p веба на базе IPFS и Dat. И кажется мне, что одно другому не мешает: микровеб и p2p могут сосуществовать, и неплохо иметь обе штуки под рукой, иногда даже в одном ПО.

Печально только, что эгрегор на электроне сделан и вообще большая часть SDK и ПО вокруг упомянутого Dat — тоже на JS, взять хотя бы Cabal Chat. И SSB тоже на JS сделан. Ох, и любят эти децентрализованные ребятки на JS писать 😉

При этом JS в контексте Эгрегора я как раз понять могу: это не только браузер как таковой, это ещё и среда для запуска — и создания — p2p-приложений, которые хранят данные на "гипердиске" и распространяются сами по тому же IPFS, bitTorrent и им подобным. По задумке оно в должно работать так, чтобы я мог прямо у себя накидать прототип, сгенерировать ключ на гипердиске и послать другу. И вот мы оба уже имеем по копии моей программки. И если она выложена на IPFS, то пока софтина будет кому-то нужна, она будет существовать. Сам же Эгрегор предоставляет вполне человечные API для простого взаимодействия с p2p штучками, чтобы можно было, скажем, прямо из bookmarklet "сграбить" обычный сайт в WebArchive и загрузить на IPFS! Это один из немногих примеров настоящего живого использования встроенных средств JS-рантайма для своих маленьких нужд — а вы знаете, как я люблю "программируемые кнопки" и прочее "moldable software", потому и Emacs пользую 🤓

Внезапно захотелось потранслировать свои мысли по поводу того, что у меня сейчас крутится в голове вокруг smol software/web, permacomputing, malleable software, а именно — про Algernon, Agregor, Hyperclay. Причём я именно подумал об кого-то вслух, а то я подзаскучал в своей echo chamber, жажду общения :)

Пока думаю завтра в районе обеда (у меня это 12 GMT+4) стартануть и будет здорово, если кто-то придёт пообщаться! Но если вы вдруг очень хотите присоединиться, но время вам не подходит, пишите в комменты до того самого завтрашнего обеда :Р Запись будет, думаю, так что если кому-то именно посмотреть захочется, то и такая возможность останется.

Update по итогам:

Запись: https://t.me/c/1750847264/1087 ( https://youtu.be/PLltigzF2Ps )

Ссылки:

- What is the Small Web? – Aral Balkan
https://ar.al/2020/08/07/what-is-the-small-web/

- Kitten: Home
https://kitten.small-web.org/

- Agregore Browser IPFS Development Environment
https://agregore.mauve.moe/docs/tutorials/ipfs-browser-devenv/part-1

- HTML APPS | Hyperclay
https://hyperclay.com/

- Algernon
https://algernon.roboticoverlords.org/

- Decker
https://beyondloom.com/decker/

Ещё в кадре фигурировали мои программки на Elm, так что вот на них ссылки, чтобы были:
- Кубики для Берсерка: https://astynax.me/berserk-ru-dices/
- SameGame: https://astynax.me/elm-samegame/
- SafeBox: https://astynax.me/elm-safe/ (стрим с процессом создания: https://www.youtube.com/watch?v=yXlrUpfEQRE )

Обычные статейки в процессе, читателей прошу не пугаться! Например, надо уже про Fleet написать, раз его теперь закапывают, а ведь там и мой код есть!

Однако не могу не отметить, что и общение голосом в прошлый раз слушателям понравилось 😎 Во вторник буду опять стримить в 12:00 GMT+4. Не уверен, что успею завести Discord, так что велика вероятность, что в этот раз всё опять случится в Telegram.

Попробую и сам формат повторить: что-то покажу, потом просто оставлю голосовой чат в фоне и буду там разглагольствовать 😉

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

Если хотите ещё что-то конкретное обсудить, то пишите в комментарии — я всегда готов поговорить про разное. А ещё можете поделиться впечатлениями от прошлого захода — за это отдельно благодарен буду!

Завтра попробую сделать тестовый голосовой чат в "чате для комментариев к каналу" — там, кажется, получится сделать именно "voice chat". А не "stream", в котором нужно каждому давать право говорить. Знать бы ещё, как давать ссылки на сам чат, а не на посты из него (ох уж этот Telegram UX 🤡).

Беседе быть!

https://t.me/brain_dump_chat?videochat=7c26a7a3b78e97a676 вот тут начну вещать в 12:00 GMT+4

https://youtu.be/qtb4dtDoIdE — оно же на Youtube, друг ещё и на PeerTube выложил
Код весь живёт тут: https://github.com/astynax/shell-hell