This was my first RailsConf, and it was at the Las Vegas Hilton. Despite the unpopularity of the choice of venue, the conference was overwhelmingly entertaining and intellectually stimulating.

I highly recommend watching the keynotes. In particular: DHH’s opening keynote and (Uncle) Bob Martin’s excellent talk, “What Killed Smalltalk Could Kill Ruby Too”.

The RailsConf organization encouraged community videos, so hopefully footage of the sessions I highlighted below will become available as time goes on.

Rails 3 - Have It Your Way

This new Rails slogan underscores the customizability of Rails 3. DHH emphasized that you’ll still be able to hit the ground running with Rails out of the box, while more special problems can be solved by swapping out Rails components for more custom solutions. Want to use DataMapper instead of ActiveRecord? No problem. Want to use JQuery instead of Prototype? As you wish.

In short, Rails will be fully functional out of the box, but very customizable given time and configuration.

But it didn’t stop there. A common theme in many sessions was : is Rails really necessary for every web application you write? Some sessions even focused entirely on non-Rails technologies. This was a more open-minded position that I am used to seeing from the Rails community.

Rack / Metal / Sinatra

There was a lot of activity around Rack, Metal and Sinatra at the conference. At least 3 sessions covered any 2 of the 3 topics. For me, realizing that Metal allows any Rack compatible application to act as middleware was particularly exciting. In Rails 2.3+, you can bypass most of the Rails stack to optimize a particular resource by using Sinatra. How cool is that?

Cucumber

Cucumber isn’t entirely new to me. I’ve been using it on my pet projects since the RSpec book went into beta. What was excellent for me to see is the unanimous support it received at RailsConf. There was an impressive attendance to Aslak Hellesoy’s cucumber talk (most of which is covered in the recent RailsCast on cucumber).

Aslak asked for show of hands: “who is using cucumber for integration testing?” Overwhelming yes. “Keep your hands up if you have non-technical people writing specs” At this, an underwhelming few kept their hands up.

But whether or not cucumber is being used for its ideal goal of having stakeholders write value-driven feature specifications— this is still a powerful technology that is not going to fade out any time soon.

Session Highlights

Git Tricks / Scott Chacon

Man this guy loves git. I’ve watched several of his GitCasts and this was like an octane-fueled version. His 60-second overview of git at the beginning was hilarious.

The tips ranged from extraordinarily geeky to incredibly useful. Definitely check out the slides

Mocks and Stubs / David Chelimsky

David is an excellent speaker. I fully appreciated his overview of mocks versus stubs— how they are often combined and confused (I couldn’t tell you the definitive difference before attending this session).

we verify stubs by checking state after an action

we tell mocks to verify interactions

In his session he brought up Pat Metheny’s response to the question, “what modes do you use” which was “that’s like asking ‘what verbs do you use?’” In other words, verbs, modes, patterns, tests emerge from the context in which their necessity is born. This resonated with me. In this session David outlined several reasons for isolated testing using mocks. As it turned out I had done every single one of these, despite the fact I couldn’t have named any of them before this talk.

Slides

Map / Reduce with RabbitMQ / Paulo Negri

This presentation really opened my eyes to the power of RabbitMQ. I’ve been meaning to try out this AMQP-compliant message daemon for a while now. And now with the emergence of carrot it’s no longer an issue to use with synchronous Rails servers (mongrel, passenger).

Paulo’s talk focused on a few real-world business applications of map/reduce on top of RabbitMQ.

Modeling Workflow in Rails / David Bock

David Bock gave an excellent overview of State-Based and Process-Based workflow systems, and how to implement them in Rails by combining the excellent AASM gem and some vanilla Rails conventions.

Lightning Talks

I caught about two thirds of the lightning talks: 5 minute presentations by anybody about anything interesting.

Of note:

• Bryan Liles’ TATFN-heavy proselytizing about TDD and being an active member of the community.
• Yoshiteru Negishi’s talk on Cookpad (which serves 6 million unique visitors per month)
• Joshua Hull’s Rack hacks that he had made for each day of the conference
• Josh Nichols’ Jeweler presentation (easy rubygem creation)

