Introduction

At JavaPolis 2006 I met Eric Evans where he gave a university session about his book Domain-Driven Design. The session was very intriguing and so I bought the book on the spot. It seemed to promise to teach me a lot about how to go about the difficult task of extracting a model from a real-life situation. Of course that same real life prevented me from reading the book for several years. So now I have finally found the time to actually sit down and read it. And just like it promised all those years ago, it gives a lot of hints, tips and tools to extract a model from a domain. An absolute must-read for programmers and architects. And preferably also to be read by managers, so they will hear from an experienced architect that modelling shouldn’t be done by ivory tower architects.

Part I: Putting the Domain Model to Work

This part of the book presents the basic goals of domain-driven development, it defines the terms used throughout the book and it gives an overview of the implications of using the domain model to drive communication and design.

Chapter 1: Crunching Knowledge

In order to get to a workable domain model which can be used to successfully build useful software, there are five necessary ingredients: binding the model and the implementation, cultivating a language based on the model, developing a knowledge-rich model, distilling the model into a deep model, and brainstorming and experimenting. These taken together can be labeled as knowledge crunching.

Chapter 2: Communication and the Use of Language

A domain model can and should be the core of a common language for a software project, the so-called ubiquitous language. The model is a set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight. These terms and interrelationships provide the semantics of a language that is tailored to the domain while being precise enough for technical development.

Chapter 3: Binding Model and Implementation

If the model can not or simply is not be used for implementation, then a lot of knowledge the analysts had is lost. Therefore the model and implementations should be tightly bound together (Model Driven Design). If the people who write the code don’t feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. Meanwhile, when a modeler is separated from the implementation process, he never acquires, or quickly loses, a feel for the constraints of the implementation. Therefore any technical person contributing to the model must spend some time touching the code and every developer must be involved in some level of discussion about the model and have contact with domain experts (Hands-On Modellers).

Part II: The Building Blocks of a Model-Driven Design

This part of the book condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. It focuses on bridging the gap between models and practical, running software. But the main point of this section is to focus on the kinds of decisions that keep the model and implementation aligned with each other.

Chapter 4: Isolating the Domain

The part of the software that specifically solves problems from the domain usually constitutes only a small portion of the software system, although its importance is disproportionate to its size. We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts wit hother concepts related only to software technology or losing sight of the domain altogether in the mass of the system. One approach is to use a layered architecture.

Chapter 5: A Model Expressed in Software

This chapter focusses on the individual model elements, such as associations, entities, value objects and services. Finally a discussion of modules will drive home the point that every design decision should be motivated by some insight into the domain. The ideas of high cohesion and low coupling can be applied to the concepts themselves. In a model-driven design, modules are part o the model, and they should reflect concepts in the domain.

Chapter 6: The Life Cycle of a Domain Object

Every object has a life cycle. Many of these are simple, transient objects. But other objects have longer life, not all of which are spent in active memory. Managing these objects presents challenges that can easily derail an attempt at model-driven design. This chapter will address these issues through three patterns. First, aggregates tighten up the model itself by defining clear ownership and boundaries, avoiding a chaotic, tangled web of objects. Next the focus turns to the beginning of the life cycle, using factories to create and reconstitute complex objects and aggregates, keeping their internal structure encapsulated. Finally, repositories address the middle and end of the life cycle, providing the means of finding and retrieving persistant objects while encapsulating the immense infrastructure involved.

Chapter 7: Using the Language: An Extended Example

The preceding three chapters introduced a pattern language for honing the fine detail of a model and maintaining a tight model-driven desing. This chapter presents an elaborate example showing the forces that apply and how the patterns of part II can resolve them.

Part III: Refactoring Toward Deeper Insight

This part of the book is about the challenge of assembling the building blocks into practical models that provide the payoff. It delves into modeling principles that can guide choices along the way to gaining deeper insight, and techniques that help direct the search.

Chapter 8: Breakthrough

The return from refactoring are not linear. Usually there is a marginal return for a small effort, and the small improvements add up. But some of the most important insights come abruptly and send a shock through the project. This chapter tells the story of one project and how they arrived at a very valuable deep model.

Chapter 9: Making Implicit Concepts Explicit

Many transformations of domain models and the corresponding code happen when developers recognize a concept that has been hinted at in discussion or present implicitly in the design, and they represent it explicitly in the model with one or more objects or relationships. Most such discoveries come from listening to the language of the team, scrutinizing awkwardness in the design and seeming contradictions in the statements of experts, mining the literature of the domain, and doing lots and lots of experimentation. Three ways of modeling less obvious kinds of concepts are explicit constraints, processes as domain objects and specifications

Chapter 10: Supple Designs

The ultimate purpose of software is to serve users. But first, that same software has to serve developers. When software with complex behavior lacks a good design, it becomes hard to refactor or combine elements. To have a project accelerate as development proceeds – rather than get weighed down by its own legacy – demands a design that is a pleasure to work with, inviting to change. A supple design. In order to get to a supple design you can use several patterns: intention-revealing interfaces, side-effect-free functions, assertions, conceptual contours, standalone classes, and closure of operations

Chapter 11: Applying Analysis Patterns

Deep models and supple designs don’t come easily. Sometimes we can get a leg up from other people’s experience when they have recorded that experience in the shape of an anlysis pattern. It hardly ever is the answer to your particular needs, yet it offers valuable leads in your investigation, and it provides cleanly abstracted vocabulary.

Chapter 12: Relating Design Patterns to the Model

Most of the patterns published to date are more technical in focus than the patterns explained in the book so far. Some, not all, of these can be used as domain patterns. Doing so requires a shift in emphasis. A discussion on the composite and strategy patterns demonstrates how some of the classis patterns can be applied to domain problems by thinking about them in a different way.

Chapter 13: Refactoring Toward Deeper Insight

Refactoring toward deeper insight is a multifaceted process. It will be helpful to stop for a moment to pull together the major points. There are three things you have to focus on: live in the domain, keep looking at things a different way, and maintain an unbroken dialog with domain experts.

Part IV: Strategic Design

This part deals with situations that arise in complex systems, larger organizations, and interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: context, distillation, and large-scale structure.

Chapter 14: Maintaining Model Integrity

The most fundamental requirement of a model is that it be internally consistent; that its terms always have the same meaning, and that it contain no contradictory rules. Total unification of the domain model for a large system will not be feasible or cost-effective. This chapter lays out techniques for recognizing, communicating, and choosing the limits of a model and its relationships to others. It all starts wit hmapping the current terrain of the project. A bounded context defines the range of applicability of each model, while a context map gives a global view of the project’s contexts and the relationships between them. This reduction of ambiguity will, in and of itself, change the way things happen on the project, but it isn’t necessarily enough. Once we have a context bounded, a process of continuous integration will keep the model unified. Then, starting from this stable situation, we can start to migrate toward more effective strategies for bounding contexts and relating them, ranging from closely allied context with shared kernels to loosely coupled models that go their separate ways.

Chapter 15: Distillation

How do you focus on your central problem and keep from drowning in a sea of side issues? Distillation is the proces of separating the components of a mixture to extract the essence in a form that makes it more valuable and useful. A model is a distillation of knowledge. As with many chemical distillations, the separated by-products are themselves made more valuable by the distillation process (as generic subdomains and coherent mechanims), but the effort is motivated by the desire to extract that one particularly valuable part, the core domain. Strategic distillation does all of the following: aids all members in grasping the overall design of the system and how it all fits together; facilitates communication by identifying a core model of manageable size to enter the ubiquitous language; guides refactoring; focuses work on areas of the model with the most value; and guides outsourcing, use of off-the-shelf components, and decisions about assignments. Most of the distillation patterns in this chapter show how to change the model and distill the core domain. However, domain vision statement and highlighted core show how the use op supplemental documents can, with a very minor investment, improve communication and awareness of the core and focus development effort.

Chapter 16: Large-Scale Structure

