Monday, January 25, 2010

JSR 229 - Dependency Injection In Java EE 6

Java EE 6 is coming with new API to support type safe dependency injection that called Contexts and Dependency Injection (CDI). The founder of Hibernate (an open source object/relational mapping solution for Java) Gavin King is leading this JSR to be best dependency injection by using the best features of earlier frameworks like Spring Framework, Google Guice and JBoss Seam.

It is too early to compare the new API with its ancestors. lets just have a brief look at what is available in the API.

Java EE 5 did have a basic form of dependency injection perhaps most appropriately termed resource injection. In Java EE 5 you could inject container resources such as Data Sources, JPA Entity Managers and EJBs via the @Resource, @PersistenceContext, @PersistenceUnit and @EJB annotations into Servlets, JSF backing beans and other EJBs. Java EE 6 is coming with enhanced version of the earlier features plus some additional features to support direct usage of EJBs in JSF backing beans and manage the scope, state, life cycle and context for objects.

Simple Injection
@Stateless
public class MyService {
@Inject
private AnotherService another;
....
}
in this example AnotherSerivice is just a simple POJO that injected to MyService.

Qualifiers
@Stateless
public class MyService {
@Inject
@MyQualifier
private AnotherService another;
....
}

@MyQualifier
public class AnotherServiceImpl implements AnotherService {
....
}

@Qualifier
@Retention(RUNTIME)
@Target({TYPE})
public @interface MyQualifier {}

If there are more than one implementation for a specific service Qualifiers can be used to specify the target implementation.

Scope Identifiers

There are five scope identifiers available in the API.

- ApplicationScoped
An object reference is created only once for the duration of the application and the object is discarded when the application is shut down.
- SessionScoped
An object reference is created for the duration of an HTTP session and is discarded when the session ends.
- RequestScoped
An object reference is created for the duration of the HTTP request and is discarded when the request ends.
- Dependent (Defult Scope)
A dependent reference is created each time it is injected and the reference is removed when the injection target is removed.
- ConversationScoped
A truncated session that defined by application.
@RequestScoped
class MyBean {
....
}

@ApplicationScoped
class MyCache {
....
}

@SessionScoped
class MySessionData {
}
Named Objects

It is possible to define a name for every object that we need to inject. this name can be used by EL in JSP or JSF to retrieve the object.
@RequestScoped @Named("foo")
class MyBean {
....
public String getId() {
....
}
....
}


In the JSP or JSF page you can use the bean by name :

... #{foo.id} ....

And this is it. a short review of Java EE 6 CDI API.
more details about JSR 299 : http://jcp.org/en/jsr/detail?id=299.

Sunday, January 24, 2010

How Pair Programming Really Works

Stuart Wray, from the Royal School of Signals, wrote a paper for the January 2010 edition of IEEE Software Magazine entitled "How Pair Programming Really Works".

In the paper he first brings together the various pairing approaches (journeyman-apprentice / driver-navigator) and identifies a common way of working:

My own experience as a developer using pair programming is that it isn’t just a technique where one person programs and the other person watches. Both programmers work closely together, chatting the whole time, jotting down reminders of things to do, and pointing out pieces of code on the screen. (One of the clichés of pair programming is that if you’re doing it right, your screen should be covered with greasy finger-marks by the end of the day.) Programmers take turns at the keyboard, usually swapping over with a phrase like, "No, let me show you what I mean."

Building on his description of effective pair programming (and identifying that not all implementations of pair programming are effective) he presents four mechanisms that make effective pair programming successful.

Mechanism 1: Pair Programmers Chat

Brian Kernighan and Rob Pike recommended explaining problems aloud, even to a stuffed toy, a practice that John Sturdy called the rubber-plant effect. Part of pair programming’s effectiveness is presumably due to this effect being continually triggered: as one programmer gets stuck, the back-and-forth chat serves to unstick them in the same way as solo programmers talking about their problems out loud.

He discusses the increased benefits that chatting brings about where what he calls the "expert programmer theory" applies - where the members of the pair perceive each other as knowledgeable problems are solved more effectively:

So perhaps this is how expert programmer theory really works: an expert is more likely to ask a deep question, which prompts the novel inference from the stuck programmer. It also seems possible that merely thinking that you’re talking to an expert - or pretending - will help the stuck programmer produce the sort of deep questions that experts have asked them in the past.

Summing up the value of chatting he states:

This first mechanism would therefore lead us to predict that programmers who chat about their programs more should be more productive and that those who pose occasional deep questions for each other should be most productive of all.

Mechanism 2: Pair Programmers Notice More Details
"You don’t see your own mistakes" is a truism of software development (and many other disciplines).

Wray links this to theories of change blindness and inattentional blindness.

What we notice depends on what we expect to see and what we unconsciously consider salient. So, although successful pair programmers will concentrate mostly on the same things, they might notice different things.

So, two people programming together won’t have the same prior knowledge or categorization: one will presumably spot some things faster and the other different things faster. Where their rate of working is limited by the rate they can find things by just looking, two heads must be better than one. And in fact, one of the earliest observations that people make when they start to pair program is that the person who isn’t typing code always picks up typos quicker: :Oh, you’ve left out the comma here."

He goes on to warn about the phenomenon of pair fatigue: When two programmers pair together, the things they notice and fail to notice become more similar. Eventually, the benefit from two pairs of eyes becomes negligible.

Pair Fatigue is a driver for rotating pairs regularly:
Some pair programmers regard rotation as an optional part of the practice, and on a small team, or with few programmers willing to pair, there might be little alternative. However, pair fatigue means they’ll ultimately be much less productive.

Mechanism 3: Fighting Poor Practices
Peer pressure not to slip into bad practices is a clearly identified benefit of effective pair programming.

He discusses the example of "code-and-fix" programming and links it to the addictive nature of slot machine gambling:

This is the special property of interactive programming that makes it difficult to do the right thing. With code and fix, we tinker haphazardly with our programs, effectively putting a coin into the slot machine each time we run our code. Slot machines are known as the most addictive form of gambling, and the similarly unpredictable rewards from code-and-fix programming mean that it could be equally addictive.

Pair programmers might be less susceptible to poor practices because they can promise to write code in a particular way and ensure that each other’s promises are kept. The prevalence of two-people working in jobs where human fallibility is a serious problem should lead us to seriously con¬sider that pair pressure might be the solution for us, too.

Mechanism 4: Sharing and Judging Expertise
The productivity differences between individuals are vast, measured to be at least a factor of 10. This often means that estimates of difficulty and time are inaccurate. This applies to both good and bad programmers - you can only determine someone’s programming capabilities by working closely with them.

Most programmers work on problems on their own, so no one knows how good (or bad) they really are. But with pair programming, people continually work together. Because they keep swapping pairs, everyone on the team learns who’s the most expert at particular things. From this comparison, they also realize their own level of expertise. We should therefore expect more accurate estimates of time and difficulty by a pair programming team than from a solo programming team. From my experience, this does appear to be the case.