Default maven:

mvn clean install
...

[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7:05.842s
[INFO] Finished at: Mon Sep 13 19:23:29 CEST 2010
[INFO] Final Memory: 193M/1216M
[INFO] ------------------------------------------------------------------------

mvn clean install -T 4
...

[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:04.982s (Wall Clock)
[INFO] Finished at: Mon Sep 13 19:29:02 CEST 2010
[INFO] Final Memory: 135M/1326M
[INFO] ------------------------------------------------------------------------

This is on my quad core I7 system. The amount of parallelism you can achieve depends on the structure of your project. If you have a project where C depends on B depends on A, you will not get a speedup since nothing can be build in parallel. If on the other hand, C and B just depend on A,you can now build B and C in parallel.

There's also an option (Weave Mode) to run different phases of different modules in parallel (for example compiling B while still running tests of A), but that doesn't yet work reliably on this project. I guess it could allow for an even greater speedup, since even dependency trees like C depends on B depends on A could then be parallelized.

The largest and slowest module of this project takes about 2 minutes to build (it has more than 800 scenario tests). Now, since that module actually implements 2 different taxes, it can be further split up into three parts (one common and 2 for the specific taxes). Doing that, I can now build those three parts in parallel, taking only 1.40 minutes instead of two. That's why multiple smaller modules are better than one larger as far as build speed is concerned (and you want multiple modules to enforce your modularity anyway).

This kind of feature, and the ease with witch you can use it out of the box, is what I absolutely love about Maven. Ok, the strict Maven model limits you in some ways at times, and the pom.xmls can become very verbose, but you gain so much back.

P.S.

Does anyone know whether any other build systems (Gradle, SBT, ...) have anything like this? (I can't imagine trying to do anything like this by myself in an Ant build.)

Technorati Tags: java maven parrallel

Nothing helps you better at learning the idioms and libraries of a language than actually programming in it. If you're learning by reading a book (which is how I always learn them), the exercises in it (if any) are either not interesting, too trivial or too large (unless you're reading the excellent Little Schemer, which is basically nothing but exercises). So you need to find some problems to program on your own. In the past, I either had no idea what to try, or was way too ambitious.

But this has changed now that I recently discovered the Programming Praxis website. It contains quite a bit of interesting exercises that always have a reference solution in Scheme. People can also post their own solutions (mostly in functional languages though).
I especially liked the Josephus problem, but I have to admit it took me quite a bit of time to come up with an elegant, working solution, only to learn that I came up with the most inefficient of the three proposed reference solutions :)

But at least now I'll never be short for exercises in the future :)

Technorati Tags: programming exercises scheme

I just read the first few chapters of The Little Schemer (the first three editions were know as "The Little Lisper"). It's a classic introduction to the Scheme/Lisp language that is written in a very unique style. Instead of lots of long paragraphs of text, it is written in the form of questions and answers (you can find an example chapter on the homepage of the author here). I really like this style, but the opinions are very mixed if you look at the reviews on Amazon. It seems people either love it or hate it, but not much in between.

After only two pages you know what an atom, a list and an s-expression are. Once those basic building blocks have been introduced, the questions gradually build up, letting you learn about car and cdr (getting the first and all but the first elements of a list), and using those primitives to build other list-manipulating functions.
It's not really a full coverage of Scheme the language, as much as it is an introduction to the programming style and culture that defines Scheme.

A very big part of that culture is recursion, which is the emphasis of the book. Recursion seems to come very natural in Lisp: solving problems in the same style would be unreadable in more imperative languages like Java, but are a thing of beauty in Lisp.
I had never really gotten the fascination with recursion, finding the examples often more complicated than simple loop-based ones, but I'm starting to come around on that after reading this book.

The minimal syntax of Lisp is definitely something you need to get used to. It seems like something of a wonder to me that you can write full fledged programs using only round brackets :). I still think that it would be painful to read through lengthy programs written in it, since it seems to be harder to quickly see the structure of the program. But it's probably also something that grows on you.

All in all, it's nice to be introduced to something that is so alien compared to what I use in my daily programming. I'm also very surprised to see how high level Lisp is, considering it has been around since 1958, which to someone my age is still the dark ages :).

Technorati Tags: lisp scheme

Today, I was talking to someone about how we made a fluent interface/dsl that allows us to construct data needed for our scenario tests in a readable and maintainable way. This allows us (the developers) to quickly create and understand tests, and even allows us to explain them to a business analyst when discussing a requirement/bug/current behaviour.

