​​Часть 2

Движок мой подразумевал то, что я скомпилирую его один раз, а ресурсы конкретной игры будут загружаться при запуске. А значит нужен был какой-то формат описания сцен, переходов, активностей. Выбрал я, конечно же, INI-файл — "искаропки", пишется в любом редакторе, секционность подходит для постраничной игры.

Имя секции соответствовало имени файла (его базовой части) изображения фона — вот вам "convention over configuration"! Первая сцена имела фиксированное имя "begin", соответственно подгружались файлы "begin.bmp" и "begin_m.bmp" — второй, это "маска", то есть тот самый невидимый слой с выделенными цветом объектами.

В секции писалось что-то такое:

[begin]
00FF00=j{waystone}
00FF00_h=Путевой камень
FF00FF=m{Бедный Ёрик}
FF00FF_h=Череп
FF0000=j{pogost}
FF0000_h=Дорога налево
FFFF00=j{rockwall}
FFFF00_h=Дорога направо

При перемещении мыши брался текущий цвет подложки, по нему как по ключу, доставались действие по клику и hint (всплывающая подсказка) для объекта: в примере эти ключ в формате RRGGBB и он же, но с суффиксом "_h" (hint). С текстом всё понятно, а действие "j{pogost}" означает "перейти(jump) к секции pogost".

Ключи секции, имеющие префикс "#", описывали "спрайты", то есть накладываемые на подложку объекты. Имя ключа (без префикса) служило именем файла, а значение было числом, которое в формате "640 * y + x" кодировало позицию спрайта относительно верхнего левого угла. Ага, тут я поленился вводить раздельное кодирование координат ;). Если же значение было меньше нуля, то спрайт не рисовался — так можно было показывать и прятать спрайты.

Вот вам спрайт дерева, которое рисовалось поверх пенька на стартовом экране (смотрите предыдущий пост).

Часть 3

Использование координат спрайтов, а точнее — их изменение, это уже попахивает переменными! Да, таковые я тоже предусмотрел. Даже секцию "vars" завёл, которая инициализирует все переменные игры. Переменные имеют префикс "$", могут встречаться в роли значений, а в секции "vars" в роли ключей. Тут всё понятно и просто.

Но переменные нужно изменять. Для этого я прикрутил целый мини-DSL. Тот самый "j{…}", упомянутый ранее, это команда языка как раз. Изменяла переменные команда "s{$x=y}" — тут тоже всё очевидно, надеюсь.

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

Предметы кодировались цифровыми идентификаторами, но по сути могли быть любыми валидными ключами: каждый идентификатор был ещё и ключом секции "invnames", значения в которой содержали имя предмета:

[invnames]
001=Ворота (украдены на кладбище)
002=Топор (взят в Пещере Гоблинов)
003=Дубовое бревно

А вот так выглядело срубание дерева на стартовом экране:

00FFFF=i{002}g{003}s{$tree=-1}.M{Вы срубили топором дуб и сделали из него бревно}
00FFFF_h=Сухое дерево (Дуб)
#tree=$tree

-   "i{002}" — если есть "топор",
-   "g{003}" — дать "бревно",
-   "s{$tree=-1}" — присвоить переменной $tree значение -1, то есть спрятать спрайт дерева,
-   "." — перерисовать сцену (максимально лаконично!),
-   "M{…}" — показать message box с указанным текстом.

"#tree=$tree" помещает спрайт дерева туда, куда указывает переменная. При перерисовке сцены переменная читается каждый раз, поэтому изменения и вступают в силу. Так на картинке первого экрана и появляется пень — просто пропадает дерево, выводимое поверх него!

Команды языка пишутся без каких либо разделителей потому, что INI-файлы не предполагают многострочных литералов. Такое вот творчество в условиях ограничений :)

Часть 4

Язык сценариев получился вполне себе выразительный — для данной задачи, конечно же. Можно было описать довольно сложные сценарии.

Например, в игре вы шли на кладбище, брали там ворота (дверцу калитки), шли с ней к пещере со рвом перед входом, перекидывали калитку через ров на манер моста, и попадали в пещеру. Тут вам и взятие объектов и выбрасывание ("d{id}"), условные переходы, опять же.

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

