JoergM.com

I recently saw Bob Martins Keynote on Øredev. Around time index 14:30 he is talking about length of iterations. This reminded me on some experiences we made recently when trying sprints of one week in some of our teams. So here are some aspects we found.

The Good

• Scrum zeremonies are done very often. The people on the teams were used to scrum, but the teams were new. So the training effect of doing planning, review and retrospectives so often was good. By the way, the zeremonies are proportionally shorter. There is no waste of time just because there done more often.
• The short iterations gave a good feedback on where the project was going and how long this will take.
• The focus is very high on completing the sprint-tasks, but this is not only a good side. See also the Ugly.
• Teambuilding happens faster than with longer iterations. I think this is mainly, because teambuilding needs all phases of an iteration to be completed and shorter iterations mean the phases happen more often.

The Bad

• Tasks need to be prepared very well. A one week iteration is not only challenging for the team. It is even more challenging for the product owner. Tasks need to be well prepared and small enough to fit into one week.
• Some people on the team will not like such a short iteration. You need to get the commitment of everybody that they want to try this for a while.
• Things that go wrong, hurt faster and harder. This is good as long as the real reason will be removed. But it is easy to think of the short iteration to be the problem instead of the real reason.

The Ugly

• As already said, it is easy to get in a situation where the one week iteration is seen as the problem even if there are other reasons. This can remove this option for the future. So make sure the situation is ready, before you try.
• People can feel like being in a hamster’s wheel. This prevents from taking a step back and seeing the whole picture. Short sprints can show a lot of problems in the process, but they can hide larger issues or prevent alternative approaches. Everybody just feels they have no time for it.

So what is your experience with one week sprints? Is it just like Uncle Bob says: “It takes a real man to do one week iterations”?

Transforming data in XML to several Java-Objects is a pretty common task. There are a lot of technologies that support this. One example would be JAXB. It is also not uncommon that the structure of the original XML and the Java objects does not match. The obvious choice for XML transformation in such a situation would be XSLT.
There is another approach that uses Groovy to transform XML directly into a POJO structure in one step. I will show you how this looks like.

Lets assume, we have a XML-file like this:

<data>
  <person>
    <firstname>Otto</firstname>
    <lastname>Mueller</lastname>
    <street>Lange Strasse</street>
    <city>Berlin</city>
  </person>
  <financial>
    <netincome>120000</netincome>
  </financial>
</data>

The target structure are two POJOs that look like this:

Both structures differ. There are also some small conversions to do. The XML includes yearly income, where the POJOs needs monthly income. The POJOs contains a field for zipcode, but the XML does not deliver it.

So, here is the Groovy-Code that does all the transformation:

public class XmlTransformer
{

  Person transform(File xml)  //1
  {
    def xmlData = new XmlSlurper().parse(xml)   //2

    Person person = new Person()

    person.firstName = xmlData.person.firstname   //3
    person.lastName = xmlData.person.lastname

    Address address = new Address()
    address.city = xmlData.person.city
    address.street = xmlData.person.street
    address.zipCode = ZipCodeFinder.find(xmlData.person.city.toString(),   //4
            xmlData.person.street.toString())
    person.address = address

    BigInteger yearlyIncome = new BigInteger(xmlData.financial.netincome.toString())
    person.monthlyIncome = yearlyIncome.divide(12)  //5

    return person
  }

}

What happens in detail (numbers on the list match the numbers in code comments):

1. This is a simple Groovy class that contains one method called transform. This method gets the XML-file as input and returns a Person object. The Person class itself is defined in Java.
2. XMLSlurper  is the Groovy XML-Parser that allows the easy access to all xml elements. For more details on it see here.
3. This uses some Groovy magic. On the left side we assign the value to the property firstName of the person object. This is a shortcut for using person.setFirstName(). On the right side we see the slurper at work to get us the XML value.
4. We can call any Java-class from within the transformation code. Here we call an example helper-class, that would return a zipcode for a given city and street.
5. Finally we also do some calculations within our transformation to convert the yearly income to a monthly value.

Groovy can be called from Java in several ways. If you do not need to change the transformation often I recommend to just compile the Groovy code. In that case it will be called from Java as if it would be Java code:

XmlTransformer transformer = new XmlTransformer();
Person person = transformer.transform(inputFile);

This kind of transformation code can easily be embedded into a Java project. There are several advantages, when using the Groovy method:

• Just one step for transformation including conversions.
• Easy debugging, when using an IDE like IntelliJ IDEA.
• Java-like syntax, no learning of XSLT required.
• Easy code-structuring. The transformation can use all features of a dynamic object-oriented language.
• Simple unit-testing. If you split the code into several methods, you can test each logical unit using established frameworks like JUnit or TestNG.

So what is your opinion? What are your current methods of transforming XML to POJOs?

The Problem

XMind is a very nice mind mapping software. It is platform independent and it’s free. I started using it at work on a Windows PC. When I installed it on my Mac I had a bad surprise. When starting it, it stopped immediately with a message that the JVM terminated.

Xmind is based on Eclipse RCP. Eclipse itself is using the Carbon framework on the Mac for it’s GUI. But Carbon is not supported on 64 Bit. But Java 1.6 on the Mac does only work on 64 Bit. So it will of course not work.

The Solution

You don’t need to uninstall Java 6 in order to run XMind. It turned out the solution was much simpler. You have to tell the XMind app what JVM to use. To do this use your favorite text editor and open the following file (I recommend VI ):

/Applications/XMind.app/Contents/Info.plist


Look for the following text and uncomment the -vm option:

<!-- to use a specific Java version (instead of the platform's default) uncomment
         the following options:-->
<string>-vm</string>
<string>/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java</string>

Make sure it points to the right JVM. I had to change it to 1.5.0 as it did only point to Current, which was 1.6.

Save, start XMind again and have fun creating Your mindmaps.

Jurgen Appelo of noop.nl had a nice post of the books he was reading recently called “My Book Slide“. He is reading a lot. I found some of the books were the same I was reading lately. So here is My Book Slide:

Sep. 2008

Robert C. Martin: Clean Code *****

Not much to say about this book except You have to read it. It is already a classic.

Oct. 2008

Neal Ford: The Productive Programmer ***

Nice book about all those little habits that make a difference in ones productivity. My favorite quote is: “There are people running their computers and others that are just walking them.”

Nov. 2008

Dan Roam: The Back of the Napkin **

Small book about explaining things visually. Dan Roam explains some easy to remember methods on how to find the right picture. For whatever reason I was expecting more of this book than it delivered.

Dec. 2008

Tom DeMarco: Adrenaline Junkies and Template Zombies ****

Great read. Nice little patterns of what are good or bad behaviours in projects. Each pattern is really short, only 2-3 pages. So it’s an ideal book to read in small breaks. The only drawback is that they are trying to follow the “Pattern-Trend”.

Nicholas Carr: The Big Switch **

Nicholas explains the analogy between utilization of electricity in the early twentieth century and the current situation in our industry. Some nice ideas, but most of it not as new or revolutionary as the cover promisses.

Roman Pichler: Scrum ****

The bestselling german book on scrum. Explains scrum very well and has also some good ideas on how to scale scrum.

Jan. 2009

Andy Hunt: Pragmatic Thinking and Learning – Refactor Your Wetware *****

This is my book of the year so far. It explains a lot around how we think and how we learn. It shows ways to improve this for everybody in a language that software developers can easily understand. But the best thing in the book is the Dreyfus-model. It explained some phenomenons I was wondering about for a long time.

Rothman, Derby: Behind Closed Doors ****

They are using the concept of story telling to explain important techniques of management. I found a lot of tips for my work. The book is just a bit short, not even 200 pages.

Currently reading

Pete McBreen: Software Craftsmanship

I like the concept of software developers being craftsmen since the I first read about it was in The Pragmatic Programmer of Hunt and Thomas. So I am curious, what this book will say about it.

Hello World is often the starting point for new experiences in software development. So I decided to keep this first WordPress headline. I welcome everybody on my blog, even if probably nobody is going to read this entry for the next 6 months I still think there has to be a starting post.

This is my first Blog. I am thinking about blogging since years, but never really found it important enough to start. What has changed now? Some good friends of mine started or restarted blogging a few weeks ago and I decided to use this energy and start my own blog too. Please do also visit their Blogs. They are mentioned in my Blogroll.

What will you be able to read about here?

Well, first of all everything related to my passion software development. This includes:

• Java/Groovy related tips or just random experiences
• Stuff about software development infrastructure
• Thoughts on software development methodologies (related to agile and scrum, as I am a Scrummaster)

You will of course also find some gadget stuff that I stumbled upon, and yes this will probably include some praise for Apple.

I hope you will be entertained or even get some value out of what I am writing here.

Yours sincerely

Joerg