Java Tools for Extreme Programming by Richard Hightower, Nicholas Lesiecki

[Book Review Team]

<pre>Author/s : Richard Hightower, Nicholas Lesiecki
Publisher : Wiley
Category : Advanced Java
Review by : Frank Carver
Rating : 9 horseshoes</pre>
You can happily ignore the main title of this book. Sure there's a nod toward extreme programming, but that's not what this book is
really all about. This book is a fine introduction to a whole bunch of really useful tools to boost your Java and especially J2EE programming. And all the tools can be downloaded, source code and all, for free! There are too many tools to list here, but they include the best-of-breed Ant build system, JUnit, HTTPUnit, ServletUnit and Cactus test frameworks, load and performance analysers and some great libraries for interacting with other servers.
Two major test cases are carried through the book to show the benefits of each approach. Each tool covered gets at least a chapter of tutorial, and some of the major ones also get an appendix of API and configuration information.
This book was almost too useful to review. It's been open on my desk from almost the minute I got it and has greatly improved many aspects of my development process. If you want to get up to speed quickly and practically on a load of useful, powerful, tools - get this book.
Everyone I've shown it to has wanted their own copy ...
More info at Amazon.com
More info at Amazon.co.uk
More info at FatBrain.com

[Rick Hightower]

(This post written by Co-Author of Book)
Thanks for the review. It is good to get the exposure for the book. Of all the books on the market, thank you for picking this one to review.


A small comment...


I agree with Frank that the book is for more than just developers that are doing XP (XPers). I state this several times in the book. However, I�d like to add...


If you are following the XP development process and you are doing J2EE development, then you especially need the tools described in this book. This is because XP relies heavily on automated testing, and continuous integration. JUnit, which is heavily covered in this book, was designed and co-created by the father of the XP process�Kent Beck.


Here is what one J2EE XP developer wrote about the book...


"I have been struggling with turning XP methodology into a solid development process. We've had some success at my company but most times we've met frustrations primarily because we were trying to teach old tools new tricks."


"Rick Hightower's java Tools for XP has made a big difference for us. My team has been able to use the tools described in this book to actually DO unit testing, and we've already automated a significant portion of our testing and deployment processes. Its also let us make a good case for open source tools at my company."


"Overall I definitely recommend this book as the first book to make XP real."


I receive a lot of email that states similar things. If you are doing XP and Java (especially J2EE), then the tools described in this book are essential.


Thanks again.



--Rick Hightower

[Johannes de Jong]

Thanks for taking the time to repond to the review Rick.

[Brian C Robinson]

Just wanted to mention that this book relies heavily on the reader's knowledge of J2EE. I am mainly a C++ developer but I do occasional applications development with Java. This didn't prepare me at all for the J2EE elements of this book.
It's certainly a good book but I wish I had known what assumptions they had about their readers before buying it.

[Rick Hightower]

Brian C. Robinson,
I agree with what you are saying. Thanks for the feedback. We need to improve the order in the next edition, or be more clear about the chapter content. Basically, if you are doing J2EE and XP, then you are the perfect match for this book.
If you are doing Java and XP, parts of the book do not apply to you. I think it is still very useful whether you do J2EE or not.
If you are doing J2EE, read it all.
If you are not doing J2EE follow the instructions, this will save you time.
Chapter guide for non-J2EE folks.
Introduction. Read
PART I: INTRODUCTION AND KEY CONCEPTS.
1) Introduction to Extreme Programming. Read
2) J2EE Deployment Concepts. Read First Half, Skip second half
3) Example Applications. Read First Half, Skip second half
PART II: MASTERING THE TOOLS.
4) Continuous Integration with Ant. Read chapter, skip case study
5) Building Java Applications with Ant. Read chapter, skip case study
6) Building J2EE Applications with Ant. Skip
7) Unit Testing with JUnit. Read chapter, skip case study
8) Testing Container Services with Cactus. Skip
9) Functional Testing with HttpUnit. Skip
10) Measuring Application Performance with JMeter. Skip
11) Load Testing with JUnitPerf. Read chapter, skip case study

PART III: API AND TAG REFERENCE.
Ant Tag Reference. Use
Ant API Reference. Use
JUnit API Reference. Use
Cactus API Reference. Skip
HttpUnit API Reference. Skip
The tools are useful wheter you are doing XP or not.

