Technoetic

I’ve been hearing so much about Ruby on Rails lately that I wanted to try it for myself. As an experiment I decided to port the XPlanner planning tool for XP/agile teams. This was only a partial porting effect focused on the core XPlanner functionality.

I experienced a few minor challenges at the start of this effort. I was working with an existing database schema which is a little trickier than creating a schema from scratch using Rails naming conventions. It wasn’t difficult to support the existing schema but some inaccuracies in the documentation led me astray temporarily.

When I’m learning a new framework I like to be able to easily browse the source code. This exploration fills in the information gaps in the documentation and in some cases resolves inaccuracies or ambiguities in the documentation. This type of exploration was very beneficial even back when my development environment was Emacs and ctags or the info application. However, I’ve been spoiled by modern IDEs with powerful cross referencing and source code navigation features. I used the Ruby Eclipse plugin and it was nice to have some basic syntax highlighting but it has no source code navigation support (version 0.5). I felt like I was somewhat crippled compared to exploring a Java framework. Obviously this is not a criticism of Ruby or Rails per se, but it’s a consideration in the total productivity evaluation. The next version of the Ruby Eclipse plugin will address some of these issue so I expect the situation to improve.

The Rails MVC architecture was similar to the XPlanner internal architecture so porting the core functionality was not difficult. There’s definitely a serious increase in fun when developing a scripted web application. I enjoyed Ruby’s dynamic features and how they’ve been used in Rails. It’s not hype that there is no XML configuration is required with Rails. This is a real time save compared to a Java Struts application using Tiles.

Many people are evangelizing Rails as providing a 10x productivity improvement. I wouldn’t say I experienced that level of productivity increase compared to a Java web application but that could well be due to my newbie status with Rails compared to extensive experience with Java applications. To fully port XPlanner will require charting and advanced HTML table components (sorting, pagination, filtering).

I wasn’t able to find portable charting code (pure Ruby, no native libraries) at the time I wrote this article. The charting code that I did find didn’t appear as capable as open source Java charting packages like JFreeChart. I’m also concerned about packaging and installation issues when a web application requires native libraries.

I didn’t find any advanced HTML table components. It’s not extremely difficult to write one of these from scratch, but the time spent writing it offsets much of the benefits of the more productive language and web framework. I believe this situation will improve with Ruby and Rails over time and probably very quickly, but again it’s a consideration for now when considering productivity. If portability is not an issue and advanced web components are not needed for your application, then Rails may be a very good choice.

Note: I’m not currently planning to complete this experimental XPlanner port. However, if someone is interested in finishing the port and supporting it, I’d be happy to provide the source that I’ve developed so far. The current experimental code is compatible with existing XPlanner databases (as of XPlanner 0.6.2 and the upcoming 0.6.3 versions).