Late to the Party: Tag ruby

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.

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.

Multi-stage deployments with Capistrano

chris.a.williams@gmail.com (Chris) — Fri, 29 Sep 2006 12:56:00 +0000

I'm seeing a recurring theme in my feed reader today - multi-stage deployments with Capistrano. It seems that those of us working in larger companies have all hit the same issue - we have some form of user acceptance, staging or other system which mirrors the production in configuration; and we want to use Capistrano to deploy to it as well as production. I know that my current company has a 5-stage process for pushing out releases (we're in financial services, and very paranoid. Whether they'd ever accept Capistrano is another issue).

So here are my lazy pointers to the discussions:

Ola Bini, who's been doing some great posts on ruby metaprogramming, calls out his need for a "production_test" environment.
Simon Harris shares some snippets of deploying to his staged server running mongrel.
Jamis Buck, the creator of Capistrano, weighed in a while ago on multiple deployment stages

Update: Michael Buffington shares his Mongrel deployment for multiple stages

Prototype based Tag Autocompletion

chris.a.williams@gmail.com (Chris) — Tue, 19 Sep 2006 15:12:00 +0000

I've been working on a website that uses tags internally. The acts_as_taggable plugin has been great, but it only takes care of the ActiveRecord portion of tagging. One of the pieces of functionality I needed was to create an autocompleter for users to enter a list of tags on a record. Below is a pure copy-paste dump of my implementation. I'm not claiming it's good code or the right way top do things, but for those looking to use an autocompleter for a text field holding tags might find it useful. The implementation is close to that used by delicious in the tags field on posting new bookmarks.

Here's an example usage:

<label for="tags">Tags</label>
<%= text_field_tag 'tags', @tags.join(' '), :size => 80, :autocomplete => "off" %>
<div class="auto_complete" id="tags_auto_complete"></div>

And the prototype-based class in javascript. You'll probably want to stick this in your application.js file if you're using Rails.

String.prototype.trim = function(){ return this.replace(/^\s+|\s+$/g,'') }

Autocompleter.Tag = Class.create();
Autocompleter.Tag.prototype = Object.extend(new Autocompleter.Base(), {
  lastEdit: '',
  currentTag: {},
  initialize: function(element, update, array, options) {
    this.baseInitialize(element, update, options);
    this.options.array = array;
  },
  
  getCurrentTag: function() {
	if(this.element.value == this.lastEdit) return true // no edit
	if(this.element == '') return false
	this.currentTag = {}
	var tagArray=this.element.value.toLowerCase().split(' '), oldArray=this.lastEdit.toLowerCase().split(' '), currentTags = [], matched=false, t,o
	for (t in tagArray) {
		for (o in oldArray) {
			if(typeof oldArray[o] == 'undefined') { oldArray.splice(o,1); break }
			if(tagArray[t] == oldArray[o]) { matched = true; oldArray.splice(o,1); break; }
		}
		if(!matched) currentTags[currentTags.length] = t
		matched=false
	}
	// more than one word changed... abort
	if(currentTags.length > 1) {
	  // hideSuggestions(); TODO Fix this!
	  return false;
	}
	this.currentTag = { text:tagArray[currentTags[0]], index:currentTags[0] }
	return true
  },

  getUpdatedChoices: function() {
    this.updateChoices(this.options.selector(this));
  },
  
  onKeyPress: function(event) {
    if(this.active)
      switch(event.keyCode) {
       case Event.KEY_TAB:
       case Event.KEY_RETURN:
         this.selectEntry();
         Event.stop(event);
       case Event.KEY_ESC:
         this.hide();
         this.active = false;
         Event.stop(event);
         return;
       case Event.KEY_LEFT:
       case Event.KEY_RIGHT:
         return;
       case Event.KEY_UP:
         this.markPrevious();
         this.render();
         if(navigator.appVersion.indexOf('AppleWebKit')>0) Event.stop(event);
         return;
       case Event.KEY_DOWN:
         this.markNext();
         this.render();
         if(navigator.appVersion.indexOf('AppleWebKit')>0) Event.stop(event);
         return;
      }
     else 
       if(event.keyCode==Event.KEY_TAB || event.keyCode==Event.KEY_RETURN || 
         (navigator.appVersion.indexOf('AppleWebKit') > 0 && event.keyCode == 0)) return;
    this.lastEdit = this.element.value;

    this.changed = true;
    this.hasFocus = true;

    if(this.observer) clearTimeout(this.observer);
      this.observer = 
        setTimeout(this.onObserverEvent.bind(this), this.options.frequency*1000);
  },
  
  updateElement: function(selectedElement) {
    if (this.options.updateElement) {
      this.options.updateElement(selectedElement);
      return;
    }
    var value = '';
    if (this.options.select) {
      var nodes = document.getElementsByClassName(this.options.select, selectedElement) || [];
      if(nodes.length>0) value = Element.collectTextNodes(nodes[0], this.options.select);
    } else
      value = Element.collectTextNodesIgnoreClass(selectedElement, 'informal');
    
    var lastTokenPos = this.findLastToken();
    if (lastTokenPos != -1) {
      var newValue = this.element.value.substr(0, lastTokenPos + 1);
      var whitespace = this.element.value.substr(lastTokenPos + 1).match(/^\s+/);
      if (whitespace)
        newValue += whitespace[0];
      this.element.value = newValue + value;
    } else {
      tagArray = this.element.value.trim().split(' ')
      if (!this.getCurrentTag()) return;  // We had a problem getting the current tag, just return?
      tagArray[this.currentTag.index] = value;
      this.element.value = tagArray.join(' ');
    }
    this.element.focus();
    
    if (this.options.afterUpdateElement)
      this.options.afterUpdateElement(this.element, selectedElement);
  },

  setOptions: function(options) {
    this.options = Object.extend({
      choices: 10,
      partialSearch: true,
      partialChars: 2,
      ignoreCase: true,
      fullSearch: false,
      selector: function(instance) {
          var ret       = []; // Beginning matches
        var partial   = []; // Inside matches
        var entry     = instance.getToken();
        
        entry = entry.trim().split(' ').pop()
        
        var count     = 0;

        for (var i = 0; i < instance.options.array.length &&  
          ret.length < instance.options.choices ; i++) { 

          var elem = instance.options.array[i];
          var foundPos = instance.options.ignoreCase ? 
            elem.toLowerCase().indexOf(entry.toLowerCase()) : 
            elem.indexOf(entry);

          while (foundPos != -1) {
            if (foundPos == 0 && elem.length != entry.length) { 
              ret.push("<li><strong>" + elem.substr(0, entry.length) + "</strong>" + 
                elem.substr(entry.length) + "</li>");
              break;
            } else if (entry.length >= instance.options.partialChars && 
              instance.options.partialSearch && foundPos != -1) {
              if (instance.options.fullSearch || /\s/.test(elem.substr(foundPos-1,1))) {
                partial.push("<li>" + elem.substr(0, foundPos) + "<strong>" +
                  elem.substr(foundPos, entry.length) + "</strong>" + elem.substr(
                  foundPos + entry.length) + "</li>");
                break;
              }
            }

            foundPos = instance.options.ignoreCase ? 
              elem.toLowerCase().indexOf(entry.toLowerCase(), foundPos + 1) : 
              elem.indexOf(entry, foundPos + 1);

          }
        }
        if (partial.length)
          ret = ret.concat(partial.slice(0, instance.options.choices - ret.length))
        return "<ul>" + ret.join('') + "</ul>";
      }    
    }, options || {});
  }
});

