We’re posting this one right at ya from Arrrrcamp 2011 in Ghent. Arrrrcamp is one of the best known RoR events in Belgium. An event Kabisa is a proud sponsor of. Our crew is sitting in the sessions and we’ll report in this post after each event.

John W Long – Design workflow for Rails

We started the day with John W Long’s session about “Design workflows for Rails”. He states that within companies there needs to be knowledge about business, design and development and that the ideal situation is having knowledge of all three aspects. The more these aspects are in synergy with eachother the better. He talked about the things that designing will improve (easier programming, better customer understanding, etc)

Similar to positive aspects that iterative development brings along, the designing of application’s would need to be iterative, too. An agile workflow that would look as following was presented:

• Create userstories
• Design / Prototyping
• Building
• Verifying
• Back to the 1st step, building new features

Conclusion: Integrating designing / prototyping in the iterative daily process will make things easier and will take communication with your customers to a higher level.

Elise Huard – Data Driven Development

Elise talked about DDD (Date Driven Development).
What we take home from her presentation:

• Your first hunch about how your web application is going to work out (target wise) is wrong most of the time; you need to measure interaction and your assumptions and react to that.
• It’s good to build interactive elements (ie:buttons on key locations) that will give you user feedback and that verify if your assumption is correct.
• Check if there is interest in your product(idea) by creating a minimal viable product that you present to the world. Create an update subscription along with that and if there IS interest, you’ll have data (subscriptions) that prove it.

Jonas Nicklass – Practical testing for assorted languages

For Ruby it isn’t acceptable to write code and NOT test it. Jonas asking the croud who works using RoR and who tests their code: all hands go up.

Asking this for Javascript only few hands are raised.Javascript is something that has always been neglected regarding to testing.
Jonas talked about some design setups for testing Javascript; about unittesting javascript.You have to ask yourself what the goal for writing tests is. Jonas indicates he tests because it makes refactoring easier (remember the red-green-refectoring loop from TDD?). Because unittests are based on testing UNITS (it’s in the name) Jonas states that we need more units in JS; we don’t have the classes and modules that are present in Ruby.JQuery is often seen as a „way of building apps”, but it really is NOT.It doesn’t provided the structure needed for creating the units.
Jonas showed some possible solutions for providing structure to JS, giving some pros and cons along with all the options (think Mootools, CoffeeScript, Backbone, etc).

Unittesting JS
Jonas recommends using Jasmine („the best JS testing framework out there”) for unittesting in JS. It is the only stable solution out there at the moment.It is small but full featured.

When it comes to building JS using a packaged Jasmine solution Jonas build a rails gem (Evergreen) that makes integrating a breeze.This can be used for testing JS. It has nice syntax and can use CoffeeScript if you’d like. Add evergreen to your Gemfile, run the server and you’re good to go!
Running tests can be done in multiple ways:

• In browsers (/evergreen)
• Terminal (using a capybara driver); you can use Selenium, Webkit or ENVJS.

Jonas gave a demo using both execution methods. Evergreen showed all the tests present for JS. Clicking on one of them (or the „all” option) runs the test(s) and shows the outcome. Terminal execution was demoed as well and integrated nicely with Selenium.

Suggestions for writing JS unittests
Structure your JS code into functions and classesMostly test event bindingsWrite custom matchers like in RspecIsolate AJAX into seperate components (don’t test or use mocks) to avoid shaky testsTreate templates as fixtures (update them manually) by isolating JS as much as possible from the Ruby code. This depends on JS being setup Simplify your DOM & Templates
Integration testing JS codeJonas talked about Capybare to simulate JS interaction performed by the user and demoed it using Cucumber.

At Kabisa we already use this. Check it out at the web for more info:https://github.com/jnicklas/capybara

Finally, Jonas gave some tips for a better JS integrations test setup:

• avoid asserting on urls, cookies, session, application state
• Asserting to what you can see (interfacing) makes the test more stable. It avoids one for having to update the integration tests constantly.
• Be as lenient as possible (avoid specific selectors)

Roy Tomeij – Stop Swashbucklin’ and Shipshape yer Front-end

Roy talked about Frontend meta languages and The Rails 3.1 asset pipeline.The target audience were people with little Haml experience.
Roy’s statement: compilers don’t create bad code, coders do (regarding Haml output HTML)
A few motivations for using front-end meta language:

