I recently discovered Octopress, and after some investigation discovered that I was basically working toward my own very similar version of Octopress. Rather than travel further down a road already travelled, I am switching over to Octopress. I plan to port some of my extensions over (and in the process switch Octopress to use ejekyll), but this will let me focus more on getting content into the blog rather than spend too much more time messing with the site generation. Hopefully I’ll start blogging on a more regular basis.

I’m also switching to Heroku for hosting. The code for my site is private, allowing me to store more sensitive information in the configuration and automate things like Flickr integration which require a secret key. Publishing is really simple - I just push to my heroku repo and the site is live. Very simple. I like it.

While I have been working on my Jekyll workflow, I’ve come across one big annoyance: all of the methods of integrating Haml layouts into my workflow have one of two undesirable side effects.

1. They leave html files lying around my source folder. Ideally, the html should be generated into some temporary staging area as needed
2. They don’t integrate well with the auto-generation cycle for quick turnaround while modifying the site content.

I’ve been using the jekyll_ext gem for a while now. The aspect-oriented approach lets me go above and beyond the existing plugin architecture without having to fork jekyll itself and maintain my own changes. One of the pre-existing extensions that I tried to use was the haml-jekyll-extension. It would be executed as part of the automatic regeneration step each time I changed a haml layout file and I could preview the changes instantly without manually rebuilding the site. I didn’t like that it also tried to handle the s{c|a}ss for you. I’m using compass for that. I also didn’t like that it generated the html files right alongside the haml source files. A litle bit of hacking gives you this code. I have modified the extension to only handle .haml layout files, and they generate into the _cache folder.

I seems somewhat obligatory to explain why you’re using Jekyll for your blogging platform of choice when you begin using it, so I suppose I should follow suit.

I’ve been using WordPress for years. I’ve never been a prolific blogger at all. I’m not at all sure that anyone cares what I have to say anyway, but it’s been at least a way to get some of what’s inside my head out of it. In every incarnation of my blog, I’ve always used a blogging platform of some type - I started on Mambo (pre-Joomla), moved to Drupal, and from there to WordPress - all self-hosted. I do have accounts at Tumblr, Blogger, and WordPress.com, but I’ve never been a fan of that lack of control over the site.

I suppose that’s the main point of now using Jekyll - I have total control. That also means I have total responsibility for everything about the site. I really need to learn how some of this stuff works. Despite my years of development experience, I’ve never gotten into Javascript. I’m in a position where I need to learn Ruby. With Jekyll, I can get some Ruby practice writing the Rakefile that helps me manage the site and the generators, converters, and plugins I use to generate the site.

Really, the big reason I’ve switched to this is because it’s something new to try.