В эфире рубрика "Кто о чём, а он опять о ритритах!". Новая смена через месяц, три трека: один просто хайковый, ещё один по 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 и вопроизводимые постустановочные настройки ОС.

Го, я создал!
- https://www.twitch.tv/astynax2hs
- https://discord.gg/tJvze5y5va

На твиче запись с недельку пролежит. Там в основном мои страдания, так что я не стал запись выгружать куда-то. Или стоило?