Coding dojo helper - Mortal Kombat Edition

A colleague of mine told us that really good developers could do a red-green-refactor-circle in about 90 seconds. This sounds quite fast, but I thought that maybe one day we could achieve that... To help getting a feeling for the time spend doing such a circle, I wrote a tool. This tool should take the time of each developer doing a round and calculate the average time of a complete timebox used for a kata, for instance.

Learned new tools :)

As a kata originally comes from martial arts, the tool got a touch of the famous video game Mortal Kombat ^^ For development, I used Blend, Gimp and Audacity to do the design and learned some new tricks. For example, one can draw an ellipse with Blend and select Object --> Path to convert it into an animation path. This path can be used in a storyboard to make a button go round another control for example:

The second thing I've learned is to capture keystrokes even if the window isn't active. This article of Stephen Toub has shown me how to do that. So, if the user presses the Scroll-Button, the stopwatch starts. If he has finished his work, he presses the Scroll-Button again and the next developer begins to code. At the end of the timebox, one presses the Pause-Button and the screen changes to show the average TDD-time and a chart listing all times:

Neat, he? This is also the first time I used a DCVS.

The first attempt was to use Git, GitHub and TortoiseGIT as mediator. But as I'm developing this on a company-laptop during my ride home, there were some difficulties accessing GitHub and I abandoned this quite fast (I do think there are ways to circumvent this, but I hadn't got the nerves to look for them any further). So I tried Mercurial, Kiln and TortoiseHg and it worked like a charm. If you want, you can fetch the sourcecode at codingdojo.kilnhg.com and have a try for yourself if you can master the red-green-refactor-mantra in under 90 seconds. On our first try, we set the alarm to a moderate 3-min-timeout, but did a 4:30 min in average *ouch*. Next time, we'll use a 4-min-timeout and are keen to beat that :)

Coding dojos

At work, we do weekly coding dojos since 2 1/2 months now - and it's great!

Every thursday at 11am we meet in front of a computer and start a 1h-timeboxed session. This session consists of 3 parts: discuss kata, code, retrospective.

Discuss kata

First, we decide which kata to start with. If we haven't finished the kata from the week before, we throw away the results and start again from scratch including finding a common interpretation of the requirements (e.g. does an account number consist of 3 or 4 lines). Throwing away the work you have already done is not painful at all. Actually, it is necessary to improve yourself. Seeing direct improvements (e.g. completing a part of the kata which was never touched the week before) is priceless!

This part should be as long as necessary but as short as possible. At the moment, we need more than 10 minutes before writing our first test. I think we can cut that into halves in the coming weeks.

Code

At the moment, we work on the Bank OCR-kata and haven't finished the first user story yet. Before this kata, we successfully finished the katas Prime Factors and Roman Numerals *proud*. We do the katas (as well as our actual real-code-pair-programming) in a flow-Randori system:
The first person to be on the keyboard creates the test-project and writes the first test. After that, we play a round of musical chairs and the next developer solves the test. When it's green, he has the chance to refactor the code using baby-steps. Having finished the refactoring, all he has to do now is to write the next test and initiate the next round of musical chairs (which doesn't necessarily needs music to play in the background).
I think doing this kind of system is perfect when you're 4-6 people. Are there more than that, you would probably more likely do the prepari system. But being 10+ developers, I would rather split the group into two halves than having one big group where not everyone can participate.

Retrospective
About 5 minutes before the deadline, we begin the retrospective and try to find out what was good or what can be better next time. Right now, we're far away from a fast TDD-circle: approximately 5 minutes lasts a red-green-refactor-mantra, which surely can be lowered to 2 minutes.

In my opinion, every company writing software should have a regular coding dojo in the calendar. It helps enormously to spread a common coding style. Everyone learns from everyone, be it new keyboard-shortcuts (- is my newest) or amazing tools like R# or Visual Studio Power Tools.

With coding dojos, it is easy to integrate new team members and guide them in learning TDD. All in all, I highly recommend that!

PDC 2009

It's PDC again! Yesterday, I watched the opening-keynote. They spoke about the cloud and the new Visual Studio and how they can interact. A database store, codename Dallas, was shown which tries to unite data from all over the world - surely nice to play around with.

About half the time, when talking about the cloud, they showed this list:

1970s: Mainframe

1980s: Client-Server

1990s: Web

2000s: SOA

2010+: Cloud

We're just working on to get to the 90s, great...

One new feature of VS2010 is intelliTrace, which is a history of the program running via the debugger. I hope we switch to VS2010 soon, because that sounds interesting.

Last year, a lot of sessions were recorded and put online. I hope they'll do it this year alike. Nevertheless, don't forget to watch the second keynote today (17:30 CET) at the website with Scott Guthrie.

--------------------------------------------------------------------

The second keynote was great! Silverlight 4 beta available now! With trusted mode!! File system access!!! *download*

Sketchflow

