So what was the problem? Well, I've been using @Configurable and @Autowired to inject stuff in my domain object which I create in code. To get this working when running mvn test you have to pass in spring-agent.jar as javaagent. When you do this, everything worked great! To to this with Maven you have to do the following:

 
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4</version>
    <configuration>
      <forkMode>once</forkMode>
      <argLine>
        -javaagent:${settings.localRepository}/org/springframework/spring-agent/${spring.version}/spring-agent-${spring.version}.jar
      </argLine>
      <useSystemClassloader>true</useSystemClassloader>
    </configuration>
</plugin>
 

Now, that's all cool, and it worked like a charm... for a while. When I added @Configurable to another class to autowire in a new dependency, I could not get that specific class to get weaved properly. Believe me, I tried everything I could think of, but nothing worked... until I found a hint on a thread with a related problem. By passing in a second javaagent, aspectjweaver.jar, the problem was solved! To do this in Maven you just add the second javaagent after the first, like this:

 
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4</version>
    <configuration>
      <forkMode>once</forkMode>
      <argLine>
        -javaagent:${settings.localRepository}/org/springframework/spring-agent/${spring.version}/spring-agent-${spring.version}.jar -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/1.6.1/aspectjweaver-1.6.1.jar
      </argLine>
      <useSystemClassloader>true</useSystemClassloader>
    </configuration>
</plugin>
 

Note: If you add a line-break between the two javaagents, it doesn't work.

What was the problem I had? I have no idea! Why does this solution work? I have no idea! All I know is that I get a green light from my tests, and that I don't need this solution when running live in Tomcat or whatever, since the classloader there has addTransformer(ClassFileTransformer).

Still, if anyone has any idea of why I, after everything worked with only spring-agent.jar, needed to add aspectjweaver I am all ears! Don't get me wrong! I can live with not knowing, but I would get peace of mind from knowing...

I was playing around with creating a Twitter clone, in my opinion the "Hello World" of graph databases, and I started out with the following simple service.

Spring configurating:

 
<beans ... >
	<context:annotation-config />
 
	<bean id="neo" class="org.neo4j.api.core.EmbeddedNeo"
		destroy-method="shutdown">
		<constructor-arg>
			<value>var/neo</value>
		</constructor-arg>
	</bean>
 
	<bean id="indexService" class="org.neo4j.util.index.NeoIndexService"
		destroy-method="shutdown">
		<constructor-arg ref="neo" />
	</bean>
 
	<bean id="twitterService"
		class="com.jayway.twitter.neo.NeoBasedTweetService">
<property name="neo" ref="neo" />
<property name="indexService" ref="indexService" />
	</bean>
 
	<!-- Transactions -->
	<tx:annotation-driven />
        ...
</beans>
 

The service:

 
public class NeoBasedTweetService implements TweetService {
 
	protected NeoService neo;
	protected IndexService indexService;
 
	//Setters for neo and indexService
 
	@Transactional
	public Tweet createTweet(User user, String tweet) {
		UserNode userNode = new UserNode(indexService.getSingleNode(
				TwitterIndexConstants.INDEX_USER, user.getUserName()));
		TweetNode tweetNode = new TweetNode(neo.createNode());
		tweetNode.setKvitt(tweet);
		userNode.createRelationshipTo(tweetNode, KvittRelationships.KVITTRAT);
		return tweetNode;
	}
 
	//Services to create User and more
 
}
 

This doesn't feel very DDD. I would really want to do the User to be responsible for creating the Tweet. Like this:

 
public class NeoBasedTweetService implements TweetService {
 
	protected NeoService neo;
	protected IndexService indexService;
 
	//Setters for neo and indexService
 
	@Transactional
	public Tweet createTweet(User user, String tweet) {
		UserNode userNode = new UserNode(indexService.getSingleNode(
				TwitterIndexConstants.INDEX_USER, user.getUserName()));
		return userNode.createTweet(tweet);
	}
 
	//Services to create User and more
 
}
 

The TweetNode and UserNode would look like this:

 
public class TweetNode extends NodeDelegate implements Tweet {
 
	TweetNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Methods for doing Tweet-stuff
 
}
 

 
public class UserNode extends NodeDelegate implements User{
 
	UserNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Methods for doing User-stuff
 
	public Tweet createTweet(String kvitt) {
		//Here comes a problem! I need a new Node
		//from the NeoService to create the TweetNode
		TweetNode tweetNode = new TweetNode(null);
		tweetNode.setTweet(tweet);
		createRelationshipTo(tweetNode, TwitterRelationships.TWEETED);
		return tweetNode;
	}
}
 

NodeDelegate, extended by both User- and TweetNode implements the Neo4j interface Node and delegates all the method calls to the underlying node ( for more on this, see my previous post) :

 
public class NodeDelegate implements Node {
 
	private Node delegate;
 
	protected NodeDelegate(Node underlyingNode) {
		delegate = underlyingNode;
	}
 
	//Methods for delegating all Node methods to the Node delegate
}
 

As you see I have a problem here. In the first version my NeoService is injected into NeoBasedTweetService and used when I create the new TweetNode. In the re-made, more DDD-style example I create the new TweetNode in the UserNode, where I don't have access to my NeoService. How do we solve this?

One alternative that I instinctively dislike is to inject the NeoService into the UserNode. The reason for me disliking this is that my UserNode IS a Node, and it feels very tangled if a Node holds a reference to its container. But I came to think of another solution thanks to a talk I did a while back together with Henrik Reinhold on what was new in Spring 2.5.

In Spring 2.5 load-time weaving (LTW) capabillites was introduced, and with LTW you can manipulate objects in load-time, as opposed to runtime weaving that is proxy based. This, combine it with @Configurable and @Autowired, proves to be very helpful when the Spring context is not in charge of creating the objects in question, as in the example above...

To enable LTW we add one tag in the Spring configuration:

 
<context:load-time-weaver />
 

After that we have to inform the Spring container of how we want thing done. To do we edit the TweetNode and NodeDelegate like this:

 
//Annotate the class with @Configurable so that Spring can find it.
@Configurable
public class TweetNode extends NodeDelegate implements Tweet {
 
	TweetNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Add a default constructor both in the TweetNode
	//and the NodeDelegate, it is new:able without a Node.
	public TweetNode() {
		super();
	}
 
	//Add a setter for the underlaying Node and annotate it with @Autowired.
	@Autowired
	public void setNode(Node nodeDelegate) {
		super.setNode(nodeDelegate);
	}
 
	//Tweet-methods as before
 
}
 

 
public class NodeDelegate implements Node {
 
	private Node delegate;
 
	protected NodeDelegate(Node underlyingNode) {
		delegate = underlyingNode;
	}
 
	protected NodeDelegate() {
	}
 
	protected void setNode(Node nodeDelegate) {
		if (delegate == null) {
			delegate = nodeDelegate;
		}
	}
 
	//Methods for delegating all Node methods to the Node delegate
 
}
 

Now Spring only has to be able to create Nodes. To do that we create a simple NodeFactory, like this:

 
public class NodeFactory implements FactoryBean{
 
	private NeoService neo = null;
 
	public void setNeo(NeoService neo) {
		this.neo = neo;
	}
 
	@Transactional
	public Object getObject() throws Exception {
		return neo.createNode();
	}
 
	public Class getObjectType() {
		return Node.class;
	}
 
	public boolean isSingleton() {
		return false;
	}
 
}
 

... and add it to the configuration, like this:

 
	<bean id="node" class="com.jayway.neo.utils.NodeFactory">
<property name="neo" ref="neo" />
	</bean>
 

The result of this is that Spring now has a NodeFactory that returns a new node for every request, I have annotated the TweetNode so that Spring knows of it (@Configurable) and what to do with it (@Autowired on setNode) and I've enabled load-time weaving in order to get the a new Node woven into a TweetNode every time a new instance of it is created in the code.