Even with a modular breakdown, a large model can be too complicated to grasp. A “large-scale structure” is a language that lets you discuss and understand the system in broad strokes. Large-scale structure can save a project, but an ill-fitting structure can severely hinder development. This chapter explores patterns for successfully structuring a design at this level, like evolving order, system metaphor, responsibility layers, knowledge level, and pluggable component framework.

Chapter 17: Bringing the Strategy Together

The preceding three chapters presented many principles and techniques for domain-driven strategic design. In a large, complex system, you may need to bring several of them to bear on the same design. The three basic principles of strategic design (context, distillation, and large-scale structure) are not substitutes for each other; they are complementary and interact in many ways. When you are tackling strategic design on a project, you need to start from a clear assessment of the current situation. This can be accomplished by the following steps: draw a context map, attend to the use of language on the project, understand what is important, find out if the technology of the project work for or against a model-driven design, find out if the developers on the team have the necessary technical skills, and find out if the developers are knowledgeable and interested in the domain. Another important question is about who sets the strategy. Traditional handing down of architecture doesn’t usually work well. Strategic design, by definition, must apply across the project. Six essentials for making strategic design decision making work are: decisions must reach the entire team, the decision process must absorb feedback, the plan must allow for evolution, architecture teams must not siphon off all the best and brightest, strategic design requires minimalism and humility, and finally objects are specialists; developers are generalists.

Conclusion

Looking back on some projects described in the book and where they went after the involvement of the author ended, it can be concluded that wrestling a complex domain into a comprehensible software design is an exciting challenge for strong technical people. What is needed are tools that allow sharper ways of exploring domain models and expressing them in working software. But though improved tools will be valuable, we mustn’t get distracted by them and lose sight of the core fact that creating good software is a learning and thinking activity. Efforts to automate what must be the product of thought are naive and counterproductive. With the tools and technology we already have, we can build systems much more valuable than most project do today.

At JAOO 2008 I was in a tutorial by Linda Rising called Fearless Change. It was a great workshop about how you could use certain patterns to introduce changes into your organisation. It was also the one tutorial I could almost literally recite to my boss over dinner that night. It was so good, that we decided to buy the book about those patterns. It’s been on my shelf for a while, but I finally made some time to read it and summarize it. And the book was every bit as good as the workshop was. If you ever think of changing anything, you’ll want to read this book. It won’t completely change the way you think about the world, most of what is in it is actually common sense. But as they say in the book under pressure you often leave your common sense behind and that’s why they wrote this book, to remind you of your common sense. Below is a summary of the book. (As is my wont I’ve tried to mainly use the authors’ own words.)

Part One – Overview

In part one it is explained what patterns for change are and a possible roadmap through all the patterns is offered.

Chapter one: Organizations and Change

There are three factors that speed up or slow down the innovation-decision process: The Change Agent, The Culture and The People. The change agent is, most likely, you. You need three things to successfully share your idea: your belief in it, the drive to bring it into your environment and some information on how to do it. It’s obvious that culture will have a significant impact on the speed of the innovation-decision process for your colleagues. The process will be easier and faster if the culture support and nurtures new ideas, allows time for people to learn and do new things, is patient enough to support innovations that have benefits on the long term, accepts that a learning curve can be long, and does not consider failure to be a death sentence. But even in the most conservative cultures, small changes can happen. You will simply need a lot more patience because change will be slower. As you set off on your journey, you might want to remind yourself that the entity you want to change is not a thing, but a collection of individuals. Even when a culture is open to change, the people within it will accept the change at different rates. In a normal organization the people are divided into five groups: the innovator – who love change, the early adopters – who are open to change after some serious consideration, the early majority – who tend to follow their peers and accept change after it has been proven succesful, the late majority – who approach new ideas with skepticism and caution, and the laggards – who are the last to adopt new ideas, if they adopt them at all.

Chapter two: Strategies or Patterns

When you give a strategie a good name, it will stick in your mind easier. All these names together give you a language to speak about the strategies. The book uses a specific format to describe the patterns. It starts with the Name, followed by the Opening Story and a Summary of the pattern. Then comes the Context in which the pattern fits, followed by the Problem it solves. Then come the Forces that are in play, followed by the Essence of the solution, and some more information about that solution. Then comes a Resulting Context with positive and negative consequences. And finally some stories with known uses of the pattern.

Chapter three: Where Do I start?

The first few patterns to try are Evangelist, Test the Waters, Time for Reflection, Small Successes and Step by Step. Every change agent begins as an Evangelist, because unless you are really passionate about the new idea, others will not be convinced to leave the tried and true ways and follow you. Only a true and abiding belief can carry you through all the turmoil of the successes and failures you’ll encounter. Trying to change an organization by throwing out the old and wholesale bringing in the new is not advisable. Instead Testing the Wates with a gradual, experimental strategy that begins with a little investigating and experimenting to see if your idea has a chance in your environment has much more chance of succeeding. Time for Reflection suggest taking time out to learn from your experiments so that you can decide what patterns to apply next. This may seem trivial, but is of the greatest importance, as you don’t learn unless you think about what you’ve learned. Small Successes remind us to celebrate even the small things along the way, to keep us energized enough to overcome the inevitable failures we’ll encounter. Finally Step by Step cautions against doing too much and expecting results quickly. Innovations are best spread slowly and quietly, so you can learn from your failures and build on your successes.

Chapter four: What Do I Do Next?

The next step is to spark some influential support for the new idea with Connector, Guru on Your Side and Innovator. You should also recognize the power of Ask for Help and Just Say Thanks. The risk with introducing anything is that you can get caught up in the passion you feel for your vision and pretty soon others see this as “all about you”. Right from the beginning you should enlist others to help you avoid this trap. The Connector pattern describes those people who are valuable assets because they know “everybody”. Once you have a Guru on Your Side (a trusted expert), many who might have been skeptics up to that point will at least show interest in the approach and will be move open to what you have to say. The Innovator pattern tells us that a small percentage of the population likes new ideas and, therefore, is likely to take up the cause and eagerly do what they can to help you. Never forget the help you get from Connectors, Gurus, Innovators, or anyone else who joing your team. When people do something they consider quite ordinary or part of their job and you take time and thank them, they seem quite pleased.

Chapter five: Meetings and More

Some effective meeting patterns are Piggyback, Brown Bag, Do Food, The Right Time, Plant the Seeds, External Validation, Next Steps, Stay in Touch, e-Forum, and Group Identity. The Piggyback pattern recommends that you don’t do any work that you don’t have to. Instead, give your presentation as part of a regularly scheduled activity. If you do decide to schedule your own meeting, try the pattern Brown Bag and have your gathering over lunch time, when most people are free. Attendees bring their lunch and eat during the meeting. The pattern Do Food recommends using food because it is a powerful influencer. The Right Time is another pattern to keep in mind. For example, there are always better times than hitting a team right before a deadline. At the end of every event, consider the pattern Next Steps. Give people something to hang on to. If you have some interesting books or articles about your new idea, use the pattern Plant the Seeds and bring these materials to the meeting. The pattern External Validation is about lookingfor evidence that your suggested change will work from outside of your own organization. As you collect a list of interested people, think of good ways to use the pattern Stay in Touch. One way to stay in touch is the pattern e-Forum, an electronic forum that will allow you to communicate with a large group of people on a regular basis. If there is sufficient interest, at an appropriate point use the pattern Group Identity. Assigning an identity to your change initiative helps people become aware that it exists and what it is trying to do.

Chapter six: Take Action!

The patterns for the next bold step are Just Do It, Study Group and Mentor. The difference between perfection and excellence is that people striving for perfection are trying not to make any errors. People striving for excellence know that it’s impossible to avoid mistakes. So what should you do to learn? The answer is in the pattern Just Do It. Take a step on the path to your goal and learn as you go. Another way to learn more is to find a small group of like-minded folks who are willing to help you use the pattern Study Group. Each member of the group takes turns leading a session and preapring a “lesson”. While you are learning, you can begin to help others using the Mentor pattern. When teams are just beginning to apply an innovation, it can be invaluable to have someone around that knows more than they do, even if it is only a
little more.