С технической стороны всё получилось максимально прямолинейно. Парсер DSL у меня был однопроходный — просто посимвольно обходил строку однократно, сразу же выполняя команды. Никаких грамматик, никакого backtracking: я и слов-то таких не знал тогда — имел то, до чего додумался сам. Зато было весело!

Игру саму я тогда не доделал, конечно. Допилил движок, и игра стала "реализуема". Дальше уже наступал черёд игрового дизайнера и сценариста, затем — художника. А вот эти роли мне были не так интересны, поэтому игра осталась в виде "proof of concept" с четырьмя игровыми экранами. Но своё удовольствие я получил. И догадался сохранить исходники, что позволило в итоге написать эту серию %^D

​​Рубрика "ссылка на видео"!

Let's Reverse: Adventures of Lomax graphics — интересный и довольно необычный скринкаст (куда уж без стримов сейчас?) разбора одной старой игры (The Adventures of Lomax от крутейших Psygnosis) на предмет того, как игра хранит графику.

Зрелище само по себе нескучное, особенно если вы интересуетесь #reverse_engineering, но в этот раз ещё и инструментарий использован примечательный: вся работа делается в IPython REPL. И не в Jupyter, а именно в текстовом режиме — текстом выводятся гистограммы, палитры, даже сама графика! Используется для всего этого фреймворк Mr.Crowbar, предоставляющий eDSL (автор вдохновлялся Django ORM, %)), с помощью которого вы жонглировать байтиками, описывать структуры и обрабатывать их так, как Web-разработчики работают с моделями ORM. Собственно это видео как раз и записано автором фреймворка как demo для "Мистера Фомки".

Сам я положу Mr.Crowbar в копилочку, а вам желаю приятного просмотра! А может быть даже и вдохновлю кого-то (менее ленивого, чем я) что-то эдакое пореверсить >;^F

#python #gamedev #video

Выступил на днях на online встрече FProg SPb. Рассказал про #gamedev на #racket — ага, как обычно, про что-то странное :)

Целью ставил перед собой демонстрацию искоробочных возможностей Racket в роли платформы для образовательного игростроя: показал, как можно использовать "How to Design Programs" Teachpacks в начале для рисования картинок, а позже уже и для создания клиент-серверной игры!

На всех уровнях (картинка, анимация, игровой мир, игровая вселенная) эти teachpacks предоставляют хорошо продуманные абстракции. Которые ученики могут в последствии использовать в качестве источника вдохновения при построении других программ. Собственно, потому курс и называется "How to Design Programs" ;)

Курс, кстати, очень хорош. Крайне рекомендую к ознакомлению — даже если вы уже знаете, как дизайнить эти ваши программы! Хорошо смотрится и продолжение "How to Design Classes", но про него я только наслышан и "подглядывал", зато знаю, что этот курс использует семейство диалектов Java, реализованное в Racket. Языки под тему — это в целом общий для обоих курсов приём: на каждом этапе обучения используется специально ограниченный язык, чтобы ученики не забегали вперёд и оставались в рамках темы. Каждый последующий язык-под-тему расширяет предыдущий, поэтому получается и видеть разницу, и одновременно наследовать опыт (объектненько!).

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

Этот же подход к языкам-темам присутствует в книжке "Beautiful Racket", которая вообще проповедует Language-Oriented Programming. Когда устаёшь от формошлёпства через ямлодокеры, такие "параллельные миры" могут стать отлично отдушиной. Так что я и книжку рекомендую, да.

Ну вот. Хотел просто запостить ссылку на видео про геймдев, а в итоге скатился в образование и саморазвитие. Ну и ладно, блог мой, поэтому могу!

#education #racket #gamedev

​​Есть такой протокол — Gopher). Отвечает за передачу текста поверх TCP/IP и организацию навигации через некое подобие меню. Был изобретён ещё до этого вашего HTTP, подходил для текстовых терминалов, но потом был благополучно забыт, уступив место привычному Вебу.

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

Но даже основные функции старичок Gopher реализует по-старинке : ни вам rich content, ни какой либо безопасности. И Unicode тоже нет. Вон, даже FTP дорос до SFTP, а не смог. И всё сложнее себя заставить использовать протокол не только лишь ради самого процесса использования.

И тут на сцену выходит Gemini — идейный наследник Гофера, "новый простой Web". Посудите сами:

-   есть статусы как в HTTP, но их меньше и сами они проще и однозначнее,
-   основной контент кодируется текстовым форматом text/gemini, который похож на Markdown (только строго построчный и минималистичный),
-   передавать можно не только текст, MIME-types поддерживаются,
-   TLS со стороны сервера обязателен, так что секурненько,
-   вместо cookies используется клиентский TLS, то есть клиент решает, когда ему менять identity — уже просто так не потрекаешь!

Протоколу Gemini недавно исполнился год, но активности в сообществе уже довольно много: люди ведут дневники (gemlogs), держат Gemini-зеркало Википедии, пишут серверы и клиенты на разных языках. Есть у "нового Веба" и поисковики, и каталоги ссылок (помните, что это такое?). Посерфить можно через прокси с помощью обычного браузера или сразу установить один из Gemini-браузеров, словом, есть и контент и средства для его потребления. Да, движение молодо, но энергией оно пока полнится!

Я и сам как-то подустал от современного Web со всей его сложностью, так что изучаю всё это "околоблизнецовое" с неподдельным интересом. Хочу поднять свой ресурсик и зеркалировать туда да хоть вот этот самый канальчик. В качестве языка возьму Rust или Haskell, а серверную реализацию напишу, неверное, сам — так интереснее! Так что, как г-рится, stay tuned!

А вам предлагаю почитать спецификацию протокола, а затем прогуляться по Gemini Gateway дабы познакомиться с сообществом и экосистемой.

​​А помните, как вы подключались к UNIX-машине под своим пользователем и делили ресурсы машины с десятком-другим таких же жильцов этой цифровой коммуналки? Я не помню: не застал :) Но наслышан и имел пунктик приобщиться к чему-то такому однажды. Так вот, я нашёл возможность!

В 1990е на больших машинах с кучей пользователей их (пользователей) Web-страницы на общем хосте имели адреса вида host.dom/~username и тильда явно выделяла имя пользователя. Это были так называемые "tilda sites". И вот в 2014 некий Paul Ford интересу ради решил воссоздать явление в миниатюре и создал <https://tilde.club>. Вы могли попросить завести вам учётную запись и получали в итоге доступ на сервер по SSH. А далее вы брали в руки $EDITOR и писали себе страничку на старом добром HTML — романтика! Сервер заработал, и, как говорится, завертелось! Больше про историю "появления явления" можно почитать тут, а я закончу сий экскурс в историю.

Сейчас Tilde-серверов существует достаточное количество. Практически каждый из них, это обычный компьютер, который не выключают на ночь. Поэтому от сотен пользователей машины ожидается соблюдение определённых норм и правил — проще говоря, монополизирование ресурсов машины не приветствуется. Ресурсы — общие и используются сообща, цифровой коммунизм :) На что же хватает ресурсов одной не самой мощной машины? На типичном tilde-сервере есть Web-сервер страниц пользователей (кто бы сомневался?), Wiki, IRC-подобный чат между пользователями (снаружи машины не доступен), столь же локальный BBS-подобный форум, нередко — какие-то многопользовательские игры с текстовым интерфейсом (ага, MUD). Кто-то дополнительно разворачивает сервисы вроде Gitea, поднимает сервер Minecraft, ноду Mastodon).

Если вы вдруг решите приобщиться и завести себе учётку на какой-нибудь тильде под управлением OpenBSD, то вам стоит пройти сюда: <https://tildeverse.org/> Это хаб сообщества, на котором вы сможете найти себе сервер по вкусу. Или, скажем, почитать тематический zine.

Я лично себе заимел учётку на <https://tilde.town>. Это Linux-машина, так что всё привычно. Общая атмосфера — нарочито дружественная, все занимаются забавными пустяками, вроде рисования своих вагонов к ASCII-паровозу (для этого нужно правильно названный текстовый файлик иметь в $HOME) или коллективного написания IF-истории про космос и голопалубы.

Моя страничка пока выглядит так, HTML для неё я сгенерировать скриптом на #racket. Генерировал на своей машине, но при желании смогу сделать это и с сервера: Racket на машине имеется, также как и GHC, не говоря уж про прочие пайтоны. Местный зоопарк языков вполне неплох, так что можно покодить что-то не сильно нагружающее машину, не выходя из терминала (Vim и Emacs тоже имеются). Имейте в виду, если вдруг захотите сгенерировать "хомяка" программой на BASIC :)

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

