HandBooks Professional Java-C-Scrip-SQL part 21 ppsx

6.3. Breaking It Down
That's a 30-minute tour through Ruby. I'm not saying that Ruby is the next great
language, but rather, that Ruby makes some of the hard things in Java easy. More
and more of the top independent consultants are looking for ways to make more
money working in Ruby, or other languages that are more dynamic. The Java
community is spending an amazing amount of money and brainpower on making
Java more dynamic. Dependency injection and aspect-oriented programming are
groundbreaking ideas for Java, and they are only now getting serious commercial
traction. For Java developers, these ideas represent better transparency and simpler
application development.
6.3.1. Collapsing Under the Weight of Abstraction?
My playtime in Ruby makes another, more powerful idea, clearer. As we stretch
Java in increasingly unnatural directions, there's a cost. AOP and dependency
injection are near-trivial exercises in Ruby, but they force Java developers to learn
new programming models, deal with XML, and introduce increasingly complex
syntax. With each new metaprogramming concept that we bake into Java, it's
looking more and more like all of that complexity is trying to drive us somewhere.
The net effect is to push Java further and further into the enterprise niche, and
make it less and less accessible to the average Joe. Contrast that situation with
Ruby, where dependency injection and AOP don't consume your focus; you're free
to apply those ideas in spots right where you need them.
I do think that Ruby, with Rails, is a near-ideal solution for that sweet spot that
we've pushed: a web-based frontend for a relational database. I've already said that
I'm using Ruby in a commercial application. My customer demanded productivity
and a price point that I couldn't achieve in any other way. I also still recommend
Java to many of my clients. They need complex frameworks that Ruby does not yet
support, or they depend on a core set of developers that have already been trained,
or they have so much legacy code in Java that change would be impractical.
In the next chapter, I'll make these arguments real. I'll show you how to build a
web-based application, from scratch, to access a relational database with a web

application. Then, I'll show you what another killer app might be, for another
language.





7.1. The Numbers Game
As a fairly content Java programmer, I really didn't go searching for an alternative.
In some ways, Rails found me. Dave Thomas and I speak at the same conference. I
taught several sessions on the Spring framework with Hibernate, and I was very
happy with my productivity. Of course, compared with EJB, I was very productive.
Dave pointed out that even in Hibernate with Spring, you tend to repeat yourself on
a fairly regular basis.
I reflected on David's comments. To make a persistent domain model, you need to
specify a database table with its fields and indexes, specify an object domain
model with a class (repeating yourself) and a field as an attribute (repeating
yourself), and add accessors for that field (repeating again and again). Then, you
need to build a mapping with the database table (repeating again) and the class
name (and yet again). Finally, your mapping must specify each database column
and the corresponding database field (repeating each column twice more). Of
course, most sane Java developers do not do all of that repeating. They let the tools
do most of it for them, but now your programming model dictates your tool set,
your development experience, and generates more lines of code to maintain. I
came to the conclusion that ORM makes sense when the domain model and object
model are sufficiently different, and I decided I'd take the slight productivity hit
and be compensated with better performance and the possibilities of better
mapping.
7.1.1. A Blinding Flash of Insight
As I've said, I worked with a company that builds safety software for a

manufacturing plant. We effectively build a web user interface to manage a
complex domain model. We decided to build this application with a lightweight
Java stack of Spring, Hibernate, and Web Work. We moved pretty quickly, and
were pleased with our progress. We were proud of our accomplishments, because
we'd rewritten a one-year Microsoft application in four months with Java.
Na
turally, as we accumulated a bigger code base, coding began to take longer.
Over time, Dave's arguments nagged at my subconscious. Dave and my business
partner had the same conversations. As luck would have it, over the same week, we
tried building a part of the application in Rails. I banged out the model and
scaffolding in a couple of days. With his stronger HTML experience, Justin got
further than I did. He actually implemented the whole application in Rails in four
nights. The Rails version shocked us in another wayit was actually faster!
Justin Gehtland: A Ruby on Rails Case Study
Coauthor of Better, Faster, Lighter Java