Chapter seven: It’s All About People

Changing means interaction with people, the patterns for this are Personal Touch, Tailor Made and Shoulder to Cry On. When you use the pattern Personal Touch, you help each individual understand how the innovation can be useful in his own environment to solve his problems. The pattern Tailor Made adresses the same concern but at a different level. It is about how the innovation can meet the business needs of the organization. Sometimes you will need the pattern Shoulder to Cry On, as the road towards your goal will not always be an easy one. Like-minded people can help, not only to listen, but also to help thrash out possible
solutions to your problems.

Chapter eight: A New Role: Now You’re Dedicated!

In order to make the change effort part of your job we have the patterns Dedicated Champion, Local Sponsor, Corporate Angel, Early Adopter and Early Majority. To make real headway, you will have to have to be able to apply the pattern Dedicated Champion, that is, the change initiative must become part of your job description. The recognition that the change initiative is deserving of this attention will probably come from your boss, this is the pattern Local Sponsor. At some point you will also need the pattern Corporate Angel, so look for opportunities to capture the interest of a high-level executive, who can ensure that your work is aligned with business needs. Early Adopters need to be convince that the idea is useful to the organization, while those in the Early Majority need to be see that others have been successful before they are influenced to try the innovation.

Chapter nine: Convince the Masses

To convince others that change is good you can use the patterns Trial Run, Guru Review, Big Jolt and Royal Audience. The Trial Run is a powerful pattern, because most of the time, for most of us, change is difficult. The magic is in seeing the change as “temporary”. Suddenly, the new approach becomes a smaller threat. Sometimes resistors want data. To show that your idea has benefit for the organization, you can ask some respected individuals or gurus to evaluate it. This is the Guru Review pattern. When you have resources, you can apply the Big Jolt pattern and bring in an outside speaker. This allows you to take advantage of the considerable influence of well-known people. When you combine a Big Jolt visit with the pattern Royal Audience, you provide the opportunity for people to personally interact with the famous visitor.

Chapter ten: More Influence Strategies

Further influence strategies are Hometown Story, Smell of Success, Just Enough, In Your Space, Token, and Location, Location, Location. Take advantage of the experiences of the early adopters and use the Hometown Story pattern. Ask people to share their story in an informal forum where they can just talk about their experience and then interact in a question and answer session. The Smell of Success pattern recognizes that people will be drawn to the innovation when they hear about positive results. When people are asking questions and things are happening, it’s a good idea to keep the work-in-progress visible using the pattern In Your Space. Making sure the new idea is seen throughout your organization will have a positive impact on the rate at which people adopt it. Another way to keep something alive in people’s minds is to use the Token pattern. This simple influence strategy suggests that you hand out something for participants to take with them when they attend an event related to the new idea. As you schedule meetings related to the innovation, consider the important pattern Location, Location, Location. Having a meeting at another location can be a powerful motivator.

Chapter eleven: Keep it Going

It’s important to keep going, so use the patterns Involve Everyone and Sustained Momentum. Use the pattern Involve Everyone to bring in even those who might not have been a part of your original target population. The second equally important pattern advises that you’ll need to keep a Sustained Momentum. Our natural tendency is to stop and rest once things are underway, but we run the risk of losing everything if we don’t keep it going.

Chapter twelve: Dealing with Resistance

The patterns Fear Less, Bridge-Builder, Champion Skeptic, Corridor Politics, and Whisper in the General’s Ear
will help you overcome resistance. The pattern Fear Less urges you to use the skeptics as resources. Listen with an open mind to hear the other side and take the message to heart. No idea is perfect. We need to learn as we go and what better way than by hearing from everyone around us. Using the pattern Bridge-Builder to find the right person to “adopt” a skeptic can allow you to reach those who don’t find you credible. To make sure you have the objections of the skeptics before you, use the pattern Champion Skeptic. Recognize the contribution of a person who is good at looking at the negative side by officially giving him that duty. When there are important decisions to make, consider the pattern Corridor Politics. Politics are here to stay, and experienced change agents know that before a big vote is taken they should contact each individual who is voting to address any concerns or questions. Use the pattern Whisper in the General’s Ear to convince reluctant managers. The primary reason for using this approach is to begin to build a relationship with a high-level manager. While he may never become an enthusiastic supporter, at least he is less likely to block your efforts.

Part Two – Experiences

To illustrate how patterns can be used to introduce something new, this part of the book presents some actual user experiences.

Multiple Sclerosis Society Experience Report

One woman’s effort to build an international organization involved in research and support for patients with MS.

UNCA Experience Report

A medium-sized university introducing a new general education curriculum.

Sun Core J2EE Patterns Experience Report

Sun Microsystems, provider of hardware, software and services, introducing a specialized collection of design patterns.

Customer Training Experience Report

Introduction of a new approach at a large avionics company.

Part Three – The Patterns

This part of the book contains the patterns. In the book the patterns are described in the format as described in chapter two. For the summary I’ll use the list as used in the appendix of the book. (And as can be downloaded from www.lindarising.org.)

Ask for Help

Since the task of introducing a new idea into an organization is a big job, look for people and resources to help your efforts.

Big Jolt

To provide more visibility for the change effort, invite a high profile person into your organization to talk about the new idea.

Bridge-Builder

Pair those who have accepted the new idea with those who have not.

Brown Bag

Use the time when people normally eat lunch to provide a convenient and relaxed setting for hearing about the new idea.

Champion Skeptic

Ask for Help from strong opinion leaders, who are skeptical of your new idea, to play the role of “official skeptic.” Use their comments to improve your effort, even if you don’t change their minds.

Connector

To help you spread the word about the innovation, Ask for Help from people who have connections with many others in the organization.

Corporate Angel

To help align the innovation with the goals of the organization, get support from a high-level executive.

Corridor Politics

Informally work on decision makers and key influencers before an important vote to make sure they fully understand the consequences of the decision.

Dedicated Champion

To increase your effectiveness in introducing your new idea, make a case for having the work part of your job description.

Do Food

Make an ordinary gathering a special event by including food.

e-Forum

Set up an electronic bulletin board, distribution list, listserve, or writeable Web site for those who want to hear more.

Early Adopter

Win the support of the people who can be opinion leaders for the new idea.

Early Majority

To create commitment to the new idea in the organization, you must convince the majority.

Evangelist

To begin to introduce the new idea into your organization, do everything you can to share your passion for it.

External Validation

To increase the credibility of the new idea, bring in information from sources external to the organization.

Fear Less

Turn resistance to the new idea to your advantage.

Group Identity

Give the change effort an identity to help people recognize that it exists.

Guru on Your Side

Enlist the support of senior-level people who are esteemed by members of the organization.

Guru Review

Gather anyone who is a Guru on Your Side and other interested colleagues to evaluate the new idea for managers and other developers.

Hometown Story

To help people see the usefulness of the new idea, encourage those who have had success with it to share their stories.

In Your Space

Keep the new idea visible by placing reminders throughout your organization.

Innovator

When you begin the change initiative, Ask for Help from colleagues who like new ideas.

Involve Everyone

For a new idea to be successful across an organization, everyone should have an opportunity to support the innovation and make his own unique contribution.

Just Do It

To prepare to spread the word about the new idea, use it in your own work to discover its benefits and limitations.

Just Enough

To ease learners into the more difficult concepts of a new idea, give a brief introduction and then make more information available when they are ready.

Just Say Thanks

To show your appreciation, say “Thanks” in the most sincere way you can to everyone who helps you.

Local Sponsor

Ask for Help from first-line management. When your boss supports the tasks you are doing to introduce the new idea, you can be even more effective.

Location, Location, Location

To avoid interruptions that disrupt the flow of an event, try to hold significant events off site.

Mentor

When a project wants to get started with the new idea, have someone around who understands it and can help the team.

Next Steps

Take time near the end of an event about the new idea to identify what participants can do next.

Personal Touch