I solved this problem today with a simple subclass. Here’s the code:

# Creates a Builder::Markup implementation that dasherizes all element and attribute names
# Use this just like you would Builder::XmlMarkup
class DasherizingBuilder < Builder::XmlMarkup

  def _start_tag(sym, attrs, end_too=false)
    super(sym.to_s.dasherize, attrs, end_too)
  end

  def _end_tag(sym)
    super(sym.to_s.dasherize)
  end

  def _insert_attributes(attrs, order=[])
    return if attrs.nil?
    new_order= []
    order.each {|item| new_order << item.to_s.dasherize}

    new_attrs = {}
    attrs.each do |k,v|
      new_attrs[k.to_s.dasherize] = v
    end

    super (new_attrs, new_order)
  end

end

Put it in your lib/ and just new up a new DasherizingBuilder to make “<sad_clown>” into “<sad-clown>”.

Enjoy!

You can use the gem server command, but if you already have an apache HTTP server somewhere, incredibly easy to get a private gem repository going, server why not use that?

1. Copy the .gem file to your server

scp your.gem your.server:/your/gem/path


2. Create a folder for hosting your gems on the server

ssh user@your.server
cd /var/www/html
mkdir my_awesome_gems
cd my_awesome_gems
mkdir gems
cp /your/gem/path/*.gem ./gems


3. Generate the gem index
gem comes with a command generate_index which generates all of the files necessary for serving gems over HTTP.

cd /var/www/html/my_awesome_gems
gem generate_index


At this point you should be able to access http://your.server/my_awesome_gems/ and see file listings.

4. Add your new source and install your gem on your client

sudo gem sources -a http://your.server/my_awesome_gems/


You should be able to install your gems from this repository now!

sudo gem install [your gem]


That’s it, you’re now stashing gems in your own repo!

Say you have the following Mooable module (as a rails plugin) that you want to dynamically inject into ActiveRecord::Base (or any ruby class for that matter).

# app/models/my_model.rb
class MyModel < ActiveRecord::Base
 ...
end

# plugins/mooable/lib/mooable.rb
module Mooable
  def moo
    return "Moo!"
  end
end

# plugins/mooable/init.irb
ActiveRecord::Base.send :include, Mooable

# test
MyModel.new.moo # => "Moo!"

But what if you wanted #moo to be a class method on ActiveRecord::Base? I was tempted to do the following:

#plugins/mooable/lib/mooable.rb
module Mooable
  def self.moo
   return "Moo!"
  end
end

# test
MyModel.moo # => NoMethodError: undefined method `moo' for MyModel:Class

As you can see, simply defining the module method as a class method is a no-go (I’m sure this is a major nuby mistake, but it’s always worth a try!)

The best way I have found so far to monkeypatch new class methods into rails classes with a plugin is to use the Object#extend method inside of the module’s self.included hook. The new class methods are defined within a sub-module Mooable::ClassMethods for easy inclusion.

# plugins/mooable/lib/mooable.rb
module Mooable

  def self.included(klass)
    klass.extend ClassMethods
  end

  module ClassMethods
      def moo
        return "Moo Static/Class Method"
      end
  end

  def moo
    return "Moo Instance Method!"
  end
end

# test
MyModel.moo # => "Moo Static/Class Method"
MyModel.new.moo # => "Moo Instance Method!"

This works like a charm.

“No good book has ever been written that has in it symbols arrived at beforehand and stuck in,” says Hemingway. “That kind of symbol sticks out like raisins in raisin bread. Raisin bread is all right, but plain bread is better.” He opens two bottles of beer and continues: “I tried to make a real old man, a real boy, a real sea and a real fish and real sharks. But if I made them good and true enough they would mean many things. The hardest thing is to make something really true and sometimes truer than true.”

I often get a lot of flack for thinking and talking about design patterns. I think the main reason is because most people who learn about them, get excited and start wildly trying to apply them everywhere possible– which subverts the underlying principle of design patterns.

One of the most valuable lessons I’ve learned about design patterns is to find them within the context of the problem and not to let the problem be defined by the pattern. Don’t apply your favorite pattern to a problem just because you know or like it. This is what Hemingway is saying; applying a design pattern for design pattern’s sake “sticks out like raisins in raisin bread.”

Admittedly, HABTM is a relationship in Rails that I use rarely. This little snag caught me off-guard last week, and the usual internet searches didn’t yield particularly fruitful results.

Say you have a simple HABTM relationship:

#Predator.rb
class Predator < ActiveRecord::Base
  has_and_belongs_to_many :prey
end

#Prey.rb
class Predator < ActiveRecord::Base
  has_and_belongs_to_many :predators
end

So you’ve added the relationship, now you go to add your join table as a new migration:

class CreatePreyPredators < ActiveRecord::Migration
  def self.up
    create_table :prey_predators do |t|
      t.integer :prey_id
      t.integer :predator_id
    end
  end

  def self.down
    drop_table :prey_predators
  end
end

Now, say you’ve added a few relationships in your database:

select * from prey_predators;
+---+--------------+--------------+
| id |   prey_id   | predator_id  |
+------------------+--------------+
|  1 |   218872420 | 368007386    |
+------------------+--------------+
1 row in set (0.00 sec)

BUT, when you look at your shiny new relationship in the console, you see this:

>> Prey.find(:first).predators
#<Predator id: 1, name: "test_predator" >

You can see that IRB is reporting the predator’s id as 1 and not 368007386. What you’re seeing isn’t the primary key of the predator record, but the primary key of the relationship record in the join table where predator was found.

It would appear that Rails gives any column named ‘id’ precedence when determining the id of the record– ignoring the foreign kesy in the join table. I tried specifying the :foreign_key and :associated_foreign_key on the has_and_belongs_to_many relationship, but that only appears to affect the query that selects the records, not the model’s “reconstitution” from the database.

Unless you want this behavior, just add :id => false to your migration and you’re woes will be gone:

class CreatePreyPredators < ActiveRecord::Migration
  def self.up
    create_table :prey_predators, :id => false do |t|
      t.integer :prey_id
      t.integer :predator_id
    end
  end

  def self.down
    drop_table :prey_predators
  end
end

As I added functionality (and thereby added tests) I noticed that my tests were becoming increasingly redundant, and that Test::Unit’s syntax was making my test files ugly and more importantly hard to read. As I started DRY-ing up the individual tests and trying to find better ways to share code and make the tests more succinct, I noticed that I was driving very close to creating my own mini-DSL for testing Xml with Xpath.

My Requirements for Xml Exporting

1. A required element must always exist in the resulting Xml regardless of the model’s state
2. An optional element:
   • Must exist when the model meets a certain state condition (i.e. the member is not null)
   • Must not exist when that condition is not met

A DSL That Meets My Testing Needs

As mentioned earlier, this DSL evolved from repeated refactoring my tests in order to make them more clear. Here is an example of an XPath-based Xml test:

xpath_tests_for @video_library do
  # ensure that the Xml always contains:
  #   <library><videos></videos</library>
  require '/library/videos'

  # ensure that when certain conditions are met, the Xml contains:
  #   <library><genres></genres></library>
  optional '/library/genres' do
    before :test_missing do |library|
      library.genres.clear
    end

    before :test_existing do |library|
      library.genres << Genre.new :name => "Comedy"
    end
  end
end

Here’s a run-down of the language elements in this mini-DSL:

xpath_tests_for @model

Describe tests for a given instance of a model

require <xpath>

Add a test requiring the xpath in the test-suite’s Xml blob

optional <xpath>

Add a test requiring the xpath in the Xml under certain conditions

before :test_missing

A block defining the conditions whereby the element must be missing in an optional test

before :test_existing

A block defining the conditions whereby the element must be existing in an optional test

How This DSL Emerged

As I mentioned at the start of this article, I didn’t approach this testing with a DSL in mind, the entire concept emerged from my testing. Here is an example of the emergent nature of this DSL. As seen in the earlier example, I can test all of my requirements, but here is a new requirement:

Since this is custom Xml generation for a specific target application, do not change the default behavior of ActiveRecord#to_xml

As you might have imagined the testing currently functions with the test runner calling ActiveRecord’s built-in to_xml method, and my Library model had code in it to generate the custom xml format.

# somewhere in the xpath test runner
xml_for_testing = @video_library.to_xml

# models/library.rb
def to_xml
  # code to render custom xml format
end

However, in order to meet the requirement, I had to change my model, moving my custom Xml generation from to_xml to some new method:

# models/library.rb
def generate_custom_xml
  # code to render custom xml format
end

Now I’m meeting the requirement, but the tests are broken because the test runner is now calling the wrong method for my tests

In order to accomodate this change, I updated my DSL to include a block for specifying how xml should be generated:

xpath_tests_for @video_library do
  generate_xml_as do |library|
    library.generate_custom_xml
  end

  require '/library/videos'
  ...
end

This way I my test runner can yield the data model to the generation block and the block can handle the specifics of using the model to generate xml.

Note: Because i’m doing “red/green” test-driven-development, I actually wrote the new test syntax first and the code later, but for clarity, wrote the article in the opposite order.

Final Notes

If I wasn’t practicing TDD, I probably would have never come up with a succinct mini-language for XPath-based testing. During the initial design of this feature, it would have seemed like an over-engineering. Who wants to put that much effort in testing anyway? However, since the code emerged as necessary from my test-driven-development, I was not only able to write some interesting testing code, but I also now have new plugin for performing XPath testing in other apps.

Not only is this a personal win for TDD in my book, but since this is my first DSL (thanks Ruby!) I learned a few things about development with a DSL. Most notably, since the DSL defines an ideal API, I rarely if ever changed the code in my tests. Most of the work I did to get this functional and optimized was in the test-runner and supporting classes. And all of that code was able to be written without changing my tests

Add a new helper method:
Add the following code to your test/test_helper.rb in order to create the assert_has_xpath method.

#test/test_helper.rb
require 'rexml/document'

# Asserts that the specified xpath matches
# at least once in the given document
def assert_has_xpath (xpath, doc)
  doc = doc.is_a?(REXML::Document) ? doc : REXML::Document.new(doc)
  match = REXML::XPath.match doc, xpath
  assert !match.empty?, "Missing xpath '#{xpath}' in document: #{doc}"
end

Optionally, you can add the above to a module and include it in your test_helper, or in your individual tests.

Use the helper in your tests:
Now, in your tests, you can do something like the following

#model.rb
def to_xml options = {}
  xml = options[:builder] ||= Builder::XmlMarkup.new(options)

  xml.toys{
    xml.toy "ball"
    xml.toy "iPhone"
  }
end

#model_test.rb
def test_create_xml_creates_toys
  model = Model.new
  xml = model.to_xml
  assert_has_xpath "/toys[toy='iPhone']", xml
end

And voila! You now have XPath testing in your Test::Unit tests.

"mile".pluralize_for(trip.miles) #returns "mile" when trip.miles is one and "miles" otherwise.

The mixin code is simple:

# martian_extensions.rb
module MartianExtensions
  def pluralize_for(number)
    unless number == 1
      self.to_s.pluralize
    else
      self.to_s
    end
  end
end

The challenge came with finding a simple, configuration-free way to ensure that this mixin is loaded. Following the guidance of Jamis Buck in this (by now ancient) blog article, i eventually settled on his solution of creating my simple mixin as a full-fledged plugin.

In order to do this without adding any configuration, you can follow Rails’ automagic loading rules, namely, create an apt folder structure under your vendor/plugins directory:

    /vendor/plugins/martian_extensions/
    /vendor/plugins/martian_extensions/init.rb
    /vendor/plugins/martian_extensions/lib
    /vendor/plugins/martian_extensions/lib/martian_extensions.rb

You’ve already seen martian_extensions.rb, as for init.rb, that’s what does the work of ensuring String loads my module and includes pluralize_for:

#init.rb
String.send :include, MartianExtensions

Personally, I’ll keep my core extensions in this single plugin so that I can keep it portable between my applications. It seems pretty clean to me, but if there’s a better solution that you have found, please comment!