You knew right away from the title that there's a catch, didn't you? No, "commercially" is not the regular "commercially" one would expect.
Me and another consultant (from another company) used a Rails app as part of a "live" demo for story test-driven development using a proprietary (sort of) FIT clone built on top of Jython and the JWebUnit WebTester utility for testing against the web interface. Basically, when the client called me up and said "we need some kind of a sandbox application to demo with the day after tomorrow", I knew that we'd have to a) use one of the Petstore implementations or b) use the Rails sample app I've got on my laptop. After some seconds of deep thinking, I also realized that since we're going to have only 30 minutes to actually implement whatever feature we need to implement, the scale is tipping fast towards the Rails app.
And so we ended up demoing the FIT clone against a Rails app.
There's more to this post than that, though. You see, we stumbled into a nasty little glitch while implementing the test--we couldn't make JWebUnit's WebTester to check a checkbox. We really couldn't. Both of us had done that before--with Java and with Jython wrapping Java--so we knew the same methods we were using had worked before.
The problem was eventually hunted down into how Rails' form helper functions deal with checkboxes. When you do
<%= check_box("to_be_shipped", order_line.id, {}, "yes", "no") %>
in the Rails ERb template (.rhtml), Rails actually renders not one but two <input/> elements. The first one is for the checkbox and the other is a hidden field with the same name and having the hardcoded value of "no" (for "not selected"). The purpose of this is of course to have the browser submit something every time regardless of whether the checkbox is selected or not.
Our problem apparently was that JWebUnit tried hard to set the value of the hidden field and not of the checkbox, resulting in a strange "value of to_be_shipped[123] must be 'no'" error message. Hardcoding the checkbox element in the .rhtml ourselves solved our immediate problem right away.
I hope this will help someone else avoid high blood pressure in a live demo situation ;)
Oh, and if you know of a better solution (than rendering the HTML ourselves), please leave a comment or something.