timjroberts.com

Windows Azure Open Space Coding Day

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.

45+ new jQuery techniques for good user-experience

If you�re using jQuery and want to improve the user-experience on your website, then take some time over a coffee and read this article.

It outlines more than 45 jQuery based solutions to improving website user-experience, including iPod style drilldown menus, Facebook like dynamic input, context menus, pagination, and light-box techniques.

Sustaining capacity in maturing Agile teams

Scott Bellware has written some recent posts on how agile teams sustain capacity as they mature their process.

The posts can be found on his blog (permalinks and content abstracts below):

Sustaining Capacity in Maturing Agile Software Teams � Part 1: Nothing Fails Like Success

We all know that following an Agile process as it is prescribed will only take us so far, eventually we�ll have to make changes. When we do begin to make changes we need to understand why. The principal reason for changing elements of the process should be to remove constraints that limit the team�s performance. As the teams�s performance increases new constraints will appear that are proportionate to that performance. Without reaction to these appearing constraints, obstructions will occur causing the team to lose its ability to perform at the new levels of expectations. Scott refers to this as entropy.

Sustaining Capacity in Maturing Agile Software Teams � Part 2: Entropy

Talks about some of the natural constraints that come out of software development. For example, design rigidity, which is where a design hasn�t been optimized to easily support change.

Sustaining Capacity in Maturing Agile Software Teams � Part 3: Recognizing Entropy

How to identify entropy and when to act upon it. Acting too early might mean that the team hasn�t enough context to understand the source of the constraints. Quite often constraints appear in code, which is a core means of communication for an agile team.

Sustaining Capacity in Maturing Agile Software Teams � Part 4: Counter Measures

Identifies some of Scott�s counter measures in dealing with constraints. In short, the environment in which Developers work should foster a learning culture that directly supports continuous improvement. With this in place the team will learn to identify constraints, and then how to counter act them. There are also a few suggested technical practices such as writing Soluble Code, Test-Driven Development and Design Improvement.

Mock-you... this is how I mock!

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.

Explicit or implicit interface implementation

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.

Design for Test

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�.

�var�: a contentious little keyword

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>();

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.

Six months later...

Well it's been six months since I last posted an entry, so let me begin by reassuring my readership (all two of them), that I have not been hit by a bus or anything like that. Things have been really busy since I started in my current role, and I just haven't found the time to post any new entries. It's a shame too since my unique visitor count was growing steadily as I posted, but obviously those figures have now since dropped off. The lesson to learn from this is that if you plan to setup a blog - post to it!

So what has taken up all my time? Well, those who are connected via LinkedIn can see that I started a new role at Confused.com back in January. This has been a fantastic (but busy), opportunity from a development and technology perspective since I'm being exposed to the very latest Microsoft technologies, including the .NET 3.0/3.5 stack (including WCF and WF), and ASP.NET MVC (we're onto Preview 3 already). The most interesting aspect of my current role however, is my involvement with the adoption of Team System and Team Foundation Server.

Confused.com is adopting Scrum as an agile methodology, and we've all been involved in slowly introducing agile to the business. To support Scrum in Team System, I have developed an appropriate Process Template from the ground up. This was easily achieved using the Process Template Editor that is part of the Team System Power Toys. The principal reason for developing a custom Process Template, rather than using one of many free versions (such as Conchango's Scrum for Team System), is that we see integration opportunities with other processes and tools already being used within the organization. A custom Process Template will support these integration opportunities much more easily than trying to shoe-horn a third-party template.

Included in the custom Process Template is a set of reports relating to the Sprint burn down and work remaining data. These were fairly easy to develop, however, I have accepted that I have a long way to go in learning SQL Server Reporting Services before I can consider myself an expert.

More recently I have become responsible for the Configuration/Release Manager roles, and taken more responsibility for the project builds. Team Build is much better in TFS 2008 than it was in 2005. We have two dedicated Team Build agents running both our continuous integration and nightly builds. The nightly builds are automatically packaged into installers using WiX, and are then ready for deployment into our Development environment.

A code-promotion branching strategy has been favored with three general branches: Production, Main and Development. Main is always stable and a clean build can always be produced ready for deployment into a QA environment. Production represents a copy of our current live environment and supports "hot-fix" (or quick-fix engineering) scenarios. Merges between Main and Production are typically always forward (unless a "hot-fix" has to be brought into the Main codeline from Production). Day-to-day work is committed into the Development branch (and we have branches off that to support individual teams). Merges between Development and Main are forward or reverse depending on what is being done. Team Leaders for example, can forward-integrate to bring their branch up-to-date with code committed into the Development branch by other teams.

