Norman Kerth – the author of “Project Retrospectives: A Handbook for Team Reviews” – formulated the following prime directive for retrospectives:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

This is true for team retrospectives. But it is true for your personal retrospective as well. I did adapt this directive a little bit for my personal retrospective. You can and should adapt it, too. A personal retrospective is your personal thing.

However, you should keep in mind, that a personal retrospective is not about blaming yourself, just like project or team retrospectives are not about blaming others.

This is hard, because we (or at least I) get easy in the mode of blaming ourselves. But by doing the retrospective, you need to accept that you cannot change the past. You will analyse it. And you will learn from it.

So let me make an example. Let’s say I failed an exam – how would I treat this in a personal retrospective?

• “Why did I fail the exam?”  - “Because I did not learn enough.”
• “Why didn’t I learn enough?” – “Because I was lazy.”
• “Why were I lazy?” – “Because I felt exhausted.”
• “Why were you exhausted?” – “Because before I was doing  XYZ.”
• (And so on ….)

The key here is to break the circle of blaming yourself. Especially when it comes to “I am to lazy” – which could be something other people might have said about you. Don’t fall into that trap! Nobody is harming himself and his goals on purpose.

As you can see, being positive about what you did does not mean you shy away from problems. You need to tackle problems. But to tackle them, you have to understand why the problem occured. You need to find the reason why you acted in some way. And than you can think about strategies, how to tackle the problems. Tackling might mean, to change things – or to stop expecting to much from yourself.

So, how do you make sure you really follow the prime directive in your retrospective?

The first step is to accept intellectually, that the this prime directive is the right strategy. You can do this by reading this article, as well as other resources on project and personal retrospectives.

If you have accepted it, the next step is to get it into your heart during the personal retrospective. I do this in two ways:

• By calling it into mind during the retrospective. I do it by reading the prime directive aloud before the retrospective to myself. Or I write it on a paper and keep it visible during the whole retrospective. You could use other means, like writing it down every retrospectives or anything which is appropriate for you.
• By experience you can convince yourself. If you practice the “the best you can” strategy as outlined in the example long enough, you may learn and therefore start to believe it. At least it worked for me. I found out, that  there is always a way to explain my actions afterwards – even if they seem strage at  the time.

This article is the part of my Personal Retrospectives Series. I was strongly influence by other people – look at the Further Material section to find out more.

The phases of a personal retrospective describe the different steps you can identify in virtually any retrospective. Everyones personal retrospective is unique – but these phases serve you as a framework, when planning your own retrospectives.

In terms of phases, there is really not much of a difference between project retrospectives and personal retrospectives. So I looked for phases in the literature – Norman Kerth names three phases: Start, Middle and End. These are a good starting point, however I think for the purpose of discussion it is better to use the stages Ester Derby and Dianne Larsen introduced.

For each phase you can select certain exercises or activities. These practices help people to recall and better understand what happened. They try to unearth hidden success stories and problems. You can find description of those exercises in

• Kerth NL. Project Retrospectives: A Handbook for Team Reviews (amazon)
• Derby E and Larsen D. Agile Retrospectives: Making Good Teams Great (amazon)
• The Agile Retrospectives Resources Wiki (link)

Now lets look into the five phases.

The goal of this phase is to create the atmosphere and mood for a retrospective. Stopping and thinking about yourself is not a normal activity. You have to get in the mood to take time to breath, to take time to think.

To get into this mood, I have for example a special music playlist I always play when I do my heartbeat retrospective. My brain is now, after some time, conditioned to switch into the reflection mode, if I hear the starting sound.

Another thing is, that I read an adapted form of the Retrospective Prime Directive to myself – aloud.

For the more extensive quarter retrospectives, I will move to a different table. Rather than working on my usual desk, I will position myself in the living room. This helps me, to recognize that I am not doing usual work – but reflection work.

In the Gather Data phase, you want to accumulate as much data about the retrospectives subject as you can get. The goal is, to gather objective information that help you, to check your experience with reality. You will remember things  better with these information.

The easiest way to gather data is with the information sources you already have:

• I look into my calendar what actually was plannend. I occasonally correct the old plan with what really happend and add important unplanned events into it afterwards.
• I have a task list, were I can check what were the task I completed in the retrospective time frame.
• I look at who I made contact with in the time frame.

In Generate Insights, you analyse the data to understand what it might tell you. You try to see patterns: What contributed to this success? Which action I did caused that breakdown?

In this phase, I use the data from calendar, task list and contact log. This data helps me to recall things – and see connections between the events. I use this, for example to write a few key-points for every day down during the heartbeat retrospectives.

On the timeline, I use colors to indicate how I felt about certain events. If you work with list, you can write down three things you ituitively associate whit each item. If you wan to have more ideas what you can do, you should really watch Aisley Nies’ presentation - she calls this phase “Distill the Learning”.

From the Insights you gained, now you need to pick what you want to do. But be aware, you should not do everything immediately. Make one or two steps forward – and start with the easy one, which will make biggest impact in the short term.

I have essentially three types of ToDos:

• Big goals, which are more like visions and ideas were I want to go. They are in the timescope of a year, a quarter and maybe sometimes a month.
• To achieve these goals, I attach SMART-Objective to them. This means a Specific objective, were you can Measure if you completed it. Therefore it has to be Achievable. To make sense, it has to be Relevant for achieving the goal and it has to be Time-boxed – which means 6 weeks maximum for me.
  I learned about those from Andy Hunts excellent Effective Thinking and Learning - were you can and should read more.
• Most of the time, a SMART-Objective has certain sub tasks. These will be concrete tasks in my task list – together with a concrete due date. Tasks which take longer to complete will also be put into the calendar at a heartbeat retrospective, to block enough time to execute them.

In the Closing the Retrospective phase, you want to move back into the normal work after the retrospective. You need to appreciate yourself (yes you can do it!) for your work and your retrospective. You should as well reflect on how the retrospective went and what you might chance next time.

I usually close the heartbeat retrospectives with a special closing song – this is the only song with vocals.

In quarter retrospectives I write a letter to myself, to summarize the retrospective. I will open the letter the next quarter retrospective. Moreover, I will make my favorite cocktail and will enjoy the insights and lessons learned in the retrospective time frame and the retrospective itself.

This article is the part of my Personal Retrospectives Series. I was strongly influence by other people – look at the Further Material section to find out more.

In this article, I will describe what a project retrospective is as well as what is similar to and different from a personal retrospective. Furthermore, I outline why to do a personal retrospective and tell a tiny bit about why I write about it.

