Infrastructure of this site as of October 2020

My private notes and this blog had always been quite separated. I’d take notes for myself, but this site was just left to rot. This was because the markup format is quite different from my private notes (previously in Markdown, now in Org mode), and because they are separate repositories — I just don’t open my blog project that often.

It doesn’t help that Pollen Markup is, by design, incredibily flexible — so in effect I’ve had to build up my own inventory of markup functions and maintain them. Moving away from Frog was a step to reduce the amount of code I had to maintain. From what I remember (I moved away from Frog in 2018), I had to carefully make sure that each tag function evaluates to Markdown or HTML in the right context.

This has left me wanting to overhaul the site, like, completely: move away from Pollen, maybe to Eleventy or to Hugo, build the entire site from the ground up. But I never found the motivation to do it, because it just seemed like too much work for not much to gain.

Meanwhile I started learning more methods of note taking — from just a list of notes on Simplenote, to throwing every diary entry into one big Org file, eventually back to putting each diary entry in its own file, but interlinked with other notes like a Zettelkasten.

I discovered Org-roam, and developed my own reimplementation of backlinks because I thought it didn’t have to be that complex. But it turns out trying to implement backlinks that integrate with Org mode is pretty hard by myself, so I moved to Org-roam and submitted pull requests to it instead.

Parts of my private notes started to resemble a blog, and after reading swyx - Learn in public I started thinking that I want a way to publish them.

The result is ox-pollen, which hopefully will allow me to publish my notes a lot more easily.

The source code is hosted on Github. Continuous integration is set up on builds.sr.ht. Whenever I push to the repository, a job will be started to build the site and deploy it to Netlify.

The build process is driven by Make. Ideally I want all dependencies to be expressed in Make instead of in Pollen’s index.ptree, but it’s still fine without it.

1. All Org files are converted into Pollen Markup.
2. The main (and only) template is preprocessed.
3. Category and tag pages are generated and rendered.
4. HTML files are built after all categories, tags, templates, and Pollen Markup files are ready.
5. CSS also gets built.
6. The end result is “published” into a finished folder with raco pollen publish,
7. then that folder is zipped with 7z.

The final result is a public.zip file, which is then submitted to Netlify through its API.

This all happens on builds.sr.ht. I replaced Travis CI with it because the Travis website is just too heavy. Often it just wouldn’t load even though I just wanted to see the build log.

There are also two features in builds.sr.ht that made using it less painful than Travis:

• The ability to submit a build recipe directly so you don’t have to keep force-pushing to the repository to initiate builds (or to not force-push, resulting in a dozen “try to fix CI” commits)
• SSH access for failed builds which allows for easy inspection into what went wrong.