Generally my experience of using Team System and Team Foundation Server is positive. There are some quirky issues that I've had to learn workarounds for and I'll try and discuss those in upcoming posts.

Abstract Thinking in UML: the Russian Doll

Within my current role, I am helping the client interview candidates for both Senior .NET Developer and Architect positions. As part of the interview process I ask the candidate a few quick-fire questions regarding .NET (dependent on the position that they have applied for), and then I ask them to model a Russian Doll using a UML class-diagram.

For those who don�t know, a Russian Doll (or a Matryoshka Doll), is made up of many pieces that nest inside one another. The idea behind this simple modelling exercise is to allow the candidate to demonstrate both abstract thinking (by applying some form of object-oriented analysis), and their agile modelling capabilities. This is obviously a very important aspect if the candidate is to fit in an Agile team.

Once the description of a Russian Doll is agreed upon, the candidate simply needs to begin modelling on the whiteboard. It is surprising how many candidates fail to apply an analysis process to the problem, or simply ask questions. I wouldn�t consider it a weakness if a candidate asks me to get the model started for them. Many have simply given up immediately.

By far the simplest approach would be to analyse the nouns in the agreed description (i.e., a �doll� made up of many �pieces�). That gives us two candidate classes. Then we need to think about how the pieces nest inside one another, and also how we can represent the fact that a piece is the last piece in the set making up the doll.

I am sure that there are several ways in which this exercise can be modelled, but my model answer is shown below:

All design is subjective, but my model answer has two qualities (which hopefully would also be represented in the candidate�s design). First, it distinguishes between two distinct piece types (one hollow and one solid), and secondly, how these pieces can be arranged using the Composite design-pattern to form a doll that is made up of several hollow pieces, with a solid piece being the terminating condition for the overall structure. The use of the Composite design-pattern also prevents us from having a structure that has a solid piece that is the container for other pieces, since clearly it is collaborating in the leaf role.

So far, one or two candidates have actually questioned the validity of the association between HollowPiece and Piece (its base). I am hoping however, that this is down to inexperience with UML, since I feel that Composite is one of the most commonly used design-patterns (regardless of whether a candidate knows they are using it in their code or not).

I would be interested to hear any thoughts on this modelling exercise, especially as part of an interview process. I would also welcome any comments on my model answer too.

Setting up Team Foundation User Permissions

So you've installed Team Foundation Server and now you need to setup your permissions. There's quite a lot to follow in the TFS Installation Guide, so if you're using Active Directory, here's a digest of how I've recently defined permissions on a single-server deployment (this should work with both 2005 and 2008):

First, we have to remember that there are three areas where permissions have to be managed. TFS itself, SharePoint Services, and SQL Server Reporting Services. As far as I can tell, SQL Server Reporting Services appear to be the least secure of the three. When a user is assigned a Role Assignment it is not in relation to any particular Team Project.

There are also four distinct role types that we have to consider when thinking about permissions (summarized below):

TFS administrators are those users who create Team Projects
TFS project administrators are those users who manage Team Projects
Everyone else is either a Contributor or a Reader

The approach that I have taken (obviously working in conjunction with an Active Directory Administrator), is to define two Active Directory domain groups called TFSAdministrators and TFSProjectAdministrators. TFSAdministrators is added to the SharePoint Administration Group (or the Farm Administration Group in SharePoint 2007). It is also added as a System Administrator for the site-wide security settings in SQL Server Reporting Services. Basically any user added to this group will then have the appropriate permissions to create Team Project Portals and Reports in both SharePoint and SQL Server Reporting Services.

The second group (TFSProjectAdministrators), gives Team Project Administrators the Content Manager Role Assignment within SQL Server Reporting Services. Finally, to support the Contributor and the Reader roles, we define a new Browser Role Assignment within SQL Sever Reporting Services for the Domain Users group (i.e., the group to which everyone on the Domain in a member).

The combination of these two Active Directory groups and their permissions within SharePoint and SQL Server Reporting Services, effectively means that there is no longer a need to manually add users to the appropriate Role Assignment in SQL Server Reporting Services. Instead, a user can be added to their appropriate Active Directory group. Since permissions in SQL Server Reporting Services are not relative to a Team Project, this makes things much more intuitive going forward. In fact, it is now possible to forget about SQL Server Reporting Services altogether, and instead focus on adding users to the Team Foundation Server groups (i.e., Team Foundation Administrators or [project_name]\Project Administrators), and then adding the user to an appropriate group in the Team Project Portal.

