Evaluation: moving from Java to Ruby on Rails
Posted by rick Wed, 16 Nov 2005 16:32:00 GMT
In September (or so) we went through the process of trying to decide whether we wanted to keep plowing through the JBoss Java stack we were building with or to pursue an alternate technology. We did some test prototyping of part of our first component (of 6) in Ruby on Rails and then a test re-implementation of the full component in Ruby on Rails.
The productivity increase (and code footprint decrease) was basically staggering. We undertook a full analysis of the consequences of shifting our development from our Java stack to a Ruby on Rails platform. Ultimately we decided to shift from Java to Ruby on Rails.
The summary document of the issues (edited to protect the guilty :-) can be found on this site at Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite.
Rick, you never fail to impress. Nice work.
Why didn’t you look at some Web Frameworks for Java like WebObjects? Isn’t it a bit strange to compare a programming language to a Web Framework? If you wanted to compare Java to something why didn’t you compare it to Ruby and not Rails? Of course these questions suppose that you wanted a fair comparison.
JohnW—thanks!
Raccoon, On the one hand it may be closer to say that we compared Ruby on Rails to Java/JBoss, since that’s the platform we came from (and there are numerous mentions of JBoss in the article, actually)—though that, perhaps, could be made more clear.
There was indeed a much longer process prior to this where Java and JBoss were selected. I was involved in the selection of Java as a(n unpaid) consultant before I took a position inside the organization. I’m familiar with the reasoning which led to the selection of JBoss, though I wasn’t involved in that selection. Were the parameters of the project to force Java at this stage I would probably still agree with the selection of JBoss for a framework/app-server/what-have-you.
I’ve documented elsewhere the reasons why Java was chosen initially, and at that date, given the parameters (including some imposed from the outside) I can see no other choice. Over a year later, however, with parameters changed, the case for Java is much less compelling.
You seem to think I wrote this article to sway public opinion, when the reality is that I wrote this article to validate my case with myself, and as part of a much wider review conducted inside our organization. This document is one piece of a larger puzzle, but a succinct summary of our overall technical thinking.
In reality, I’ve bet my reputation on the things I wrote in that document being true—that our particular team, in our particular organization, given our particular mandate and restrictions, can create an application that suits the needs of our user base better and faster by using Ruby on Rails than we can using Anything on Java.
I could be wrong. Time will tell. But, the document here is an artifact of my process of convincing myself that the risk of getting to where we need to be is lower for us going this path than the (Java) path we were on. Given the lack of succinct useful analysis on this topic I figured someone else might gain some insight from reading that artifact.
Thanks, Rick
As I’m also a Java developer interested in the possibilities of Ruby and Rails, and someone in the position of making technology recommendations to my employer, I found your analysis very useful and interesting.
As I read it, it comes across a bit as “I want to do Rails, and here’s my justification for that decision”, and less as a comparative analysis. Perhaps the former was your intent, but I’m wondering if you’ve written anything (or would be willing to write anything) addressing the specific pros of Java you’ve identified that you might be sacrificing by the switch.
In other words, apart from the risk of working with a new technology using developers that have minimal experience with technology, what things really keep you up at night when you think about making this transition?
Dan, I’ll answer you in two parts…
First, the piece should probably come across somewhat how you described it, due to its function and history. We were running aground with Java/JBoss and started looking at other languages and platforms. We (mostly me) did survey work to see what the current trends are in web application development (we knew, due to the distributed nature of many of our sites, including a presence at a number of schools, that we would be required to run a web app as opposed to running a remote app under Terminal Services (etc.)). We narrowed the field down to a tree of alternatives (many of which were in the Java subtree) and ultimately ended up with a Java platform very similar to what we were working on, Ruby on Rails, and Oracle Forms.
We did some more evaluation, and our commitment to database agnosticism ended up eventually ruling out Oracle Forms (there is a similar but shorter document highlighting the pros and cons of Oracle Forms, but ultimately being dependent on Oracle alone was too much for us). We will be deploying this software to small groups occasionally, in some cases as small as an office with a couple of clinicians. We could provide an ASP service (and may still) to small sites, but being in bed with a single database vendor didn’t sit well with us. Since then our commitment to database agnosticism has paid off in our development process. I’ll probably write more about that later.
Anyway, we did more trial development with Ruby on Rails and found impressive reductions in code and complexity, as well as significant gains in productivity. Then we began researching the nooks and crannies of the platforms to find the upsides and downsides of staying or moving. After that we’d decided that technically we were better off on Ruby on Rails.
So the document you see came next and was essentially a succinct encapsulation of the issues, but also something of an advocacy paper for the decision we as a team were making on technical merits. The good and the bad points are in there, as they affect us, but the underlying tone of the piece is, “we’re advising you on how we want to proceed”.
That said, I’m not aware of any Java pros—for us—that I’m leaving out. We don’t anticipate the need for heavy-duty messaging servers, i18n to 12 different languages, or Swing front-ends for desktop applications, etc. Those are all big Java upsides, they just don’t figure into our decision.
As far as what keeps me up at night re: this transition. Now the things that keep me preoccupied are less technical concerns—how do we keep the pipe full for the developers as we try to gather requirements from our customers, many of whom are very difficult to reach in a timely manner; how do we make sure the team communicates effectively when our facility gives everyone his own office; how do we model measurements in such a way that evidence-based treatment, billing, and clinical guidance are supported efficiently; how do we incorporate prescription history without the pitfalls other medical records have fallen into, etc.
Now that we’ve switched platforms, our developers are mostly up to speed with developing in this environment. One technical hurdle was introducing an automated testing methodology in an organization which to my knowledge had never written a unit test (I’m not even sure any sort of automated testing has darkened the doors here). Now we’re running continuous integration with unit and functional tests, and talking about more types of tests (smoke tests, converted data tests, etc.); and there’s a little bit of TDD going on as well already.
Another concern I have is data conversion—we’ve already started the data conversion process from our huge old nasty-ass legacy system. This promises to expend a significant fraction of the overall project effort. Bringing other organizations online to this system means that they’re going to be undertaking similar data conversion projects, but they’ll be starting later (much later in some cases) than we are, with little knowledge of our domain model. We will have to begin working with each organization as early as possible in order to get a handle on the potential risks and delays that are going to come with their data conversion. That one keeps me a bit worried.
Anyway, as you can see, the least of our worries, now that we appear to be moving forward quite well with the new technology stack, are related to the technology itself. The technology is working for us, and I don’t see anything yet on the horizon that looks like a potential problem. Now we’re working where we should be—in the business and personal domain.
Best, Rick
Rick,
Thanks for the great article. I come to RoR from building web apps in Perl and C++, the latter on embedded systems. I’ve also built some Java apps, but for the most part, I’ve never found Java (and its many frameworks) to be the right match for any project I’ve worked on. It’s really an impressive language and I appreciate its purpose and vision, but the cost/benefit just hasn’t worked out for me.
These days, there are so many Java frameworks involved with building a “real” Java web application that it’s incredibly daunting to someone from the outside. I mean, I’ve been building web apps for years, so what’s the deal that I now need to learn a half dozen new frameworks? But for pros in the Java space, that’s apparently what you do. I can’t help believe that a lot of that knowledge is throw-away; in five years everyone will be using other frameworks. (To Raccoon’s point, I’d say this article’s comparison is Ruby on Rails vs. Java and [insert flavor of the day Java framework here].)
But RoR is just a piece of cake. I’m familiar with MVC; most professional developers are. Mapping from that general concept into Rails code is incredibly straightforward. By the time you’ve worked through the Depot application in the rails book, you know enough to start building some real, useful apps. If you’re into agile development and want to write code test-first, it’s all right there. Good point on the developer tools, too: you just need an editor and command line. Almost zero learning curve.
As such, I’m in complete agreement on the point about hiring developers. The good ones will learn whatever they need to be effective. We build products, we don’t just “write Java code.” I heard some very reputable (and not generally excitable) people talking about RoR and decided I needed to check it out. I did, it delivers, so now I’m using it on real projects.
II read through most of your discourse on Java vs. Ruby (on Rails) and appreciate most everything you’ve written.
Through all of it, it did not find any discussion of Web standard compliance.
I was wondering if you had given any thought to Web standards compliance (i.e. HTML 4.01, XHTML 1.0, CSS 1.0, CSS 2.0, WCAG/S.508, etc.) in regards to the use of Ruby on Rails and especially AJAX.
Your comments and feedback are appreciated.
Flirting with Rails,
Ben Roberts broberts80@gmail.com