Can is the blogging engine I’ve rolled for my site, with a generous tip ‘o the hat to Steven Frank. It’s almost unfair to call this an “engine”: really it’s just 100 lines of Python (and not very good Python, either). Whether that’s an indication of Python’s awesomeness or just my laziness I’ll leave to you. Either way it does what I need it to do:

  • Blog posts are just text files I’ve saved in a directory.

  • I use Markdown as input.

  • Running python can.py publish spits out my entire blog in HTML files. No server-side processing.

It’s far from where I want it to be. The templating system sucks. There’s no good way of saving media for posts. It doesn’t spit out an RSS feed. But it has one thing going for it: it’s on Launchpad.net. Branch it, add junk, and merge it back in. Or don’t.

This means that I’ve (again) broken all URLs to my site. I’ve noticed that — because I hardly write anything — I can remove (almost) all unecessary cruft in the URLs. Before and after:

http://aneviltrend.com/blog/articles/2008/05/06/can
http://aneviltrend.com/archive/can.html

I’m still slapping myself for that /blog/articles bit of the URL. Tim Berners-Lee, the guy who coded the first internet browser, penned an excellent article on the art of beautiful URLs.

Where do I see can going from this point forward? The templating system needs an overhaul. I have three template files describing a base page layout with about one line of difference between each, in flagrant violation of DRY principles. The backend for the templates is hack as well: searching for known strings and using re.sub() to insert HTML. I feel that a cleaner approach would use Python’s built-in DOM support.

Media support just doesn’t exist. At this point my old posts with screenshots are pulling graphics from a temporary directory I set up. But I the approach I’d like is something like this:

  • Publishing script creates a directory per post in a specified media base directory.

  • Drop any media corresponding to a particular post into said directory.

  • The post source uses a flag — something like class='media' — in links that reference local media. The publishing script looks for these in posts and prepends the post’s media directory to the link.

It seems a bit excessive — why not just hard code in the link? — but this approach seems to be the cleanest from a “writing the post” view: I don’t need to worry about what the generated slug will be (since that will likely be the name of the media directory) and it’s clean markup.