А ведь вообще-то я сейчас глубоко закопался как раз в то, для чего я и создавал этот канальчик: в выгрузку из внутреннего органического мозга во внешний "мозг", как говорят, exo brain. Я уже пробовал и блоги вести и просто "сайтов" сделал парочку. Но все начинания упирались в то, что мне сложно себя приучить писать много текста и делать это часто.

А меж тем, мне и статьи интересные попадаются, и видео, и книги в конце концов. Но просто вести канал с записями вида "вот ссылка на смешной видос" мне совесть не позволяет, заставляет как-то перерабатывать материал. Вот так и копятся идеи, TODO в org-файлике, закладки в браузере. И голова пухнет — череп жмёт :) Нужно сливать излишки почаще, пусть даже в менее структурированном виде!

Вот только блог не подходит для структурирования: далеко не всё хорошо ложится на одну ось, в роли которой выступает время. Вот даже интересная статейка про то, как блоги убивают интернет. И вообще, нынче модно разводить Цифровые Сады (#digital_garden). Про это явление можете почитать здесь. Суть: вручную и с любовью выстроенная структура, цветущая информация, засыхающие пережитки прошлого — красиво, эко, завлекает! Погружался и в сады, долго выбираться пришлось :)

Садоводы правы в том, что в голове вообще нет единой цепочки, есть островки и мосты. Вот и exo brain в моём понимании должен быть больше похож на граф — на неструктурированный гипертекст в котором ссылки могут быть даже важнее прочего содержимого.

Среди тех, кто ведёт свои базы знаний и выгружает мозги, многие используют Wiki Software в роли хранилища. Я на такой вариант тоже смотрел. Вот только иметь именно сервер да ещё и со встроенной CMS мне не хочется, поэтому пока я отложил и написанный на #Haskell Gitit и минималистичный Ikiwiki (этот ещё и на Perl, что мне не очень нравится). Нашёл парочку решений, умеющих сгенерировать Wiki-подобный сайт в статическом виде, но решения эти скорее мертвы, чем живут, а я пока не готов подхватывать чужой проект. Штуки вроде TiddlyWiki меня не устраивают тем, что это вещи в себе, а мне хочется писать код в любимом редакторе (#Emacs, конечно же). Да, Emacs позволяет выгружать контент страниц в форматах многих "вик", но я хочу сам управлять в том числе и структурой, а не только содержимым.

Ещё один популярный способ хранения сливок — иерархические заметочники (outliners) тоже существуют. Те же Org Mode, или Joplin. Эти, правда, тоже слегка навязывают структуру и строго одну. Да, можно использовать теги и делать по ним группировку, но чувствуется любой отход от изначальной идеи чужеродно.

Учесть сервисы, кто-то нынче использует Notion (ссылку не даю, и так все знают про него), другие всё ещё сидят в Evernote. Тут тоже теги, блокноты, структура. Из новых сервисов в изрядном почёте ходит Roam. Главная фишка последнего — автоматические обратные ссылки. Вы ссылаетесь в одном куске информации на другой, а тот получает ссылку на первый (в обратную сторону получается связь "один-ко-многим"). Вот тут неплохой мастеркласс по Roam, советую глянуть — прочувствуете идею, так сказать. Обратные ссылки, это "новый чёрный" в среде заметколюбов, их уже и в Notion анонсировали, и другие игроки подтянутся, я уверен.

(продолжение следует)

(продолжение)

И всё бы ничего, вот только Roam стоит не таких уж маленьких денег, да и является закрытым внешним сервисом. Что лишает меня контроля — да, я хочу контролировать и этот аспект. Народ создаёт свои аналоги, например, Athens (опенсорс на #Clojure!), но ждать их взросления долго. Зато Athens можно будет хоcтить и у себя, так что я лично послежу. Себе же взял OrgRoam — надстройку над Org Mode, которая добавляет обратные ссылки и убирает структуру (за счёт отказа от одного outline в пользу отдельных файлов). Пробую что-то записывать, может быть прикручу публикацию в таком виде — минималистично, статично, обратно-ссылочно! А может быть и откачусь на голый Org, буду всё держать в больших файлах — так тоже живут (внимание, это тоже кроличья нора, легко провалиться).

Есть ещё одна опция: самодельное решение. Так тоже делают. Плюс тут один: полный контроль над всеми аспектами. Делай себе инструменты сам, как говорят (и пишут). И над этим вариантом я тоже думаю. Может получится скрестить Gitit и Org Mode в то, что подойдёт лично мне…

Вот, дампнул немножко мозгов. Сумбурно вышло, но пока я не готов это структурировать — сначала нужно придумать, как! ;)

Ох уж этот Телеграм, даже лонгрид достаточно лонг не напишешь...

Как только написал предыдущую "портянку", постучались читатели и поделились опытом! Ух, значит не просто так воздух сотрясаю! Спасибо, приятно :)

