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!