One of the coolest things about wmii is how customizable it is. A significant amount of the fundamental logic isn’t handled by the core code. Tagging, keybindings, even manipulating windows - none of that is set in C (so to speak).

This logic isn’t written in a specialized extension language, like Lisp for Emacs or Javascript for Firefox, though. Instead, wmii exposes a virtual filesystem and is controlled by writing to magic files there.

I went into some depth on this last time, so I won’t ramble about it here. The upshot is that scripting isn’t bound to any particular programming language. The default config script is written in a maximally portable subset of sh; you could use whitespace if you really wanted.

Naturally, I’d like to configure and script wmii in the language I’m most comfortable with: Ruby. Handily, there were others who shared my sentiment. In particular, Mauricio Fernandez created ruby-wmii, a Ruby library for configuring/scripting wmii.

Ah… theres’ nothing like a four-day weekend to allow me to forget about homework and spend some quality time hacking Haml. Over the course of the past two days, I have

• Fixed the benchmark code (multiple times).
• Ripped out all the automatic caching.
• Added support for evaluating templates in the context of Bindings.
• Cleaned up all sorts of internal organizational stuff.
• Added a several methods that could be used to implement caching outside of Engine.
• Changed the way local variables are handled.
• Reimplemented caching for Rails using the new methods.

It’s been a busy couple days.

What does all this mean for you? Well, if you don’t use Haml at all and just read my blog for Emacs tidbits or make_resourceful tutorials, probably nothing. I guess it means you don’t have to read through this post.

Way back when we released Haml 1.7, I said that it was only 1.7 times slower than ERB. In addition, we mentioned that it was 18 times faster than Markaby.

Well, I’m afraid the benchmarks we were running were lacking a little in the accuracy department. See, we had been running them through ActionView, Rails’ rendering manager. Except Markaby, which I couldn’t get set up quite right - that was run as just a templating engine.

This made some sense when we first started out and Haml was pretty much only used with Rails. But now between Merb, StaticMatic, and all the other stuff for using Haml without Rails, this isn’t really the case any more.

Update: As of Merb 0.5, Sass works out of the box. No dependency stuff necessary.

Another release announcement! This time, it’s Haml 1.7.2 that’s being released. Although this is just a build release, there’s actually a lot of cool stuff there. I strongly reccommend upgrading.

If you want to do so, pay attention: we’re recommending a different installation method for Rails this time around. Instead of doing ./script/plugin install, install the Haml gem and use that to install Haml in your application:

One of the many cool things about make_resourceful is that all the accessors and helper methods that make up the default actions and are used by the user are so concise. Most of them are one line. The rest are more, but just because they check properties of the controller to see how they should behave. If you implemented them for each controller individually, they’d also be one line.

Except for one: parent_objects.

def parent_objects
  return [] if parents.empty?
  return @parent_objects if @parent_objects

  first = parent_models[0].find(parent_params[0])
  @parent_objects = [first]
  parent_params.zip(parents)[1..-1].inject(first) do |object, arr|
    id, name = arr
    @parent_objects << object.send(name.pluralize).find(id)
    @parent_objects[-1]
  end
  @parent_objects
end

After many months of development, make_resourceful version 0.2.0 is finally ready for release. We’ve now got a full set of specs (i.e. tests) and full RDoc documentation. The code is cleaner, bugs are fixed, the filesize is smaller¹.

Oh, and there are new features. New, awesome features.

Installation

Before we go into the features, though, let’s talk about installing the thing.

Holy cow has this poor website been through a lot in the last couple of days. At about 11:40 pacific time on Halloween night, my server decided to take a nap.

More of a coma, really: it wouldn’t wake up. Try as my hosting folks might, they couldn’t get it to boot. They had to rebuild the VPS and copy the pertinent data over to it.

Now, it turns out the issue was an incompatibility between Feisty Fawn and OpenVZ. Unfortunately, I only realized this after I tried to update my new VPS to Feisty, and knocked it out as well.