Justin Gehtland is the co-founder of Relevance, a consulting/training
organization based in Durham, North Carolina. He's the coauthor of the
Jolt-winning book, Better, Faster, Lighter Java, and has been developing
applications of all sizes since the early 1990s. Over the last six years, he
has delivered products using Java, .NET, LAMP, and now, Ruby on
Rails.
You've recently
moved a Java
project to Ruby
on Rails. What
Java frameworks
did the
application use?
JG: The original stack was the usual suspects

in the lightweight movement: Spring and
Hibernate, plus a little JSTL on the frontend
(so that the end customers could more easily
customize the interface). I was using the
ACEGI security framework for
authentication and authorization, but only to
authenticate against a local database of
accounts.
What surprised
you the most
JG: After porting the app and talking about
the experience, I was really surprised by the
about the
experience?
heated discussion it generated. There's that
old saw about disruptive technologies; if the
temperature gauge on the discussion is any
indication, Rails is clearly in the disruptive
category.
From a technology perspective, I was
surprised at the level of performance I was
able to achieve. The Rails version of the app
was fast, and faster even than the original
Java version. That's partially due to a better
understanding of the domain (rewrites
always take lessons learned into account),
partially due to a lack of performance tuning
on the original stack, but mostly due to the
fact that the performance gains with Rails are
easy to achieve. The page and action caching

strategies are right at the surface, and it's
easy to manage their life cycle. I was able to
max out the web server's ability to serve
pages. I literally couldn't get it to go any
faster.
Is Rails ready to
usurp Java?
JG: Ruby isn't going to outstrip Java on a
straight road. The JVM is tuned, and tuned,
and tuned again to optimize byte code
execution. But Ruby on Rails shines on the
turns. Its integrated stack, dynamic language,
and lack of a write/compile/test/deploy cycle
means it handles better. For this application,
it was like racing a Miata against a funny car
on a mountain road. The funny car has more
horsepower, but it just ends up driving
straight all the time.
What are the top
three things that
made Ruby so
much more
productive?
JG: I'd have to say that the dedication to
smart defaults is the primary benefit to Ruby
on Rails. Ben Galbraith has said it several
times, and I concur. Since Rails always lets
you override any of its defaults, you are
never in danger of getting stuck in a corner,
but for the most part, you can create an

application and ignore 90% of what would be
surfaced in configuration files in another
framework.
Second, I really was surprised at how much
of a difference the lack of the
configure/compile/deploy/test cycle really
makes. Saving a change and launching the
tests while reloading the browser just seemed
so instantaneous comparatively. I don't know
that it made me more productive, but it made
me feel more productive.
Lastly, the dynamic nature of Ruby really
shined for me. I did need some common
pieces of functionality in the app that really
belonged back at the framework level.
Instead of having to delve into the source to
add them, I just extended the classes I needed
to at runtime. That kind of extensibility is
anathema (and usually impossible) in a more
statically typed language.


7.1.2. Making the Commitment
Of course, playing with a prototype and getting a customer to switch from tried and
proven Java to a relatively unknown framework on an unknown language was an
altogether different proposition. I had a conversation with the start-up's owner, and
the results surprised me. He jumped at the chance to move. I guess I shouldn't be
surprised. We simply couldn't ignore the differences in raw productivity between
the frameworks.
In a start-up environment, productivity rules all other concerns. Since you don't

often have the resources of your competition, you need to iterate fast. You can get
some leverage by working longer hours and cutting bureaucracy. If you can
generate an edge with technology, you've got to take that opportunity. In an
increasingly competitive global landscape, we'll all need to act more like start-ups.
If a framework makes you a mere 120% faster, you might be tempted to s
tay with a
safer language like Java. But if you can be 400% faster or more, I don't think you
can ignore the difference.
Remember, my premise is that Java is drifting away from its base. Most of us need
to build web applications on relational databases. Language issues are important,
but Java's drivers are so focused on hard-core enterprise problems that they're not
making any progress on this simple core problem. If Rails doesn't step into this
gap, something else will.
7.1.3. Some Numbers
I'm going to give you some performance and productivity numbers based on
experience. I recognize the numbers are imperfect, for a whole lot of reasons. In
some ways, the deck was stacked against Rails:
 The Ruby application implemented more customer requirements. By the
