Thursday, May 31, 2007

My advice to Jamie

It seems that Microsoft is not pleased with the fact that my favorite VS add-in offers support for the VS Express SKU. You can read all about it in this post from Jamie Cansdale, the creator TestDriven.NET. My advice to Jamie:

  1. Remove support for the express editions of Visual Studio. You can't win against their army of lawyers. Let the baby have its bottle. It is simply not worth the trouble. Maybe the guys at CodeGear or SharpDevelop are interested.
  2. When you are cleaning up your code, remove the support for MS Test as well. Let's face it, your add-in is used by some many developers. Play the game and stop supporting their crap too (I'm glad that even Martin Fowler shares my opinion about MS Test).
  3. Don't let this incident affect you and keep up the good work. 

Wednesday, May 30, 2007

You're not alone

It seems that Jimmy Nilsson also has a lot of trouble with ASP.NET. As you know (or might not know), I'm not enjoying my experiences with ASP.NET either. Enough with the ASP.NET bashing for now.

Let Composite Application Block bashing begin. No, just kidding. Actually it's too late for that one. There were several blog posts over the last couple of days, but the one that started it all was this post from Resharper-Jedi Oren Eini. There were several responses in favor and several against his point of view, most notably from Chris Holmes and Sam Gentile. If you're interested, you should do some Googling about it.

I think that the truth lies somewhere in between. Although I've never created a Windows application with CAB, I can certainly believe it's hard to grasp initially. Besides some blog posts and some "Hello World" examples, I couldn't find some concise explanatory documentation. As with every framework, there is a learning curve involved (heck, I'm still learning new things about NHibernate every day).

On the other hand, I strongly believe that the P&P team is doing a good job. They've created a framework for building Windows applications using patterns like IOC/DI, MVP, MVC etc. necessary to have a testable design. Could they've come up with a simpler solution? Sure they could. It doesn't matter to me (everyone knows that you should go along with the third release). What does matter is that they create awareness amongst developers that putting all your UI logic in the code-behind model is not the best thing since sliced bread. In order to create maintainable solutions, it's necessary to have a testable design that adheres to low coupling, high cohesion. I believe that Microsoft is doing a terrible job at the moment in encouraging developers to write maintainable software, except for the P&P team. They are the light at the end of the tunnel. Although their efforts are not perfect either, I hope that they can make a difference.

Monday, May 21, 2007

Resharper dude

Over the weekend I watched this screen cast from Oren Eini. You should have a look at it, even if you're completely not interested in mocking frameworks. The best commercial of Resharper I've ever seen!

Is Microsoft losing the Alpha Geeks?

The highly respected Scott Hanselman talks about his experiences at RailsConf in Portland. You can find his already legendary post here. I think its time to have a look at Ruby and especially Ruby on Rails. As a matter of fact, I ordered Beginning Ruby: From Novice to Professional last week just to get me started.

Sunday, May 20, 2007

It's Time for Violence

This is the title of the first smash hit single from Roy Osherove. You can download it here. Hopefully we see him soon on Top of the Pops.

Tuesday, May 15, 2007

NUnit vs Team System Unit Test

At work there's a discussion going on whether we will choose NUnit or Team System Unit Test for our unit tests. Currently we have about 1000+ unit tests written in NUnit and we are most pleased about it. The reason that this discussion has come up is a company-wide adoption of unit testing, something that we are all very happy about. 

In order to get a clear and objective view, I gathered all pros and cons for each of these unit test frameworks. Here goes ...

First I made a listing of all attributes:

NUnit attributes TS Unit Test attributes
[Category(“name”)] [AssemblyCleanup]
[Description(“description”)] [AssemblyInitialize]
[ExpectedException(“myException”)] [ClassCleanup]
[Explicit] [ClassInitialize]
[Ignore(“reason”)] [CssIteration("name")]
[Platform(“name”)] [TestProperty("name", "value")]
[Property(“name”, “value”)] [CssProjectStructure("name")]
[SetUp] [DataSource("name")]
[SetUpFixture] [DeploymentItem("path")]
[Suite] [Description("text")]
[TearDown] [ExpectedException("myExcepton")]
[Test] [HostType("type")]
[TestFixture] [Ignore]
[TextFixtureSetUp] [Owner("name")]
[TextFixtureTearDown] [Priority(1)]


and all assertions:

NUnit assertions TS Unit Test assertions
Assert.AreEqual Assert.AreEqual
Assert.AreNotEqual Assert.AreNotEqual
Assert.AreNotSame Assert.AreNotSame
Assert.AreSame Assert.AreSame
Assert.Contains Assert.Equals
Assert.Fail Assert.Fail
Assert.Greater Assert.Inconclusive
Assert.GreaterOrEqual Assert.IsFalse
Assert.Ignore Assert.IsInstanceOfType
Assert.IsAssignableFrom Assert.IsNotInstanceOfType
Assert.IsEmpty Assert.IsNotNull
Assert.IsFalse Assert.IsNull
Assert.IsInstanceOfType Assert.IsTrue


