If you’re reading this, it means that I’ve successfully switched the software that generates this site from Octopress something of my own creation.

Why Would You Do This?

Mostly, complexity.

By it’s authors admission Octopress is a bit of a hack (see the blog post announcing version 3.0). Octopress is a fork of Jekyll and the version I was using had been modified even further, as well as using a theme I had also customised. The result of all this was the software equivalent of a drunken game of Jenga. I’d constantly be hunting around for the correct place to change things (this was particularly bad in the theme, which was spread across a wealth of files in an way that probably makes sense to someone who was more familiar with Sass) and when I found a likely place to make the change, it either had no effect or broke everything.

In addition, the old set-up required an old Ruby install (pre 2.0), but since I also do other Ruby code and like to be using a modern version for that I ended up having both versions installed. This worked but was a bit of a faff (and as far as I know, none of the tools to make this easy support Windows).

Finally, I wanted a project to unwind with after Seraph and making a static-site generator in Ruby is pretty far away from C# and Unity.

The New Hotness

My static site generator is called Evander, and it is written entirely in Ruby and is quite small (which I consider a bonus). It almost certainly doesn’t have all the features of Jekyll or Octopress, but it does what I need.

It has the following features:

Those last two points are one of the things that annoyed me about the previous set-up, images used to have to be in an images folder (that just got copied to the output folder) and you had to know where the image was going to end up to link to it. In order to keep some sort of organisation I ended up with a folder tree in the images folder that essentially mirrored the site structure, and maintaining that was a pain. But with evander, I can just put the images right next to the markdown file, link to it with a relative path, and when the site is generated the images are copied into the images directory (in a sub-dir based off the page url) and the link is expanded correctly.

This leads to a situation where there is a directory per page, and that directory contains everything that is page-specific (the markdown, the config file, images, etc.) which I think is a lot cleaner. To support this further, some pages can be marked to not render, that is, the markdown will not be converted into a separate .html file, but is assumed to be included in another page (currently the Projects pages work like this, each project has it’s own folder with the markdown and images, but the parent page iterates through them all and renders them in-line. If I ever want to have separate pages for each project, that would be a very simple change).

In addition to writing all that, I completely re-wrote the HTML template and CSS for the site to something that is a lot simpler (but visually similar). I’m pretty happy with how it turned out.