If your team spends more than an afternoon deploying their product to a test region or to production then you need to start chipping away at this next step. Agile software development emphasizes working software. While this seems like a no-brainer, we often neglect the core issues that prevent our software from working. The most significant one being that we often do not know our software does not work until it is too late.

The single most powerful change that you can bring to your software development team is continuous deployment. What does this mean? I’m not suggesting that you auto deploy to production. I have not worked with an organization yet that is ready to make this leap of faith. Instead I’m encouraging you to:

1. automate your deployment process and run it every time your check in your code.
2. run a couple of user tests that walk through the most common end-to-end flows

While this may seem fairly straight forward this is difficult to complete. Much of this depends on your architecture, infrastructure and policies. To illustrate this point let’s look at a project that I lead a couple of years ago. In order to auto deploy our project and run test against our product we needed:

1. to have admin privileges on 5 dedicated database.
2. to create the database from versioned scripts
3. to load test data in each database
4. to have an application server on our CI box.
5. to have a message queue on our CI box.
6. to have three web services deployed and running
7. to have a build process that can automatically build and deploy an EAR to the application server

Policies, licensing and time are the largest barrier standing in the way of achieving this in any organization. This example may be more or less complex than the needs on your project. Nevertheless, in my experience working to break down these barriers is essential to delivering working software. Being able to address deployment issues as they come up is much less stressful than standing in a cube after hours trying to figure out why this stupid app won’t work with managers asking if you are “done yet”.

Policies can be changed if you track the amount of wasted time as it relates to deployment delays. Licensing costs can be accounted for or avoided (open source) if managers understand the savings. And as far as time goes, I’m more willing to put some time up front so I don’t have to loose my nights and weekends at the end of the project.

I know that this is possible. I have seen it work on numerous projects and team. Take the next step in Agility and automate your deployment process. Ensure that your software works by running a few end-to-end user tests. The effort is worth it. Your time and sanity is worth it.

Paradigm Shift

When I entered the development scene I was immersed in Object Oriented programming. As a result, I tend to think of good design in objects. A few years ago I began to learn and apply Groovy. With closures I was able to bleed into the realm of Functional programming. This gave me a small taste of a new paradigm. I thought of new ways to solve problems that I couldn’t see with Java. I can only imagine how much more I could learn if I developed exclusively in a Functional language for several months.

I tend to see two camps when it comes to learning new languages. The first camp thinks that the language that they know is sufficient for solving all programming problems. The second camp runs after the newest hot thing and divorces themselves from their old language. Neither extreme is healthy. We need to see languages as tools. A hammer is not good for solving all problems. Sure you might be able to turn a screw with the claw of a hammer but why would you. We need to understand our problems first and select a language that solves it best.

JVM languages allow us to make this decision at the last responsible moment. We can select a JVM language that seems appropriate and begin coding. If it becomes clear later that this language is not well suited to solve this problem then we can change our mind. The JVM provides a single platform for us to use the best tool for the job. We can even use multiple languages to develop one system. The JVM is an amazing canvas for agility.

Detour

Now I want to take what may seem like a major detour. However I would suggest that this does not stray all that far. We need to extend our effort to become multilingual beyond the JVM. As professionals we would benefit from learning the language of different business areas. Management, Testers, and Business Analysts solve problems in different language paradigms.

Many developers begin to tune out as I mention management. Feelings of frustration begin to take over. We can tolerate BA’s and Testers for the most part but management is just a waste of time. The pain and frustration from the past takes over and we just tune out. We code in secret and try not to disturb the gods of management. We avoid them and hopefully they will leave us alone.

While I’m not here to say that all management is just massively misunderstood and we need to forgive and forget, we do need to learn to communicate. We often contribute to our own misery. We are either silent or we speak in a language that makes no sense. We need to learn their language.

Speaking the Same Language

Before I proceed let me make a very important side note. Not all managers are open to an intelligent and rational discussions. Some have given in to money and power and they just want to be right no matter the cost. While this can be true, I think that there are many managers that can be reasonable. The challenge is not intellectual but one of language.

How do managers think? Well one simple way to find out is to listen to them. What are they focused on? What excites them? What frustrates them? But the most important question is why. Why are they focused on certain things? The question of why delves into the area of motivation. What motivates management? Sure we can go for the easy answer of money, but is that the whole story?

Expanding our Library

Once you start listening I believe we need to move to education. We need to add a few business books to our technical library. Begin to understand the information that managers are focused on. Take time to understand how they get information and how that effects their decisions. And now it’s time for a big leap. How can we provide information from our development effort that can influence management decisions. Now I want to caution you. This will not always work. But if we are not speaking manager-eez then we can not expect to influence their decisions. I see this same challenge in my marriage. My wife doesn’t focus on the same things that I do. Nevertheless, over time we’ve learned to speak each others language. We work to bridge this divide because we “care” about each other. I know I brought out a feeling word. We can try to avoid the “F” word, but if we don’t care enough to take the first step to bridge the technical and management divide who will?