In UserNode I really don't have to make any changes. "setNode(Node)" will get a new Node after the instantiation of a TweetNode, even if the constructor that takes a Node is called. For clarity I still changed the UserNode as follows:

 
public class UserNode extends NodeDelegate implements User{
 
	UserNode(Node underlyingNode) {
		super(underlyingNode);
	}
 
	//Methods for doing User-stuff
 
	public Tweet createTweet(String kvitt) {
		//This TweetNode will get a Node set by Spring
		TweetNode tweetNode = new TweetNode();
		tweetNode.setTweet(tweet);
		createRelationshipTo(tweetNode, TwitterRelationships.TWEETED);
		return tweetNode;
	}
}
 

The problem I had when trying to make the UserNode responsible for creating its TweetNode's was that I needed to inject something that could create Nodes into the UserNodes. By using load-time weaving and instructing Spring of how to wire a TweetNode I don't have to pass my NeoService around to all the UserNodes created in my code. Instead I can rely on Spring to inject what is needed, when it's needed.

The truth "Autonomous, re-runnable, code-based tests are objectivity good" has created a perceived truth, namely "Testable design is good design". This assumption is incorrect.

The phrase "testable design" is dependent of two things; the design of the code under test AND the tools used for testing the code. This is a problem when the major tools today in the Java world tells you to not test private methods, final classes
and so on.

Yes, there is a big overlap between testable design and good design, but should the test tools you use govern your design? Conscious and good design choices should govern the structure of your code, and testability should come with that.

PowerMock changes the phrase "Testable design is always good" to what it should be, and that is "Good design is always testable".

And when it comes to the hurt of legacy code, would you rather re-factor the code in order to write tests, or write tests to be able to re-factor the code safely?

What is Twitter? Well, it's a micro blog. Users post so called tweets, messages with 140 characters or less. You can tweet, follow peoples tweets and search. That's basically it. And this is cool why?

Keep yourself updated

