Eclipse Banking Day

A couple of weeks back I attended Eclipse Banking Day in London. The day was devoted to talking about various Eclipse technologies with a focus on how these technologies can be applied to the financial sector.

My particular interest was in BIRT of which there were two talks. The first talk was about how BIRT was used at the Bank of East Asia. This talk was informative however, I was disappointed that BIRT was used in a simplistic way. My hope was find someone who used BIRT in an advanced way and who may have encountered the same problems I had.

Over lunch I was able to talk to other people who used BIRT in their organisation. It was interesting to find out that we faced the same problems with our BIRT implementation.

The other BIRT talk was presented by a representative from Actuate, the company which created BIRT. This talk gave an overview of BIRT functionality. While the talk covered a lot of the basics. The part which I found most interesting was the demonstration of how to create a custom data source. This is an area which I think we can improve in our use of BIRT. I was encouraged/inspired after the talk for a way to implement this.

The other highlights of the day were:
Eclipse 4.0: The Next Generation of Eclipse
Extensible Banking Platforms with Equinox/OSGi
Modeling Industry Data with Eclipse Modeling Project

Code Dojo VII: Return of the JTanks

In early December we held another Code Dojo. We wanted to build on the successes of the last dojo and to make a few small improvements and changes. It seems that staying away from randori style is much more liked by everyone, so we didn’t want to move too far away from a winning formula.

At our last dojo had the problem that most teams fell into a hacking mindset and did not concentrate too much on practicing good techniques. The flip side is that everyone had so much fun that it was hard to stop. This time around we wanted to keep that excitement, but make sure that the dojo gave us techniques that we could apply immediately in our day jobs to improve application features and code maintainability.

Since I had volunteered to organize this dojo, I thought that a good way to keep that excitement but make sure that there is still a significant amount of learning would be model the Code Dojo after real dojos that I am familiar with: kendo dojos. Kendo dojos offer an excellent model for how to handle code dojos. In code dojos we want people to practice working together in teams and improving skills. Kendo dojos offer almost exactly this model.

Practice at kendo dojos centers around pairs of practitioners: a receiver and an attacker. The receiver is not just passively receiving, however. They are there to keep an eye on what the attacker is doing. They provide an opening (appropriate to the skill of the attacker) and give feedback (through words or actions) to the attacker. After the attacker has practiced a few times, the receiver and attacker swap roles. Practice continues after both sides have performed both roles by having everyone rotate pairs. Throughout the practice the sensei will introduce different techniques and everyone will practice these techniques.

Kendo Rotation
Rotation in a Kendo Dojo
The upper-right person stays in place to break up the groups.

After practicing specific techniques, participants move on to sparring practice. During sparring, the pairs practice the techniques that they have been working on that day as well anything else that they feel they need to work on (maybe even just returning to practicing the absolute basics). Sparring is the chance to practice when you have an opponent that fights back.

To transfer this style to a coding dojo I had to make a few modifications. We wanted to build on the success of the JTanks framework at the previous dojo, practice some good techniques, and have fun. We came up with a list of changes to the JTanks framework that we wanted to have. Each one of these tasks got assigned to a workstation (not a person or a pair). Along with each task were two or three different design guidelines and code smells that the pair working on the task should pay attention to.

In addition to the specific guidelines and smells, everyone was also supposed to constantly pay attention to other practices: checking in often, practicing TDD, and keeping it “DRY, shy, and tell the other guy.”

The pairs of people were then spread to each workstation and started working on the task. At this point each pair was supposed to try to make progress on the tasks, but mainly practice identifying and fixing code smells (practice the techniques). After half an hour of working on the tasks the “left” pair rotated left by one workstation. The new pairs continued working for another half an hour. Then the “right” pair rotated to the right by one workstation.

Code Dojo Rotation
The “left” Rotation

Instead of getting right back to work with the new pairs we took a short break. Everyone seemed to be enjoying themselves and most of the people felt that they were making progress on the tasks. There was even a little competition and commiseration on the frequent checkin front.

After the break the pairs reformed (in the same pairs that they had just rotated to) and went back to work. During the last rotation the pairs were told to enter into full-speed sparring practice with the task.

Another half-hour later everyone was pried away from the computers. We reconvened in a meeting room, ate dinner, and discussed how it all went. Most of the tasks had made significant progress (some could even be considered done). Each person had gotten a chance to practice some new skills, learn some new concepts, and have some fun.

The format that we used for this dojo seemed to be very popular. So we will definitely be trying it again. We think we will call it a keiko dojo – though the style of training used in kendo doesn’t seem to have a formal name, this word for “practise” seems to describe it well.