Category: Ruby

Categories
Enterprise Rails Ruby

Defending Ruby and Rails in the Enterprise

I consider myself fortunate that the previous two projects I worked on (the BT Web21C Portal and Mojo) were Rails-based (actually it wan’t just luck in the former case, as I had a part in selecting the framework). I love the expressiveness and flexibility of the Ruby language, the power and relative simplicity of the Rails framework, and the all-round awesomeness of tools like RSpec and Capistrano, and I don’t particularly relish the thought of going back to Java (although I’m told that Spring is much nicer than last time I used it).

At our recent release planning session, I was assigned to a new project, which involves (among other things) exposing a CLI-based configuration interface as a web service. In our initial discussions, the four of us more-or-less agreed on a few initial decisions:

  • The exposure should be REST. Fortunately the people developing the upstream system shared this opinion.
  • Rails is an ideal framework for RESTful web services.
  • Ruby seemed like a good fit for parsing the command responses too.
  • Asynchronous behaviour would be handled using queues (probably ActiveMQ).

Since we’d all been working on Rails projects when the new team was formed, we assumed that this wouldn’t be a particularly contentious route to go down, but unfortunately our director/architect/boss didn’t see things quite the same way. He had two main objections:

  • Rails may make sense for GUI applications, but why on earth would you use it for a service? All our other [SOAP] services are written in Java.
  • At some point the application will need to go into support, and we don’t have support/operations people with Ruby or Rails experience

I think the first point’s easier to address, as I’d argue it’s based on a misunderstanding: Rails isn’t really anything to do with GUIs, but is a framework for creating MVC web applications. Virtually all the heavy lifting Rails takes care of is in the controller and model areas, with the creation of the actual visible GUI being left to the developer to take care of with the usual mix of HTML, CSS and Javascript. The only thing Rails adds is the ability to insert dynamic content using ERB – similar to the role of JSP in Java EE.

A RESTful web service is, to all intents and purposes, the same as a normal web application, but (potentially) without the HTML. All the power that Rails brings to web application development is also harnessed when creating RESTful services.

The second point represents a much more fundamental strategy choice. If the company makes the decision that all development is going to use Java (the language as well as the platform), then we inevitably lose the flexibility to choose what may appear (in a local context) to be the right tool for the job. Personally I think that would be a shortsighted and ill-informed decision: if that were the strategy, we’d presumably all still be developing in C, or COBOL, or Assembler. Or we’d have gone bust. But then I’m not an architect (incidentally, according to Peter Gillard-Moss, that’s reason number 10 why I don’t deserve to be fired), so what do I know?

However, if Ruby is considered an acceptable technology choice for “normal” web applications, we’ll still need people with appropriate skills to support those, so the problem doesn’t go away. I suspect even for a Java specialist, supporting a well-written Rails application with good test coverage is probably easier than supporting some of the spaghetti-coded Java I’ve seen.

Anyway, our arguments obviously weren’t totally unconvincing, because we were given a couple of weeks to show what we could produce before getting a final decision. That time runs out on Monday, so if I’m unnaturally grumpy after that it’ll be because we’ve been told to chuck all our work so far away and start from scratch in Java. Or possibly FORTRAN.

Update, 16 June Well we made our case, and we get to stick with Rails. Celebration all round!

Categories
Rails rspec Ruby

“You have to declare the controller name in controller specs”

For ages I’ve been getting an intermittent problem with RSpec, where occasionally I’d see the following error on a model spec:

You have to declare the controller name in controller specs. For example:
describe "The ExampleController" do
controller_name "example" #invokes the ExampleController
end

The problem seemed to depend on which order the specs were run in, and for rake it could be avoided by removing --loadby mtime --reverse from spec.opts. It was a real pain with autotest though, and today (my original plan of “wait for RSpec 1.1 and hope it goes away” having failed) I finally got round to looking into it properly.

It seemed that the error was being triggered by the rather unpleasant code I wrote a while ago to simplify testing of model validation. Digging into the RSpec source to see what was happening, I found that that error message only gets returned when (as you’d expect) you don’t declare the controller name in a controller spec (specifically in an instance of Spec::Rails::Example::ControllerExampleGroup). The code that decides what type of example group to create lives in Spec::DSL::BehaviourFactory, and according to its specs, there are two methods it uses to figure out what type of spec it’s looking at:

it "should return a ModelExampleGroup when given :type => :model" do
...
it "should return a ModelExampleGroup when given :spec_path => '/blah/spec/models/'" do
...
it "should return a ModelExampleGroup when given :spec_path => '\\blah\\spec\\models\\' (windows format)" do
...
it "should favor the :type over the :spec_path" do
...

I began to suspect that the problem was caused by the fact that my specify_attributes method wasn’t declared in a file in spec/models, so I thought I’d try specifying the type explicitly. So instead of this:

describe "#{label} with all attributes set" do

I changed it to this:

describe "#{label} with all attributes set", :type => 'model' do

Sure enough, it worked! Not sure whether anyone else is likely to see the same problem (unless they’re foolish enough to use my validation spec code), but hopefully if you do, a Google search will bring up this post and it might point you in the right direction.

Categories
General nonsense Rails

Rails Envy’s take on the werewolf question

This clip [MP3, 57s] from a Rails Envy podcast made me laugh. It’s referring to Charles Nutter’s recent musings on whether werewolf is killing the conference hackfest.

Incidentally, how often do you get the chance to Google for “nutter werewolf”?

[tags]rails envy, werewolf[/tags]

Categories
Rails

Weird Rails bug

