2 minute read

Having spent a lot of time recently (even more than normal) working with Git I decided to once again migrate my site to another content management system. I do this every few years, mainly because it’s a great excuse to play with some software and possibly programming or markup languages that I haven’t use before. This instance is no exception. Additionally I’ve been consolidating my old web servers due to a steady decrease in their load as sites get retired or removed; this has made me reevaluate what I wanted to do with this site as it would require a migration to another server anyway - a perfect opportunity to play with something new.

This site used to run on a flat file CMS called Grav that I’ve really had no complaints about. It’s been fast and maintenance free and there have been a steady stream of updates for the core system as well as the common plugins I used. But times are changing and I’ve been interested in using the static site generator Jekyll for a while.

Paired with Github Pages, Jekyll makes for a mean little tool that makes development and deployment fast and pretty easy to understand. The fact that Github Pages uses Jekyll under-the-hood means that it’s treated as a first-class citizen and everything works out of the box. You can develop locally, get everything just the way you want and then push to your remote repository and with any luck everything will be working and live without any further actions.

This is the first time I’ve had a website that uses git for storage. This idea is great both in concept and practice, having the ability to view the history of all files in one place is valuable when putting together a site. It’s a shame that the bar is set so high when setting all of this up, although this is simple for a software engineer, WordPress will always be more approachable than pushing and pulling your changes in a terminal to a muggle. And yes, I know that WYSIWYG content management systems exist for Jekyll and other static site generators but at that point you may as well use WordPress or some other traditional CMS, the magical experience of using Git and a text editor is long gone.

So here we are. I hope to write more on this site in the coming year, not because anything I write should be read by anyone but because this is a good place to leave myself a trail of breadcrumbs when it comes to problem solving and development practises going forward. Future me won’t remember much.