For whatever reason I started blogging again last week. Not knowing why isn’t due to a lack of introspection on my part.

Maybe the nauseating weight of the Trump administration was suppressing my desire to write for the previous three-and-a-half years? Or maybe I’m just arbitrary and lazy?

It’s also unclear how long I can keep this up. Inspiration and a willingness to type are not something which you can purchase online or install with a package manager. I suppose we’ll find out.

However, the mechanics of blogging again are simpler to understand.

For one thing, as I write here:

… this website is only free-range, handcrafted, artisanal HTML. With a little CSS, of course. No JavaScript—that’s just crazy talk.

Technically, it’s all created using software. I don’t actually type all that markup manually, like some filthy animal.

And since the site remained unchanged from the time I generated it during June of 2017, it was still working fine as of last week. Keep that in mind when you consider the architecture for your own blog. Once you’ve created it, static HTML is pretty much maintenance free.

However, there’s that whole problem of generating it again. With new content. Yeah.

I had all the publishing software, content, configuration, etc. installed on my Mac originally. But since we all know I’m using a Windows PC now, I had to migrate everything.

That meant just copying my blog posts since they’re simply Markdown documents with YAML frontmatter. Easy.

But my content management system is Nanoc, a Ruby-based generator. And while it’s reasonably cross-platform and mostly runs on Windows, it’s not officially supported there. More importantly, the scripts and other tools I built on top of Nanoc were kinda Unix-adjacent, if you know what I mean.

This is where the Windows Subsystem for Linux (WSL) came to the rescue.

Normally, I use the Windows-specific version of ruby.exe for my other projects. But with WSL, you really need to apt-get ruby and shove that baby into Ubuntu as well.

After that it was just a gem install of nanoc and kramdown, my Markdown parser of choice. At least, I thought that’s all I needed.

Turns out the kramdown-parser-gfm Gem is required too since I depend on GitHub-flavored Markdown and the kramdown developers removed support for it from the main project back in 2019. Surprise, surprise. But that’s what I get for not parsing any Markdown for so damn long.

By the way, for any of you also installing Ruby Gems in WSL or other Unix-like environments, don’t preface gem install with sudo. This is both unnecessary and unwise.

It’s unnecessary because you can simply append --user-install to those installation commands. This will place them in ~/.gem, your local Gem directory.

And it’s unwise because you don’t want them placed in your system-wide Gem directory. Doing so will delete, overwrite or otherwise fuck them up whenever you update ruby itself.

Of course, you’ll need to add that local Gem directory to your $PATH variable in ~/.bash_profile or whatever the equivalent is for your shell. Otherwise the shell can’t find those Gems. Duh.

Here’s an example ~/.bash_profile showing how to do just that:

if [ -f ~/.bashrc ]; then
	. ~/.bashrc
fi

PATH=$HOME/.gem/ruby/2.7.0/bin:$PATH

Obviously the version of ruby in that path will need to be adjusted if yours if different.

So after getting the correct Gems installed in the correct places, I then had to make a few changes to my Nanoc configuration files and various homebuilt Unix-y scripts. These were mostly just converting some hard-coded macOS-specific directory names to their Windows-specific equivalents.

And then… it all worked. Flawlessly.

Which means migration was not really much of a problem at all. Sure, thinking ahead on what I needed to do took awhile, but that actual typing necessary to make it happen was just a matter of minutes.

Kind of anticlimactic, really.

Of course, now I have to figure out what to write. Dammit.