Late to the Party: Category Programming

Aptana Studio 1.0 Released!

chris.a.williams@gmail.com (Chris) — Tue, 30 Oct 2007 12:41:00 +0000

Wow it's been quite a while since I last posted. In the meantime I've been working hard on RDT and RadRails at Aptana and the job has been great. I'm very lucky to have found a way to work on the open source projects I love full-time.

In that vein I'd like to announce that we've released the 1.0 of Aptana. This release is important for a number of reasons. First, we think the product is good-to-go for everyone. Second, we're announcing a Pro version of the IDE. This version is for users who want to support the project so we can keep going, or who want the extra features and perks that come with a license: nightly build access, priority support, IE Javascript Debugger, SFTP/FTPS support and all sorts of other goodies. The support, nightly builds, SVN access also apply to the other components of what we're now calling Aptana Studio: RadRails, iPhone, PHP and AIR. So if you want to be on the bleeding edge of RadRails/RDT development you'll probably want to look into getting a license.

Keep in mind that while we do offer a pro version for those who'd like to support us or the extra stuff, we are still shipping the same codebase (minus the commercial features) as an open source project under GPL. And we plan to remain an open-source company with an open source product. Here's hoping that model will work for us!

Aptana backs RDT, hires me

chris.a.williams@gmail.com (Chris) — Sat, 21 Apr 2007 16:41:00 +0000

I'm proud to announce today that Aptana has hired me to work full-time on RDT, RadRails and integrating that work with their existing Aptana IDE which focuses on CSS, HTML and Javascript.

This announcement means that RDT will now have commercial backing (but will remain open-source and free!) and that you should see RDT and RadRails move forward at a much quicker pace than in the past.

This is also great news for RadRails users and Rails developers in general as integrating the two will give you code completion, outlines, help, debugging and much more across the entire stack - from model to controller to the HTML, ruby code, CSS and Javascript that make up your views.

RadRails dying off?

chris.a.williams@gmail.com (Chris) — Tue, 06 Mar 2007 14:02:00 +0000

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.

SVN and SVK

chris.a.williams@gmail.com (Chris) — Fri, 16 Feb 2007 13:38:00 +0000

Dear Lazyweb:

I would like to take an existing SVN repository of a project (like say, Typo), check out a tagged version, create local modifications and save the modified version in a local/home SVN repository(my blog). Later, I'd like to sync up the local version to a new tagged version of the original repository (Typo), handle any merges locally and then check in the result into my local repository again. Rinse and repeat, ad infinitum.

Is SVK the right job for this? Has anybody done something like this? Essentially its the equivalent of creating a branch on a SVN repository but having that branch in an entirely separate SVN repository instance. I don't have experience with this, so I'd greatly appreciate any pointers anybody out there might have.

RDT gets Refactoring support

chris.a.williams@gmail.com (Chris) — Tue, 06 Feb 2007 16:37:00 +0000

Well the cat is out of the bag: Mirko Stocker and his cohorts have committed their refactoring support to RDT's Subversion repository.

This means we'll be able to roll out 0.9.0 with this support. Right now we're working to get it integrated into the build process, so that it will begin showing up in our new builds. I'm pretty excited myself, because I've had little chance to try out their work.

This refactoring support joins other recent work in RDT which allows us to do some occurence marking of variables, code completion and other exciting features (thanks Jason!). There's certainly a long way yet to go to get the tools polished - for instance we still have a hard time doing code completion (or much else) on a file which is being edited while the syntax is temporarily incorrect (the JRuby parser is great, but not so forgiving) - but we're constantly marching forward.

Look for 0.9.0 to come out sometime this month (we're aiming for the 15th)!

Patterns in Ruby: Decorator revisited

chris.a.williams@gmail.com (Chris) — Tue, 26 Dec 2006 18:38:00 +0000

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).

Patterns in Ruby: Observer Pattern

chris.a.williams@gmail.com (Chris) — Thu, 02 Nov 2006 20:10:00 +0000