• Quick results
• DRY (!)
• Unforgiving compilers, so less errors
• Better performance „out of the box”
• Maintainable code

The front-end meta languages Roy talked about were Haml, Sass(&Compass) & CoffeeScript. He showed examples alongside the output that these language generate (it being HTML, CSS or Javascript).

Roy finalized his talk about Rails 3.1 asset pipelines and where to put all the various assets.

In conclusion: frontend meta languages keep your code clean and maintainable so it won’t hurt to take them into serious consideration!

Andrew Nesbitt – A/B Testing everything with Split

Andrew talked about the question: are you making the best out of your pages?
A/B testing is the process of sharing two designs with your users and learning what works best.
Andrew also showed an example of a salespitch text that – by simply showing another title – made +30% sales.

Some existing  A/B testing frameworks out there:

• Abingo
• niceSevenMinuteAbs
• Vanity

Because these frameworks didn’t go all the way, Andrew wrote the Split library.

Some approaches that could be used for A/B testing:

• Swap css stylesheets
• Render different templates / partials
• Set different variables at the controller level
• Hack the page with JS

Split depends on two classes: Split::Experiment and Split::Alternative. These two, accompanied with a CRUD interface make up Split.

Andrew showed an example using an ab_test statement that showed one of two button images (50% chance you see either option a or b).
In the controller’s signup function a „finished” statement was added, after which you can check in the CRUD interface what option is most chosen / successful.The example showed how simple but powerfull this works.

A new feature of Split is weighted averages; you can now define ratio’s in which to serve option A or B.
Another nice feature of Split is the option to ignore certain IP adresses. This helps preventing your stats being mangled by colleagues who develop or test around.

Some tips regarding to A/B Testing

• If you would want to get definitive favored choices from your users, test BIG changes. The bigger the change the more you’ll see the preffered version.
• A typical A/B test would be ~2 weeks. Mind that this has to be longer if you have a low volume website.
• Don’t run 2 tests that cross eachother’s stream. This will make the results inconclusive.

Conclusion: having trouble discussing the best solution to put out there? Use A/B testing to give all the options a try and let the stats choose a winner.

Cory Haines – Fast Rails Tests

Cory started right on with showing the not-so-speedy process of running Rspec tests.Right after that Cory kicks off some tests that show all greens  „near-instantly”…
Cory talked about the fact that it’s crazy to see such a key element taking up so much time.Thinking back on where we were years ago, thinks aren’t all that bad (referring to the time were an optionally filled /test map resided in projects).Rails changed all that by introducing ways to implement unittesting and integration testing.
He described the evolution of coding; moving business related code to the models. Good for the code, not so good for the speed of tests.

The difference between the Test First and TDD approach is that with TDD,  after you feel the pain, the whole design of the code is corrected instead of the test itself. After that, Cory talked about what „good design” is. His definition of a good design is: a design that is easy to change. He referred to businesses and their need to adapt themselves to their surroundings.
The core pain with Rails testsuites is not „the databases”, even though FactoryGirl or in-memory db’s are trying to create faster experiences. The actual pain of slow tests is Rails itself. Rails is the biggest 3th party dependency in our apps.

Cory demonstrated a way to run rspec on a new directory (fast_spec/speedy_shop/calculates_total_price.rb) in which a ruby file, with only the business logic from the shopping cart model in it,  requires the original codefile followed by the Rspec tests. Using this implementation, spec_helper (that starts rails, and generates all this stuff for you) is not used so you don’t have to wait for the time that would normally take.

He states that one shouldn’t be testing Rails itself and one certainly should not test database interaction by using mocks, because the best test for functionality that interacts with the db IS interacting with the DB (2 db records, one for failing and one for success scenario).
Testing the regular Rspec stuff mostly includes testing the rails configuration that you have put up for your app. This needs to be tested, but not in your main developing circle: build speedy tests to test the business logic in a fast way, and make that process a lot faster (without the accompanying sough).

Conclusion: extracting your business functionality and getting them on track with speedy rspec tests will improve your day-to-day developing cycle and make it less intensive to change simple things and having to run heavy tests.

