Real world JRuby on Rails: Infectious disease reporting and management

JRuby and JRuby on Rails continue to being adopted by many projects. After Mingle, Oracle Mix or Sun's rewrite of mediacast.sun.com, a new project using JRuby on Rails has surfaced.

From the press release:

Collaborative Software Initiative (CSI), the company that brings like-minded organizations together to work on collaborative software at a fraction of the cost, today announced the release of the first open source, web-based infectious disease reporting and management system.

The disease reporting and management system, which is being piloted in Utah, will be adaptable in all 50 states and available under an open source license later this year. It is designed to support local health departments in the early detection and investigation of individual cases and local clusters of communicable diseases, while simultaneously meeting the state and federal needs of outbreak control, disease surveillance and epidemiologic research.

One thing to note further down in the press release: the project uses JRuby. We talked to Mike Herrick, Program Manager at the Collaborative Software Initiative,  to talk about the experience of using JRuby for the project.

InfoQ: Could you give a quick overview what kind of software you implemented and which parts you implemented using JRuby? Is it mostly a web site or are there any (business) logic parts involved as well - are they also done using JRuby?

We are about 6 months into an iterative (based on Lean Software Development) two year initial build of the application. So far it is 100% JRuby. Its currently all web application, but we have a very extensive roadmap that includes analytics, a disconnected client, and substantial integration. We are undecided on the technology for analytics, disconnected client, and integration. We'll want to use JRuby and Java as much as possible.

InfoQ:  What's your list of technologies you used for JRuby and Rails? What servlet engine do you use? Do you use tools like Warbler or others?

We are currently using Java 6, JRuby 1.1.1 with the following gems:
 * Rails 2.0.2
 * hpricot
 * mechanize
 * postgres-pr

We are currently using the following Rails plug-ins:
 * auto_complete
 * validates_date_time
 * model_auto_completer
 * haml
 * calendar_date_select
 * betternestedset
