As an official JRuby fanboy, I have been looking for a project at work to use JRuby on Rails on, and finally I thought I’d found one.
I need to write a little service to manage user preferences. Clients need to be able to save and load their list of favorites for a particular activity, along with a list preferred favorites determined by “someone in charge”. In my head, I was seeing a slick little REST service, feeding lists back to the client as XML. Since our application uses a Swing client, I don’t even need to provide an HTML view. It just need to run it on Tomcat against an embedded H2 database.
It almost worked.
There is definately a promising future for this development style. Some things work really well:
- The service ran in Tomcat just fine. Thanks to Warbler (you rule Nick), it was dead simple to get this running in a Java container. And this was before that whole Glassfish gem whatchacallit was released. I can’t wait to try that!
- I added some code to environment.rb that would run the migrations in production on start up if it detected that the schema was out of date. Convenient for deploying new releases to clients (we don’t host our applications) but migrations have to be rock solid.
- Using JNDI, it’s possible to configure where the embedded database files are stored, which is great when twitchy sysadmins start asking about making back ups.
All and all, it would have made a pretty slick solution.
In the end, the death knell for JRuby on this project was that, at the time I had to make the final call, I could not get the script\console or unit tests to work with H2. No tests, in particular, is a big deal. Our shop is pretty open to adopting new technologies. At this time last year we were putting JRuby 0.9.1 into our application to support customizable ETL precesses. But when it came time to commit on this project, I wasn’t comfortable building in JRuby on Rails if I couldn’t deliver a complete Rails application. I have a reputation to maintain, after all.
Oh well, maybe next time.