[Rick Salsa]

Hi Rick,
I have to say that I absolutely love your book!! Although I'm not all that familiar with J2EE the concepts presented throughout the book are very helpful. If you understand a little bit of J2EE or even the concepts, I think that you can follow on.
So what's up for you next? I heard that you might be working on more Open Source type books is that true?
Thanks again for developing such a useful reference. It combined everything that I wanted to learn in one easy to follow book.
/rick

[Heidi-Marie]

This book was given to me as a present. My friend loved it so much he ended up buying it me and probably a few other people. I am relatively new to Java, I've written a chat server but nothing else before and certainly no J2EE. I started off as a C++ programmer then did a little Pearl then PHP and now I'm really enjoying Java and all the new technologies that make it such a joy. This book gives a good brief introduction to extreme programming, I work from home so I don't get to pair program but found these ideas interesting and useful. The book explains the benefits of the technologies/tools it describes (JUnit, Cactus, Ant, HTTPUnit, etc) and explains how to use them in an easy to understand manner and gives some good examples. I feel so much happier now when I commit my code to CVS having written tests to ensure all is good. Using Ant to do all the hard work for you is just amazing!
The code examples in the book can all be download from Rick's website and when ever I have emailed Rick and Nicholas with any questions they have sent me very helpful replies.
I have to say this has been one of the best presents I have recieved! This book has helped to make my programming much easier, quicker and solid. Most of the ideas in the book are common sense and you end up wondering why you never did these things before!
Heidi

[Rick Hightower]

Heidi said:

The book explains the benefits of the technologies/tools it describes (JUnit, Cactus, Ant, HTTPUnit, etc) and explains how to use them in an easy to understand manner and gives some good examples. I feel so much happier now when I commit my code to CVS having written tests to ensure all is good.
Using Ant to do all the hard work for you is just amazing! The code examples in the book can all be download from Rick's website and when ever I have emailed Rick and Nicholas with any questions they have sent me very helpful replies.

Yes. I felt the same way when I started using Ant and JUnit together. These are great tools for automating mundane things. I get a rush when my JUnit tests pass! Automated testing and continuous integration are key to XP development.

I have to say this has been one of the best presents I have received!

[BLUSH] Thanks.

This book has helped to make my programming much easier, quicker and solid. Most of the ideas in the book are common sense and you end up wondering why you never did these things before!

I think most good ideas seem like common sense. XP is no different. It just organizes all of the good ideas in one place. The XP tool chest is useful for non-XPers.
I am glad you wrote this review. I think it shows that although the book is ideal for J2EE/XP developers that all folks doing Java will get value out of this book.
The tools presented in this book are really useful. I would not want to do Java/J2EE development without the tools described in this book.
I never knew when we were writing this book that it would be the #1 Software Development book on Amazon for several weeks (under the category Books > Subjects > Computers & Internet > Programming > Software Design > Software Development�more than 2000 books in this category), it would make it to the #1 book for John Wiley (for one day) on www.bookpool.com, and make it as high as the #3 Java development book on Amazon out of 2000+ books.
Nick and I are floored by the success of this book and how well it has been received. I think the book really fit a need in the market. We get emails about the book daily. The feedback has been really positive.
I think XP makes sense for a lot of organizations, and I hope this book will introduce key XP concepts into many organizations that would not otherwise be interested in XP per se, but who want to automated their build and provide automated testing.
[ February 27, 2002: Message edited by: Rick Hightower ]

[Rick Hightower]

I have to say that I absolutely love your book!!

Oh stop! [BLUSH] Thanks!

Although I'm not all that familiar with J2EE the concepts presented throughout the book are very helpful. If you understand a little bit of J2EE or even the concepts, I think that you can follow on.

Thanks. I feel the tools are especially helpful if you are doing J2EE development due to all of the deployment descriptors and archive files (jar, EJB jar, war, ear, etc.). The build process for the above just beg to be automated. And, you need a way to test J2EE application, which this book covers well (my bias opinion).
However, you can also get a lot of mileage from these tools if you are not doing J2EE. I think Java developers who don't do J2EE would get a lot of use out of this book.

[Johannes de Jong]

