Random Inconsequential Thoughts

Switching to Octopress

2011-11-29T16:06:00-05:00

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.

Using Haml with Jekyll

2011-10-31T13:48:25-04:00

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.

They leave html files lying around my source folder. Ideally, the html should be generated into some temporary staging area as needed
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.

# Original idea came from https://github.com/codegram/haml-jekyll-extension and http://rfelix.com/2010/01/19/jekyll-extensions-minus-equal-pain/ # This extension allows the use of Haml layout templates in Jekyll. It has the benefit of not requiring the use to generate the html files in the source folder. Instead, we generate the HTML into the _cache folder and then load the Layout objects from those files. This does affect any other plugin or extension that directly reads the layout files rather than referencing the layout objects from the Jekyll site instance. begin require ‘haml’ rescue LoadError require ‘rubygems’ require ‘haml’ end module Jekyll class Site def compile_haml_layouts Dir.glob(File.join(self.source, "layouts", "*.haml")).each do |f| begin origin = File.open(f).read result = Haml::Engine.new(origin).render raise HamlErrorException.new if result.empty? puts "Rendering #{f}" output_file_name = File.join("cache", "layouts", File.basename(f, ‘.haml’) + ‘.html’) FileUtils.mkpath(File.dirname(output_file_name)) File.open(output_file_name,‘w’) {|f| f.write(result)} if !File.exists?(output_file_name) or (File.exists?(output_filename) and result != File.read(outputfilename)) rescue HamlErrorException => e end end end end class HamlErrorException < Exception end AOP.around(Site, :read_layouts) do |site_instance, args, proceed, abort| site_instance.compile_haml_layouts old_source = site_instance.source site_instance.source = ‘_cache’ result = proceed.call site_instance.source = old_source result end

end

I didn’t change the actual generation code much other than to change where it generates the html files, but I want to highlight the extension code for anyone who might not be familiar with how it works. All you really need to know is that it generates the html into the cache/_layouts folder.

Line 38 tells jekyll_ext that you want to run this code around the specified method, not simply before or after. This allows you to control more precisely where in the code flow you want the original behavior to execute. I wanted to wrap the read_layouts function of the Site class to change the location it will load the html layouts from.
Line 39 calls the haml generation code from earlier in the class. This will generate the html layout files into _cache/_layouts
Line 40 saves off the existing source configuration so we can restore it later.
Line 41 sets the source location to our _cache folder.
Line 42 calls the existing read_layouts method. The proceed object passed to us in the block is a Proc object representing the original method. The read_layouts method will look in the configured source folder for a folder named _layouts and read the html layouts from there into Layout objects. This is why we changed the source folder earlier – we want to make read_layouts read from the _cache folder rather than the existing source folder.
Line 43 sets the source folder back to the value we saved earlier.
Line 44 returns the result of the read_layouts call.

The great thing with this approach is that we don’t clutter our source folders with both source and generated content, something I really hate. When I edit a Haml layout, it gets regenerated and used to generate the rest of the site in --auto mode.

I hope this helps someone out there… I hope to have a compass plugin that works the same way. I really want to be able to quickly iterate on my styles without having to constantly kill and restart the jekyll server.

UPDATE
My compass extension is now ready as well.

First post with Jekyll

2011-10-02T15:17:02-04:00

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.