Slashdot Mirror
Java Meets XP: Two Reviews
The two books are excellent examples of how the book industry organizes and disciplines the often crazy explosion of new tools, approaches, structures and metaphors developed by the software industry. Ant: The Definitive Guide by Jesse Tilly and Eric Burke comes from O'Reilly, the masters of producing missing manuals for open source projects. The other, Java Tools for eXtreme Programming: Mastering Open Source Tools including Ant, JUnit, and Cactus by Richard Hightower and Nicholas Lesiecki was published by John Wiley and Sons. Both provide a clear, example-driven exploration of the tools at hand.
The books are probably driven by the success of Kent Beck's Extreme Programming Explained: Embrace Change , a manifesto that outlined Beck's belief that the best way to develop code was with small teams of programmers and users who constantly reworked the software. His most controversial and attention grabbing notion demanded that the programmers work in pairs sharing one computer, one mouse and one keyboard. The constant interaction forced everyone to actually communicate with each other without sending emails and that, more than anything else, may be responsible for the success of his vision. His book spawned a few others on how programmers can plan to apply his vision.
Meanwhile, on the other side of the buzzword galaxy, the Apache group was quietly creating some of the coolest Java development and deployment tools around. Ant was and still is one of the most revolutionary, even though it was just a simple reworking of the classic UNIX make command. Its creator, James Davidson, grew so frustrated with the shell interface of the make command that he wrote a Java-centric version that moved all of the compilation, compression, and distribution inside one Java process. Now, no one has to wait for another Java Virtual Machine to start up to compile each class file independently.
While Davidson's Ant isn't much different than make at first glance, it's hard to overestimate the power of giving programmers a clever tool with plenty of hooks into the development process. Anyone can write new tasks for Ant, and some clever folks have built great new widgets that do things like enforce style guidelines or grab new code from a CVS tree. The structure of Ant lets the programmer dig deeply into the build process. The organic growth and dynamic flexibility shows how close Java can be to Lisp.
Tilly and Burke do a good job capturing the spirit of the tool. Their book follows O'Reilly's time-tested and market-proven simple-examples technique to illustrate how to use Ant for your projects. The chapters in the first half of the book outline how to use and extend Ant for your project. The strength of the book may be the way the authors casually include practical advice about the bugs and idiosyncracies of the tool. While Ant is quite capable, there are a number of little limitations to the XML parser that can drive new users a bit nuts. The second half of the book is a detailed description of the API, the data types and the other practical documentation.
In one sense, it's not really fair to lump this book in with all of this gloss about Extreme Programming. because it's just another methodical O'Reilly book with Dover artwork on the cover. It's important to realize that these tools aren't directly tied to the extreme programming movement. Ant was just created by a Java programmer who hated to wait. Everything else came afterwards when he opened the API.
Ant: The Definitive Guide author Jesse Tilly & Eric M. Burke pages 260 publisher O'Reilly rating 7 ISBN 0-597-00184-3 summary A methodical, in-depth look at the Java tool.
The other book, however, explicitly illustrates how some popular open source tools can help the process of extreme programming. Hightower and Lesiecki's book is much broader than Tilly and Burke's because they want to tackle so much more. They don't want to just provide a missing manual for the tool-- they want to give the world a road map on how they use Ant and its cousins JUnit, HTTPUnit, and Cactus to build better applications. It should be noted that Hightower and Lesiecki work for a consulting group called eBlox and a number of other eBlox programmers are listed as contributors to the book. I think it's fair to say that anyone who hires eBlox will get eXtreme Programming results built with this methodology.
The best part about this book is the wide scope. Ant remains the central taskmaster responsible for building the software, but the book explains how to incorporate other tools for testing the software. The authors embrace one of the extreme programming central beliefs that programmers should define how to test their code before it is actually written. The book explains how to use JUnit, Cactus, and HTTPUnit to set up rules to test every class file. After ANT fires up the compiler, it turns around and runs the tests on the code.
Java Tools for eXtreme Programming author Richard Hightower and Nicholas Lesiecki pages 513 publisher John Wiley and Sons rating 7 ISBN 0-471-20708-X summary How to use some Java tools to transform extreme programming theory into reality.
I don't think that eXtreme Programming or any of these tools is the last word on the subject. The biggest problem is that testing a piece of code is guaranteed to be fairly rudimentary. No programmer can come up with test cases to push all of buttons in all possible combinations. The structure and discipline provided by this approach can help, but the book makes it clear that no amount of pairs programming or extremism will remove the need for the guidance of good programmers.
If anything these tools and the books about them should serve as inspiration for the next round of tools even more focused on extreme programming. The tools are impressive, but there is plenty of room for more innovation. None of them is aimed at explicitly coordinating the work of multiple developers and none of them is designed to provide much structure to the refactoring process. These areas are still very much arts, but there's no reason why tool suites like Ant can't evolve some rational approach to solving them. Perhaps the Slashdot audience can provide some informative postings with pointers to the next generation of cool tools.
Hightower and Lesiecki's book feels a bit more rudimentary and basic than Tilly and Burke's, in part because they cover so much more ground. Although their book is broader, it doesn't go into as much depth about Ant as Tilly and Burke's. The examples are simpler, too, and Hightower and Liesiecki seem mainly interested in getting you excited about building and testing software with the tools. There just isn't as much room for details. If you're interested in learning as much as you can about Ant, choose the book devoted to it. If you want to learn how to use a diverse set of tools to build and test your program in an extreme way, go for that book.
Peter Wayner blends the buzzwords of security, privacy, and data warehousing together in his latest book, Translucent Databases. It shows how to ensure that only the right people see the right information and the wrong people get nothing. His other new book, Disappearing Cryptography, mixes the buzzwords of being, nothingness, steganography, and cryptography. You can purchase both Ant: The Definitive Guide and Java Tools for eXtreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.
When reading about XP, I see a lot of mentions of Ant, XUnit, and cactus, but not much mention of Cruise Control. It builds upon Ant to allow continuous integration, one of the important piece of XP that should and can be automated.
So I noticed the links at the bottom have a sourceid parameter in them which as I recall, is bn.com's affiliate system. Am I wrong or is this just a blatant cash grab?
Maybe the slashdot editors could pick up the clue stick on this one?
I am not a number! I am a man! And don't you
Some more information about Java Tools For Extreme Programming can be found on this earlier review of
[alk]
XP fans have been calling our practice XP since long before the latest version of Windows was released. You seem to think we should compensate for Microsoft's lack of foresight? Oh, I see, you think we should just roll over and get a new acronym everytime Microsoft makes a new release. I'm sure you no longer use the word "ME" do you?
Java and XP are a natural combination anyway, since a lot of the emphasis of XP is to fixing crappy code. Since lots of Java code is written by your standard junior-to-mid-level Java programmer (usually an ex-VB or ex-ASP flunkie), it usually needs a lot of re-writing (oops, "refactoring"!).
That being said, I don't see how a build tool is related to a programming methodology. Is it because it has a fairly standard JUnit task? You could easily get make to do that.
Besides, reading a book now about Ant is foolish, because (hope, hope) Ant 2 will be available soon, which hopefully fixes Ant's more egregious kludges and bugs.
I agree that naming it extreme programming might not have been the best choice considering the images it conjurs up(picture Mountain Dew commercials with "narly d00ds" snowboarding yelling "Get Vertical!")
BUT, that being said the XP name came from the fact that everything is done to the extreme. If testing is good then test everything. If integration helps find problems then integrate continuously. etc, etc.
I say to any developer - take a look at XP. It's simply a set of industry proven techniques done to the extreme. It does work and even if you don't use everything you can still bring good practices to your coding from it. You don't have to accept any cult, take the red pill, or claim allegiance to xenu to take advantage of good techniques. If you don't like them or find they don't work then say so, but don't judge a book by it's cover (for lack of a more fitting cliche).
The Extreme Programming movement came largely from the Smalltalk community, right about the time that community faced up to the face that VB and Java had pretty much cornered their former market. Java may have syntax like C++, but its semantics are surprisingly close to Smalltalk's; the migration started long ago. Most Extreme Programming projects (and books) are Java-based these days. (This crowd's second most common language is probably Ruby.)
Stupid job ads, weird spam, occasional insight at
I think you just made my point for me better than anything I've written on this thread. By your own admission, relying purely on the passing of automated tests cannot be a sufficient guarantee that your code is not crappy, which was my original contention.
I think perhaps I'm giving the wrong impression here. I do not think unit testing is bad; on the contrary, I religiously write and perform unit tests for every piece of code I create. I also prefer to have automated unit tests if the opportunity arises. My objection is to the claim that passing such unit tests -- one of the central aims of an XP approach -- is sufficient to ensure that your code is good, and reduces the need for skilled developers. My arguments are that (a) passing unit tests does not give any indication of maintainability, and (b) passing all the unit tests, while a good confidence builder, is not an absolute guarantee that requirements have been met and no bugs are lurking.
Not necessarily. If you are writing all of the code concerned, and you have control over the modularity, interfaces, etc, then yes. But much real world software development does not fall into this tidy pattern. If you have to deal with external influences, whether hardware or software, and particularly if someone else defines the interfaces (but may not keep to them perfectly themselves), then you may not be able to automate testing at all.
On the contrary. Several people have gone back and, quite independent of me, added to my original code. It was designed to be extensible, that design and the intent behind it were documented enough for people to find their way around, and they went and coded. Then they, too, ran walkthroughs on their new bits of code and unit tests of the various options, and their code, like mine, has run without reported bugs ever since.
Under the XP alternative, it's certainly true that anyone could come along, change my code and find out immediately if they'd screwed up. Whether or not they could successfully change the code and produce a new version that solved the problem is quite a different question.
One thing a clear and well-documented design is excellent for is reducing your dependence on the guy who originally wrote the code. OTOH, how does a new guy on the project who wasn't in your original development pair learn his way around? (I'm not saying it can't be done, just that it might be harder without a clearly documented overall design.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.