He asked me to clarify what I meant with readable, and since talking about code without seeing any is pretty hard, I'm showing an example here.

The core of our datamodel needed for calculating immovable property taxes consists of the following connected entities (a simplification of the real model):
As you can see, that's already quite a bit of data we will need to setup. Since this datamodel is also bitemporal (data has a validity and record dimension to it) and sourced (meaning several sources/reporters can report the same kind of data), setting things up gets complex and verbose very quickly.

This is what a (partial) setup would look like in our raw entity model API:

Person landlord = Person.create();
landlord.getPersonalEvent(Reporter.RR, PersonalEventType.BIRTH)
		.set(new PersonalEvent(PersonalEventType.BIRTH, new Day(7, 6, 1980), Reporter.RR),
				ValidityRange.fromToday());
landlord.getPersonName(Reporter.RR).set(new PersonName("landlord", Reporter.RR));
landlord.getExternalIdentification(Reporter.AKRED, ExternalIdentificationType.AKRED_NUMBER).set(
		Collections.singleton(new ExternalIdentification(ExternalIdentificationType.AKRED_NUMBER,
				"1234567890X", Reporter.AKRED)));
landlord.getOccupiedSpace(Reporter.VLABEL).set(new OccupiedSpace(someSpace, landlord, Reporter.VLABEL));


CadastralArticle article = CadastralArticle.create(someCadastralDepartment, 1);

Collection<RightState> rightstates = CollectionFactory.newList();
RightState rs = new RightState(landlord, 1, new Percentage(100));
rightstates.add(rs);
article.getTimeSlice(Reporter.AKRED, null).set(new TimeSlice(Reporter.AKRED, rightstates),
		ValidityRange.wholeYear(2009));

ImmovableProperty ip = ImmovableProperty.create(someCadastralDepartment, "some-long-code");

Collection<ImmovablePropertyIncome> incomes = CollectionFactory.newList();
ImmovablePropertyIncomeBuilder builder = BuilderFactory.createBuilder(ImmovablePropertyIncomeBuilder.class);
builder.setCadastralIncome(new MonetaryAmount(100));
builder.setFiscalStatus(FiscalStatusType.NORMAL);
builder.setSequenceNumber(1);
builder.setType(ImmovablePropertyIncomeType.NORMAL_BEBOUWD);
incomes.add(builder.build());
ip.getIncomes(Reporter.AKRED).set(incomes, ValidityRange.wholeYear(2009));

// and it just goes on and on

As you can see, that's quite some code to setup the data (and it's just a trivial scenario). Just imagine trying to maintain hundres of testcases written this way. Now, this is what it looks like in our simplified API:

// we need the finals since they're being used in the anonymous inner classes we create.
final Person landlord = new TestPersonBuilder() {
	{
		bornOn(new Day(7, 6, 1980));
		name("landlord");
		eid("1234567890X");
		occupies(someSpace);
	}
}.build();

final CadastralArticle article = new TestCaBuilder() {
	{
		articleNumber(1);
		fullyOwnedBy(landlord);
	}
}.build();


ImmovableProperty house = new TestIpBuilder() {
	{
		plotCode("some-long-code");
		normalIncome(100);
		includedIn(landlordArticle, sequence(1));
		equivalentWith(someSpace);
	}
}.build();

This is already quite a bit more readable, and at the same time offers more functionality. Sane defaults are being used behind the scenes, but you can still override them where necessary. By using these TestDataBuilders (as we called those classes), we've been able to implement hundreds of testcases in a readable and maintainable way, and it was much worth the effort coming up with those.

Technorati Tags: java tdd

I recently ran into a Scala / TestNG gotcha that proves how much of a Scala noob I still am (but also the kind of problems you can have with the type inference features).

Scala has two nice features that can make your method definitions very succinct, but as is the case with many of such features, they can cause some problems of their own if you're not careful.
The two features are:

• result type inference
• optional return statement

The result type inference allows you not to specify the result type of a method, allowing the scala compiler to infer it:

// the result type is explicitly defined
def getFooWithResultTypeSpecified() : String = {
    return "123"
}

//the result type will be inferred
def getFoo() = {
    return "123"
}

val foo = getFoo()
// foo will be inferred to be a String as getFoo was inferred to returning String.
assertEquals(foo,"123")

