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.
Check out my double nested for loop ollie nose-grind, dude!!
If bad puns were like deli meat, this would be the wurst
...there was an instant spark between us... Despite the fact that I'm an OS committed to my hardware, I could definitely see something happening... Sure, she was openly platform-promiscuous, but I knew she always used VM protection... besides, both of us were protective of our own (code) secrets... and I must say that the mystery attracted me. So, I thought, why not?
...if only I had foreseen Bill and Scott walking in on us that one day... lord knows why they were hanging out together, but suspicion can make people do crazy things...
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
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.
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.
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]
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)
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.
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
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.
Yes, I agree that's a possibility. I'm not sure how innocuous it is -- I mean, aren't the book reviews supposed to be impartial? Why don't we just let the authors write them?
Granted this is all largely theoretical as the vast majority (all?) of the reviews on slashdot are crap. They frequently are less informed than the average reader reviews on Amazon...
I am not a number! I am a man! And don't you
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.
I like many of the concepts of XP because it is a more realistic model of how developers actually work. The big problem however is that it does not account for programmer laziness and time constraints. One of the premises of XP is that you should develop objects for your current needs today. If tommorrow or next week, those objects nolonger suit your needs, refactor them until they do. In real life many/most programmers are too lazy or don't have time to refactor a class and then work through the code base to insure that every thing still works. Yes i know there are tools and the unit tests help. But the fact is most programmers will just write new code rather than rework existing stuff, especially if someone else wrote the original.
The other big problem with XP is the working in pairs bit. Most developers smell bad, who wants to be stuck in a cubie with one.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.