O''''Reilly Network For Information About''''s Book part 1 ppt

Comments and Questions
Please address comments and questions concerning this book to the publisher:
O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
(800) 998-9938 (in the United States or Canada)
(707) 829-0515 (international/local)
(707) 829-0104 (fax)
There is a web page for this book, which lists errata, examples, or any additional
information. You can access this page at:

To comment or ask technical questions about this book, send email to:

For information about books, conferences, Resource Centers, and the O'Reilly
Network, see the O'Reilly web site at:






Safari® Enabled
When you see a Safari® Enabled icon on the cover of your favorite
technology book, it means the book is available online through the O'Reilly
Network Safari Bookshel
f.
Safari offers a solution that's better than e-books. It's a virtual library that lets you

easily search thousands of top technology books, cut and paste code samples,
download chapters, and find quick answers when you need the most accurate,
current information. Try it for free at .





Acknowledgments
This book challenged me more than any other book I've written. I felt that I needed
to bolster my opinions with those of other respected programmers and consultants.
I asked for many opinions, and published some of the responses. Thanks to Mike
Clark, Matt Raible, Andrew Hunt, Ramnivas Laddad, Brett McLaughlin, and Eitan
Suez for answering my questions. Thanks especially to Glenn Vanderburg, Ted
Neward, Erik Hatcher, Justin Gehtland, James Duncan Davidson, Jim Weirich,
Jamis Buck, David Heinemeier Hansson, Dion Almaer, Jason Hunter, Richard
Monson-Haefel, Stuart Halloway, and Dennis Sosnoski for agreeing to let me post
your interviews in the book. Thanks again to Justin Gehtland for use of your
metrics, and being a partner through two writing projects.
Special thanks go to David Heinemeier Hansson for access to your framework and
community from the inside. When I needed reviewers, you used your influence to
find them for me. When I had hard questions, you answered them. You also
provide the irresistible force that is Ruby on Rails. I'm grateful. I hope this book
marks only the beginning of a partnership, and a possible friendship.
Dave Thomas, you have given me the courage and faith to explore things beyond
Java. You've been a role model for me. Your consistent honor and class teach me;
your skill with your keyboard and your voice inspire me; your business sense
instructs me. Avi Bryant, thanks for your tireless work and promotion on the
Seaside framework.
Special thanks also go out to Michael Loukides. Supporting me is your job, but I

also feel a special kinship. We've been through a lot together, and I aim for that
relationship to continue. You've been very good for me and my writing career. I
hope you've benefited in some small way, too.
After letting my readers down by publishing Spring, A Developer's Notebook
before it was ready, I feel the
need to offer some thanks for helping me through the
negative press. O'Reilly, you were great to stand behind me. I felt that I needed to
have this book reviewed exhaustively, to prevent the same mistake from happening
twice. Many answered the call. Ted Neward, Venkat Subramaniam, Michael
Koziarski, Jeremy Kemper, Michael Loukides (who gave me advice and ideas far
beyond the usual editorial support), and many others too numerous to list here
provided good reviews.
Invariably, some reviewers take on a book as a personal mission. Usually, a book
is lucky to have one such reviewer. This time, I had four. Steve Yegge, Jason
Hunter, David Rupp, and Curt Hibbs all went far beyond the call of duty. They
provided help that was stylistic, philosophical, technical, and even structural. This
book is radically different from my initial vision. Thanks to all who contributed.
To Jay Zimmerman and all of those I've met at NoFluffJustStuff, this book is as
much yours as it is mine. You've helped me shape and sharpen these ideas, and
you've given me a platform to present them.
Most of all, I've got to recognize the contributions of one special lady in my life.
She propped me up when I was too low to write, she talked through many of the
ideas, she sat through many boring dinners as I talked through this stuff with
anyone who would listen. Her smile fills my soul with the passion that I need for
writing, and gives me a reason to be. We share a common purpose in raising our
daughters, Kayla and Julia, a common foundation of faith in Jesus Christ, an
unending hospitality for weary colleagues on the road, and a sense of adventure in
life. Without you, I'm nothing. With you, I feel like I matter, and my ideas matter.
You're a bigger part of this book than you'll ever know. I love you always.

