Always databind SelectedItem before ItemsSource

The order in which bindings are defined in Xaml are relevant. Look at this Example: I have a ComboBox and a ViewModel. The ItemsSource of the ComboBox is bound to the Repositories property and SelectedItem is bound to SelectedRepository.

<ComboBox ItemsSource="{Binding Repositories}"
          SelectedItem="{Binding SelectedRepository}" />

The constructor of the ViewModel initializes the Repositories with a non empty collection and sets the SelectedRepository to the first element.

public ViewModel()
{
    Repositories = new List<string> {"First", "Second", "Third"};
    SelectedRepository = Repositories[0];
}

Yet, immediately after starting, I got null reference exceptions from other databound properties that are referencing the SelectedRepository property! After a little debugging I found out that when assigning the ViewModel to the DataContext of the view, the Binding Engine assigns null to the SelectedRepository! If you change the declaration of Databinding everything works as expected:

<ComboBox SelectedItem="{SelectedRepository}"
          ItemsSource="Repositories" />

Conclusion: the order of databinding declaration matters!

Using Assembly.CodeBase to get the location if shadow copied

A long time I had problems with NUnit tests that needed to access files living relative to the tested dll. NUnit (and Resharper) are shadow copying a dll before running the test, so the Location property of an assembly returns the path to the shadow folder and not the original location where the expected file lives. My solution was to disable shadow copying in NUnit and Resharper. But every now and then I forgot to disable it in new projects. The result was spending time with debugging until I remembered to disable shadow copying.
But now I have found by chance a much better solution, which is more robust and also useful for other shadow copying scenarios like hosting WCF services in IIS. You can use the assemblies CodeBase property to get the original location. The only drawback is that the codebase is formatted as a Uri. It normally includes a file protocol “file:///”  and uses slashes ‘/’ instead of backslashes ‘\’, so you need to modify the returned string a bit:

var assembly = Assembly.GetExecutingAssembly();
var path = assembly.CodeBase.Replace("file:///", "").Replace("/", "\\");

I believe that in certain scenarios you may see other protocols (perhaps http://) but for unit testing scenarios that relieves from the pain of remembering to disable shadow copying.

Mercurial tutorial by Joel Spolsky

A really good mercurial tutorial (especially for those who are damaged by subversion) by Joel Spolsky:

 http://hginit.com/index.html.

Wissensvermittlung und ein Konfuzius Zitat

Ich habe gerade ein sehr passendes Zitat von Konfuzius gelesen (Papier, OBJEKTspektrum 03/2009) indem ich mich selbst wiedererkenne, wenn es um Wissensvermittlung geht:

“Erkläre es mir und ich werde es vergessen. Zeige es mir und ich werde mich erinnern. Lass es mich selber machen und ich werde es verstehen.”

Expression Blend 3 Design Time Attributes

Only a few people (including me until a few weeks ago) know that Expression Blend supports so called “Design Time Attributes”. These properties are very valuable to get “Design Time Data” into Blend. Without those example data designing DataTemplates is cumbersome and no fun. Those Design Time Attributes are not documented at all and I found out about them only by chance, reading some blogs. It seems that they are officially introduced with VS 2010 and documented there. Nevertheless they are fully functional with VS 2008 because they are ignored by the compiler and only used by design tools like blend.

All Design Time Attributes live in the d: namespace:

d:DesignHeight	In Blend, there is a special handle you can use to modify the d:DesignHeight and d:DesignWidth attributes without modifying the real Height attribute. This is handy if you just want to test some resizing logic.
d:DesignWidth
d:DataContext	Lets you specify the DataContext used at design time. Example: d:DataContext={StaticResource MyDataContextObject}, or even better    use d:DesignInstance
d:DesignInstance	d:DataContext="{d:DesignInstance Type=local:MyDataContext, IsDesignTimeCreatable=True}"
d:DesignData	needs VS2010, links to a sample data object defined in a xaml file
d:DesignSource	sets the Source property of a CollectionViewSource at design time

You are not thy user

I have just finished reading Dave S. Platt’s book “Why Software SUCKS”, and it was a lot of fun. I like his polemic and exaggerated way to make his point. And I strongly believe that at its heart he is absolutely right in his findings.

The believe of programmers, that the user of a program is like him, causes much if not all of the trouble with the usability of programs nowadays. “You are not your user” says Platt. And if a programmer thinks “If I design a user interface that I like, the users will love it.” Dave says “Wrong!”. This is not new knowledge, in Germany we know it as “Der Trugschluß der egozentrischen Intuition”, but no one before described it in such a catchy way.

But I don’t like the oversimplification that always the programmer is the bad guy. In my experience the same amount of damage to usability is done by every person in the development chain, that means QA people, project managers, sales people, directors and the people responsible for buying.

Think of Joe Programmer, who actually knows something about user interface design and has studied it for several years. He has seen the actual users in person and at work and knows the problem thy want to solve. He has designed a beautiful user interface and now his boss comes in, demanding a short review. “I don’t like that. My favorite GeekyApp does it like this, I like it and therefore it must be liked by the customer. Please change your software so that it does work like my beloved GeekyApp.” Ouch. Next comes the QA guy: “I need to test the performance of your app and I don’t like to manually create 1000th entries of test data, could you please add some batch generator to your UI, it would help me doing my job faster!” Argh, no user will ever do what you poor QA guy have to do. Now the sales people cry: “I need more colors and more animations. Otherwise I can’t sell it!” Sigh. Then the project manager declares: “I need a quick way to discover what is going on in the customers installation, please give me more analysis features.” Last but not least, even the people who are responsible for buying the software force him to cripple the user experience because the prefer to buy what they like and not what their users like. Poor users, no wonder why so many software sucks.

My tip for Joe Programmer: Not only the final user has needs, everyone in the chain has his own needs. You cannot ignore them but must find a way to satisfy them adequately. You can give QA an automation api without compromising the user interface. You can build a system diagnosis view, that the normal user never will see. You can argue with sales and your boss (point them to Platt’s book). Offer some “baffle” mode for presentations and to convince the buying agent. This is a lot of work but by reading “Why Software SUCKS” you have a chance to convince the other people that they are also not like your users. At least it helps to detect the trap before falling into it.

New NUnit syntax of how to expect exceptions

I have just stumbled upon a new beautiful syntax of how you can write a unit tests that expects that a method throws a certain exeception or an exception derived from it. First your test fixture needs to inherit from AssertionHelper which gives you the static Expect method. Then you can implement a test like this:

[Test]
public void GetExternals_InvalidWorkingCopy_ThrowsSvnException()
{
    // Arange
    var ep = new WorkingCopyCache();

    // Act & Assert            
    Expect(() => ep.Get(@"X:\Dummy"), Throws.InstanceOf<SvnException>());
}

To be honest this constraint based syntax exists for quite a while now, but I just didn’t know before. IMHO it is very powerful and readable, compared to other solutions. For more details about how NUnit evolved to finally arrived at this syntax see this blog http://nunit.com/blogs/?p=63.