Friends of mine know me as more of a cat person than dog, but after meeting my now wife she twisted my arm into buying a dog (on condition I could have a cat of course) and now four years or so later, Marnie is a much loved member of the family.

However, one of the reasons I prefer cats to dogs is the minimal maintenance needed. Especially walking!

This is why I was glad to find a website that makes finding local dog walks simpler, and dare I say, more enjoyable!

Walkiees.co.uk is a brand new site for dog owners to commune and share (primarily) dog walks which they recommend. The site allows you to search for dog walks by location which makes it easy to find walks in your vicinity. And because walks are added by users, they include photos and ratings to give you an idea of what the walk is like.

Coupled with a clear design and easy to use layout, I can see this site building quite a following, so I recommend checking it out if your stuck for walks in the UK.

Retrieving and displaying assembly version info in MVC views

I've tried a few times to get the right version number to display within an MVC view on a few projects now. And for a few different reasons I've always found it not entirely straight forward.

Taking pointers from the above link I ended up rolling some extension methods to HtmlHelper to allow me to easily pull through Assembly information from the AssemblyInfo.cs file and display them within MVC views.

        public static string AssemblyFileVersion(this HtmlHelper helper)
                if (Assembly == null)
                    return "x.x.x.x";

                var version = Assembly.GetName().Version;
                if (version == null)
                    return "x.x.x.x";

                return version.ToString();
                return "x.x.x.x";

        public static string AssemblyInformationalVersion(this HtmlHelper helper)
                if (Assembly == null)
                    return AssemblyFileVersion(helper);

                var version = FileVersionInfo.GetVersionInfo(Assembly.Location).ProductVersion;
                if (version == null)
                    return AssemblyFileVersion(helper);

                return version;
                return AssemblyFileVersion(helper);

Now I was able to display version information in markup by simply using @Html.AssemblyFileVersion().

The reason I wanted to get these numbers displayed somewhere is two fold:

  1. Let people (developers mainly) quickly and easily know what version of the software they are using.
  2. Use the version number as a way to force downloads of potentially cached static content (like .js files).

That last point is the real bonus to this technique. By adding ?version=@Html.AssemblyFileVersion() to the end of my Javascript includes they end up looking like /scripts/myjavascriptfile.js?version= This means that any changes to the JavaScript file that otherwise wouldn't have been pulled down by the browser will be forced to download due to the change of URI.

Comments are not the same as self documenting code

I've often heard developers scoff at the very idea of adding comments to their code. Indeed, I've even worked on projects with fellow programmers where their submissions lack even a single comment.

When challenged on this, the argument I receive time and time again is one of 'code should be self documenting'. Yes. But no.

You are correct, code should be self documenting. But you've missed the original point. We are talking about comments, and comments are not the same as self documented code.

Let's examine an example to illustrate the point:

    var a = 3.14159265359f * radius * radius;

Is far more obfuscated than:

    const float PI = 3.14159265359f;
    var areaOfCircle = PI * radius * radius;

I hope you'll agree this is a nice succinct example of self documenting code. Whereby both the constant and the variable name serve to communicate intent locally without having to read further down to understand how a gets used or where radius came from.

So when to prefer comments over self documentation?

Easy. If the code would become unnecessarily complex or architecturally compromised simply to satisfy something which a comment could solve with zero impact.

If you can refactor code to make some specific design decision bubble to the surface for easy comprehension then well done; you've achieved self documenting code (just be careful you're not eating too much into development time). But if you're twisting and breaking your well crafted API simply to let people know that you had to 'do it this way' because there is a bug in some library you depend on which only occurs on one platform if it happens to be a leap year, then I'm afraid you've dropped the ball.


        public void FindPathUsingModifiedAStarUsingMapsWithNodeGraph(int x, int y, Grid map)


        //based on A* - http://www.policyalmanac.org/games/aStarTutorial.htm
        //map: expects node data to speed up graph traversal
        public void FindPath(int x, int y, Grid map)

The signature is far more sensible and the comments actually communicate more information. (I know this is simplistic but I hope the reader can see the key point here.)

If you're wondering what I consider potential candidates for comments; I submit:

  • Optimisations (speed, memory etc.)
  • Minor bug fixes which don't impact the public interface.
  • Questions or points of consideration. ('May need to come back to this once we have more time')
  • Justifications. ('This may look whack but I had to do it this way because...')
  • Elaborations. When the self documentation within the code just isn't enough.
  • Anything temporary that shouldn't end up in the release build (TODO's)
  • ...
  • Thinking about it there are actually tons of reasons!

But comments are evil

I know, comments have the fair share of problems. They're instantly out of date, they add cruft to the code that only humans understand, high level languages are designed to be understood by both machines and humans so what's the need? These are all wholly valid points but everything comes with pro's and con's. No one is advocating a 1:1 ratio between LoC's and comments. That would be ludicrous. The advice here as with most things in our field is to apply common sense and justify everything on a case by case basis. If it needs a comment stick it in. If you can explain it in the method signature prefer that.

My fear is that developers who don't agree with this or have never considered these points have probably never worked on projects which require them. Which is fine. Just stop saying never.

Further reading

SOLID principles of object orientated programming

My User Group's latest talk covered the SOLID principles of object orientated programming. SOLID is one of those words I've heard bandied around on job specs and during tech discussions many times over. It covers a set of guidelines for how to manage (primarily) dependencies within your code, and how to reduce code smells that otherwise could manifest themselves into hard to maintain codebases.

