Tools for the management of content

For movieos, I’m going to try to avoid building anything like the terrifying custom CMS that powered jerakeen.org, because, although writing web apps is what I do, I’ve always felt terribly hampered by the power of the thing. Once you have a custom CMS, it’s so easy to add more features to it. Every feature you add is probably something that you can’t get anywhere else. Every time I re-wrote the thing that powered jerakeen.org, I had to reimplement more features. Every time I tried to get out of running it myself and host it on a wordpress or something, I had to give up because I couldn’t get the new thing to respect some weirdness I’d done with permalinks five years ago, or it wouldn’t handle both my blog and my code pages from the same templates, so it would be too much trouble to manage.

The custom code is also a pain to run. PHP isn’t my thing, so I tend to write personal projects in Ruby or Python, depending on whim, and that doesn’t make them easy to deploy. I have to run dedicated daemons and reverse proxy through to them from apaches, which would be fair enough for some real application somewhere, but there’s not a lot of memory in this colo box. I’d rather not allocate half of it to mongrel processes. PHP looks ugly, but I’m going to learn it one of these days just because for projects of a certain size, ability to ship easily trumps just about every other consideration.

Hence Tumblr for blogging this time. I’m attracted to it for the same reason I suspect many of my friends are – it’s very easy to put content into it, because of the first-class support it has for different post types, and it’s very hard to customise it to any significant degree. You get to pick a template, and you get to decide if your posts get permalinks with words in, or permalinks with just numbers. End of story. Simple URLs mean that if I need to leave it at some point, it’ll be easy, though I may have dug myself into a bit of a hole with the domain name.

I can’t keep everything in Tumblr, though. There’s a few other pages that I want to be able to manage. In the interests of starting with the simplest thing I can make work, these are currently just HTML files served out of an apache for now, and I’m going to add intelligence to them using JavaScript rather than server-side stuff whenever possible. That being said, it’s nice to have something in the way of a templating engine for them, so I looked at a few modern page baking solutions, after a friend mentioned webby to me as something I should look at: webgen, jekyll, nanoc and webby.

In the end, I went for jekyll. Not for any particular reason, even, it just worked. I check all my raw pages into git, and a post-update hook on the colo updates the web checkout and runs compass and jekyll across the raw files, generating my pretty HTML.

Apache can serve it just fine, it doesn’t rely on a database being up to work, and I can be confident that I can survive a slashdotting. It’s also extremely simple. Let’s see how long I can resist the urge to tinker with it..