Na het invullen van de enquete over elektrisch rijden en energieverbruik was het dan zover; Frank Nienhaus van Stichting Limburg Elektrisch deelde de voertuigen uit onder het personeel.

Natuurlijk was het een dolle boel. We probeerden direct alles uit. Heel benieuwd was ik naar de Citroen C-zero. Hoe rijdt zo’n elektrische auto nou? Het leek net of ik over de weg zweefde, zo weinig geluid kwam er uit die auto.

Harm was verknocht aan de stoere PG Bike die wel 40 kilometer per uur ging. Maar zelfs de ‘gewone’ e-bike haalde een snelheid van 30 kilometer per uur gemakkelijk. Trots fietse ik alle top wielrenners voorbij zonder een druppel zweet op mijn voorhoofd.

Helaas zijn de prijzen van elektrische voertuigen nog erg hoog en kan de elektrische auto maar 100 kilometer rijden voordat hij weer aan de laadpaal moet. Toch vond ik het een mooie ervaring die veel enthousiaste reacties heeft opgeleverd. Dus bij deze: Kabisa en Stichting Limburg Elektrisch bedankt!

Groetjes,

Rosian Custers

De elektrische voertuigen zijn een stuk minder afhankelijk van fossiele brandstoffen en daarom een goede keuze als vervoersmiddel. Het zou goed zijn als meer bedrijven, net als Kabisa, het inzetten van elektrische voertuigen als serieus alternatief gaan zien. Dat zou de wereld een stuk schoner, gezonder en stiller maken. Medewerkers die na de proefperiode besluiten een elektrisch voertuig te kopen krijgen een aantrekkelijke korting. Daarnaast krijgen ze ook nog een jaar lang een bijdrage per kilometer.

Stichting Limburg Elektrisch wil met deze projecten het  gebruik van elektrische vervoersmiddelen promoten omdat dit beter is voor de gezondheid van de medewerkers en voor het milieu. Ook willen ze door middel van ervaringen meer kennis vergaren over de wensen en behoeften van de medewerkers.

Medewerker Joost Saanen van Kabisa probeert direct de Twike uit, een elektrisch voertuig op drie wielen. “Het voertuig ziet er leuk uit en het is ook nog eens milieubewust”, zegt Joost. Hij moet per dag 30 kilometer reizen voor naar zijn werk te komen. Dus dat tikt lekker aan bij de huidige brandstofprijzen. Of hij er ook gezonder van wordt nog blijken. “Ik zal eens wat vaker op de weegschaal gaan staan in de komende weken” vertelt hij lachend.

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.

After opening an Xcode 3 project in Xcode 4, we received the message:

“No architectures to compile for (ARCHS=i386, VALID_ARCHS=armv6 armv7).”

Since all the architecture settings are configurable from the Build settings that was the first place to look. Strange enough, there were the settings that claimed to let the project build for the “armv6 armv7″ architecture. So why didn’t this compile like it supposed to?

As it seems, Xcode 4 doesn’t always read these settings correct from the older project format. So here’s how we fixed this settings related issue:

• Remove both the armv6 and armv7 items from the Valid Architectures build setting (for both the project AND the target)
• Create a new value and set it to: $(ARCHS_STANDARD_32_BIT)
• Clean the project builds and rebuild the project
• The project should build using the correct architecture setting

Hopefully, this info will save you some time when coding on ye olde Xcode 3 projects.

When hitting ‘Run’, all Xcode would do is show the message “Attaching to MyApp”. The simulator and my iPhone both didn’t do anything, the app didn’t even get installed on the devices.

The solution is quite simple. Xcode4 is a bit picky about the name of your project.

• Go to Project > Build Settings
• Search for “Product name”

Here you’ll find the names for the debug en release versions of your app. Now compare those the name of your project. Here’s what I found:

• Project name: myapp-iphone
• Product name: Multiple values
• Debug: MyApp-DEV
• Release: MyApp

The solution to the “Attaching to MyApp” problem is very easy. Simple update the “Product name” value to $(TARGET_NAME). After that, clean your app by pressing ⇧⌘K.

Now, when you press ‘Run’, your app should start as you’d expect.

The Problem

Updating data can take a very long time, especially if done incorrectly. Consider the following example:

Photo.all.each do |photo|
  photo.update_attribute :order, 999 if photo.order.nil?
end

This might look nice and all and work okay on your development machine. However, if you run this on your production database with 78k photos…

You guessed it, it takes for ever. What happens is that Rails will fetch all photos from the database and instantiate 78k Photo objects. Then for each object it will issue an update-query if necessary.

Running this took at least ten minutes or more. Bad!

The Alternative

There is, luckily, an alternative that is quite a bit faster.

Photo.update_all("`order` = 999", "`order` IS NULL")

This alternative issues exactly one update-query to the database and achieves the same end result as the previous code example. Also, this query took about 20 seconds to run!

You may want to look into http://apidock.com/rails/ActiveRecord/Base/update_all/class for more information about the update_all method.

Conclusion

Thinking about the code you put in your migrations, especially when manipulating data, is very important and will pay you back in less database downtime during deployments.

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…

RGB is used for screens (e.g. television, monitors, phones). Screens work by combining different light colors (red, green or blue) into one color we can actually see.

CMYK is used in print often. Instead of sending out light, paper must reflect light to give it color. If you check your own printer you’ll see there are three colors: cyan, magenta and yellow. Again, these three colors can be combined to *absorb* colors, and thus reflect the color you want.

The problem is that not all web browsers are capable of handling JPEGs that use the CMYK colorspace. Internet Explorer is the most notorious one. Internet Explorer users will see an ‘image not found’-error – or red cross – instead.

