I just found that you can configure Eclipse not to write rewrite the wildcard import for certain cases. See the picture how to get there.

Definitely a place to go back again (We even caught ourselves dreaming about living there )

123►

Agile games…. waddayasay? Ok, it was fairly new for me as well, so I can imagine I need to elaborate a bit more. Agile games are about making people aware of things that can be improved about a process. Yup, as broad as that. For instance, let me describe some of the games played.

Penny game

The penny game is about having a table with at least 4 people, that’s the team. Each player is backed by a manager and you’ve also got the customer in the end. How quick is the team able to deliver flipped pennies to the customer. Player 1 starts off with 20 pennies. He’s gotta flip all pennies and then pass them on (in a batch of 20, no cheating!) to the next person in the team. This person flips the pennies back up again so that the queen can watch our pretty faces again. This goes on till the last team member which delivers all the pennies in batch to the customer. The customer is armed with a stopwatch and notes the time the first and last item are delivered. As this is a batch these are of course the same.

Then… smaller batches. You still got 20 pennies, but now lessen the batch size to 5. Flip 5 pennies – pass ‘em on – Flip the next 5 pennies – pass ‘em on, et cetera. This is different to the first round, as:

• The customer is getting the first penny faster than before
• The batch sizes decrease, so the team member in the end of the chain are processing pennies as the first person is still flipping new ones as well. So the total process speeds up as there is less waiting

Next try a batch size of 1. Whow… now the customer is getting stuff real fast. Also, if you’ve got any quality issues it is immediately noticed by a team member as opposed to be hidden in a large batch. Lesson to learn in real life processes: focus on improving one-piece flow. I don’t want to make this blog post toooo long, I might post something about that someday.

Multitasking game

Everybody knows (right?) that multitasking for people is bad. Women can do it better compared to males women consistently say, but still even for them it isn’t the best. This simple game proves that. Draw three columns on a whiteboard. The first column will contain numbers 1-10, the second column will have A-J and the last one will have the Roman numbers I-X. First do them all sequential, that is one column at a time. So note 1, 2, 3 … 10. Next, A, B, C … J and finally I, II, III … X. Time that and note the time passed.

Secondly, do one number of a column at a time. So then you’ll get a 1 first. Move over to the next column for an A. Finish the line in the Roman column with a I. Then a 2, B, II. 3, C, III, … Stop the clock and note the time passed. As you can imagine this will take longer. How come? You constantly context switching. This is only a simple example compared to real life, but your mind has to adapt of processing decimal numbers to Roman numbers. How come in work processes it is still often the case that people believe multitasking is good.

Ball game

Whow… this was fun. Hard to explain it fully at these late hours, but it’s about passing balls (take ping pong balls for easiness sake) through the team as fast as you can. Some rules apply, as you cannot throw them to the people right next to you. Make up a scheme as a team in which you think you can toss around the balls the quickest way possible. I’m not gonna give this away fully, but you suck the first couple of times! Then the product owner comes in stating that there are teams capable of doing this in just a few seconds, while you’re currently doing over 20 seconds. Shoot…. this make creativity rise to the fullest. You will come up with solutions you can’t imagine to let them pass the team. I’m not telling you the secret but I’m proud we made it to 1 (or was it 2) second(s)