To convince people of the value in a new idea, show how it can be personally useful and valuable to them.

Piggyback

When faced with several obstacles in your strategy to introduce something new, look for a way to piggyback on a practice in your organization.

Plant the Seeds

To spark interest, carry materials (seeds) and display (plant) them when the opportunity arises.

The Right Time

Consider the timing when you schedule events or when you ask others for help.

Royal Audience

Arrange for management and members of the organization to spend time with a Big Jolt visitor.

Shoulder to Cry On

To avoid becoming too discouraged when the going gets tough, find opportunities to talk with others who are also struggling to introduce a new idea.

Small Successes

To avoid becoming overwhelmed by the challenges and all the things you have to do when you’re involved in an organizational change effort, celebrate even small successes.

Smell of Success

When your efforts result in some visible positive result, people will come out of the woodwork to talk to you. Treat this opportunity as a teaching moment.

Stay in Touch

Once you’ve enlisted the support of key persons, don’t forget about them and make sure they don’t forget about you.

Step by Step

Relieve your frustration at the enormous task of changing an organization by taking one small step at a time toward your goal.

Study Group

Form a small group of colleagues who are interested in exploring or continuing to learn about a specific topic.

Sustained Momentum

Take a pro-active approach to the ongoing work of sustaining the interest in the new idea in your organization.

Tailor Made

To convince people in the organization of the value they can gain from the new idea, tailor your message to the needs of the organization.

Test the Waters

When a new opportunity presents itself, see if there is any interest by using some of the patterns in this language and then evaluating the result.

Time For Reflection

To learn from the past, take time at regular intervals to evaluate what is working well and what should be done differently.

Token

To keep a new idea alive in a person’s memory, hand out tokens that can be identified with the topic being introduced.

Trial Run

When the organization is not willing to commit to the new idea, suggest that they experiment with it for a short period and study the results.

Whisper in the General’s Ear

Managers are sometimes hard to convince in a group setting, so meet privately to address any concerns.

The DevDays event took place in Amsterdam last week, a one day event about software development. Behind it stands Stack Overflow, also known as Spolky’s software Q and A site, and himself of course. My overall impression was not great I have to say. Something that played role in my slight disappointment was the organization itself. I found the venue very small relative to the amount of people, pretty noisy since the catering facility was in the same room and most importantly quite cold; I spent most of the event wearing my jacket. Lunch was ok but the queue was incredibly long and the sandwiches not enough. Nevertheless, to give the organizers some credit, wifi was working fine at all times.

The day began with a very entertaining talk of Joel Spolsky about the debate between simplicity and power. Do we need all these features or is it better to keep it simple but guaranteed to work properly? Bringing Salginatobel Bridge as an example, he praised the combination of elegance and modesty; in other words software should hide its complexity behind a simple and easy to use interface. And what is the drive of humanity to do anything, even to write (good) software? According to Joel it is to become more attractive and increase the chances of copying our DNA I would agree with him here!

The next talk was about jQuery. I do not know that much about it, but I got the impression that the talk was more like someone summarizing its documentation. Even thought there were few interesting points, it wasn’t well delivered in order to catch my attention. After this, there was a talk about the QT toolkit, apparently pronounced cutie and not cute after Nokia’s acquisition of Trolltech. The talk pointed out QT’s platform independency, however not supporting for instance the iPhone; at least not yet… Last talk before lunch was a promotional talk of Joel Spolsky about FogBugz. Despite the whole marketing content I was pretty impressed by the capabilities of the tool: automatic velocity calculation, probability estimation of project completion by date, automatic creation of burn-down charts, ability to break a task in subtasks and estimate them instead of the whole task, code review support etc. I would like to give it a try!

The first talk after lunch was about Python. The speaker, Simon Willison, a bash and Python guru gave a live command line presentation, which I actually found really interesting and informative. The most useful tip for absolute Python beginners, like me, is the virtue of the interactive interpreter. You can first experiment as much as you want and then later create the real stuff using parts of your previous attempts, since the complete history is there for you. All in all, for the first time I was really persuaded for python’s benefits.

The following talk was about the Google App Engine. Nick Johnson deployed an application in very little time. One thing I didn’t like about it is the fact that it supports only relational databases at the moment. As far as language flexibility is concerned, it supports anything that can be compiled to Java bytecode with potential of extension in the future. The next presenter, Christian Heilmann, talked about Yahoo Development Network. Even though it wasn’t one of the talks that brought me to the event, I was positively surprised both by the content and the speakers presentation skills. What to take out if this talk? Check YQL, if you haven’t done it yet, an SQL like query language to manipulate data across the Internet.

Finally the day ended with a talk about ASP .NET MVC. Even though the demo was ok, I found the talk a little bit slow, so given the time of the day I spaced out and decided to leave a little bit earlier. Overall, for next year, I would probably give it one more try, but I would pay more attention at the list of speakers. Also, if it takes place in a different venue, it would be a plus.

In my search for new frameworks to try out, I came across a little web framework called Wicket. The idea to really separate the logic from the markup appealed to me, as well as the fact that you wouldn’t need as much JavaScript anymore. So I went looking for a book about the subject and found Wicket in Action written by some of the core contributors to Wicket. It was a tough job summarizing the book as it is crammed with lots of examples about what you can do with it. So please forgive me if the following is a bit dry, I can assure you that the book itself isn’t!

Part 1 Getting started with Wicket
This part of the book contains a quick introduction to Wicket so you can get started.

What is Wicket
Wicket is an open source web-application framework for the Java platform, which bridges the impedance mismatch between the stateless HTTP and stateful server-side programming in Java by providing a programming model that hides the fact that you’re working on a stateless protocol. With Wicket, you program in just Java and just HTML using meaningful abstractions.

The architecture of Wicket
The architecture of Wicket revolves around several objects that play a central role in request processing: Application, Session, SessionStore, Request, Response, RequestCycle, RequestCycleProcessor and RequestTarget. When Wicket determines that it should handle a request, it delegates the processing to a request-cycle object. The processing is done in four consecutive steps: decode request, determine request target, process events and respond.
In order to build applications, you would like to reuse as much as possible, so you don’t have to reinvent everything. To this end there are many Wicket components. Each of these components consists of three parts, also known as the component triad: the markup, the Java component and the model. The markup is only concerned with presentation, you’ll find no logic in it. The UI logic is encoded in the Java components. Models are optional and are an indirection for how to get the data that drives the Java components. Typically, components are meant for one purpose. Labels render text. Text fields handle text input. Repeaters repeat elements, and so forth. But in many cases, you want to use a certain component but add functionality that isn’t related to its core function. This is where behaviors come in, they allow you to extend components using composition. Behaviors are mainly used for —but aren’t limited to— modifying attributes of HTML tags and responding to events or calls to the components they’re bound to (their host components).

Building a cheesy Wicket application
In this chapter the presented knowledge is used to build a first application.

Part 2 Ingredients for your Wicket applications
In this part of the book several components, models and behaviors are introduced.

Understanding models
Models separate your domain layer from things in the view layer, but also bind them together to make a cohesive and neatly layered structure. Models are arguably the most crucial part of Wicket to understand because they can significantly affect your application’s performance and memory requirements. Because Wicket models mediate between the view and domain layer, they enable you to apply transformations on your data before you display it, or before you accept user input and propagate it to your domain layer. All components have a model property. Not all components do something with their model: several components work fine with no model value. From the point of view of the component, IModel acts as a bean property: it has a getter and a setter. Depending on the model implementation, the value can be local and self-contained within the model, or it can be looked up dynamically and come from a domain object. Conversely, from our point of view, the model acts as the actual value of the component. The most commonly used model classes provided by Wicket are: Model, PropertyModel, CompoundPropertyModel, LoadableDetachableModel, ResourceModel and StringResourceModel. The choice between these models depends on the requirements on the model, should it be static or dynamic, does it need to be solve serialization issues, are there lots of properties that use a model, do you need to serialize all the data in the model. Finally models can be nested to combine the advantages of several types of models.