If you’re using thoughtbot’s Paperclip, the solution is easy.
By adding some custom ImageMagick `convert` options you can make sure that all generated thumbnails are in the RGB colorspace.

has_attached_file :avatar

would become:

has_attached_file :avatar 
   :convert_options => { :all => '-strip -colorspace RGB'}

Easy right?

If you have a lot of CMYK images already, you don’t have to delete them, you can easily reprocess them when you made the above change:

User.find_each { |user| user.avatar.reprocess! }

More and more useful applications, libraries and plugins are appearing that take away some of the pain that is sometimes involved in making software tests useful for entire teams. Examples of excellent tools that we have at our disposal right now are Hudson for continuous integration, Cucumber for integration tests and Selenium for automated testing of web applications in an actual browser. But making all these play together nicely involves more and more setting up of build servers and configuration.

Our goal is to document the steps required to overcome one of the hurdles that we kept running into, namely running our full Cucumber test suite including all Selenium scenarios on our Hudson integration server.

Ingredients

We’re going to use the following ingredients in this post:

• 1 Debian 5.0.4 ‘Lenny’ installation
• 1 installation of Xvfb
• 1 web browser (in our case iceweasel, Firefox rebranded by Debian)
• 1 Ruby on Rails 2.3.7 application
• 1 Capybara 0.3.8 gem
• As many Cucumbers (0.7.3) as necessary

We won’t go into the details of creating a Rails application, installing the gems and writing the Cucumber scenarios here. Their manuals are perfect guides for this.

Installing required packages

We start with installing a couple of packages that allow us to run headless tests in a web browser.

Virtual framebuffer with Xvfb

“In the X Window System, Xvfb or X virtual framebuffer is an X11 server that performs all graphical operations in memory, not showing any screen output.” Source: http://en.wikipedia.org/wiki/Xvfb

$ apt-get install xvfb

Web browser

After installing Xvfb we can go ahead and install a web browser.

$ apt-get install iceweasel

Before we continue we want to configure our browser profile so that it doesn’t whine about tabs being closed or not resuming correctly after it has crashed. If we don’t do this, our test suite might crash or run forever.

$ cd ~/.mozilla/firefox/xxxxxxxx.default/
$ vim user.js

Now put the following two lines in the user.js file:

user_pref("browser.sessionstore.enabled", false);
user_pref("browser.sessionstore.resume_from_crash", false);

Test Display

Before we start running our tests we will ant to verify that all packages were installed successfully. To do so start a virtual framebuffer (an Xvfb session) on display 99 with screen 0:

$ Xvfb :99 -ac -screen 0 1024x768x16

In a different terminal window do:

$ DISPLAY=:99.0 iceweasel http://example.org

This will start our web browser in the virtual framebuffer and open the example.com homepage in this browser. Next up is makinga ‘screenshot’ so that we can see what is going on inside our virtual framebuffer.

$ xwd -root -display :99.0 -out xwdout

And subsequently view the screenshot using:

$ xwud -in xwdout

Do you see the example.org homepage? Then Xvfb and iceweasel were installed successfully and we are now ready to do some testing.

Iceweasel in Xvfb

Running cucumbers

Before we integrate this setup into our continuous integration environment we do a test run to see if the cucumbers work with our new configuration. We can do this using the following command, keep in mind that we have to explicitly tell the cucumbers to use our virtual framebuffer display:

$ DISPLAY=:99.0 rake cucumber

If all goes well then we will see that all scenarios passed. If not all scenarios pass first check if they do run on in a non-headless situation.

Configuring Hudson

Now we have come to the point where we can tie all strings together. We need to add a new build step to the job that needs to run headless cucumbers. But, before adding this build step, we will create a start/stop script for our virtual framebuffer. This script can be used to start a buffer before running the scenarios, and stop the buffer after the scenarios completed. You can save this script to /etc/init.d. Make sure that the permissions are set so that the user that runs Hudson can execute it.

XVFB=/usr/bin/Xvfb
XVFBARGS="$DISPLAY -ac -screen 0 1024x768x16"
PIDFILE=/var/hudson/xvfb_${DISPLAY:1}.pid
case "$1" in
  start)
    echo -n "Starting virtual X frame buffer: Xvfb"
    /sbin/start-stop-daemon --start --quiet --pidfile $PIDFILE --make-pidfile --background --exec $XVFB -- $XVFBARGS
    echo "."
    ;;
  stop)
    echo -n "Stopping virtual X frame buffer: Xvfb"
    /sbin/start-stop-daemon --stop --quiet --pidfile $PIDFILE
    echo "."
    ;;
  restart)
    $0 stop
    $0 start
    ;;
  *)
  echo "Usage: /etc/init.d/xvfb {start|stop|restart}"
  exit 1
esac
exit 0

Source: http://marc.info/?l=tomcat-user&m=102335321103262&w=2

Final step is to add an ‘Execute shell’ build script to our Hudson job. You can use the following set of commands to run your cucumbers.

#!/bin/bash
export DISPLAY=:99
/etc/init.d/xvfb start
rake cucumber
RESULT=$?
/etc/init.d/xvfb stop
exit $RESULT

After adding this build step we save our job and let Hudson build it. If all goes well the cucumber scenarios should now be running as part of our continuous integration process. You can check the ‘Console output’ page of a Build in Hudson for hints when it didn’t run successfully.

Conclusion

If you have followed along with this post then you should have a working, headless setup by now. The advantage of this setup is that it is pretty light-weight and easy to setup. But this setup is not suited for you if you need to test across multiple browsers on different browsers. For such a setup you will want to have a look at virtual machines and Hudson slave agents.