The optional return statement is exactly that: it allows you to leave out the actual return statement. The compiler will use the result of the last expression as the result type.

def getFoo() = {
    "123"
}

val foo = getFoo()
assertEquals(foo,"123")

The gotcha I had was in the combination of these features. TestNG considers test methods to be those methods that are both public and void returning. So let's say I start out with he following method:

def testFoo() = {
    val foo = new Foo()
    // if doSomeVoidMethod doesn't fail, it's good
    foo.doSomeVoidMethod()
}

The correct protection against this is always ensuring that your test methods are explicitly declared to return Unit (void) like this:

def testFoo() : Unit = {
    val foo = new Foo()
    // if doSomeStringReturningMethod doesn't fail, it's good
    foo.doSomeStringReturningMethod()
}

def testFoo() {
    val foo = new Foo()
    // if doSomeStringReturningMethod doesn't fail, it's good
    foo.doSomeStringReturningMethod()
}

Technorati Tags: scala java testng

I always thought this sentence was reserved for Perl, but I recently discovered that this can unfortunately also be applied to Scala. Scala supports operator overloading (although technically it's not), so we see the good and the bad sides of this.

Representing the good side, you have the parser/combinators library that comes with scala. It implements a DSL that looks very natural if you're already familiar with the BNF form.

The dubious honour for representing the bad side in this case goes to the Dispatch library. I was looking for a library that would allow me to make some calls to a restful service (couchdb in this case), and came upon it.

It has some of the worst abuses of operator I've seen in a while. Look at the following lines you can find in the introduction docs:

import dispatch._
val http = new Http
val req = :/("example.com") / "path"

val rhead = req <:> Map("Cache-control" -> "no-cache")
http(req / "somefile.xml" <> { _ \\ "book" })
val rauth = req as ("user", "secret")
val rquery = req <<? Map("key" -> "value")
val rform = req << Map("key" -> "value")
http(req >~ { _.getLines.foreach(println) })
val rsec = req.secure

Now, I left out the comments above each line that explain what the code does, but that is my whole point. There is now no longer any way for someone not already very familiar with Dispatch to have any idea whatsoever about what that code does. Even if I were to write code using this library, I'm certain that I'd have trouble figuring out what it exactly does again only a week later.

It really feels to me that the author of this library has an innate hatred against the alphabetic part of his keyboard. There's i.m.o. no other justification for letting "<<?" mean "add a query string to the request".
Even a javastyle req.setQuery(Map(...)) would have been much better, rememberable and readable.

If libraries like Dispatch represent how idiomatic scala will be written, I'll be looking for another language to succeed java.

A small bonus :)