Balancing Act

Once you have a good understanding of how your management team makes decisions, you need to get the right information to them. While every company and manager is different there tend to be some common ingredients in their decision making process. The first ingredient is return on investment (ROI). The second ingredient is generally risk management.

As a developer these tend to make me irritated. ROI appears to be something that can not be accurately measured and risk management just results in more work. However these are things that we deal with in our personal lives all the time. Marriage, 401K, children, cars, investments, homes all require us to consider ROI and risk. After buying three homes and selling two I am painfully aware of ROI and the need for risk assessment. Each purchase has different factors. A starter home needs to be something that I can resell in a few years. However starter homes often require a lot of maintenance and updating. A retirement home needs to be built to last. Similarly, every management decision has specific factors that drive the decision.

In software development the major factors tend to be: time-to-market, timeliness, development cost, maintenance costs, usability, scalability, security and features. The right product at the wrong time results in a useless product. A great 8 track player delivered in 1980 as the cassette tape market was on the rise, would be a waste of money. If you were one of the 70 million customers of Sony’s PlayStation that had their information stolen this year, all the other features became less important. Developing software, or products, is not just a matter of putting the correct components together. Good managers try to balance all the moving parts.

Show me the Facts

So how can we provide valuable information? One vital piece of information is the project burndown. A burndown projects the projected completion date based on the historical velocity and the size of the feature backlog. But marching towards the finish line does not always equate to a valuable product. Regular demos to the customer allows us to calibrate the relevance and usability. Tracking the feedback from these demos helps us measure the value of the current product.

Another factor to measure is the maintainability of a product. As we set a development pace we need to determine if this pace is creating waste. Managers have to weigh the cost of speedy development with the cost of long-term maintenance. But without any data this decision can not be made. Are developers just wasting time trying to make a Rolls-Royce when we just need a Pinto? We need facts not opinions to steer the ship of management. Instead of pretending that I am an expert in this area I am going to recommend that you read two of Neal Ford’s articles on “Evolutionary architecture and emergent design”.

• Evolutionary architecture and emergent design: Environmental considerations for design, Part 1
• Evolutionary architecture and emergent design: Emergent design through metrics

While the topic may be a little different from this blog these articles contain amazing insight on gathering, analyzing and visualizing technical debt. Technical debt is that elusive beast that we feed when we, with the best intentions, just try to “get-er done”. The fatter this beast gets the harder it is to make changes during the development process and during long-term maintenance. In this case harder means more costly.

Summary

As developers we are focused on language. We use words to create software. We translate business words into code. We are in fact professional interpreters. We use our multilingual skills to translate concepts into working software. But when it comes to bridging the communication divide between software development and management decisions we often give up. We try to use emotion pleas or technical words to effect change but people quickly stop listening.

As professional, multilingual, translators we need to focus our skills on effectively communicating with management. We need to understand their domain and gather valuable and relevant information that can guide their decisions. Instead of avoiding management we need to engage them. We need to gather information that only we poses and translate it into information that makes sense to critical decision makers. We need to become part of the solution instead of contributing to an overwhelming problem.

I’ve been asked several times to explain the difference between injecting Spring beans with ‘@Resource’, ‘@Autowired’, and ‘@Inject’. While I received a few opinions from colleagues and read a couple of posts on this topic I didn’t feel like I had a complete picture.

Annotations

In order to explore the behavior of each annotation I fired up Spring Tool Suite and started debugging the code. I used Spring 3.0.5.RELEASE in my research. The following is a summary of my findings.

The Code

I wanted to know how ‘@Resource’, ‘@Autowired’, and ‘@Inject’ resolved dependencies. I created an interface called ‘Party’ and created two implementations classes. This allowed me to inject beans without using the concrete type. This provided the flexibility I needed to determine how Spring resolves beans when there are multiple type matches.

public interface Party {
 
}

‘Person’ is a component and it implements ‘Party’.

package com.sourceallies.person;
...
@Component
public class Person implements Party {
 
}

‘Organization’ is a component and it implements ‘Party’.

package com.sourceallies.organization;
...
@Component
public class Organization implements Party {
 
}

I setup a Spring context that scans both of these packages for beans marked with ‘@Component’.

<context:component-scan base-package="com.sourceallies.organization"/>
<context:component-scan base-package="com.sourceallies.person"/>

Tests

Test 1: Ambiguous Beans

In this test I injected a ‘Party’ bean that has multiple implementations in the Spring context.

@Resource
private Party party;

@Autowired
private Party party;

@Inject
private Party party;

In all three cases a ‘NoSuchBeanDefinitionException’ is thrown. While this exception’s name implies that no beans were found, the message explains that two beans were found. All of these annotations result in the same exception.

org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No unique bean of type [com.sourceallies.Party] is defined: 
expected single matching bean but found 2: [organization, person]

Test 2: Field Name

In this test I named the Party field person. By default beans marked with ‘@Component’ will have the same name as the class. Therefore the name of the class ‘Person’ is person.

