So, this is a blog...

Posted on 20 Jan 2014

I’ve been thinking of publishing a blog for a while now, but have been hesitant. I’ve had blogs in the past, as well as a handful of other personal sites containing all manner of junk over the years. They’ve mostly been for my own amusement more than anything else, but I’ve mostly not wanted to add my own cruft to the already crowded ‘blogosphere’. Mostly because, well, who cares? Do we really need yet another person wasting bits? But I’ve finally broken down and made my own blog - for a couple of reasons, which I’ll gladly waste some bits elucidating for you.

I’ve been looking at the Jekyll project for a bit now and thought it was a really neat idea. Not only do I have some projects that could benefit from Jekyll itself, but I also have an idea for a project that I have at work that could work something like Jekyll, and so I wanted to give it a go and see what it was like to use it, and how I might steal some of its ideas. Combine Jekyll with Github Pages for free and easy hosting of the site, and I’m sold.

I work for Vevo, where I tend a rather traditional CMS. It provides a set of tools for managing content, and also handles rendering that content for front-end users. The CMS itself is custom software, so it differs from any off-the-shelf software, like Wordpress or Drupal, but has affinities with both. I have a simple API for some of the data, but it is far from RESTful in that it is just outputting JSON templates instead of HTML. I am now in the position to fundamentally change the way that the system works, and so I’m considering an approach similar to, but not quite like Jekyll.

So what makes Jekyll so different? The way a ‘traditional’ CMS works is that the content creator logs in to an admin section of the site and uses tools for creating and managing content to set up the site or blog posts or whatever content it allows. When a user views that content, the CMS grabs it from wherever it is stored (since we’re talking about PHP CMSs here, it’ll most likely be a MySQL database) and does its magic to render that content. It marries templates that describe the look and feel of the site with data that describes the content and spits out the finished product to the end user. If it’s fancy enough and/or the developer is smart enough, it will include some kind of caching mechanism so that it doesn’t have to do all of the heavy lifting each time. But sooner or later it will have to do that heavy lifting again when the cache expires. But the problem is, for things like blog posts, the content rarely changes. New blog posts may be added or updates made to old posts, but the content is by no means in constant flux or dynamic. This is not a stock ticker, the data is pretty stagnant. So why am I doing any heavy lifting?

Jekyll stands this on its head. The sites it creates are static - they never change. They are just a set of linked documents, not unlike the kind of site I’d be building fifteen years ago (although a lot fancier now, of course). So how is this any different/better? Well, instead of having to manage those documents, Jekyll provides a way to easily set up content and then publish it as a static site. I don’t have to manually manage those pages myself, and it can add some dynamic content when it compiles the pages. For instance, using the ‘site.time’ variable I can insert the time that this page was published right into the page and Jekyll will render the date when I publish this page: 2019-05-29 19:02:44 +0000

Combining this publishing platform with Github Pages I am able to easily publish blog posts onto a CDN with little worry of downtime or outages. Or, at least, I don’t have to directly manage the hardware responsible for that and can rely on others to manage it. The project that I have in mind would look something like this, only I will still provide those CMS tools to admin users so that they have an intuitive interface for entering and managing data, but end content that needs rendering will be published as static content to a CDN - Amazon S3 in this case. Instead of the content being re-rendered each time the cache expires, it will only be re-rendered when something in the content actually changes, which is not too often. The data itself will be retained in a database, where we can build a more RESTful API around it for those services that require data instead of rendered templates (ie, mobile apps).

I can’t say that setting up this blog was without any issues. It was a little frustrating figuring out where everything goes and getting it working properly. I did have a few issues, not the least of which was figuring out the DNS tools on the NetworkSolutions site (there’s a reason the domain only cost $0.50). But I have most of those figured out now, so I’ll just chalk it up to a learning curve and move on. Where this goes from here is anybody’s guess. I’m planning on documenting various projects and ideas here that may have some merit for posterity, so stay tuned, but by all means don’t hold your breath.

Comments