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.
It's more like 2 quater reviews than "two reviews in one". Not even a table of contents? Jesus! Especially since the books have exactly zero to do with each other.
IMHO, Anyone who needs book to figure out Ant should be shot.
I am not a number! I am a man! And don't you
It's important not to lose sight of this in all the troll^H^H^H^H^H enlightened debate about XP that will surely accompany this review. We used Ant for a number of large Java development projects and we were not an XP shop by any stretch. As the reviewer says, Ant really shines when you start making use of various extensions. In our case, we were able to wrap most of the software release process (synching from Perforce, rebuilding and packaging the code, and uploading the distribution to an ftp site) within a collection of Ant tasks.
Is it just me, or does anyone else get irritated hearing the new idiot buzzwords that come out every week? (Such as eXtreme Programmming?)
Some of us are hard working, college educated computing professionals, not dim-witted adolescents with the urge to jump off of a cliff without a parachute. We need to take our field or work back from every idiot that can put the three brain cells together required to write a stupid book, or to introduce a brand new moronic buzzword.
(Ok, I'll get off my soapbox, you can now mod me to -1000 loser-troll-flame-bait)
I dont understand why people give two different things (Extreme Programming...whatever the hell that is) and (windows) XP the same name. Perhaps EP would be better for the former?
Then again, perhaps I`m a little old for it...I certainly dislike the way everything is being spelt phonetically now...Lyke weer all Stupidue phucking hip-hop fann boyz now or sum`thin`...
You assume that it is the reviewer's affiliate number. Perhaps you assume too much. Remember, /. has been looking for new revenue streams. Perhaps they have the cluestick firmly in hand. If that's the case, it's a fairly innocuous revenue hook. I don't mind it much.
Light cup, beer drink, thin so chain, neck turtle fat, man I won't say it again
Extreme Programming consists of a lot of distinct ideas including: small teams, two people per keyboard, unit testing, and refactoring.
The most useful of these ideas to me is refactoring. (probably followed closely by unit testing) Refactoring starts with the humble admission that at the start of most software projects, you really don't know exactly what the final product will look like. This implies that the design of the project will change during development. Refactoring is a set of techniques that allows the design of a program to change without making a mess of the code.
If you are interested in Java and Refactoring, you really owe it to yourself to check out Refactoring by Martin Fowler. He has come up with a very well written book in the format of Design Patterns that does a good job of enumerating and explaining many refactoring techniques.
I've used Ant, and concluded that it's only strength is that it comes with a bunch of modules ready-to-use. (Never mind that most of those modules would be five lines in a more modular, flexible system like make.) Further, in several respects, it has several serious regressions compared to other build systems. In light of this, it seems to me that the main reason Ant is popular is that it attempts to cover for the deficiencies of common Java compilers. What a mess!
The first regression is that Ant (by default) doesn't do reliable rebuilds. The most basic function of a build system is to produce correct output, and Ant doesn't do it! Its default algorithm for rebuilding is to compile only those source files that are newer than their corresponding class files. So, for example, if you change an interface, Ant won't recompile all the classes that implement the interface. You won't know that they are broken until you (or someone else) tries a full rebuild.
Ant has a "depend" task that attempts to fix this, by tracking source dependencies. Unfortunately, because most Java compilers don't do their part, Ant has to do this in an utterly kludgy way--by parsing class files! Not only is this slow and has some weird side-effects, it's still not completely reliable: Only the compiler really knows what files depend on what others. (For example, if it in-lines a constant, this may not be evident in the class file.) However, as far as I know, gcc is the only Java compiler that can output correct dependencies (jikes claims to do it, but is broken). Even if your compiler does output dependencies, you can't easily use them with Ant, because it stores its dependencies in a non-standard format.
Another regression is that in Ant, individual source and class files are not first-class objects to the build system. You can't easily depend on, or ask to rebuild, a single class file. It's all or nothing. This too is largely due to compiler deficiencies: There is no way to tell most compilers to compile only the given sources; they insist upon compiling everything they think is out-of-date (again, gcc is an exception). This misfeature takes control out of the build system's hands, with the result that "recompile everything that's out-of-date" is the only feasible approach. Another effect is that parallel and distributed builds cannot be done reliably.
Not to mention,
I don't even know where to start on that one. All Ant shows is that if you give people a half-working workaround for broken tools, they'll flock to it.The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Look man, you might be educated to be a programmer, but if you are worth anything to your employers then you implement some sort of software design methodology, and that's all XP is: it's a lightweight, high-discipline approach to delivering software to a client.
You can argue whether or not XP works, but if you are ridiculing and avoiding it just because it has the word "extreme" in its title then you are a poor programmer and a fool. Since your entire post consists of mockery you leave no choice but to believe you are both.
The big problem however is that it does not account for programmer laziness and time constraints.
Larry Wall tells us that the three cardinal virtues of programmers are laziness, impatience, and hubris. It would be a shame to work with a methodology that doesn't support those virtues. Happily, I am a lazy man, and I love XP. The problem you describe isn't one of laziness; it's with short-term thinking and a lack of discipline.
If your tests are good, refactoring's pretty easy; you make the change you like and let your tests tell you if you've screwed anything up. (But it helps if you use an IDE with refactoring support like IntelliJ's IDEA; that takes care of all the donkey work.) If your tests aren't good, then you weren't disciplined in writing them.
If you keep things refactored and your tests are good, then adding new features is easy and low-pain. If you let your design rot and your tests don't cover anything, then adding new features takes a long time and hurts a lot. The truly lazy man will thus take the first path.
Think of it like cleaning the kitchen. The short-term lazy person will dash in, cook a meal, and leave the pans just sitting around. Next time he cooks a meal, the pans are all crusty, so it takes a long time to clean them. The master of laziness washes the dishes right away, as that is the path of minimum work.
Of course, this long-term laziness can be hard to acquire, but things like pair programming, a close team environment, and short iterations help a lot. If your partner notices your laziness right away or a team member will deal with your code next week, you're much, much less likely to write crappy code.