fkr.dev

About

Hio, this is Flo. Born 1990, I like doing things and this is my blog. Into lisps, oil painting and esoteric text editors. On the interwebs I like to appear as a badger interested in cryptography. Every other decade I like spinning old jazz/funk records or programming experimental electronic music as Winfried Scratchmann. Currently located in Aix la Chapelle.

Table of Contents
    The Idea
    Tech Stack/Overview/TLDR
    Org-\>MD
    MD
    MD-\>HTML
    Clojurescript/JS
    Deployment
    The long story
    maybe trash it and restart all over?
    For the log and the future
    The code
    Honorable Mentions

How To (not) write your blog

In our blog we sport our own fashion. In another fkr-classic, let me document how much unnecessary interesting tech one can stuff in a simple static site. What you are about to witness is nodejs, the jvm, clojure, clojurescript, emacs, org-mode, minor-modes, react, npm, material-ui, pandoc, docker, pupeteer, chromium, vega, lots of glue, discarded ideas, rewrites, an own cron interface, sqlite, bash and the refreshing absence of html and css in: the quest for rendering hypertext.

The Idea

Since i structure my notes using org-roam, my idea and (?) a natural approach to blogging for me was to export articles directly from my org-roam structure by assigning them a special tag BLOG. From this i'd only need a script converting it to suitable html and push it to a webserver. Done.

But as it happens every so often i wanted to use the opportunity of a new project to scratch a few itches:

  • I do not like designing and i do not really care - but I do also not want to have my site look like shit. So for some time i think how to outsource the design problem to some preset / template / framework that will take care of the basics for me.
  • Ever since studying the wizard i like lispy syntax and having cljs, a lisp-like language compiling to js sounded too useful not to try. Also i read notes about rendering react components as static sites sounded strange and… interesting.
  • I provide local weather information using the signal protocol to a friend. Delivering complex data through text messages is cumbersome so i also wanted to have a way to render and serve relevant data in a more convenient way.

Tech Stack/Overview/TLDR

Org->MD

I derive an own org-export backend from the existing markdown export. Necessary because:

  • pandocs org->md export has section-issues, the default export does not preserve the language in source blocks.
  • images and other static files are collected and rewritten during the org->md conv

MD

  • the blogs content is versioned and archived in the intermediate markdown format using git.

MD->HTML

After fiddling with clojures oz too long i ended up coding my own static site generator. The current very hacky version stores the article content as base64 encoded data in the html. I was finally able to create some MaterialUI-react components using clojurescript and render them to html/css in the backend using nodejs, but I am still exploring this approach.

Clojurescript/JS

For now I use Clojurescript (compiled to js) to read the b64 encoded site-content on page-load (in the frontend) and render the site using react components.

Deployment

Docker does it. But intercommunication between the different containers is an unexplored topic for me (at least, concerning best practices). Is the canonical way:

  • to have docker-in-docker, one container to rule them all?
  • to expose common data via a shared volumes? (the current approach)
  • to expose a common unix-socket and define a protocol for sharing?
  • to expose a rest-api for every little service you create? (hello microservices)

I tend to like the unix-socket approach, it (coincidentally) also provides the necessity to think about an as generic as possible one-size-fits-all, reusable, protocol which is the kind of problem I love to waste time on.

The long story

#TODO

maybe trash it and restart all over?

Turns out we hit a parsing bug much quicker than we hoped. The clj markdown parser renders the following org sample:

1. oh, a list!
2. item 2
3. the third item with code example
   #+begin_src shell
echo "hi i am shellcode"
   #+end_src
   i am some comment that follows from the shellcode example
4. the fourth item continuing the list

Like this:

1. oh, a list!
2. item 2
3. the third item with code example
   #+begin_src shell
echo "hi i am shellcode"
   #+end_src
i am some comment that follows from the shellcode example
1. the fourth item continuing the list

For the log and the future

Since I am a bit unnerved of the strange path this abomination is taking the current (live, today) plan is to cut our losses and look at what we got working.

1.) A javascript(frontend,browser) app that expects base64 encoded.. stuff?! delivered in a certain position inside a certain html element, to process and render a homepage/an article/arbitrary stuff from (arbitrary as in maybe a table with state transitions and an endless tape) 2.) A nodejs backend able to parse markdown and render it to html. 3.) An Emacs plugin that renders :BLOG: tagged org-roam notes to markdown and extracts attached images

A sidenote
The rational behind the first design decisions was -> somehow get org to markdown to html and use javascript to display it with some fancy framework that prevents the necessity to do design myself + adds a dynamic look and feel while being a static site. I find that albeit having those humble goals, the project somehow inherited the worst of both, the static and dynamic site, aproaches:

We gonna try like this - let us do the webapp using just the clojure implemenentation and the mardown rendering using nodejs. If possible I want to find a new separation between front/and backend. (Currently the base64 encoded transmission, originally chosen to save bandwith). For SEO reasons also I'd like to skip the base64 encoding, also the separation seems artificial.

The code

.. is too messy to publish right now.

Honorable Mentions