The kind of smells which are common in large code bases, and are targeted by a SOLID design approach include:

  • Rigidity - Can't make changes without affecting large areas of the system.
  • Fragility - Can't make changes without breaking something.
  • Immobility - Can't reuse any of the code due to low cohesion etc.
  • Viscosity - Can't make changes that follow the architecture (design) of the system. Hacking.
  • Complexity - The code is needlessly complex. KISS.
  • Repetition - The code needlessly breaks the DRY principle.
  • Opacity - Difficult to understand.

So what are the principles of SOLID?

The full 11 set of principles covered by SOLID are:

  • The Single Responsibility Principle - A class should have one, and only one, reason to change.
  • The Open Closed Principle - You should be able to extend a classes behaviour, without modifying it.
  • The Liskov Substitution Principle - Derived classes must be substitutable for their base classes.
  • The Dependency Inversion Principle - Depend on abstractions, not on concretions.
  • The Interface Segregation Principle - Make fine grained interfaces that are client specific.

  • The Release Reuse Equivalency Principle - The granule of reuse is the granule of release.
  • The Common Closure Principle - Classes that change together are packaged together.
  • The Common Reuse Principle - Classes that are used together are packaged together.

  • The Acyclic Dependencies Principle - The dependency graph of packages must have no cycles.
  • The Stable Dependencies Principle - Depend in the direction of stability.
  • The Stable Abstractions Principle - Abstractness increases with stability.

Most developers who have never heard of SOLID or any of its principles probably still adhere to parts of what it attempts to communicate. For example; Single Responsibility or Dependency Injection. They may have just never heard it referred to in a larger group of principles.

When looking at the benefits of following the recommendations it is helpful to look through a code base which follows the guidelines and boasts a clean and tidy API. These codebases are few and far between but when you do find one you can really see the strengths of SOLID at work. You can also see it at play in smaller ways, like maybe a class which encapsulates it's problem nicely and communicates its intent clearly.

When SOLID isn't followed

I can think of one example which breaks at least the Interface Segregation Principle, and that's Microsoft's MembershipProvider in ASP.NET. It's a large class which users need to extend and implement in order to use its features. Most of which are probably not needed in every case but are forced upon the developer due to short sighted design.

This class could (should?) have been broken down into seperate classes/interfaces to handle things like password management and user management seperatly so that each feature can be leveraged in isolation rather then littering your sub class with lots of NotImplementedException's etc.

After reading up and familiarising myself with all this I have decided to make a conscious effort to try and enforce the SOLID approach in the next mid-large scale project I work on.

When I get more time I think I'll blog in depth about each principle.

Further reading

Connecting a PC to a Samsung TV

A few years back I splashed out and bought myself a (now dated) 40" Samsung LCD TV, specifically the LE40A558P3F XXU.

Not long after, I was trying to connect my Sony VAIO (VPCEC1M1E) laptop to the PC input on the back of the TV. My heart sank when I then noticed the option to select PC from the source list was disabled (greyed out) and wasn't selectable. It appeared the TV wasn't detecting a VGA signal.

I all but despaired!

After trying a few of the obvious things, different cables, upgrading firmware and drivers etc. I pretty much gave up. For some time actually. It wasn't until a year or so later I got frustrated that I had an expensive TV and expensive laptop that couldn't do something as simple as connect via VGA, so I reinvestigated.

Eventually I read something about the VGA cable's broadcasting the presence of a VGA device via a signal down one of the pins and how Samsung TV's can have a problem with this. I then also read you can fake these signals by shorting out the right pin, thus tricking the TV into thinking it is receiving a signal.

Short out the 10th pin

Here you can see which pin needs to be short circuited by connecting it to the outer (metal) casing of the VGA connector with another piece of metal. This metal bridge will create the short and cause the TV to think there is a VGA device connected.

Ignore the fact that this type of VGA cable doesn't have a 9th pin. It's used by certain monitors for plug and play purposes and not needed here.

Once shorted you will see the PC option of the Source List menu on the TV light up bright white. This means the TV is receiving the signal and you can now select the PC source.

Don't ask me why Samsung software demands that a signal be 'perceived' before you can select the option. I can only guess they are trying to make the TV's more user friendly by allowing user's to skip over options which they don't use. Unfortunately this isn't the case as the software allows you to select TV even when it is receiving noise and it is clever enough to detect the noise as it helpfully switches itself off if the noise continues for a set amount of time. Nonsense.

Anyway, now the TV is happily configured to display a PC signal, remove the short and go ahead and connect up your computer hardware. Once you flick on the VGA output on your PC (Windows 7 hit windows key + P) and your TV should now be displaying your PC screen in all its glory. Note that the PC must be outputting a resolution that your TV supports.

Extendable JsonResult

Another class I had lying around that I thought might be useful. Here I offer an extension to the .NET MVC JsonResult class that allows you to pass JavaScriptConverter's that will be used to parse the result prior to it being returned in the response.

    /// Extends JsonResult to accept JavaScriptConvertors to be used as serialisers for it's data.
    public class ExtendableJsonResult : JsonResult
        /// Constructs a ExtendableJsonResult using the supplied converters.
        /// The convertors to be used to serialise this results Data.
        public ExtendableJsonResult(IEnumerable<JavaScriptConverter> acceptedConvertors)
            _acceptedConvertors = acceptedConvertors;

        public override void ExecuteResult(ControllerContext context)
            if (context == null)
                throw new ArgumentNullException("context");

            var response = context.HttpContext.Response;

            response.ContentType = !String.IsNullOrEmpty(ContentType) ? ContentType : "application/json";

            if (ContentEncoding != null)
                response.ContentEncoding = ContentEncoding;

            if (Data == null)

            JavaScriptSerializer jsSerialiser = new JavaScriptSerializer();


        private readonly IEnumerable<JavaScriptConverter> _acceptedConvertors;