Я почему-то всегда думал, что я уже писал здесь про Propeller и саму контору Parallax. Оказалось — нет, не писал. Восполняю пропуск!
Есть такая фирма, Parallax. Занимается разработкой своих линеек микроконтроллеров, а также наборов для обучения робототехнике.
Эпоха Stamps
В 199х Parallax была известна своими BASIC Stamp — это такие микроконтроллеры, которые работают под управлением специализированной версии #BASIC. Каждый контроллер выглядел, как 24-ногая микросхема (на самом деле это была маленькая платка), которая для работы требовала только батареи на 9В. Достаточно высокоуровневый, язык PBASIC позволял управлять множеством видов периферии, код загружался в ППЗУ по последовательному порту (позже через USB2UART), а ведь до Arduino оставался ещё десяток лет! Платформа была достаточно популярна тогда, но имеет своих почитателей и сейчас.
В 1997 году Parallax запустили образовательную программу "Stamps in Class", которая знакомила учеников с микроконтроллерами, основам разработки программ и электронных схем. Ученики даже программировали роботов Boe-Bot (один из самых популярных продуктов Parallax), имеющих BASIC Stamp 2 в роли "мозга".
Что интересно, по началу BASIC Stamp и BASIC Stamp 2 делались на баже микроконтроллеров PIC, которые устанавливались на ту самую плату-сборку, имитирующую DIP-корпус. Позже Parallax начали применять свой собственный PIC-подобные контроллеры Parallax SX, и продолжали применять до 2009г, когда чипы были сняты с производства.
В 2002г Parallax сделали смелый шаг — выпустили Javelin Stamp. На этот раз "почтовые марки" предлагалось программировать на Java! Да, это была урезанная версия и языка и платформы, но всё равно это было впечатляюще!
А потом в 2006г stamps наконец перешли на Parallax Propeller и язык Spin. Об этом в следующем посте <музыка из JoJo>
Есть такая фирма, Parallax. Занимается разработкой своих линеек микроконтроллеров, а также наборов для обучения робототехнике.
Эпоха Stamps
В 199х Parallax была известна своими BASIC Stamp — это такие микроконтроллеры, которые работают под управлением специализированной версии #BASIC. Каждый контроллер выглядел, как 24-ногая микросхема (на самом деле это была маленькая платка), которая для работы требовала только батареи на 9В. Достаточно высокоуровневый, язык PBASIC позволял управлять множеством видов периферии, код загружался в ППЗУ по последовательному порту (позже через USB2UART), а ведь до Arduino оставался ещё десяток лет! Платформа была достаточно популярна тогда, но имеет своих почитателей и сейчас.
В 1997 году Parallax запустили образовательную программу "Stamps in Class", которая знакомила учеников с микроконтроллерами, основам разработки программ и электронных схем. Ученики даже программировали роботов Boe-Bot (один из самых популярных продуктов Parallax), имеющих BASIC Stamp 2 в роли "мозга".
Что интересно, по началу BASIC Stamp и BASIC Stamp 2 делались на баже микроконтроллеров PIC, которые устанавливались на ту самую плату-сборку, имитирующую DIP-корпус. Позже Parallax начали применять свой собственный PIC-подобные контроллеры Parallax SX, и продолжали применять до 2009г, когда чипы были сняты с производства.
В 2002г Parallax сделали смелый шаг — выпустили Javelin Stamp. На этот раз "почтовые марки" предлагалось программировать на Java! Да, это была урезанная версия и языка и платформы, но всё равно это было впечатляюще!
А потом в 2006г stamps наконец перешли на Parallax Propeller и язык Spin. Об этом в следующем посте <музыка из JoJo>
(продолжение предыдущей записи)
Эпоха Propeller
Propeller, это уже полностью детище самой Parallax, микроконтроллер с процессором 32-битной RISC-архитектуры, имеющим восемь ядер (2006г, напомню!). Программировался контроллер на своём ассемблере, а также на отдельном языке Spin — всё это, а также IDE для Spin разработали сами Parallax!
Для чего же микроконтроллеру восемь ядер, спросите вы? Ответ на этот вопрос и делает Пропеллер таким интересным! Дело в том, что Propeller не нёс на своём борту выделенных аппаратных шин, вроде UART, SPI и i2c: вместо этого предлагалось реализовывать соответствующие шины программно и поручать их обслуживание отдельным ядрам! Даже вместо прерываний и таймеров предполагалось использовать именно отдельные ядра. Потенциальные возможности поражали, ведь получился "почти ПЛИС", только программируемый на процедурном языке: представьте, что вы можете сделать контроллер с семью последовательными портами (одно ядро будет таки выполнять вашу программу) или что-то вроде "3 SPI + 2 TWI + 2 Dallas 1-wire"!
Кроме того, разные ядра могли по-разному тактоваться, что сильно упрощало формирование видеосигналов разных форматов. Или, скажем, цифрового звука.
Ввод-вывод был организован через один общий 32-битный порт со специальной подсистемой, защищающей от конфликтов при совместном доступе. Каждый из 32 пинов мог выдавать ШИМ!
Сам Spin был высокоуровневым языком, компилирующимся в байткод, который и выполнял Propeller на отдельных ядрах (их называли Cogs) — по интерпретатору на ядро. Язык использовал отступы для обозначения блоков, в коде допускались ассемблерные вставки.
Со временем появились компиляторы для C и PropBASIC (специальный диалект для Propeller), пара реализаций #Forth и прочие менее успешные поделки вроде подмножеств Pascal и Java.
Увы, железка получилась слишком уж специфической: для новичков она была сложна (трудно в голове уложить восемь программ), а для промышленности — слишком необычна. К 2010ым производство свернули.
В 2014 Parallax открыла под GPL 3.0 как всё ПО, так и всё "железо": код интерпретатора Spin, сред разработки, Verilog-описание процессора, HDL-файлы для обвеса. Так что Propeller 1 теперь полностью открыт. Хотя бы это радует!
Parallax тогда же объявил, что теперь они занимаются разработкой нового Propeller с производительностью 200 MIPS/Cog (вместо 20 MIPS на ядро у Propeller 1). Но я не знаю, в каком состоянии сейчас проект находится
Вторая жизнь Propeller 1
Так как платформа открыта, энтузиасты воплощают её в том или ином виде на FPGA. Есть и коммерческие реализации. Например, Soft Propeller от Trenz-Electronic — реализация Propeller на базе Xiliz Zinq (я как-то писал про Pynq — ПЛИС из этого же семейства, программируемый на Python). Что интересно, Soft Propeller физически совместим со старым "пропеллерным" железом: платка с ПЛИС, выполнена в том же формфакторе Narrow DIP, в котором выпускался оригинал, и может быть просто вставлена на место старого чипа! Люблю такое!
Эпоха Propeller
Propeller, это уже полностью детище самой Parallax, микроконтроллер с процессором 32-битной RISC-архитектуры, имеющим восемь ядер (2006г, напомню!). Программировался контроллер на своём ассемблере, а также на отдельном языке Spin — всё это, а также IDE для Spin разработали сами Parallax!
Для чего же микроконтроллеру восемь ядер, спросите вы? Ответ на этот вопрос и делает Пропеллер таким интересным! Дело в том, что Propeller не нёс на своём борту выделенных аппаратных шин, вроде UART, SPI и i2c: вместо этого предлагалось реализовывать соответствующие шины программно и поручать их обслуживание отдельным ядрам! Даже вместо прерываний и таймеров предполагалось использовать именно отдельные ядра. Потенциальные возможности поражали, ведь получился "почти ПЛИС", только программируемый на процедурном языке: представьте, что вы можете сделать контроллер с семью последовательными портами (одно ядро будет таки выполнять вашу программу) или что-то вроде "3 SPI + 2 TWI + 2 Dallas 1-wire"!
Кроме того, разные ядра могли по-разному тактоваться, что сильно упрощало формирование видеосигналов разных форматов. Или, скажем, цифрового звука.
Ввод-вывод был организован через один общий 32-битный порт со специальной подсистемой, защищающей от конфликтов при совместном доступе. Каждый из 32 пинов мог выдавать ШИМ!
Сам Spin был высокоуровневым языком, компилирующимся в байткод, который и выполнял Propeller на отдельных ядрах (их называли Cogs) — по интерпретатору на ядро. Язык использовал отступы для обозначения блоков, в коде допускались ассемблерные вставки.
Со временем появились компиляторы для C и PropBASIC (специальный диалект для Propeller), пара реализаций #Forth и прочие менее успешные поделки вроде подмножеств Pascal и Java.
Увы, железка получилась слишком уж специфической: для новичков она была сложна (трудно в голове уложить восемь программ), а для промышленности — слишком необычна. К 2010ым производство свернули.
В 2014 Parallax открыла под GPL 3.0 как всё ПО, так и всё "железо": код интерпретатора Spin, сред разработки, Verilog-описание процессора, HDL-файлы для обвеса. Так что Propeller 1 теперь полностью открыт. Хотя бы это радует!
Parallax тогда же объявил, что теперь они занимаются разработкой нового Propeller с производительностью 200 MIPS/Cog (вместо 20 MIPS на ядро у Propeller 1). Но я не знаю, в каком состоянии сейчас проект находится
:(Вторая жизнь Propeller 1
Так как платформа открыта, энтузиасты воплощают её в том или ином виде на FPGA. Есть и коммерческие реализации. Например, Soft Propeller от Trenz-Electronic — реализация Propeller на базе Xiliz Zinq (я как-то писал про Pynq — ПЛИС из этого же семейства, программируемый на Python). Что интересно, Soft Propeller физически совместим со старым "пропеллерным" железом: платка с ПЛИС, выполнена в том же формфакторе Narrow DIP, в котором выпускался оригинал, и может быть просто вставлена на место старого чипа! Люблю такое!
Демо либы для NTSC-графики. Тетрис на двоих. Редактор Spin-кода в SVGA режиме. Всё работает на #Propeller
Давненько не писал. Будем считать, что был в творческом отпуске. Буду навёрстывать!
В прошлый раз я писал про #propeller, поделюсь ещё одной интересной штучкой с пропеллером!
К DEFCON'22' (DEFCON — это такая конференция для технарей) бейджики готовили сами Parallax. И, конечно же, бейджики были сделаны на основе Propeller! Тут можно почитать подробности. А я пройдусь "по верхам".
Каждый бейдж имел на борту помимо пропеллера ещё и ИК-трансивер (приёмник + светодиод), восемь светодиодов и четыре сенсорные кнопки. Ну и USB, конечно. При этом каждый бейдж был ещё и полноценной dev board для пропеллера: все порты были выведены на пятачки для пайки. ИК-трансивер был рассчитан на общение бейджиков между собой(!). Участники конференции обменивались таким образом контактами — забавно, правда? С эстетической точки зрения бейджи были тоже очень хороши: фигурные платы в разных цветовых схемах (фото прикреплю ниже), прям глаз радуется. Что интересно, именно на DEFCON'22 параллаксовцы официально объявили об открытии "исходников" Propeller — Verilog, схемы, вот это всё.
Но про бейдж DEFCON'22 я узнал, исследуя интернеты в поисках информации об этой прелести! Это тоже бейдж на пропеллере, но с OLED-экраном, тем же беспроводными средствами связи (ИК), и тоже представленный в нескольких цветах (разные цвета для персонала конференции, и для гостей). Пока я нашёл только эту заметку, в которой авторы делятся своим видением будущего устройства. Буду искать дальше, очень уж интересно.
К DEFCON'22' (DEFCON — это такая конференция для технарей) бейджики готовили сами Parallax. И, конечно же, бейджики были сделаны на основе Propeller! Тут можно почитать подробности. А я пройдусь "по верхам".
Каждый бейдж имел на борту помимо пропеллера ещё и ИК-трансивер (приёмник + светодиод), восемь светодиодов и четыре сенсорные кнопки. Ну и USB, конечно. При этом каждый бейдж был ещё и полноценной dev board для пропеллера: все порты были выведены на пятачки для пайки. ИК-трансивер был рассчитан на общение бейджиков между собой(!). Участники конференции обменивались таким образом контактами — забавно, правда? С эстетической точки зрения бейджи были тоже очень хороши: фигурные платы в разных цветовых схемах (фото прикреплю ниже), прям глаз радуется. Что интересно, именно на DEFCON'22 параллаксовцы официально объявили об открытии "исходников" Propeller — Verilog, схемы, вот это всё.
Но про бейдж DEFCON'22 я узнал, исследуя интернеты в поисках информации об этой прелести! Это тоже бейдж на пропеллере, но с OLED-экраном, тем же беспроводными средствами связи (ИК), и тоже представленный в нескольких цветах (разные цвета для персонала конференции, и для гостей). Пока я нашёл только эту заметку, в которой авторы делятся своим видением будущего устройства. Буду искать дальше, очень уж интересно.
В прошедшие выходные добрался таки до Pollen — системы для написании/программирования книг, построенной на базе #racket.
Racket я использую давно и знаю, что документация к языку и пакетам написана на отдельном диалекте Scribble, как уж это водится у "рэкетиров". И даже о Pollen я давно был наслышан — на Pollen "написана" отличная книга "Beautiful Racket" (а ещё "Practical Typography").
Pollen умеет обрабатывать Markdown и генерировать на его основе HTML, но может быть использован и в других сценариях. Самое интересное в системе, это специальный язык X-expressions — описание дерева документа, пригодное для дальнейшей обработки.
Так, все входные форматы сначала преобразуются в X-exps, а уже потом перегоняются в тот же HTML. Даже Markdown может быть преобразован в X-exps и дообработан программно перед преобразованием в HTML. И конечно же, обрабатывать X-exps и даже формировать можно с помощью Racket — Pollen является его надмножеством.
Подкину коду для демонстрации:
"Ромбики" являются началами команд. S-exps являются Racket-кодом, а другие описывают разметку. Разметка при этом не выполняется, она просто записывается в X-exps как есть. А если учесть, что X-exps, имеет вид
В конце итоговое X-exp скармливается шаблону, который превращает разметку в текст выходного формата. Причём выходных форматов может быть несколько! Книгу, скажем, можно преобразовать в HTML, а можно и в LaTeX/PDF.
При этом обрабатывает Pollen проекты по-взрослому — кэширует, раздаёт встроенным сервером контент (формирует контент налету).
Я на всём этом добре решил сгенерировать страничку для моей VDS с хобби-проектами. Получилось что-то такое: recursive.one. Контента, как обычно для меня, нет. Но сам "движок" писать мне понравилось
Racket я использую давно и знаю, что документация к языку и пакетам написана на отдельном диалекте Scribble, как уж это водится у "рэкетиров". И даже о Pollen я давно был наслышан — на Pollen "написана" отличная книга "Beautiful Racket" (а ещё "Practical Typography").
Pollen умеет обрабатывать Markdown и генерировать на его основе HTML, но может быть использован и в других сценариях. Самое интересное в системе, это специальный язык X-expressions — описание дерева документа, пригодное для дальнейшей обработки.
Так, все входные форматы сначала преобразуются в X-exps, а уже потом перегоняются в тот же HTML. Даже Markdown может быть преобразован в X-exps и дообработан программно перед преобразованием в HTML. И конечно же, обрабатывать X-exps и даже формировать можно с помощью Racket — Pollen является его надмножеством.
Подкину коду для демонстрации:
#lang pollen
◊(define who "World!")
◊div[#:class "content"]{
◊h1{
Hello ◊|who|!
}
◊strong{text}
}
"Ромбики" являются началами команд. S-exps являются Racket-кодом, а другие описывают разметку. Разметка при этом не выполняется, она просто записывается в X-exps как есть. А если учесть, что X-exps, имеет вид
(div ((#:class "content")) (h1 () "Hello " who)) то вы можете догадаться, как Racket обрабатывает разметку и генерирует её сам :)В конце итоговое X-exp скармливается шаблону, который превращает разметку в текст выходного формата. Причём выходных форматов может быть несколько! Книгу, скажем, можно преобразовать в HTML, а можно и в LaTeX/PDF.
При этом обрабатывает Pollen проекты по-взрослому — кэширует, раздаёт встроенным сервером контент (формирует контент налету).
Я на всём этом добре решил сгенерировать страничку для моей VDS с хобби-проектами. Получилось что-то такое: recursive.one. Контента, как обычно для меня, нет. Но сам "движок" писать мне понравилось
:D. Как и в прошлый раз, когда я на #haskell и Shake движок написал.
Забыл написать, что этот свой Pollen generated site я запихал в #docker контейнер с lighttpd, чтобы самораздавайка получилась.
А контейнер задеплоил на VDS, на котором Dokku бегает — такой вот PaaS у меня для микропроектиков. Вот только heroku-style deploying через гит я не люблю, да и Heroku CLI мне не особо нравится. Поэтому загружаю образы целиком через
Кому-то это всё покажется детскими играми. Но я не умею в этот ваш DevOps современный да и не очень-то и хочу уметь. Из современного освоил только Docker, а вся автоматизация на Makefiles сделана — не могу в k8s, зато могу в GNU m2e! И мне норм
А контейнер задеплоил на VDS, на котором Dokku бегает — такой вот PaaS у меня для микропроектиков. Вот только heroku-style deploying через гит я не люблю, да и Heroku CLI мне не особо нравится. Поэтому загружаю образы целиком через
docker save | ssh ... — для моих поделок на "не самых популярных стеках" самое то. Уже успешно "задоккивал" проект на #Clojure, Web-приветмир на #Racket.Кому-то это всё покажется детскими играми. Но я не умею в этот ваш DevOps современный да и не очень-то и хочу уметь. Из современного освоил только Docker, а вся автоматизация на Makefiles сделана — не могу в k8s, зато могу в GNU m2e! И мне норм
:)Попробую новый экспериментальный формат: "Смотрите, какую дичь я писал когда-то", то есть "мои #old_projects".
Увы, в здесь нельзя вставлять изображения посреди текста, а поднимать заново движок для блога я пока не готов. А в Medium публиковать не хочу. Поэтому напишу серию постов — формат получается вдвойне экспериментальный.
Я, как настоящий самоучка, аж до моей второй работы варился исключительно в собственном соку. Учась в институте, я делал все свои проекты на Delphi, который изучил по его же встроенной документации, а дополнял знания из .CHM-книжек "Kuliba3000" (а может 4000, я уже и не помню) — был такой "самиздат" сборников статей из интернетов, прикладывался к дискам "сколько-то-там компонент для Delphi". Интернета у меня не было курса до третьего, так что на этом, собственно, мои источники информации и исчерпывались. Это к концу учёбы я добрался до интернета, форумов, Хабра. И узнал, что на Delphi писать зазорно. Ну да ладно, пост не об этом.
То, что я писал на QBASIC и TurboPascal в школе, увы не сохранилось — померло то ли на одном из старых "винтов", то ли на старых же дискетах. Этого вашего Git тогда ещё не было, а без интернета я бы всё равно не смог бы его использовать. Чудом сохранились лишь мои студенческие Delphi-поделки. Про одну из таких я и хочу рассказать.
Увы, в здесь нельзя вставлять изображения посреди текста, а поднимать заново движок для блога я пока не готов. А в Medium публиковать не хочу. Поэтому напишу серию постов — формат получается вдвойне экспериментальный.
Я, как настоящий самоучка, аж до моей второй работы варился исключительно в собственном соку. Учась в институте, я делал все свои проекты на Delphi, который изучил по его же встроенной документации, а дополнял знания из .CHM-книжек "Kuliba3000" (а может 4000, я уже и не помню) — был такой "самиздат" сборников статей из интернетов, прикладывался к дискам "сколько-то-там компонент для Delphi". Интернета у меня не было курса до третьего, так что на этом, собственно, мои источники информации и исчерпывались. Это к концу учёбы я добрался до интернета, форумов, Хабра. И узнал, что на Delphi писать зазорно. Ну да ладно, пост не об этом.
То, что я писал на QBASIC и TurboPascal в школе, увы не сохранилось — померло то ли на одном из старых "винтов", то ли на старых же дискетах. Этого вашего Git тогда ещё не было, а без интернета я бы всё равно не смог бы его использовать. Чудом сохранились лишь мои студенческие Delphi-поделки. Про одну из таких я и хочу рассказать.
Часть 1
Задумал я как-то написать движок для "point&click" квестов. Да, сразу движок. Потому что я откуда-то знал, что игры делают на движках, а не хардкодят каждый экран. Об анимации и визуализации персонажа я в принципе не думал. Предполагалось, что игры будут "от первого лица", как в "7th Guest" (ага, oldschool!). Был намечен абсолютный минимум: кликабельные объекты на экране, имеющие всплывающие подсказки, какой-то инвентарь, возможность изменять часть сцены (то есть наложение объектов на фон).
Нарисовал я пару экранов в XaraX, и начал думать, как бы разметить объекты сцены. В итоге выкрутился так: сделал невидимое изображение в 16-цветном .BMP, подложенное под изображение сцены. Позиция мыши "прокалывала" холст и я мог получить цвет задника. Цвет и был идентификатором объекта. 16 цветов, это 16 объектов — для одного экрана достаточно. Зато объекты могли состоять из нескольких областей и вообще иметь произвольную форму. А самое главное, я эту цветовую карту мог очень просто выгружать: я просто делал равномерную заливку в векторе, убирал сглаживание и экспортировал в .BMP. Этот формат использовался потому, что Delphi мог читать такие файлы самостоятельно и сжатие не вводило новые цвета, то есть не портило мне разметку.
Самый первый экран выглядел так:
Задумал я как-то написать движок для "point&click" квестов. Да, сразу движок. Потому что я откуда-то знал, что игры делают на движках, а не хардкодят каждый экран. Об анимации и визуализации персонажа я в принципе не думал. Предполагалось, что игры будут "от первого лица", как в "7th Guest" (ага, oldschool!). Был намечен абсолютный минимум: кликабельные объекты на экране, имеющие всплывающие подсказки, какой-то инвентарь, возможность изменять часть сцены (то есть наложение объектов на фон).
Нарисовал я пару экранов в XaraX, и начал думать, как бы разметить объекты сцены. В итоге выкрутился так: сделал невидимое изображение в 16-цветном .BMP, подложенное под изображение сцены. Позиция мыши "прокалывала" холст и я мог получить цвет задника. Цвет и был идентификатором объекта. 16 цветов, это 16 объектов — для одного экрана достаточно. Зато объекты могли состоять из нескольких областей и вообще иметь произвольную форму. А самое главное, я эту цветовую карту мог очень просто выгружать: я просто делал равномерную заливку в векторе, убирал сглаживание и экспортировал в .BMP. Этот формат использовался потому, что Delphi мог читать такие файлы самостоятельно и сжатие не вводило новые цвета, то есть не портило мне разметку.
Самый первый экран выглядел так:
Часть 2
Движок мой подразумевал то, что я скомпилирую его один раз, а ресурсы конкретной игры будут загружаться при запуске. А значит нужен был какой-то формат описания сцен, переходов, активностей. Выбрал я, конечно же, INI-файл — "искаропки", пишется в любом редакторе, секционность подходит для постраничной игры.
Имя секции соответствовало имени файла (его базовой части) изображения фона — вот вам "convention over configuration"! Первая сцена имела фиксированное имя "begin", соответственно подгружались файлы "begin.bmp" и "begin_m.bmp" — второй, это "маска", то есть тот самый невидимый слой с выделенными цветом объектами.
В секции писалось что-то такое:
При перемещении мыши брался текущий цвет подложки, по нему как по ключу, доставались действие по клику и hint (всплывающая подсказка) для объекта: в примере эти ключ в формате RRGGBB и он же, но с суффиксом "_h" (hint). С текстом всё понятно, а действие "
Ключи секции, имеющие префикс "
Вот вам спрайт дерева, которое рисовалось поверх пенька на стартовом экране (смотрите предыдущий пост).
Движок мой подразумевал то, что я скомпилирую его один раз, а ресурсы конкретной игры будут загружаться при запуске. А значит нужен был какой-то формат описания сцен, переходов, активностей. Выбрал я, конечно же, 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" завёл, которая инициализирует все переменные игры. Переменные имеют префикс "
Но переменные нужно изменять. Для этого я прикрутил целый мини-DSL. Тот самый "
Ещё язык содержал предусловие, которое позволяло продолжить выполнение сценария только при наличии в инвентаре игрока нужного предмета. Парой для этой команды выступала команда, добавляющая в инвентарь предмет.
Предметы кодировались цифровыми идентификаторами, но по сути могли быть любыми валидными ключами: каждый идентификатор был ещё и ключом секции "invnames", значения в которой содержали имя предмета:
А вот так выглядело срубание дерева на стартовом экране:
- "
- "
- "
- "
- "
"
Команды языка пишутся без каких либо разделителей потому, что INI-файлы не предполагают многострочных литералов. Такое вот творчество в условиях ограничений
Использование координат спрайтов, а точнее — их изменение, это уже попахивает переменными! Да, таковые я тоже предусмотрел. Даже секцию "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
Язык сценариев получился вполне себе выразительный — для данной задачи, конечно же. Можно было описать довольно сложные сценарии.
Например, в игре вы шли на кладбище, брали там ворота (дверцу калитки), шли с ней к пещере со рвом перед входом, перекидывали калитку через ров на манер моста, и попадали в пещеру. Тут вам и взятие объектов и выбрасывание ("
В пещере вы получали топор, возвращались назад, рубили дерево, шли опять к пещере и заменяли калитку на бревно, чтобы использовать саму калитку позже! Тут использовались сценарии, хранящиеся в переменных — до экранирования я не догадался, поэтому копировал код из одних переменных в другие, вместо того, чтобы записывать код в "обработчики клика".
С технической стороны всё получилось максимально прямолинейно. Парсер DSL у меня был однопроходный — просто посимвольно обходил строку однократно, сразу же выполняя команды. Никаких грамматик, никакого backtracking: я и слов-то таких не знал тогда — имел то, до чего додумался сам. Зато было весело!
Игру саму я тогда не доделал, конечно. Допилил движок, и игра стала "реализуема". Дальше уже наступал черёд игрового дизайнера и сценариста, затем — художника. А вот эти роли мне были не так интересны, поэтому игра осталась в виде "proof of concept" с четырьмя игровыми экранами. Но своё удовольствие я получил. И догадался сохранить исходники, что позволило в итоге написать эту серию
Язык сценариев получился вполне себе выразительный — для данной задачи, конечно же. Можно было описать довольно сложные сценарии.
Например, в игре вы шли на кладбище, брали там ворота (дверцу калитки), шли с ней к пещере со рвом перед входом, перекидывали калитку через ров на манер моста, и попадали в пещеру. Тут вам и взятие объектов и выбрасывание ("
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,
Сам я положу Mr.Crowbar в копилочку, а вам желаю приятного просмотра! А может быть даже и вдохновлю кого-то (менее ленивого, чем я) что-то эдакое пореверсить
#python #gamedev #video
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 — ага, как обычно, про что-то странное
На всех уровнях (картинка, анимация, игровой мир, игровая вселенная) эти teachpacks предоставляют хорошо продуманные абстракции. Которые ученики могут в последствии использовать в качестве источника вдохновения при построении других программ. Собственно, потому курс и называется "How to Design Programs"
Я вообще считаю, что использование расширяющих друг друга языков работает лучше, чем изучение того же ООП на примере разных языков, заставляющее с каждым языком провести несколько незабываемых часов только для того, чтобы отвыкнуть-привыкнуть.
Этот же подход к языкам-темам присутствует в книжке "Beautiful Racket", которая вообще проповедует Language-Oriented Programming. Когда устаёшь от формошлёпства через ямлодокеры, такие "параллельные миры" могут стать отлично отдушиной. Так что я и книжку рекомендую, да.
Ну вот. Хотел просто запостить ссылку на видео про геймдев, а в итоге скатился в образование и саморазвитие. Ну и ладно, блог мой, поэтому могу!
#education #racket #gamedev
:)
Целью ставил перед собой демонстрацию искоробочных возможностей 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, но их меньше и сами они проще и однозначнее,
- основной контент кодируется текстовым форматом
- передавать можно не только текст, MIME-types поддерживаются,
- TLS со стороны сервера обязателен, так что секурненько,
- вместо cookies используется клиентский TLS, то есть клиент решает, когда ему менять identity — уже просто так не потрекаешь!
Протоколу Gemini недавно исполнился год, но активности в сообществе уже довольно много: люди ведут дневники (gemlogs), держат Gemini-зеркало Википедии, пишут серверы и клиенты на разных языках. Есть у "нового Веба" и поисковики, и каталоги ссылок (помните, что это такое?). Посерфить можно через прокси с помощью обычного браузера или сразу установить один из Gemini-браузеров, словом, есть и контент и средства для его потребления. Да, движение молодо, но энергией оно пока полнится!
Я и сам как-то подустал от современного Web со всей его сложностью, так что изучаю всё это "околоблизнецовое" с неподдельным интересом. Хочу поднять свой ресурсик и зеркалировать туда да хоть вот этот самый канальчик. В качестве языка возьму Rust или Haskell, а серверную реализацию напишу, неверное, сам — так интереснее! Так что, как г-рится, stay tuned!
А вам предлагаю почитать спецификацию протокола, а затем прогуляться по Gemini Gateway дабы познакомиться с сообществом и экосистемой.
Тем не менее, некоторые ценители старины (ретрограды, чего уж там!) протокола продолжают поддерживать в рабочем состоянии 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-страницы на общем хосте имели адреса вида
Сейчас Tilde-серверов существует достаточное количество. Практически каждый из них, это обычный компьютер, который не выключают на ночь. Поэтому от сотен пользователей машины ожидается соблюдение определённых норм и правил — проще говоря, монополизирование ресурсов машины не приветствуется. Ресурсы — общие и используются сообща, цифровой коммунизм :) На что же хватает ресурсов одной не самой мощной машины? На типичном tilde-сервере есть Web-сервер страниц пользователей (кто бы сомневался?), Wiki, IRC-подобный чат между пользователями (снаружи машины не доступен), столь же локальный BBS-подобный форум, нередко — какие-то многопользовательские игры с текстовым интерфейсом (ага, MUD). Кто-то дополнительно разворачивает сервисы вроде Gitea, поднимает сервер Minecraft, ноду Mastodon).
Если вы вдруг решите приобщиться и завести себе учётку на какой-нибудь тильде под управлением OpenBSD, то вам стоит пройти сюда: <https://tildeverse.org/> Это хаб сообщества, на котором вы сможете найти себе сервер по вкусу. Или, скажем, почитать тематический zine.
Я лично себе заимел учётку на <https://tilde.town>. Это Linux-машина, так что всё привычно. Общая атмосфера — нарочито дружественная, все занимаются забавными пустяками, вроде рисования своих вагонов к ASCII-паровозу (для этого нужно правильно названный текстовый файлик иметь в
Моя страничка пока выглядит так, HTML для неё я сгенерировать скриптом на #racket. Генерировал на своей машине, но при желании смогу сделать это и с сервера: Racket на машине имеется, также как и GHC, не говоря уж про прочие пайтоны. Местный зоопарк языков вполне неплох, так что можно покодить что-то не сильно нагружающее машину, не выходя из терминала (Vim и Emacs тоже имеются). Имейте в виду, если вдруг захотите сгенерировать "хомяка" программой на BASIC
В 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). Про это явление можете почитать здесь. Суть: вручную и с любовью выстроенная структура, цветущая информация, засыхающие пережитки прошлого — красиво, эко, завлекает! Погружался и в сады, долго выбираться пришлось
Среди тех, кто ведёт свои базы знаний и выгружает мозги, многие используют Wiki Software в роли хранилища. Я на такой вариант тоже смотрел. Вот только иметь именно сервер да ещё и со встроенной CMS мне не хочется, поэтому пока я отложил и написанный на #Haskell Gitit и минималистичный Ikiwiki (этот ещё и на Perl, что мне не очень нравится). Нашёл парочку решений, умеющих сгенерировать Wiki-подобный сайт в статическом виде, но решения эти скорее мертвы, чем живут, а я пока не готов подхватывать чужой проект. Штуки вроде TiddlyWiki меня не устраивают тем, что это вещи в себе, а мне хочется писать код в любимом редакторе (#Emacs, конечно же). Да, Emacs позволяет выгружать контент страниц в форматах многих "вик", но я хочу сам управлять в том числе и структурой, а не только содержимым.
Ещё один популярный способ хранения сливок — иерархические заметочники (outliners) тоже существуют. Те же Org Mode, или Joplin. Эти, правда, тоже слегка навязывают структуру и строго одну. Да, можно использовать теги и делать по ним группировку, но чувствуется любой отход от изначальной идеи чужеродно.
Учесть сервисы, кто-то нынче использует Notion (ссылку не даю, и так все знают про него), другие всё ещё сидят в Evernote. Тут тоже теги, блокноты, структура. Из новых сервисов в изрядном почёте ходит Roam. Главная фишка последнего — автоматические обратные ссылки. Вы ссылаетесь в одном куске информации на другой, а тот получает ссылку на первый (в обратную сторону получается связь "один-ко-многим"). Вот тут неплохой мастеркласс по Roam, советую глянуть — прочувствуете идею, так сказать. Обратные ссылки, это "новый чёрный" в среде заметколюбов, их уже и в Notion анонсировали, и другие игроки подтянутся, я уверен.
(продолжение следует)
А ведь вообще-то я сейчас глубоко закопался как раз в то, для чего я и создавал этот канальчик: в выгрузку из внутреннего органического мозга во внешний "мозг", как говорят, 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 в то, что подойдёт лично мне…
Вот, дампнул немножко мозгов. Сумбурно вышло, но пока я не готов это структурировать — сначала нужно придумать, как!
И всё бы ничего, вот только Roam стоит не таких уж маленьких денег, да и является закрытым внешним сервисом. Что лишает меня контроля — да, я хочу контролировать и этот аспект. Народ создаёт свои аналоги, например, Athens (опенсорс на #Clojure!), но ждать их взросления долго. Зато Athens можно будет хоcтить и у себя, так что я лично послежу. Себе же взял OrgRoam — надстройку над Org Mode, которая добавляет обратные ссылки и убирает структуру (за счёт отказа от одного outline в пользу отдельных файлов). Пробую что-то записывать, может быть прикручу публикацию в таком виде — минималистично, статично, обратно-ссылочно! А может быть и откачусь на голый Org, буду всё держать в больших файлах — так тоже живут (внимание, это тоже кроличья нора, легко провалиться).
Есть ещё одна опция: самодельное решение. Так тоже делают. Плюс тут один: полный контроль над всеми аспектами. Делай себе инструменты сам, как говорят (и пишут). И над этим вариантом я тоже думаю. Может получится скрестить Gitit и Org Mode в то, что подойдёт лично мне…
Вот, дампнул немножко мозгов. Сумбурно вышло, но пока я не готов это структурировать — сначала нужно придумать, как!
;)GitHub
GitHub - athensresearch/athens: Athens is no longer maintainted. Athens was an open-source, collaborative knowledge graph, backed…
Athens is no longer maintainted. Athens was an open-source, collaborative knowledge graph, backed by YC W21 - athensresearch/athens