@Resource
private Party person;

@Autowired
private Party person;

@Inject
private Party person;

‘@Resource’ can also take an optional ‘name’ attribute. This is equivalent to the ‘@Resource’ code above. In this case the field variable name remains ‘party’. There is no equivalent syntax for ‘@Autowired’ or ‘@Inject’. Instead you would have to use a ‘@Qualifier’. This syntax will be covered later.

@Resource(name="person")
private Party party;

All four of these styles inject the ‘Person’ bean.

Test 3: Field Type

In this test I changed the type to be a ‘Person’.

@Resource
private Person party;

@Autowired
private Person party;

@Inject
private Person party;

All of these annotations inject the ‘Person’ bean.

Test 4: Default Name Qualifier

In this test I use a ‘@Qualifier’ annotation to point to the default name of the ‘Person’ component.

@Resource
@Qualifier("person")
private Party party;

@Autowired
@Qualifier("person")
private Party party;

@Inject
@Qualifier("person")
private Party party;

All of these annotations inject the ‘Person’ bean.

Test 5: Qualified Name

I added a ‘@Qualifier’ annotation to the ‘Person’ class

package com.sourceallies.person;
...
@Component
@Qualifier("personBean")
public class Person implements Party {
 
}

In this test I use a ‘@Qualifier’ annotation to point to the qualified name of the ‘Person’ component.

@Resource
@Qualifier("personBean")
private Party party;

@Autowired
@Qualifier("personBean")
private Party party;

@Inject
@Qualifier("personBean")
private Party party;

All of these annotations inject the ‘Person’ bean.

Test 6: List of Beans

In this test I inject a list of beans.

@Resource
private List<Party> parties;

@Autowired
private List<Party> parties;

@Inject
private List<Party> parties;

All of these annotations inject 2 beans into the list. This can also be accomplished with a ‘@Qualifier’. Each bean marked with a specific qualifier will be added to the list.

Test 7: Conflicting messages

In this test I add a bad ‘@Qualifier’ and a matching field name.

@Resource
@Qualifier("bad")
private Party person;

@Autowired
@Qualifier("bad")
private Party person;

@Inject
@Qualifier("bad")
private Party person;

In this case the field marked with ‘@Resource’ uses the field name and ignores the ‘@Qualifier’. As a result the ‘Person’ bean is injected.

However the ‘@Autowired’ and ‘@Inject’ field throw a ‘NoSuchBeanDefinitionException’ error because it can not find a bean that matches the ‘@Qualifier’.

 org.springframework.beans.factory.NoSuchBeanDefinitionException: 
No matching bean of type [com.sourceallies.Party] found for dependency: 
expected at least 1 bean which qualifies as autowire candidate for this dependency. 
Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true),
@org.springframework.beans.factory.annotation.Qualifier(value=bad)}

Conclusions

With the exception of test 2 & 7 the configuration and outcomes were identical. When I looked under the hood I determined that the ‘@Autowired’ and ‘@Inject’ annotation behave identically. Both of these annotations use the ‘AutowiredAnnotationBeanPostProcessor’ to inject dependencies. ‘@Autowired’ and ‘@Inject’ can be used interchangeable to inject Spring beans. However the ‘@Resource’ annotation uses the ‘CommonAnnotationBeanPostProcessor’ to inject dependencies. Even though they use different post processor classes they all behave nearly identically. Below is a summary of their execution paths.

@Autowired and @Inject

1. Matches by Type
2. Restricts by Qualifiers
3. Matches by Name

@Resource

1. Matches by Name
2. Matches by Type
3. Restricts by Qualifiers (ignored if match is found by name)

While it could be argued that ‘@Resource’ will perform faster by name than ‘@Autowired’ and ‘@Inject’ it would be negligible. This isn’t a sufficient reason to favor one syntax over the others. I do however favor the ‘@Resource’ annotation for it’s concise notation style.

@Resource(name="person")

@Autowired
@Qualifier("person")

@Inject
@Qualifier("person")

You may argue that they can be equal concise if you use the field name to identify the bean name.

@Resource
private Party person;

@Autowired
private Party person;

@Inject
private Party person;

True enough, but what happens if you want to refactor your code? By simply renaming the field name you’re no longer referring to the same bean. I recommend the following practices when wiring beans with annotations.

Spring Annotation Style Best Practices

1. Explicitly name your component [@Component("beanName")]
2. Use ‘@Resource’ with the ‘name’ attribute [@Resource(name="beanName")]
3. Avoid ‘@Qualifier’ annotations unless you want to create a list of similar beans. For example you may want to mark a set of rules with a specific ‘@Qualifier’ annotation. This approach makes it simple to inject a group of rule classes into a list that can be used for processing data.
4. Scan specific packages for components [context:component-scan base-package="com.sourceallies.person"]. While this will result in more component-scan configurations it reduces the chance that you’ll add unnecessary components to your Spring context.

Following these guidelines will increase the readability and stability of your Spring annotation configurations.