That’s not even all, but need to go to bed as I got an early day tomorrow. It was loads of fun meeting fellow agile minded people. Had a blast being with you tonight. And thumbs up for the organization and for the catering (http://www.eetwijn.com).

After the first bit (theoretic part), you would go for the hands on action. First up, theory. 20 questions are up, of which you need to have 15 right. Most of them were rather easy, especially if you’d have practiced a lot of exam questions. After about 20 minutes I was the 2nd person leaving the room. Out on the terrace which filled up with more contestants there was heavy discussion about the questions. My dear friend N stepped outside 5 mins later. We both felt quite confident about it. Then the news came… I was invited to take the practical exam as I scored 20/20! Friend N scored 18 right. We went in different pairs to the championship course of golf course Naarderbos. There we played hole 1, 2, 4 and 5. Of the best 3 holes played you were allowed in total 10 above par. So if you played really well (which N did ) hole 4 was just for fun. My play was not too bad, but not that smooth either. The lady I played with unfortunately did not play that well. During hole 2 I realized that if I kept playing the way I did, I would surely pass. Some lousy and some magnificent shots later the verdict came: I passed! Triple yay My lady partner however did not.

Back on the terrace N came with his good news. After a nice lunch out in the open, we played the par 3 course. A nice track of 9 holes , not as much fun though as the 18 holes. We both played 38 strokes, 7 below our freshly acquired handicap of 36.

After finishing enjoying a nice beer I went to a presentation of Lars Vonk about Test Driven Development (TDD in short). He explained very clearly about this concept: first write your functional oriented test case, then write your code. He described a tool called Fitnesse, in which you can create these tests using pretty much natural language. I’ve heard about TDD before but now it triggered something inside me. Stuff to think about. It’s on a higher level compared to unit testing. With unit testing you can only verify so much, but you do not test if the software integrates well. With TDD you write actual integration tests, focusing on the bigger picture. Furthermore, you can also reuse already written tests. What more do you need in life

Inside you would register for your iPhone, in both our cases the 32 GB black edition. Hope we won’t mix up phones some day So much staff around, it pretty much outnumbered the crowd in the beginning. They did a good job though in the cool&clean T-Mobile stilo. Inside amazingly I got a ticket for the third iPhone! Fem got ticket 21 (huh?). While lounging there you could give the new iPhone demo models a try, Mac apparati available for checking your mail and a concert pianist and some kind of DJ was there for amusement. And then…. 9 am! Being third in line and cruising through the press (photographers, TV stations, radio (BNN)) I got in the shop. Complete mayhem in there, pretty much like the “DDD dagen” at the Bijenkorf 20 minutes later I was the proud owner of my new iPhone. My new matey is lying next to me, charging and loading my iTunes music. How sweet is that!

See flickr for pictures.

The CD did not cost much, plus it gave me the opportunity to get to know some new bands. One of the bands present on that CD is Flyleaf. The song “I’m so sick” immediately got my attention, because of the aggressive tone and psychedelic sound of the front woman Lacey Mosley. The live sound is actually a bit different (and somewhat weirder) ) compared to their own CD. Most likely because of the volume of booz consumed

The song also appeared in Die Hard 4, played when the terrorists attacked the home of the computer hacker.

You can check their album at Last.fm.

An assumption is made that the blocking action is done due to the upcoming memorial day of the Tiananmen Square protests of 1989. I know Sepultura made a song in 1994 referencing to this: Refuse/Resist. This song is against world disorder. The inside of the EP shows a picture of Tank Man. That’s the name of the man who stood in front of the line of tanks. Astonishing… I was just a little guy back then (10 yrs old) but I still remember seeing this event on tv and the impression it made back then. I don’t know everything there is to know about China, but I do think it a scary country. Remind what they do (and did) to Tibet.

However (sence the tone in the title ) things do not turn out that magnificent as we’d hoped. If you’d check out. You’d see a three level dependency graph. Main artifact A depends on B,C and D, which in turn all depend on E. However, they each depend on a different version of E. The order of the dependencies in A’s POM is first A, then B and finally C. My idea always was that Maven would check depth and versioning and would actually compare different versions of the same artifact. In this example, Maven would compare versions 1.0.0, 1.0.3 and 1.5.0 and would come to the conclusion that at this level version 1.5.0 would be considered the best. Maven would come to this conclusion by using the <major>.<minor>.<revision> scheme. Only a major upgrade of E – so a version 2.x.y – could break stuff, so while you’re safely in the 1.x.y zone, you’re good. Just take the highest referenced version.

Unfortunately…

Maven does not work this way. A tiny note in the Maven docs (which I should’ve noticed of course) states the following:

Dependency mediation – this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the “nearest definition” which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project’s POM. Note that if two dependency versions are at the same depth in the dependency tree, until Maven 2.0.4 it was not defined which one would win, but since Maven 2.0.5 it’s the order in the declaration that counts: the first declaration wins.

So the closest dependency to the root gets to win and order in your pom.xml matters. In our example version 1.0.0 of artifact E will prevail – see Figure 2 why. The only way to fix this (currently) is to change the order of the dependencies in your POM, or to explicitly list a dependency of E in your POM with the version you would like to have. This could be a real bugger as components C and D may expect bugs to have been fixed or interfaces to be present (say stuff that has been introduced since 1.0.3). You could end up with nasty runtime issues.

Now what?

I’m currently working on a plugin that will try to traverse the graph and list the maximum version of each dependency (including transitive ones). Then it will match this with the actual version that Maven decides to use. If this does not match it will list in in some kind of report. Still work in progress, so things might turn out differently.

Whow…. an important moment in time has come. Birds are flying by, looking inside to see what is happening here and yes…. here it is: my blog.

I’ve seen quite some blogs out there, but I’ve decided to begin my own. This came up since I’m doing cool stuff at work – see my profile page for details – and because I’m shooting more and more pictures with my digital camera that I want to share with the world. Hoping to have just some visitors someday

It’s time to play…

Cheers!