[1,2,3,4,4,6,2].uniq => [1,2,3,4,6]

This does not work for arrays of ActiveRecord objects, especially if you want uniqueness on a arbitrary property. Here’s a snippet that allows you to uniquify an Array using an arbitrary property:

Hash[*arrayname.map {|obj| [obj.name, obj]}.flatten].values

Basically you create a new Hash, using the unique value as the key and the actual object as value. Then you convert the Hash#values back to an Array.

Although session configuration differs from version 2 to 3, getting this done wasn’t such a hard job, mainly thanks to this blogpost written by Dan McNevin.

Basically this means the sessions are configured as follows:

# Rails 2.1.2
# config/environment.rb
...
Rails::Initializer.run do |config|
  config.action_controller.session = {
    :session_key    => '_sso_session',
    :secret         => 'a really long hex string'
  }
  config.action_controller.session_store = :cookie_store
end
 
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:session_domain] = '.rails.local'
# End of Rails 2.1.2
 
# Rails 2.3.8 (and probably 2.3.x)
# config/initializers/session_store.rb
ActionController::Base.session = {
  :domain => '.rails.local',
  :key => '_sso_session',
  :secret => 'the same really long hex string'
}
# End of Rails 2.3.8
 
# Rails 3.0.1
# config/initializers/session_store.rb
[AppName]::Application.config.session_store :cookie_store, {
 :key => '_sso_session',
 :domain => '.rails.local'
}
 
# config/initializers/secret_token.rb
[AppName]::Application.config.secret_token = 'the same really long hex string'
# End of Rails 3.0.1

Session sharing between 2.1.2 and 2.3.8 worked fine, however when swapping to the 3.0.1 application I got the error:

ActionDispatch::Session::SessionRestoreError (Session contains objects whose class definition isn’t available.
Remember to require the classes for all objects kept in the session.
(Original exception: uninitialized constant ActionController::Flash::FlashHash [NameError])
):

In other words (or actually, my own words): the session contains an object (ActionController::Flash::FlashHash) which is unfamiliar to Rails 3.

To solve this problem, I added the class:

# Rails 3.0.1
# config/initializers/session_store.rb
module ActionController
  module Flash
    class FlashHash < Hash
      def method_missing(m, *a, &b)
      end
    end
  end
end
# End of Rails 3.0.1

Now, the error didn’t show up anymore and so was the session… I was able to switch from Rails 2 to Rails 3, but now the session didn’t contain a single keys!?!?
Assuming there is a require_user method doing the authentication, I added a

# Rails 3.0.1
# app/controllers/application_controller.rb
  def require_user
    y request
  ...
# End of Rails 3.0.1

to this controller action (which is short for puts request.to_yaml) and I was surprised to find the keys, which were stored by the Rails 2 app., in the env object in it’s action_dispatch.request.unsigned_session_cookie key:

# Rails 3.0.1
  y request.env['action_dispatch.request.unsigned_session_cookie']
  # => ---
      serial: 0
      _csrf_token: nTHGmUfA0sKh1rDZWvt+1tLZmG3fCWlhf8pkiHGMU5I=
      last_quote_time_en_US: !timestamp
        at: "2010-10-27 14:52:15.736034 +02:00"
        "@marshal_with_utc_coercion": true
      session_id: ef4c356efc12113792ecccbde65bba7a
      user_id: 35
      lang: en_US
      shown_quotes_en_US:
      - 17688
      ...
# End of Rails 3.0.1

Pretty hopeless by now, I decided to get the keys I needed out of this Hash and add them to the Rails 3 session manually:

# Rails 3.0.1
  session[:user_id] = request.env['action_dispatch.request.unsigned_session_cookie']['user_id']
# End of Rails 3.0.1

But this surprised me even more, finding a fully populated session only after adding one key.

Time to investigate the actionpack gem.
When you add a key to the session object, this will call the []=-method in the ActionDispatch::Session::SessionHash class. The []=-method internally calls a private method load_for_write!. My thinking was (since diving deeper into the code didn’t come to my mind) that the Rails 3 session is fully populated, but not yet loaded when going or returning to the Rails 3 application.

This was an easy one, I just had to reload the session before using it:

# Rails 3.0.1
# app/controllers/application_controller.rb
  def require_user
    session.send(:load_for_write!)
  ...