Working with components: labels, links, and repeaters
There are many Wicket components that can be used to build your applications. This chapter discusses the most basic ones. There are several components for displaying text of which the two most important ones are Label and MultiLineLabel. Then there are three components for navigation using links, ExternalLink, BookmarkablePageLink and the special markup tag <wicket:link>. Another category of components are those to respond to client actions, namely Link, AjaxLink and AjaxFallbackLink. And the final category of the chapter contains the components for repeating markup: RepeatingView and ListView. All of these components can be hidden when necessary. The markup attributes can also be changed.

Processing user input using forms
The Form component groups controls that take user input and processes them when they’re submitted. A form has an HTML part and a Java (Wicket) part. A form is used to get input from users in the form of text fields, selection boxes, radio buttons, check boxes, buttons, and more. The form groups input controls and processes all of them together when the form is submitted. Unless told otherwise, Wicket uses the post method by default to submit forms. Wicket supports three strategies for handling form submissions, configured at the application level: no redirect, redirect to buffer, redirect to render. On the server the form submission is processed in five steps: checking required input, converting the input from string to the model type, validating the converted input, pushing the converted value to the model. A failure in any of these steps stops further processing for the field that failed. When even one field has failed any step, the last step (push input) isn’t performed for any of the fields and onError is called. After the five steps have been executed either onSubmit or onError is called.
There are many Components that can be used to let the user provide input to the form. First there are the text input components: TextField, Password and TextArea. Then there are the components that let the user select from a list of items: ListChoice, DropDownChoice, RadioChoice, ListMultipleChoice and CheckBoxMultipleChoice. For this last category it is quite common to bind the components to a model that fetches the data from some other source than the Java code. In such a case it might be convenient to use a ChoiceRenderer to bind the value and the display text to certain properties of a Java Object that represents the object. Finally there is also the CheckBox to represent boolean properties. A third category of components contains components for submitting the form data. This category contains Button, SubmitLink and AjaxSubmitLink. In order to make a cancel button, you will have to tell it to skip form processing, or in case you want to keep the values, only the validation. Then there is the validation itself. Fields can be required, and validators can be added to them. Wicket supplies a large number of validators, among them the NumberValidator, StringValidator, PatternValidator, EmailValidator, UrlValidator, EqualPasswordInputValidator. It’s also very easy to write your own validators.
The last aspect of forms is the feedback. Wicket comes with many feedback messages in various languages. The messages are provided in resource bundles and can be customized. Besides the validation messages you can add your own messages at different levels of severity (info, warn, and error). To display these messages you have to add a FeedbackPanel. The feedback panel also lets you filter for certain kinds of messages.

Composing your pages
Another issue where Wicket has lots of components to help you out is the issue of grouping and distributing components to maximize reuse and minimize maintenance costs. For grouping on pages there are three options: grouping using a WebMarkupContainer, grouping using a Panel, and grouping using a Fragment. A WebMarkupContainer groups components directly in the markup and Java code. No extra files are necessary. It should be used when the grouped components aren’t reusable, but they need to act together for Ajax updates or visibility changes. This approach is also helpful to modify attributes of a markup tag. A Panel groups components in a separate markup file and Java class. It should be used when the grouped components are to be reused in different pages, or contributions to the header are necessary. And finally a Fragment groups components in a separate component hierarchy outside the normal hierarchy, but inside the markup file. Also known as an inline panel. It should be used when the grouped components are inherent to the page/panel they’re part of and aren’t reusable in other pages/panels.
The other half of the equation in this chapter is page composition. There are three options for composition: using plain pages, using markup inheritance, and using panels. The main disadvantage of using plain pages is that all things that are on both pages have to be duplicated. With inheritance you can create a base page that contains all the components common to all pages. This base page can then put a special tag “wicket:child” in the place where the specific components have to be put for all the pages that extend the base page. All the pages that extend the base page have an element “wicket:extend” to indicate that everything between those tags has to be put in the child element. All the elements from the child page are added to the base page. This leads to problems when the child tag is wrapped in another tag, like a form. You would expect the components of the child page to be added to the form in that case, but that is not the case. This can be achieved however by turning the container into a transparent resolver. The final option is to put the common functionality in a single page and using panels to swap parts of the page with new content. To decide on which of these strategies to use there are four criteria that should be considered: previewability, duplication, navigation and bookmarkability. Since neither of the three strategies fulfills all criteria, there is no clear preferred solution.

Part 3 Going beyond Wicket basics
In this part of the book they show how to build your own components.

Developing reusable components
Wicket has a lot of abstract classes that can be used to create custom components. Making these reusable is as easy as putting the implementation code in it’s own class. Compound components can be easily created by placing components on a Panel. In order to make a compound component into a form component the FormComponentPanel has to be extended. To keep the models of the nested components and the top component synchronized, we need to override two methods: onBeforeRender, which prepares for rendering, and convertInput, which handles receiving input. onBeforeRender is defined at the level of the Component base class.

Images, CSS, and scripts: working with resources
There are some things you can’t do with Components. For example, you can’t render PDFs with them, and they don’t provide a direct answer to how images or CSS files should be handled. Therefor Wicket supports adding resources to your project. Packaged resources are resource that are packaged along with all the rest of your code, without the configuration hassle that marks most other frameworks. Packaged resources can be added to a page using auto-linking (i.e. using the wicket:link tag in the markup). WebResource is a base resource class that can be used to work with streams. To host such a resource, a ResourceLink has to be added to the page, or the resource has to be turned into a SharedResource. To implement streaming, there is also the alternative solution to set the target of an onSubmit method directly ot the ResourceStreamRequestTarget. Resources can handle requests independently and stream responses back to the client any way they like. This makes them suitable for streaming content that isn’t rendered by Wicket, but by third party libraries.

Rich components and Ajax
Ajax is an acronym for Asynchronous JavaScript and XML. It stands for a whole range of techniques that have the same goal: letting browsers perform server round-trips in the background so that web pages can be updated without doing a full reload. Wicket ships with a specialized Ajax engine designed to be used with Wicket’s server-side components and behaviors. It is designed to be as minimal as possible and thus isn’t as feature rich as some other Ajax engines. The engine is geared toward the following: message-handling between the client and the server, repainting and hiding components, executing custom JavaScript sent by Ajax responses, dynamically adding JavaScript and CSS to the page, providing the meanse to debug/track the engine’s workings, and throttling and timeout functionality. Wicket ships with quite a few high-level Ajax components, such as: AjaxLink, AjaxSubmitLink, AjaxSubmitButton, AjaxCheckBox, AjaxEditableLabel, and AutoCompleteTextField. Beside these components there are also Ajax behaviors. Ajax behaviors are created by extending AbstractAjaxBehavior. There are also some standard implementations that are shipped with wicket like: AjaxSelfUpdatingTimerBehavior, AjaxFormComponentUpdatingBehavior, AjaxFormSubmitBehavior and AjaxFormValidatingBehavior.
Contributing to the header section of pages is crucial for many components. This ability of individual components and behaviors to contribute to the page’s header is called a header contribution. One option to make a header contribution is by adding a HeaderContributor. Another option is by overriding the renderHead method in an Ajax behavior. The third option is to add the wicket:head tag to the markup.
If you want to use a third-party Ajax engine, you typically start by creating an abstract base class for that engine. That base class should extend AbstractAjaxBehavior. The minimal thing the base class then does is ensure that the proper JavaScript is contributed when the host component is rendered. You also want to be sure the common JavaScript is contributed only once for all behaviors that use the same engine, and you want to encapsulate these contributions so clients don’t have to know anything about them.

Part 4 Preparing for the real world
This final part of the book deals with some final aspects to get your application ready for the big, bad world that is out there.

