It’s been a while since I posted anything! I decided to add some social-media links to this site (more on that bellow), and when I pushed the updates my hand-rolled static-site generator broke. This post goes over what I was trying to do and what I did to clean things up.
Like anyone else addicted to lurking on Twitter I have fears: that the site is falling apart or that the new ownership is driving away the posters I care about. I’ve created an account over on hachyderm.io (a Mastodon instance) and started following folks in that ecosystem. To make it easier to find me I updated my Twitter profile blurb to include my new Mastodaon handle. That was seemingly against Twitter rules for a day or so, so I updated the front page of this site to have various social links I care about so that folks could find me even if I had to pull the explicit Mastodon mention.
(All of this is a bit much - I don’t really post to social media so it’s a small group of folks that would actually care to follow me elsewhere!)
The first thing that happend is that the links I created were mal-formed. I write content for this site in Markdown and use Pandoc to transform it to HTML. I wrote the following and expected it to work:
Ways to get in touch/see what I'm doing:
* Twitter [@latteras][1]
* Mastodon: [hachyderm.io/@ant_][2]
* [GitLab][3]The text [foo][2] is Markdown syntax for “create a link
with the text foo to the content specified in
footnote-number-2”. Markdown is fun in that there are many different
flavors of it - and these links worked great in the “Markdown preview”
functionality of VS Code.
But Pandoc uses it’s own variation of Markdown that gets wildly thrown
off by the @ characters in the link-text.
The right thing to do would be to tell Pandoc to use a different “flavor” of Markdown. Specifcially, “CommonMark” is the variation that sites like GitHub have settled on, and it’s well-specificed and supported by Pandoc.
The easy thing to do was escape the problem characters, so that’s what I did:
Ways to get in touch/see what I'm doing:
* Twitter [\@latteras][1]
* Mastodon: [hachyderm.io/\@ant_][2]
* [GitLab][3]This site is generated by a GitLab pipeline which:
Checks to see if the compiled Go binary we use for part of the build has changed, and if so build a fresh Docker image that the rest of the build relies on. We also install Pandoc on to this image.
On the Docker image from (1) convert content from Markdown to HTML and generate Markdown for “dynamic” site content (like the ‘recent posts’ links on the front page). Also convert the “dynamic” content to HTML using Pandoc.
Somehow in the process of all of this the pipeline decided it was time to re-build Docker image above, which hasn’t happened in years and was now broke.
Specifically the random testing-package for Pandoc I was installing into an old version of Alpine Linux was no longer available/working.
So I decided to do some spring-cleaning:
Updated the project to use Go 1.19 (from Go 1.14). One thing I appreciate about using Go for personal projects is that I can neglect them for years and still expect things to work when I want to adopt a new version of the compiler or standard libraries. I didn’t have to make any code-changes to take 5 major-version-updates.
Migrate from github.com/mattn/go-sqlite3 to modernc.org/sqlite. These are both Go libraries for woirking with SQLite. The mattn/go-sqlite3 library is great, and is what I would choose for a production system I had to relay on. But because it calls into C code (the sqlite library) the build system is more brittle than a typical Go program, and a broken build is a real motivation killer for a personal project.
modernc.org/sqlite is built from the same C code, but transpiled to Go. It doesn’t claim to be production ready, and the whole concept of a generated/hand-crafted libc in Go is a bit scary, but to get a simpler build on a non-critical project I think the tradeoff is worth it.
Simplify the base image and upgrade to a newer version of Alpine Linux and Pandoc. This was espcially nice because due to (2) I could drop GCC and libc-headers from my build-image.
I still want to migrate things over to CommonMark. I had thought this would be simple but I’m not sure which versions of which Linux distros actually have a version of Pandoc which supports it, and I was getting warnings about the Pandoc template I’m using that I didn’t want to take them time to dig in to - so this will wait for another time. CommonMark is closer to the Markdown I use at work, so I feel like I’d be less likely to make silly mistakes on this site if that’s what I were using.