# End of Rails 3.0.1

Problem solved? Well, not completely. I was able to successfully browse from the Rails 2 app. to Rails 3, without losing my session, but going back to the Rails 2 app. introduced another problem: keys initially stored as symbols were now turned into string because of the Rails 3 app.

Initially, I tried to solve this by converting all keys back into symbols, but this should introduce another problem, since I was not sure if all session keys were stored as symbols. Rails itself stores the Flash object in the session into the “flash” key, instead of :flash.

A better approach is to patch the CGI::Session object and make sure all keys can be stored and retrieved as both string and symbols:

# Rails 2.1.2 and 2.3.x
# config/initializers/load_patches.rb
#
# Loads patches stored in lib/patches.
Dir[RAILS_ROOT + "/lib/patches/**/*.rb"].each { |file| require file }
 
# lib/patches/cgi/session.rb
require 'cgi/session'
 
# Patching CGI:Session so that it on longer matters if you retrieve a session
# value using a String, Symbol, ... This in order to make it play nicely
# together with Rails 3.
#
# = Examples
#
#  session[:foo] = "Bar"
#  session[:foo] # => "Bar"
#  session["foo"] # => "Bar"
#
#  session["qux"] = "Baz"
#  session[:qux] # => "Baz"
#  session["qux"] # => "Baz"
class CGI #:nodoc:
  class Session #:nodoc:
    def [](key)
      @data ||= @dbman.restore
      @data[key.to_s]
    end
 
    def []=(key, val)
      @write_lock ||= true
      @data ||= @dbman.restore
      @data[key.to_s] = val
    end
  end
end
 
# End of Rails 2.1.2 and 2.3.x

Now it worked! I am able to share sessions between Rails 2.1, 2.3.x and Rails 3.0 application.

To wrap things up:

# Rails 2.1.2
# config/environment.rb
...
Rails::Initializer.run do |config|
  config.action_controller.session = {
    :session_key    => '_sso_session',
    :secret         => 'a really long hex string'
  }
  config.action_controller.session_store = :cookie_store
end
 
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS[:session_domain] = '.rails.local'
 
# config/initializers/load_patches.rb
Dir[RAILS_ROOT + "/lib/patches/**/*.rb"].each { |file| require file }
 
# lib/patches/cgi/session.rb
require 'cgi/session'
 
class CGI #:nodoc:
  class Session #:nodoc:
    def [](key)
      @data ||= @dbman.restore
      @data[key.to_s]
    end
 
    def []=(key, val)
      @write_lock ||= true
      @data ||= @dbman.restore
      @data[key.to_s] = val
    end
  end
end
# End of Rails 2.1.2
 
# Rails 2.3.8 (and probably 2.3.x)
# config/initializers/session_store.rb
ActionController::Base.session = {
  :domain => '.rails.local',
  :key => '_sso_session',
  :secret => 'the same really long hex string'
}
 
# config/initializers/load_patches.rb
Dir[RAILS_ROOT + "/lib/patches/**/*.rb"].each { |file| require file }
 
# lib/patches/cgi/session.rb
require 'cgi/session'
 
class CGI #:nodoc:
  class Session #:nodoc:
    def [](key)
      @data ||= @dbman.restore
      @data[key.to_s]
    end
 
    def []=(key, val)
      @write_lock ||= true
      @data ||= @dbman.restore
      @data[key.to_s] = val
    end
  end
end
# End of Rails 2.3.8
 
# Rails 3.0.1
# config/initializers/session_store.rb
[AppName]::Application.config.session_store :cookie_store, {
 :key => '_sso_session',
 :domain => '.rails.local'
}
 
module ActionController
  module Flash
    class FlashHash < Hash
      def method_missing(m, *a, &b); end
    end
  end
end
 
# config/initializers/secret_token.rb
[AppName]::Application.config.secret_token = 'the same really long hex string'
 
# app/controllers/application_controller.rb
  def require_user
    session.send(:load_for_write!)
  ...
# End of Rails 3.0.1

Next job is to upgrade the legacy code to Rails 3…

Code found in features/support/env.rb is run when Cucumber begins and exits so this seemed the right place to start Solr:

Sunspot::Rails::Server.new.start
 
at_exit do
  Sunspot::Rails::Server.new.stop
end

Also, make sure you’ve added a cucumber environment to the config/sunspot.yml file; we copied the test-environment for that:

test: &TEST
  solr:
    hostname: localhost
    port: 8981
    log_level: WARNING
 
cucumber:
  <<: *TEST

Running cucumber will let all scenarios fail unfortunately and we got a ‘Connection refused – connect(2) (RSolr::RequestError)‘ in our console.

The reason for this is simple (after I stepped into the sunspot_rails gem to be honest): the Sunspot::Rails::Server.new.start method will eventually launch a Java Servlet Container (Jetty) with the Solr WAR and uses the port defined in your sunspot.yml.
Now, starting up a server could take some time, so if cucumber’s features are run before the Solr server is up and running, the ‘Connection refused’ sounds trivial then.
First I added a sleep after starting up the server:

Sunspot::Rails::Server.new.start
sleep(5)

and this will work for most cases, but I thought it would be better to let cucumber wait just long enough until the server is up and running. When the server is up, you can open up your browser and enter http://localhost:8981/solr to administering Solr. This we can use to find out if we’ve waited long enough and start our features. I’ve put this into a seperate class named CukeSunspot and created this file in the features/support directory:

require "net/http"
 
class CukeSunspot
 
  def initialize
    @server = Sunspot::Rails::Server.new
  end
 
  def start
    @started = Time.now
    @server.start
    up
  end
 
  private
  def port
    @server.port
  end
 
  def uri
    "http://0.0.0.0:#{port}/solr/"
  end
 
  def up
    while starting
      puts "Sunspot server is starting..."
    end
    puts "Sunspot server took #{'%.2f' % (Time.now - @started)} sec. to get up and running. Let's cuke!"
  end
 
  def starting
    begin
      sleep(1)
      request = Net::HTTP.get_response(URI.parse(uri))
      false
    rescue Errno::ECONNREFUSED
      true
    end
  end
 
end

Now we can the alternative start method and remove the explicit sleep statement in our global before hook. features/support/env.rb:

CukeSunspot.new.start
 
at_exit do
  Sunspot::Rails::Server.new.stop
end

And voila, if you run cucumber, you scenario’s should run successfully. On my machine:

Sunspot server is starting...
Sunspot server is starting...
Sunspot server took 3.74 sec. to get up and running. Let's cuke!

Note: the following examples have been tested with DataMapper version 0.10.2.

One of the questions I had was how to perform multiple queries within a single (database) transaction, so that I can ‘stage’ a number of database queries and commit (or rollback) them all in one go. Fortunately, after some investigation of the DataMapper source code, it turns out to be an extremely simple task:

User.transaction do
  User.first.update(:name => "John Smith")
  Address.first.update(:street => "") # Invalid: street must not be blank
end

With this code neither the address nor the user will be updated in the database if one of the updates fails. The syntax is actually the same as for the ActiveRecord ORM. However, triggering a rollback is done differently, as can be seen in the following example.

User.transaction do |t|
  User.first.update(:name => "John Smith")
  Address.first.update(:street => "Oak St. 400")
  t.rollback # Transaction will be rolled back even when updates are OK.
end

That’s it for now. I’m sure there are some additional features that I haven’t mentioned here, but this is all I had to know at this point.

Let’s start by installing Ruby and all tools:

# apt-get install build-essential
# apt-get install ruby irb ri rdoc libopenssl-ruby ruby1.8-dev
# ruby -v
# cd /usr/local/src
# wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz # replace with latest version of rubygems
# tar xfvz rubygems-1.3.5.tgz
# cd rubygems-1.3.5
# ruby setup.rb
# ln -s /usr/bin/gem1.8 /usr/bin/gem
# gem -v
# gem install gemcutter
# gem tumble
# apt-get install mysql-server # this will ask for a password during installation
# apt-get install libmysqlclient15-dev
# gem install mysql
# gem install rails
# apt-get install git-core
# apt-get install apache2
# gem install passenger
# passenger-install-apache2-module

Copy the following lines from the output and paste them at the end of the file /etc/apache2/apache2.conf. They should look something like this:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.7/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.7
PassengerRuby /usr/bin/ruby1.8

