Monday, February 14, 2011

Some more misunderstanding

Very good blog entry by Joakim Holm: the big misunderstanding.

Since the comments are closed I'd like to add that this terminology completely focused on "building" explains why some people think that programmers a.k.a "builders" are interchangeable, like lego bricks. So if you need to replace programmer A in team X because he or she quit all you have to do is call upon programmer B. Then team X will be complete again like nothing had happened.

Related to this is the fact that teams that work well and manage to produce value during a project are usually "disbanded" at the end of that project with all the knowledge gathered during the team's retrospectives, etc lost or at least scattered in documents or wikis that no one will read.
When did you see a good football team that won Champions League being "disbanded"? Never, of course, because it doesn't make sense. The sensible thing is to keep the team together for another project and another...you don't want to let go off your good team...or you shouldn't...

Clearly, we (software developers) are failing to communicate as a group that there's value in keeping good teams together, that there's value in the experience of seasoned developers, that there's value in good design, that it's not just about "building", that knowledge work is not about Lego, and so on.

The ones making the big decisions (but of course there are exceptions!) are not seeing the value in all the above which is surprising since:

Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to (Gorman's Law Of Software-Dependent Business Evolution)

Maybe we need to raise our game.

Wednesday, February 9, 2011

Hibernate, JSF 2 and ManyToMany

It can be quite a bit of a headache if you have multiple checkboxes (or similar) that are mapped to a @ManyToMany relationship using JSF 2 and Hibernate JPA.


In this case, the selectManyCheckbox is mapped to a Set which is annotated with @ManyToMany using a join table. If you want to avoid repeated LIEs when submitting the form you need to add the following attribute:

collectionType="java.util.HashSet"

to h:selectManyCheckbox.

If you use the Hibernate JPA persistence provider and choose default or lazy as the association fetch value an org.hibernate.LazyInitializationException exception can occur at runtime unless you set the collection type. This problem is apparently specific to Hibernate JPA.

Thursday, February 3, 2011

Less (looping) noise with lambdaj

 I know a Java developer who became a project manager when he couldn't stand the pain of having to write yet another loop ;)

If you're stuck with Java and can't use Groovy or less noisy languages, how about doing more with less?

Lambdaj to the rescue! Lambdaj is a powerful library that allow us to manipulate collections in a psudo-functional and statically-typed way. Just a a couple of examples:

Let's say that a collection of task objects and I want to collect the id for each of them.

With your regular Java loop you'd probably write:

With lambdaj I'd write:

OK, that was just one line!

Let's say I want to filter the roles equal to "admin"

The iterative version:


And with lambdaj:

And there's more. Another common task while working with collections is to aggregate their items in some way. Let's say that we have a list of tasks objects with end dates and I want to get the max end date for all of them.

Without lambdaj's aggregating functions:

With lambdaj you just write:
maxFrom(tasks).getEndDate();

This is just a small taste. See more features here: http://code.google.com/p/lambdaj/wiki/LambdajFeatures

Download http://code.google.com/p/lambdaj/ and loop less!