Спросили, почему не использую Telegra.ph или другие внешние сервисы, которые позволяют писать тексты, более длинные чем одно сообщение в Tg. Отвечаю: я не хочу завязываться на ещё один (помимо, собственно, Телеграма) внешний сервис. Я и посты держу в локальном .org-файле, пишу новые в нём же, экспортирую в Markdown и публикую уже готовый текст. Это позволяет иметь резервную копию и опубликовать контент где-то в другом месте при желании и/или необходимости.

А ещё мне скорее даже нравится наличие ограничений, которые Телеграм накладывает на контент: нельзя "затвориться" и написать такое сообщение, которое будет уже неудобно читать из-за размера или форматирования. Так что я негодую по поводу размера лонгридов больше для вида: недавний пришлось делить не там, где я хотел, а там, где пришлось, вот и взгрустнул.

Ещё я не могу не поделиться тем, с чем поделились со мной.

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

Ещё мне предложили приобщиться к проекту MycorrhizaWiki. Это самодельный Wiki-движок, хранящий данные в обычных файлах, использующий Gemini Text (я про Gemini писал, если помните) в качестве разметки, и очень легковесный. Обязательно посмотрю! И вы посмотрите. У разработчиков есть телеграм-чат, если что.

Gemini, кстати, это тоже хороший повод заморочиться своими движком и хостингом: иметь поддержку протокола хочется, а никакой GitHub пока в нём не вещает! А ведь было бы здорово получить хранилище, в которое можно ходить по таким легковесным каналам. Получил информацию для размышления, записал в Org Roam, буду переваривать!

Нынче Hacktoberfest выдался своеобразный: пуллреквестил я в свои же репозитории. Да, не очень красиво, но тут я хотя бы нашёл повод оживить пару своих проектов. Даже сделал целый issue и получил PR в ответ — ура, движуха! Напишу про прогресс в паре проектов.

В tea-combine добавился пример с рекурсивным типом модели. Получилось неплохо, на мой взгляд. В процессе добавления примера с эффектами пришлось дописать забытый комбинатор для subscriptions. Заодно переделал генерацию примеров на идиоматичный Makefile, теперь надо будет CI прикрутить.

Напомню, TEA Combine — это библиотека комбинаторов, упрощающая сборку сложносоставных приложений в парадигме The #Elm Architecture из не сильно зависимых кусков. Упрощает клепание интерфейсов с вкладками, например: можно разрабатывать каждую вкладку полностью независимо и не думать об увязывании созданных вкладок в общее приложение. А ещё, как мне кажется, довольно неплохо получилась композиция форм и binging их содержимого.

...

...

В Hemmet добавил генерацию обычного DOM с отображением в HTML, CSS и Elm.Html. Этот вариант генерации давно напрашивался, а то BEM-шаблоны сильно "нишевыми" оказались (об этом ниже), и вот я добрался до него, наконец. Заодно код порефакторил, перевёл проект со Stack на новый Cabal, а в Emacs наконец прикрутил #Haskell Language Server — и одно с другим вполне состыковалось, проект я продолжил пилить по-новому да по-модному!

Hemmet — генератор разметки разных видов по однострочным шаблонам. Копирует идею Emmet и ZenCoding, и несколько расширяет её за пределы вёрстки для Web. Так, сейчас можно генерировать деревья на подобие тех, которые выдаёт tree(1), а также выдавать bash-скрипт, который требуемую структуру директорий и файлов воссоздаст на диске. А теперь можно генерировать и обычную HTML-разметку в том числе и в виде Elm.Html (eDSL для Elm).