Finally let’s restart apache2:

/etc/init.d/apache2 restart

Phew! That's it... We now have all the software we need on the server that's required to deploy your Ruby on Rails app on Debian Linux (Lenny)!

In a future article I'll cover the basics of deployment using Capistrano.

doc = Hpricot(open("https://www.cert.org/blogs/vuls/rss.xml")) # => /usr/lib/ruby/1.8/net/http.rb:590:in `connect': certificate verify failed (OpenSSL::SSL::SSLError)

or

warning: peer certificate won't be verified in this SSL session

The solution is to make sure ruby has access to the right set of root certificates.

The easiest way to get hold of those root certificates is by downloading this file cacert.pem (details) (updated weekly by the developers of CURL, based on the Mozilla browser). Download this file and store it somewhere in your app.

If you’re really keen on security, don’t trust the guys from CURL and download the different root certificates from their providers manually. However, in most cases, the file from CURL will suffice.

Then, in your ruby code, setup the connection like this and you’ll have a validated SSL connection:

#! /usr/bin/env ruby
require 'net/https'
require 'uri'
 
uri = URI.parse(ARGV[0] || 'https://localhost/')
http = Net::HTTP.new(uri.host, uri.port)
if uri.scheme == "https"  # enable SSL/TLS
  http.use_ssl = true
  # Only needed for ruby 1.8.6
  # http.enable_post_connection_check = true
  http.verify_mode = OpenSSL::SSL::VERIFY_PEER
  http.ca_file = File.join(File.dirname(__FILE__), "cacert.pem")
end
http.start {
  http.request_get(uri.path) {|res|
    print res.body
  }
}

For the first time in its history Ruby en Rails was a multiple day event. The first day, October 31, was packed with interesting presentations on various Ruby and Rails related topics, by great speakers including renowned community idols like Yehuda Katz, Jeremy Kemper, Jonathan Weiss and many more. The second day (the ‘geek-day’) focused on more practical sessions and lightning talks. On this day another event was held: The RubyEnRails Rumble (RERR), a competition where teams of two had to complete an assignment within a certain time.

Since we from Kabisa consider ourselves to be Ruby programmers we wanted to take the challenge and see how we would do in this competition. Michel de Graaf and Ludo van den Boom were given the honor to rumble for Kabisa. This post will describe how we prepared for the RubyEnRails Rumble and how we have experienced it.

Rumble Preparations

After deciding that we would partake in the Rumble we knew that we would have to prepare ourselves as good as possible so that we could utilize our time at the Rumble as efficiently as possible. Neither of us had ever participated in an event like this, so we started of with a session in which we tried to decide what we could do to help us prepare for the Rumble. Together with our Kabisa colleagues we made a list of items and topics that could prove to be handy during the Rumble.

The hard part was that we had no experience and that we did not know what the assignment would be, so we dove into a broad range of subjects. With help from our colleagues we were able to refresh our knowledge of Ruby and Rails related technologies and built up a collection of snippets/links to quickly be able to perform standard tasks like retrieving tweets from Twitter and adding jQuery UI sugar to an application. In the end we prepared a Rails application template so that we would be able to quickly set-up a Rails skeleton application including basic functionality like authentication and authorization. Besides this template we also prepared a user interface template builder that could help us to quickly apply a ‘theme/skin’ to an application (interfaceLift).

For scaffolding we used dry_scaffold: This gem contains a rails generator that will replace the default rails scaffolding with more up to date DRY controllers and views. Controllers are implemented using inherited_resources. And the views are generated in haml that make use of Formtastic Forms to generate nice looking forms. The fork we where using also generated a search form that was implemented using searchlogic.

Another challenge was that we had not worked together before. So, apart from the technical toolkit that we set-up, we also had to find a way to get more acquainted with each others good and bad sides. We decided that the best way to do this would be to simulate a Rumble, and that’s what we did. Our colleague Ralph came up with an assignment that we worked on for about six hours. In these six hours we managed to crank out some decent results and learned how we could best divide the development tasks to our individual skill sets. This simulation prepared us for lots of things but it did not really simulate the most vital element of a competition: stress.

Rumble Ramblings

