Updates
Hello, it’s been a while…
My last update on this blog was almost 8 years ago, and when I wanted to write something a few months ago, I couldn’t get the site to build. It wasn’t that hard to get it working again, but it felt like a sign that I should do some updates.
Moving on from Jekyll
There’s nothing really wrong with Jekyll, but as with much of the Ruby ecosystem, it feels the world has moved on. A lot has changed since I chose Jekyll in 2016, and there are better options available now. I’ve gone with Astro, and I’m using Deno as my Javascript runtime.
One of the things I like about Astro is that it’s both simple and flexible. Things work well out of the box, and it doesn’t get in the way if you want to make it your own. The only “hard” rule is pages go in ./src/pages, and everything else is a convention that you can choose to follow or ignore. Deno is great too, and the combination makes life easy. I haven’t had to mess around with config files, and it’s the easiest way I’ve found to get up and running with TypeScript.
For now, I’ve copied over the existing theme, images, and content, and focussed on making it work. Things don’t look very different, but Astro gives me some more options for playing around with interactive posts and playgrounds, which would have been painful with Jekyll. There are more visible updates I want to make too, but I wanted to do that separately from the more technical migration.
Goodbye CircleCI
I haven’t seen CircleCI on a client project since 2017, and the pipeline for deploying this blog broke some time in 2019 which I never bothered to fix. I decided to switch to GitHub Actions. I’ve also moved to OIDC authentication with AWS (which wasn’t possible in 2017) instead of IAM access keys in CI. I feel much more comfortable from a security perspective not having long lived credentials sitting in a CI provider waiting to be breached.
CloudFormation template evolution
The change to OIDC lead me to evolve my https-static-site-cloudformation script (which I use to provision the AWS infra that hosts this site) into aws-cloudformation-quick-stacks. It can still deploy everything I need for hosting this site, and I’ve added stacks for a Github OIDC provider and an IAM deployment role. I’ve tried to make it more like a proper tool, and structured it so that it should be easier to extend.
URI structure
I never liked the .html URIs that I had previously, but when I set up S3 with Cloudfront in 2017, there was no good alternative without opening up the S3 bucket as a static site directly. In 2021, Amazon added Cloudfront functions, which means that I can now do index.html rewrites easily. I’ve set up redirects in Astro so that the old URIs aren’t dead links.
Security and SEO updates
I also decided to adopt some new security features that AWS have added, added URI canonicalization, security headers, better caching, and made a handful of refactors. Small changes individually, but they add up to something meaningful, and it makes my hosting more in line with what the likes of Netlify and Cloudflare can do for static sites.
AWS account migration
I converted my AWS setup into a multi-account setup. It’s overkill for a personal account, but the flow of a multi-account login feels more familiar to me these days, and I wanted to see what it was like from the setup side. In doing this, I migrated all my infra to a new AWS account, which wasn’t hard (thanks to my new CloudFormation stacks), but infra provisioning can be slow, particularly when you have to wait for AWS to “release” an S3 bucket so that the new account can claim it.
The takeaway
It feels like I’ve done a lot of work for not much visible gain: updating Cloudformation templates, creating a new tool, migrating the pipeline, AWS account, tech stack, and porting the layout and content… It all took time and effort, and every change had experiments and ideas that were left on the cutting room floor as I tried to figure out the best approach.
The term for this is yak-shaving, although the “Hal fixing a lightbulb” scene from Malcolm in the Middle explains the concept much better. Yak-shaving is often seen as a distraction from value adding work. Google it, and you’ll find numerous articles on how to avoid it. But here’s a different take: visible benefits aren’t the only ones worth pursuing.
Things might look the same, but I’ve turned a single-purpose template into a more useful and extensible tool, moved to better CI/CD, improved the security of my pipelines and infra, and unlocked ideas that were previously in the “too hard” basket. I learned a lot and broke nothing. If not for this post, no one would notice the before and after. That feels like success to me!
Sometimes, yak-shaving is worth it. What feels like wasted time isn’t a waste when the end result is that you’ve not only solved the original issue (I can now deploy my blog again), but you’ve also fixed a few other things along the way.