Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Java Tools For Extreme Programming 175

Posted by timothy from the espresso dept.
David Kennedy writes: "Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus by Hightower & Lesiecki is a welcome addition to my bookshelf at work. It tackles a gap in the Java book market in dealing with the thorny issues of testing, integration and deployment." The rest of his review is below.
Java Tools For Exteme Programming: Mastering Open Source Tools including Ant, JUnit and Cactus
author Richard Hightower & Nicholas Lesiecki
pages 516
publisher Wiley Computer Publishing
rating 8
reviewer David Kennedy
ISBN 047120708X
summary Practical introduction to Java tools for Extreme Programming, with an emphasis on immediate results rather than deep theory.

In recent years there has been a increased emphasis on Agile Software Development. The most prominent of these methodologies is probably Extreme Programming.

What sets Extreme Programming apart from most other Agile Technologies, in my opinion at least, is that it has provided practical, easy-to-use tools to support its way of working. Most of these tools (Ant, JUnit etc) are Open Source and freely available. However popular these tools have been with the Open Source and Extreme Programming communities, it has arguably been difficult to introduce them to traditional IT development environments. This has been primarily due to the problems of justifying spending time on 'playing' with something and the difficulties of retro-fitting new tools to an existing development environment (think projects of 150+ people which have been releasing for 5-10 years for some idea of the potential problems).

It's worth noting that when embarking on a new, large-scale project it's very difficult to find a book discussing the issues of controlled builds, integration and deployment in practical terms. The most valuable aspect of Java Tools for eXteme Programming is that it's alone in its market niche.

The book is mainly useful as (a) an introduction to the various building and continuous testing tools out there and (b) a tutorial to getting them setup and working on your computer. As the authors note, there's a critical period where the user must get some result after playing with the tool for a short period of time or just give it up as 'too difficult.'

From a technical standpoint the book is very readable, but it doesn't tackle any one subject in great depth. It certainly provides enough information to get you up and running, and also, perhaps more valuably, illustrates how to integrate the tools together. It's an excellent primer for those who want to use the tools but are unsure of how exactly to start.

What's covered? Here are the chapter headings:

  1. Introduction and Key Concepts
    1. Introduction to Extreme Programming
    2. J2EE Deployment Concepts
    3. Example applications
  2. Mastering the Tools
    1. Continuous integration with Ant
    2. Building Java Applications with Ant
    3. Building J2EE applications with Ant
    4. Unit testing with JUnit
    5. Testing Container Services with Cactus
    6. Functional Testing with HttpUnit
    7. Measuring Application Performance with JMeter
    8. Load Testing with JUnitPerf
  3. API and Tag Reference
    1. Ant Tag Reference
    2. Ant API Reference
    3. JUnit API Reference
    4. Cactus API Reference
    5. HttpUnit API Reference

If you use some of these tools already will you learn anything? Probably -- I personally have been using JUnit to test EJBs for almost nine months now but didn't know about JUnitPerf or Cactus.

Should you buy it? If you're new to the tools, then Yes. If you work in a professional but traditional IT shop, I'd buy one for the group (I have). It'd be particularly useful when dealing with management and proposing changes to working processes, or when trying to bring co-workers up to speed and sell them the benefits of agile ways of working.

You can visit the book's website at Wiley. You can purchase the Jave Tools For Extreme Programming from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
This discussion has been archived. No new comments can be posted.

Java Tools For Extreme Programming More

Java Tools For Extreme Programming