("@ , There's been
°!&  0 an explosion
#^a /|\ at the ASCII
`;<  |  factory!!!!
@a  / \

Technorati Tags: scala dispatch operator overloading

If you're like me, you spend quite some time in the total dark behind your computer screens. The only light is coming from your display, but even that may be too much at times.

Recently, I discovered a nifty little app called Nocturne for the Mac (which I'm fortunate enough to use :), that allows you to switch to a "night mode". It basically inverts your display, so all whites turn black and vice versa.

Since a picture says more than a thousand words, I'll display the effect here:

Nocturne enabled:

Nocturne disabled:

You could do the same by creating some color profiles for your apps/os, but that gets tedious quick. The only drawback to this solution is that it is not a very good mode to process your photos at night :)

Technorati Tags: nocturne

Another weekend, another location that needs to be visited. This time, we went to an abandoned (duh :) castle somewhere in Belgium.

We had gotten a tip from fellow urbexers, and decided to check it out. As far as I know, no one had visited that place before. Finding the castle wasn't hard, since you could see it from the main road, but that didn't mean it was easy to get in. Since the only "official" entrance to the domain around the castle passed right along some villas, which had clear signs of activity, we decided to look for another way.

I had spotted another road on the GPS that led to the other side of the domain. Unfortunately, it was only a very muddy dirt road, used by local farmers. After a while, we found ourselves walking along the forest of the domain, spotted a weak part in the fence around it, which we could jump :)

But as it turned out, that was only the easy part: there were no real paths on the domain. So we had to walk a few hundred meters in shoulder-height nettles, while we tried to make our own path while guessing what the direction towards the castle was. Fortunately for me, I was wearing long trousers (experience tells me that this is a wise thing to do while urbexing), but unfortunately, I was only wearing a simple T-shirt. So I ended up with having itchy arms for the rest of the day :).

Progress was slow, we weren't absolutely sure we were going in the right direction, but in the end, we could spot the castle. What we saw was already worth it: a beautiful green pasture, filled with sheep, that were grazing along the pond that is located around the castle.

We took some shots from the outside, while at the same time trying to see if we could spot an entrance. It didn't look to good, all windows and doors were barricaded. But on the other side of the castle, we did spot an entrance that seemed to lead into the basement. When we entered, it became clear that the basement was used as a stable for the sheep. We found a door that lead upstairs, and so we entered the ground floor (pretty much the only floor of three that was still not collapsed).

In there we found stacks of hay, a stairwell without stairs, lots of animal cages and lots of remains of the top floors :). It was there I took this shot:

It's a shame that the rest (what was left of it after more than 50 years of abandonment) of the castle was in such a bad shape, so we only spent time on ground floor. But it sure was all worth it.

Technorati Tags: urbex belgium photgraphy castle

You should really follow that comic if you don't already (most of them are not about games).

Technorati Tags: mario cyanide and happiness

This saturday, my girlfriend and I went to Aalst, to visit the abandoned factory Du Parc. Du Parc was a brand of stockings that was manufactured in there, along with other things like socks and underwear.

Finding the entrance and getting in was pretty easy, and once we were in, we quickly started scouting the place (over time, we've come to realize that it's better to get a quick view of the whole place, so you can focus on those parts that are the nicest to shoot. It has happened before that we discover the most beautiful parts at the end of the day, when it is getting dark :).

A large part of the factory was blackened by a fire that had once raged in it (officials decided that the fire was no accident). There was still lots of semi-burned paperwork lying around. I must say, the traces of the fire produced a very nice color pallet. The production areas themselves were in no better state: leaking, collapsed and even missing roofs, rotten floors, oil spills, ...

There was one particular thing about the place: slogans were painted on most of the walls. The slogans themselves were incoherent messages, and ranged from (translated from dutch) "Ripped of - Thieves are pretty stupid" and "Students, you have no business here" to "And especially you two sluts should stay out of here".

Now we are used to seeing lots of graffiti in places like that, but this kind of painting was new for us :)

After a few hours of shooting, all of the sudden some man/woman (we're still not sure) who looked pretty much like an escaped psychiatric patient came to us,started asking what we were doing (shooting, duh :) and whether we had permission (of course we didn't :). We were not impressed and when we started asking whether he himself had permission, that person threatened to call the owner. Much to my surprise, a few seconds later, a fancy cell phone appeared, and he started "calling". I say "calling", as I can't tell for sure, since that person was gone as fast as he had come. I seriously doubt he actually called anyone (other than some imaginary friend :)

An hour later, in another part of the factory (it is a pretty large place), we ran into him again. He seemed to be surprised we were still there, once again mumbled something about the owner, and quickly disappeared again. But he had been active in that time: a small stairway that we had used early in the day, was now amateurishly barricaded with a cupboard and some fire extinguishers. It probably wouldn't have been able to slow down a 2 year old infant for longer than a few minutes :).

Once we were outside of the factory, to take some shots of the exterior walls, he even followed us from a distance, trying not to be spotted. Going out, we had also spotted another painted wall, with lots of text. It seemed to be one long incoherent rambling, of which I only remember fragments like "too much to the far right is dangerous", "illegal activities take place here", "porn inside this building". all very interesting :)

But still, it makes you wonder what really went on in that mind of his: is he really thinking he's battling with thieves? Doe she suffer from delusional paranoia? There's really nothing (left) in that building that could be of any interest to thieves. It's also pretty sad that people still live like this in our said-to-be wealthy country. That person probably needs help.

A shot taken that day:

Technorati Tags: urbex aalst

In my current project, we have a lot of immutable values (a side effect of the fact that we have a bitemporal domain¹², but that is a story for another time). We decided to actually enforce that immutability, so those values have no methods that mutate its state (a.k.a. setters). So all properties must be set at creation time using the constructor.

Now, some of these value classes have 10+ properties, so instantiating everything using the constructor isn't an attractive or readable option. Ideally, you'd use some kind of Builder Pattern to set those properties and create the actual instance once you're done setting them.

The only part that sucks about using Builders is that you have to code, test and maintain them. This is the part where dynamic proxies and code generation can come to the rescue. In the way I implemented this, we have three components in the solution:

• The immutable value class (OrganizationState is this example).
• Builder, an interface that defines a Builder, which is a class that knows how to build instances. This one should be extended for each concrete type you want to build, containing setters for each of the properties you want to set.
• BuilderFactory, a concrete class that can generate an implementation of the right Builder. This is done using JDK proxies.

Using those components looks like this:

The value class and its accompanying Builder interface:

public class OrganizationState implements Serializable, Reported {

	private Day foundedOn;
	private Day endedOn;
	private OrganizationEndReason endReason;
	private OrganizationType type;
	private EstablishmentType establishmentType;
	private KboStatus kboStatus;
	private Reporter authenticReporter;

	public OrganizationState(Day foundedOn, Day endedOn,
OrganizationEndReason endReason, OrganizationType type,
EstablishmentType establishmentType, KboStatus kboStatus, 
Reporter authenticReporter) {
		this.foundedOn = foundedOn;
...

public interface OrganizationStateBuilder extends
 Builder<OrganizationState> {
	void setFoundedOn(Day foundedOn);
	void setEndedOn(Day endedOn);
	void setEndReason(OrganizationEndReason endReason);
	void setType(OrganizationType type);
	void setEstablishmentType(EstablishmentType establishmentType);
	void setKboStatus(KboStatus kboStatus);
	void setAuthenticReporter(Reporter authenticReporter);
}

As you can see, we have 7 properties that need to be set. Using a constructor would lead to wieldy, unreadable code, especially when you have have lots of properties of the same type. The Builder interface itself looks like this:

public interface Builder<V> {

	/**
	 * Initialize the V instance being built by the builder
         * with given prototype instance.
	 * @param prototype
	 */
	void fromPrototype(V prototype);

	/**
	 * Build the product (a V instance) and return it.
	 */
	V build();
}

Now the client code for using a Builder looks like this:

 
//create an implementation of the OrganizationStateBuilder, using JDK proxies.
OrganizationStateBuilder builder = BuilderFactory.createBuilder(OrganizationStateBuilder.class);

//set the properties on the build, from is a TO that comes from the frontend.
builder.setAuthenticReporter(from.getOrganizationInfo().getAuthenticReporter());
builder.setFoundedOn(from.getOrganizationInfo().getStartDate());
builder.setEndedOn(from.getOrganizationInfo().getEndDate());
//set some more properties
...

//build the actual instance.
OrganizationState state = builder.build();

OrganizationState prototype = ....;
...
OrganizationStateBuilder builder = BuilderFactory.createBuilder(OrganizationStateBuilder.class);
builder.fromPrototype(prototype);

builder.setFoundedOn(Day.today());
//build the actual instance.
OrganizationState state = builder.build();

As you can see, this code look much easier on the eyes than the equivalent constructor based version would look. For the next part, we'll look at how the BuilderFactory is implemented, and I'll talk about the how this code is generated and tested.

One of my colleagues recently had an issue with a javascript validation method that was being generated (and called) by trinidad. He wanted to change the behavior of the method (basically adding a guard clause in the beginning), and did this by copy pasting the existing method, modifying and defining it again. He knew this was asking for trouble anytime the trinidad implementation changes, so I helped him work out a better solution.

Since in javascript, functions are full-fledged objects, you can have references to them (this is something that escapes most programmers when they only have a basic knowledge of javascript). But in our case, that provides everything we needed to solve our problem. So I suggested something like this instead:

//keep a reference to the original function
//notice we don't use (), otherwise we'd execute the function.
var origThirdPartyFunction = nameOfTrinidadFunction;
//make the name of the original function point to our version
nameOfTrinidadFunction = patched;
	
//our version of the fuction
function patched() {
	//check some stuff before
	if(someCondition) {
		return;
	}
	//call original trinidad method
	origThirdPartyFunction(arguments);
}

The trick is in the first line: you can refer to a function by assigning it to another var if you don't actually call it by using round brackets. In the next line, we're doing the same, but now with the function we defined ourselves. In that function, we call the original function with the name we gave it.

So now, anytime trinidad calls the function under its original name, our version will get executed instead. This way, we could add the guard clause, without potential breakage should the trinidad implementatin change, since we no longer copy it's implementation.

Now, there are also other ways to implement this, like using AOP with javascript :)

Technorati Tags: javascript trinidad