Rails for Java Developers: comparative example...

[Gian Franco]

Hello,

I think I'm not alone if I'm still wondering how
certain aspects of Rails would be an improvement.

Is it possible to give a comparative example, that
would fit in a thread?

Maybe starting from a scenario E.g. there are two
simple administrative apps (i.e. one Rails based, one
J2EE based), both have the same functionality/features
and are MVC. Suppose the users come with a change request
that spans more than one of the original use cases...

Gian

[Lasse Koskela]

So which app is easier to change, you mean?

If both apps are designed well, though, the difference should be largely a question of the programming language. In that sense, I'd say that the Rails application is more likely to be easier assuming that the change doesn't involve large-scale refactoring that (so far) has been a manual operation with the current Ruby IDEs.

[Gian Franco]

Hi,

No I meant...

How would one tackle this situation of implementing a similar
change request in those two worlds.

I realize it is a vague scenario...but I'm eager to see how
tackling a J2EE implementation issue differs from tackling
a Rails implementation issue...where is the silver bullet

A discerning insight of the two environments probably would lead
to a simpler example, illustrating the different implementation
issues one encounters.

Gian

[Lasse Koskela]

Originally posted by Gian Franco Casula:
I realize it is a vague scenario...but I'm eager to see how
tackling a J2EE implementation issue differs from tackling
a Rails implementation issue...where is the silver bullet

Ok. Let's say you get a change request for the Amazon's ass-kicking online bookstore you've been developing on top of Rails in your spare time. Your focus group (the guy sitting next to you at work) says that the shopping cart really should display the total of the items in your cart. And you agree, feeling slightly proud about your friend thinking that someone might actually buy something from your precious little web shop.

So, how do you go about implementing the change?

First, you take a quick look at the existing controller class (app/controllers/shopping_cart_controller.rb) and figure out roughly how you could implement the change. Realizing that you'll need the controller to populate a new piece of data (the total price) for the view and that it's the domain object (app/models/shopping_cart.rb) who is best able to calculate the total, you stretch your fingers and get to work.

Starting from the domain object, you add a new method named "total" to your ShoppingCart class (app/models/shopping_cart.rb), collecting the prices of individual items and summing them up. Then, you take your ShoppingCartController class (app/controllers/shopping_cart_controller.rb) and add a one-liner along the lines of "@total_price = model.total". Finally, you look at the ERb template for the shopping cart page (app/views/shopping_cart/show.rhtml) and tweak the HTML, embedding "<%= @total_price %>" to the appropriate place.

And obviously you did all of those code changes test-first, right?

The approach doesn't really differ all that much from what you'd do in a similar well-architected J2EE application. Except maybe in that the combination of Ruby and Rails lets you type less. And think less. In a good way.
[ January 31, 2007: Message edited by: Lasse Koskela ]

[Gian Franco]

Originally posted by Lasse Koskela:

The approach doesn't really differ all that much from what you'd do in a similar
well-architected J2EE application. Except maybe in that the combination of Ruby
and Rails lets you type less. And think less. In a good way.

With all respect Lasse, the given example is too simple, but the last
sentence is interesting.

Given the fact that maintenance is a major issue in software development
an explanation of why Rails "think less. In a good way" would be on
the money.

A comparison that jumps to my mind lies in the database world: with
MSAccess, for example, I can think less, but with Oracle I can do more.
MSAccess and Oracle have both pro's and con's of course.

In a nutshell, why should a programmer or company invest in this new way of
thinking less?

Thanks!

Gian
[ February 01, 2007: Message edited by: Gian Franco Casula ]