I have also made a listing of all pros and cons of both unit testing frameworks.

  • Its the de-facto standard for unit tests in .NET. 
  • Already exists for several years now and it's very stable.
  • New releases and new features on a regular basis.
  • It's very easy to extend and write your own assertions (constraint model).
  • Lots of features and assertions with support for collections and files.
  • Very good integration with all editions of Visual Studio thanks to the TestDriven.NET add-in.
  • It's open-source (yes, I see this as an advantage).
  • Has its own stand-alone test runner that can installed with a simple XCOPY deployment. 
  • It's available for both .NET 1.1, .NET 2.0 or higher.
  • Very easy to use with Selenium or WatiN
  • No out-of-the-box integration with Team Foundation Server.
Team System Unit Test
  • Out-of-the-box integration with Team Foundation Server.
  • Less users
  • Its not free and only available for the Team System editions of Visual Studio. There's also no stand-alone test runner available. When our project lead or our functional analysts like to run some integration tests, they have to install one of the Team System editions of Visual Studio in order to do so. 
  • It's has many bugs and is less stable than NUnit. One of these bugs has to do with the ExpectedException attribute. I've also experienced some unexpected behavior with Assert.AreEqual (tests that should fail but instead pass for some obscure reasons). I've also got some frequent crashes of test runs.  
  • Test runs are very slow. One of the most important characteristics of a good unit test is that it's fast.
  • Less features than other unit test frameworks like NUnit or MbUnit. Less assertions, no inheritance of test fixtures and no hierarchical organization of unit tests to name a few.
  • Only available for .NET 2.0 or higher.
  • Web testing of Team System simply sucks compared to Selenium and WatiN. It's possible to use the latter web testing frameworks in favor of the first one, but they are not well integrated.

I value the out-of-the-box integration of Team System Unit Test with TFS, but in order to sacrifice all the NUnit goodness, Microsoft has to do a better job for their unit test framework. Based on this list, information I found and my own experiences, I think NUnit is a no-brainer. I guess that after some Googling around and some tweaking, it's possible to integrate NUnit with TFS as well but I can't prove that right now (if you can help me with that, please send me an e-mail).

Therefore I would like to get your opinion on this matter. Some feedback is highly appreciated. You can also have a look at this post from Roy Osherove.

Sunday, May 13, 2007

Agile is just human nature

I just finished reading a book written by Phillip Khan-Panni, and its not about any of the latest cool technologies or methodologies, but about efficient communication between us human beings. It's about learning how to talk on lectures, presentations, meetings, etc. ...  without putting anyone to sleep (that's why I started reading this book). The book I read was translated in Dutch, so I don't know the original title of the book.

One of the exercises in the book is to have two people sitting with their backs against each other. One of the two people involved describes the following drawing to the other person as he tries to recreate the drawing according to the directions from the first person.

You can probably imagine that this gives you quite some funny variations of this drawing. The clue is that most people (including me) fail miserably in successfully completing this exercise and this for the following reasons:

  • we need human gestures.
  • we need to have eye contact.
  • we need interaction as we speak our language.

We needs these things in order to communicate properly from one person to another.

We need feedback to let us know how we are doing and lead us to adapt our communication in order to accomplish better results.

Sounds pretty agile to me, right? Being an agile developer is all about having all kinds of feedback:

  • feedback from our clients after each iteration so that we know we're on the right track. If not, we need to use this feedback to make the right adjustments.
  • feedback from our code thanks to continuous integration, daily builds and unit testing.
  • feedback from code coverage.
  • feedback from code metrics.
  • etc. ...

Therefore I say that agile development means to bring the process of  developing software back to our roots. This is why agile development feels like the right thing to do (for me it is).

The absence of eye contact forces us to completely rely on words. This brings us to the interpretation of those words.

This describes why the waterfall methodology fails miserably. Near the end of this sequential development process everything and everyone involved gets out of sync including the software itself because of a continuous lack of feedback. How we interpreted the input coming from our clients at the very beginning is something we need to show them as soon as possible. It's all about people communicating with each other. 

What I'm trying to explain here is that the traditional waterfall approach is a violation of human rights. Noticed that I used the word feedback eight times in this post (not including this sentence). We need a guy that jumps up on stage on agile conferences, jumping around like a monkey while screaming "feedback, feedback, feedback" ;-). What do you think? (and no, I'm not the chosen one)   

Thursday, May 10, 2007

Eric Evans on .NET Rocks

Just found out that Richard Campbell and Carl Franklin recorded a show with Eric Evans on Domain-Driven Design. Get it while it's hot.

Wednesday, May 09, 2007

Exploring WCF - The Close vs Abort confusion

In my journey to explore the Windows Communication Foundation, I came across an issue that confused me at first but actually made some sense after spending half a day figuring things out.

In order to understand to try out fault contracts in WCF, I created a service like the following:

