На тильде, где у меня есть аккаунт (про это всё я как-то писал) среди прочего ПО, на котором держится местный уютно минималистичный 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

Поздравляю всех читатетей с Наступающим Новым Годом! Буду продолжать вас развлекать и в 2026!

Тут исходник на Python, который я ещё и на no_std/Rust переписал.

Решил я недавно в очередной раз попробовать взращивать цифровой садик 🪴 (о том, что это, я писал тут) и совместить этот процесс с новой попыткой попользоваться TiddlyWiki.

TiddlyWiki — это приложение для ведения "нелинейных заметок". Но приложение особенное тем, что упаковано в самодостаточный HTML-файл, не требующий для работы никаких облаков. А ещё TW интересна тем, что это настоящее Malleable Software, а эта тема мне очень близка, недаром я использую именно Emacs! Если говорить кратко, то TW позволяет изменять и расширять себя без каких-либо искусственных ограничений. TiddlyWiki сама реализована на себе: код, шаблоны, стили оформления, plugins — всё это тоже заметки, которые можно в любой момент найти и отредактировать!

Отдельно стоит озвучить, что TW интерфейсно не разделяет автора и читателей. У читателя всего лишь нет возможности сохранить изменения (по умолчанию нет, но и это поправимо!). Таким образом читатель всегда видит не только контент базы заметок, но и само ПО, которое эту базу обслуживает. Читатель может сохранить копию себе и затем начать её модифицировать под свои задачи! Даже распространяется TiddlyWiki таким образом: можно скачать empty.html, где уже есть платформа, но нет контента. А ещё есть возможность начать и со сторонней "сборки".

Интересно сделана и подсистема сохранения изменений. Браузеры не позволяют странице записывать что-то на диск, но это может делать браузерное расширение. В крайнем случае можно просто предложить пользователь "скачать" и сохранить файл вручную. Со временем появились и другие savers, например очень удобная сохранялка, делающая коммит в GitHub по токену. Токен хранится в Local Storage браузера, вместе с настройками не утекает. А поскольку на GH сохраняется готовый HTML-файл, то оный можно сразу и раздать через GitHub Pages — и вот мы уже имеет готовую CRM для ведения публичной Wiki, цифрового сада, списка прочитанных книг и т.п! Вот это "минимальное трение" при ведении садика меня очень привлекает, так что свой сад я ровно таким способом и завёл.

Надо сказать, что о TW я знаю давно, видел садики на её основе не раз, но у самого как-то руки не доходили погрузиться глубоко. Но недавно я наткнулся на книгу Grok TiddlyWiki, которая, конечно же, оформлена как экземпляр TW, но помимо самого текста имеет ещё и встроенные упражнения и даже карточки с системой интервального их повторения — да, и такой plugin для TiddlyWiki есть! Причём книга не является перепечаткой официальной документации к проекту, это скорее очень авторский курс по тому, как думать о/в TW и как подстраивать её под себя — я такое очень люблю!

Собственно, когда я начал читать/проходить GTW, то встала необходимость каким-то образом захостить и учебник, и учебную тетрадьWiki. Ещё и эти две на GH я выкладывать не захотел, а пойти по рекомендованному в книге пути и завести аккаунт на специальном хостинге для TW тоже показалось не интересно, и я написал свой серверчик 😎. Сервер написан на Python, раздаёт HTML-файл по GET, а по POST сохраняет новую версию с резервным копированием нескольких свежих сохранений. Кода получилось на полтора экрана, всё на встроенных модулях!

Есть, правда, пока не решённая проблема с ведением нескольких Wiki под разными именами: комплектный saver отправляет довольно специфический POST запрос, мне ещё предстоит разобрать прилагаемый к нему form/multi-part, но это дело техники. И да, готовых приложений для локального поднятия TiddlyWiki уже существует несколько, но я захотел сделать свой минималистичный вариант, развлекаюсь 😜

Часика через два попробую запустить трансляцию в Twitch и голосовой канал в дискорд, там буду лайфкодить на питоне — доделывать свой серверчик для WiddlyWiki.

Сегодня мне хочется опробовать сетап для будущих тематических трансляций. Завтра как раз таковую планирую сделать, мне уже и тем подкинули: hotkey managers и вопроизводимые постустановочные настройки ОС.