Over the last four months, I’ve been doing both Java and Ruby work.
Inland Revenue are building an external authentication system in Java Portlets on Websphere Portal. And, Sharesight are building an online share portfolio manager in Ruby on Rails.
I’ve noticed how different the two environments are when using 3rd party libraries. Take these two examples:
Using Display-tag for rendering multi-page tables
Display-tag is a Java library that has been around for a long time. I remember using it back at Westpac in 2005. It provides a JSP tag that you can use to render large collections – either on a single page, or over multiple pages. And provides the ability to switch between each of those pages with the expected next/previous and page 1/2/3/etc links. It also can sort the collection by clicking on the column headings.
Anyway, we ran into a problem. The functional specification document wanted the paging link positioned in a specific manner. This differed from what display-tag generated by default. The developer writing the tag spent a lot of time poring over the (good) documentation trying to find out how to make the links appear in the desired position.
Eventually, he came to the conclusion that the Display-tag library wouldn’t do it. The only way the achieve the desired outcome would be to use some CSS magic.
Using Mail queue for asynchronous email
Mail Queue is a Ruby on Rails plugin that converts the normally synchronous mail sending capability of Rails to an asynchronous queue. The emails get stored in a database table, and you use a background process such as cron or Backgroundrb to send the stored email.
It was all going very well, but we wanted to enhance the plugin to add the ability to archive the sent emails, rather than delete them. This would allow us to diagnose problems a lot easier.
In a Rails plugin, you have direct access to the source code. The plugin is stored in the vendor/plugins/mail_queue directory of your Rails project. We opened the mail_queue.rb file, found the code we needed to change, made the enhancement, and saved the file.
The differences
With Java 3rd party libraries, they are packaged into a standard JAR file. Inside the JAR file are all the pre-compiled class files. It’s difficult to see how the library is coded. If I wanted to change how a Java library worked, I’d have to:
- Download the “source” distrubution
- Unzip the distribution to a temp directory
- Find the code, and make the change
- Search for the build instructions
- Download Ant, or Maven, or similar
- Do I have the correct JDK version
- Hopefully the build works
- Replace the old JAR with the new build
Contrast that with the Rails approach:
- Find the plugin code and make the change
- Restart your server
It’s the dynamic nature of the Ruby language that contributes to the ease-of-modification. Being able to replace the change/build/package steps with just a change step makes a huge difference to productivity.
Conclusions
- Ease of modification means greater use of plugins
- Dynamic languages are the future