[ServiceContract()] public interface IFaultService { [OperationContract] [FaultContract(typeof(InvalidOperationException))] String CalculateSomeStuff(); } [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] public class FaultService : IFaultService { public String CalculateSomeStuff() { throw new InvalidOperationException( "Invalid operation, dude."); } }

After generating a proxy with svcutil, I created a console application that calls the service:

try { using(FaultsServiceClient faultsServiceClient = new FaultsServiceClient()) { String result = faultsServiceClient.CalculateSomeStuff(); Console.WriteLine("Result: {0}", result); } } catch(FaultException<InvalidOperationException> ex) { Console.WriteLine("------------------------------"); Console.WriteLine("FaultException of type InvalidOperationException caught."); Console.WriteLine("------------------------------"); Console.WriteLine(ex.ToString()); Console.WriteLine("------------------------------"); } catch(Exception ex) { Console.WriteLine("------------------------------"); Console.WriteLine("Exception caught of type: {0}.", ex.GetType().Name); Console.WriteLine("------------------------------"); Console.WriteLine(ex.ToString()); Console.WriteLine("------------------------------"); }

I expected that the code inside the first catch handler, for FaultException <InvalidOperationException>, would be executed. Instead the second catch handler, for Exception, caught an exception of type
CommunicationObjectFaultedException. I couldn't figure out what was happening, so I did a search on the MSDN forums. The first post I found was this one. Somewhere in the middle there is a reply from Madhu Ponduru where he states the following:

using() should only be used for non-production applications (POC, etc). Production apps should use the try {…Close();} catch (CommunicationException) {Abort();} catch (TimeoutException) {Abort();} paradigm that is being used in the latest SDK samples.

He says that the Abort method should be called instead of the Close method when the proxy is in a faulted state. Bye, bye using statement. That made me feel a bit frustrated. If you read a book on WCF (I've read the excellent Programming WCF Services from cover to cover), you can't help noticing the use of a using statement in order to ensure that an instance of a proxy class gets cleaned up properly. Also, the following can be found on page 207 of Programming WCF Services:

By default, all service-thrown exceptions fault the channel so that even if the client catches that exception, it cannot issue subsequent calls because those yield a CommunicationObjectFaultedException. The client can only close the proxy.

It clearly states that it is possible to close the proxy after it went into the fault state. Searching through the MSDN library, I found the following in the documentation for the CommunicationState enumeration:

An object in the Faulted state is not closed and may be holding resources. The Abort method should be used to close an object that has faulted. If Close is called on an object in the Faulted state, a CommunicationObject-FaultedException is thrown because the object cannot be gracefully closed. 

When I looked at the Dispose method of the ClientBase<T> class in Reflector, I found out that it simply calls the Close method. Because this implies that the Dispose method can throw an exception, it means that proxy classes should not be instantiated inside a using statement. I found the following in FWDG regarding exceptions thrown from the Dispose method of the IDisposable interface:

Avoid throwing an exception from within Dispose(bool) except under critical situations where the containing process has been corrupted. Users expect that a call to Dispose would not raise an  exception.                   

Is closing a WCF client proxy a critical situation where the containing process has been corrupted? Get some dog food over here ;-). Some further Googling on this matter delivered this post on the MSDN forums that explains a lot. I'm not going to put the whole explanation in here, but you should definitely give it read in order to understand why they shipped it as is. Erwyn van der Meer also gives a great explanation and provides a solution to this problem in this great post. Kudos!

I strongly believe that the WCF team did a great job on the first version of the Windows Communcation Foundation. Regarding this matter, I think they made two mistakes. First, they should have communicated this a little bit better and second I think it would be best that they just got rid of the IDisposable interface for the ClientBase<T> class.

Oh well, too late for that now.

Monday, May 07, 2007

A Browser Tale

I'm a big fan of the Opera web browser for many years now. I like it because it's the underdog. They don't have the same market share as IE and Firefox, but I find it the most innovative browser around. An example of this is the fact that tabbed browsing is practically invented by the Opera guys and dolls many years ago. Today, they have the killer features that IE and Firefox will implement tomorrow. Yesterday as I was upgrading to Opera 9.2, I was pleasantly surprised by a new feature called Speed Dial. It does as it's name implies:


It's possible to easily configure up to nine of your favorite web sites. Then you can pick one of these web sites when you open a new tab. They can also be opened by means of a shortcut (e.g. CTRL-1 opens favorite web site number one in the active browser tab).

Besides Opera, I'm starting to appreciate Firefox and the way it makes me more productive when I'm doing web development. More specific, it's the add-ons that make the difference. Here is a list of the add-ons that I have currently installed:

I would love to hear wich add-ons for Firefox you have installed. 

Friday, May 04, 2007


After reading this post from David Laribee, I promptly put the four criteria to be an ALT.NET developer on our team portal.

1/ You’re the type of developer who uses what works while keeping an eye out for a better way.

2/ You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.

3/ You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.

4/ You know tools are great, but they only take you so far. It’s the principals and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principals (e.g. Resharper.)

Are you ALT.NET?