Kristian Lyngstøl's Blog

Introducing a blog

Posted on 2012-04-13

My new blog is now feature complete. This is not a very big deal for my dear readers, yet, but it does let me write content more efficiently, which hopefully leads to more quality content to those of you who care.

I already wrote a bit about it a few weeks ago. Since I've now made the decision to abandon Wordpress and my tools for blogging are feature complete, I figure I could write an update.

What problem am I solving?

Blogging (I hate that word, by the way) is about content, ideas and creativity. Before I decided to change my blog I had to think about what that means.

I believe the following list covers my needs:

  • It must be comfortable to write and read the content.
  • The content should come first.
  • I want control over my platform. If something is missing, I want it to be my fault, so I can fix it myself.
  • My reads must be able to find related articles.
  • My reads should be able to give me feedback, preferably by comments.
  • I want statistics. The more detailed the better.
  • I want to be able to mix various types of content. Anything from fairly random files/images in /misc/ to proper blog posts or articles.
  • It should be easy to maintain

Of course, it's easy to write this list after I have a solution.

My solution

I've already written a book in reStructuredText. It was a natural choice. All the content is written in reStrucutredText. I also decided to keep each individual blog post in a single file. Take a look at /posts/ and you can see both the .rst files and the rendered .html files. This also serves as an archive, though I admit it's a bit messy. I might make a script that formats it a bit better.

All of the content is also generated before I upload it to my web server. This means I get a local preview if I want to. I've kept my web pages in ~/Documents/Web/ for a long time now, and since that's part of my ~/Documents/ git repository, I also get revision control for free. I already had some scripts in place for rendering part of my home page and rsyncing it.

For tags I wrote a little awk/shell script that simply tracks what posts have which tags and the amount. The individual "tag-pages" are perhaps not too pretty, but as long as the file names are proper, it could/should work.

I quickly realized that comments and statistics would be out sourced. I've set up Disqus ( for comments, and it seems to work OK, even though the design is a bit intrusive compared to the rest of my pages. For statistics, Google Analytics was the natural choice. I also added a little site search from Google.

The only drawback so far is that the scripts can slow down page loading every once in a while. I haven't looked into it too closely.

An other important thing I needed was a feed. I implemented my own little feed builder by reading the Atom-protocol and simply trying it out. It works fairly well, and uses rst2html to render the content (With a special template that only includes the body, not <head> and whatever not). Since the feed only ever updates if I write or modify content, there's no reason why I can't generate the XML file ahead of time. I also made a special feed for posts tagged Varnish, mainly because of

All of this is glued together using make. It's a rather obvious tool for the task, if you know make.

Show me the code!

I don't have a public git repository for all this because that would require me to split it out of my blog and whatever not. It's just not worth it. However, the relevant bits as of right now are:

The tools I use are:

  • rst2html - Renders almost all the HTML
  • make - Build tool/glue
  • gawk - For tag processing and various other tasks
  • vim - for writing stuff!
  • rsync - for distributing the content
  • git - Version control
  • Apache - Web server. Could be anything. Used to run nginx before I switched VM. Believe it or not, I'm not running Varnish in front of this right now.
  • Google Analytics
  • Disqus
  • Google Site Search

Cool details

I'm pretty sure this is one of the platforms that's easiest to scale, if I rule out the external components. Granted, it's just running on a mostly out-of-the-box Apache server now.

I can write and test off-line! I frequently write when I'm on airplanes, so that's convenient.

I can end this blog post on line 128. A nice, round number!