Leonardo Borges

As always I expected a good talk from Ola and once more he delivered it. But this one was different. It might have been even boring to some ruby developers since we saw a fair amount of java code in this presentation. Ola gave us a tour through the main classes that make JRuby possible with a single purpose: so we can check out the code and hack ourselves. You can download his slides here.

If you’ve been following both JRuby and Ola Bini for the past year or so, you’ve noticed the trend and evolution of this alternative - and so far the most complete one - implementation of the ruby language. Specially at conferences.

Last year at QCon London, Ola was also talking about JRuby. At Euruko ‘08, in Prague, Charles Nutter also talked about it. RailsConf in Berlin also had its share. What all these talks had in common is that they talked about JRuby from a user/developer point of view. They were selling the solution. Convincing people to use it and presenting successful use cases.

And as the trend goes on, JRuby is now faced as a true alternative - one that we, btw, believe here at the company as we’re actively using it - and it seems that now the call is for help. Help to make JRuby an even more complete and overall better ruby implementation. Charles’ call for help was a great step. As he states, it’s a good way to get your feet wet. I answered the call and am hacking JRuby myself, having already submitted a couple of patches. Perhaps this was the reason for which I enjoyed the talk the most. I was already familiar with some of the structure and classes in JRuby.

There were 2 more talks about JRuby: The Pleasure and Pain of Migrating to jRuby, by Steven Bristol and Integrating Enterprise Java with JRuby and Rails, Michael Johann. Unfortunately only the first one was a real case experience, where Steven walked through the problems he faced integrating JRuby with an existing java project. Interesting insights.

Michael Johann basically presented a short tutorial on how to integrate rails with EJB3 which, albeit interesting, failed to address issues faced on real life projects, like dependency management. Issues which we have already addressed in a very cool way here and I plan to share it soon. Still deciding how though…

As you probably know, since rails 2.1 you can write test methods in the following format:

test "hotel should return its permalink" do
  #your test code here
end

Which is great, as the test name becomes much more clear. But you can’t simply run this test easily from the command line. You’d have to run something like:

$ ruby your_test_file.rb -n test_hotel_should_return_its_permalink

It annoys me. And it’s not practical either to make the test fail just so you can get the test’s real name.
I wanted to be able to just copy and paste the readable name in the console and have Test::Unit do the conversion and run it for me, like this:

$ ruby your_test_file.rb -n "hotel should return its permalink"

So I created readable_test_names_runner. It’s a tiny rails plugin that adds this feature for you.

Enjoy.

The rcov_plugin project is a rails plugin for rcov that adds some useful rake tasks to your application.  And since I’m currently working in a JRuby project it made sense to use this plugin.

The thing is, among other stuff, an rcov report from a JRuby project includes some files that shouldn’t be there at all, plus you also need to change the way you call rcov as such. Thus, I thought I’d contribute these changes to the plugin and my pull request was approved this morning - just install the latest version and you should be good to go.

It was useful for us here, hope it might be useful for you too.

Enjoy