Another easy to implement pattern in Ruby is the Observer pattern. The Observer pattern is a publish/subscribe mechanism where an objects can register to be notified of state changes (or observe changes) on another observed object. This pattern may often become refactored into a more general event framework (where objects fire events off into queues to which there are listeners subscribed).

The basic implementation

Here's a look at a simple ruby implementation:

class Observable
  def initialize
    @listeners = []
  end

  def register_listener(listener)
    @listeners << listener
  end

  def unregister_listener(listener)
    @listeners.remove(listener)
  end

  def run
    notify_listeners("Hello!")
  end

  protected
  def notify_listeners(event)
    @listeners.each {|l| l.notify(event) }
  end
end

class Listener
  def initialize(observable)
    observable.register_listener(self)
  end

  def notify(event)
    puts "Notified of '#{event}'"
  end
end

observable = Observable.new
listener = Listener.new(observable)
observable.run                        #=> Notified of 'Hello!'

The pattern itself in this form is pretty general. So general, in fact, that there is a module mixin of Observer inside the standard ruby library (observer.rb). There's some good documentation in there, and it provides a simpler path to this implementation:

require "observer"

class TV
  include Observable
  def initialize(channel)
    @channel = channel
  end

  def up
    @channel += 1
    changed
    notify_observers(@channel)
  end
end

class ChannelWatcher
  def initialize(tv)
    tv.add_observer(self)
  end

  def update(channel)
    puts "Changed channel to #{channel}"
  end
end

tv = TV.new(160)
watcher = ChannelWatcher.new(tv)
tv.up                              #=> Changed channel to 161

Please be aware that the API is a little different from my initial example.

Moving towards events

Both of the above implementations rely on a generic observer pattern, but the Observer pattern can often evolve into a simple event mechanism. The difference is that instead of firing a generic event object via a generic notify method, the move towards events uses unique method names, and filters events to notify only those interested in the type of event occurring.

Let's see a TV example where we move towards a more specialized event firing version of the pattern:

require "observer"

class TV
  def initialize(channel)
    @channel = channel
    @listeners = []
  end

  def add_listener(listener)
    @listeners << listener
  end

  def up
    @channel += 1
    @listeners.each {|l| l.channel_increased(@channel) }
  end

  def down
    @channel -= 1
    @listeners.each {|l| l.channel_decreased(@channel) }
  end
end

class ChannelUpWatcher
  def initialize(tv)
    tv.add_listener(self)
  end

  def channel_increased(channel)
    puts "Changed channel to #{channel}"
  end

  def channel_decreased
    # do nothing...
  end
end

tv = TV.new(160)
watcher = ChannelUpWatcher.new(tv)
tv.up                              #=> Changed channel to 161

In this instance we can fire off events for surfing the Tv upwards or downwards (in channels) separately, though we still register listeners into a generic pool, and listeners are expected to contain both event methods. Variations of this can be done to register listeners into sub-groups upon registration by calling unique methods names for each registration, or by passing in a Filter object that can be used to filter to the events the listener cares about. In filtering at registration we can avoid listeners having to implement every event firing method and minimize the number of events fired off.

One illustration of this observer based event model is the Java Swing events API.

Extending the pattern towards this event firing mechanism even further we'd likely move into using queues and firing events off to the queues themselves rather than directly to observers. Observers would then become subscribers to the queues.

Using blocks and procs

The Observer pattern as described above is the typical pattern followed in most languages without closures, lambdas or functors. In Ruby we have the ability to throw around closures/blocks so we can take the pattern a little further.

Let's revisit our original implementation, but let's add the ability to register the callback function to be performed upon notification.

class Observable
  def initialize
    @listeners = []
  end

  def register_listener(&blk)
    @listeners << blk
  end

  def unregister_listener(&blk)
    @listeners.remove(blk)
  end

  def run
    notify_listeners("Hello!")
  end

  protected
  def notify_listeners(event)
    @listeners.each {|l| l.call(event) }
  end
end

class Listener
  def initialize(observable)
    observable.register_listener {|event| "Notified of '#{event}'"}
  end