Heidi-Marie thanks for your comments on the book, we really appreciate the feedback from our visitors on the books the have read
However we do have a naming policy. If you wish to keep on using our site pse change your publicly displayed name
name. Thanks.

[David Benjamin]

I really enjoyed this book. The title is a bit unfortunate, as while it
summarizes XP development concepts, its not the main focus of the book.
Perhaps a better title would be "Integrating & Automating Multi-Component
Software Project Building & Testing using Ant, JUnit, Cactus, etc." but
this is a bit hard to fit on the spine of the book.
What has made "Java Tools for XP" very useful for our project is that it
presents via clear example, a couple of "fer instance" cases of using
ant to build projects with various flavor components (libraries, web apps,
EJB) and how to wrap in testing via junit.
The documentation for the tools used, Ant & JUnit is easily available for
free on the web. While you can have a long passionate discussion on the
quality of the documentation, its pretty good, and its enough.
Most developers go about adopting Ant & JUnit by doing the following:
- reading the tool documentation
- having a play around with it
- taking a look at how some well-respected open software packages use it
- having another play
- roughly imitating the way the well-respected open software package used it
but with some clever improvements and ugly hacks.
- trying to explain what they did to the other developers, but usually
just saying "um, just like they did in well-respected open software package"
While we are still doing a bit of this, this book allows us a more reliable
resource to get all the developers thinking along the same lines.
From a development management standpoint, this has eliminated (or at least
focussed) about a hundred water-cooler discussions about how to go about
putting together the build & test system. And for the meeker developers,
it gives them a quick tutorial on what the hell everyone else is
jabbering on about.

[Rick Hightower]

Thanks for the excellent review. I enjoy your comments!

I really enjoyed this book. The title is a bit unfortunate, as while it
summarizes XP development concepts, its not the main focus of the book.

I think is based on your perspecitve of XP. I find that you would have a hard time doing XP without this tools described in this book. The main target audience of the book is for people who want to do XP with J2EE and Java.
Do you work in an XP shop?
What do you think about XP?
The book was not meant to replace Kent Beck's book(s). It was meant to supplement his stuff with real life code examples for Java and J2EE development.
Also, since the tools described in the book are good for other forms of development, the book is a good intro to XP to people who are not familiar with it.

Perhaps a better title would be "Integrating & Automating Multi-Component
Software Project Building & Testing using Ant, JUnit, Cactus, etc." but
this is a bit hard to fit on the spine of the book.

I tried to get the title "Applying XP to J2EE" but everyone vetoed it. The title is meant to invoke interest from XPer and non-XPers because the book can be used by both, but its primary audience (the people who would get the most out of it) are XPers. I like your idea though since it shows the book is really applicable to non-XPer. Since I work in an XP shop, my perspective might be different than yours.

[Rick Hightower]

If you decide to comment on the book, can you state what your party affiliation is..., i.e., XPer or not.
If you are not an XPer, can you state the likely hood of looking into XP after reading this book.
I am just curious.
BTW This post stuff needs a spell checker. Its making me look bad!

[Rick Hightower]

From a development management standpoint, this has eliminated (or at least
focussed) about a hundred water-cooler discussions about how to go about
putting together the build & test system. And for the meeker developers,
it gives them a quick tutorial on what the hell everyone else is
jabbering on about.

Can you define what a meeker developer is?
Is this an averagely motivated developer?
I am just curious.

[Ravi Veera]

If you decide to comment on the book, can you state what your party affiliation is..., i.e., XPer or not.
If you are not an XPer, can you state the likely hood of looking into XP after reading this book.
I am just curious.
BTW This post stuff needs a spell checker. Its making me look bad!

I have been developing/deploying code for a few years, well before XP entered the jargon. I like your book as it describes the tools well without getting into the *preach* mode most XP/XPer's books get into. The XP methodology would be better served if there are more books like the one you have written.
I have no problem with XP itself although I wouldn't call myself an XPer. It has provided good tools to the developers. It is a good methodolgy and works reasonably well under most circumstances.
Most XPer's I have dealt with seem to equate it with a religon. It's like, "Thou shalt use this eXtremly Painful methodology or you will burn in hell" or something like that.
Also I have seen XP is used as an excuse to do away with the design process. True,it's not necessary to spend years in design and it's also true that requirements do change. But a good design gives you a focus and direction which is invaluable.

[Rick Hightower]

