Switching to Jekyll
For quite a while now I have been searching for the right CMS platform that I was comfortable with. I have tried many; Wordpress, TypePad, Tumblr and several others. While all good platforms in themselves, none of them felt right for me. Then I found Jekyll.
Jekyll is 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 favourite web server.
Quoting the ReadMe at Jekyll’s Github Repository
This sounded great for me. Basically it takes a bunch of template files as input, and spits them out as a fully fledged hierarchy of html files to a /_site directory. It is the contents of this directory that you will host to the host server of your choice. The problem with a statically generated site however, is providing dynamically generated content. At it’s core, the site would be static, but with services like Disqus showing up, serving dynamic content on a static file is not as much of a problem as it used to be.
My Jekyll Blogging Environment
A popular choice amongst the Jekyll community is to host their content on a git server and deploy to their host via a git hook. I choose to generate my site locally and us rsync to post to my server. If you do use this method without using git to as a file store then I would definitely recommend having a decent backup system in place, as all it would take is one hard drive failure to loose the template data of your site.
I freaking love having my entire site in static files. It’s a nerd feeling that’s hard to explain. As a Mac user, I just need to activate Spotlight with two keystrokes and I can instantly find any old blog post.
Paul Stamatiou on one of the reasons he prefers keeping a static file site.
I have used a few of Pauls techniques on my Jekyll environment I have created a symbolic link of my Jekyll tree to the root folder of my local web server. I have configured apache to set the vhost of that server to point from the ‘jekyll.dev’ URI. I can have a live preview of my site on my local server before I deploy it.
As I use a Mac, I prefer writing my code using Textmate. I work faster and more efficiently, and I feel it gives me more control to write posts than a WYSIWYG editor. If I create a formatting error, it is quite easy to trace and correct.
I also use Pygments for syntax highlighting.
Installing Pygments
I have installed Pygments for code syntax higlighting on my blog posts. Pygments is a Python based program that prettifies code into IDE style highlighting. I will now show you how to install Pygments, whilst also showing it off somewhat:
Download and install setuptools and Pygments
curl -O http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
sudo sh setuptools-0.6c11-py2.6.egg
easy_install Pygments
I would recommend downloading Tom Preston-Werner’s stylesheet for syntax highlighting and including it in your base template header.
Get Tom’s syntax.css
curl -O http://tom.preston-werner.com/css/syntax.css
mv syntax.css /pathTo/Jekyll_blog/css/
Well, ok. That was some pretty vanilla code right there so it didn’t do so much. Look at the bash script below for a better demonstration of Pygments highlighting.
Automating Jekyll Tasks
Typically, writing a blog post would require (filename, Yaml, markdown/textile).
To automate this I dissected this code snippet from TJ on Forrst, for my own environment.
~/.bashrc
# create a new post and fill the template
alias create="sh ~/.postname.sh"
# start up Jekyll for local preview of blog
alias preview="cd /Users/dbar/jekyll-blog/ && jekyll --auto"
# delete the existing built site and rebuild
alias build="cd /Users/dbar/jekyll-blog/ && rm -rf _site/ && jekyll"
# use rsync to push the weblog to my (ve)
alias deploy="echo 'Deploying to remote host...' &&
cd /Users/dbar/jekyll-blog/ &&
rsync -rtz --delete _site/ deploy@foobar.com:/var/www/_site &&
echo 'Done!'"
The code above is a snippet of my .bashrc file. I can create a new post using the ‘create’ command on terminal, which names the file with the relevant date and file, along with a template of the YAML front matter. This command will work in tandem with the code in the script below.
~/.postname.sh
# the contents of ~/.postname:
#!/bin/bash
################
# Get our info #
################
yearmonth=`date "+%Y/%m"`
postdate=`date "+%Y-%m-%d"`
jekylldate=`date "+%Y-%m-%d"`
read -p "Enter the post name: " post_variable;
touch /Users/dbar/jekyll-blog/_posts/$postdate-$post_variable.textile &&
cat <<EOF > /Users/dbar/jekyll-blog/_posts/$postdate-$post_variable.textile
---
layout: post
date: $jekylldate
title: $post_variable
clip:
---
EOF
mate /Users/dbar/jekyll-blog/_posts/$postdate-$post_variable.textile
exit 0
Deploying my Jekyll Blog
Some people chose to keep their Jekyll files on a Git repository, and roll out updates to the deployment server via a git hook. There are several ways to deploy a Jekyll blog.. I chose to generate mine locally and then push the /_site directory to my server via rsync (see .bashrc alias above).
Thoughts on Jekyll
Being the hacker I am, I feel that I have got along with Jekyll rather quickly and easily. Theoretically Jekyll could be really efficient on the bandwidth/cpu quotas, thus being more efficient on my hosting bill.
I love that all my files are within a few clicks on my hard drive, and that I can always get a fully working preview of my site before I deploy. You can get this with most good CMS package, but none of them feel as good as using Jekyll.