I think that this provides a sensible and intuitive approach in managing user permissions within TFS. One change that I might consider is not adding the Domain Users group to the Browser Role Assignment in SQL Server Reporting Services, since this effectively gives every user in the Domain the ability to view all reports.

The Agile misconception as witnessed by Dilbert

A common "agile" misconception reflected in a way that only Scott Adams can:

(isn't this all too familiar?)

Introducing Partial Methods (that's right... methods)

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


public partial class Foo
{
���private int m_value;
	
���public static void Main()
���{
������m_value = 5;
		
������UpdateValue(SquareValue(m_value));
		
������Console.WriteLine(m_value);
���}
	
���private partial void UpdateValue(int x);
	
���private static int SquareValue(int value)
���{
������return value * value;
���}
}

If the partial method has no body, then the compiler will not emit any MSIL for the associated calls to that method (including any evaluation of the call parameters). In the above example UpdateValue() has no body, so the second statement in Main() will be removed (including the call to SquareValue()). The output for the above example will be "5". If we extend the partial class with the following code, and provide an implementation for the UpdateValue() method:


public partial class Foo
{
���private partial void UpdateValue(int x)
���{
������m_value = x;
���}
}

then all the code associated with calls to UpdateValue() will now be emitted. Since our implementation of UpdateValue() simply stores its input in the m_value field, the output will now be "25", since the emitted code will also include the call to SquareValue().

I will be the first to admit that the above example is very convoluted. It does however, demonstrate how the compiler deals with partial method declarations and implementations. In short, if a partial method has no implementation then all reference to its existence is removed, including any evaluation of the parameters used to call it. Even though I now have an understanding of how to write partial methods, I still have difficulty in seeing where I would want to use them. I can only assume that since partial methods can only be declared within partial classes, they only offer value in code generation scenarios.

T4 Template Editor for Visual Studio 2005/8

Clarius have released a new T4 Templating Transformation Toolkit that provides a better experience when working with T4 templates. Although T4 templates are predominately used for Guidance Automation and DSL work, with the T4 components being included out of the box in Visual Studio 2008, it is likely that more and more developers will begin using them for their own code-generation work. Well worth taking a look.

Had a think... time to re-think the adventure

To�all those who have subscribed to, or regularly read my blog (there's not many I know but one can hope):
�
I have decided to abandon my attempt in building a Software Factory for 3-tier Enterprise solutions. I have decided to do this because of two principal reasons: The adventure was always supposed to be about getting exposure to the tools used�in building Software Factories. I have realized that the sheer size and scope of 3-tier Enterprise applications will most likely interfere with that focus. I had intended to try and conceptualize the underlying�Enterprise�Framework, but this�will be very difficult to do, plus it would�detract from the product-line paradigm.
�
One day�I may also want to begin talking about and presenting material on what I have learnt during the adventure. This will typically be with my own clients, but as the topic becomes more prominent, I may also look into public speaking. Again, the size and scope of 3-tier Enterprise applications would make this much more difficult.
�
Despite this, I am not abandoning my adventure with Software Factories. Instead I am going to select a domain that is much smaller and self-contained,�and continue the adventure with that. I already have a few ideas and I'll post more over the next few days. I hope that you will agree that by adopting a smaller domain, the focus will remain on the tools themselves, and more importantly, the value that they may bring to the process.
�
While pondering my decision, I came across the NMVP Enterprise Factory that has been�started on CodePlex. I will take a look at this project soon�and possibly even try and contribute to it (if the project owner is willing). I will post more on that if it happens too.

Please note: I have removed some of the posts in the Software Factories category because they are no longer relevant. I will continue to add information about my adventures with Software Factories to the same area on the wiki. I really hope you continue following my adventure, albeit a slighty new one.

How to add Guidance Automation recipes to arbitrary Visual Studio menus

If you want to place a Guidance Automation recipe virtually anywhere within Visual Studio's menu structure, then here's a great tip for finding those menu Guids and Id's.

Articles on building and packaging Software Factories

Jezz Santos has announced a mini-series of articles that will discuss the packaging and building of Software Factories. The first article discusses how the various assets of a Software Factory, such as the DSL's and Guidance Automation Packages, can be combined into a single MSI installer.