Wow, has it really been another year since my last blog post?

I travelled up to Birmingham Science Park today and attended my first Open Space Coding Day, with the focus of the day being on Windows Azure. The format of the day was a new experience and completely different to what I have typically found at user-group sessions or a training course. The aim of the day is for everyone to learn from each other, rather than sitting through a rehearsed presentation of slides and demo code. Essentially, once the attendees have suggested, voted and scheduled a collection of topics for the day, they split up into groups who then collectively research that topic, or undertake a hands-on coding exercise together.

In all, there were around 40 attendees, and I think that with exception to a few, most of us were all Azure newbies. Microsoft was well represented, and in particular Eric Nelson and David Gristwood were available throughout the day to help out with the groups, and for answering everyone’s questions.

SQL Azure appeared to be the most popular topic, but for my part I wanted to remain more focused on the compute aspects of Azure. After deploying my first WebRole into the cloud (via the free service instances that were arranged for the attendees by Microsoft), I started developing a Distributed Grep solution made up of Worker Roles, WCF services and Queues. Obviously I hadn’t completed this by the end of the day – after all, I was there to learn, but I am planning on finishing this little pet-project, and I’ll hopefully contribute the code to the OpenSpaceCode Repository as soon as I can. In the meantime I’ll be frequently checking out the UK Azure Platform online-community (available on Ning) for future events, and to keep up to date with what others are learning and discovering and what they are building on the Azure platform.

Mocking Frameworks are becoming more prominent in our development activities as unit testing, and hopefully test driven development, become much more mainstream. Like most technical topics, the choice of Mocking Framework can lead to long debates. I’ve been involved in these debates myself, and a fairly recent Phil Haack post that compares Rhino Mocks to Moq sums up these typical discussions.

Like Phil (and I would suspect most other Developers), I too have only recently discovered Moq (pronounced “mock-you”), and I’ve started to favour it over Rhino Mocks. Expectations are much more easily set up, and playback is more implicit. This simply suits my style and I also like the use of lambda’s in setting up the expectations. Perhaps my style makes me a mockist.

I accidentally came across this blog post yesterday that discusses the use of explicit and implicit interface implementations in C#. I have to admit, although I’ve known about these two approaches of interface implementation, I’ve never really given them any serious thought. I normally implement interfaces implicitly:

public interface IFoo
{
   void Bar();
}

public class Foo : IFoo
{
   public void Bar()
   {
      // implementation
   }
}

The explicit version basically requires that you qualify the method in the implementing type (IFoo.Bar()), and remove the access modifier (since it must be public as in the interface itself). So far the only changes are in the syntax, therefore the differences must manifest themselves during compilation:

Given the explicit implementation of IFoo:

public class Foo : IFoo
{
   void IFoo.Bar()
   {
      // implementation
   }
}

you cannot directly invoke Bar() on a Foo object without first casting it to IFoo:

Foo f = new Foo();
f.Bar(); // causes a compilation error

Foo f = new Foo();
((IFoo)f).Bar(); // works fine

In my opinion (coming from a C++ background), this is counter-intuitive. Since the Bar() method is public I would like it to be callable without a cast. After all, there is nothing stopping me from performing the cast in order to call the method, so why does the compiler force you through the hoops?

Brad Adams has some interesting thoughts on explicit interface implementations and where they should be used. In brief, he recommends their usage for hiding implementation details (i.e., the interface is typically only used internally), therefore approximating a private interface implementation. As I already mentioned, you can still directly call the methods through a cast, but the methods are effectively hidden from public view. Given this, I would generally think of explicit interface implementation as an implementation pattern, and I feel safe continuing to implement interfaces implicitly.

One final thought: if you use explicit interface implementation on a value type (i.e., on a struct), there will be a boxing performance penalty when you call any of the implemented methods.

As Developers we have quickly learnt how important unit testing is. Moreover we have also learnt, sometimes through hard lessons, that to implement unit tests we need to design and build our code so that it is actually testable. In my mind, this is a benefit, since it forces us to think about the code we’re writing, and more often than not, a better design emerges from our efforts.

We all know that one of the biggest advantages of unit testing is that it affords us confidence when making future changes. We know we’re going to make them, so let’s help ourselves when we do. Unit testing is also an important ally when refactoring code (especially if you also practice continuous refactoring – like all good Developers should). A good example of what I mean by “design for test” came about with the release of ASP.NET MVC Preview 3.