A project retrospective is a ritual of taking time to think about and reflect on what happend in a project. For a retrospective, a project team takes a certain amount of time, to talk about what happened during the project.

In a retrospective you will talk with your team mates about your own thoughts on and experiences of the projects. In addition to that, you learn how your colleagues experienced the project.

So why should you do project retrospectives? Because you want to learn from the experience. But don’t you do this anyway?

Linda Rising always brings up the nice example of her friend, who has been married and divorced three times. Did this lady really learn from her experience?

If you want to learn from your experience you have to acknowledge it. You have to draw conclusions from on what you did, the steps you took and how they affected the team and the project. This is why you do retrospectives.

An important aspect to note is, that retrospectives are not about blaming anyone, including yourself. They are not an evaluation on what was good and what was bad.

Norman Kerth has formulated a Retrospective Prime Directive which should be the spirit of any retrospective:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

There are four key questions you try to answer in every retrospective:

1. What did we do well, that if we don’t discuss we might forget?

For this question, your team will look at your success stories. What was really good in the team or the project? Why were you successful? Could you use the similar means to be successful in the future?

2. What did we learn?

In this question, the team will look at the past from a more general point of view. What are the patterns you noticed as a team? What wisdom can you derive from the experience?

3. What should we do differently next time?

With this question you look at the aspects, that went bad. Why did it not go well? What can we change to do better next time?

4. What still puzzles us?

This question is more about the open topics in your team or project. It is worth noting those and making them transparent to everyone. What is worrying you? Are there circumstances, which make the work harder for the team which the team cannot control?

To answer this questions, there are a number of retrospective exercises which are practices derived from dysfunctional family therapies. I’ll refer to these exercises in later articles on personal retrospectives.

In essence, the personal retrospective is the same as the project retrospective. It is a retrospective where the team is just you. You think about your life on your own. You can optionally have a retrospective where your significant other or a good friend facilitates the retrospective. However, I always do the personal retrospective by myself.

Personal retrospectives are an active framework for self-review. What works for me, might or might not work for you. You have to create your unique and individual retrospectives.

The biggest difference between project retrospectives and personal ones is that there are no communications within a group. In project retrospectives the discussion takes place orally with the help of whiteboards and index cards. If you do a personal retrospective, it is in your head.

I always do the personal retrospective always on paper. I write down my thoughts by hand – on paper. I feel writing them down helps me to clarify my line of thoughts. Afterwards, I write summaries and important aspects into my private wiki. But I keep the paper.

Personal retrospectives are a tool for me, to asses my whole life. I reflect on my work, my tech hobbies, my non-tech hobbies, my relationship to all kinds of people and everything else.

A personal retrospective should not be about creating an ambitious ToDo list. For me, it is sometimes more important to notice, that I need some rest or I really want talk to somebody again. These important insights for my life would go unnoticed, if I were not doing personal retrospectives.

So, how often do I do a personal retrospective?

• I do a quarterly retrospective to reflect on the bigger items in my life. I then take four hours to think about myself. I want to notice what happened to me and my life for the last three month. In this time I check and massage the goals I have in my life as well as the means I use to achieve them. At the end, I  think about my retrospectives activities and restructure them.
• I do a heartbeat retrospective every week. I always hold the retrospective on the evening before the working week starts (usually Sunday). I have a paper template were I answer the questions I want to answer for this week. The questions are about what happened in the passed week and about what I plan to do next week.

So, why to do this personal retrospectives thing? Why do I spend four hours of life time to do it?

After having done it, I really feel that it would be too expensive not do it. There are so many details which would go unnoticed in my life, if I didn’t do personal retrospectives. I start to see patterns in my life which I think I would not see without taking the time to think. With retrospectives I see more clearly what happened to me and my life – and how I feel about it.

I use retrospectives to learn what happens to me and what I do affects my life. I use it to improve my working practice and my personal well being.

Doing personal retrospective helped me to gain a new level of self-awareness. Since I do retrospectives I learned a lot about my self, although this might as well be just an effect of getting older..

I never had an external facilitated project retrospective with my team. And I certainly never faciliated a project retrospective. So I’m really not an expert on retrospectives.

I write this blog series because I want to share my experience with personal retrospectives. I started doing personal retrospectives at the beginning of 2009. Since then, I have developed my unique framework over the course of more than two years.

So I will just write down, what I think is valuable to know.

You have to note that I did no formal research on this. I will report techniques which worked for me. I can by no means comment on how and if they will work for you. You will have to experiment with what works for you. I will of course be happy to hear what you think and would really like to hear, what works for you.

In the end, I strongly believe that it can almost never harm yourself if you think and reflect on yourself.

This post is the first part of my Personal Retrospectives Series. I was strongly influence by other people – look at the Further Material section to find out more.

The Java SE 8 release is planned for mid 2013 by Oracle.

Project Lambda as well as the JSR-335 wants to provide means for modelling of code as data in Java – in non-exact, colloquial words one could say it aims for functions as first-class objects in Java. To do so, Project lambda wants to provide the following four extensions to the Java language:

1. Lambda Expressions or Closures which allow the programmer to specify a piece of executable code  in an idomatic way. They can be stored in a variable, passed to a method as argument or used as return value of a method.
2. Expandend Target Typing to bind the Lambda Expressions to objects of a specific type (type inference). These types can be so-called Function Interfaces – Java interfaces with exactly one method.
3. Method and Constructor References to allow the programmer to use existing methods on objects to be bound to a a Function Interface.
4. Default or Virtual Extension Methods to add more methods to existing interfaces without breaking existing implementations  (especially in the collection library).

List students = // ...
students.filter(new FilerFunction(){
    @Override
    public boolean filter(Student s){
      return s.getEntryYear() == 2011;
    }
    })
  .map(new MapFunction<Student,Integer>(){
    @Override
    public Integer map(Student s){
      return s.getGrade();
    }
  })
  .reduce(new ReduceFunction<Integer>(){
    @Override
    public Integer reduce(Integer value1, Integer value2){
      Math.max(value1, value2);
    }
  });

In contrast the following code using the features on their way with Project Lambda:

List students = // ...
students.paralell()
  .filter(s -> s.getEntryYear() == 2011)
  .map(s -> s.getGrade())
  .reduce(Math::max);

The information about the current state from Specification Lead and OpenJDK Project Lead Brian Goetz can be found at State of the Lambda.

In Project Jigsaw, the OpenJDK community lead by Oracle tries to introduce modularity into Java the language. The approach will be different from e.g. OSGi, because they want to establish it on the language level – with static compile time checking. The Oracle people always say they strive for compatibility of Jigsaw with OSGi.