For me, one of the key features of Twitter is that there are really interesting people twittering. If you go to WeFollow you'll find people like Kevin Rose, Tim O'Reilly and Guy Kawasaki in the tech segment. Since they are active this means that you are able to listen to feeds from some of the, in their fields, most updated people. And Twitter is basically full of fantastic people to follow... like Chris Hughes (http://twitter.com/chews), less followed but equally interesting, who's Twitter Bio says "I was the one of first to hack the iPhone. BOOOM'"... In short, nothing is stopping anyone from evolving their web presence and getting people to follow them.

Before Twitter everyone knew people that where islands of new knowledge; people that seemed to have one ear to the ground and hear the most interesting things. With Twitter, these guys and girls broadcast their nuggets of information to the world, effectively building their personal brand and enabling everyone to listen to them. All of the sudden you have the opportunity to be as updated as these people are. Not only that, since you have the possibility to listen to multiple islands at once you can get a perspective of the entire world of islands...

Ok, there are great people to follow, and they share information, great links and insight, but this all sums up to a lot of information. Yes! In this day and age you have to accept a certain degree of white noise if you want to hear interesting signals... deal with it. Luckily there are plenty of tools to help you deal with it. I use TweetDeck on my Mac, but there are tons of tools out there...

The Twitter API

The Twitter API is in my opinion is one of the most obvious reasons for Twitter success. It is an open API which anyone can use to create applications that uses Twitter data... and it's silly simple, especially if you use the Java API java-twitter. The following is what is needed to login a user and print their friends timeline (the stream of tweets from people a person follows):

public void printFriendsTimeline(String username, String password) throws TwitterException{
	Api api = new Api();
	api.setCredentials(username, password);
	Status[] userTimeline = api.getFriendsTimeline();
	for (Status status : userTimeline) {
		System.out.println(status.getUser().getName() + ":" + status.getText());
	}
}
 

This means that anyone can do just about anything with the Twitter data. Your basic level of allowed requests is 100 request per hour and IP, but if your application is request-intensive you can ask Twitter for more and get up to 20.000 requests per hour and IP. Of course this has created a flora, or even an entire ecosystem, of applications and implementations where you can tweet, watch statistics, see the most tweeted links and everything you can imagine (just check out this list).

Some tweeting advice

Not that I'm an authority on this, but I still wanted to end with some advice on tweeting:

1. Create good content that you think people want to read. Did you published a blog post? Tweet about it. Going to a conference? Tweet about it. Did you find a new interesting framework? Tweet about it. Got a new fantastic insight? Tweet about it.

2. #tag your tweets. If you tweet "Just found out about this great API http://tr.im/hr8S" end it with describing #tags like this "Just found out about this great API http://tr.im/hr8S #java #dev #twitter" to make it searchable and to add more context.

3. Re-tweet/RT when you read a good tweet. RT is a user derived notation which is used when forwarding tweets. If you get "Jayway.com is a great company!" from me and love it you simply write "RT @mattiasask : Jayway.com is a great company!". Applications like TweetDeck also help you with this...

4. Try to get re-tweeted if you want to spread you tweets. A tweet can travel by RT from social graph to social graph and reach a lot of people that way. Read Guy Kawasakis' blog on how to get retweeted (http://blogs.openforum.com/2009/02/18/how-to-get-retweeted/) for more on this.

/Mattias Ask, @mattiasask

PS. I have to add cool thing about Twitter and the speed of updates, something Twitter co-founder Evan Williams talked about at TED this year. During the California forest fires in -07 Twitter followers where more updated about where the fires spread than the people listing to the traditional media sources where. Why? Because people in the actual areas where the fire spread were tweeting about it from their cellphones...

For good or for bad, the market is unprecedented in its power to generate wealth. What if we could use this power, not to generate wealth, but to generate good?

Since the market understands money really well, why not create representative money based on donations? If we do this, everyone will be able to handle donations as money. We could own it, measure it, trade with it, work to generate more of it... and every cent of it would represent donations for good causes.

This is what OpenCauses.org is doing.

OpenCauses.org really only aims to change one word. Instead of saying "I make donations to good causes" you will say "I buy donations to good causes". This slight change makes all the difference.

What is it we are doing?
We are creating the Open Causes Platform, a non-profit donation platform, which will enable donations to causes aimed at the UN Millennium Development Goals. The Open Causes Platform will also hold Cause Credits. Causes Credits is representative money based on donations. This means that each Causes Credit represents a donation made to a good cause.

When you donate through the Open Causes Platform you receive Cause Credits for your donation. Your Cause Credits are measurable and accumulative, and they are also transferable between users of the platform. All this combined effectively makes Cause Credits into a means of trade.

The Open Causes Platform is an infrastructural platform which exposes a number of web-services. With these services integrators can integrate basically any site or Internet connected product to the platform. Anyone can create pretty much any implementation of donation based services imaginable. They will be able to make donations, show how much users have donated, compare and transfer donation.

Using Cause Credits
If you, as a person or an organization, own 100 Cause Credits you have donated $100 through the Open Causes Platform. If you later donate $10 more, you own 110 Cause Credits.

Now, let's say that I have a cellular phone that I don't use. If you give me your 110CC, I'll give you my phone. If so, I have made the actual donations for $110 and you have bought my phone in two steps. The value of my phone has paid for the $110 donation. You now own a phone, but have not made any donations.

Summary
We are implementing a currency based on donations. Essentially we want to complement the market of today with a market based on generosity. Just imagine if every corporation where to accept a currency based on donations for 1% of their services and products... What couldn't we do then?

Mattias Ask,
Founder of OpenCauses.org

If you have any questions or want more information about the project, go to OpenCauses.org or contact me at mattias.ask@opencauses.org.

Like most people that has been up on stage a couple of times I'm used to talking for somewhere between 30 and 90 minutes. The longest session I've held was at Linköping University where I talked for 3 hours... Now I'm going to talk for 3 minutes, and to quote the people at TED:

"The 3-minute time limit will be strictly enforced -- it's a limit, not a goal."

And they are not kidding! They literally have a clock ticking down and they literally cut you off if you go over. And I have 3 minutes.

So, how do you prepare? Well, meticulous, of course. But how much time do you need to prepare it? Hard to say, but there are actually some hints here and there about that. Among the most interesting I found this:

"Woodrow Wilson was once asked how long it would take him to prepare for a 10 minute speech. He replied "Two weeks". He was then asked how long it would take for a 1 hour speech. "One week", he replied. 2 hour speech? "I'm ready right now," he replied."

This gives us something to aim for:
* It takes 0 days to prepare a 120 minutes speech
* It takes 7 days to prepare a 60 minute speech
* It takes 14 days to prepare a 10 minute speech.

Now we can plot this on a curve like this:

As you might see this is not a linear dependency, meaning that we have to play around a bit. After a minute of that we get this:

This curve is a pretty decent approximation of Woodrows need for speech preparation. It says that in one week he actually could present for 64 minutes, but Woodrow was probably simplifying things when he said one hour in one week. These findings are of course objective and universal. The length of the talk has an deceleration that increases by 2.1% for each day of preparation needed. The last mark is the 10 minute speech. When go beyond that and zoom in we'll see the following:

The questions in the beginning of this post was how to prepare for a 3 minute talk. Based on the chart above we now know that the answer: meticulously, for 17 days!

(On a side note we also know that it takes 21 days to prepare a 21 second speech, and about 25 day for a hefty 1,5 second speech.)

When I first started looking at Neo4j I was blown away by how precise the graph database structure matched my mental model of information. You have blobs of informations (nodes with properties) that relates to other blobs of information. Perfect!

When I started playing around with the API I couldn't do what I wanted, namely extend NodeImpl and make the objects I want to persist Nodes. Now, Neo4j has a very nice API which is hard to abuse (if you don't place your classes in the same namespace as they use), and understandably they don't want you to extend NodeImpl. The design guide gives this example of use:

 
public class CustomerImpl implements Customer{
 