Comments Filter:

  • This isn't a review (Score:1)

    by Anonymous Coward
    this is more like the text on the back of the book. Please go into depth about the types of examples, does it discuss practical applications, and deployment plans?
    • Please mod this guy up. This isn't a review. Nobody at Slashdot or whoever wrote this review actually seems to have read the book and compare it to the actual practice of extreme programming in the context of Java development.

      Modding it to zero reflects what on the part of Moderators?

  • Continuous Integration - CruiseControl (Score:5, Insightful)

    by smagoun ( 546733 ) on Monday April 29, 2002 @09:39AM (#3428981) Homepage
    Although (apparently) not mentioned in the book, CruiseControl [sourceforge.net] deserves a look. It's a continuous build tool you can use in conjunction with Ant, JUnit, etc.

    "Build early and often" is one of the continuous integration mantras, and CruiseControl helps out with that. By having a coninuous build cycle, you can catch errors literally within minutes of when they're committed to the source repository. CruiseControl will email you if builds don't work, and also has a nifty servlet to let you track builds on the web. It's definitely worth a look.

  • This book is *terrible* for extreme programming - I don't know why they even put it in the title (um, ok - to sell more books...) It's a good book for the price though - don't just take my word for it:

    amazon reviews [amazon.com]
    • What does Ant (an extremely useful buildtool for Java) have to do with Extreme programming? Nothing! I can't really imagine why anyone would need a book on Ant (can't say much for the others) -- there's pretty self explanatory documentation here [apache.org]. Since extreme programming strikes me as a load of crap to begin with, this is all probably a good thing.

      YOur right about the amazon reviews. What is it with these "reviews" that get posted here -- the table of contents for christ sakes? It seems like book reviews are just an excuse to post a affiliate link to a book store. For shame slashdot. For shame...
      • Kinda wondering what "Extreme programming" is. Is it where you bungie jump while coding? I dunno.
        • Extreme programming is based on the following. Code reviews are good (questionable but we'll assume this for the moment), rewriting code is good (ditto) so doing these things ALOT (or in the parlance "to the extreme") must be really good. Basically, thinking things through is hard to do so just keep iterating on the solution till your "done". "done" is defined as the point in time when the client stops paying for your code wanking. Consequently, you don't see much of it outside of consulting.

      • Re:Catchphrase whoring (Score:3, Informative)

        by yog ( 19073 )
        Well, "extreme programming" is part hype and part common sense. The hype part is to educate management into the methods lots of people have been using for decades. Codifying it and giving it a sexy name helps legitimize these practices. Code reviews **are** useful sometimes as is pair programming, rigorous unit testing, etc., but this stuff has been happening all along with or without management approval.

        Now if you're sitting next to your buddy, watching and commenting as he or she steps through some code, and your manager asks you why you're not at your own desk doing real work, you can explain that you're "pair programming" or code reviewing or what have you. Whatever. It's just a name for something everyone already does from time to time.

        If you think the hype's a "load of crap" then I would tend to agree, but if it's the practice you object to, then you're obviously a rank beginner.
        • The part of extreme programming I object to is taking things that are common sense when done in moderation and then asserting that if a little bit is good then a lot is great. Code reviews are rarely as useful as say a design review is. Too often it's a "find my bugs for me" type effort or people correcting grammar in comments. The worst part is that managers assume that because other "experts" looked at the code it is valid. Since most people don't single step new code through the debugger (something that actually is useful) and which is a lot cheaper than a code review.

          There's a big difference between two people sitting together to work on a problem and two people chained to the same computer in the vain hope that they will produce better results. It's the old "two men dig a hole in half the time of one" syndrome.

          But that's just me and I could be wrong. Maybe it does make alot of sense.

  • A relief, for me (Score:2, Insightful)

    by hoegg ( 132716 )

    Personally, I learn programming concepts well when I have a real book instead of web research. Either I missed this book or it's new, because learning JUnit, Cactus, and Ant all at once on a single project from only web research is rather challenging.

    This is going on my shopping list.

  • I'm no dummy! I'm sticking with "Java for Dummies"! Oh, wait... Damn!

  • Extreme Programming: Unrealistic? (Score:4, Insightful)

    by Kombat ( 93720 ) <kevin@swanweddingphotography.com> on Monday April 29, 2002 @09:43AM (#3428993)
    I really like the concept of XP, and have been working hard to incorporate some of the ideals into my own work. However, XP seems more suited to small, nimble projects of less than 20 people. It doesn't seem to scale very well to larger projects, especially in an organization averse to taking risks and doing things any differently than the way they've been doing them for 20 years (doubly so in this punishing economic environment).

    Last year, I actually had the opportunity to ask Kent Beck if he had any suggestions for adopting XP to large projects (200+ people across multiple geographic locations), and unfortunately, he wasn't too optimistic. He indicated that the largest projects he's tried XP on were 20 people or so.

    Other issues we've had when considering adopting XP in our organization are that XP tends to assume that you will be developing for a single customer with a set of evolving - but consistent - requirements. In our reality, we have multiple customers, who want different things.

    Finally, XP doesn't seem to offer any solution for testing GUIs, which make up a large part of our product.

    So while I'm very excited by the promises of XP (and will likely buy this book), I think it is important to temper your enthusiasm with a healthy dose of reality, and consider that XP relies on some subtle preconditions in order to deliver on the promise of a smooth and successful development cycle.

    • > Finally, XP doesn't seem to offer any solution for testing GUIs, which make up a large part of our product.

      Well, testing anything specific (and GUIs in particular) is not something that development methodology has to answer for. You're on your own, just as if you were to test, say, a numerical algorithm used in your code.

      That said, there /are/ methods to test GUIs. For example, use GUI toolkit that allows a scripted access to the GUI controls. Applescript does that for Macs and Accessibility Toolkit does it for Gnome2/Gtk2 applications (once GNOME 2 officially comes out, of course). I know for a fact that a number of companies have their own in-house testing harnesses for Windows.

      --
    • I am a development manager with a large (20+) team; I am gradually introducing some aspects of extreme programming into the organisation, and so far, it's working pretty well.
      The concept of user stories is great for getting our multiple customers to get to grips with their requirements; the tactile nature of the cards allows the planning sessions to be participatory and inclusive, the customers understand the trade-offs and the developers get to understand what they're _really_ being asked to deliver.
      Pair programming and continuous testing have produced decent results; the main problems we have are accomodating sickness and holidays into the project plan.
      On the other hand, our organisation does insist on some of the more traditional aspects of development management - a formal "Project Manager" role, regular progress reports to the executive team, functional and technical specifications etc.
      I don't see how you could realistically hope to convert an entire team to XP overnight. The gradual introduction of some of the basic concepts - esp. those which can be explained as "quality oriented" - is a lot more likely to succeed.
      I've read the book, and it's okay; the editing could have been a lot tighter (there's page after page of code printed out which outlines the application to be tested, not the tests themselves, there is a huge chunk devoted to the documentation for the tools which is available online etc.), and it kinda drifts away from the point now and then. If you want to get up to speed with Ant, jUnit etc. it's worthwhile, but don't expect to become an XP xpert.

    • JFCUnit (Score:1)

      by Dix ( 73628 )
      Difficulty JUnit testing with a GUI? Try:

      http://sourceforge.net/projects/jfcunit/

    • Why do projects require large teams, such as 200+ people? This is the first question you should be asking. XP is not some sort of band aid that will make the pain go away. It is a collection of some time honored practices, some newer techniques and whole lot of guidelines on what you should not be doing. Any oversimplification or executive summaries are not going to help you understand what is XP let alone how to apply it.

      I think the most important, critical, absolutely must criteria is self-organizing teams. Traditionally, especially your 200+ person team, chops up development into "pieces" according to some vague boundries based on classical engineering practices. Some shops get into creating blueprints aka UML by "architects" and code written by "monkeys" aka contracters.
  • Check out the book's price at Half.com [ebay.com] .

    Overall, they're cheaper than bn.com (I have no association with either, but I've found good deals on these book resellers).

    Sig: What Happened To The Censorware Project (censorware.org) [sethf.com]

  • 1) Read a book review somewhere (presently DDJ)
    2) post a critic, including links to web stores
    3) earn referer fees
  • If you want to save a few bucks ($24.50 vs. $31.99 at bn) go to bookpool [bookpool.com].
  • I have a question for the JUnit users out there. Basically we are doing unit tests here in the following way:

    1. We mark the test code in the classes between special comment lines (so that it can be programmatically removed)
    2. The tests are in static methods with the prefix "test", called by a Test.class in each package. Test.class has a main that just calls the other tests
    3. Each test prints out on a single line the class it's in, the name of the test and "passed" or "failed" and the failure may have extra info as to why it failed

    This is working well for us, but considering how many people are happy with JUnit I was wondering what it provides over this way of doing unit tests? Basically, I'm just looking for some of the things that JUnit has provided you (above and beyond what the above gives) and maybe a real use example, but don't really need to be sold on unit testing (we already think it's great and are doing it).

    F
    • It provides two things. First, you don't have to mark your code, so you can avoid a preprocessor step, and thus reduce complexity. And it provides a client for your units. Your JUnit test case should use your code just like a developer or customer would.

      It's also a realy nice framework. You can extend TestResult to do whatever you want, meaning you can have your harness report directly to your defect tracking system, send e-mail to the appropriate place, or some other thing that hasn't been thought of yet.

      So three things. Reliability, unit clients, and flexability.

      It's handy as heck.

    • Re:JUnit advantage? (Score:3, Informative)

      by tdrury ( 49462 )
      JUnit is amazing. It's incredibly easy after you've written your first unit test. Here is a prime example of its use: I had about 50 classes spread out over a couple packages one of which is "core" to all the others. I had unit tests for all the code. I wanted to totally redesign how I implemented one of the core classes which is inherited by a number of other classes. I think people that don't have unit tests would shy away from such a large change. I simply backed up the old source file, put in the new file, and ran my ant script which builds, deploys (on appserver) and runs junit. After about 20 minutes of cranking through the unit tests, it finished with no failures. At that point I was 100% confident that my change worked and I wouldn't be surprised by a suble bug later. That is what junit is good for - peace of mind and confidence. You'll allow yourself to make changes to code (for the better) that you may otherwise have though too complex to attempt.

      As for your first unit test, it isn't that hard. Use a standard naming schema like "FooTest.java" or "FooJUnit.java" for your test cases - this way ant can filter on those name and run junit against them while keeping your unit tests out of your distribution jars. Extend TestCase and overload setUp() and tearDown() - often you won't need those. Name your methods testXYZ() and junit will run them. Inside your test methods call Assert.xxx() on the things you want to test. You can test for null, compare to known values, etc. You can test to make sure exceptions should be thrown or not. Sprinkle in a little log4j [apache.org] and you can get more detailed progress of the tests.

      -tim
    • If you have a working unit testing mechanism, then JUnit doesn't have much of an advantage. The best thing it has going for it is standardization... it's what most people who are bothering to actually test their code (i pity the poor fools who think they are too busy coding to prove that their code actually works) use. That means it gets integrated into just about any open source Java tools - Ant, NetBeans, etc. You can integrate yours too, but it's work and maintenance.
  • Recently, I was researching some java applets for a website. I saw many instances where different code bases had to be kept for IE, Netscape, and others. On many sites I found that applets were slow or unpredictable on IE and/or Netscape 6.

    Is java an idea that never lived up to its hype of being cross-platform or do most web designers need a serious lesson in programming?

    • Re:java in pratice (Score:2, Insightful)

      by Rentar ( 168939 )
      Is java an idea that never lived up to its hype of being cross-platform or do most web designers need a serious lesson in programming?

      Java did live up to the hype, but no on the desktop 'though. Java is very much alive on the server side. Client side java pretty much never existed on the big scale ('though there are some very good client side java programms). Applets were killed by old and incompatible implementations of the JVM (not only Microsofts, but others as well). The Problem is/was that most Browsers shipped with a Version 1.1 JDK, which is just plain old and outdated. Microsoft never even shipped anything more up to date. You can use plugins to use more up-to-date versions of Java, but that's quite some trouble. And most Applets are just used as a flash-replacement and for this it really isn't worth to download the Plugin.

    • Re:java in pratice (Score:4, Informative)

      by Phoukka ( 83589 ) on Monday April 29, 2002 @10:37AM (#3429205)
      Been under a rock for a while, haven't you? ;)

      Okay, all ribbing aside, as someone who programs Java for money, let me give you the skinny: Java applets bite. More specifically, they are slow to download, prone to crashing, and subject to problems due to lack of control over the Java runtime available to the browser.

      Java has, instead, found its niche on the server. Server-side programming is where Java works really, really well. Development is generally faster than with C/C++, and Sun and others (go Apache! :) have provided some seriously amazing libraries/frameworks/etc. that help programmers avoid reinventing the wheel -- or the bucket seat, the 5-speed automatic transmission, or even the 10-disc CD changer.

      The other benefit that Java on the server provides is that web designers don't have to monkey with the code, and programmers don't have to deal (so much) with HTML.

      Needless to say, everything above is a generalization, all generalizations are false (including this one), and YMMV.
    • The biggest reason for different source code for IE/Netscape is (IMHO) that IE's native Java support is frozen at V1.1.x. Most applets that I see on the web are coded for this level of Java and, generally speaking, run under Netscape....but since Netscape provides (I think) V1.3.x of Java you could definitely write a different version for V1.3 that has more features/whatever than the V1.1.x that you have to maintain for IE. Of course Sun released a Java plug in for IE to give it more up-to-date Java support....but you can't assume your customers all have it.

      Having said all that, I think applets are the worst representative of Java usage. I write server-side Java and really like it. The server-side specs (JSP's, Servlets, J2EE) seem to be port across platforms quite well. When we deploy code on WebSphere (IBM's J2EE platform) it runs across Windows, Linux, AIX, Solaris,etc with no problems. I haven't tried porting EJB's between J2EE platforms but I have written Servlets & JSP's on one platform and moved them to another with no changes, although the deployment details (what goes where) may differ.

  • Extreme Programming - WTF is that? (Score:3, Funny)

    by Navius Eurisko ( 322438 ) on Monday April 29, 2002 @10:04AM (#3429082)
    When I think of extreme programming, I think of writing code on a laptop while BASE jumping or while being attacked by a shark.
  • Is that like extreme wrestling, or extreme sports?

    As a programmer, something like Extreme Programming sounds downright scary to me. Or at the very least, something that would force me to get up out of my chair more often than I would like.

  • Java Refactoring Browsers (Score:4, Informative)

    by Frums ( 112820 ) on Monday April 29, 2002 @10:13AM (#3429116) Homepage Journal

    I'v enot read the book, but looking at the chapter headings they seem to have leftout one great tool for XP in Java - the various refactoring browsers that are now hitting stride for Java, including JRefactory, IDEA (my favorite IDE period), jFactor, and X-ref (for the Emacs lovers)

    With the XP RefactorMercilessly principle, IDE support for for refactoring is a must on big projects. Custom writing a Perl, sed, or awk script to move a method from one class to another (in its argument list) is possible, having IDEA or another refactoring tool handle all the updates across 2000 changes in 700 files is a lot nicer.

    -Frums

    • I don't have mod points today, so I'll just reply:

      I don't think you could be more correct. You simply can't have a book about Java tools for XP without talking about IDEA and some of the other great refactoring tools out there.

      IDEA has completely changed the way I write code. I never really took the idea of refactoring seriously until I found it. Until then, it seemed like the refactoring book was just a guide to the obvious, but to see the refactorings automated with names I immediately recognize made me rethink things. All those idealistic phrases I once laughed at started flooding back to mind.

      With the exception of JUnit (and even that's a close call), I don't think any other tool supports XP as well as IDEA.
  • The most scary part of the whole eXtreme Programming stuff is the pair coding. For those who don't know, it's the idea that all programming should be done by two people at the same time one actually coding and supposed to think "strategically" (about integration, structure and stuff like that).

    Now some poor programmers don't even have a PC for themselves. They have to share it with a colleague and they are even denied their most basic right to have a few square meters of personal space.

    I would never accept such working conditions but it's unfortunate that this seems to happen more and more. :( I hope people will soon realize that it's impossible to think when you have someone watching over your shoulder.
    • Yea, I wouldn't want to do it all the time every day, but I find that two brains on something can make for much better code. We use the concept here when there is a difficult task to be completed. It seems to work pretty well.
    • OK, I haven't done pair programming, but the idea isn't that it's someone 'watching over your shoulder', you're working together, but one of you is doing the typing. You can trade spots pretty often though.

      Tom
    • you share a workstation when you pair prog. you don't share when u r reading mail, playing unreal etc, dpoing spike work to get a proposed idea fleshed out. and if you are in the right sort of projects and work spaces, PP is fun and productive. IMOit is very hard to do pairing for more than 2 hours at a time cos it is actually harder on yr brain - you can't goof off mentally for ten minutes when things get tough.

    • A co-worker and I stumbled onto a GREAT way to do pair-programming: VNC.

      It's awesome, you sit facing each other on your own computers (thus having your personal space) and then you can work together in an instant just by logging on using VNC to see the other programmer's computer. VNC is fully interactive and you both have control of the keyboard/mouse at the same time. It's perfect for pair programming.

      There are many times when all you're doing in programming is a bunch of busy work. Copying and pasting fields from a database into get/sets of a Java class or something ridiculous like that that doesn't really need two heads. These can be done solo, but then when you start to get heads down into the business logic, you can just say "Hey, let's work together on this bit," and your coworker just logs on and you start collaboratively working together again.

      This way there's no fighting over the keyboard ("Oh, christ! When are you going to learn to touch-type, give me that!", "No! You drive me crazy with your backspacing... I'll drive."). Whoever has the right idea can type just by doing so and the other person can watch for errors, comment on style, etc.

      Mark my words, it works really well, it should be part of the XP standard.

      -Russ

    • "it's impossible to think when you have someone watching over your shoulder"

      The person watching is supposed to be doing the thinking. The other guy is supposed to bang out the code. i.e., one guy is thinking of the "big picture" and how it all fits together, while the other guy concerns himself with the details of syntax and writing code that runs. You alternate the roles periodically so each person has a chance to contribute to the "big picture."

      I find that in almost all cases, whether it's coding or testing, I get better solutions more quickly when I'm working with another person.
  • I was impressed by this book review, so that I was already thinking about a purchase and checking at the german amazon website (guess where I'm from?) for price and availability.

    The book had two quite bad reviews there. (2.5 points out of 5, which seems to be a pretty bad rating for amazon) The main point from both was the missing link between the java build tools, which seem to be discussed considerably, and eXtreme programming.

  • Naked objects (Score:4, Informative)

    by fuzzbrain ( 239898 ) on Monday April 29, 2002 @10:31AM (#3429174)
    One extreme programming tool written in Java which I haven't seen mentioned here is that of Naked Objects [nakedobjects.org]. I had play with it the other day and thought it quite a neat idea.
    • Naked Objects are not a tool for XP. They are simply a tool for presenting the business objects directly to the user. Although using Naked Objects might be easier if you were to use an agile process, they don't fulfill any of the needs of XP.
  • Java, Exteme Programming, Open Source. The title rings some warnings bells...
    • true, then again, the book does seems to be talking about programming in java, using open source (well, free, actually) tools and following Extreme Programming methodologies, go figure.

      And since when is "Java" a buzz word?

      • A technology can become buzzwordified if there is a lot of hype surrounding it and those pushing it don't really understand what it's all about. For example, XML is a big buzzword today. Everybody is all jazzed up about XML, but not many people understand its benefits and shortcomings, or that there are more compact human-readable data formats out there (Windows .INI files and s-expression structures as written by LISP/Scheme programs come to mind); they just think that linking against expat is going to give their program some special interoperability magic.

  • extreme programming (Score:2, Interesting)

    by grakwell ( 571986 )
    My experience with extreme programming is that it is simply a bass-ackwards way of development.

    The advocates of eXtreme pr0gramming who love to "refactor" their code on a daily basis seem to have the same mindset as the people in my upper level CS courses that would spend the entire weekend in the computer lab on their projects, and complain about their grades and the time they spent afterward.

    I'd spend a couple hours making object relationship diagrams, program flow diagrams, etc beforehand. I'd show up at the lab Saturday morning at 9 and leave at noon, and the looks these students gave me were a combination of hatred, jealousy, and disbelief.

    IMO, it's just a process choice. Planned, focussed development, or tinker-till-it-works.
    • Good luck getting perfect specs at the start of the project.

      Programming isn't just about programming. Too often its about learning how to do the clients job to a minute detail. XP (to me) seems to be about one person learning the clients job, while the other is banging out some code.

      Keeping a client involved is a good thing. Showing them frequent results gets feedback before its too late.

      This style won't work for everything, but I see it as a valid way of working with business clients.

  • Sorry, but I glean little from this review (Score:4, Insightful)

    by SloppyElvis ( 450156 ) on Monday April 29, 2002 @10:52AM (#3429294)
    Extreme Programming has been discussed at /. before, and the links provided at the beginning of this review were useful, but the review itself falls short of mentioning how the authors integrate these tools with the extreme programming philosophy.

    Check me if I'm wrong, but from my initial readings, XP relies heavily on customer feedback, and short-term iterations serving to adjust the project plan "on-the-run" so to speak, which minimizes time loss incurred by the difficulty of making accurate long-term estimates in programming, and compensation made for fickle end users. While testing is a large part of XP, is only a part of XP. What does this book say about implementing XP on the whole? Anything? Is this just a book about tools you may use to test your software? Can I test my software if I don't use XP?

    The most valuable aspect of Java Tools for eXt[r]eme Programming is that it's alone in its market niche.

    Excuse me for being picky, but what is useful about that? Are you saying that this is good if you want generic text that has XP written on the cover, or what?

    The links describing XP give it a nice once-over on how you can think about the process of getting release versions out the door [which users and managers like]. I haven't seen anything that deals with the aspects of applications design that span beyond iterative releases, namely, systems that are proven to assist in the overall application architecture, and systems that are proven effective for creating flexible and useable GUIs. If you have a crack team of programmers, XP will cushion the unavoidables [ software is hard to estimate, and users change their minds frequently ]. Of course, you still need competent minds at work on the overall architecture of your code, and that planning seems to be an afterthought in XP ( features first, architecture second, perhaps this is why managers like it ;P ).

    Also, for any large project, you are going to have developers who display special skill in certain areas, and some who display ineptitude in certain areas. Before you start saying, "well, just fire the inept", remember that firing and finding replacement talent isn't all its cracked up to be, and "failure to exhibit genius" isn't cause to send somebody packing (nor is it always wise). XP takes the stance that everybody should do everything, but oftentimes you'll find that some on your team just don't have it like the top dogs do. In many cases, you want an expert to code a critical segment and, while it'd be nice if they could teach the whole team their skills, in reality, that is not always possible. I believe in peer learning, but everybody do everything, well... excuse the pun but that sounds a little "extreme"

    XP has good guidelines, but I have many questions about how to interpret those guidelines, and a text that puts XP on the cover should say something about them, IMHO. So you say this book is about tools for XP, not XP itself. Ok, then what tools does it discuss other than those used to test code? Are there any other tools? Are these tools only for use with XP?

    I guess what I can take home with me is that if the buzzwords "Java" and "XP" are on your cover, than somebody will publish your book.

    • You gleam little because you don't have the base knowledge that this book expects from its audience.

      If you were expecting an overview of XP you were completely off base... You should perhaps check out the SERIES of books on XP at your local bookstore...

      I'm glad that you pointed out that you still need qualified people in order to develop software... However, by implying that you would like to fire the inept you are overlooking how pair programming helps share the knowledge between the specialists that you have in your organization.

      Finally, if you want to know what XP has to say about developing flexible gui's, etc, perhaps you should read up a bit more on Design Patterns... then see what Beck has to say about using them in extreme programming.

      Have a nice day.

    • Your post seems to hint that XP was presented to you as the be-all-end-all of programming methodologies. I don't think anyone well educated in the subject would recommend it for all projects.

      I don't pretend to be an expert (just regurgitating some information from a guest speaker from Object Mentor at a JUG meeting), but from what I understood there are several reasons not to pick XP for a given project. Some that I remember include lack of management buy in (XP can't be forced on a company), extremely large projects that can't(won't) be broken up, or too many dead-beat programmers to fail (although he only conceded to the most extreme example... one guy worked in a programmers union).

      XP isn't for every project.

  • sunday, Sunday, SUNDAY...
    At the Megaplex Arena,

    Extreme, In Your Face, Programming Action!!!!
    Java, Perl, C/C++, VB, and many, many more...

    Geek-tastic and nerd-a-riffic!
    Tickets going Fast!!!!!

    Remember, this Sunday at the Megaplex, EXTEREME Programming!
    We'll sell you the whole seat, but you'll only need the edge!

  • Can XP work? (Score:2, Insightful)

    by Tomster ( 5075 )
    Yes. I have ex-coworkers who are in a very XP environment. Things they have learned include:

    - XP is very tactical. You need someone at the strategic level guiding and leading.
    - Productivity drops significantly after about 40 hours per week (they collect detailed statistics about defect rates showing this).
    - Individual productivity appears to suffer, but the result of pair programming and short (two-week for them) iterations results in code that is easy to work on (read: good design) and very low on bugs (read: well written).

    They've put a lot of support around their XP team to make XP effective, in the form of tools, processes, and people (roles). Without that, I suspect they would be disorganized and chaotic.

    There's a time and a place for just about every methodology out there. XP is an effective approach to development as long as it's done in the right environment by people who understand (or can learn) how to make it work for them.

  • Since this thread is turning into a discussion about Extreme Programming I thought I would throw in my experiences with it. I work on a web application which when I first joined the project was run very much "by the seat of its pants". The project was in its infancy and we were in constant contact with customers who had wildly verying ideas of what the finished product should be. At that time we were testing/building constantly with no documentation other than code comments. We were also taking requests right until the release. For these reasons I say we were doing Extreme Programming. Our customers loved us and we quickly made the project one of the top projects in a very large company. On a side note I have often wondered if Extreme Programming is a simply a justification for what programmers tend to do when left on their own. Well then our success bit us in the butt. The big wigs took notice and labled us "Mission Critical". Now we spend more time documenting the application then writting code. Any requirement a customer wants has to go through several levels of review, and they are never accepted just before a release. Management now "measures" quality by number of defects openned on a release. (Yes I too reject the whole notion of measuring a quality by the counting of ANYTHING). Releases now take longer, frustrate customers more, and have lowered the moral of the developers who now feel they are simply documentation monkeys. Yet Management insists the project is better than before. The moral of the story I have taken away from this experience is that even if extreme programming is the better method for a given project management will regect it. It results in more defects being found, more change which scares the hell out of management types, and finally code which isn't well documented so that management can't replace skilled help with code monkeys at a moments notice. You don't have to count beans to make coffee. However, management won't let you make coffee at all without knowing how many beans are in each cup.
    • From what you have said, you were not doing extreme programming.

      With XP you would have gathered your stories first... (requirements) After that you'd have decided which stories were important for that release, and then you would've worked on implementing *those stories* in that specific release... You would not have included more stories than you could actually complete in your release cycle. Your managers would've been perhaps following the metrics recommended by the big blue XP book also, if they were really into measuring things.

      Were you doing unittests? If so, you might have had managers measuring the number of unittests as a metric... perhaps measuring the number of functional test that were passing fo the stories that were in that release... just ideas...

      I'm glad you were able to rant, however, don't confuse what you experienced with extreme programming.... you are the victim of bad management.

      • I will admit what I know about Extreme Programming is limited to a few things I haver read here and there so your probably right what we were doing was probably not Extreme Programming. I was making the association based on little or no documentation, greater interaction between developers and customers, and changing requirements. I understood these to be qualities of Extreme Programming, but thats probably not the whole picture. Well thanks for listening to my rant :)
  • I have this book and I'd almost recommend it but I think that the main point that needs to be made is that it's not about extreme programming (despite the title), it's about various tools that have come out of the Java (and XP) community.

    The title is a very unfortunate marketing ploy. I say unfortunate because putting XP in the title will probably drive away Java programmers who don't care for XP.

    But the tools it discusses (Ant, JUnit (and family), and JMeter) are applicable to any Java project, regardless of your development methodology. And beyond the first twenty pages or so of the book, the authors really don't mention XP.
  • Extreme Programming.

    It's a (GOOD) marketing brand for a loose set of unrelated ways of trying to solve complex problems in the field of application programming. Not much more.

    XP will work for talents (and a few trainees) who, if left alone, would probably work somewhat like that, not for "people" in general, and especially not for the workplaces that need a "development model", and sees XP as a Solution (yes the "S" is on purpose :).

    Although people in general (especially the one who should not use XP) think it's great -- I fail to see the benefits, beyound rationalizing and "memorizing" the way talent's work.

    Educated: Someone with a vast knowledge about a problem-domain, and means (often approximating algorithms) to recognize problem/solution pairs.

    Talent: Someone who "just does stuff", doesn't have to think about it. Often turns out to outperform educated people by doing "The Right Thing", even when they should not be able to :)

    Educated Talent: Rare! explosive mix! Hire at all cost!

    PS: I don't think of myself as talented at more than 2-3 (smaller) things/fields.
  • Maybe not Extreme but I find it useful
    BlueJ [bluej.org]
  • Sounds like the Extreme Fajitas from the Tchotchke's chain restaurant in the Office Space movie.

    Would you like some Extreme Programming? Some nachos?

  • I am a CS major with focus on software engineering. I have been working with XP and agile methodology for some time, and doing some research to apply these principles on geographically distributed projects open source projects in particular. I also started doing some research on different ways to improve the development of open source projects. I haven't received much assistance or interest from the faculty at my CS department. I am wondering if anyone, or any school doing any related work? Or is there any project established that would help even improve more open source development. I think there is a lot of good things to be learned from open source development but better tools and an established methodology can even make open source software development faster, better quality, and easier.
    • I have an open source project that uses many of the principals of XP. The most important ones used to guarantee quality is heavy reliance on unit tests, acceptance tests and continuous integration. Much of the code was pair programmed but with a distributed application that is not always possible. Fortunately open source compensates by being so well geared to constant peer review. The name of the project is QuickFIX (http://quickfix.thoughtworks.com). It is an implementation of an open protocol used for financial transactions. It should be noted that this application is in production as a mission critical component in many financial institutions. In fact I know it is being used by one of the major online brokerages for routing customer stock trades.
  • One thing I really don't understand is why Ant reinvents the wheel.

    Many people have been using makefiles successfully for years, and, now, part of the Java community comes out and says, "Make sucks. Let's just throw it away (even though it is really mature) and start over from scratch (instead of implementing Make in Java)."

    I have found that the common arguments against Make really aren't very strong. The tab issue is really minor. The only issue that bugs me is that parallel builds aren't possible with most implementations. There are other more theoretical issues, such as the dependency graphing, etc., but I don't see Ant taking on these much more complex issues.

    My other peeve is that Ant is fairly Java-specific, while Make is really language-independent (I use it for Java, C, C++, release management, testing, etc.).

    Is the popularity of Ant really just a case of jumping on the bandwagon?

    • Re:Why Ant? (Score:4, Informative)

      by Orville ( 104680 ) on Monday April 29, 2002 @04:51PM (#3432107) Journal
      Well, a couple of years ago I was on a project where I was assigned the informal (at the time) job of 'build engineer'. I started off with Make, and adopted and 'fell in love' with Ant (so to speak). Here's why:
      • On the project, we had a large number of objects (near 500, if I recall correctly), including GUI, EJB, and 'normal' object classes. Just maintaining manifest files was beginning to be a problem.
      • Unfortunately, we had cross-platform issues. The 'main' builds were being done on a Solaris machine, but most development was being done on Windows machines. (JBuilder at the time was a Windows-only toy.) Installing versions of 'make' (even cygwin/gnumake) was not going to be practical. Any other version cost $$$.
      • I soon found out the true strength of ANT: it is extremely flexible and extensible to make 'hard' tasks very simple. Automated deployment to servers, unit testing, and release management can be done without knowing sometimes cryptic Makefile commands.)
      • Ant is initially geared towards Java, but can be used to compile anything that has a command line compiler. (I saw a talk given by Martin Fowler where he joked about annoying a Microsoft engineer by creating an Ant process that would automate builds and tests of Visual C++ files!)

      Ant isn't really 'reinventing' the wheel, but making the wheel easier to manage (one file) and extend (ant tasks). It's a neat tool to have in the arsenal; I personally have found it easier and more intuative than Make for more 'complicated' projects. (Now, if I could just create an Ant script to automate and test builds of Oracle Pro*C programs...)

  • The reviews for the book and comments on Amazon, TheServerSide.com, JavaRanch are very encouraging. Thank you all. And, thanks to SlashDot for reviewing the book on this forum...

    I'd like to thank some other folks.

    This book would not be possible without the great set of tools written for building and testing J2EE. I'd like to publicly thank James Duncan Davidson et al, Mike Clark, Vincent Massol et al, Kent Beck and Erich Gamma.

    James Duncan Davidson et al created Ant. The de facto build tool for Java. This is the glue for building applications and making continuos integration doable with Java.

    JUnit is the regression-testing framework written by Erich Gamma and Kent Beck. After looking at this code base you can see this framework screams with design patterns and solid OOP, and is central to Extreme Programming development with Java. It is as if these guys wrote *the definitive books* on Design Patterns and Extreme Programming--oh yeah they did!

    Russell Gold wrote HttpUnit, which makes functional web applications easy and fun. (It can also be combined with Cactus.)

    Mike Clark extended JUnit to provide JUnitPerf, which does load testing and performance testing. This code is an excellent example of how to extend JUnit. Mike Clark is also a really nice guy.

    Vincent Massol et al for creating the Cactus (was J2EEUnit). I use this tool every day at work to unit test JSP Tags and EJBs. This is a truly novel tool. (BTW Nicholas Lesiecki, the co-author of the book, is an active committer on this project.)

    Vincent Massol of Cactus contributed to the creation of the book. He reviewed the chapter on Cactus. His acknowledgement was accidentally omitted from the book during publication.

    I am not implying that anyone mentioned above endorses the book or name dropping. I just wanted to thank them for contributing their time and effort to create these tools and then just give them away! Without them this book would not exist.

    The book has been a bestseller under software development on Amazon most of this year. Thank you. We are blown away with the success of the book.

    Check out these threads about the book if you get a chance....

    Thread TheServerSide.com [theserverside.com]

    Nick and I answered a lot of questions about the book at the JavaRanch as well...

    Thread at JavaRanch [javaranch.com]
    I've posted some more background information about the book here...

    Book Web Site [rickhightower.com]

    I'll check back and try to answer any questions about the book. Thanks again.

    The web site will soon have a sample chapter on it. Later, when we write the second edition, the book web site will have early drafts for review.

    --Rick Hightower Co-Author of Java Tools for Extreme Programming
  • Link to book web site [rickhightower.com]

    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.

    There are other great books that cover other aspects of Extreme Programming. This book focuses on Automated Testing and Continuous Integration.

    The book does mention XP throughout, but does not cover all other practices of XP in detail. This book focuses on the mechanics of XP. Other books cover the philosophy of XP quite nicely and there was no need to repeat it in this book. There is an introduction to all aspects of XP, however, the focus is on Automated Testing and Continuous Integration.

    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.

    There are some really great books on XP. Three of my favorites are as follows:

    Extreme Programming Explained: Embrace Change by Kent Beck

    Planning Extreme Programming by Kent Beck, Martin Fowler (favorite)

    Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by Scott W. Ambler

    You will enjoy this book as it covers topics not covered in other books, i.e., essential topics that are critical to J2EE and Java development. This book is highly rated and is doing very well. If you are thinking about buying a copy check out these reviews reviews [rickhightower.com]

Slashdot Top Deals

"Say yur prayers, yuh flea-pickin' varmint!" -- Yosemite Sam

Close