end

observable = Observable.new
listener = Listener.new(observable)
observable.run                        #=> Notified of 'Hello!'

This is the model illustrated in the Tk bindings for Ruby - you can see examples of usage in Programming Ruby's section on binding events in Tk. That section and their section on blocks as closures begin to broach the how closures capture the context in which they were defined - allowing for some very interesting and complex behavior in using blocks and procs as event or observer callbacks (allowing you to refer to objects available at the scope of the block definition, not when the callback/block execution occurs).

Patterns in Ruby: Singleton Pattern

chris.a.williams@gmail.com (Chris) — Tue, 31 Oct 2006 14:26:00 +0000

The Singleton pattern is the black sheep of the pattern family. It was easy to grasp, developers everywhere applied it liberally, and an inevitable backlash came against its overuse.

I won't make any judgments or reccomendations on when to use it - but I will show you just how easy it is to apply in Ruby.

The literal translation of the pattern is to create a class level instance method and to hide the new method.

    
class Example
  def initialize
    # do something?
  end

  def self.instance
    return @@instance if defined? @@instance
    @@instance = new
  end
  private_class_method  :new
end

puts Example.instance.object_id  #=> 21783380
puts Example.instance.object_id  #=> 21783380

This example gives you the basic idea, but it doesn't cover many cases you'd like to handle, like cloning or duping the singleton. It also doesn't hide the class level allocate method, which means a sneaky coder could still create another instance through some hacking. Lastly, it's not thread safe.

Luckily, Ruby already provides a module for making classes singletons. It's in the standard library, inside 'singleton.rb'. Here's how you use it:

    
require 'singleton'

class Example
  include Singleton
end

This module will do the same thing as my example above but will also handle hiding allocate, overriding the clone and dup methods, and is thread safe. The library file itself contains a bunch of examples of its usage, and those interested should definitely read through it.

One thing to note about these implementations is that the instance method takes no arguments, so none are passed on to the object's constructor. This makes sense because the first time instance is called those will be the arguments used for this global instance. Setters are typically more appropriate for most singletons.

Since singletons are global in nature setters should be at the class level. As an extra bonus here's the implementation of the class level attr_ methods to generate the vanilla getter/setter methods (stolen from Rails).

class Class # :nodoc:
  def cattr_reader(*syms)
    syms.flatten.each do |sym|
      class_eval(<<-EOS, __FILE__, __LINE__)
        unless defined? @@#{sym}
          @@#{sym} = nil
        end

        def self.#{sym}
          @@#{sym}
        end

        def #{sym}
          @@#{sym}
        end
      EOS
    end
  end

  def cattr_writer(*syms)
    syms.flatten.each do |sym|
      class_eval(<<-EOS, __FILE__, __LINE__)
        unless defined? @@#{sym}
          @@#{sym} = nil
        end

        def self.#{sym}=(obj)
          @@#{sym} = obj
        end

        def #{sym}=(obj)
          @@#{sym} = obj
        end
      EOS
    end
  end

  def cattr_accessor(*syms)
    cattr_reader(*syms)
    cattr_writer(*syms)
  end
end

Now we can create a more realistic singleton:

    
require 'singleton'

class JimmyGrimble
  include Singleton
  cattr_reader :boots
  cattr_accessor :football
end

Patterns in Ruby: Decorator Pattern

chris.a.williams@gmail.com (Chris) — Fri, 27 Oct 2006 17:08:00 +0000

I've been a fan of the work that was done by the Gang of Four on Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series), Martin Fowler's Refactoring: Improving the Design of Existing Code and the bridge book by Joshua Kerievsky, Refactoring to Patterns. I haven't seen a lot of information out there on how Ruby changes the game: ways to apply these patterns using Ruby idioms, new patterns that show up, patterns that fall away. So I've decided that as I go along I'll try and document the new twists as I see them.

Today's article is the twist on the Decorator pattern. The Decorator pattern wraps the original object in a new one which will add functionality to some of the methods and then delegate to the original object. The prototypical example is decorating a window object.

