The Rails Edge, 2006 - Day 1

In this post and the two that follow, I highlight interesting talks at The Rails Edge, 2006.  I do it for Google searching posterity and for my admittedly selfish desire to reinforce key concepts presented. 

Metaprogramming - Extending Ruby for Fun and Profit by Dave Thomas

Dave seemed chipper as he clipped on his mic Thursday morning for the first talk of the day; news of Agile Web Development With Rails, Second Edition going to print were still only hours old. 

Having purchased the beta of this book and been the recipient of seemingly endless revisions, I have a small appreciation for what it must be like to give birth to a new title like this.  No wonder he seemed to be on cloud nine.  Plus, I just think he genuinely loves talking about Ruby.

Essentially, according to Dave, metaprogramming boils down to four key points:

• Classes are open - In Ruby a class is just a special type of object that can be manipulated like any other in Ruby.  Adding to or changing behavior in core Ruby libraries such as Fixnum is incredibly useful, is easy, and can make your code much more readable.  The example given showed a quick way to be able to write:

cookie.expiry_time = 3.hours.from_now

• Definitions are active - Say you have the following class:

class Logger
    def log(msg)
        # write ...
    end
end

What if you need the log() method to behave differently if a debug flag exists?  In Ruby you can write:

class Logger
    if ENV['DEBUG']
        def log(msg)
            # write with debug info...
        end
    else
        def log(msg)
            # write as usual...
        end
    end
end

• All method calls have a receiver - In Ruby, any line of Ruby code runs as a method call on some object, whether it is explicit or not.  So, suppose a class method is defined for class Demo as follows:

class Demo
    def self.say_hello
        puts "Hello"
    end
end

A subclass of Demo can call this method in the class context as follows:

class SubClass < Demo
    say_hello
end

The receiver of the say_hello method call in SubClass is, self, the class object (not the SubClass instance).  It's no different that writing:

class SubClass < Demo
    self.say_hello
end

You see these kinds of class helper methods in Rails everywhere.

• Classes are objects - In the example above, Demo and SubClass are objects of class Class.

Dave continued to show how you apply this knowledge to do useful things.  Blocks and closures were covered in the process.  Sign up for The Rails Edge if you want to get the real scoop.

Ruby Idioms for Rails Programmers by Stuart Halloway

If you've never heard Stuart talk, you must figure out a way.  His style is so polished by years of instruction and public speaking as to be rendered flawlessly lucid and interesting.  Add to this a sense of humor that wanders slightly off topic from time to time, keeping things light.  He's also opinionated and deliberately rational, all of which, adds up to talks that never disappoint.

Ruby Idioms for Rails Programmers attempted to capture stylistic and language usage patterns that seem to be emerging as 'good' ways of doing things.  For instance, he highlights Rails' tendency to make things implicit if at all possible, leaving explicit statements to the problem domain.

He discusses how Ruby makes it possible, or even encourages, Personalized Object Models (POMs), where you can and should augment other people's code, implement DSLs with dynamically added method definitions, etc.  This advice is counterbalanced with the caution to use method_missing sparingly, as this type of POM can make it increasingly difficult to track down where and how methods are defined.

Poor Composition Disrupts Flow was a key point.  Essentially, he argues that poor composition often makes the intent of the method difficult to ascertain, casting a vote, instead, to methods concise and with layers of abstraction cleanly distinguished (even separate).

Rails Reflection by Chad Fowler

Chad is decidedly more low key than Stewart but immediately conveys an aura of seasoned experience and deep Rails knowledge.  He proceeded to cover all the ways you might use reflection-style methods to learn about Rails models, their associations, etc.  For instance, did you know you can type:

MyModel.reflections

which will return a whole slew of metadata about this model?

Chad's highlights are extremely useful with Rails given how heavily we rely on script/console to test out new behavior, analyze bugs, etc.  Use Rails style reflection, script/console gets a lot better.

Design Patterns in Ruby by Jim Weirich

Jim Weirich is a bearded, large man with a warm demeanor that inspires an immediate, fatherly kind of respect.  As the creator of Rake, this wasn't required.  Jim's speaking style is also notably deliberate and understandable.  I wish I could've more professors like this guy in my college days.

Jim starts with the idea of patterns, generally speaking then quickly dives into key patterns for Rails, such as Template Method, Strategy Pattern, and Singleton.  To my joy, he concluded the discussion of Singleton by recommending that it never be used, despite how easy it is to do in Ruby (require 'singleton'; class ClassToMakeASingleton include Singleton end).

He also covers a new pattern, possible only in Ruby, that he calls "Blank Slate."  By using metaprogramming to remove almost all methods defined in Object/Kernel, Jim creates a class that literally has almost no behavior.  This allows for domain specific method calls like "class" that would, otherwise, create problems.

He concludes by advising that patterns should always emerge organically, that patterns != good, and that Ruby has incorporated characteristics that relegate certain patterns to history.

Ajax On Rails by Justin Ghetland

Justin Ghetland, in the same class of speaker as Stuart Halloway, introduces Rails' support for prototype, scriptaculous, Javascript, rjs, and JSON.  Other than describing and demoing the surprisingly large number of Rails helper methods that wrap prototype and scriptaculous, Justin also laid out concepts such as how to gracefully degrade your AJAX URLs.