Welcome...to the atrocity exhibition.
Fittingly, this site is powered by Jekyll and Github pages but the precise details will probably take a series of 1,739 posts.
Welcome...to the atrocity exhibition.
Fittingly, this site is powered by Jekyll and Github pages but the precise details will probably take a series of 1,739 posts.
βIs she a werewolf ?
Noβ.
'Does she have the ability to spontaneously transform into a fierce animal ?β
'Noβ.
'Is she a robot ?β
'Noβ.
'Is she a very early version of a robot that is running version 1.0.1 (alpha) of the software that meant she lost to that human-robot hybrid ?β
'Noβ
'Is she a normal human but just set 200 years in a post-apocalyptic world where water, fuel and sunlight are at a premium ?β
'Noβ.
'Is she a clone of that other slightly built but attractive girl who looks identical except for the hairstyle ?β
'Noβ.
'Is she an alien masquerading on earth as a normal human ?β
'Noβ
'Is she Sarah Millican ?β
'Yesβ.
One of the main advantages of a statically generated blog (like Octopress) over a blogging platform that uses a database (WordPress, Drupal) is performance.
My humble blog doesn't get enough traffic for performance to be a consideration and I thought I wouldn't be able to discern any improvement.

This graph is from Google Webmaster Tools. Can you guess when the blog migration from Drupal to Octopress was done ? Yes - that's right - the middle of September (17th to be precise).
Undeniably, the performance is much better (fastest response time of 128 milliseconds) and reliable since the move to Octopress. Unfortunately, this 'before' and 'after' comparison isn't ideal. Previously, the blog was running Drupal 7, configured with a small number of modules using MySQL and hosted on cheap ($6 a month) shared hosting with Bluehost.
The performance spikes (high of 2.5 seconds to access a page !) are probably related to high usage of the Linux server my blog was co-hosted on (rather than a specific Drupal performance problem).
When I migrated to Octopress, I also moved the blog to Amazon S3 storage so it's not entirely clear how much S3 has contributed to the relatively stable and fast response times of the blog since mid-September.
With hindsight, I really wish I had phased the migration by deploying Octopress for a month on the same Bluehost hosting (using rsync) and then moved to Amazon S3. Still, it's a but late for that now.
However, it looks like I am ready for the SlashDot effect.
Diamond Geezer recently posted his annual analysis of how many blogrolls he appears in. Unsurprisingly, perhaps, the number is steadily declining and he finds it harder to find new blogs to add to his list.
I thought it might be interesting to look at the blogging platforms used by the 98 blogs listed. Here are the results:
The dominance of Blogger/Blogspot didn't surprise me that much. I have noticed before that it's very popular amongst UK bloggers; particularly veteran bloggers who maybe had less choice available that the plethora of options available today.
Which blogging platform do you use and why ?
My site has 966 posts and 70 categories.
By default, Octopress re-generates the entire site - every single post, all the category pages, the archive pages
On my Acer Aspire One (Intel Atom 1.66GHz) netbook, the regeneration takes around 10 minutes.
There are a couple of options that can significantly reduce this time and make the write/preview/edit iterative process more tolerable.
Firstly, you can use 'rake isolate' to move all other posts into a 'stash' directory and simply process the newly created post.
$ rake isolate['speeding']
$ ls source/_posts/
2012-09-20-speeding-up-octopress-generation.markdown
This reduces the generation time significantly to 18 seconds.
$ time rake generate
## Generating Site with Jekyll
unchanged sass/screen.scss
Configuration from /home/andy/blog/octopress/_config.yml
Building site: source -> public
Successfully generated site: source -> public
real 0m18.192s
user 0m14.369s
sys 0m1.368s
This is helpful for previewing the post as it will work on the site and fixing typos but still the time consuming site generation needs be to done prior to deployment.
$ rake integrate
$ rake generate
The second method is to use 'jekyll --limit-posts This also significantly reduced the site generation time Out of interest, I converted my content into Hyde (a static site generator written in Python). Hyde generated the entire site in 9 mins 17 seconds. However, Hyde also supports incremental builds (which took just 34 seconds for a single new post). I also tried raw Jekyll using the default Tom Preston-Werner theme. This took 2 minutes to generate the site in its entirety. The last ever migration of this blog is now complete. This blog is now powered by Octopress and is a statically generated site hosted on Amazon S3. All posts have been migrated from HTML to Markdown and every single permalink (all 954 of them) have been painstakingly checked, rationalised and consolidated. To achieve this, I simply generated a sitemap of the Drupal site and compared this with a sitemap for a test site using Octopress after the data migration. This unveiled a few issues that needed to be fixed: The permalink structure is now 'site.com/yyyy/mm/dd/hello-world/' (with a trailing slash) and will never change. Ever. Again. I also resurrected some orphan Disqus comments by using the URL mapping tool which works brilliantly and helped identify comments associated with a non-existent URL. I am generally delighted with Octopress as it bundles so many features I need for a blog (Disqus, Google Analytics etc) and is much easier than using raw Jekyll. The only vague disappointment is the fact that the entire site is re-published even after a single post has been added. On my Aspire One netbook, a 'rake generate' takes 8 minutes. I might try the same process on my work laptop (faster, newer Lenovo Thinkpad) for comparison purposes. Inevitably, there is a Jekyll fork that supports incremental deployment but the Octopress author is (understandably) reluctant to base Octopress on a fork that could quickly become stale. Publishing the site to Amazon S3 is slightly better but, as Atom feeds get regenerated for categories, this still takes around 4 minutes. Still, maybe this lengthy publishing process will encourage me to properly preview and get my posts perfect before publishing. I am not sure about having all 954 posts stored in a single directory; I would rather have a sub-directory for each year but then again, being able to quickly search all posts for a keyword using 'grep' is useful. I decided to keep the Feedburner integration for now (to avoid losing my two readers). The use of a statically generated site also killed one of my favourite features - my legendary and award winning rotating tagline. Oh well. Blogging like a hacker but publishing like a snail with a heavy weight strapped to his back. Octopress is great Wish I'd bitten the bullet earlier. This is my first post in Octopress. The text uses Markdown which is marvellous. My favourite blogging platforms are: The BBC is a popular Web site. End of message. Loose thoughts on the plan of attack for the blog migration: I am a veteran of blog migrations with the scars to prove it. Here is a handy cut out and keep checklist of the important things I normally forget: Please feel free to add your own tips in the comments.desc "Generate jekyll site (last 5 posts)"
task :fastgen do
raise "### You haven't set anything up yet. First run `rake install` to set up an Octopress theme." unless File.directory?(source_dir)
puts "## Generating Site with Jekyll (last 5 posts)"
system "compass compile --css-dir #{source_dir}/stylesheets"
system "jekyll --limit_posts 5"
end
$ time rake fastgen
## Generating Site with Jekyll (last 5 posts)
unchanged sass/screen.scss
Configuration from /home/andy/blog/octopress/_config.yml
Building site: source -> public
Successfully generated site: source -> public
real 0m59.061s
user 0m40.995s
sys 0m6.956s
migration complete
the awkward second post
Hello World
migration plan
blog migration checklist