We're started a project and are now in gather-requirements-phase. I sketched some UI-views for my module and Alex said: great - can you scan them in so we can discuss them with Uwe from Hamburg?
I remembered that I've heard something about Sketchflow which is build into Expression Blend. Sketchflow is a rapid prototyping software which lets you design new UI-sketches very fast. So I surfed to Sketchflow overview and thought "well, I'll give it a try". So I downloaded Expression Blend 3 and a Starterkit with some neat videos. While installing, I watched the first one and was impressed what you can do with that piece of software: build your UI using predefined toolsets, add navigation to your sketched application and even gather feedback from various persons via a Sketchflow-player.
After 3 and a half hours of work, I sketched all paper-sketches into Sketchflow and showed it to Alex and Reinhard. Gosh, they were impressed. Here are two screenshots:

This will be the first screen after a import has finished. They suggested to delete the buttons and integrate the navigation into the colored labels.

This shows how easy it is to create a rich screen in just a few minutes. If you wish, you can even use real data imported into Expression Blend! And best of all: it makes a lot of fun ^^

Pair Programming

Puh, just finished a pair programming-session with Artem. This was hard work!
We started at about 14:00 and wanted to add some unittests for a class Artem wrote. I already reviewed his code, so I knew it quite good. By the way, one result of the review was "where are the unittests?" - so I maneuvered myself in this position. Anyway, good quality-code needs some sacrifices *heroic*
I took the keyboard and Artem the mouse... No, just kidding. He was sitting beside me keeping an eye on my cursor. So we began with the first function and let Visual Studio build a test-stub and an accessor (yes, I love that!) for us. We discussed what to test for this method and I began to write code for it - easy. Not long afterwards, we found the first inconsistency which wasn't visible in the review and in the productive code either. Fixed it and continued. This went on and on, one unittest after the other. We discussed the relevant parts of the code and enhanced a few places.
But as time goes by, I noticed how unconcentrated I was and that I made more and more typos. What a luck that we almost had all unittests we longed for. So we created the rest and finished that session. It was 16:00 and I was exhausted like never before when writing some code.
I must say, that this was hard, but it was worth for it. You can't get such a tight feedback-loop when doing reviews and you can't produce code just by discussing it in a normal meeting. So, pair programming is great but exhausting!

How to build a collection of Interfaces

Here’s the problem: we have some files and some devices which operate with signals. As a signal is one of our main objects, we want to return a collection of signals when opening a file or beginning a communication with a device:

But of course, we want to handle each signal the same, so a signal from an EDF-file should be from the same class as a signal from a device. We could define a signal-class in the Main-library like this:

But this constructs a circular reference. We could create a converter for each special signal and build a collection in the main-library of all signals:

Ouch – ugly. For every signal-type we need one converter. What happens when DeviceSignal changes? Hopefully, we update the corresponding DeviceSignalConverter... Here’s my solution:

We implement all interfaces a signal could be loaded / imported from in the main-signal-class and use generics to simulate a factory. A EDF-dll could have:

  public interface ISignal {
      int SamplesPerRecord { get; set; }
  }

  public class SignalReader where T : ISignal, new() {
      public override ICollection GetSignals() {
          List signals = new List();
          var signal = new T();
          signal.SamplesPerRecord = 3;
          signals.Add(signal);
          return signals;
      }
  }

The signal in the main-library implements that interface:

   public class Signal : ISignal {
       public int SamplesPerRecord { get; set; }
   }

We can now call the SignalReader and it returns us a collection of signals we can use:

   public ICollection GetSignals() {
       SignalReader reader = new SignalReader();
       return reader.GetSignals();
   }

We can implement further signal-readers just by implementing the necessary interfaces into the main-signal-class. In fact, for each reader we created from Signal inherited classes implementing the interface the reader defines. With that construct, we can work without circular references and get a collection of objects we can work with.

What a wonderful world

Recently I read a lot about the M-V-VM pattern and I wanted to try it out. So I started small with a WPF-application implementing a listview showing some events related to sleep medicine. I’ve created a simple model with a collection of various data. This model is the data-provider for a ViewModel which is databind to this view:

So far, so good; worked pretty easy. I then read something about the graphical ability of WPF, which should be very bad in displaying a lot of graphical objects. Again, I wrote a sleep-medical-application, but this time showing some random biosignals with events:

The problem here was the very long signal build of thousands of Polyline-segments. And indeed, this brought WPF to its knees. You can’t show some signals with the pure use of WPF-technology. I instead used GDI+ inside of a Canvas-element for the signal and the VirtualCanvas-technique for the events (read here about it). With that I managed to preserve databinding on the modifiable objects (the events): you can move them around and change their duration by dragging their border.

In a second step, I combined the model of the ListView with that of the biosignals and injected it into its ViewModel. Of course, every ViewModel is being unittested – what a wonderful world:

Thread-Threat

