Singletons are Pathological Liars

You can live in a society where everyone (every class) declares who their friends (collaborators) are. If I know that Joe knows Mary but neither Mary nor Joe knows Tim, then it is safe for me to assume that if I give some information to Joe he may give it to Mary, but under no circumstances will Tim get hold of it. Now, imagine that everyone (every class) declares some of their friends (collaborators), but other friends (collaborators which are singletons) are kept secret. Now you are left wondering how in the world did Tim got hold of the information you gave to Joe.

read full story here.

Dependency Injection, The manual way

Dependency Injection, The manual way

"The JCP Is Dead" ?

The JCP Is Dead
... and Oracle killed it.

By this time, most people know that the ASF has resigned from the JCP EC.

What was posted was our final version of the notice, but I'd also like to share with the community an earlier, rougher and more "emotional" version. It says the same, but in a more face-to-face conversational way. I feel that both versions represent the disappointment, anger and sadness over this whole issue, which has been fostering since 2006. The below just captures it from a different point of view:


Read the full story on Jim's blog

What's in a Story? [Dan North]

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria.

Introduction
Software delivery is about writing software to achieve business outcomes. It sounds obvious, but often political or environmental factors distract us from remembering this. Sometimes software delivery can appear to be about producing optimistic reports to keep senior management happy, or just creating “busy work” to keep people in paid employment, but that’s a topic for another day.

Usually, the business outcomes are too coarse-grained to be used to directly write software (where do you start coding when the outcome is “save 5% of my operating costs”?) so we need to define requirements at some intermediate level in order to get work done.

Behaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on. To do this, we need a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work. From this they can agree a common definiton of “done”, and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing”.

This, then, is the role of a Story. It has to be a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is “done”. This is a more rigorous definition than in other agile methodologies, where it is variously described as a “promise of a conversation” or a “description of a feature”. (A BDD story can just as easily describe a non-functional requirement, as long as the work can be scoped, estimated and agreed on.)

continue here : http://blog.dannorth.net/whats-in-a-story/

Writing Testable Systems

Writing Testable Systems
— Complex enterprise applications are generally hard to maintain, and risky and difficult to change. As a new developer on a team, a large legacy code base is often difficult to understand, especially when the code has evolved over a long period and new functionality has been grafted onto an existing application.

Test-Driven Development Is Not About Testing

Test-Driven Development Is Not About Testing
— I am always on the look out for good questions to ask candidates in an interview. Not the 'How many oranges can I fit in this room?' kind of nonsense (the stock response to which is apparently 'with or without us standing in it?').

InfoQ: Is it Time to Rethink Enterprise Architecture?

InfoQ: Is it Time to Rethink Enterprise Architecture?

InfoQ: The Role of the Enterprise Architect

InfoQ: The Role of the Enterprise Architect

I’ve been programming for X years … now what?

You’ve been a programmer for some number of years.

You are stuck in a rut and bored.

You still like programming but you need to do something new.

Is this you?

Career development for programmers has always been a sticky subject. The most traditional path is into management, even if the programmer doesn’t have any management skills or interest in management. This leads to disgruntled and bad managers which only aggravates the career development cycle for future programmers.

Some (usually larger) companies offer a senior level technical track, often titled “Technical Lead” or “Software Architect”. The duties are different than that of a manager, but still involves leading other programmers in some manner.

continue here

Agile Anti-Patterns - a discussion

Some practices which harm the way we adapt to agile way of working or in a way sort of bad practices which are counter productive. They may very well push back the organizations which are still testing the waters of going agile.

1 - End of the day integration

2 - Let us keep the refactoring tasks for later

3 - Unit testing the complex pieces is enough

4 - Move the iteration until all the user stories are done

5 - Let us try to do as much as possible during the iteration

6 - Comment the test as it is breaking the build and we will come to it later

7 - Retrospectives are not adding much value, will save time if we skip it

8 - We are doing continuous integration so we are already agile

9 - Most of the user stories are high priority

read the full story

REST and SOAP: When Should I Use Each (or Both)?

The two approaches for interfacing to the web with web services, namely SOAP (Simple Object Access Protocol) and REST (Representational State Transfer). Both approaches work, both have advantages and disadvantages to interfacing to web services, but it is up to the web developer to make the decision of which approach may be best for each particular case

read the article in InfoQ

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.

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.