Slashdot Mirror
Java Tools For Extreme Programming
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:
- Introduction and Key Concepts
- Introduction to Extreme Programming
- J2EE Deployment Concepts
- Example applications
- Mastering the Tools
- Continuous integration with Ant
- Building Java Applications with Ant
- Building J2EE applications with Ant
- Unit testing with JUnit
- Testing Container Services with Cactus
- Functional Testing with HttpUnit
- Measuring Application Performance with JMeter
- Load Testing with JUnitPerf
- API and Tag Reference
- Ant Tag Reference
- Ant API Reference
- JUnit API Reference
- Cactus API Reference
- 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 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
RC
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
One extreme programming tool written in Java which I haven't seen mentioned here is that of Naked Objects. I had play with it the other day and thought it quite a neat idea.
XP is for hackers who want to improvise, and upon whom nobody relies for their survival. If people built houses, bridges and planes this way we'd all be up in arms about the lack of quality.
This isn't true - XP is no more for hackers than any other type of programmer. At the core of XP is building quality in from the first stages. For example, one of the XP techniques, pair programming, though very intensive, increases quality through a continual peer-review - you have two coders going at the same code on one machine - any line of code that doesn't cut the mustard is more likely to be found.
Additionally, XP tends away from 'big-bang' integration scenarios by having early releases, regardless of size - this means the system is all working together from the beginning, and that bugs residing in different definitions of what an interface 'really' means are found early before they cause problems. If that wasn't enough, there is also a large concentration on testing - before writing the code, XP users are thinking 'how are we going to test this? Exactly? What are the exact criteria for success of this unit?'.
It isn't a tenet of XP that you 'continually change each piece'.
XP isn't a tool for hackers, it's got nothing to do with it. Nobody is saying 'don't design the architecture of your system', nor is anyone saying 'change things around until they work'.
thenerd.
The camels are coming. I'm in love.
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 and you can get more detailed progress of the tests.
-tim
Been under a rock for a while, haven't you? ;)
:) 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.
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!
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.
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.
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.
it's = "it is"; its = possessive. E.g., it's flapping its wings.
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
Nick and I answered a lot of questions about the book at the JavaRanch as well...
Thread at JavaRanch
I've posted some more background information about the book here...
Book Web Site
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
rick hightower dot com
Link to book web site
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
rick hightower dot com