2021

It’s February 2021, and I haven’t published anything to my blog in over a year. It’s not that I had nothing to talk about – after all, 2020 had plenty of goings-on worth examining. I wrote many thousands of words at work in Slack, email, and documentation. But I never carved out time to write here. Upon some reflection, I realized how much worse my written communication has become in the last year. I find it harder and harder to convey complex information succinctly; I struggle to explain myself; and I find the task of writing to be tiresome. It would seem, for me, that the regular act of thinking about things in the context of publishing those thoughts, and then actually publishing them, produces better output.

I’d also been somewhat frustrated with the process of publishing that I had created for myself. The bash script I cooked up almost worked, most of the time, but the time and energy required to deal with it when it didn’t work really demotivated me. Easier to not use it and not have it break.

On the technical side, Caddy, the webserver I use to serve this site, released a major new version that fundamentally broke the configuration on which I had been relying. Specifically, the templating system was completely redone, making it really hard for Caddy to render plain Markdown files at HTML. The time and energy of migrating back to Hugo, upgrading the software, and dealing with the inevitable list of things that broke was a real turn off. Easier to to just not do it.

I did spend a fair amount of time exploring alternative options. Maybe managing a website is just something I don’t want to do any more. Time to subscribe to a service, perhaps? I investigated micro.blog which is a really nice product. Simple to use, a healthy and vibrant community, and enough sophisticated features to appeal to technologists like me. I looked at write.as and write feeely. Both are nice, focused apps and their philosophies really appealed to me. And of course, I visited good ol’ WordPress dot com to see how things are over there these days. Each of these, and several others, all had some really nice features; but they all also had some fatal flaw for me. Whether it was lack of customizable URLs, weird media management, or some other restriction, each failed to grab me.

So, it was time to commit to upgrading Caddy, resuming my use of Hugo to generate static files, and figure out a good way, low-friction way to sustainably get new content online. Thankfully I’d saved my Hugo themes, so that was a huge help in building some momentum. The bulk of my Caddy configuration survived the upgrade, with only a few small tweaks. So it was time to tackle the publication process.

I’d heard about GitHub Actions, but never really considered using them. I don’t do much with GitHub on a regular basis, and didn’t see many automation options for me there. But this was, in fact, the solution I needed. I created a GitHub repository for my blog, and through the power of GitHub actions I can have GitHub handle all the work of runing Hugo to build my site, and then push the results out to my server.

Nothing I’m doing here is unique or novel. Lots of people have published guides on how they do this, and I benefited from their experience. Deploy Hugo websites with Github Actions was particularly useful to me.

One aspect of this, though, was security. I felt a little uncomfortable giving GitHub.com unfettered access to ssh into my personal server. I’m positive that GitHub’s security controls are worlds better than anything I could cook up, but “security in depth” is still an important guiding principle for all things Internet. Thankfully, I found Restricting SSH Access to rsync which perfectly explains how to limit what GitHub can do when it connects to my server. I created a new ssh key, and defined a specific command – rrsync that helps constrain the GitHub connection to a single command targeting a single directory.

This isn’t foolproof, but it gived me peace of mind. In the event my account or repository get compromised, or GitHub has some serious insider threat exploit, someone could publish junk to my website, but they shouldn’t be able to modify the server.

Finally, an important workflow component for me is mobile access. I don’t want to have to sit down at my computer to publish something. Because my site is now stored in a git repository, I can access the whole thing, and all its history, from any device with a git client. That git client can send updated content, and GitHub Actions ensures that the content gets posted. I’m writing this post in Working Copy on an iPad. I’ll install Working Copy onto my phone. I can create and edit anywhere, any time, which is what I wanted with my bash solution.

I have high hopes that this latest iteration of my blog is more stable, and results in me using it more.