Some Website Upgrades

How the hosting as evolved over the years

How the site used to look in 2003

Over the 23 years I’ve been maintaining this site, I have used a bunch of different technologies to maintain and operate it.

The original version was written in Classic ASP and a Microsoft Access database. Each post was stored as a row in a table and the classic ASP would read the post from this table and generate the markup for the page.

In the early days of the site, I lost quite a lot of posts through database corruption. The very first post on the current site is dated to just after one of these events.

It always bothered me that the earlier posts from this period were lost. I don’t think I had much that was insightful from this period, but those posts reflected a part of my personal history and to have lost some of that history through database accidents was just annoying. This experience coloured a lot of my technology choices in future years. I wanted to make sure accidents didn’t result in lost posts.

In the middle of the 2000s, I got tired with the Microsoft technology stack. The .NET framework was invented and I was faced with a rewrite of my code to ASP.NET. Classic ASP was dying and ASP.NET at the time was significantly more resource hungry. Back in 2007, I set about moving the hosting of the site to Linux. As I said in my post discussing the change, the goal was to have a blog that would require relatively little maintenance over decade long time spans and to detach myself from being dependent on a particular company’s products.

The way I set about doing this was to have a big XML file that stored the posts and then use XLST to generate XHTML files for the site. It was a homebrew static site generator before those technologies were really established. Over time, the XSLT fell by the wayside and I started just making new posts as a new HTML file each time and having each post as its own file in source control.

One of the downsides of this approach was that the friction of actually creating and uploading a post was enough to slow down the pace at which I blogged, which can be seen in the post history.

It also meant that big changes to the markup and layout of the site required changing all the files. This is obviously quite a big headache.

More years went by and things slowly evolved. I changed Apache for Lighttpd, I used LetsEncrypt to put the site behind TLS. etc. Small, incremental improvements.

Version control systems changed, I started by having none at all. Then in 2007 I started a Subversion repository for the site. This got converted to Mercurial when it was clear that Subversion was being left behind. There was a period where Git didn’t really work on Windows very well and Mercurial was the competitor distributed version control system that worked properly on Windows. Eventually, Git completely dominated on all platforms but I put off the project of changing the source control system even though the world had moved on.

The start of the replatform

In September, 2023 I started to think about doing the next big upgrade to the way the site was managed.

Things had changed:

• Now static site generators weren’t an “edgy” choice but really mature technologies that had been around for years.
  • I could pick one and have reasonable confidence I wouldn’t get stuck on the technology.
  • It would also allow me to fix some of the management problems above.
  • I feel vindicated for the position I took in this post.
• Git had won.
  • I could dump Mercurial and use GitHub as a hosting solution for the source code.
• Back when I started, everything was “serverless” because you just uploaded via FTP.
  • Then we went to servers, to virtual private servers, to Docker and back to serverless again.
• XHTML was a dead-end. HTML5 had been invented and has basically taken over.

The goal was to refresh the technologies and set myself up for another 20 years of blogging.

The project took a lot longer than I expected, and only got completed late in 2025.

Templating and look and feel

I settled on Jekyll for the templating system. Jekyll is nice in that it allows you to mix content on the new templating system with the old hand-built files.

Slowly but surely, I started working through all my old posts and converting them to markdown with the appropriate front-matter. When I did this exercise, I had a dilemma as to whether I should go through and fix the spelling and grammar on some of the earlier posts.

I decided against it, mostly, trying to preserve the site as it was. I also opted to keep the original emoticons . I deliberately keep the site looking a bit retro - something that wouldn’t look out of place in 2003, as a nod to that time and place. These emoticons were used on the site before the glyphs we have today were standardised in to Unicode. I think they add a bit of character!

Upgrading to HTML5

I decided to junk the old XHTML template and transform the site to HTML5, using the newly introduced semantic tags. This involved adding the article and nav tags and changing the CSS styles so they style the nested elements rather than using explicit classes. This simplified the markup and styling of the site.

Now that the posts were all converted to Markdown this was a fairly easy change. I just had to change the base templates and the CSS then check it all works locally.

I also added a HTML indent step to the pipeline so the markup that was generated had consistent indentation. This was probably a bit overkill, but I like being able to “View Source” on the site and see that the markup looks well structured.

Migrating to GitHub

I ditched my locally hosted Mercurial repository and converted the entire commit history to Git. Once I had a working Git repository, I pushed the commits up to a private GitHub.

This ensures the version history is backed up in the cloud, while also retaining the local copy I have on my devices. This improves the backup-posture for the site.

Moving to Cloudflare pages

I then moved the site off the old Lightsail AWS instances I had running and migrated to Cloudflare pages. This is able to build Jekyll sites directly from GitHub, host and deploy them while handling the TLS certificate renewals and other backend management processes.

This takes a lot of noise out of the running of the site. The Linux host I had was hand configured, which is fine for hobbyist purposes but the Debian instance needed a full distribution upgrade. Not a huge amount of work, but enough to be annoying. The host also acted as a single point of failure. If the AWS region went down, the site was offline.

Rather than go through the pain of hand configuring the site again, I just decided to use Cloudflare and cut out all that work. Cloudflare has its outages of course, but the simplicity gained in the on-going management of the site will be worth it.

What’s nice is that it’ll build your branches in to their own isolated test site. This allows you to do quality checks before merging your branch in to master and putting the posts live.

Conclusions

I think the technology choices over the last 20 years worked quite well. I think I correctly identified static site generation as the right way to run the blog. This prevented a lot of unnecessary platform and code upgrades.

At the time, XHTML seemed like a good choice. A stricter markup technology seemed like the direction we were heading in. Then HTML5 happened and basically killed XHTML overnight.

Building my own XSLT transformer for the template management was a bad idea. While the idea of owning all the code that powers your site is nice, it meant I was lacking features and ultimately the will to maintain it properly.

The static site generator tool chain matured quite quickly and I probably should have replatformed earlier to take advantage of them. Jekyll was first released in 2008, so it’s nearly been around 20 years in its own right.

I selected the wrong version control systems. I started with Subversion, moved to Mercurial when it was clear Subversion wasn’t going to last but over time Mercurial basically disappeared too. Git looks like it’ll be a long term winner that lasts for decades though. Third time lucky.

If anything, it just shows the challenge with making long lasting technical choices. The future is very hard to predict.

That said, the technology refresh fixes a bunch of problems. It picks established technologies where there are least 2-3 other people doing the same sorts of things. This means nothing I’ve done should lock me in. It also makes the site easier to update, which means I should post more often.

Let’s see how I get on in 2026 and beyond.