Securing your application
With Wicket, if you don’t code using bookmarkable pages, you use session-relative pages. Page instances are kept on the server, and you ask Wicket (through your browser) for a certain page by providing the page number, the version, and the component that is the target of the request.
A good place to store authorization information is in the Wicket session object, because it’s available throughout the user’s session. Wicket creates sessions for users automatically. A simple form of authentication uses a sign-in page with a user name and password field in a form. It is good practice to have this form extend StatelessForm, so that the page doesn’t expire. The onSubmit method of the form should then handle the actual authentication.
Wicket uses authorization strategies to implement authorization as a cross-cutting concern. In order to create your own strategy, you have to implement IAuthorizationStrategy. One option of using such a strategy is by creating a base secured class that protected pages must extend. Another option is using annotations to mark the protected pages.
Finally the wicket-auth-roles and the WASP/SWARM projects are mentioned. Both are projects that have built standardized security mechanisms to support Wicket.

Conquer the world with l10n and i18n
Localization refers to the adaptation of your application for one or more specific locales. A related term is internationalization, which encompasses all techniques that enable applications to be localized: being able to conveniently maintain different languages, handling different date and number formats, using the proper encoding type, and so forth. For the sake of simplicity, the authors use only the term localization, even if it sometimes would be more precise to talk about internationalization. The most important aspects of localization are alphabets and scripts, and formats. To support multiple languages you can put all the locale-dependent parts in separate files and then using the wicket:message tag to look up those parts. The pattern for looking up these files is:

session = The current user session
component = The component that initiated the resource lookup
name = The name of the class of the component that is currently input for the search, starting with the name of component
style = [component.variation" "_" "[session.style" "_" "]]
ext = (”.properties” /”.xml”)
path = name["_"style["_" language["_" country]["_variant"]]]ext

Instead of using <wicket:message> tags, you could use normal Label components with a ResourceModel. Another option is to use localized markup files. The disadvantage of this however is that there will probably be a lot of duplication.
Wicket has a mechanism for handling objects that have different string representations depending on the locale. The objects responsible for such conversions in Wicket are called converters. Wicket’s default configuration is probably good for 95% of use cases. But the default configuration may be insufficient at times. If that is the case you can write a custom converter. This can be done by overriding the getConverter method in a field. Or you can create a converter locator that knows where to get converter instances for the appropriate types.

Multitiered architectures
This chapter gives an overview of how to set up Spring and Hibernate to create a multitiered architecture for your application.

Putting your application into production
Before you can put your application in production you have to test it, create a site map that is optimized for your users and search engines, and configure the application for production. Then finally you’ll want to keep an eye on it once it is in production.
In order to test you Wicket application you can use the WicketTester class combined with JUnit. This class has methods like startPage, assertLabel and onClick to test-drive the pages and components as if they were called during a normal request.
The regular session-relative requests aren’t very nice for your users, as they won’t be able to bookmark them. Search engines in particular can’t deal with them, which means that all the information in your application can’t be found. While that is sometimes a good thing, at other times it is not what you want. That is why they have provided the BookmarkablePageLink. This still doesn’t provide a URL that looks nice, but at least search engines can handle them. If you want a URL that looks nice as well, which is something that will help you score better in some search engines too, you will have to use mounting and URL encoding. Mounting is the process of converting the BookmarkablePageLink with a fully qualified classname into a specific path. Transforming something like:

http://cheesr.com/shop?wicket:bookmarkablePage=%3Acom.cheesr.shop.CheeseDetailsPage&cheese=edam

into something like:

http://cheesr.com/cheeses/cheese/edam/

By using URL encoding strategies, this can be optimized even further. Wicket provides several strategies like: QueryStringUrlEncodingStrategy, BookmarkablePageRequestTargetUrlCodingStrategy, IndexedParamUrlCodingStrategy, MixedParamUrlCodingStrategy, HybridUrlCodingStrategy and IndexedHybridUrlCodingStrategy.
Wicket applications can run in two modes: Development mode, which provides maximum developer support, and Deployment mode, which provides maximum performance and security for production. By default Wicket starts in development mode. Before going to production the mode should be switched, either through a system property, a servlet/filter-initialization parameter or a context-initialization parameter. All of the options that are turned off by switching to deployment mode, can be turned back on again in the Application’s init method. Another part of the configuration of an application that should be done before production is providing meaningful error pages. Wicket does provide default error pages, but these don’t look very nice, so you might want to customize them. Beside the error page, the access-denied page, the internal-error page and the page-expired error page can also be customized.
Once your application is running on your server and delivering pages to visitors, you need to ensure that the application keeps running. This means monitoring the application and, when things go wrong, figuring out what happened and how to fix it. The request logger provides this information, but it does have to be enabled and configured. Another feature that Wicket has is that through the Java Management Extendsions (JMX) it allows you to look inside a running server and adjust parameters on the fly, so you can change the markup files in production without restarting the application for example.

Conclusion
Wicket in Action is the perfect book if you want to get started with Wicket. It gently guides you past all the important concepts in Wicket and gives you tons of examples to play around with. It points you in the direction of all the most important components that you might need. The code of the examples is also provided on a site accompanying the book, so you won’t have to type it all yourself. It’s also a good book if you’ve already been playing with the framework for a little while and want to really understand what it is you’re working with.

I had heard a lot about Maven and it sounded like a nice addition to the toolbox of a developer and thus I decided to dive into the subject. I quickly found the book “Maven: The definitive guide” by Tim O’Brien, John Casey, Brian Fox, Bruce Snyder, Jason Van Zyl, and Eric Redmond. This review/summary is based on version 0.22. The book is still a living book, so it is still under construction. On their website: http://www.sonatype.com/books/maven-book/pdf/maven-definitive-guide.pdf there is already a version 0.5 (which is apparently a later version). In the next few pages I have attempted to summarize the book, to allow you to decide for yourself whether you think the book is worth your time. I must note however that in some places I have left stuff out, as the summary would get too long. This is specifically in the areas where the book went into great detail. So if you want to know anything specific about Maven, go ahead and have a look at the website and take a look at the index to see if your subject might not be treated after all.

Introducing Apache Maven

The first chapter describes that Maven is a project management tool that relies heavily on convention over configuration. This means that a lot of things about your project do not have to be specified, such as the location of the source code. However most of these default can be customized. All these defaults together offer a common interface to building software, where a user can install a certain piece of software with a two word comman (mvn install). And while the core of Maven doesn’t do very much beside parsin a few XML documents and keeping track of a lifecycle and a few plugins, it can be extended very easily with a lot of plugins. Each of these plugins can be downloaded from a remote repository, where they are maintained centrally, so you don’t have to continually upgrade Maven to get new functionality. Everything about your project is described in the project object model, the coordinates, the license, the developers, etcetera. This model enables features like dependency management, remote repositories, reuse of build logic, tool portability, and easy searching of artifacts.

Installing and Running Maven

The next chaptergives detailed instructions on how install Maven and verify that it works. The paragraphs here are all pretty short, seeing how it is relatively easy to do. There are instructions for different operating systems, and also for upgrading and even uninstalling Maven.

Part I. Maven by Example

After these two introductory chapters Maven is “introduced by doing”. The chapters in this part are a long string of examples showing exactly how to use Maven.

A Simple Maven Project

The first example shows how to create a simple project from scratch using the Maven Archetype plugin. Guided by this example they show the default Maven file structure and explain that the project object model (aka POM) is stored in the file named pom.xml. They also give the commands that you can use to build, package and install the software. And finally they explain some of the core concepts of Maven, like plugins and goals, the lifecycle, coordinates, repositories, dependency management and site generation and reporting.

Customizing a Maven Project

The second example is a weather project, which is used to show customization. Contrary to the first example, this example is dependent on some other projects, and so these dependencies are added to the POM. The project also has some resources that need to be added to the classpath. By putting these files in the right directory (src/main/resources), no further configuration is needed, as Maven picks them up automatically. Then the application should be tested, unit tests are made and again put in the right directory (src/test/java) so no configurations is needed for the tests to be found, as testing is part of the lifecycle. The tests that are written do have some dependencies, and so the test-scoped dependencies are explained. Tests can also have resources (src/test/resources). Packaging and installing incur testing, but the lifecycle can also be made to stop after the test phase by calling mvn test. Finally the assembly plugin is demonstrated to put together a distribution that can be deployed on a server.