Ravi Wrote

I have been developing/deploying code for a few years, well before XP entered the jargon. I like your book as it describes the tools well without getting into the *preach* mode most XP/XPer's books get into. The XP methodology would be better served if there are more books like the one you have written.

Thanks. I hear this a lot. I really appreciate it.

When I came up with the outline for the book my idea was to start where many of the other books on XP let off. Most of those books focus on why, or why it is better... I wanted to focus on how to do the developer mechanics of XP--the details of XP.
Most books on XP are focused on theory and methodology. I wanted to write a book on the practical application in a Java Enterprise Environment.
XP is extremely popular! And I am a big fan of the "why" XP books. I am the biggest fan of the first book by Kent Beck (the white one) and, the XP planning book by Kent Beck and Martin Fowler (the dark green one).
This book focuses on using Open Source Software tools to apply XP technology to Enterprise Java development. It mainly encompasses automating the build & integration process, and automating the testing process.
Essentially this book is a cookbook on how to implement XP methodology in an Enterprise Java shop with real world case studies.
XP is the methodology, i.e., the philosophy. Ant, JUnit, etc., help developers realize the XP philosophy. The book is centered on Junit and Ant. It covers a lot of Junits spawns, i.e., HttpUnit, JUnitPerf, Cactus, etc.
XP is a lot more than testing and integration & build tools, but testing and integration tools is a key way XP materializes in the development process.
Off the top of my head XP is about:
* Involving the customer.
* Pair programming.
* Short Iterations.
* Constant Feedback.
* Code centricprocess.
* Unit testing with automated tests.
* Integrating often.
* and much more.
Ant helps because it automates the integration and testing through build control. JUnit et al help with the automatic testing.
It is good to make the testing part of the build. With the JUnit and Ant combo you can do this. Ant and JUnit et al are the "physical tools" that you would use in an XP process.
Of course you do not have to be an XPer to enjoy automatic tesing and continous integration.
The book does not for example cover in detail:
* Involving the customer.
* Pair-programming.
* Code centric process.
Many XP books do this already. As you pointed out, the book is not a "me too" XP book.
The book does cover the following in detail:
* Unit testing with automated tests.
* Integrating often by automating the
integration and build process.
Thanks again for your compliments.

[Ilja Preuss]

Originally posted by Ravi Veeraghanta:

True,it's not necessary to spend years in design [...].

Interestingly, the XP view is quite the opposite: you should *never* stop designing. That is why most of it is not done up front in its own phase, but incorporated into the whole development process.
See http://martinfowler.com/articles/designDead.html

But a good design gives you a focus and direction which is invaluable.

Focus is given in XP by the "System Methapher" and the Release Plan and Iteration Plans, combined with frequent releases.
BTW, to get back on topic - there is another book review at http://www.xprogramming.com/xpmag/books20020203.htm#book047120708x
Regards, Ilja
[ March 12, 2002: Message edited by: Ilja Preuss ]

[Nicholas Lesiecki]

Hi Ravi,
You said:

Most XPer's I have dealt with seem to equate it with a religon. It's like, "Thou shalt use this eXtremly Painful methodology or you will burn in hell" or something like that.

