Second sprint experiences of the Coding Dojo Helper

The motto of the second sprint was "Visual Studio Integration". On Microsofts website about VS-extensions, there are a lot of resources about extending the IDE. Unfortunately, after navigating around a bit, you quickly land on the boring msdn library pages. As I haven't found any nice tutorials on the web either, I had to find it out by myself: after downloading the SDK, there are new templates in the new project window under the Extensibility-folder. One of them is named "WPF Toolbox Control" and that sounded nice to me and so I took it ;)

Visual Studio Integration

Outline of a WPF Toolbox Control project

When you compile the project, you get a simple, empty dockable toolbox window inside of Visual Studio, like the properties-window but without the properties :)
The main classes of the project are the CodingDojoHelperVSExtension*.*-files, which specify the embedding of the extension into Visual Studio and MyToolWindow.cs, which is your entry-point in modifying the toolbox.
As I'm using Prism, my constructor (which is the complete code for MyToolWindow btw) looks like this:

[Guid(AGloballyUniqueIdentifier)]
public class MyToolWindow : ToolWindowPane
{
    public MyToolWindow() :
        base(null)
    {
        this.Caption = Resources.ToolWindowTitle;
        this.BitmapResourceID = 301;
        this.BitmapIndex = 1;
 
        var bootstrapper = new CodingDojoHelper.Bootstrapper();
        bootstrapper.Run();
 
        var shell = bootstrapper.Shell;
        shell.Background = new SolidColorBrush(Colors.Black);
 
        base.Content = shell;
    }
}

In my solution, I now have three projects:

• CodingDojoHelper, which has all the logic and UI in it.
• CodingDojoHelperDesktop, which references CodingDojoHelper and just provides the main window.
• CodingDojoHelperVsExtension, which references CodingDojoHelper and just provides the IDE-integration.

I just need minor tweaks to adapt it to the 2 scenarios (like shell.Background = new SolidColorBrush(Colors.Black); instead of an transparent background for the desktop-version). This is really nice and I haven't thought that the integration would be so easy. However, I had two problems to solve:

Digest view with the new amCharts

1. Every VS-extension must be compiled with a strong key. This means, every depending library also must have a strong key. It leads to the point, that I even need the strong key of Rhino Mocks, because I'm using the [assembly: InternalsVisibleTo]-attribute to be able to mock internal classes for unit-testing. Fortunately, Rhino Mocks provides a key callable via Rhino.Mocks.RhinoMocks.StrongName.
2. I had to switch from WPF Toolkit to amCharts for this reason: the WPF Toolkit is not a published product and therefore, it hasn't got a strong name :( However, I like amCharts more by now :) I don't need to do much designing so that it looks good ^^

New features

Start-screen

What else is new in this sprint?

• Start-screen: I've made a start-screen where you can select the target-duration of the TDD-cycles. When the time is up, you'll hear a nasty sound bite like "You weak pathetic fool" from the original Mortal Kombat game! So beware and keep your tests small and do make baby-steps to receive a saying like "Well done" from Shao Khan himself!
• Beautified: You also have the possibility to set the total duration of the dojo and the number of combatants, that is developers. But these two items are just to show off yet, because they will gain meaning in the next sprint. I downloaded gif-animations of the fighters from an internet-resource and used a special class to make them move inside WPF - looks cool 8-) The other cool thing is a storyboard using an ElasticEase that makes the two buttons for modifying the times (which is indeed a styled scrollbar) swing into their new place. At first, I looked in Blend for the easing functions for WPF in vain. But then, I opened a Silverlight-project, build the storyboard there and copied the XAML into my WPF-project. Feels awkward, but works.



Config-screen

• Config-Screen: This screen is also new to the Coding Dojo Helper and it was easily integrated with the help of Prism. Unfortunately, I haven't looked into Prism V4 and the new navigation possibilities - but this is another user story for me in the coming sprint(s).
• Styling: I've done the same (styling with a Silverlight-project and copying the result into a WPF-project) with a Checkbox. That was needed, because the WPF-Checkbox is precompiled and therefore not decomposable into atomic WPF elements like Ellipse etc.
• Gif-Editing: I edited my first gif-image inside of Gimp. The finish him-writing wasn't part of the image. So I opened the gif in Gimp, added 6 frames to it with the text and saved it back. It's as simple as that!
• Adorner: It is now possible to select the keys used to switch a developer and to end the session. I grab the AdornmentLayer, make it 25% transparent and prompt the user to push the new key for it. Luckily, I had to make the same Adorner-job at work last month. So this was a no-brainer ^^

The Coding Dojo Helper is now fully functional and we use it at work in our weekly coding dojo sessions. When I finished my third sprint, it should be ready for release :D

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 :)

Prism is witchery

