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...
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.
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.
"Eppur si muove!"
posted 13 years ago
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 ]
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?
Gian [ February 01, 2007: Message edited by: Gian Franco Casula ]
"Eppur si muove!"
They weren't very bright, but they were very, very big. Ad contrast:
Two software engineers solve most of the world's problems in one K&R sized book