I agree that XP practitioners can be somewhat preachy. On the other hand, a lot of the time they have to contend with a prejudice that XP is hard, painful, or just doesn't make "sense". A lot of XP is counter-intuitive (at first), or easily misinterpreted, and it certainly does not have the "Big Iron" feel of say something with a name like The Unified Software Development Process (insert scary reverb here.) So some XP people see their job as “selling” XP to a cold audience. this is probably less true today than a few years ago, but the perception lingers.
Also, XP takes a lot of energy and focus on the part of team-leaders and even programmers. To quote from something I read recently in Extreme Programming Examined: "Developing at this pace is exciting, but it can be exhausting." So XP requires that people be excited about it, and willing to overcome the challenges posed by doing it right. It's a lot easier to have no process, you're just not as likely to succeed.
So while I don't excuse fanaticism about what is essentially a very reasonable process, I think some of XP's "over-enthusiasm" is the product of loving a process that requires excitement.
Cheers,
Nicholas Lesiecki
(Oh and to answer Rick's question--I am an XPer )

[Ravi Veera]

So some XP people see their job as “selling” XP to a cold audience.

I have been using various elements of XP with a decent amount of success.
My 2 bits if you want to sell XP to an organisation/group of people.
-Introduce tools like Ant/make,Junit,Cactus. Developers like tools that make their job easier. It's also easier to get a buy-in when you can demonstrate something concrete and get immediate results.
-Remember most organisations/people do not "embrace change" easily so don't go in and try to demolish existing practices.
-When you are suggesting a new tool/new approach list out all the practical benefits that can be obtained. Do not say it worked in xyz co., or that this is the latest way things are done.
-Some aspects of XP may be counter-intutive but people do see reason. Be patient and ask people to give it a try for a small amount of time.
-And remember XP is only a methodology. It's not an end but a means to an end.
cheers,

[Rick Hightower]

Reviews

Review from JavaPro

"This book is the first of its kind, covering topics that haven't been explored this directly anywhere. It does a remarkable job, covering not just the tools but the philosophy behind good unit tests and frequent, automated builds...." ... ... "The philosophy behind this material is modern and forward thinking. ... (The book has the ) potential to make you a better programmer and better able to deliver higher-quality code on a shorter timeline. "

--Claude Duguay
Check out the full review at

full review from JavaPro


Review from JavaRanch

"...This book is a fine introduction to a whole bunch of really useful tools to boost your Java and especially J2EE programming.... This book was almost too useful to review. ... If you want to get up to speed quickly and practically on a load of useful, powerful, tools - get this book. Everyone I've shown it to has wanted their own copy ... "

--Frank Carver
Check out the full review at full review at JavaRanch
This review became book review of the month!

XProgramming.com

"This book should appeal to XPers and non-XPers alike who recognize that automated testing and continuous integration are good things for any project." ... ... "The book is a good introduction for the uninitiated and a valuable reference for those plying their trade with these tools. Don't miss an opportunity to easily automate your Java project and spend more time delivering business value!"

--Mike Clark
Check out the full review at
full review at XProgramming.com

---------------------------------
Book Description
The book contains small examples and tutorials on each tool. The examples cover building, deploying, and testing Java and J2EE applications.
In addition to small examples, there are larger case studies. The case studies are larger more realistic examples. We have case studies involving XSLT, EJB, Struts, JDBC, etc.
Each case study is complete with an ant build script and several tests, written with JUnit, HttpUnit, Cactus, JUnitPerf and/or JMeter. The case studies focus on building, deploying and testing J2EE applications with Ant and JUnit.
There is also a reference section for APIs. Instead of rehashing the API documentation, the reference section has example usage, i.e., code examples for the important classes and methods.
Although this book speaks from an XP perspective, you need not practice XP to benefit from it. For example, you do not have to adopt the entire XP methodology to get value out of this book. Automated testing, for example, can help you refactor code regardless of whether you are doing pair programming or not. Continuous integration can help you detect and fix problems early in the lifecycle of the system regardless of whether your customer is on site or not.

[Ilja Preuss]

Originally posted by Ravi Veeraghanta:

-Introduce tools like Ant/make,Junit,Cactus. Developers like tools that make their job easier. It's also easier to get a buy-in when you can demonstrate something concrete and get immediate
results.

I also had great success introducing a refactoring browser to a co-worker while pairing on a hard, mission critical task.

-Remember most organisations/people do not "embrace change" easily so don't go in and try to demolish existing practices.

As Ron Jeffries puts it: XP can't be introduced-to, but only choosen-by a team.

-When you are suggesting a new tool/new approach list out all the practical benefits that can be obtained. Do not say it worked in xyz co., or that this is the latest way things are done.

Additionally, point out potential problems. Find examples of when it did *not* work, try to find out why and how this could influence your use of it.

-Some aspects of XP may be counter-intutive but people do see reason. Be patient and ask people to give it a try for a small amount of time.

Make sure they do expect to need some learning time before the advantages of the new working style get visible.

-And remember XP is only a methodology. It's not an end but a means to an end.
cheers,

In fact, XP is only a starting point. Its purpose is to get a grip on the "agile philosophy", to learn a bunch of new practices to add to your bag of tricks and to finally don't care anymore wether you are doing XP or not.
Regards, Ilja
(If there is interest in it, we should probably move this subthread to the process forum...)
[ March 14, 2002: Message edited by: Ilja Preuss ]