For my newest project, I wanted to use Prism to guide us writing a decoupled WPF-application. I started investigating it and was quickly amazed about the module-approach. In our former WinForms-project, we didn't used a framework to guide us building a nice architecture, but developed our own clsForms-class (at that time even with hungarian notation *awkward*) and used even IPC to communicate across process-boundaries.

I began writing the framework for the new project with heavy guidance of Prism (RegionManager, EventAggregator, DelegateCommands and CommandBehaviors). In the end, we had some modules building a master-detail view with database-access. This was the time when other coworkers started to complain that the architecture is way too complex for such a small application as it is today. We started to discuss how to simplify it and at the end we had a draw in our opinions: some people wanted to keep everything (me included *g*) and some wanted to strip it down to remove Prism, to abolish dependency injection and the IoC container Unity. Our boss had to decide it and spoke to us: "thou shalt remove Prism but keep DI for a better TDD").

The top-3 reasons why Prism is evil for us* are:
(*) i.e. not for me

3) Using the app.config for setting up the modules is error-prone and not type-safe.
I told them that we could do it in code also but somehow I got not heared :/

2) Debugging is too hard.
When you get an exception in a view which will be inserted into a region, you got this Prism-Exception telling you that there was a problem resolving this module for that region. I learned here that you cannot expect everyone to look at inner-exceptions (admittedly mostly at level >5)...

1) Top reason why Prism is evil: it is too intransparent how the regions get filled (witchery *hooo*).
What can I say? For sure, you have to look at the good documentation at their homepage to get the hang of it. Else it's witchery, yes.

So we burned it and removed it from our solution with 10+ modules and about 10,000 loc. We needed 5 hours to remove the lightweight Prism-sections completely and substitute it with our own RegionManager-approach (which is basically the same) and with our own DelegateCommand-approach (wich is basically the same) and without the help for commanding of Prism (we now use code-behind to execute the commands). Ah yes, and we copied the EventAggregator out of the Prism-sourcecode and use it now, because our approach would be basically the same...

Everyone feels better now that the evil is being distroyed.

What was the problem? We're using a whole bunch of new technologies and paradigms in this project (WPF is new to us, as Entity framework, WCF, Prism, TestDrivenDevelopment and dependency injection). This means a lot to learn and sooner or later, your retentiveness is exhausted. This meant to sacrifice a pawn, in this case it was Prism.

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 ^^

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:

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.

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

MSDN magazine and Unity

οἶδα οὐκ εἰδώς, oída ouk eidós!

Thank you wikipedia for helping me with my greek. In the last few weeks, I learned so much while considering this and that for the new architecture; my programming-knowledge seems to duplicate with every line I read. Was I completely dazzled all the time?

Well, I'm reading the MSDN magazine now (in fact, I'm trying to manage to read a tiny part of it) to keep me up to date at least with the MS-world. By the way, in the february-issue, there is a great article about MVVM by Josh Smith.

One cool new think I learned is IoC of famous Martin Fowler. So I looked at Unity, a relatively new dependency injection container. Imho a great way for spreading logging and parts of our MCC_Aufzeichnung. Works fine with MVVM as Jason Dolinger demonstrates. This video was kind of an eye-opener in the matter of WPF for me.

WPF too slow?

I'm just looking for a new VSE (= Visual-Control-Element)-design. Using DirectX will propably be overdone but WPF is too slow in a first approach showing 10 signals with 1000 line-segments per Polyline. The overhead is truely too big. So I googled a bit and found a comment of Marco Zhou (Zhou Yong) who proposes using a WriteableBitmap for WPF-GDI-access. Unfortunately, this throws away all the cool stuff of an UIElement, but who needs databinding a static signal anyway?

Using the aforementioned technique, my sample runs at least as smooth as SOMNOlab :)

Now let's try to put some UIElement-biosignal-events atop of it and the weekend is near ^^

SOA again, 2 new blogs to read

On wednesday, I had to return SOA und Webservices in der Praxis of Herbert Burbiel to the bib. Unfortunately, there was a reservation on this book. Anyway, I wouldn't have the time to test this promising ASP.NET-world. I'm really astonished how easy it is to write a webservice or -client with .NET - not a great difference to a normal windows forms application. So, the book is great; however, it uses examples of .NET and Java and makes every step (write a client, write a service, make a db-connection) twice, if not thrice (Java, C# and VB.NET). Actually that showed me that the .NET-way is the right one for me ;)

On my journeys in the web, I recently found two great blogs about WPF (Windows Forms - someone needs that anymore?), or better say two great minds writing about WPF: John Gossman and Josh Smith. See Karl Shifflett (not John Gossman...) talking about MVVM here - I love that guy :) (more to come about MVVM soon!).

What Great .NET Developers Ought To Know

Recently I browsed a bit in Scott Hanselman's Computer Zen and found a blog-entry reading What Great .NET Developers Ought To Know. I think this is a fine place to start knowing what you don't know (yet).

Also look at BabySmash! by Scott Hanselman - a great introduction to WPF and the way to it.