Skip to: Site menu | Main content

XPlanner

Planning and tracking tool for agile teams following XP or Scrum

Ruby on Rails rewrite Print

Steve Bate and I have debated a while back a rewrite to Ruby on Rails.

Outside of the geek coolness factor of ROR, I can see the following advantages of ROR.

However there is a significant investment in xplanner already both in software and people.

We are just facing a typical "innovator's dilemma" the same as anybody writing web application nowadays.

new ROR version advantages

Simpler

No spring-bean.xml, struts-config.xml, screen-definitions.xml, *.hbm.xml...

Programming by convention! I always built my frameworks like that. ROR just felt right in that way! Explicitness is overrated IMHO!

Development cycle speed

No compile, no jsp compile!, no server restart. Some of our antiquated laptops at work takes 4mn to restart tomcat!

Terseness of Ruby

Compare to java ruby shines. java closures where are you!!!!

To some extent, java 1.5 syntax solves some of it (foreach, autoboxing...)

AJAX builtin into ROR

ROR has embraced AJAX and even push it. Unfortunately the java space is trailing (no pun intended) behind.

Clean slate

The current xplanner is showing its age in some parts: untested, full of duplication, inconsistent...

Right now XPlanner is 60% automatically tested

Maybe the current best web AT framework

Watir is maybe the best web acceptance test framework around and it is written in ruby.

As I have learned with xplanner, having your AT framework in the same language as your application speeds your development up in more than one way.

I don't believe the initial scafolding is a significant bonus since it is a one time only framework and is only intended to get you started fast.

Current java version advantages

The obvious advantages of the current java

Already built features

Let's list them here so we can estimate how much it would take to implement them in ROR

Specifically the current features that would be hard to replace are: charts and the different exports (pdf, jasperreports, mpx, excel...). They are usually the features that people uses to integrate xplanner in their environment.

Large base of free java components

xplanner already uses lots of free components:

  1. cewolf(charts),
  2. spring,
  3. itext (pdf),
  4. mpxj (ms project),
  5. poi (excel),
  6. jaspereports (reports)

From a java component perspective ROR="java, struts, ajaxtags, hibernate, axis, javamail"

Easier enterprise integration

  • User management through LDAP/Active directory.
  • JMS for future integration with CRM/DTS... (At work we are looking at a Siebel integration through SeaBeyond EAI)

Static typing

The small case for static typing is the few errors caught at compile time. However these would be caught anyway in testing if we had 100% coverage as we should strive for in a rewrite.

My biggest preference for static typing is its clarity. The typing system allows to define clear contract:

  1. interfaces
  2. collection element types (generic)
  3. parameters...

Next steps

After 0.7, I believe we need to look into measuring how much it would take to get to the same level of features. Anybody want to help?

Wait but there is another way!

The other alternative is to leverage the existing codebase and use groovy instead. groovy is as good a language as ruby in my mind. What it has for itself is the fact that you can embed groovy in java and vise-a-versa. There is even a ROR port to groovy under way: grails

Jacques Morel