Introduction
This website is managed with erbium, a CMS I created that is written in Ruby. It definitely isn't any better than any other CMS out there but it is fun to hack on, and surely that is the important thing.
This website once ran under a system called E-fort, that was written in PHP back when that was "the in thing". Up until February 2006 it ran on website-xml, which was a tangled web of GNU make, GNU autoconf, GNU automake, XSLT, Python and bash. Up until October 2006 this site was running on the atom-cms system, but now that the blog is dead a different system is needed.
Backend
erbium uses a home-brew concoction of:
- Ruby
- eruby - for use in output templates
- ncurses-ruby - for administration without hand editing the configuration files
- rake - for building the content, running the test harness and housekeeping
- ruby-breakpoint - for debugging
- ruby-progressbar - for pretty output when generating the content
- Pygments - for Python code highlighting, and to support Pygments a minimal Python install. (A small, and really ugly, Ruby module is used for highlighting Ruby, C and C#).
Contrary to the previous tool, atom-cms, erbium doesn't use a fancy relational database for storage and has reverted back to a filesystem based storage approach. The filesystem approach is just a lot more flexible, as long as you're willing to put a little extra work in at the outset.
Content creation
Content is added using a text editor, and is simply a matter of creating a file in the appropriate place in the hierarchy. The format used for the entries is almost reST, that is created with a small Ruby-based parser I have written. The parser should produce output that is exactly the same as docutils, that was its purpose, but it remains to be seen how successful that will be.
We all know there are a lot of structures one would like to use that isn't available in reST, and rightly so as keeps the format clean and usable. This does mean that there has to be a secondary system to take up the slack for the odd occasion when this matters, and I'm yet to decide on one yet. For the time being I'm just using raw HTML, but I'd prefer to move away from that as soon as possible. It does provide an enormous amount of power though, because eruby is also usable within raw HTML blocks thanks to the order of the processing chain.
And of course there is also the small matter of metadata and reST, there isn't really anyway to express the necessary information for building the site in reST. I really have a dislike for separating the information, as it breaks the simple drag 'n' drop approach to site organisation I like. I've currently opted for including the information in a reST comment block, and I've written a little pre-build parser that pulls the information from there. It is, however, incredibly brittle and needs replacing as soon as a better idea comes along.
And finally...
I'd like to believe that all my pages are valid XHTML and CSS and all my feeds are valid Atom. Web standards are important, and I try to stick to them. Check the content against validators if you wish, and shame me if I've failed :) I believe strongly enough that each XHTML/CSS/Atom file is run through a series of validation tests, and if any of them fail rake stops the build(there is no make style --keep-going flag).
Once rake has fired off all the processes and the build is complete, I have a static tree that can be uploaded to the UKFSN servers. And with the joy that is rsync I don't even need to bother maintaining a record of what has been pushed to the server.