Jorgen Austvik Jorgen Austvik's Weblog

Monday 2009-03-23 i held a presentation called Hudson: Introduction and Experiences at the Free Test 2009 conference.

The conference was very professionally arranged, despite this being the first year it was held. In addition to the presentations it was nice to meet some fellow testers from all over the world. See you all next year!

Sun uses to participate in itDagen at NTNU, and this year was no exception. We talked to the students about Sun, Java, Solaris, SunSPOT, Trondheim OpenSolaris User Group (TrOSUG), Memcached and MySQL, and served coffee from Sun cups.

For people that use to sit in front of a screen the whole day, it can be exhausting to stand up and meet people face to face for a whole day - as this picture of Trond, Jørgen and a huge SGI monster shows.

I am giving a presentation at the Free Test 2009 conference in Trondheim in March, and I am looking into visualizing or proving why continuous integration is such a good idea because of this.

These visualizations are based on three dimensions: line, time and person doing the change.  In the (horizontal) x-dimension you have time. In the (vertical) y-dimension you have line number. Imagine all lines in a SCM concatenated together e.g. like "find . -exec cat {} \+ | nl". A changed line would get a single line number with this transformation. With this visualization, each time a person saves what has been changed in her editor, there would be a vertical line (with possible holes) which shows the fingerprint of which lines in the complete SCM the person has changed per save. The last dimension - persons, I have tried to visualize with blue and red color. I appologise to the color-blind, but adding a z-dimension made it difficult to see overlaps, and using different line strokes also made it difficult to see.

I have two visualizations so far. The first came after a discussion with Terje Røsten, where we agreed that the rate of change per unit of time was constant, and that therefor the possible overlap of two persons changes are bigger the more seldom you integrate. This would translate to "there is more work involved to fix the merge".

In this figure, the blue and the red persons has both integrated a patch that touches some of the same lines.  When the patches are big the average overlap can be lines (a), and when the patches are small, the overlap must be few lines (b).

In the next figure I try to visualize the possibility of a collision to occur. In this figure I have painted one integration point (think commit, push and pull) - i1. At this point we have two conflicts - c1 and c2.

In the next figure I have the exact same sequence of changes from both programmers, but much more often integrations. Here there are no conflicts because they are resolved before they happen because of the integrations.

OK, so now I have some visualizations showing a couple of reasons why continuous integration is good for you, but I am still looking for a mathematical formula. I think it has to include something like this:

P(collision) = ((avg size of patches)/(total size of code in SCM)) * (number of committers) * (number of commits per integration)

The "problem" with this formula is that while you increase the number of integrations, you decrease the average size of each patch - so the P(collision) for each integration point decreases, but the number of integration points increase with the same factor - so the net result is the same.

Are there any mathematicians or statisticians out there that could shed some light?

Just before Christmas we had a Christmas party at Sun.

The just-about-to-break-through band "The Directless" had a stunning performance releasing their new hit single "Riga River", here are a couple of pictures:

Jan Ståle blogged the lyrics.

OpenGrok 0.7 has just been released!

I worked on the Git backend, and on improving the quality. Well, not only improving it - it seems like a fix to make it compile on Java 1.5 didn't really fix the problem. A real fix has been pushed now, but is not in 0.7.

(OpenSolaris only has Java 6, so it is difficult to test my changes on 1.5 - luckily Lubos has 1.5 running in a Hudson - I should check it more often).

Last autumn I worked on a secret project in Menlo Park for a couple of months, and now Sun has launched the project as Kenai.

Tim Bray have blogged an interview with Nick, with some information about what the project does.

I see they have had almost four thousand check-ins since I left, so lots have changed since I last saw it. It still looks good though - but I am missing project Kenai itself from its it's project list. It would be fun to work a little with the old gang to add OpenGrok support to it.

Speaking about fun and good colleagues; here is a picture showing frenetically coding:

This weekend I attended a mountain bike race in Norway, caller Birkebeinerrittet.

It is 91 km with some nice roads, some terrain and some places where you have to run through mud and stones. I finished in four hours and six minutes, which I am very pleased with after some technical problems and a salto mortale. Next year I'll go for 3:40.

Hmm, I really need to come up with a new naming scheme for my blog posts.

Knut Anders and Trond have been fixing FindBugs and CheckStyle warnings like crazy, and now there are just 3 FindBugs warnings and 22 CheckStyle warnings left. Clearly something had to be done!

Enter PMD: 

 [echo] PMD finished, found 1103 warnings.

If you want to run PMD on your OpenGrok, you can enable it like this:

  cd ~/.ant/lib

  unzip ~/Desktop/pmd-bin-4.2.2.zip

  ln -s pmd-4.2.2/ pmd

You also have to make links to the jar files:

  cd ~/.ant/lib/pmd/lib

  ln -s pmd-4.2.2.jar pmd.jar

  ln -s jaxen-1.1.1.jar jaxen.jar

To run PMD on the source code, just run ant pmd:

  ant pmd

See the OpenGrok README.txt for more details.

(And if Knut Anders and Trond fix those 1103 warnings I can always enable the optimizations ruleset to get 1815 more warnings )

I haven't had time to do much on OpenGrok lately (training for Birkebeinerrittet), but since I am evidently the only OpenGrok developer with some style (he, he) Trond has been nagging me about adding some ant rules for CheckStyle in our build system.

I added them, and Trond added the plugin to his Hudson, and after that Trond and Knut Anders has been fixing lots of the warnings, so it seems to be working fine.

If you want to be stylish too , this is how you run CheckStyle on the OpenGrok code:

First you must download the CheckStyle 5.0 Zip file, and unpack it:

   cd ~/.ant/lib

   unzip ~/Desktop/checkstyle-5.0-beta01.zip

   ln -s checkstyle-5.0-beta01 checkstyle

You also have to create symbolic links to the jar files:

   cd checkstyle

   ln -s checkstyle-5.0-beta01.jar checkstyle.jar

   ln -s checkstyle-all-5.0-beta01.jar checkstyle-all.jar

Now you are ready to check how stylish you are:

   ant checkstyle

Enjoy! 

I was having some problems compiling libpqxx head against PostgreSQL head on OpenSolaris with Sun Studio compilers (Sun CC bundled STL is missing iterator_traits and has a non-standard std::distance - looks like we are aware of the problems with the Rough Wave STL implementation). On the libpqxx homepage, I see that my colleague Bjørn Munch has integrated libpqxx in the PostgreSQL packages for OpenSolaris while I was on vacation. Cool!