1.1. Ignorance as a Virtue
In many ways, k
ayaking is like programming. I've learned an incredible trick. I can
be surprisingly productive by simply ignoring most problems. With a little luck,
the problems often just go away. Such an attitude can work for you or against you.
Many post office clerks and minimum-wage fast food employees have learned that
the same technique actually works for their problems, also known as customers.
These are ostriches. If you look closely, you can find some selective, wise
application of ignorancethe owl's trademark. I actually find that most "problems"
in programming are merely potential problems. If you've read any of my books,
you know that I preach against the dangers of premature optimization, and echo the
popular agile principle of YAGNI : "You ain't gonna need it." I usually ignore
bloated frameworks that promise to save me time, trusting my instincts to simpler
solutions.
More to the point, I've found that Java does everything that I need, so I haven't
looked beyond these borders for a very long time. Ignorance is bliss. I know some
languages are more dynamic, and possibly more productive in spurts, but in the
end, it seems like Java will always win. It's got tens of thousands of frameworks to
do anything from running systems for nuclear reactors to programming an
embedded controller on a power toenail clipper. Many of the best frameworks are
even free. I can always find a Java developer to do what I need. I know that people
have made it work to solve massive problems. And I know that my customers will
feel safe and secure. In short, the community and breadth of Java have always
trumped anything that the alternatives have to offer. So I quit looking. And I'm
glad that I did, because it allowed me to focus on building a consulting business
and satisfying my customers instead of doing exhausting research for every new
problem.

When a dominant language or technology is in its prime, there's a blissful
ignorance stage, when ignoring alternatives works in your favor. Figure 1-1 shows
what I mean. When a new language arrives with the power and dominance of a
Java or C++, you can afford to ignore alternatives for a while. But if you don't
accurately identify the end of the cycle, you can get steamrolled. Suddenly, your
competition has the jump on you, with much better productivity leading to better
quality, improved productivity, and more customers. When you enter the transition
time, you'd better start paying attention.
I admit unashamedly that I liked having my head in the sand. It was easy, and
productive, and politically safe. I bet that many of you Java developers act like me.
You may have your own reasons. Living in this shelter is certainly easierdoing
nothing trumps extra work. You might feel saferno one ever got fired for choosing
IBM. (OK, so maybe Component Broker on
Figure 1-1. For a period of time, ignorance is productive, but the ending of that
period can be unpredictable

OS/2 was not such a good idea ) You may have an incredible investment in skills
that you believe will not commute, and if you've invested poorly in your skill set,
you may be right. You may be bound like a Siamese twin to Java by a long-term
project or a group based on the language. Like my reasons, many of these are
sound.
1.1.1. Shaken to the Core
After living in blissful ignorance for five years or more, I had an experience that
shook me to the core. I led a new start-up down a path that required what I'd
consider three of the most productive lightweight frameworks out there for web
development of persistence applications: Hibernate, Spring, and Web Work. I
knew there were slightly more productive environments for this kind of thing, but
they either would not scale (in terms of complexity or performance), or were not
popular enough to justify the risk.
My partner and I decided to implement a small part of the application in Ruby on

Rails, a highly productive web-based programming framework. We did this not to
satisfy our customer, but to satisfy a little intellectual curiosity. The results
astounded us:
 For the rewrite, we programmed faster. Much faster. It took Justin, my lead
programmer, four nights to build what it had taken four months to build in
Java. We estimated that we were between 5 and 10 times more productive.
 We generated one-fourth the lines of code; one-fifth if you consider
configuration files.
 The productivity gains held up after we moved beyond the rewrite.
 The Ruby on Rails version of the application performed faster. This is
probably not true of all possible use cases, but for our application, the RoR
active record persistence strategy trumped Hibernate's Object Relational
Mapping (ORM) , at least with minimal tuning.
 The customer cared much more about productivity than being on a safe Java
foundation.
As you can well imagine, this shook my world view down to the foundation. I'm
now frantically trying to catch up. It seems that conditions on the river changed
without my noticing. I've got to start scouting again.