RadRails dying off?

Kyle Shank of the RadRails team has mentioned that he and Matt are both working on a web startup. Looks like the priority of RadRails is lower for them - after all, RadRails doesn't make money.

It's a shame that this sort of thing happens, but I can't say I'm all that surprised. I've been working on RDT for nearly 4 years now and I can definitely say that people just don't pay for free things. You can beg for donations, but you shouldn't expect them. Given the amount of time and effort - and the sheer number of downloads - it just doesn't pay the bills to run an open source project that passively solicits donations. I estimate the per-user donations for RDT to be at about 1.4 cents*. And if we take out the one large donor? .00071 cents per user.

That doesn't quite cut it for rent and food, unless of course you get the entire world to use your product.

I wish Kyle and Matt well and hope that others from the community step forward and help lead the project onward.

Update: Looks like RadRails isn't dying off - it's getting new ownership.

* This estimate assumes we count RadRails users as RDT users, because RadRails contains RDT. It also uses just the raw zip downloads from Sourceforge for both projects. There is a large number of users we are not counting here who have downloaded via Eclipse's update site mechanism, and who use RDT from other distributions available.

Patterns in Ruby: Decorator revisited

A while back I wrote an article describing some possible ways to implement a Decorator pattern in Ruby. I've stumbled across several mentions of yet another idiom used so often in the Rails codebase that they've extracted it into the latest ActiveSupport. That idiom is alias_method_chain, and it's a good example of a decorator implementation.

This idiom is a codified example of using the alias approach I briefly mentioned in the earlier article. In that article we aliased the original implementation with anew name, and set up a new implementation of our method (often delegating to the original) with the original's name. A quick example makes this clear:

class Window
  def draw
    # do some drawing here...
  end

  # some code...

# creates a 'copy' of draw method, but gives it
# the name/selector 'original_draw'
  alias :original_draw :draw 

  def draw
    draw_vertical_scrollbar
    original_draw
  end
end

alias_method_chain

In Rails 1.2 (ActiveSupport specifically), the Rails core team found many instances of this pattern and codified a new method on the class Module, alias_method_chain. This class-level method encapsulates this pattern of wrapping existing methods with additional behavior.

Here's a specific example, showing how they would wrap rendering with layouts:

alias_method :render_with_no_layout, :render
alias_method :render, :render_with_a_layout

In this small code snippet, they are creating a small chain of methods to wrap the existing render behavior. Now calls to render will be routed to render_with_a_layout and then on to the original render implementation (which is now aliased to render_with_no_layout). So they coded up alias_method_chain which simply does the wrapping for them (using naming conventions):

class Module
  # Encapsulates the common pattern of:
  #
  #   alias_method :foo_without_feature, :foo
  #   alias_method :foo, :foo_with_feature
  #
  # With this, you simply do:
  #
  #   alias_method_chain :foo, :feature
  #
  # And both aliases are set up for you.
  def alias_method_chain(target, feature)
    alias_method "#{target}_without_#{feature}", target
    alias_method target, "#{target}_with_#{feature}"
  end
end

Please note that if they were to replace their existing two calls to alias_method above, they would need to tweak the naming a little (the methods would become render_without_layout and render_with_layout as opposed to render_with_no_layout and render_with_a_layout respectively).