A Simple Web Application

The third example shows how to configure a web application. First of all the packaging tag needs to contain the value war instead of the default jar. Then they add the jetty plugin, so the application doesn’t have to be manually deployed. Thirdly a servlet is added and configured (in web.xml). To get the servlet working the servlet api is added as a dependency.

A Multi-module Project

A multimodule project consists of a parent module and several submodules. The parent module contains mainly the parent POM that references the submodules. For the fourth example they combine the weather project and the web application of the previous two chapters. The parent POM states that the packaging type is POM, defines the modules that the project consists of, and defines some setting which will be inherited by all submodules. All the submodules get an extra definition of the parent module. While building a multi-module project, the order in which the submodules are listed in the parent POM is maintained unless changes need to be made. For instance if one of the modules is dependent on the other.

Multi-module Enterprise Project

In this chapter they give an example of a small multi-module enterprise project that shows what a larger real life project might look like. They integrate Hibernate and Spring to show how this might be done. A lot of the chapter is in fact not spent on Maven at all, which shows the simplicity of Maven.

Optimizing and Refactoring POMs

In the final chapter of part I, the authors have a look at what they are left with after the last example. The first step in cleaning up a multimodule project’s POM is looking for duplication. The first duplication that is encountered is in the dependencies. This is cleared up by moving these dependencies to the dependencyManagement section in the parent POM. Then the versions of these dependencies in the submodules are removed, as they would otherwise override the dependencyManagement. The next step is to put the versions of several related dependencies into a property, so that they will never differ. After that the sibling dependencies inside the project itself are resoled by using ${project.groupId} and ${project.version} to denote the communal groupId and version.
After the dependencies, the plugins are optimized. Most complex Maven multimodule projects ten to define all versions in the top level POM. Then there is the pluginManagement section where duplicate plugins can be defined. To find used dependencies that are undeclared, the Maven Dependency plugin can be used (mvn dependency:analyze). It can also be used to find unused, declared dependencies, but this is a little trickier due to for example scoped dependencies.

Part II. Maven Reference

In this part of the book the blanks are filled in and the authors really dig into the details.

The POM

A Maven project is defined by the presence of a pom.xml file. While most of the examples in the book are geared towards Java applications, there is nothing Java-specific in the definition of a Maven POM. A POM contains four categories of description and configuration: General project information (name, URL, developers, etc.), Build settings (the behavior of the default Maven build), Build environment (profiles that can be activated for use in different environments), and POM relationships (as a project rarely stands alone). All Maven POMs implicitly extend the Super POM which defines a set of defaults shared by all projects, including the central Maven repository, the default plugin repository, the directories in the Maven Standard Directory layout, and the default versions of the core plugins. As all these defaults are specified (and therefor inherited by every POM), the simplest POM contains only the coordinates of the project (groupId, artifactId and version). Since POMs can inherit configuration from other POMs, you must always think of a Maven POM in terms of combination of the Super POM, plus any parent POMs, and finally the current project’s POM, where the lower level overrides the higher level (the Super POM being the highest level).
The dependencies described in the POM can both be internal (your own projects) and external (3^rd party libraries) dependencies. Each dependency has one of five scopes: compile (default), provided (when the JDK or container provide them), runtime (required to execute and test, but not to compile), test (required for testing only) and system (native jars). Dependencies can also be declared optional, when you don’t want them showing up as transitive dependencies in the project depending on this project. This does have the consequence that they have to be included in the project that is depending on this one. Further more, it is also possible to specify a range of versions that would satisfy a given dependency. Very convenient when a certain functionality you need has been added to a specific version, but been discontinued in a later version. Transitive dependencies are dependencies of dependencies. In Maven1 you had to specify all of these explicitly, but Maven2 is able to sort these out on it’s own, by building a graph of dependencies and dealing with any conflicts and overlaps that might occur. When a conflict does occur, they can be solved by for example excluding certain transitive dependencies (explicitly) and replacing them by another dependency (implicitly). Finally the versions of the dependencies can be managed in the parent POM by dependencyManagement.

The Build Lifecycle

The Maven lifecycle is the mechanism that allows Maven to act upon the objects in the POM. Such a lifecycle consists of a sequence of named phases. There are three standard lifecycles in Maven: clean, default and site. The clean lifecycle is the simplest, it deletes the output of a build by deleting the build directory. It consists of 3 phases, pre-clean, clean and post-clean. The default lifecycle is also called the build lifecycle. It consists of 21 phases, starting with validate, running through compile, test and package and ending with deploy. The third lifecycle is the site lifecycle, which consists of the four phases pre-site, site, post-site and site-deploy. This cycle produces the project documentation and generates a site for it.
The specific goals bound to each phase default to a set of goals specific to a project’s packaging. A project with packaging jar has a different set of default goals from a project with a packaging of war, pom, plugin, ejb or ear. But there are a lot of similar goals in many of the packaging lifecycles. Most of the lifecycles have goals for managing resources, running tests, and compiling source code.

Build Profiles

Profiles allow for the ability to customize a particular build for a particular environment; profiles enable portability between different build environments. Portability is a measure of how easy it is take a particular project and build it in different environments. A Maven profile is an alternative set of configuration which set or override default values. You can even conditionally activate a profile, if the decision whether to use it or not depends on some system variable, like the presence of a Java 6 compiler. As Maven profiles can be defined in a variety of sources there is no good way to keep track of shich profiles are available. Therefor the Maven Help plugin defines a goal, active-profiles, which lists all the active profiles and where they have been defined.

Maven Assemblies

Sometimes you’ll need to create an archive or directory with a custom layout. Such custom archive are called Maven Assemblies. They can be made with the Assembly plugin. With this plugin you can create your own archive recipe, called assembly descriptor, but there are also several built-in descriptors, such as bin, jar-with-dependencies, project, and src.

Properties and Resource Filtering

Properties are a convenient method of keeping your projects consistent. Maven has some implicit properties that are available in any project: project.* (used to reference values in a POM), settings.* (used to reference values from your Maven Settings), env.* (used to reference environment variables), and System Properties (used to reference any property that can be retrieved from the System.getProperty() method). In addition to these implicit properties there is also a set of arbitrary, user-defined properties.
In addition to these defintions, you can also use resource filtering to perform variable replacement on project resources. This feature has to be enabled first. This feature combines nicely with profiles, for example to reference an external resource such as a database for different systems.

Maven and Eclipse: m2eclipse

This chapter is replaced by an entire book: http://www.sonatype.com/books/m2eclipse-book/reference/

Site Generation

Maven can be used to create a project web site to capture information which is relevant to both the end-user and the developer audience. The most simple POM would generate a website that is mostly empty and not very useful. In order to fix this problem the site descriptor will have to be customized. You can easily alter for example the default menu and the logo of the site. All the files for the site should be placed under src/site, where there are different directories for different file formats like APT, FML and XDoc. Maven uses a documentation-processing engine called Doxia which reads multiple source formats into a common document model. To write document for your project, you will need to write your content in a format which can be parsed by Doxia, like the aforementioned APT, FML and XDoc. To deploy your site you’ll use the Maven Site plugin which can take care of deploying your project’s site to a remote server using a number of methods including FTP, SCP, and DAV.
The easiest way to affect the look and feel of your project’s web site is through the project’s site.css file (under src/site/resources). To change the page structure that is rendered by default, we can configure the site plugin in our POM to use a custom page template.

Repository Management with Nexus

This chapter is replaced by an entire book: http://www.sonatype.com/books/nexus-book/reference/

Writing Plugins

