Editor's note: In the previous excerpt from Java Extreme Programming Cookbook we showed you how to create a mock implementation of an event listener interface, and how to avoid duplicated validation logic in your tests. This week we offer a sampling from Chapter 8 ("JUnitPerf") on creating a load test, and one from Chapter 9 ("XDoclet") on executing a custom template. |
Editor's note: The first recipe we plucked from the pages of Java Extreme Programming Cookbook showed you how to set up an efficient development environment using an Ant buildfile. In these two recipes, excerpted from Chapter 6 on "Mock Objects," learn how to create a mock implementation of an event listener interface, and how to avoid duplicated validation logic in your tests. And check back here next week for recipes on creating a load test and executing a custom template. |
Editor's note: In this first sample recipe from O'Reilly's Java Extreme Programming Cookbook (from Chapter 5 on "Ant"), you'll learn how to set up an efficient development environment using an Ant buildfile. In the coming weeks, we'll offer sample recipes from the book on Mock Objects, JUnitPerf, and XDoclet, so check back here over the next few weeks to sample the latest recipes. |
My recommendations from "XP distilled" remain the same: The whole is greater than the sum of the parts. You can implement single practices or a small subset, and get great benefits over not using any. But you only get the maximum benefit if you implement all of them, because their power comes from their interaction. Do XP by the book at first as a benchmark. Once you understand how the practices interact, you will have the knowledge you need to adapt them to your context. Remember that "doing XP" is not the goal; it is a means to an end. The goal is to develop superior software quickly. If your process mutates in a manner that disqualifies you from saying you are doing XP, yet your results are blowing the doors off your competitors, you have succeeded. |
To run the Ant script, go to the Resource perspective, right-click build.xml, and select Run Ant. That brings up a dialog with the default target already selected. Click Run. If there's a failure, Eclipse will show the Ant Console at the bottom of the screen. This is my biggest gripe about Ant: if something goes wrong, debugging can be a bear. Fortunately, the Echo Ant target gives you the equivalent of System.out.println(). If something goes wrong in your script, stick some helpful message in there to help you figure out what's going on. In the current case, the error is a tricky one. Ant complains that it can't find tools.jar. You need to tell Ant where to find the Java classes necessary to compile stuff. To do that, follow these steps: |
Roy W. Miller has been a software developer and technology consultant for almost ten years, first with Andersen Consulting (now Accenture) and currently with RoleModel Software, Inc. in North Carolina. He has used heavyweight methods and agile ones, including XP. He co-authored a book in the Addison-Wesley XP Series (Extreme Programming Applied: Playing to Win and is currently writing a book about complexity, emergence, and software development. Contact Roy at [email protected]. |
Last time I talked a bit about software development projects focusing on business value to drive your projects. Devoting time and money to making software simply because somebody told you to isn't a good business reason (although it may be a good way to keep your job). In the end, if the software your team makes doesn't provide value to the business, it's not worth whatever your project sponsor paid for it -- a fact he'll eventually discover. |
|
Talk about a tall order. The sad truth is that traditional software development has consistently not delivered. One of the primary reasons is probably one of the least expected: customers haven't done their job. Before I explain, you need to understand what "the customer" for an XP project looks like. |
Today's application development environment is as fast paced as ever. Many development shops are turning to application development methodologies, such as Extreme Programming (XP), to help them effectively manage their development processes and quickly create code that meets user expectations and is of high quality. Many development shops also are relying on powerful Integrated Development Environments (IDEs), such as IBM VisualAge for Java, to help them quickly develop and assemble complex applications. |
It has been a year since Chris Collins and I wrote "XP distilled," and a good bit has changed since then. Extreme Programming (XP) has grown up some, and more people are implementing it in their organizations than ever before. But even with XP gaining ground and the resultant buzz this has created, there is still a great deal of confusion and debate about what XP is and is not. Not surprisingly, even Microsoft has contributed to the confusion by labeling its latest operating system "Windows XP." |
You can see more about Java Tools for eXtreme Programming and order the book at amazon.com. You can also order a copy of this work by calling 1-800-CALL WILEY or visiting the Wiley Web site. |
Pairing can be discussed at two levels. The first level is mechanical -- the raw description as to what constitutes "pairing." The second, deeper level is the interpersonal. Pairing is about relating to the people you work with as part of a team. That's the most challenging part of work -- relating to people you're not related to because (most often) somebody else told you that you must. Since every person is different, this can be a challenge, both for you and for others. As Ken Auer and I point out in Extreme Programming Applied (see Resources), interpersonal relationships are hard, especially in a professional environment where politics and hidden agendas can complicate things. Even if just for a few hours, these types of relationships are not something most people are interested in. This is a radical idea, and it isn't for everyone. But it also can produce some of the most rewarding experiences of your professional career. |
When you try to design to an extremely low level of detail before you start writing code you plan to keep, you're assuming you can know what the end result should look like. That's a dangerous assumption. If things change while you're in the middle of coding, your design becomes invalid. There are three ways you can handle this likely situation: you can deny it will happen and just rigorously adhere to your design. The result, however, is that users get the system they thought they wanted when the project started, not the system they end up wanting when the project's done. |
Is it hopeless? Are you stuck forever? Well, yes, if you don't start behaving differently. I'm not an expert on the thought process; I can only speak from experience. Sometimes I believe you should first try to think differently, then that will influence your behavior. Most of the time, though, that doesn't work for me. I have to behave differently first. My thinking comes around later. The best approach for me is to behave differently with the intention of changing the way I think. This is where XP can help. |
This article describes the experiences of one development team that has successfully adopted many of the eXtreme Programming (XP) principles and values in their development methodologies. |
Extreme Programming (XP) is a formalization of a set of methods that have been shown to work well together. It is based around the idea that the cost of change for a software development project does not need to rise throughout the life-cycle of the project. If the cost of change can be leveled off then the attitude toward the development process can be radically rethought. |