JRuby guys hired by Sun, Netbeans Ruby IDE to come?

chris.a.williams@gmail.com (Chris) — Thu, 07 Sep 2006 22:40:00 +0000

Given the news about Sun hiring the JRuby developers, I thought I should chime my two cents in on the ongoing blog discussions.

First, and foremost, congratulations to Thomas and Charles. This is great news for their project and for Ruby in general. It goes a long way to say that the company behind Java is now supporting a project to run Ruby on the JVM. Maybe now I can give presentations on Ruby at my employer and not be chased with pitchforks and tar.

Next, I'd like to address a number of commenters out there. In particular, Cote': Hi there. There's already a project out there to make Eclipse into a Ruby IDE. I's called RDT and I'm one of the lead developers. It's also the set of plugins that those RadRails guys build on top of. Go check it out. Oh, and Tim Bray should too. He makes no mention of it, but maybe that has to do with politics...

Speaking of politics, the underlying tone behind the news is that Sun is looking to create a Ruby IDE in Netbeans. I have to say I'm a bit torn over this. It's great to see a large company want to create a full Ruby IDE and competition leads to better products for the end users, the Ruby community. But can Sun please get over itself and acknowledge Eclipse exists? It seems a bit of a waste of time for them to roll their own IDE rather than support an existing editor like RDT (or FreeRIDE, or whatever). I guess it's a bit too naive of me to think that they'd do something that didn't push their corporate agenda to some extent. Well, I guess I could always ask IBM to throw me some cash...

Tim Bray on Ruby IDEs

chris.a.williams@gmail.com (Chris) — Wed, 06 Sep 2006 13:33:00 +0000

Tim Bray has been posting an ongoing series of articles documenting his experience in creating a Ruby based Atom protocol exerciser. His inisghts are a nice look from a newcomer to the language and he makes a good case for a number of areas where Ruby is behind the times and behind other prevailing languages.

One such case is in IDEs. I've been aware of this since I began looking at Ruby, and obviously with my work on RDT I've been trying to help out in this regard.

I would encourage Tim and other newcomers to the language to give RDT a serious try. While we're light-years away from the level of functionality found in Java support for Eclipse, we've been making some exciting progress on RDT lately.

In fact, for those who don't mind the bleeding edge, you can download our nightly builds via Eclipse's update mechanism at http://updatesite.rubypeople.org/nightly.

The latest builds now include the work that was completed by Jason in his Google Summer of Code project. So the astute among you should now notice mark occurences support for variables, and even some code completion. We're working to polish those features up and get code completion working under more conditions. Right now, it'll work easily to complete variable names in scope or methods on a declared type. There are some severe limitations as to when the method completion will work for now: it's the first method in the chain on the object and the type is able to be inferred (i.e. declared in scope). To try out the type inferrencing (and show I'm not lying!), you can use a simple example of invoking code completion on code like "1.".

I know, it's a long way from the JDT, but we're getting there. And with a pending patch to JRuby, we'll also be able to integrate the refactoring/code generation work by Mirko and company.