99 out of 100 Maven users will never need to write a custom plugin to customize Maven; there is an abundance of configurable plugins, and unless your project has particularly unique requirements, you will have to work to find a reason to write a new plugin. A Maven Plugin is a Maven artifact which contains a plugin descriptor and one or more Mojos. A Mojo can be thought of as a goal in Maven, and every goal corresponds to a Mojo. A Maven plugin contains a road-map for Maven that tells Maven about the various Mojos and plugin configuration, called a plugin descriptor. When you are writing custom Maven plugins, you will almost never need to think about writing a plugin descriptor. The lifecycle goals bound to the maven-plugin packaging type show that the plugin:descriptor goal is bound to the generate-resources phase. This goal generates a plugin descriptor off of the annotations present in a plugin’s source code. There are three parts to a plugin descriptor: the top-level configuration of the plugin which contains elements like groupId and artifactId, the declaration of mojos, and the declaration of dependencies.

Writing Plugins in Alternative Languages

Mojos can be written in Java, or in an alternative language. Maven has support for a number of implementation languages, and this chapter shows how to create plugins in three languages: Groovy, Ant, and Ruby.

Using Maven Archetypes

An archetype is a template for a Maven project which is used by the Maven Archetype plugin to create new projects. Archetypes are useful for open source projects such as Apache Wicket or Apache Cocoon which want to present end-users with a set of baseline projects that can be used as a foundation for new applications. Archetypes can also be useful within an organization that wants to encourage standards across a series of similar and related projects. Archetypes can be used by invoking the generate goal of the Archetype plugin via the command-line or with m2eclipse. There are already many archetypes out there, including the default Maven archetypes for creating a simple project with JAR packaging and a single dependency on JUnit, a web application, and a mojo. Then there are a lot of third-party archetypes, like AppFuse, Confluence and JIRA, and Wicket.

Conclusion

All in all, it is a very comprehensive book that is well worth your time to read it. The first part is perfect for beginners as it guides you gently into the Maven domain. The second part is perfect for the more advanced user who wants to know the details on some subject.

Introduction
In my quest to grow up to be an architect I came by the book ‘Organizational Patterns of Agile Software Development’ by James O. Coplien and Neil B. Harrison. It had the words Agile and Organization in it, so it seemed to offer some advice on how to turn your organization into an agile entity. Sitting on the bench, waiting for a book about Wicket to come in, I had some spare time and started reading it. And thus I found out that it really was what it promised.

I History and introduction
It started off with exploring what a pattern and a pattern language is. Their conclusion was that to understand a pattern, you’d need to know what a pattern language is, and to know what a pattern language is, you need to know what a pattern is. Indeed, recursion. And so they set off with an incomplete definition of a pattern as a configuration rule that contributes to the overall structure of a system and that works together with other patterns to create emergent structure and behavior. A pattern language is then defined to contain patterns and rules to combine those patterns in a meaningful way. In a pattern language, patterns can be combined in many different ways depending on context. An organizational pattern language is usually though of as describing the architecture of an organization. In this book they describe four different pattern languages, which will usually be used in parallel: Project Management, Piecemeal Growth, Organizational Style, and People And Code. The rest of part one talks about how they came to the patterns and how to use the book, which I will not go into in this review. Suffice it to say that they did a lot of research and have a lot of experience.

II The pattern languages
Part two explores the actual patterns in the pattern languages. Some of the patterns could be in several of the pattern languages, and where this was the case they have described it in the language where it most seemed to fit and put a reference in the other language(s). The four languages are split up into two groups: Organizational Design Patterns and Organization Construction Patterns. The first group is about the architecture, the relationships between the parts. The second group is about the daily reality of building an organization. Project Management and Piecemeal Growth fall into the first group and Organizational Style and People and Code fall into the second.

Project Management is all about the organizational aspects of managing projects. There are 26 patterns in this language. Some samples of these are mentioned below. The explaining text is in the shape of what they call patlets, which is a short summary of the problem and solution for a pattern. The text from the patlets is taken from the appendix.
Take no small slips
If you are getting behind schedule and you need additional time resources, Then: take one large planned slip instead of creating project instability and low team morale with small, unanticipated slips.
Developer controls process
If you need to orchestrate the activities of a given location or feature, Then: put the Developer role in control of the succession of activities.
Someone always makes progress
If distraction constantly interrupt your team’s progress, Then: whatever happens, ensure someone keeps moving toward your primary goal.

Piecemeal Growth of the organization is all about the ways in which an organization grows and develops over time. There are 32 patterns in this language. Here are some samples.
Size the organization
If an organization is too large, communications break down, and if it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore, start projects with a critical mass of about 10 people.
Self-selecting team
If you appoint people to a team, the people don’t come together as a team. People who share similar outside interests make the best team members. Therefore, teams should be largely self-selecting, performing limited screening of candidates based on their track record and outside interests.
Developing in pairs
If you want to improve the effectiveness of individual developers, Then: have people develop in pairs.

Organizational style is about the general approach to the way the organization works. There are 23 patterns in this language. Here are some samples.
Few roles
If your organization has high communication overhead and latency, Then: identify the roles in the organization and reduce the number of roles to 16 or fewer.
Producers in the middle
If your developers are somewhat lost, Then: make sure the producer roles are at the center of all communication.
Face to face before working remotely
If a project is divided geographically, Then: begin the project by inviting everyone to a meeting at a single place.

People and code is about the ways in which people affect code, and the ways in which the design of code affects people. There are 23 patterns in this language. Here are some samples.
Stand-up meeting
If there are pockets of misinformation or if people are out of the loop, Then: hold short daily meetings to socialize emerging developments.
Architect also implements
If an architect is in an ivory tower, he or she is out of touch with reality; yet someone needs to reconcile the high-level overview with practice. Therefore, ensure that the architect is materially involved in day-to-day implementation.
Standards linking locations
If development is separated geographically, Then: use standards to link parts of the architecture that cross geographic boundaries.

III Foundations and history
Then in part three, they investigate the principles behind organizational structure. First they explain the organization principles. Not every organization is ready for change. Dissonance often goes ahead of a resolution. This can take the shape of a team burnout, where a team feels that everything is better than the current situation. But burnout can also work against change, as the team simply tries to solve things by working harder and closing up to the outside world. But no change can take place as long as there is no open communication. Team-building excersises might be a way of bringing back trust to the organization and getting them to open up to change again. The best way to change an organization is to start with the healthiest team and go step by step. Introducing one pattern at a time. If a change doesn’t work, you should back out and try something else. So in order to change an organization, you need it to be stable. If it is ever in flux, you can’t see the results of the changes you make.
Not every pattern works for every team. Keep in mind that the patterns are meant as inspiration, to be adapted to fit the organization in question, with a little tweak a pattern might fit your team a lot better. Then there is also the issue that not every pattern can be executed by everyone, some are for developers, others are for managers. But all of them work on groups of people, not individuals. And the last point, which is mostly aimed at managers, is that people are inpredictable. It is mostly useless to determine a path through the patterns in advance. Simply go one step at a time, see what change it brings and then determine the next pattern to try.
The second chapter in part three looks at the anthropological foundations. Here the authors point to research that states that there are three kinds of learning: single loop learning, which is about changing the process, the how of things; double loop learning, which is about changes in insight, the why of things; and triple loop learning, which is about changing identity, who we are. Most organizations focus on single loop learning and process. But process alone does not suffice as software development is still not predictable enough. Organizations that focus on product function a lot better than those who focus on process, as the structural elements of the product will reflect itself in the structure of the organization. Focusing on process work only in a mature domain with predictable steps. In fact process must emerge from the structures of communication and production beneath it. Those structures, in turn, are held in place by the values of the organization. So why focus on roles instead of process. Roles define what is done, which is more stable than how it is done. And second, people identify with roles.

IV Case studies & Apendices
The fourth part of the book goes into some case studies, and shows how the patterns were at work there. Then in the appendix they give a nice summary of all the patterns (the above mentioned patlets).

Conclusion
Not all the patterns are equally clear to me, because sometimes two to three pages of description is just too short. But it is still a very good book. In fact every manager should read this book. It gives a lot of insight in how organizations and people work. It is also a very good read for everybody who is dissatisfied with the way their organization works, but who have no idea what to do about it.