Related Links

Testing Spring Wiring
Beanoh Spring Wiring Test Framework

I’ve been using open source software for many years, but I’ve never open sourced my own project. This blog is a record of my experience as I start this journey. The resulting project can be found at http://beanoh.org.

Where

First I had to decide where to store the code.  There are several popular (Comparison of open source software hosting) open source hosting options. I chose GitHub (github.com) because I already had an account and I’m comfortable using Git.  Furthermore, GitHub provides intuitive tools that make it easy to manage a project.  I can setup an organization so multiple Source Allies employees can have commit rights on this project.  GitHub also has an integrated issue and feature tracking system that connects commits with tickets.  Overall I am very impressed with GitHub.

License

Before I push my code into GitHub I need to choose a liscense. This seems very overwhelming. I’m not a lawyer so how can I understand what each license provides? I started by searching for comparison charts. Out of these results I found the following comparisons helpful:

• Comparison of free software licenses
• Open Source License Comparison
• open source licenses for dummies

I feel like I understand the differences a little better, but I would like to know what other open source projects are using. I found a list of the “Top 20 Most Commonly Used Licenses in Open Source Projects” (http://www.blackducksoftware.com/oss/licenses). With the comparisons and the ranking I am leaning towards the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL).

I went to ‘gnu.org’ to research these licenses and I stumbled across a page called Why you shouldn’t use the Lesser GPL for your next library. It says, “The choice of license makes a big difference: using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.” In my mind this is a reason to use the “Lesser” license. I want to provide an open source project that can be used in any product. The “Lesser” license provides more to the community.  In all fairness it is worth mentioning that the ordinary GPL is designed to encourage developers to open source the software that uses these libraries. In my case I want to make my library available to anyone.

Now that I have decided on the license I am going to put the following disclaimer at the top of every file:

Copyright (c) 2011 Source Allies

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation;
version 3.0.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with this library; if not, visit
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt.

I also need to include a license.txt file at the root of my project that contains the full text of the LGPL.

Make sure you get the license in place before you start distributing or using the jar with third party organizations. In the case of consulting the client may end up owning the product if it is not licensed properly. Why go to so much trouble to open source code just to have the right lost to a third party organization?

Setup GitHub

I already have a GitHub account, but I want to setup an organization to manage a team of developers. I am able to create an organization under my personal ‘Account Settings’ under ‘Organizations’. I clicked the ‘Create Organization’ button and followed the wizard. For more information visit https://github.com/blog/674-introducing-organizations.

Collaboration

I am curious how open source projects manage changes from non-committers. I found a great article at GitHub that explains how most teams collaborate within their site (http://help.github.com/pull-requests). In short, contributors outside of the core development team submit “Pull Requests”. The project administrator(s) review these requests and decide if they want to merge them back into the code base. In my experience Git merging is fairly painless. This model allows anyone in the world the opportunity to contribute, while preserving the owners right to control the flow of changes. Too many chefs in the kitchen will ruin the food.

U-turn

I started looking for “How To” open source software articles and books. I didn’t find very many resources. Everyone talks about how to use open source, but very few people talk about how to effectively open source your own software. Eventually I ran accross “Producing Open Source Software: How to Run a Successful Free Software Project” by Karl Fogel (http://producingoss.com/producingoss.pdf). This book is a collection of insights from a major contributor to the open source project Subersion (http://subversion.apache.org).  I gravitated to this book because it is free.  Apparently Karl believes software and books should be available at no charge .

In the first chapter Fogel suggestes that 90 to 95% of all open source projects fail.  As the founding committer of Subversion, Karl has a little bit of experience leading a wildly successful open source project.  “This book is about avoiding failure. It examines not only how to do things right, but how to do them wrong, so you can recognize and correct problems early.” (p. 10)  So it is time to look at my mistakes so far.

First, I have not selected a “good name” (p. 21-22).  So what does “good” mean.  The project names that I talk about are the ones that I remember.  I am drawn to word plays like Mockito (mockito.org) which is a play on the drink Mojito.  When I heard it I remembered two things, the punny name and it’s purpose of mocking.

Second, I need to develop a “clear mission” (p. 22 – 23).  I have to admit that this idea of a mission statement is overwhelming to me.  In order to put myself to sleep I googled a few corporate mission statements.  Without referring back to their statements I would not be able to tell you what they were.  Ultimately they stated that they were super awesome organizations focused on making money.  Nevertheless, what is a good and useful mission statement?  Karl describes it as a “quick description”.  A statement that helps the customer decide in 30 seconds if they are interested in your project.  He recommends that this statement be “prominently placed on the front page, preferably right under the project’s name.” (p.22)  If we take a look at Mockito again they  state, right under their name, that it is “simpler & better mocking” (mockito.org).  Traditionally I would consider this a tagline and not a mission statement.  Nevertheless, I know several company’s taglines but I don’t know a single “mission statement”.  So what the heck, why split hairs?

While it seems strange, the third thing is to “state that the project is free”. (p. 22-23).  I had to visit several open source project homepages to find an example of this.  I did find the phrase “open source’ in the first two sentences at http://subversion.apache.org.  This does not seem to be a common practice, but it doesn’t take much effort to put the words “open source” in the description of the project.

Fourth, I need to take time to create clear documentation (p. 26-29).  This just takes time.  The obvious first step is a Getting Started page.   What’s more difficult is writing this from the perspective of someone that knows nothing about my product.  Fogel suggests that you do not have to wait until you have comprehensive documentation.  On the other hand, just write down some basic information.  It does not matter if it is incomplete.  Focus on helping new users get your product running.

New Direction

After reading this I need to slow down and make sure that we put our best foot forward.  We need a good name, logo, and well designed website.  I need to clearly state what this software does.   I need to put together some basic documentation that is easy to read and understand.

After some discussion we decided to setup a logo contest on https://99designs.com. This was very easy to setup and we got some amazing designs. I also went through every class and added javadocs. I put together some short screen casts with Camtasia (http://www.techsmith.com/camtasia/). This took a few tries, but the results were well worth it. Now I’m working on integrating all of this documentation into an intuitive and effective website design.

As a software developer it is easy for me to focus on the technical aspects of my software and neglect the presentation. While this may not be my initial focus I found that as a consumer I evaluate other projects in a few seconds based on how their websites looks. If I feel like it is interesting I start click through their site. If I don’t “get it” in a few clicks I move on. This evaluation period is extended if I have a recommendation from a friend or colleague. Nevertheless, I make snap judgments on aesthetics, not on the substance of the project.

If I know this about myself, then I need to make a reasonable investment in the initial presentation of this software. Even though our project will be distributed freely, we decided to spend money on the design to make sure our presentation matches the quality of our software.  Unfortunately it costs money to provide a quality open source product.

Conclusions

I have to admit that I have been avoiding this journey for quite a while.  Between the licensing and the project administration I felt a bit overwhelmed.  Nevertheless, I am starting with a small pilot project that has focused and limited functionality.  I’m sure that there will be a lessons learned blog that will emerge out of this experience as time goes on.  Until then have fun sharing your code with the world and check out Source Allies newest open source project at beanoh.org.

public class ServiceExample1 {
	private FooDAO fooDAO;
	private BarDAO barDAO;
 
	public void searchForFooAndBar() {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(Foo foo) {
		fooDAO.createFoo(foo);
	}
	public void createANewBar(Bar bar) {
		barDAO.createBar(bar);
	}
}

A couple of methods are defined, and they use two difference dao objects. Writing a test for the searchForFooAndBar method would currently involve providing alternative implementations for both the FooDAO and BarDAO objects. While this initially wouldn’t be too difficulty, it is easy to imagine how the number of dao dependencies could grow as the project goes on. It could also cause problems since we wouldn’t know which methods in the dao needed to be stubbed out or mocked for testing. I also worry that it would be too easy to test implementation instead of behavior. A test failure would be reported if the service changed which dao methods were called.

Another issue I’ve run into is not knowing which dao’s are involved in a method when writing the test. My initial thought was to not have the service object maintain references to the dao objects, but instead have each method require them as method parameters.

public class ServiceExample2 {
	public void searchForFooAndBar(FooDAO fooDAO, BarDAO barDAO) {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(FooDAO fooDAO, Foo foo) {
		fooDAO.createFoo(foo);
	}
	public void createANewBar(BarDAO barDAO, Bar bar) {
		barDAO.createBar(bar);
	}
}

Looking over this code, I didn’t care for it from the start. Maybe if the service layer objects were finer grained. Instead of three methods in the service from our first example, maybe there should be 3 service classes.

	public void searchForFooAndBar() {
		//
		// do some stuff
		//
 
		fooDAO.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		barDAO.searchForBar();
 
		//
		// finish up doing stuff
		//
	}

I think this would help fix the problem of having too many dao references, but I still wasn’t sure I liked the dependency on the dao’s themselves. That brought me to the final solution I thought of, which involves creating an interface for each method that defines the operations it requires to be provided.

public interface FooCreationAdapter {
	public void createFoo(Foo foo);
}
public interface BarCreationAdapter {
	public void createBar(Bar bar);
}
public interface SearchAdapter {
	public void searchForFoo();
	public void searchForBar();
}
public class Service {
	public void searchForFooAndBar(SearchAdapter searchAdapter) {
		//
		// do some stuff
		//
 
		searchAdapter.searchForFoo();
 
		//
		// do some more stuff
		// 
 
		searchAdapter.searchForBar();
 
		//
		// finish up doing stuff
		//
	}
 
	public void createANewFoo(FooCreationAdapter adapter, Foo foo) {
		adapter.createFoo(foo);
	}
	public void createANewBar(BarCreationAdapter adapter, Bar bar) {
		adapter.createBar(bar);
	}
}

While I feel this is the cleanest solution that would be the easiest to test, I really don’t think it is practical on a project level. Does anyone have a solution that has worked well for them?

Our client was tracking their daily status on a whiteboard in a conference room. A corporate memo was sent out banning the exclusive use of whiteboards for teams. As a result we turned to our web-based tracking tool. Unfortunately their whiteboard equivalent was clunky and inadequate. I spent a few hours putting together a Greasemonkey script that altered the look of this page to mimic our old whiteboard. These changes helped ease this transition.

Let’s walk through a simple example to change the behavior of the base Google search page.

1. Download and install Greasemonkey from https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
2. Navigate to www.google.com
3. Tools – > Greasemonkey -> New User Script…
4. Enter a name
5. Enter a namespace (This is provided so your scripts do not clash with others)
6. Verify that the Includes contain ‘http://www.google.com/’
7. A new js file will open in your default text editor.
8. The script will contain a comment that reflects the values that you entered
9. Add the following code

GM_addStyle("\
    body{\
        background-image:url('http://upload.wikimedia.org/wikipedia/en/d/d3/Gm_icon.png');\
    }\
");

10. GM_addStyle is method provided by the Greasemonkey API. (http://wiki.greasespot.net/Greasemonkey_Manual:API)
11. Save the script and refresh ‘www.google.com’
12. You should see grease monkeys all over the page.
13. Now add the following code

alert("I have been modified by Greasemonkey.");

14. Save the script and refresh ‘www.google.com’
15. You should see an alert box with the text above.

While this is a trivial example you can begin to imagine the possibilities. One of my colleagues used greasemonkey to modify a monitoring page. Before his modification it took three clicks to get the detailed information. We used this page every day all day to monitor our tests. After we installed his greasemonkey script we could just click on a new link that was generated. This seems like a trivial example, but we found that a number of these modifications helped us be more efficient and improved our quality of life. As a developer I hate repetitive tasks. I have a deep desire to automate everything. Greasemonkey empowers us to make the World Wide Web our own.

When I first got into the software industry I was a manual tester. Those years of repetition and tedium drove me to the world of coding and automation. As a software developer I am committed to automated testing. If a feature is worth coding it is worth testing. Automated tests have positioned me to be proactive instead of reactive. Nevertheless, transactions are quite challenging to test.

In order to test a transaction you must control three steps.

1. Successfully make a change within a transaction.
2. Cause an exception to be thrown within the same transaction.
3. Verify that the change in step one was rolled-back.

Step two is generally the hardest step to control within a test.

There are two main ways to create an exception. The first, and less complicated way, is to throw the exception within your code. This works great if you have a transaction that encompasses multiple steps within a method.

@Transactional
public void batchUpdate(List people){
	for(Person person : people){
		repository.save(person);
		log.info("Saved person: " + person.name());
	}
}

To test this you could write the following JUnit test.

@Resource
BatchProcessor batchProcessor;
 
@Resource
PersonRepository personRepository;
 
@Test
public void testBatchUpdate(){
	List people = Arrays.asList(new Person("Bob"), 
                          new Person("Mary"), new Person("Ben"));
 
	Assert.assertEquals(0, personRepository.findAllPoeple().size());
	batchProcessor.batchUpdate(people);
	Assert.assertEquals(3, personRepository.findAllPoeple().size());
}
 
@Test
public void testBatchUpdateRollback(){
	batchProcessor.setLogger(new StubExplodingLogger(2));
	List people = Arrays.asList(new Person("Bob"), 
                              new Person("Mary"), new Person("Ben"));
 
	Assert.assertEquals(0, personRepository.findAllPoeple().size());
	try{
		batchProcessor.batchUpdate(people);
		Assert.fail();
	}catch(RuntimeException e){
		System.out.println("boom");
		Assert.assertEquals(0, personRepository.findAllPoeple().size());
	}
}
 
public class StubExplodingLogger extends Logger{
 
	private int countDown;
 
	public StubExplodingLogger(int countDown){
		super("explodingLogger");
		this.countDown = countDown;
	}
 
	@Override
	public void info(Object message) {
		if(countDown <= 0){
			throw new RuntimeException("test explosion - BOOM!");
		}
		System.out.println("tick");
		countDown--;
	}
}

In this example you inject a fake logger that explodes on the second call. This is an ideal implementation for testing transactions and makes our test fairly straightforward. However the test for the repository save transaction is more complicated.

@Transactional
public void save(Person person){
	//save the person
}

The test for this method would look something like this.

@Test
public void testPersonRepositorySaveRollback(){
	Assert.assertEquals(0, personRepository.findAllPoeple().size());
	try{
		personRepository.save(new Person("Bob"));
		Assert.fail();
	}catch(Exception e){
		Assert.assertEquals(0, personRepository.findAllPoeple().size());
	}
}

In this case we have to rely on the database to throw an exception. This means that our application allows us to send data to the database that is in a bad state. In the past I have opened up a hole in my validation that allowed me to send bad data to the database. This is an irresponsible approach. There are two approaches that solve this issue while preserving the integrity of your application.

The first way is to simply test the configuration. It is fairly straight forward to verify that the method is marked with @Transactional and the framework is wrapping this with a transaction.

@Resource
PersonRepository personRepository;
 
@Test
public void testTransactionalConfiguration(){
    //verify the save method is marked with @Transactional
    Method method = 
         PersonRepository.class.getDeclaredMethod("save", Person.class);
    Annotation annotation = method.getAnnotation(Transactional.class);
    Assert.assertNotNull(annotation);
 
    //verify PersonRepository is a proxy
    Assert.assertTrue(personRepository.getClass().
                                toString().contains("$$EnhancerByCGLIB$$"));
}

However this approach fails to test the effect. It verifies that it is configured to work, but it fails to verify that it truly works.

The second approach is to temporarily modify the database constraints within a test to cause a failure. The simplest modification is to setup a database constraint that will not allow the state “AL”.

@Before
public void setup(){
    jdbcTemplate.execute("ALTER TABLE State" +
		                "ADD CONSTRAINT test_constraint " +
                                "CHECK (State <> 'AL');");
}
 
@Test
public void testPersonRepositorySaveRollback(){
	Assert.assertEquals(0, personRepository.findAllPoeple().size());
	try{
                Address address = new Address("100 Street", 
                                                   "Mobile", "AL", "36601");
		personRepository.save(new Person("Bob", address));
		Assert.fail();
	}catch(Exception e){
		Assert.assertEquals(0, personRepository.findAllPoeple().size());
	}
}
 
@Test
public void testPersonRepositorySaveRollback(){
	Assert.assertEquals(0, personRepository.findAllPoeple().size());
 
        Address address = new Address("200 Street", "Des Moines", 
                                                  "IA", "50044");
	personRepository.save(new Person("Mary", address));
 
	Assert.assertEquals(1, personRepository.findAllPoeple().size());
}
 
@After
public void tearDown(){
    jdbcTemplate.execute("ALTER TABLE State" +
		              "DROP CONSTRAINT test_constraint;");
}

This allows you to test that people with other states are committed and that people that are in the state of “AL” are rolled-back. It is important that this constraint is added in the @Before setup method and removed in the @After teardown method.

I have lost too many hours of my life tracking down strange bugs that were ultimately related to missing or improperly configured transactions. Transactions are mission critical. They only get attention when they do not work. Furthermore, the cleanup of fragmented data can be crippling to an organization.

As professionals we must be committed to writing automated tests. This is especially true for mission critical features like transactions. Transactions are rarely explicitly stated in requirements. They are almost never directly tested by manual testers. And they are very expensive when they are missing or fail to work properly in production. They are our invisible allies. We need to make them first class citizens in our tests.

The Download
When I bought this machine it had a fresh install of Windows XP and came with the recovery disk which was excellent because I had to use it multiple times before I got things just the way I wanted them. Since this computer didn’t have any files I didn’t have to worry about backing anything up but it would be a must if considering putting Ubuntu on an everyday machine. To install Ubuntu you need the install CD. Ubuntu community can mail you one if you so request online, but why not be a DIYer and burn it yourself? I downloaded the Ubuntu 9.10 Desktop version for a graphical install and then went straight to burning it onto a CD. This was a mistake. I didn’t figure that the piece of the installation instructions regarding running the checksum was all that important, but it absolutely is. If the download is the least bit wrong the installation will not work. I burned several CDs of a bad image. Eventually I followed the installation documentation more closely and actually downloaded winMd5Sum. With this free tool I was able to compare the checksum of the downloaded image with the correct checksum from the Ubuntu site. It took several attempts and switching to a Canadian mirror before getting a successful download. Finally I could burn it to a disc.

Burning the Disc
The download comes as an image with an “.iso” extension. I had never burned an image before so I followed the Ubuntu advice to download the free Infra Recorder. The actual burning of the image to the disc couldn’t have been easier. Following the Ubuntu instructions I quickly had an Ubuntu install disc. I inserted it into my computer and restarted it so it could boot from the disc and headed straight to the install options. Here is where I went wrong for the second time by skipping a small part of the install instructions. Instead of using the “Install” option on the disc I should have first chose, “Check the disc for defects.” After a few failed installs and a bunch of wasted time, choosing the “Check for defects” option finally revealed that while my download was successful, my burn did not translate to the disc just right. Burning another disc or two finally yielded some successful results.

Installing
There are many ways to install Ubuntu. It can be installed as the sole operating system on the computer, as a virtual OS inside of Windows, or even as a side-by-side dual boot with Windows. I was attempting the latter. When trying to achieve a dual boot installation the hard drive must be partitioned so that each OS can reside in its own territory. With Windows on the machine I first dabbled in the computer management menu to try to clear space for Ubuntu, but then while installing it was difficult to interpret the partitioning. My solution was to reformat the hard drive so that Windows again occupied the whole hard drive and then use the installer disc to set up the partitions. I think this is the best option because you get a very good visual of how your hard drive is split up and you’ll have to go through the setup menu anyway so it saves you time from toiling in a Windows configuration. Other items in the installation process are very easy such as choosing language, naming the computer and setting up a user account. With the install completed, the next time the computer starts there will be a choice to start Ubuntu or Windows which is the whole idea of a dual-booting system.

In Conclusion
Installing Ubuntu, especially in a dual-boot situation, can be a daunting task. Although my experience exemplified Murphy’s Law it is a very do-able process. Looking back, I could have saved a ton of time had I followed the online instructions more carefully and verified the download and burn of the image. Bottom line though is that the instructions and documentation are great resources and there are plenty of forums and YouTube videos also documenting the process. With the volume of help out there I wouldn’t worry about lacking experience like myself, just jump in, read up and take your time.

1. Musings of a SpringOne 2009 Attendee Day 1
2. Musings of a SpringOne 2009 Attendee Day 2
3. Musings of a SpringOne 2009 Attendee Day 3

Read on for day 4.

OSGi and Groovy Jump Start

The presentation started with a 5 minute youtube video preview which I thought was pretty innovative.

The first half was around what is OSGi, some of which I’ve had experience with. I did pick up on a few key concepts that I didn’t know i wasn’t communicating earlier in my own presentations on OSGi.

We covered how a groovy POGO has groovy types in the public API. So if your groovy bundle has the groovylib in it’s classpath then it has to export the groovy package. Also when using Groovy in OSGi, if possible use POJOs for your applications type system since POGOs force you to expose couple groovy types in the bundle’s API.

The examples were done using gradle and this was my first live example of using gradle. This is a key benefit of conferences — being exposed to technologies you may otherwise not have the time to take a peek at.

I liked how the presenter took the path of not making things look complex but rather simplifying the concepts. He did this with concepts such as the OSGi bundle lifecycle.

Some of the tools covered in this session were:

• bnd to create a groovy manifest
• osgi bundle for gradle uses bnd
• junit4osgi

Expand your business with Groovy – Case Study

This session was a case study on how a monolithic application was extended to provide customizations using groovy. A major customer had approached HypericQ wanting a custom dashboard.

HypericQ developed a architecture around attach point’s which are places within the UI where plugins can connect to.

Custom UI was provided by gsp templates for customer specific dashboards.

Groovy templates was used as the templating framework that allowed clients to build their own using GSP pages.

A Web Services API was provided as part of the core platform that enabled several benefits:
- hqapi command line interaction
- allows integration testing of the application
- embedding a groovy console inside the application
- console gives you a HQL way to query the domain and not worry about the end customers database environment

The talk was an interesting exercise in how a dynamic plugin architecture could be implemented. Groovy categories was heavily used to enable this.

Re-factoring a Spring Application for SOA using Spring technologies in 40 min

The current focus of SOA is really software architecture. SOA is neither static nor predictable. The architectural pattern of any application must be reflective of the business. SOA is preparing the stuff that is critical to your business to stand the test of time.

Architecture involves the courage to be wrong while minimizing the impact of being wrong. It is about making educated decisions between speed and perfection. The longer it takes to deliver the software the higher the client’s expectations of that software is.

The foundation of SOA is highly cohesive, loosely coupled modules. One must practice

1. strategy first programming
2. process life-cycle dynamics
3. process collaboration
4. loose coupling promotes a network based architecture over a hierarchical one – composition over inheritance

SOA and OSGi enable embracing change by making versioning a runtime concept.

There is an argument to be made for deploying a process as a whole in BPEL. But what about flexible orchestration via simple messaging. We were given the American football analogy. Each play is scripted, but between plays we need to adjust strategy to meet the overall goal.

Modern event driven architecture was mentioned as a composite process linked together in a linear fashion through the use of rule based pathing.

The second half of this talk was the Spring booking demo from Spring Web Flow project. There are 3 OSGi bundles:

1. war bundle
2. service bundle
3. datasource bundle

The demo was using STS and it’s DM Server tooling. The entire development workflow was very seamless with SpringSource having done an awesome job of the tooling.

We saw an example of a transparent failover. So there is a need to take down the primary database for maintenance work without taking the application down. A backup datasource bundle is started and the primary datasource bundle is stopped. The datasource bundle is a simple datasource definition and an osgi service with ranking. Because of a higher rank the backup datasource bundle takes precendence and the primary datasource bundle can be safely stopped. Bundles can also take advantage of filtering besides ranking.

Spring Integration builds on pipes and filters. You can expose OSGi services as pipes. It provides the ability to change the behavior of a modularized application by changing how the modules are hooked up in the XML as opposed to modifying source code or in cases where the source code is not available.

Conference Wrap Up

Here are my key take aways:

• It is time for Grails
• Need to investigate Spring Faces
• Webgoat
• Spring Web Flow
• Spring Integration
• Spring DM Server

Overall it was a very productive conference and I would recommend it for anyone looking to attend it next year.