At work, I'm trying to get a software-feature faster by introducing multithreading. We import data from a device and convert it into our format. This is done sequentially at the moment, first importing, then converting. First tests have shown that we can get a benefit of about 30% if we do that in parallel. So I developed a wonderful producer-consumer-queue with a producer-thread and a consumer-thread which gets its data from the producer-thread. So far, so good: all unit-tests with that queue ran successfully.

However, as soon as I plugged that code into the import-conversion-piece to make it multithreaded, I got System.Runtime.InteropServices.COMExceptions with HRESULTs of -2147467259 (RPC_E_SERVERCALL_RETRYLATER, Unspecified error) or -2147417856 (RPC_E_SYS_CALL_FAILED, System call failed) - (here is a list with automation errors). These errors occured randomly on different parts of the code. But all code-parts had in common that they're calling a VB6-COM-object (well, it's a COMException - what should I expect...).

Some googling brought me similarities with Office-automation (see here and here for example). My picture about that problem became clearer and clearer and I sketched that diagram to understand it:

Thread A and B are accessing the same COM-object. This access is provided via a RCW (runtime callable wrapper). There is only one RCW for all accesses to that COM-object (read the great article series "Beyond (COM) Add Reference: Has Anyone Seen the Bridge?" of Sam Gentile for a deeper dive into COM-interop). This means multithreading and COM-interop is no fun.

What about protecting the access to that COM-interop with a lock? I designed a little construct so that I won't forget to protect any calls to that COM-interop:

The wrapper for the COM-interop, ThreadSafeComInterop, offers the COM-interop via a Lock-class. Each time you want to access the COM-object, you acquire the lock. With that, a Monitor enters the lock and exits it not until the lock is disposed. It's neat with the using-construct:

Using lock = _interop.Lock
' do something with lock.ComInterop
End Using

See that sequence-diagram for further information:

The provider creates the ThreadSafeComInterop by passing the COM-interop to the constructor. The recipient can call the Lock via the using-construct and access the COM-interop via lock.ComInterop. By creating the ThreadSafeComInteropLock, a Monitor.Enter is established on a static lock-object. When finished using the COM-object, the Lock is being disposed and Monitor.Exit is being called to allow other components to access the COM-object.

This sounds great and tests are showing that the exception-rate is degreasing from 10 tries - 9 exceptions to 10 tries - 1 exception. But unfortunately, this exception is one exception too much. Reading "Lessons Learned Automating Excel from .NET" finally convinced me to write the needed parts of the COM-component in .NET.

BendingStackPanel

I just finished a nice little tool for our Message-module: Message.dll for dummies.

On the right is a ListView with various components of which the trace-level can be altered. In the center of the dialog are 3 Buttons to vary the debug-mode. These buttons are on a StackPanel with a custom-made property "Bend" and overrides to Measure and Arrange. You can bend the StackPanel up to 180 degrees. Here is a picture with more buttons and an ellipse (any UIElement can be added):

The slider and the TextBlock binds to the BendingStackPanels Bend-property so that you can interactively bend and unbend the panel - looks really cool :) I was amazed how straightforward the development was: it took me just a few hours! Here is the envelope of ideas - nice, eh? ;)

The whole bending-stuff is just class-10 (yes, I looked it up...) sine- and cosine-trigonometry. You can have a look at the code here.

LoC and FxCop

I was curious on how many lines of codes we are working. There were only nebulous guesses of around 100.000 locs – but no official ones. So I googled a bit and found CLOC, a counting tool for lines of code. I ran it on my ActiveX- and DotNet-folder and it calculated:

·         80,000 loc VB.NET and 40,000 lines of comments in VB.NET

·         410,000 loc VB6 and 310,000 lines of comments in VB6

·         20,000 loc C++ and 5,000 lines of comments in C++

The good number of comments in VB6 might result of the huge header we gave each file and a rather big header for each method. In VB.NET this is more dense.

 

Another tool on my way to a great developer is FxCop. This program can examine a dll if certain rules are broken. You can select and deselect single rules or whole rule-sections. The rules are made by Microsoft but you can build your own rules and add them. When you run the program, it lists all violation and you can either try to fix them or if you disagree, you can exclude them with a comment.

Moving to blogger

I decided to move this blog outside of the MCC-wiki. The content isn't MCC-specific (actually, I deleted the 'hot'-company-stuff) at all and I want to write something about my private projects too.

So, here it comes: after working a bit with WPF (approx 4 months) and trying ASP.NET (approx 1 month), I started a ASP.NET Silverlight project with the brand new Virtual Earth Silverlight Control. You can add UIElements to the map and give them coordinates so that they will move with the panning of the map. This means a way of possibilities:

'todo: upload Picture

The beginning

I'll try to produce a blog here about interesting stuff I found on the web. I write this in english because I hope that someone of multilingual-ISS will find an interesting link or idea here. Right now, PDC is over and many high-quality-content screencasts were being generated. Here is just one of them about the future directions for MS VB (10 especially): the underscore will finally go away!!! Also look at Channel 9 in general and stay informed.