Andrew Ingram

New Website: Implementation

Posted on .

The technologies I ended up using for my website rebuild.

When I made the decision to rebuild this website at the start of the year, I opted to focus on getting something live quickly rather than fuss over non-essential functionality. This was a deliberate departure from how I normally approach personal projects, but it ended up being a valuable experience. There's something strangely rewarding about knowing there are things you want to improve on, but still going ahead and releasing anyway.

As I mentioned in the previous post, the last website was powered by Expression Engine, which did the job well at the time but suffers because of its nature as an off-the-shelf solution. They have their place, but in my experience require a lot of non-transferable knowledge in order to use effectively.

With all this in mind, I decided to code up my own software. Not only does this approach give me greater control over what functionality exists, but with the right tools I'm able to build something in less time than it would take to coerce an existing application into fitting my needs. As long as you can handle deployment, the current generation of web development frameworks like Django and Ruby on Rails are sufficiently powerful and intuitive to be real competitors to the likes of WordPress, Textpattern and Expression Engine, even for a simple blog site such as this one.


I've been using Django full-time for the past 4 years, and I'm a big fan of it. It's not without its warts, but it gets a lot right and lets me work very quickly. There are also a number of platform-as-a-service solutions in their infancy, that are starting to solve what has historically been a fiddly deployment process for Django projects. I'm also using version 1.4 (alpha), there's nothing that absolutely prevents me using 1.3, but a few of the changes have simplified deployment, and a personal site is a safe sandbox to experiment with new functionality.

Django's class-based generic views were a big timesaver on this project, i've used them extensively on significantly larger projects, but this is the first time I've used them on a small one. They're not perfect, and the documentation for them is poor, but they're worth a look if you often have a lot of repetitious logic in your view code. I've even written some extra ones that make working with formsets pretty trivial.

The site is served through nginx, which handles the static content like CSS and JavaScript directly, and proxies the Django requests to uwsgi. The uwsgi processes are controlled by supervisor, not really necessary but I wanted to learn how to use it. Native support for uwsgi in the newer versions of nginx means that it's now just as easy as using gunicorn, both are far more straightforward than using Apache. I'm using sqlite3 for the database because a site this simple doesn't need a full-blown database like PostgreSQL or MySQL, I'm quite interested in seeing how this goes. All of this is hosted on a single Linode VPS, which I strongly recommend.


It's been a while since I've done any significant front-end work, and there've been a lot of significant developments over the last year. Even though it's not supported by older versions of Internet Explorer, HTML5 is seeing rapid adoption by front-end developers. A simple piece of JavaScript fixes most of the IE issues, so I saw no compelling reason not to use it. I'm looking forward to playing with more of the fun new features of HTML5, CSS3 and JavaScript in future projects.


At the moment, blog posts are written in Markdown through Django's admin site. I may reach the point where Markdown isn't powerful enough to take advantage of HTML5 tags like <aside> and <figure>, that I'm likely to want to use eventually. I'll have a couple of options when this happens: I could extend the Markdown syntax (asides would be easy, figures less so), or I could use contentEditable and edit the content on the blog post pages directly. I prefer the latter approach because it removes the layer of separation between authoring and previewing the posts, but it would be considerably more complicated to implement. That's a problem for another day though.

I'm going to end up open-sourcing the code and configuration behind this site. There's nothing clever or complicated, but there's no real reason to hide the code. I love seeing how other people build things, so it seems only fair to reciprocate.

Now all the self-indulgent "building this website" posts are out of the way, I'm looking forward to writing some real content!