To use thor with your merb 1.0.15 app, you need to install thor -v0.9.9 and then follow the instructions on this page: http://wiki.merbivore.com/deployment/bundling

So, at times a cleanup is in order. Here is what i’ve done to cleanup my merb setup:

$ sudo gem update --system
$ gem search --no-version merb | grep merb | xargs sudo gem uninstall -a # NOTE: removes all old version of merb
$ gem search --no-version dm | grep dm | xargs sudo gem uninstall -a # NOTE: removes all old version of data_mapper
$ gem search --no-version data_objects | grep data_objects | xargs sudo gem uninstall -a # NOTE: removes all old version of data_objects
$ sudo gem sources -c
$ sudo rm PATH_TO_GEMS/cache/merb* # PATH_TO_GEMS is the path to your rubygems install.  Mine is /usr/lib/ruby/gems/1.8
$ sudo rm PATH_TO_GEMS/cache/dm*
$ sudo gem install -r merb

This was taken from the meb installation instructions at: http://wiki.merbivore.com/howto/installation/gems

For this to work, you need to run a quick one-liner on the command line:

sudo ln -s /Applications/TextMate.app/Contents/Resources/mate /usr/local/bin/mate

Once done, you can call mate and pass it any object you want to open, such as:

$ mate my_rails_app

and it opens the entire directory as if it were a TextMate project.

Lots more detail available here: http://manual.macromates.com/en/using_textmate_from_terminal.html

I am also using Cucumber, Webrat and Selenium for my integration tests.

I needed my integration tests to test the Ajax responses and the tests weren’t receiving a response from the Ajax requests.

The Problem

I found that by simply completing the web form, the ajax request was not being fired and my test was therefore failing when i checked for the existance of the Ajax response. It soon became clear that selenium doesn’t really interact with the form in the sense of selecting fields and entering values; It simply enters values. As such, the Ajax request was not firing and my test was failing.

The Solution

The solution is Selenium’s fireEvent method, which you can pass a form field id and the blur method:

selenium_session.fireEvent(”field”, “blur”);

In Webrat, this is ever simpler:

fire_event(”field”,”blur”)

On using this in a Cucumber step, the ajax is fired as the blur command tells the browser to take focus off the field.

Lovely!

My upgrade to Snow Leopard killed my Merb, Cucumber and Webrat setup so i had to start afresh. That was the bad. The good is that some manual hacks that were required in Leopard are no longer necessary, meaning I can rely on direct gem installations.

Here’s what i did:

1. Install Ruby and Gems
   Follow instructions on http://hivelogic.com/articles/compiling-ruby-rubygems-and-rails-on-snow-leopard/
2. Install merb, rspec, cucumber, merb_cucumber and mongrel and dependencies
   sudo gem install merb rspec cucumber roman-merb_cucumber mongrel term-ansicolor treetop diff-lcs nokogiri do_sqlite3
3. Install webrat
   sudo gem install hoe hpricot webrat
4. Fix Firefox bug with Snow Leopard
   For some reason the libsqlite3.dylib  library in FireFox 3.5.2 is out of date and breaks cucumber under Snow Leopard. Thankfully, it’s a simple fix:
   mv /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib.orig
   cp /usr/lib/libsqlite3.dylib /Applications/Firefox.app/Contents/MacOS/libsqlite3.dylib
5. Install Selenium
   sudo gem install Selenium
   sudo gem install selenium-client
6. Install the textmate cucumber bundle
   http://github.com/bmabey/cucumber-tmbundle/tree/master

Deprecated Instructions on Snow Leopard that were required on Leopard

The following ugly hacks were required on Leopard with it’s default Ruby installation. These are no longer required (at least on my machine) on Snow Leopard:

Manual hack of Selenium

http://wiki.github.com/aslakhellesoy/cucumber/setting-up-selenium