I Spent some time yesterday tracking down a bizarre bug which was causing some of our Selenium tests to fail. Watching the browser running the tests, I could see that occasionally a page would fail to render, with an “invalid argument” error and a stack trace. The line in question was an <%= end_form_tag %> in a layout. The strange thing was, it didn’t display the same behaviour when I ran the single failing test on its own, or when I viewed the page myself.

Or at least, I thought it didn’t. Because it seemed intermittent, I tried reloading the page a few times, and sure enough, the error appeared. Once. Then the page reloaded successfully six times, before failing again. This was completely repeatable – six times OK; one stack trace. Regular as clockwork.

Completely stumped, I thought I might as well at least replace the deprecated <%= start_form_tag %> … <%= end_form_tag %> with <% form_tag do %> … <% end %>, and lo and behold, that fixed it.

Unfortunately, I have no idea why. An imaginary prize to whoever can explain it!

Categories
Java Ruby

String#casecmp

As far as I can tell, this is the correct way to do case-insensitive string comparison in Ruby:

if string1.casecmp(string2) == 0
  # strings match, ignoring case
end

That’s so ugly, it almost looks like Java. Actually, it’s worse than Java, which has String#equalsIgnoreCase.

Categories
Agile Ruby Software

Driving Selenium from the RSpec Story Runner (RBehave)

[Update] The story runner is now included in the 1.1 release of RSpec, so a lot of the hackery mentioned below is no longer required. See http://rspec.info/ for details.

Background

A while ago I cobbled together some code to drive Selenium from Exactor (which was the acceptance testing framework we were using at the time). That project was offshored shortly afterwards, and I’m pretty sure Selenium never actually got integrated into the build (sneaking a peek at the continuous integration server reveals that even the pre-Selenium acceptance test build hasn’t run successfully for months), but I was convinced of the value of Selenium for testing non-trivial web applications.

On my next project (the Web21C SDK portal) we used Selenium on Rails heavily for automated acceptance testing. This worked well, although the fact that the tests are deployed with the application limits what you can do – you can’t interrogate the database after a test, for example, or dynamically set up stubs for systems you interface with (unless you also deploy the stubs as part of the application, and drive them from the browser).

With Mojo there’s an additional complication: as well as being accessible through a browser, most functionality is also available as a RESTful API, using digest-based authentication. To keep our acceptance tests in one place, we wanted to be able to drive a browser using Selenium, alongside other tests which talked to the server directly. The obvious answer was to use Selenium Remote Control, and I also liked the look of RBehave, which has now been incorporated into RSpec (but not released yet).

The RSpec story runner

The story runner in the upcoming release of RSpec is an evolution of Dan North’s RBehave, which in turn is based on JBehave (from the same author). In the past couple of weeks, David Chelimsky has done some excellent work on extracting the text of stories from the code, leading to the plain text story runner.

Read on for the gory details of my solution to running Selenium tests from the story runner.

Continue reading “Driving Selenium from the RSpec Story Runner (RBehave)”
Categories
Apple Ruby

Ruby in Leopard: so close and yet…

I was quite excited to see the announcement of improved Ruby and Rails support in Leopard, and one of the first things I did after upgrading was to delete my MacPorts installations of Ruby and RubyGems, and try using the built-in ones instead.

For a while, all seemed well. The milk was cold, the food stayed fresh, my specs still passed, my Rails projects still worked, and even the light worked when you opened the door.

But then the trouble started.

Firstly I tried updating and installing gems while behind a firewall. The gem command completely ignored my http_proxy setting, and when I explicitly provided the proxy using -p, I got this error:

ERROR:  While executing gem ... (NoMethodError)
    undefined method `[]=' for #

I worked round this by downloading the gems manually and installing the local copies (despite this being a pain, especially when there are dependencies).

I then tried using gemsonrails to freeze some gems, and it got confused by the fact that Leopard stores built-in gems separately from user-installed ones. Thinking about it, if I’d successfully frozen the gem, it might have turned out to have been tweaked in some Mac-specific way and broken on other platforms.

Forgetting about that issue, I carried on with other work for a while, then found that autotest wouldn’t work, and mysteriously was trying to run something from /opt/local (where MacPorts install lived). Even after removing any gem-related scripts from /opt/local/bin, the problem persisted.

Oh well, looks like I’ll be re-installing everything using MacPorts. I’m not sure whether all these problems are intrinsic to the Ruby installation that comes with the system, or whether some are caused by lingering remains of my MacPorts installation – I’d be interested to hear how others got on.

[tags]ruby, rails, mac, 10.5, leopard[/tags]

Categories
Rails Software

Rails, SOAP and REST

From the list of new features coming in Rails 2.0:

It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so.

Categories
General nonsense Ruby

Duck typing for dummies

def duck?
  respond_to? :quack
end
Categories
Ruby

Unimplemented specs in RSpec

One of RSpec‘s many neat features is the ability to insert placeholder specs. These allow you to list a whole bunch of expected behaviour up front, without having to implement either the specs or the code, and without creating a huge swath of failing specs. All you need to do is omit the body of the specify or it block. Here’s a trivial example:

describe "The string 'foo'" do
  before do
    @foo = 'foo'
  end
  
  it "should be three characters long" do
    @foo.size.should == 3
  end
  
  it "should be capitalised to 'Foo'"
end

$ spec -f s foo_spec.rb                     

The string 'foo'
- should be three characters long
- should be capitalised to 'Foo' (NOT IMPLEMENTED)

Finished in 0.011201 seconds

2 examples, 0 failures, 1 not implemented

[tags]ruby,rspec[/tags]