Изначально же Hemmet я сделал для того, чтобы на одной из прошлых работ быстро переверстать в формате React Flux (это такой eDSL для Haskell) то, что выдал профессиональный верстальщик в виде HTML/CSS. Оригинальный макет был свёрстан с применением БЭМ, что добавляло "веселья". Поэтому исторически Hemmet и поддерживает БЭМ — поддерживает программиста, вынужденного этот подход использовать. Hemmet следит за тем, чтобы блоки содержали элементы, миксы, модификаторы, и автоматически формирует все эти длиннющие имена классов — нам это сильно упростило жизнь тогда. А с тех пор я БЭМ так и не использовал ни разу :)

Файловые деревья — та фича, которую использую конкретно я больше всего. Я даже прикрутил возможность генерации структур в стиле Haskell и Python: имена нужным образом оформляются, добавляются файлы вроде __init__.py — удобно!

А ещё у Hemmet есть TUI, т.е. можно прямо во время набора шаблона видеть результат его разворачивания!

Вот так TUI для Hemmet выглядит в живую. В записи показано, как работает генерация bas-скрипта, формирующего иерархию директорий и файлов. Затем вывод специализируется для Python, что позволяет нагенерировать ещё и инициализирующие модули для нужных пакетов.

https://asciinema.org/a/365732

​​На волне желания выгружать мозг, про которое я писал давеча, я таки сподобился завести Wiki.

Взял Gitit, запаковал в Docker, развернул на Dokku, который у меня уже давно вертится в дроплете на DigitalOcean. Так как хранить данные сразу было решено в Git, а именно — в GitHub, то пришлось научиться

-   заводить в GitHub ключи для деплоя,
-   пробрасывать эти ключи в Docker-образ,
-   импортировать ключи и вообще работать с SSH из контейнера — добавлять сайт в known_hosts, и всё такое прочее.

Репозиторий пока синхронизируется только в одну сторону — push после каждого изменения. Как делать pull, я пока ещё не определился. Может git-sync возьму.

Но в итоге я доволен тем, что в итоге всё получилось. Теперь Wiki живёт тут: wiki.recursive.one. Да, лого и favicon навекторил тоже я сам, не удивляйтесь ;)

Ведём вики мы вдвоём с товарищем. Планируем использовать как базу знаний, но может я и цифрофой сад посажу там же — посмотрим. И обратные ссылки я тоже реализую, как только придумаю как.

Да, я знаю про опечатку.

Но поправить не смогу без потери прикреплённой картинки: при редактировании сообщения Telegram заменяет прикреп на превью первой же ссылки из текста. Если закрыть превью, то не будет прикреплено ничего. Вот такой вот UX...

Ну да ладно, я привык.

​​Не могу не поделиться, отличная картинка и прям про меня!

Я как раз нахожусь в правом нижнем углу: вместо того, чтобы писать регулярно, используя единожды настроенное окружение, я раз за разом настраиваю новое — мне просто больше нравится процесс создания этого самого окружения, чем его последующее использование :)

Когда-то, году эдак в 2012 я поднял свой первый блог на Pelican. Сразу статический сайт, раздаваемый с GitHub pages, комментарии на базе disqus (тогда это было не стыдно делать). Начал писать статьи, выдал штук десять, причём длинных — пяток от силы. В основном же писал про то, как я где-то там выступил, и прикреплял слайды — просто чтобы не размещать их где-то отдельно.

Потом Pelican мне поднадоел, да и #haskell хотелось уже применить в бою. Перевёл блог на Hakyll, благо Markdown в качестве исходников был. Комментарии — с десяток за всё время — смигрировал, это тоже было не скучно: выгрузить в CSV, прогнать скриптом, загрузить обратно (Disqus тут соломки подстелил). В этот новый блог писал всякую мелочь, но зато поигрался со входными форматами: и в Org mode статейки были, и на Literate Haskell — и это тоже "процесс важнее результата".

Сейчас пишу сюда. И тут отсутствие возможности что-либо настраивать и менять движок пока останавливает от новых переездов :) Впрочем, контент можно выгрузить да и исходник всё равно храню в .org-файле. А комментарии я не прикручиваю принципиально — те, кому хочется что-то сказать, пишут в личку (редко, но метко!).