time Justin realized that his experience was important, he'd implemented
some features that never made it into the Java version.

Justin was a recognized expert in Java, but had never used Ruby in a project,
and had never used Rails. He wrote a Spring book, and he taught two
weekend sessions 16 times per year for Hibernate.
 The Rails framework has some design philosophies that are unfamiliar to
Java developers.
More importantly, some of the factors worked against Java in the implementation:
 The Java code was in no way fully tuned. The Java apps were much harder
to tune, so we didn't get as far. We'd only started to look into performance.
(The Ruby code was not fully tuned either, but its default implementation

performs quite well with only some minor tweaks.)

We had already implemented the problem once, so the Ruby implementation
had the benefit of some experience. The dramatic difference in application
structure tempers this somewhat, but the user interface was nearly identical.
 Justin did not have a chance to
implement all possible tuning scenarios in all
possible environments. The Java version used Tomcat on an Apple iBook
instead of Resin or something faster. Justin just made a few simple tests.
 The caching models are fundamentally different, and are far eas
ier to tune on
Rails.
Still, with Ruby, we develop faster; we're probably four or five times as
productive. Table 7-1 shows the raw productivity metrics. We write less code.
There's less code to maintain. With this type of increase in our cycle time, the
customer is much happier, and we can better react to last-minute changes. Our test
code is every bit as rich, and probably more so.
Table 7-1. Productivity metrics
Metric Java Ruby


Spring/Hibernate Rails
Time to market
4 months, approximately 20
hours/week
4 nights (5
hours/night)
Lines of code 3,293 1,164
Lines of configuration 1,161 113
Number of

classes/methods
62/549 55/126

Table 7-2 shows the performance numbers. They're probably a little more
controversial. I'm not trying to show that a Ruby application will always be faster
than a Java application. I'm just showing that in this case, Ruby is fast enough, and
it took almost no time or experience to get to this point.
Table 7-2. Difference in performance between untuned versions of a Java
application after we moved it to Ruby on Rails
Metric
(requests per second)
Java
Spring/Hibernate
Ruby
Rails
User scenario 1 (100 runs)
(no preexisting cache)
71.89 75.59
User scenario 1 (100 runs)
(with preexisting cache)
80.86 174.39
User scenario 2 (100 runs)
(no preexisting cache)
80.86 62.50
User scenario 2 (100 runs)
(with preexisting cache)
88.97 1,785.15

To be clear, in no way is Justin claiming that we've done everything possible to
tune the Java application. The point here is that tuning Rails to this level was

nearly effortless, and tuning the Java examples requires much more skill, time, and
effort. The Ruby version is fast enough to meet requirements, with very little
additional effort.
7.1.4. The Community Response
When Justin published this experience, followed by supporting data across two
blogs,
[*]
the Java community lashed out with surprising vigor. It's ironic, because
Justin was completely honest with his numbers, and he presented performance
numbers only after he was challenged by the community. You probably know that
backlash will be particularly strong around disruptive technologies. In this case, the
backlash may well be justified, because Rails is a credible threat to Java in some
important niches, and it's likely to get stronger quickly. If Rails does happen, a
whole lot of knowledge can get marginalized in a hurry.
[*]
Justin Gehtland, Weblogs for Relevance, LLC (April 2005);
I *heart* rails; Some Numbers at Last.
Look, I'm not saying that this data is scientific, thorough, or even broadly
applicable to other applications. It just reflects our experience, and as such, it is
compelling. It tells me that Rails is productive, is fast enough to get the job done,
generates less code, and is much easier to tune. The data does not prove but
strongly suggests a few other hints as well. Rails could well be much more
productive than Java for a pretty wide class of applications. Rails can handle
sophisticated domains with inheritance and relationships. And Rails is often
enough to get the job done.
Keep an open mind. Judge for yourself.