I have been working in Scrum teams for quite some time now, and I am a big fan of the method. One thing I always wondered about however is why product owners seem to change their minds so often after a sprint delivery.
The last few months I got the chance to experience Scrum from the product owner’s side and it really confirmed the value of the method to me and also taught me a valuable lesson…
I have an Arduino Uno that I want to use to drive a LED banner sign which posts messages from IRC. Accessing the serial port from Java on a Dockstar with Debian proved to be somewhat of a challenge.
When I was a little kid my parents often took my little brother and I to a sand quarry to play or pick berries; later, when I was in my early teens, we spent summer holidays near an active drifting sand plain. These places looked huge then; a trek across the sand felt like an expedition into unknown territory, the slopes of the quarry looked like enormous cliffs…
Around the same time, I started programming. First in MSX Basic, then in Z80 assembly. This was a magic time of discovery, having a machine printing out text to you, drawing images and animations, and making sounds (and combining those to devise an intruder alarm for your room, scaring mom!). It gave me a feeling of great accomplishment.
A lot of things I saw on Devoxx do not warrant their own blog post, but they are interesting enough to mention.
I attended two presentations on improving the Agile process once it’s implemented. Sven Peters of Atlassian gave us seven ideas to make good teams great, and Trisha Gee and Isra Rodriguez of LMAX talked about the problems they encountered using the Agile process.
Andres Almiray vented his frustration on the creation and maintenance of boilerplate code – you know, getters, setters, toString, equals, hashcode, singleton and factory stuff – citing Project Lombok as an alternative.
Today at Devoxx I saw two presentations back-to-back that dealt with integration of sensors and controllers with your personal computing devices, but without the need to pick up a soldering iron.
JBoss AS 7.1.1 has version 2.2.13 of the HornetQ messaging server built-in. I needed to use JMS for a Camel route from outside the container and found that configuring and using HornetQ is not really difficult. It can be confusing however, mainly because the documentation and examples I found often refer to a different version of either HornetQ or JBoss AS. In the end I got it to work; to save you the trouble of having to find it all out by yourself, I thought I’d write a walk-through of the process…
For the project I was working on, I wanted to try out the Mule ebMS adapter written by Clockwork. This adapter needs Mule 2, but unfortunately some of the dependencies for the latest release of Mule 2 (2.2.1) seem to have vanished from the popular Maven repositories.
No worries though, the Mule 2.2 source is not dead yet! Looking into their subversion repository you will find newer tags, so I checked out the latest tag, 2.2.8, and tried to build it – only to get a build failure.
I was using Maven 3, but Mule 2 was written for Maven 2. Not wanting to install an older version of Maven, I set out to fix the problem. Turned out there were actually two:
Firstly, Maven 3 does not want you to use values directly in the <includes> element, not even if it is a single value instead of a comma-separated list. Rather, you should use the child <include> element.
Secondly, the gmaven-plugin version used by Mule does not play nice with Maven 3. Upgrading to the latest version (1.4) fixed that.
This one was not all that hard to solve in the end, but it took a lot of googling and experimenting. I hope I will save you that trouble!