Marc Reinhold, Oracles Chief Platform Architect and OpenJDK Project Lead, describes three principles of the modularity approach:

• Modularity is a language construct – The best way to support modular programming in a standard way in the Java platform is to extend the language itself to support modules. Developers already think about standard kinds of program components such as classes and interfaces in terms of the language; modules should be just another kind of program component.
• Module boundaries should be strongly enforced –  A class that is private to a module should be private in exactly the same way that a private field is private to a class. In other words, module boundaries should determine not just the visibility of classes and interfaces but also their accessibility. Without this guarantee it is impossible to construct modular systems capable of running untrusted code securely.
• Static, single-version module resolution is usually sufficient – Most applications do not need to add or remove modules dynamically at run time, nor do they need to use multiple versions of the same module simultaneously. The module system should be optimized for common scenarios but also support narrowly-scoped forms of dynamic multi-version resolution motivated by actual use cases such as, e.g., application servers, IDEs, and test harnesses.

For the programmer using Jigsaw, it will be especially noticable because the language will now have three phases (instead of two):

• Compile Time: The classes of a module are compiled. The compiled classes together with the resources (configuration files, metadata files etc.) are packed together in an archive in the format of JMOD (for java module):
• Install Time: On any computer having the JRE installed, there will be a module library. Here the user can install java modules.
• Run Time: A module defining a main class (Invokable Module) can be executed. The JVM will load this module and any module it requires from the module library and then execute the code.

Information about the the current state of Project Jigsaw from Marc Reinhold can be found at Project Jigsaw: The Big Picture — DRAFT 1.

The “Golden Eggs” have been written down from Joe’s slides – I hope without big mistakes. The comments are my summaries from his talk.

The full version of Joe’s talk will be available at Parleys soon.

This is a topic Joe has been talking about in a few Java Posse episodes already. And it is simple: By looking at the UI, you should not be able to see already the data structure. The UI should be solely tailored to be easy to perceive and understand by the user. Users don’t think in data structures typically – don’t make them.

With the former rule at hand, some of us engineers tend to go out, design a view and make the data structure look exactly the same. This it not how it is supposed to be. We have layers in all of our applications to abstract away the data structure, for example in the database, from the user interface. So we should do it. Design the data structure to be efficient and elegant for storing. Not like in the user interface.

You never ever should user HTML 5 because it is HTML 5. You should not use anything for the sake of technology.

Think about the user, think about their expectations. What user experience do you want to give them? This should lead your technology decisions.

When starting to design a UI, use a real use case. Not an abstract one, a generalized one. Use something the user will really do with the application. Use example interactions and data which are realistic.

Identify which kind of persons will use your apps. Split them into categories and give them a real name like ‘Ben’ or ‘Anna’. Give them a personality – this is called personas in a design process. Attach one persona to each use case you want to discuss.

As a side note: If you have two very different personas, think about the trade-off for creating two UIs compared to making one configurable. It is sometimes cheaper to create two UIs.

For the user experience it is important to think in application flows. Meaning the process of clicking through an “Login Process” with all state changes and transitions. Don’t think about a login screen.

Similar – if you design a design prototype, make it functional. The steps going through the design is as important as the look on the screen.

UI design is developed in prototypes. Create a prototype of your apps UI – and then throw it away. If you do not throw it away, it is not a prototype!

When you are inside a dialog of your application, the next step the user wants to do should always be very obvious. Make it never hard to find the login button, the next button or the create new user button if this is, what the user wants to do.

To understand this, you have to understand how our brain works, when it perceives a user interface. There are always three phases:

1. In the emotional phase, the brain recognizes colors, layouts and images on the screen. It sets the tone of the interaction with the UI.
2. In the parsing phase, the brain figures out the purpose of every element on the screen. It prepares the user for the task.
3. In the execute phase, the user starts to interact with the first element of the UI.

Our brain is a muscle. It can be trained. It reacts to common patterns. So make your UI consistent to use. Same things should always look the same. And they should align with the behavior the user expects from his operating system.

If you are inside the web, avoid complete page loads. Use the techniques offered by AJAX to load new elements or information in place. So the user does not have to re-parse all the elements because they are gone temporarily.

If your application changes the state, use simple transitions to make clear what is happening. For example, if you hide someting, fade it out so the user knows where to look if he wants to have it back.

The process of designing a UI is iterative. You have to make a lot of proposals and be ready to change your mind. Extend them. Add new designs. Combine them. Throw some ideas away and use others to iterate further.

I had – again – the luck to attend and it was an awesome experience. I’m really thankful that Stephan and his team is doing this works. We love you guys!

So – let me try to give you a very brief overview on what I found most interesting at Devoxx 2011.

As you might know, Java 7 has shipped this summer. I don’t describe the features in depth – but here are the most important ones:

• Project Coin  (JSR-334) which does some small changes to the language to make developers life easier (I wrote about this here and here already).
• The DaVinci Virtual Machine project aims to introduce some features for dynamic languages to the JVM. In Java 7 they introduced invokedynamic (JSR-292), which allows more performant dynamic method invocation.
• The Fork-Join framework (JSR-166) allows a command-and-conquer style execution of big tasks on multiple CPU cores.

Java 8 will be a revolutional release. On contrary, Java 7 was considered evolutional.

The are two revolutional features in Java 8:

• Project Lambda (JSR-335)
• Project Jigsaw (Marc Reinhold (@mreinhold) want to file a JSR soon)

Lambda will allow lambda expressions on the JVM. You can think of a lambda as a function, which stands on its own. A method without an explicit class context. These lambdas can be mapped to SAM-Types (Single-Abstract-Method) types and therefore be very useful for a lot of purposes.

Here is a syntax grap, which is subject to change (as always):