A Decorator Example

public interface Window {
  public void draw();
}

In Java, we'd probably use a decorator to add scroll bars.

public Class VerticalScrollWindow implements Window {
  private Window window;

  public VerticalScrollWindow(Window window) {
    this.window = window;
  }

  public void draw() {
    drawScrollBar();
    window.draw();
  }
}

The basic concept is that we'll usually want to be adding some behavior around a particular method call to extend behavior, while retaining the same interface.

Ruby

In ruby, we have a number of options to achieve this pattern. First, let's define our original Window in Ruby code:

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

Translating the pattern literally

Given ruby's duck-typing nature, we could easily create a VerticalScrollWindow that wraps the original Window when we create the original window object, and pass that around. In fact we could patch only the single method and add a method_missing implementation that always delegated to the original Window.

class VerticalScrollWindow

  def initialize(window)
    @window = window
  end

  def draw
    draw_vertical_scrollbar
    window.draw
  end

  def method_missing(method, *args, &block)
    @window.send(method, *args, &block)
  end
end

This approach could be evolved to a much higher level using method_missing tricks and dynamic modifications. One could create a generic Proxy class which took a target class and intercepted all method calls, executing pre- and post- method blocks for specific methods. I'll leave that as an exercise for the reader for now...

Using Alias

Another option we have is to "monkeypatch" the original class (or specific instances of it). The idea here is to rename the old implementation of the method, insert a new implementation and have that refer to the renamed original.

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

  # some code...

  alias :original_draw :draw
  def draw
    draw_vertical_scrollbar
    original_draw
  end
end

Building pre and post hooks

Our last option is to build pre and post method hooks into the original class definition. Obviously, this approach requires the original class' author to explicitly build in callback hooks. This approach can be found in Capistrano (you can add tasks which get executed before or after well known tasks), or in ActiveRecord (lifecycle type callbacks - i.e. before_save, after_destroy).

This option is a bit more advanced and differs in the approach taken. To learn how Capistrano does it, dive into capistrano/actor.rb, line 118. Each task is defined as a method which explicitly calls before and after methods if they exist.

For ActiveRecord, please refer to activerecord/callback.rb. ActiveRecord goes a little further by allowing class level methods to add pre- and post- code blocks to be executed which will be inherited down the class hierarchy. They also allow instance level methods to be defined for each hook which would not be inherited.

Update: Francisco points us to a great article on Decorator showing some other possible Ruby implementations.

Getting Capistrano to play with Oracle on Red Hat Enterprise Linux

chris.a.williams@gmail.com (Chris) — Fri, 27 Oct 2006 15:29:00 +0000

I've been working on an internal project that connects to a legacy Oracle database. The process of getting the driver and client set up was a bit annoying, but I'd done it before and I managed to get through it again. (For those of you braving it, be sure you don't include a trailing slash on your ORACLE_HOME environment variable).

The Oracle driver and client are like most Oracle products - unnecessarily complex. One of its requirements is that you set an ORACLE_HOME environment variable. I'd managed to do this and add it to my .bashrc file so that when I manually logged into the app server via SSH I could get the rails app up and running. The problems was that remotely deploying via Capistrano was causing errors - anything that loaded the rails framework, and therefore the Oracle driver, would die with a stack trace about an undefined method. Luckily in my past troubles with the driver, I knew that meant that it didn't have the ORACLE_HOME environment variable set.

In case anyone else is running into this (or I do again), here's a patch:

First, add the following to your deploy.rb recipe:

set :use_sudo, false

Next, modify your capistrano/actor.rb file to force all run commands through bash with BASH_ENV set:

alias :run_without_env :run
def run(cmd, options={}, &block)
  cmd = <<-CMD
  BASH_ENV=.bashrc /bin/bash -c -- "#{cmd}"
  CMD
  run_without_env cmd, options, &block
end

These two changes will force the environment to be loaded and also make all command be run as the original user (which should have rights to do so).

You can read more about it on the Google group for Capistrano