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.
Duhhhhh.. but I thought XP shipped without Java support ?? :-)
Check out my double nested for loop ollie nose-grind, dude!!
If bad puns were like deli meat, this would be the wurst
Now you can run java on XP.
Too bad you can't run VB on solaris...
Linux is dead.
LU
...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
An article about Extreme Programming uses an acronym that makes everyone assume it's about Windows XP. How foresighted.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Yeah! Real Programmers (TM) write self-modifying code in assembly with no comments.
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]
Both Java and C++ are statically typed compiled languages. Java in particular requires some extremely awkward casting to use their container classes.
If you want to experience true eXtreme Programming use Perl or Ruby - get the same work done in one tenth the number of lines of code with a modern dynamic interpreted programming langauge.
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 write self modiying code that comments itself as it goes.
For everyone who doesn't get the joke, it's because XP stands for eXtreme Programming, a means by which you can generate assloads of documentation and spend lots of time in meetings... Er, program more efficiently, that's right. This has nothing to do with Windows.
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.
imp0rn Xtreme.J4va.COAD;
Clazz JazzyJava {
pubic voyd maine(Strig wordup) {
while(jav4_is_still_Xtream)
System.printl("you betta believe it sukka")
}
}
...sounds like it involves a small surf-type board and a large U - shaped object.
No declaractions. Juse use your variables and go!
Run your code without compiling it.
Put that in your Xtreme pipe and smoke it!
Is it? Try a tracert to www.nato.int - it goes through *.UK.KPNQwest.net and *.BE.KPNQwest.net from here (UK) so I suspect that rumours of its demise have been exaggerated.
In 1994, the buzzword was "multimedia."
In 1998, the buzzwords all involved the Internet.
In 1999, the buzz was all about UNIX and Linux.
In 2000, Apple announced Mac OS X, which was a pun on the point that the new OS would run a form of BSD UNIX and that this was version 10, as in the Roman numeral. (There may have been an OS named "OS 10" elsewhere that could've led to trademark suits, too.) The new interface was named "Aqua."
Microsoft, working on its "Whistler" OS successor, later announced that it would slap on a Fisher-Pricey interface on its Whistler OS and name the interface "Luna." Later, they would announce that the new OS would be named Windows XP.
The industry names their products with respectively confusing names thereafter.
I think we can blame Microsoft on helping to muddy the waters once again on this one to confuse things mostly with OS X and other UNIXes.
Vos teneo officium eram periculosus ut vos recipero is.
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
Considering Java is a language that only requires an interpreter that works with the OS on any machine.
:-) I personally love java... when used properly.
You can run java on any computer, as long as you have an java interpreter on that machine as well. So hypothetically, you've always been able to run java in XP, you just needed the interpreter.(or the processor understands javacode, which is highly unlikely, Probability --> 0)
Just a humourous thought.
~ kjrose
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.
VB is good if you need to produce something quickly to use it just one time. In such cases you dont care how long it runs, you care how long it takes to write the code.
that programmers working side-by-side on the same machine will have to start taking baths!
But what do you think when one says "XP". I'm sure, you think about Windows. And the apbbreviation is a good advirtizing trick! Well done!
More than that, there's a belief (justified or otherwise; I've got an open mind and want to get some experience before I take a stand) that xUnit allows the programmers to write the tests before writing the code, and that this "test first development" or "test driven development" leads to well designed code. (Kernighan and Pike suggest something similar in The Practice of Programming, but don't take it that far.) Interesting idea, at the very least.
Stupid job ads, weird spam, occasional insight at
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
Real Programming is an undefined term for dip$hits like you boys that have no knowledge of how to build quality software. I think you mean that you are one of those dumb ass proponents of Coding By The Seat Of My Stink Ass Pants.
Java has its limitations, but I'd like to hear what language you would recommend over it.
It is high time to recal an idea to prove that the program is correct instead of testing it. For short peices of code it used to help a lot.
"Hype meets Hype".
everyone else just ripped it off.
Like they do whenever Apple has good ideas.
Another important XP practice is acceptance tests.
AUATs take care of the whether the pieces work
together.
He didn't say they were new. He just said that XP "consists of a lot of distinct ideas." Where do you read the word "new" in that sentence?
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.
The Java VM seems to be gone on one of my win2k boxes, and any time I go to instlall it, either from MS or from Java, it says "This is a protected Windows component. you cannot install it" or some such crap.
I think this is actually where I disagree. Good code must be (a) correct and (b) maintainable. Good unit tests guarantee the former if, but say nothing about the latter. It is therefore quite possible to write crappy code that passes all of the unit tests.
And herein, IMHO, lies the single biggest weakness in XP. In all the focus on passing unit tests (which are written first) and constantly refactoring, they have deliberately lessened the focus on a clean, maintainable design, and left it essentially to chance. If your development team consists purely of top-10% programmers who work well together, then certainly they will "refactor mercilessly" and maintain/develop a tidy design. However, most project teams don't, and in my experience will be "at the mercy of refactoring" instead.
Now, suppose six months down the line, I have a codebase that passes all the tests, but in making a simple change to meet a new requirement I can cause it to fail 500 tests and need six man-months of rewrite time before it passes them all again. Do I really have a good codebase?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I like Ant, but anybody else tired of restarting the VM every time you have to build?
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.
At least, that's where I assume you were speaking from after posting a comment like the above claiming XP development methodology is some "new idiot buzzword". Take a look at www.extremeprogramming.org for a bit of history and perspective. There has been a lot of discussion and interest in lightweight software development methodologies over the past few years in part due Kent Beck's book "Extreme Programming explained", but keep in mind, it was first published in late 1999. This is hardly "new" and for sure didn't come out just this week as you imply.
...computing professionals" (college educated or otherwise), please take some time to keep up in your field or shut up and listen when you don't know something. If you're actually a software developer and don't know or don't care about the work of some of the individuals listed on the XP site or the XP book series authors and those listed in the credits (Martin Fowler, Erich Gamma, Kent Beck, Ward Cunningham to name a few), then please do us "serious" Software Engineers a favor and make that career move you've been grumbling about. At this point you're either a.) young and ignorant and bound to make us look bad or b.) old and arogant and bound to make us look worse.
Also, for the sake of the rest of us "hard working
*** Sigs are a stupid waste of bandwidth.
Nor did I say he did. However, as you point out yourself, he said that XP consisted of various ideas. My point was that since it didn't invent any of them, and all of them are widely used elsewhere as well, there must be more to XP than that.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
is the only way to guarantee a clean build.
I learned that everyknow knows that Ant is broken - but no one cares or even understands the issue.
Coming from a Makefile background I find this sentiment to be pretty annoying.
There is some benefit to the naming and the book writing that surrounds it: more programmers get exposed to the ideas. But don't expect a magic bullet: people have had a lot more experience with those techniques than their recent new clothes suggest. For some problems and environment, they work well, for others they don't. Talk to experienced programmers from the 1980's for more advice :-)
Java in-lines of a constant are a Javac BUG.
.class files when they clearly were not allowed to by the JLS. When classes were derived from these ill-optimized classes their virtual function overrides did not work.
Those values ought to be "late-bound" at runtime.
Please voice your concerns with the Sun Java Bug Parade.
There is no good reason to have to recompile code if a library ships with a different constant - afterall, you did not type in a number in your code - you typed in SomeClass.CONSTANT. (Swing made this same mistake in changing an event constant from JDK 1.3 to JDK 1.4).
This is no difference from early JDK 1.1 Javac compilers that naively illegally inlined non-final functions in base class
Part of the reason why Sun ignores the fact that late constants are not "late-bound" at runtime is because the JVM opcodes lookupswitch and tableswitch only operate on numeric constants.
Making them work properly would require a JVM overhaul and a change to the class file format.
Ok, big long rant here. I've been programming for about 6 years now, I've been projects ranging from a mammoth-sized Y2K with 50 programmers slogging over 2 years, to ones where it was just me over a couple weeks. I believe most of the time that XP, and similar incarnations of "technique efficiency boosters", are in practice a waste of time. Oh it's not to say that they're quite entirely useless, they might have some good ideas, but it's just that what they have to offer is an insignificant factor compared to what the real problems of software development typically are.
I submit that development techniques and programming language structures are not what in practice hurts software projects, and therefore they aren't particularly meaningful candidates in the big picture for "fixing". How you document the code as you go, or test iteratively, or storyboard scenarios, or whatever just isn't going to fix the problems. The things that really grind projects down are inefficient and/or bad programmers, poor two-way communication on requirements, and having business analysis and testers without a layman's knowledge of a programmer's technical job. These things are all personal-skills based. I would say XP is great if you happen to have those three things above already whipped, but that's hardly ever the case. I've seen people I work with get all giddy with the thought of fabulous new efficient ways of doing things like with XP.. not even realizing it's just deck chairs on the Titanic. If you don't start with good ingredients, you will never be able to cook up something tasty. Software project managers should just face that fact, and quit looking for boondoggle hyped-up fixes like XP.
You really need skilled developers first and foremost to have a successful project. You need programmers who really know the language, have experience, and have the good judgment of when to quit making the code more complicated. I've seen big bureaucratic companies hire housewives and history majors for real full-time software development jobs. What were they expecting? I don't know, that they would catch on some day I guess. These people struggle, write bad code, and get things done things poorly if at all. They take time from the more qualified programmers by needing fixes and debugging done to their bad code, and to also by needing hand-holding and to keep them up to speed.
For those good programmers, and I've worked with some really sharp guys, the biggest danger for them building a big complicated tank out of their work. Oh, It does everything! Cooks your breakfast, handles every possible contingency, and tries to predict anything you might want to use it for over the next 10 years. They obsess about those unbelievably remote contingencies.. they catch and handle that "OhMyGodAliensHaveInvadedTheEarthException" condition, and then hmm, build something that organizes those errors by tenticle-number and suction-cups-on-fingers or not, and then hmm, etc etc. All having nothing to do with the original goal of the code they were writing. Meanwhile, they took two months longer than they should have to build it and nobody can figure what the hell their code does in less than a week of pouring though it. Software can be such a creative process that they get caught up in the momentum. Being a perfectionist has no place in development work. Do what needs done given all the actual requirements, and then stop! You have other things to get to. Complexity is not a virtue.
Anyway, I think it's about the people- they need to be skilled enough to be competent and mature enough to focus their effort. Get good people on the development team. Get qualified people to design/scope and test the app. Get them to fully communicate with each other. THEN worry about stuff like XP.
I like this quote: "In theory, there's no difference between theory and practice. In practice, there is." Focus on the real world, I say, not on theory. Well, so much for my rant. Thanks.
i feel for you posting at -1 with slashdot's lamest. hopefully we'll find some mod points for you.
mjl
- The Rules
- The Wiki Roadmap
And more on-topic: A nice IBM article about automation w/ Ant and JUnit.evolution IS god.
VB is good if you need to produce something quickly to use it just one time.
Perl is good for one-off scripts as well, especially with its regular expression support.
Will I retire or break 10K?
not running VB on solaris might as well be a security feature opf Solaris as it protects it from run away programs and HORRIBLY coded apps...
Actually, a VB compatible interpreter runs on the Solaris operating environment. What protects the system from runaway VB apps is not a lack of VB but the presence of working permissions on the system.
Will I retire or break 10K?
public class CmdrTaco implements TacoSnotting {
snot.color = green;
while (! nose.empty()) {
snot = nose.pick();
mouth.consume(snot);
}
}
(or the processor understands javacode, which is highly unlikely, Probability --> 0)
Talk to Transmeta. Transmeta's Crusoe processor runs programs through dynamic recompilation of bytecode. Current products emulate Intel x86 bytecode, but the Code Morphing recompiler is a piece of software and can be easily replaced with one that understands Java bytecode or .NET MSIL bytecode.
Will I retire or break 10K?
"To some folks, XP seems like just good common sense. So why the 'extreme' in the name? XP takes commonsense principles and practice to extreme levels"
-- from the second paragraph of the Preface to Extreme Programming Explained by Kent Beck (page xv)
To say "People have used the technique for decades" is wrong. It is correct to say we all knew about and used the individual techniques (principles) for decades. BUT no one before Kent Beck bundled them all into one coherent methodology, and explained the synergies. THAT is the genius of XP!
BTW, I AM an experienced programmer from the 1980's
Haven't read the book, but I wonder if there is any mention of Eclispe and TogetherJ, both Java IDEs. Both have refactoring built in (highlight code--> right-click--> extract method, and such), and also have integrated support for JUnit, CVS (Eclipse, anyway), and other XP-loving features.
If Slashdot is where the spelling-challenged go when they die, I'm in heaven.
They both deal with ant, you moron.
The ISBN on "Ant: The Definitive Guide" is incorrect: both bn.com and Amazon.com have it listed as 0-596-00184-3, not 0-567...
Check out the book web site for more details about the book. Java Tools for eXtreme Programming describes techniques for implementing the Extreme Programming practices of Automated Testing and Continuous Integration using Open Source tools, e.g., Ant, JUnit, HttpUnit, JMeter, and much more. This page contains review excerpts, links to the code, and a book description.
rick hightower dot com
"It is ... a pleasure to review ... books that are both original and useful. The first is Richard Hightower and Nicholas Lesiecki's Java Tools for Extreme Programming, which describes five new Open-Source Java programming tools... Java Tools is readable and well organized... As a bonus, the authors show how to use these tools together; for example, how to automate reexecution of JUnit tests using Ant."
--Gregory V. Wilson (Dr Dobb's)
"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 (JavaPro)
rick hightower dot com
Sometimes code REQURES a rewrite, or it's quicker to do so. In these cases, a rewrite is CERTAINLY meritted, rather than bashing your head against a wall trying to get code to do something it was never intended to do.