        private final Node underlyingNode;
 
        private static final String KEY_FIRST_NAME = "firstName";
 
        CustomerImpl( Node underlyingNode ){
                this.underlyingNode = underlyingNode;
        }
 
        public void setFirstName( String firstName ){
                underlyingNode.setProperty( KEY_FIRST_NAME, firstName );
        }
 
        public String getFirstName(){
                return ( String ) underlyingNode.getProperty( KEY_FIRST_NAME );
        }
 
        // ...
}
 

That's great, but it doesn't match what I see in my head... In order to make things match I made a subtle change.

 
public class NodeDelegate implements Node {
 
        private Node delegate;
 
        protected NodeDelegate(Node node) {
                delegate = node;
        }
 
        // Delegate all methods of the Node interface to the
        // Node received in the constructor...
}
 
public class CustomerNode extends NodeDelegate implements Customer {
 
        private static final String KEY_FIRST_NAME = "firstName";
 
        CustomerNode(Node node) {
                super(node);
        }
 
        public void setFirstName( String firstName ){
                setProperty( KEY_FIRST_NAME, firstName );
        }
 
        public String getFirstName(){
                return ( String ) getProperty( KEY_FIRST_NAME );
        }
 
        // ...
 
}
 

By doing this I can work with my domain objects as Nodes. I don't know if it is "correct" but with this small change I can say that "A Customer IS a Node" and this is what I see in my head. Good? Bad? You be the judge, but it fits me

Usability is the science of usage which means that usability rules and laws apply to rich clients, web applications, paper forms, furniture, milk cartons, tools etc. It needs to be taken into consideration whenever there is a human end-user. If not, the product will be designed to be specifically useful to the designer.

Know your user

The first question to ask yourself is: Who is going to use your API? If you know that
then you are half way to the bank. Why? Simply because you know what your users
know and want, and thus you can give them what they need.
If the user has a list of objects and wants to remove objects which already exists in
another list, your API could look something like this:

CustomList myList = getMyList();
CustomList yourList = getYourList();
myList.removeSharedItems(yourList);

“myList.removedSharedItems(yourList);” describes what the function does to your
list, and is suited for most any programmer. If, on the other hand, you know that
your users are working with set theory, you would probably want to do something
like this:

CustomList myList = getMyList();
CustomList yourList = getYourList();
myList.toRelativeComplement(yourList);

Let the API be self-documenting

Remember that when it comes to learning or getting started with an API, many pro-
grammers simply rely on the AutoCompletion-function in their IDE. If they don’t
get it from looking at that, they might turn to the documentation, or simply turn to
another competing API. So don’t take naming your classes and methods lightly.
In the previous example both

myList.removeSharedItems(yourList);

..and:

myList.toRelativeComplement(yourList);

..mutate myList. This is visualised by using “remove” and “to” which both refer
to the myList-object. If for example “myList.toRelativeComplement (yourList);”
didn’t have the word “to”, the user wouldn’t know if it returns the relative comple-
ment or if it mutates myList to it.
In SpringFramework, self-explanatory class names such as “BatchPreparedState-
mentSetter” (an interface for a prepared statement setters used during batch up-
dates) are widely used. The only risk with this is that class-, interface- and method
names can get rather long, resulting in poorer readability. Explain what it does but
be as precise as possible and don’t take it to the extreme.

Don’t present the underlying implementation

The API should limit itself to what the user needs to know; no more, no less. The
names of classes, interfaces and methods should describe what they do and what
they are used for; not how they do it. Why force the user to know what the underly-
ing implementation does if they don’t need to know? Open-source your code and
give the user the choice to see how it is done instead of forcing it on them.
Java.io.Properties.loadFromXML takes an InputStream. This means that to load
properties from XML the following needs to be done.

File myProps = new File(“.\\MyProps.xml”);
FileInputStream is = new FileInputStream(myProps);
Properties p = new Properties();
//void loadFromXML(InputStream in)
p.loadFromXML(is);

The fact that loadFromXML takes an InputStream describes what the method does.
A better solution would be to look at SpringFramework’s Resource solution. There
they have a common interface called “Resource” which is implemented by every-
thing from FileSystemResource to InputStreamResource. If java.io.File were to im-
plement such an interface, a solution could simply be:

Properties p = new Properties();
//void loadFromXML(Resource xmlResource)
p.loadFromXML(new File(“.\\MyProps.xml”));

In this case the user of the API doesn’t have to think about in what way the XML
will be read; just that it will be read.

Think of logical mapping

The methods of a class (name and responsibility) must map well to the classes
name; input and output of a method must map the responsibility of the method and
so on. If this is done, the user will be able to use the API intuitively, and learn and
understand how to use it without any documentation.

//Bad mapping in Calendar
void setTime(Date date)
//Better mapping
void setTime(Time time)

Limit the number of options

If you have something in your API that can be done in two different ways, choose
one. Don’t give the user an ambiguous API with features that are so similar that it is
confusing, and force them to go to the documentation or choose by chance.

myCalendar.add(Calendar.DAY_OF_WEEK,7);
//...differs from...
myCalendar.roll(Calendar.DAY_OF_WEEK,7);
//...in what way?

Avoid methods and classes that do
different things in different object states

Separate your domain entities in such a way that they overlap as little as possible.
This is basic OO and should be common sense, but it is a common problem. Java.
io.File has exactly this problem. An object of java.io.File can be a File or a Directory.
If the object is created from the path of a directory it is a directory. This gives the
possibility to write, among other things, the following illogical code:

File myFile = new File(“.\\MyFile.xml”);
boolean dirMade = myFile.mkDir();

A better solution would be if File were structured something like:

interface FileSystemElement extends Resource{
   //...
}
class abstract AbstractFileSystemElement implements FileSystemElement{
   //...
} 

class File extends AbstractFileSystemElement{
   //...
} 

class Directory extends AbstractFileSystemElement{
   //...
} 

Summary

The most important thing to remember is that there is a human user at the other
end of an API. If you remember this you will create better APIs. The pointers in this
article simply scratch the surface of what could be done to improve your APIs. One
thing that would result in great improvements is if you found a couple of users and
user-tested the solution. (http://en.wikipedia.org/wiki/Usability_testing).

Originally published in JayView.