As the instructions recommended replacing the Selemium RC jar file () in the installed gem with one from the Selenium website, i had to find out where the gem had installed. Thankfully, gem -h pointed me toward gem help commands and from there i ran gem environment – This told me where gems are installed locally and i found that Selemium RC had been installed into /Library/Ruby/Gems/1.8/gems/Selenium-1.1.14/ I replaced as advised and then ran selenium from within the app root and all worked fine, using the replacement. I then downloaded and ran the test selenium code from http://github.com/aslakhellesoy/cucumber/tree/master/examples/selenium running selenium in a different console and then running cucumber examples/selenium/features/ . It worked a treat and booted up selenium as required. Great!

Manual hack installation of webrat

Download http://github.com/gwynm/webrat/tree/master tar file. Git clone doesn’t work

sudo gem install hoe hpricot
cd downloaded and untarred file
rake gem
sudo gem install pkg/webrat-0.2.1.gem

Balsamiq is an excellent tool for rapidly creating purposefully low-fi wireframe mockups

Napkee enables you to import Balsamiq mockups and turn them into HTML prototypes! Lovely!

Axure is excellent for rapidly creating interactive prototypes.

Liferay Portal is a pretty awesome portlet container that, with a bit of UX (HTML, CSS and JSP) hacking, enables you to rapidly produce fully functional portals. It comes with a vast array of portlets out of the box, saving you a whole load of time.

JQueryUI is a lovely toolkit for quickly developing interactive prototypes. I’m not completely convinced by it as a production tool (heavy JS? but i could be wrong), but excellent for prototyping

An important point to consider.

Part 1: Collectively clarify what happens on projects now (on projects that do not use stories)

It was a highly interactive session and i first asked attendees to collectively draw on a whiteboard the project process as they saw it, with all of the project’s actors, products and interactions.

What was drawn resembled a kind of mashup of a UML activity diagram with swim lanes & a gantt chart. It showed what the individual actors in the process did and when, and who fed into who in the process.

Part 2: Clarify what documents are written and the associated risks and costs

When the whiteboard was complete, I asked the attendees to consider a number of things:

1. At what points during the process are documents produced and by who?
2. Of those documents produced, which are directly focused on the business and user requirements?
3. Of the many producers of those documents, which of these producers had their focus on the business and user requirements?
4. Of the many documents produced, which were open to interpretation and translation?
5. What are the perceived risks of having so many documents and periods of documentation translation?

When this work was complete, a few points became clear to the group:

1. The project team, as defined on the whiteboard, was greatly separated into areas of expertise and each was concerned about their area of expertise
2. Interactions between actors were mostly through written documents
3. Few actors following this project process retained a direct focus on the business and end user requirements
4. A lot of documentation was being written and much of it was being duplicated, at times to protect actors within the process
5. Vast amounts of document interpretation and translation was going on to produce each document

Part 3: Consider stories

After this part of the session was complete, i gave some examples of the wonderfully simple story DSL and then suggested that many of these documents could be replaced by stories and scenarios:

1. I explained that stories can be used to clarify both high-level requirements and detailed solution definitions. I described how stories can be expanded through the use of scenarios.
2. I described how everyone on the project, including the client, can understand the wonderfully simple DSL and contribute to the bank of stories.
3. I then came in with the ace Stories can be used to drive automated browser tests! Man, they fell off their seats at the point!

It was an awesome session. A lot was discussed and understood.

My intention is to have the Rails app on a separate server from the Hudson server and have the Rails app return Hudson-friendly XML from RSpec and Cucumber tests. When i get this to work, it’ll enable me to roll this out at work, with a central Hudson server (perhaps) that interacts with multiple app servers of various technologies and, along with the wonders of Sonar, gives a view into code test coverage, pass rate and complexity. I feel that i might struggle convincing Sonar to play with Ruby, but we’ll see.

Why Hudson?

To be completely honest, at work, i didn’t make that decision and am yet to chase down exactly why it was chosen over CruiseControl, but I completely trust those that made the decision on their project. I’m a big believer in standardising and am as such following suit and trying out Hudson.

I started the quest ages ago and have progressed it, but more in practice than in reading. Now’s the time for the reading to pick up again…