Recently, I was approached and asked how this blog was made. Well, the foundation is Jekyll, described by its developers as

a simple, blog aware, static site generator. It takes a template directory (representing the raw form of a website), runs it through Textile or Markdown and Liquid converters, and spits out a complete, static website suitable for serving with Apache or your favorite web server. This is also the engine behind GitHub Pages, which you can use to host your project’s page or blog right here from GitHub.

Just as the description says, each post is written in a Markdown formatted text file with a special YAML front matter. Jekyll uses these content files and templates, to produce static HTML pages. These pages are then served by the nginx web server.

Although some dynamic features such as comments (although they can be integrated with services like Disqus) are not possible with the static Jekyll approach, there are certain aspects that make up for these defiances:

Version Control with Git

The real fun is, that this blog is actually backed by Git. For each private project that needs to be version controlled and available wherever I go, I add a new Git repository to the Gitolite installation on my VPS. There is also one blog repository that contains the Markdown sources, HTML templates, Jekyll configuration and assets. Whenever I push new commits to the server, the Jekyll site-generator is called (see this post from Nick Plante) and the resulting HTML files put in the directory, where nginx can find them.

The usual workflow for me then goes like this:

  1. Create a new branch off of master that contains either a new post or a fix to the layout.
  2. Hack, hack, hack and commit.
  3. If it is a long-term post, I will push the branch otherwise …
  4. I merge with master with the branch and …
  5. push the master.
  6. The HTML will be re-generated and the new content goes online.

Usually I setup a local Jekyll server using jekyll --server that serves on to preview what I produce. This feels a bit like the edit-pdflatex-view cycle when creating TeX documents but is a million times faster than writing content into a shaky JavaScript editor of a Wordpress blog.

Responsive Design

Being a smartphone user, I always complain when web site developers do not provide a specific mobile site or at least some CSS that adjusts the site to the actual display device. Thus, I shamelessly stole the CSS from 87studios’ responsive navigation tutorial and adapted it to my needs. In the following screen shots you can see the difference:

This solution is not as fancy as Mat Tomaszewski’s site, but at least it does not look like total crap on mobile devices (that support media queries).


The main font used on this site is PT Sans by the Russian font foundry Paratype. It has a large glyph coverage and is very legible, at least to my eyes. Unfortunately, the kerning sometimes looks really bad when viewed with Firefox. The code examples are set in Droid Sans Mono designed for the Android mobile phone OS.


That are the technical details concerning this blog. Although the blog is working as advertised I still have one problem: I am a terrible web site designer and have only a very limited CSS knowledge. This is the reason why the style.css is such a mess and the “archive” section at the bottom of the front page still does not look like I want it to be. Hopefully, this will change in the future.

So, that’s it. If you feel you need more control over your content, you should really consider to move to Jekyll and be part of the group of cool internet kids.

One last thing. You might ask what “bloerg” means: It doesn’t mean a thing.


This post might also have some comments at Google+.