Although based on a pattern which itself leads to increased testability (Model-View-Controller), prior to Preview 3 there were still some fiddly points that made testing controllers and their actions awkward. Actions were void which meant it was difficult to observe and test expectations about what the action did. With Preview 3 actions can now optionally return an ActionResult object, which is then executed later on in the rendering process by the MVC Framework. This refactoring increases the ability to unit test controllers and actions, and more importantly, it makes writing those tests easier since there is less of a requirement to mock. This is a good example of “design for test”.

It’s old news but most of us will know that C# 3.0 introduced a new keyword: var. This tiny keyword brings with it a great deal of power behind the scenes, most of which was intended for use with another C# 3.0 language feature, namely LINQ. Simply put, what var does is tell the compiler to infer the type being used rather than having it specified explicitly.

You can appreciate this benefit when working with LINQ, since the type being returned from a query may not be known in advance. Consider anonymous types for example, and their use with LINQ projection where you cannot explicitly determine the result type. With this scenario you have to utilize the var keyword:

string[] words = {"AA","BB", "Hello", "World", "CCC", "DDDD"};

var result = 
  from s in words 
  where s.Length >= 5
  select new { Word = s, Length = s.Length };

So, in the above example we’re returning instances of an anonymous type from a query that will contain two properties: Word, and Length. We have two options, either explicitly create a new type that defines those two properties, or use var. If we use a var declaration then we understand that those anonymously typed object instances can only be used locally. I have no problem at all with this use of var (since it is really what var was designed for). The same goes for anonymous types – they should only be used in the context of LINQ (unless they’re used for very localized purposes).

What about the following query instead?

string[] words = {"AA","BB", "Hello", "World", "CCC", "DDDD"};

var result = 
  from s in words 
  where s.Length >= 5
  select s;

To some this is acceptable, but to me it’s problematic. If we look at the line of code defining the query, we have no way of determining the type of the result variable other than to scan the lines of code above it (maybe you could call this human inference). Why would this be acceptable? Why would you want to have to scan code in order to determine a variable’s type?

Instead, I would use the following query and be explicit about the type (after all, it’s not anonymous):

IEnumerable<string> result = 
  from s in words 
  where s.Length >= 5
  select s;

Now it’s easy to see what the query is projecting (a collection of strings). It might be a few more characters to type, but it is much more readable by myself and my fellow Developers.

In short, I think that the over use of var can easily lead to unreadable code, and that as Developers, we owe it to ourselves to keep our code readable. One use of var outside the context of LINQ that I really like is shown below:

var hashtable = new Hashtable<int, List<MyClass>>();

You can still easily determine the type of the hashtable variable from the same line of code, and you’ve saved yourself from typing the type-name twice.

Another example of var laziness is shown below:

foreach (var word in words)
{
  word.??
}

Reliance on Intellisence is simply not an answer.

Since the early betas, and now with the final RTM release of Visual Studio 2008, developers have the opportunity to begin exploring some new language features. Perhaps the most talked about language feature is LINQ (Language INtegrated Query), that provides a ubiquitous way in which to query data sources right from within the language itself, whether it be memory resident objects, XML, or relational data. There is however, one new language feature that has not been publicized that much: Partial Methods.

By now, most developers will have encountered partial classes and seen their benefits. They provide a means by which code-generation can be easily implemented and managed. Authored code and generated code can exist side-by-side in separate files, and the compiler will perform the task of stitching everything together during compilation. The Form designer provides a good example of this separation in action. Thinking beyond the Form designer however, it is safe to assume that many of the motivations for partial classes was driven by Microsoft's Software Factory thinking. Code that is generated by a DSL for example, can be easily interwoven with code provided by the developer using the DSL. There is no longer the need to mark areas of a source-file as protected from the code-generator, as was often the case in the past. The value gained from partial classes is clear, but not immediately obvious for partial methods.

Partial methods are made up of a method-declaration using the partial keyword, and an optional method-body. The method can accept parameters, including parameters modified with the ref, this, or params keyword. Methods must also be private and must return void, and more significantly, they can only be declared within a partial class. The following example demonstrates a partial method declaration (in bold).
Read More...

When we think "design-pattern", we are typically referring to logical level design-patterns, such as those presented in the seminal books on design-patterns ([1], [2] for example). These logical-level patterns provide structural and behavioural solutions to common problems when developing object-oriented software. These patterns are considered logical because they are independent of the programming language - for example - you can apply the Composite or Decorator pattern in C++, C#, Java, Smalltalk, or any programming language that is object-oriented.

An implementation-pattern (or an idiom), is simply a pattern that exists at the physical level. Typically they will be specific to a particular programming language and may well take advantage of a construct or concept specific to that programming language. There are many well documented implementation-patterns that are used in C# for example:

How do you implement the IDisposable interface?
How do you declare and fire an Event?
Read More...