The Rails community is still catching up to the recently released Rails 3. RSpec, which the tutorial recommends for testing, is no exception. RSpec 2 is the latest version, and the first to bring compatibility with Rails 3. However, I’m finding that there are still a few kinks that need to be worked out.

Most of the issues I’ve encountered have been easy to solve. However, I encountered a particularly frustrating problem dealing with the interrelation between rspec-rails and webrat, which is described in this issue. It is a known problem that has been variously fixed and re-broken by commits to the two libraries in question.

When executing an integration test using the following code:

describe "LayoutLinks" do
  describe "GET /" do
    it "should have a Home page at '/'" do
      get '/'
      response.should have_selector('title', :content => "Home")
    end
  end
end


A failure is reported:

Failures:
  1) LayoutLinks GET / should have a Home page at '/'
     Failure/Error: response.should have_selector('title', :content => "Home")
     stack level too deep
     # ./spec/requests/layout_links_spec.rb:8


I haven’t traced down the exact issue, but it appears to be caused by webrat 0.7.2, and its interaction with both rspec-rails 2.0.1 and 2.1.0. I attempted upgrading to webrat 0.7.2.beta.2, but that did not resolve the issue. However, downgrading to webrat 0.7.1 did.

Simply specify the following in your Gemfile:

group :test do
  gem "webrat", "0.7.1"
end


Execute bundle install to use webrat 0.7.1 and the error will be resolved.

Ruby on Rails dramatically altered the way people build web applications. With the 1.2 release, it continues to influence thought patterns by bringing REST to the forefront. REST provides a set of principles for the design of network-based software. By presenting these patterns to a mainstream audience, Rails is having a profound impact on the future of software development.

The release also has numerous other improvements, including Unicode support, a new URL routing implementation, and better module loading.

My Objective-C leanings lead me to use Ruby as a scripting language. Ruby has been propelled into the spotlight recently by Ruby on Rails, an incredible framework for developing web applications.

Objective-C and Ruby are both descendants of Smalltalk. All three languages are object-oriented, and have the notion of message passing as a central construct. Message passing is not found in more popular languages like C++ and Java, yet understanding it can give any developer an invaluable new perspective.

In an attempt to further my understanding of these concepts, I’ve recently been studying Smalltalk. While having been around for more than 30 years, the concepts behind the language are still considered state-of-the-art and its influence is broad. That influence extends all the way to the web, as I discovered in a recent entry by James Robertson.

Found in the comments is a link to an editorial by Dan Connolly, dated February 13, 1997. From the article:

HTTP was design as a distributed realization of the Objective C (originally Smalltalk) message passing infrastructure: the first few bytes of every HTTP message are a method name: GET or POST. Uniform Resource Locator is just the result of squeezing the term object reference through the IETF standardization process.

Recent projects have caused me to view the web as just such a distributed object system. However, I was not aware of the historical link to Objective-C and Smalltalk. Seen in that light, though, the message passing approach is remarkably consistent.

David Heinemeier Hansson, the creator of Ruby on Rails, is a true innovator in the web application frontier. His addition of Active Resource to edge Rails is the natural next step in this line of thinking. In his keynote address at RailsConf 2006, he gives a compelling presentation about the benefits of discovering a world of resources.

Message passing languages are efficient and productive for application development. Unfortunately, they have a minority stake of developer mindshare. Ruby and Rails are currently improving this situation. It may be wishful thinking, but I’d like to see these trends renew interest in Objective-C and Smalltalk as well.