Here's a great online resource for formatting C# code as HTML. It's perfect for when you need to include code in your blog posts or email.

I’ve been a big fan of Resharper for quite a while, and I’ve heard a few people comment on how cool the structured search and replace is. Two weeks into my new assignment at N4 Solutions, I had a need to change some code that I thought structured search and replace would be ideal for. Given some code structured like that shown below:

[DataContract]
public class Foo
{
    [DataMember(IsRequired = true)]
    public IList Bars { get; set; }
}

I want to replace all public properties so that when they are required (i.e., the DataMember attribute has an IsRequired property set to true), I want the property to become read-only by making the set protected. So the above example would become:

[DataContract]
public class Foo
{
    [DataMember(IsRequired = true)]
    public IList Bars { get; protected set; }
}

Sounds straight forward, and you can see why I thought structured search and replace would be the ideal tool for this job. After all, this is a straight forward mechanical task – when IsRequired is true, make the setter protected. Simple. Although Resharper’s structural search and replace appears to be a fantastic feature, it doesn’t appear to support this kind of “structure”. It works fine across expressions and statements, but not if you want to work at method, property, attribute, or class levels. It doesn’t appear to support those, giving you the “Cannot parse pattern” error. If the team at JetBrains read this, then please work on supporting these structures too – it would make an awesome feature even more awesome.

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.

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.

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.

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