Помимо блог(а|ов) делал себе сайтики, несколько штук уже. И все — разными способами (ага, опять):

-   astynax.me генерируется самодельным генератором на Haskell, и это вообще квинтэссенция поднятой сегодня темы — контента нет совсем, зато движок делать понравилось :)
-   recursive.one генерируется с помощью Pollen, про это я писал ранее. Тут я тоже поигрался и с движком, и с Dokku (тоже см. выше). Контента опять нет, удовольствие от процесса получено
-   tilde.town/~astynax генерируется не с помощью Pollen, но с помощью x-exps, его я тоже упоминал
-   astynax.neocities.org вообще вручную свёрстан, ибо сама площадка обязывает :)

Теперь вот ещё и wiki завёл, пишу туда, нравится (в дурку пока не забрали©). А ведь тоже радовался процессу выбора инструмента, разворачиванию, написанию про разворачивание — всё как на картинке! :^D

Занялся добавлением контента по #racket на CodeBasics.

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

Сейчас пишу про списки, параллельно сижу в Racket Repl, выбираю, про что и как рассказывать. И мне положительно нравится рэкетова система контрактов тот факт, что оная прикручена к стандартной библиотеке. Насколько приятно видеть такую ошибку — не передать!

> (first (cons 1 2))
; first: contract violation
;   expected: (and/c list? (not/c empty?))
;   given: '(1 . 2)

(and/c list? (not/c empty?)) означает "список И НЕ пустой" — максимально понятно, даже не нужно словами описывать дополнительно! Но кое где и словами описано: вот, например, вызов map с неравными по длине списками:

> (map + '(1 2 3) '(10 20))
; map: all lists must have same size
;   first list length: 3
;   other list length: 2

Это тоже проверка предусловий, но тут ещё и сообщение сделано вручную, с ориентацией на новичков. Вот что значит — учебный язык!

Система контрактов в Racket довольно таки развесистая. Можно даже делать контракты, согласно которым в функции ветвление будет организовано — можно почти pattern matching делать и multi clause функции!

Да, это "не настоящие типы" и проверки будут производиться во время исполнения. Но TypedRacket может использовать некоторые контракты при выводе типов, если я правильно помню. В любом случае, это интересная особенность языка, а я такие штуки люблю!

​​Всё же в #racket есть очень забавные штуки прямо в стандартной библиотеке.

Одни только for/smth чего стоят! Прикреплю решение одной из моих любимых задачек на паре этих самых for loops. Но у Racket есть for loop для promises, например — вот это уже на грани :)

​​Накидал на днях прототип ещё одной реализации моего давнего проекта PixCell, все ипостаси которого реализуют простой редактор Pixel Art в виде Web-приложения.

Изначально концепция была такая: сделать такое приложение, которое будет всё состояние хранить в адресе страницы, без cookies, без local storage, без какого-либо состояния на сервере. Закладки в браузере вместо сохранения результатов работы, история браузера вместо Undo/Redo — как вам такое? На мой взгляд, весьма забавно!

Так как я не особенно люблю и умею во внутрибраузерные технологии, а также забавы ради, делал я предыдущие реализации исключительно на серверной шаблонизации: каждый клик по пикселю, смена цвета или инструмента просто заставляли перезагружать страницу — старая школа, Web 1.0. И верстал на таблицах всегда, конечно же — для аутентичности!

А тут решил таки сделать такую версию, которая была бы представлена самодостаточной HTML-страницей (один файл без ресурсов), которую можно было бы сохранить локально и использовать без подключения к Сети. Поэтому делать решил на #elm. Так как планировал пользоваться сам, в том числе и на планшете, то задумал сделать всё на SVG, чтобы масштабировалось произвольно.

Текущую версию можно пощупать тут: https://astynax.me/pixcell-elm

Пока не реализовано сохранение результата, планирую сделать выгрузку в PNG и SVG. Возможно, добавлю возможность делиться результатом через сохранение состояния в URL и загрузки из оного при открытии страницы. А ещё подумываю заменить Unicode-символы на кнопках инструментов на нормальные пиктограммы — может даже в PixCell и нарисую ;)

Вот такой вот проектик выходного дня: большую часть за один день накидал, и то возился в основном с генерацией SVG руками без обёрток.