List<Students> students = // ...
students.paralell()
  .filter(s -> s.getEntryYear() == 2011)
  .map(s -> s.getGrade())
  .reduce(Math#max);

The feature will be coupled with virtual extension methods. A virtual extension method is a default implementations of interface methods. This default implementation will be used, if the implementing class does not provide one.

Project Jigsaw will introduce a modularity system for the core Java platform. I haven’t been to a Jigsaw talk this year, so I have no new knowlegde. Nevertheless, Jigsaw will allow you to group your classes into modules and make those modules depend on each other – just like the dependencies section in a maven POM. However, it will be checked by the compiler.

There will be a new file format jmod as well to replace jar files. This will allow you to use modules already installed on your systems, instead of having to package them everywhere.

Other features of Java 8 will be:

• Convergance of the Hotspot VM (former Sun’s VM) and the JRockit VM (Oracle’s own one)
• Type Annotation (JSR-308) to allow annotations in more places.
• A new Date/Time API (JSR-310) base on the joda-time efforts.

Java 8 will be release summer 2013. I bet it will at least have some release at 2013/08/08 . Oracle wants to stay with the two years release cycle. We’ll have to find out, if they can.

The features planned for Java SE are numerous – and still more in a planning phase. Nevertheless, they give you an idea what might come:

• Convergance of the Java SE and the Java ME platform
• Supporting to handle Big Data
• Reification of Generics to make generics more accesible via the reflection APIs
• Unification of primitives and objects in Java
• Having a common Meta-Data Object Protocol for all languages on the JVM.
• Tails Calls & Continuations
• Support for Multi-Tenancy
• Self-tuning VM which is able to inspect and improve its own parameters.

There have been two talks which I shamelessly will handle together, because in my opinion they had the same overall statement. The first one was “Courage in Software Development” by Dick Wall (@dickwall). The other one was “The Diablic Developer” by Martijn Verburg (@karianna). The latter one was acutally over-exagerated and ironic, so  beware I might have misinterpreted it.

Both were actually making the point, that you should not over-estimate the power of best practices. You should always strive for better coding – but this does not mean reading best practices from a book. Most important, you need to try out the things yourself. Try out new things, improve your practice.

Dick was talking a lot about taking risk in software development (and mountain biking). He thinks, that risks as well as failure are part of life, part of learning and part of getting better. So we should do it. Well, I agree on this.

Both stessed the need, to think yourself. “Don’t trust the giant” – said Martijn. This means, don’t unreflectively repeat the heros of our industry. Think about what they say. Think about why they say it. Think about what is there agenda.

Actually I think both talks were pretty good.

This was a Talk from Joe Nuxoll (@joeracer) – trying to teach engineers like us how designers thinks. According to him, the most important thing is to communicate. And for this communcation, designs and engineers have to understand each others language. So …

One common misunderstanding is, that design is about “make things pretty”. But this is acutally the last step. Design is a process. It starts with the idea of a product and it continues through several stages very closely analysing what the different user types (personas) need. The bullet points for this are:

1. Concept
2. Information Architecture & Interaction Design
3. Visual Desing / Interaction Polish
4. Production Plan

You have to understand, that this process is highly iterative and comparative. Designer iterate a lot and make a lot of different drafts and prototypes for there design work. They are also highly interested to critique each others work.

One of the most importants skills of a designer is to listen to the potential users – especially listen between the lines.

After this introduction Joe gave a few golden eggs for UI design. Maybe I’ll blog about them some time later (if asked ).

It was announced in the wednesday keynote, that the Devoxx will be branching out. April, 18th till 20th 2012 a second Devoxx will take place in France, Paris (see http://devoxx.fr/display/FR12/Accueil). The talks will be 25 percent in English, the rest will be in French.

The original Devoxx will of course stay as it is: In Antwerp Belgium and in November.

Other things shortly noted

• The whole Devoxx talks as well as some talks from JavaOne this year will be on Parleys http://www.parleys.com/
• Oracle stopped funding the work in Swing. So Swing is effectively dead.
• There we loads of talk about HTML5 – and they were very well attended. Feels like it is on top of the Hype now.
• There is a “Adopt a JSR” Programm from the London Java User Group to envolve the community in the Java Community Process: http://java.net/projects/ljc-london-jug/pages/AdoptAJSRProgram
• The Technial Discussion Panel with Emmanuel Bernard, Brian H. Prince, Mark Reinhold, Brian Goetz, Joshua Bloch and Ben Evans has been great. You should watch it on parleys.

Especially GIT, which has been developed by the linux kernel developers has some momentum. Furthermore it has a very nice integration into SVN, so that you can use GIT as an interface to a remote subversion repository. In this post, I will show a little bit how I currently use GIT to interface with different branches of the blueprint and training project.

Subversion is a central source control management systems. This means, that there is only one repository where you commit your changesets to. In contrast, on your local machine, you just have a working copy of that repository. Meaning you have the files from a particular branch in a particular revision on your local machine.

In a distributed version control system, everyone has a complete repository. So you have all the code, in all branches and all revisions on your local computer. To share code, you can now syncronize with other repositories over the internet/intranet, but as well locally or via a usb drive.

You can find a more extensive explaination with really nice graphics here.

This sounds very nice. But why should I use it? I will give you some reasons why I use it currently.

To give you some background: I currently work in a department, which supports other developers working with an company internal framework. So we have a project, which is called PetClinic. This PetClinic is used, in different states, as QA project, as training project, as experiment project and as blueprint project.

In the PetClinic we are trying out the latest features from our framework. As we try those on the development versions of the framework, we naturally run into bugs and might therefore break somethings – which would hinder my collegues work, if I check it into subversion, before the bugs I report get fixed.

For this, GIT enables me to create a private branch. This branch and all the commits to it only lives on my machine. When the bugs are fixed, I can check in everything – but still have a nice history.

Merging in SVN is a pain. Especially when you look at our situation. We have a branch for the current snapshot blueprint, a branch ‘exercises’ where we have the final solutions of all exercises  and finally a branch ‘starter’ which is the base project for our training where the training starts from.

These branches require to be synchronized often, with a very fine grained, selective level. It is very often the case, that I want to merge a few revisions from ‘exercises’ back to ‘starter’. This happens as well, when in training I discover something I want to have in ‘exercise’ and/or in ‘starter’ for the next training. Or if some new feature from the blueprint branch needs to be ported to one of the training branches.

GIT helps me here with a sophisticated merging mechanism. Furthermore I can use git cherry-pick to select one specific changeset I want to have in a branch.

Especially for Training, I want, that all my commits are complete and make sense. So someone who looks into my history, should have a step by step description what I did.

Unfortunatly I don’t get everything right the first time. So I often discover after one or two commits, that one line has been missing in a commit or one particular change should belong to another commit.

GIT gives me the opportunity to do so using git rebase.

When working with SVN, you always need a network connection to your SVN server to commit your changes. So typically when in the airplane above the atlantic, you code and make a monster commit.

Furthermore, when you have a network connection, on every commit you wait a few seconds (or more) before the commit is through with the central server. This takes alot of time, I you are not in the company and maybe on a slow VPN connection.

In GIT you commit locally. Against your machine. No network connection required. Only if you synchronize with the external repository – calling push and pull in GIT terminology – you need a connection to this repository. But in this step, you could synchronize hundred nice, small changesets. And you can do it, after your done – while watching TV or brushing your teeth.

GIT has been done by the linux kernel developers. So it has been made for linux. And it has been made for the command-line. On linux, you can easily install the git-core package via the package manager.

On windows, I would recommend using cygwin and install GIT via its package manager – I use it every day and it just works fine. I have installed the packages git, git-svn, gitk and git-gui.

You can install GIT on Windows. There is a TortoiseGit on the internet. I have no idea how the quality is now, but one or two years ago I had some problems using it.

For this blog, I’ll show you the stuff on the command line, as real developers use the command-line ;-)

So, first lets setup a petclinic project connected to our trunk blueprint:

$ mkdir petclinic # create an empty directory
$ cd petclinic # switch to the new directory
$ git svn init http://someserver/svnrepos/common \
    -Ttrunk/blueprints/petclinic \
    -bbranches/QA/*/petclinic \
    -ttags/blueprints/petclinic

This will lead to the following message

Initialized empty git repository in /tmp/petclinic/.git/

This initializes the repository with telling the GIT-SVN tool, where it can find trunk (which is essentially just a branch for GIT), where it can find the other branches and where it can find the tags.

The star * in the branches tells GIT, that at this place it should take the folder name as name of the branch. So the folder name branches/QA/2.11.1.x/petclinic will be the branch 2.11.1.x for GIT. For the tags it automatically assumes the name at the end, because I didn’t specify anything different.

The GIT repository has now been created. It is located in the .git folder. Your working copy is in the normal file system once you selected a current branch.

Ok, now we can fetch the data:

$ git svn fetch

This will now fetch the whole history of all the branches in the PetClinic. So take some time. On larger histories it can take a whole night or more. So be aware – but it has only to be done once.

In SVN you have properties svn:ignore on folders, to tell the version control system which files it should not consider when commiting to the repository. In GIT there are configuration files called .gitignore in the root of your repository which define which files to be ignored.

For example this .gitignore file excludes .project files and the target folder:

.project
target/*

But I do not want to check this file into want to check in this file into version control – it might confuse the SVN users. There is another option: .git/info/exclude. This file works just the same – but is local to your repository.

I can generate the .git/info/exclude file from the svn:ignore information with the following command:

$ git svn show-ignore >> .git/info/exclude

So first of all, I want to see how the different tags and branches behave. A nice point to check this is GITK:

$ gitk --all

This will show something like this:

Ok. After I know, what I have in my repository I want do do some work. I want to try out the some new featuer in a local branch. So I create a new branch based on the current trunk:

$ git checkout -b new_experiment svn/trunk

So, what does this mean?

• git checkout means, that git should “open” the a branch
• -b mean, it should create the branch first.
• view_compiler_experiment is the name of this new branch
• svn/trunk means the new branch should be based on the trunk branch, from the remote repository called trunk

So now, I’m in this branch – and I made some changes to some files. Now I want to commit them.

In GIT I have a very fine-grained control over what I want to commit. First I need to stage the changes I want to commit. I can do this by using git add path/to/file. In contrast to SVN, I need to do this on all changes – not only on the files which are actually new.

Then commit my changes locally by doing:

$ git commit

I could as well do

$ git commit -a

This would automatically stage all changes in files under version control (so this is like the SVN behaviour).

So now I have a bunch of commits and want to push them up to SVN. But first I want to get any changesets from SVN. This is done by

git svn rebase

This will fetch the changesets one by one from the SVN an try to merge them with your branch. In my experience, this does not raise so many merge conflicts as usual – and if it does, they are smaller.

Then I am ready to push my changes into the SVN

$ git svn dcommit

GIT and GIT-SVN have a ton of features. I only use a fraction of them – and from those I only showed a even smaller fractions. There is a Cheatsheet on the GIT page only for GIT-SVN. An the internet is full of other tutorials.

I would really encourage you to use it. Just use the comments, if you need any help with it. I might write a sequel in future.

So, let’s dive into the topic:

Sometimes in Java, you face the problem that a certain set of method calls may throw more than one checked exceptions. This is especially true, if you are working with reflections.

You often want to do the same thing with those exceptions. You might, for example, box them into a RuntimeException because you and your caller methods will not be able to do anything, if the method toString() on the String class is suddenly missing.

The problem might be, that the only common parent of all those checked exceptions is java.lang.Exception. But you cannot really use java.lang.Exception in a catch block, because you are garanteed to catch exceptions you don’t want to catch as well. One of those examples might be the famous java.lang.NullPointerException.

So you have to dublicate your code. This might look like this:

try {
  callWithReflection(arg);
} catch (NoSuchMethodException e) {
  throw new RuntimeException(e);
} catch (IllegalAccessException e) {
  throw new RuntimeException(e);
} catch (InvocationTargetException e) {
  throw new RuntimeException(e);
} catch (ClassNotFoundException e) {
  throw new RuntimeException(e);
} catch (IOException e) {
  throw new RuntimeException(e);
}

JDK 7 will improve the situation for the specific case of reflections, by offering a common parent for all reflection related operations: ReflectiveOperationException. So the following code looks a little better – but we still have two catch blocks, so we are dublicating our code still:

try {
  callWithReflection(arg);
} catch (ReflectiveOperationException e) {
  throw new RuntimeException(e);
} catch (IOException e) {
  throw new RuntimeException(e);
}

This is were multi-catch comes to help. You will be allowed to catch any type of exception – you just have to declare the parameter in the catch block final and seperate the types by a pipe |.

try {
  callWithReflection(arg);
} catch (final ReflectiveOperationException | IOException e) {
  throw new RuntimeException(e);
}

In the exception logic, you can still use only methods on which are available on the first common parent of all the exception types you specified. But if you need more specific methods, you better want to use different catch blocks anyway.

The next features is related. Because you declare the method parameter final, the compiler knows, which checked exceptions might occur in a catch block. So if you are catching IOException and ReflectiveOperationException with a final parameter and rethrow them, you only need to declare those two on the method. So it can look like this:

public void call() throws ReflectiveOperationException, IOException {
    try {
      callWithReflection(arg);
    } catch (final Exception e) {
      logger.trace("Exception in reflection", e);
      throw e;
    }
}

You can – and should – of course combine multi-catch and final rethrow.

There is a second place were exception handling can be nasty: If you have a resource, which needs to be closed. It becomes especially unhealthy if you have more than one resource to close.

Here I want to read the data from a database. The example is the same I used in the first post as an example for the diamond operator. We  have a table, were we have a patient, a medication date and a medication description.

For this we need the following resources: a database connection, a jdbc statement and a jdbc result set. So let’s try the code with JDBC 4.1 (which is new in JDK 7 as well, by the way):

public void readData() {
  Connection conn = null;
  Statement statement = null;
  ResultSet resultSet = null;
  try {
    conn = DriverManager.getConnection(CONNECTION_STRING);
    statement = conn.createStatement();
    resultSet = statement.executeQuery("SELECT patient, medication_day, medication_desc FROM medications");
    while (resultSet.next()) {
      String patient = resultSet.getString("patient");
      LocalDate medication_day = LocalDate.fromDateFields(resultSet.getDate("medication_day"));
      String medication_desc = resultSet.getString("medication_desc");</p>
      System.out.println(String.format("'%s','%s','%s'", patient, medication_day, medication_desc));
    }
  } catch (SQLException ex) {
    logger.error("Error in Database", ex);
  } finally {
    try {
      resultSet.close();
      statement.close();
      conn.close();
    } catch (SQLException ex) {
      logger.error("Error in Database", ex);
    }
  }
}

The problem is, that this code does not account for all possible error which might occur. Here are some of those:

• connection could not be opened (NullPointerException line 22)
• statement could not be opened (NullPointerException line 22)
• sql exception when creating the result set (NullPointer Exception in line 22)
• exception in one of the close statements (unclosed exceptions)

So I did an – probably not perfectly correct – attempt to do a more sophisticated error handling:

finally {
  try {
    if (resultSet != null) {
      resultSet.close();
    }
  } catch (SQLException ex) {
    logger.error("Error in Database", ex);
  } finally {
    try {
      if (statement != null) {
        statement.close();
      }</p>
    } catch (SQLException ex) {
      logger.error("Error in Database", ex);
    } finally {
      try {
       if (conn != null) {
         conn.close();
       }
     } catch (SQLException ex) {
      logger.error("Error in Database", ex);
    }
  }
}

This is a lot of code. And the problem with it is: It might even be still wrong. You can do exceptions handling with resources correct, but  you cannot do innovation. It is a stultifying work.

And stultifying work can be done by compilers! So – with Project Coin – the compiler can do the work for you.

You have to allocate you resources inside of parentheses after the try statement. Then the compiler will care for the resources.

This made my example so easy that I could add another resource (using NIO.2 which is also new with JDK 7) to write the data into a CSV file.

try (Connection conn = DriverManager.getConnection(CONNECTION_STRING);
        Statement statement = conn.createStatement();
        ResultSet resultSet = statement.executeQuery("SELECT patient, medication_day, medication_desc FROM medications");
        BufferedWriter output = Files.newBufferedWriter(target, Charset.forName("utf-8"))) {
  while (resultSet.next()) {
    String patient = resultSet.getString("patient");
    LocalDate medication_day = LocalDate.fromDateFields(resultSet.getDate("medication_day"));
    String medication_desc = resultSet.getString("medication_desc");</p>
    output.write(String.format("'%s','%s','%s'\n", patient, medication_day, medication_desc));</p>
  }
} catch (SQLException ex) {
  logger.error("Error in Database", ex);
} catch (IOException ex) {
  logger.error("Error in File Writing", ex);
}

You still need to handle the exception with the try-with-resources concept. You can either rethrow or catch them – but the system will care to close the resources you have.

One thing, which requires mentioning, is that in a try-with-resources statement it might happen, that more than one exception occur in the handling of closes. You can find those exceptions as “supressed” in the new method on Throwable getSuppressed().

Project Coin is a project about “small language changes”. Those are changes, mostly inside the compiler, that do improve the productivity of the developers but are small of scope.

The changes by Coin are very easy to grasp if you see them in code, so I’ll demonstrate them to you here.

You can test all the Coin features (as you can test all JDK 7 features) with the developer preview build available from OpenJDK. For Coin you need to use Netbeans 7 Beta, because Coin brings a few syntax changes. Netbeans even shows you, where you could use the new Coin features instead of old style and helps you with the conversion:

With Java you could always specify integer values (int or long) using the decimal notation, the octal notation (starting with 0) or the hexadecimal notation (starting 0x). For binaries you could use the Integer.parseInt(…) method. In JDK7 you will be able to specify such values in binary notation as well, if you start your declaration with an 0b. The definition of the decimal number 153 in all four representation can be found below:

int dec = 153;
int hex = 0x99;
int oct = 0231;
int bin = 0b10011001;

Assert.assertEquals(dec, hex);
Assert.assertEquals(hex, oct);
Assert.assertEquals(oct, bin);
Assert.assertEquals(bin, dec);

Besides this, you can now insert an underscore _ into an inger literal. You can use this, to make the literal more readable. The compiler will just ignore it. It  will look like this:

private long salary = 15_500_000_000L;
private int bitmask = 0b1010_1011;

In Java you have a switch satement available to check for the value of a variable and do several different thing in consequence. One of the thing you might do is, to perform an action for “yes”, “no”, “cancel” or “yes to all” according to the input of a user. You can determine what to do, by giving the user the possibilty to enter a char Y,N,C or A according to their wishes. This char can be used in a switch-case statement like this:

public void perfom(char userInput) {
  userInput = Character.toUpperCase(userInput);
  switch (userInput) {
    case 'Y':
      performYes();
      break;
    case 'N':
      performNo();
      break;
    case 'C':
      performCancel();
      break;
    case 'A':
      performYesToAll();
      break;
    default:
       throw new IllegalArgumentException();
  }
}

If you now want to add a new method “no to all”, you have a problem because there is no obivous char mapping. So you might want to use strings as user input instead. Unfortunalty, if you are using Java 6 or below, you cannot use switch-case with strings. So you have to use if-else statements, which some people consider to be a bit boilerplate:

public void perfom(String userInput) {
  userInput = userInput.toLowerCase(Locale.US);
  if (userInput.equals("YES")) {
    performYes();
  } else if (userInput.equals("NO")) {
    performNo();
  } else if (userInput.equals("CANCEL")) {
    performCancel();
  } else if (userInput.equals("YES TO ALL")) {
    performYesToAll();
  } else if (userInput.equals("NO TO ALL")) {
    performNoToAll();
  } else {
    throw new IllegalArgumentException();
  }
}

With Java 7 you can use switch for strings as well. So the code now can look like this:

public void perfom(String userInput) {
  userInput = userInput.toLowerCase(Locale.US);
  switch (userInput) {
    case "YES":
      performYes();
      break;
    case "NO":
      performNo();
      break;
    case "CANCEL":
       performCancel();
       break;
    case "YES TO ALL":
       performYesToAll();
       break;
    case "NO TO ALL":
      performNoToAll();
      break;
    default:
      throw new IllegalArgumentException();
  }
}

I studied medical informatics – so I give you an example from the medical domain. You want to have a data structure, were you can find the medications of the patients groupped by the date they received their medication. For this you could come up with something like this:

Map>> medications = new HashMap>>();

What you can see is, that there is a very lengthy generic type declaration. But what is more: you have to repeat it. You have to write it inside the Map<…> of the type declation and inside the HashMap<…> of the intialization. You should not specify anything different in the initialization, because it breaks you program.

So why writing it? The good new is: You don’t neet to anymore. You can use the diamond syntax.

Map>> medications = new HashMap<>();

These  two angle brackes <> look like a diamond – that’s why it is called diamond syntax. They tell the compiler to copy the generic type from the declaration to the initialization. That’s all

To know, what this warning really is about, you have to understand what heap pollution means. As did not know this before, so I’ll explain it. If you already know, you can skip all the text and code until the last two code blocks. In Java, Arrays and generic types do not go well together. If you want to create an Array of objects which can be typed generically, you can define the generic type on declaration. But you cannot use it in initiazation:

List[] matrix = new List[23];

This can lead to something called Heap Pollution, when you assign an object with an “illegal” generic type to that array. If you try to access the object from the array as the type-signature tells you, you can face a ClassCastException, where you never though you would cast anything.

List[] matrix = new List[23];
List[] nonGenericMatrix = matrix;
// No exception
nonGenericMatrix[0] = Arrays.asList("String1", "String1");
// java.lang.Integer cannot be cast to java.lang.String
List vectorList = matrix[0];

This behaviour is contradictory to the behaviour of a array, without generic types. Here you would receive an ArrayStoreException, when you try to assign an illegally typed object to the array.

Integer[] vector = new Integer[3];
Object[] vectorObjects = vector;
// java.lang.ArrayStoreException
vectorObjects[0] = "String";

Heap Pollution becomes really tricky, when it comes to var-args were you pass an object with a generic type. Var-args will be treated by the virtual machine as arrays, so the problem is essentially the same.

What makes it more difficult, is that you might not have implemented the method you call yourself. You call the method and maybe store the result. And then, 10 years later you are using values from the array you once stored and …

public static  L[] createHeapPollution(L... args) {
  Object[] elements = args;
  elements[0] = Arrays.asList(12, 12);

 return args;
}

public static void main(String... args) {
  List[] polluted = createHeapPollution(Arrays.asList("a", "b", "c"));
  // java.lang.Integer cannot be cast to java.lang.String
  String element = polluted[0].get(0);
}

This was the reason, that in Java 6 you got the compiler warning “[unchecked] unchecked generic array creation of type java.util.ArrayList<java.lang.String>[] for varargs parameter” on the method call which used generic typed objects and var-args. This warning confused users of APIs, while the authors of those APIs got no warnings. To avoid this, a new compiler warning “[unchecked] Possible heap pollution from parameterized vararg type L” has been introduced, so the author of the library will get notified about the problem. He also can use the @SafeVars annotation, to promise that his method will not generate heap pollution. In this case the warning will dissapear on the side of the implementer and the caller of the method.

@SafeVarags
public static  L[] createHeapPollution(L... args) {
  return args;
}

public static void main(String... args) {
  List[] unpolluted = createNoHeapPollution(Arrays.asList("a", "b", "c"));
  String element = unpolluted[0].get(0);
}

There are two addtitional features Project Coin introduces. They will be described in the next post on the JDK 7 subject. Stay tuned …

The discussion panel

This was a discussion panel lead by Joe Nuxoll (with Dick Wall as keeper of the minutes) between Josh Bloch, Mark Reinhold, Antonio Goncalves, Stephen Colebourne, Jürgen Hoeller and Bill Venners. They did a fanominal job in covering up for James Goslings cancellation (get well soon James!).

They did discuss the Future of the JCP and expressed throughout the bord (in some sense) the need for an incompatible version of Java – maybe under a different name. Sadly we also found out, that Apache Harmony will not get the TCK – and the Oracle statement seems to be, that this decision is final.

The next big JVM language

This was a talk of Stephen Colebourne where he lined out the principles he thinks a next big JVM language should have. There are namely (hope  I don’t forget any):

• no checked exceptions
• no primitives and no arrays (but of course a collection with the name Array)
• static typing
• a better and easier approach to generic wild cards
• closures
• language support for null-handling (like the groovy ?. operator)
• function types and method handles to get rid of factories
• simpler reflections
• a java like {} syntax – but maybe no semicolons ‘;’
• modules
• resource management

He then when rapidly over disqualifiy Closure and Groovy as the next BIG JVM language (not as JVM language – don’t misqoute me or him like that). He spend a little more time rubbing up Scala and Fantom – Scala for having the ability to write Perl like code in it and beeing to complex, Fantom for not having generics at all.

He proposed to have a non-compatible Java instead to be the next big JVM language.

I think he has a point in all he says. I might ask however, if there really will be a “next big JVM language”. Do we really have to have a new major language? Or will we drift more in specific languages and write application in more than one language?

I would at least not take it for granted, that there will be a successor in terms of adoption to Java.

If there is, the consequence of a JavaNG – a non backwarts compatible Java – seems appealing to me. So anyway: Great Talk Stephen!

Java SE 7 (More than one talk)

Well – we all knew, that Oracle is going for Plan B. But it felt there were dedicated to bring it out next year – they named the date for general availability to be 2010/07/28. Hopefully this dedication will lead to a release at last!
It is supposed to be feature comple soon (2010712/16) and everyone is encouraged to try it out and use it at: http://download.java.net/jdk7/. The latest netbeans beta version already carries the Project Coin “small language changes” that make huge differrent to your productivity. You can check out the examples from http://blogs.sun.com/darcy/entry/project_coin_javaone_2010

Beyond Coin, the JDK 7 will hold the Fork-Join framework as well as the invokedynamic bytecode. So good times for my old buddies from my thesis: Fork-Join and beloved JRuby.

And by the way … we no have filed JSRs for Project Coin (JSR 334), Project Lambda (325), Java 7 (JSR 336) and Java 8 (JSR 337).

Java SE 8 (More than one talk)

So the two main features for the late 2012 planned JDK 8 are closures and modules

Closures. They will be in – the syntax seems to be debated the most – but the protagonist seemed to be tired of it. In fact they said, the wanted to talk about features. I personally was very glad, they god rid of a function type idea and just wanted to use SAM types (that is a class or interface with a “Single Abstract Method”) as a replacement type for a type-safe closure. This allows us to have libraries done with the intent for use in closures – but beeing used in pre Java 8 code as well. So we don’t have any “first-class” and “second-class” closure methods. As Brian Goetz did put it: “Forward-compatible”

Modules. Well – as partly Ruby guy I have to say: The want rubygems for Java. And they want it type-safe. Of course they want to split up the whole rt.jar (AWT, Swing, CORBA, java.io, NIO 1+2 … you get the picture). That is hard work I believe. So lets hope they get it done – it would help us alot.
While Mark Reinhold stated, they will aim for interoperability with Maven (in both directions), OSGi seems to be left aside. This does not bother me personally, but it seems to bother alot of other folks.

But all in all, Java SE 8 is something to really look forward to.

(Of course Project Coin will add some small improvements that make big differences as well again.)

Java Puzzlers

Josh Bloch and his brother William Pugh did six new buzzlers this time. I cannot recall them – so wait for them to be available on parleys.com (and make Stephan happy by buying a subscription). But I wrote down some of the morals, which I’ll happily share with you here:

• Don’t use the BigDecimal(double) constructor. By using a double you already lost precision. Use BigDecimal(String) instead. BigDecimal.valueOf(double) is better, but still not perfect.
• Don’t worsen your API to improve performance
• Avoid having regular expressions to have overlapping matchings for the same thing – otherwise you can have very easy denial-of-service attacks by very long strings.
• Don’t mix generics and var-args.
• Don’t ignore warnings (an old one … but you know … the generic warnigs are hard to understand, but sometimes important)
• When you construct an object with an raw-type (non-generic) constructor, which could have been generic, all generics are gone from this object. Even if they do not relate! (This was referenced as raw typed mode).

Reflection Madness

The title of this talk by Heinz Kabutz was very well choosen. The author of the Java Specialists’ Newsletter showed some things you though never possible. Everyone of those was already presented in a newletter before . The highlights from my point of view are:

• Change Strings in the constant pool
• Change values of integers in the constant pool of the Integer class (very nasty thing when you loop)
• Adding an enum at runtime or changing enum values
• Modify final fields
• Construct without constructor

The BOFs

I don’t want to name a BOF specificly – but if you are at devoxx go to them! Even if you are tired – they are so informative. How it goes: There are your heros in a room, and you can ask questions. Any question! Ok the ones about aquisition and law suites will not get answered … but the interesting technical ones. And even if you don’t have questions, you can just listen to them. Other people in the community always have great questions!

I think this is somewhat like an open spaces conference in “light”. I surely must go to one of these soon …

The JavaPosse Live

Ok … that one you cannot describe. You have to be there! Feel it. It is great.

The litte kangaroo

No – not a talk. We brought our mascott this year. It is a little kangoroo – well see your self: http://twitter.com/#!/search/%23daskleinekaenguru

Last but no least

Devoxx Team I love you! You do a phenomenal job! *hug*

def insertionSort(unsortedList : List[String]) = {
    val F = unsortedList.toArray
    for(i <- (2 until F.length)){
      val m = F(i)
      var j = i;
      while(j > 1 && !sorted){
        if (F(j-1) >= m) {
          F(j) = F(j-1)
          j -= 1
        }
      }
      F(j) = m
    }
    F.toList
 }

// Note:
// This algorithm has been transcribed from:
// Saake and Sattler. "Algorithmen und Datenstrukturen. Eine Einführung in Java".
// dpunkt.verlag Heidelberg, 2004. page 123f

So, the program iterates over the indexes of the elements from 2 to unsortedList.lenght (line 3). Then it grabs the element of the current index (line 4) and and checks that all elements bigger than the current one get moved one index higher (line 6-11). The it assigns the current element to the place the last element from has been moved from – and everything is sorted.
What I left out from the original algorithm from my source, is a break. This is not critical as the break is a green-cut, to save some performance. This is because scala doesn’t offer a break. This does not really look like scala code. It uses an Array, which is a mutable class – and it uses index based access to a large extend. So I thought about the algorithm and came up (after some trying) with this alternative implementation:

def insertionSort(source : List[String]) = {
  var sorted = List(source.head)
  var unsorted = source.tail
  while(unsorted.tail != Nil){
    val index = sorted.indexWhere( _ > unsorted.head)

    if(index < 0){
      sorted = sorted ::: List(unsorted.head)
    }
    else {
      sorted = sorted.take(index) ::: unsorted.head :: sorted.drop(index)
    }

    unsorted = unsorted.tail
  }
  sorted
}

So first of all, we now have two lists. One with the unsorted and one with the sorted elements. At first the program puts the head of the source list into the sorted list, the tail ends up in the unsorted list (lines 2 and 3). Then it does a while loop until the unsorted list is empty (Nil is an empty list in scala, line 4)- always putting its head into the sorted list and putting its tail in the unsorted list itself, so the unsorted list gets smaller every while-iteration.

The sorting happens based on index (as I understand it, this cannot be avoided in insertion sort, or do you have a solution?). First it finds the index of the first element smaller than the current one (line 5). Then the program creates a new sorted list (the lists are immutable, so we have to create one and assign it to the variable) – with the elements before at the top, the current element in the middle and the elements after at the end (line 11). If the current element is the biggest one (which would mean the index is -1), the element is put at the end (line 8).

So this is my approach. Do you have a better one? Or at least a different one?

svn log | ruby -e "puts STDIN.read.split(/\n/).select{|l| l =~ /^r\d+/}.map{|l| l.split('|')[1].strip}.uniq.sort"

Who has any guess why I did need this?

The ruby script basically automates the upgrade instructions from the DokuWiki main page. So the following actions are performed when executing the script:

1. Making a backup into /tmp/dokuwiki_backup_#{timestamp} of every installation.
2. Downloading the dokuwiki release (passed in as a parameter).
3. Extracting the files and copying everything to the installations (execept for the content of the /data directory).
4. Creating missing folders in the /data directory, making the owner www-data:www-data and chmodding them to 664.
5. Deleting files from a list of file from older revisions.

Within the script you need to specifiy this snipped for setting your DokuWiki installations:

# Definition of existing installation
INSTALLATIONS = [
  '/path/to/docu/wiki/installation1',
  '/path/to/docu/wiki/installation2'
].freeze

Then you can call for a new release as follows:

/path/to/script/upgrade_dokuwiki.rb http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2009-12-25c.tgz

If you want to improve the script, feel free to fork me on Gist.