* RAA soundex (actually a library: http://raa.ruby-lang.org/project/soundex/)

We also have a plug-in in development named acts_as_auditable and may spin it out as open source before we open the entire project if it pans out. We are using RSpec and Selenium Grid (also uses RSpec) for testing, and Hudson for Continuous Integration. We are using NetBeans and vim for development.

We are using PostgreSQL for the database. We looked at Solr for full text search, but ultimately favored PostgreSQL Full Text Search as it met our needs and we didn't want to introduce another moving part.

We are currently using Tomcat for our servlet engine. It is working well. We have heard good things about GlassFish and would like to take it for a spin at some point. Warbler has been terrific. Nick Sieger really eased some pain with that (original Goldspike based packaging has now been deprecated). A small contribution we made to the JRuby community was to provide some specific documentation on how to use Warbler with Rails 2 when it first was released in the JRuby wiki. I wrote a blog post on that pointing at it the wiki page and it still gets dozens of hits a day from lots of large companies. I've taken that as a good sign of JRuby uptake

InfoQ: According to the information in the above link, the project's team is rather large - how many people were involved with writing JRuby code?

Collaborative Software Initiative (CSI) engages the power of community to build project teams and provides the central project management function for developing Collaborative Software, including development, testing and ongoing support for the code. CSI delivers the software to a broader base of customers under the open source licensing or Software as a Service (SaaS) model. There are currently over 100 participants in our public health community. The community is currently made up of Subject Matter Experts (SMEs) and Developers. The SMEs in this case are epidemiologists, nurses, and medical doctors. There is a core team of 15 SMEs and Developers. 5 members of the Core Team are developers. We also have 2 part time developer contributors. Of the 7 developers, 4.5 are actively writing JRuby. Our senior developers on the project are Ed Copony and Pete Lacey. Plug: we are looking for another core developer.

InfoQ: What problems did you encounter while working with JRuby on Rails - and how did you solve these problems (tools, workarounds, bug reports to JRuby team,...)?

At the end of the day, developing serious software is really hard even under ideal situations like ours. We hired known performers for the development team. For better or worse, our experience with JRuby, Ruby, and Rails wasn't terribly deep although we had some. Ross Cooperman, the leader of another Collaborative Software Initiative project in the Financial Services vertical had deep Ruby and Rails experience with MRI. That was really useful in the early days of the project in steering us in the right direction. So there certainly have been learning curve issues. Ruby and Rails are productive once you conquer the learning curve, but it doesn't come over night. We have had some trying days, but are having far less of them now.

Along the way we've turned to the JRuby mailing lists, wiki, and IRC. The community has been very supportive. When Rails 2.0 first came out I found a bug in Goldspike (the JRuby Rails servlet): http://jira.codehaus.org/browse/JRUBY-1879. We worked out a fix with the community quickly over a weekend. In the days leading up to our first release in March, JRuby 1.1 was about to ship and we found a bug that was going to prevent us from releasing our application with JRuby 1.1 as we had hoped: http://jira.codehaus.org/browse/JRUBY-2314. The JRuby community rallied around it and squashed it and we were able to release with JRuby 1.1.

InfoQ: What's the reason of using JRuby over regular Ruby?

We chose JRuby over MRI for a number of reasons: * Ease of deployment * Every enterprise on the planet runs Java * Our development team has a Java heritage * Our roadmap for the project is extensive and we didn't believe we could do it with Ruby alone. We wanted our fall back language to be Java rather than C.

InfoQ: Are there any features or improvements you'd like to see implemented in JRuby or the JRuby on Rails software stack?

More than anything, we have been impressed with the drive of the JRuby community. It is very ambitious and also pragmatic. The core team is comprised of some spectacular developers. The focus seems to be on the right things. Better Java integration, constant performance improvement, and collaborating with the JVM folks on improving the JVM for all dynamic languages. This is all good.

I ran this question past Pete and Ed to get their input as well. Their input has to do with Rails & not JRuby specifically. We'd like to see better multi-model support, possibly via nested has_many throughs and has_one throughs. We'd also like to see more consistent validation support, including rolling up validation errors to the top model. And finally more flexible URLs formats, maybe including URI Templates.

 In our experience to date, Rails is holding up. As I mentioned above, JRuby and Rails is a very productive environment, but we are building a large application here - its a ton of work regardless of what technology you are using. We are definitely seeing significant productivity benefits over straight Java or Java and Spring, but Rails is not a silver bullet. That said, there are many innovative tools and ideas in the Ruby community and in Rails that have provided for many moments of delight, even in the midst of tackling sometime frustrating learning curves.

InfoQ: Are there Ruby language or standard library features you'd like to see in the future?

In our experience, JRuby just works. We have yet to have an issue with JRuby vs. MRI compatibility. There are of course some gems that have not been ported to Java yet, but we have not had a need to use them.

InfoQ: Did you have any problems in getting JRuby accepted as implementation technology (by management or the client)? If yes: how did you get around these problems?

We haven't had any problems externally with our partners as its just Java to them. Our current deployment package contains database scripts and a .war file. As we build out the roadmap there will be more moving parts, but certainly no more than a typical JEE application.

Collaborative Software Initiative is a very meritocratic company. At the beginning of the project we debated using Ruby (MRI), Python, Java & Spring, JRuby & Rails & Java, JRuby & Merb & Java, PHP etc. It really came down to momentum. The Ruby language has a lot of momentum. There is a lot of diversity in Ruby virtual machine implementations and collaboration between the language implementors. This is a very good thing in our view. We looked at all the options, assessed the communities, had a healthy debate and then voted. We were very impressed with the trajectory of JRuby. In our view, it was ready for production use. We ultimately decided that given this project and our team, we were most comfortable with JRuby, Rails, and Java. We certainly have nothing against the other options, but we made our choice and are happy with the results so far.

Have you used JRuby on Rails for non-trivial web applications?