Some hints on what the assignment would be were dropped during the presentations on the first day. Still, we could only guess what exactly to expect. At the start of the Rumble the assignment was introduced and explained, the assignment was titled ‘Community Love’. It turned out that we had to create a system that would keep users of Ruby libraries up-to-date with updates about these libraries. The assignment was kept vague on purpose so that the teams had the ability to put their creative minds to work with finding a solution to the problems laid out in the assignment description.

So, now we had a little under eight hours left to design and build something that would convince the jury of our programming skills. After a short stand-up meeting we came up with a rough idea for what we would create.

The Plan…

As a Ruby/Rails developer you will probably make use of lots of gems in your application. You can specify these gem dependencies in your Rails configuration. Or make use of the awesome gem bundler. This will help you manage gem dependencies but they will not inform you when there are updates to the gems you are using. We figured that, as a developer who uses gems in a Ruby project you should be able to send a list of gem dependencies you use in a specific application to a service that will inform you when there are updates to the gems that you are using. An update could, for example, be a new version, a reported security vulnerability or a blog post. Since we had only one day to build something, we decided to focus on Rubygems exclusively. Mostly because there are already good centralized repositories where we would be able to easily find information about gems (gemcutter).

… And the Solution …

Our solution consists of three parts: (1) a gem that you use locally to update the list of gems you use in particular applications, (2) an online service (Rails application) where you can see the gems you use and (3) notification channels (i.e. email and twitter) through which news about gems is pushed to you. We named our solution ‘gemstreamer’, for it would stream information about gems to you as a user of these gems. For those of you who are interested to see what we actually made: you can see the ‘online service’ Rails application that is used as the central ‘information hub’ where information is gathered and distributed at http://github.com/ludo/rerr2009. For the gem that you would use locally to push the gems you use to the central hub see http://github.com/michel/gemstreamer. We deliberately kept the code as simple as possible and leveraged as many existing tools as possible to be able to quickly get things done. The end result is pretty simple, but the ideas behind it might actually be useful when extended and polished for real-life usage. This was also one of the comments from the jury, where they believed that something like this could make a great extension to http://gemcutter.org.

… At a Price

Did we mention the stress? Apparently we were both not very satisfied with how we made progress. There was so much that we wanted to do, and so little time to do it all. This is probably the biggest flaw in how we approached the Rumble. Before the Rumble we had already discussed that it would be best to make something small that works instead of something big that does not work. This reasoning sounded really good before the Rumble and after the Rumble, but we actually forgot it during the Rumble… Still, we managed to get our main ideas implemented which we were able to present at the end of the day.

Rumble Opponents

With five pretty strong teams the competition was fierce. It was interesting to see that every team approached the assignment from a different angle. Where our end result can be seen as an interesting prototype, others had created something that could be of use to developers right away. Here is a short summary of what the other teams created:

• The Fingertips team created Apprise for which they patched Bundler. This patch to was applied to Bundler By Yehuda the very next day.
• Iain Hecker and Marcel de Graaf built an extension to Webistrano that shows outdated gems, named ‘deproll‘.
• The i76 team (Tom-Eric Gerritsen and Rik Tonnard) built a Rails plugin that you can hook-up in your application so that you can see the dependencies that your app uses through a web interface (http://github.com/i76/rrrer2009).
• Leon Berenschot and Klaas-Jan Wierenga gave a cool presentation and won the Twitter vote (http://github.com/LeipeLeon/Dev-Enter).

Rumble Results

Victory! Completely unexpected we were awarded the first prize: two tickets to RailsConf 2010 in Baltimore, MD. The winner was selected by a jury and through public voting via Twitter. In the Twitter vote we ended as third, which we thought was already a great achievement. But the professional jury had unanimously picked us! These two votes combined made us the overall winners of the Ruby en Rails Rumble 2009: awesome!

In hindsight we can conclude that our plan was a little too ambitious as it turned out that eight hours is really not that much. Nonetheless, the rumble turned out to be a great experience that was really fun doing. It was a crazy day with a lot of stress, but it was also an interesting experiment to see how we would do against some other very good teams. The end result turned out to be even better than what we’ve hoped for. We want to thank the jury for choosing us as well as the people who voted for us on Twitter. Last but not least many thanks to the people who made Ruby en Rails possible this year, we had a great time!