markhneedham/blog huggingface dataset:
Debugging: Get to a stage where it works
Date: 2009-05-12 09:21:13

When debugging a problem I've learnt far too many times that where possible the most effective approach is to try and get the application back into a state where it does work and then analyse the changes that have resulted in it no longer working as expected.

About 7 or 8 years ago when I used to code PHP at school and university that pretty much was my default approach - I didn't really know how to program well enough to work out how to fix something that was broken so I would always just revert back all the steps I'd done until it worked.

I didn't think it was a particularly good approach at the time - I wasn't using source control so I always used to lose my changes - but looking back at that approach now I think it is one of the most effective ones when debugging.

A recent example of this came when we were trying to work out why our selenium server was no longer being launched when we ran the build locally.

There had been some changes on the files involved but they didn't seem substantial, so my pair and I started looking through the code as it was now and trying to work out what it was doing wrong now.

We didn't really succeed in getting anywhere - there wasn't anything that stood out as being wrong.

Somewhat luckily another colleague happened to come across the code that we were looking at and pointed out something else that seemed strange about what was going on. It turned out that more of the code had been changed that we originally thought.

We went back to the subversion logs and realised that the paths to the selenium jar had been changed to be relative rather than absolute - it was a valid change designed to allow us to run the build for different branches locally - but the relative path wasn't correct and therefore the selenium server was never being started even when the build was run from the trunk.

We had actually been attempting to fix this problem on a branch so we had actually made the problem more difficult for ourselves than it needed to be. Not only was the absolute path not going to work for us but the relative path that we needed was also different as we had checked out the code a level up in the directory structure.

In an attempt to get something working we reverted the changes back to a state where we were able to run the build on the trunk and the selenium server starting working correctly again.

We then had a more stable base to make the changes from.

The lesson for me here was that if things go wrong it's more effective to get back to a working state as quickly as possible and go from there instead of theorising on what went wrong and trying to fix it that way.
Mercurial: Pulling from behind a proxy
Date: 2009-05-13 07:49:44

I've been playing around with Mercurial and the mercurial hosting website http://bitbucket.org/[bitbucket] a bit this year and recently wanted to pull from a repository from behind a proxy server.

With a bit of help from the http://www.nabble.com/proxy-td21973435.html[mercurial mailing list] and the http://www.selenic.com/mercurial/hgrc.5.html[documentation] this is how I was able to pull the repository for the Hambread project I've been doing a bit of work on:

~~~text

hg --config http_proxy.host=ipOfYourProxyServer:portOfYourProxyServer --config http_proxy.user=user --config http_proxy.passwd=password pull http://bitbucket.org/markhneedham/hambread~~~

After that command a 'hg update' updates your local repository with all the changes that have just been pulled.

What I found strange was that you needed to define the '-- config' part of the command three times as far as I can tell in order to pass each of the different properties related to the proxy.

I tried just defining it once and just setting the properties individually but that just produced errors.
Nant include task - namespace matters
Date: 2009-02-03 10:43:56

We've been trying to include some properties into our build file from a properties file today but no matter what we tried the properties were not being set.

We eventually realised that the build file has an XML Namespace set on the project element.

[source,text]
----

<project name="..." xmlns="http://nant.sf.net/schemas/nant.xsd">
----

It turns out that if you want to include a properties file in your build file, like so:

[source,text]
----

<include buildfile="properties.xml" />
----

...you need to put the namespace on the project attribute of that file as well, otherwise its properties don't get picked up.

Our properties file therefore needs to look like this, assuming that we have a namespace set on the build file.

[source,text]
----

<project name="properties" xmlns="http://nant.sf.net/schemas/nant.xsd">
	<property name="foo" value="bar" />
</project>
----

What's a bit confusing is that on the NAnt documentation page for the http://nant.sourceforge.net/release/latest/help/tasks/include.html[include task] it says that project element attributes are ignored! That's not what we found!
C#: Public fields vs automatic properties 
Date: 2009-02-04 17:52:03

An interesting new feature in C# 3.0 is that of http://msdn.microsoft.com/en-us/library/bb384054.aspx[automatic properties] on objects - this allows us to define a get/set property and the creation of the underlying field is taken care off for us.

We can therefore create a class like this:

[source,csharp]
----

public class Foo {
	public string Bar { get; set; }
}
----

Now ignoring the fact that it's terrible OO to write a class like that, one thing that we've been wondering is what's the difference between doing the above and just creating a public field on Foo called Bar like so:

[source,csharp]
----

public class Foo
{
	public string Bar;
}
----

In terms of how we use the class in our code it's conceptually the same but there are a couple of subtle differences.

We can change our implementation more easily if we use the automated properties. If we decide that we want to do something else apart from just setting a field or returning it then we can do that more easily without having to recompile assemblies that depend on that class.

If we decided we only wanted the getter to be public but to have a private setter that would be an easier change using automated properties, and if we want to reflect on the class I find it's much easier to do that when we have properties rather than fields.

That's all I can think of at least. Are there any other differences?
C#: Properties vs Methods
Date: 2009-02-11 11:20:08

I was browsing through our tests today and noticed a test along these lines (simplified for example purposes):

[source,csharp]
----

[Test, ExpectedException(typeof(Exception))]
public void ShouldThrowExceptionIfNoBarSet()
{
    var bar = new Foo(null).Bar;
}
----

[source,csharp]
----

public class Foo
{
	private readonly string bar;

	public Foo(string bar)
	{
    		this.bar = bar;
	}

	public string Bar
	{
    		get
    		{
        		if (bar == null)
        		{
            		throw new Exception("No bar");
        		}
        		return bar;
    		}
	}
}
----

What I found strange here is that 'bar' is never used and Resharper points out as much. If we try to remove it, however, the code no longer compiles.

[source,csharp]
----

[Test, ExpectedException(typeof(Exception))]
public void ShouldThrowExceptionIfNoBarSet()
{
    new Foo(null).Bar;
}
----

[source,text]
----

Only call, assignment, increment, decrement, and new object expressions can be used as a statement.
----

We therefore need to assign the call to Bar to a variable even though we never intend to reference it.

This problem wouldn't happen if Bar was a method instead.

[source,csharp]
----

[Test, ExpectedException(typeof(Exception))]
public void ShouldThrowExceptionIfNoBarSet()
{
    new Foo(null).Bar();
}
----

[source,csharp]
----

public string Bar()
{
    if (bar == null)
    {
        throw new Exception("No bar");
    }
    return bar;
}
----

Which got me thinking how do we know when to use a method and when to use a property?

Clearly if there are parameters to be passed in then we have no choice but to use a method since we can't call properties with parameters.

If we are simply returning data values then we might as well just use properties since this is what they were made for. We can even make use of automated properties to smooth the process.

Which leaves the situation where there is some logic that needs to be calculated, no outside data is needed to do this calculation and a result is returned to the client.

Probably because of the Java influence my preference would be to do this using a method but I don't really have any other justification for not using a property to achieve the same thing.

Discussing this briefly with http://twitter.com/davcamer[Dave] we thought maybe if a property is used then the execution needs to be idempotent (i.e. return the same result every time) although the argument could be made that well written methods should also be side effect free. Eric Evans' advocates writing http://domaindrivendesign.org/discussion/messageboardarchive/SideEffectFreeFunctions.html[side effect free functions] in http://domaindrivendesign.org/[Domain Driven Design] for example.

Does anyone have any compelling reasons why or why not to use one or the other?
Agile: Re-estimating cards
Date: 2009-02-11 07:25:50

Chris Johnston has another interesting post in which he writes about the http://www.fuzzylizard.com/archives/2009/02/08/1008/[practice of re-estimating cards after they have been completed].

I think this somewhat misses the point that *the estimate is indeed supposed to be an estimate*. It might turn out to be too optimistic or too pessimistic, the theory being that overall we will end up with a reasonable balance that will allow us to make a prediction on how much work we believe we can complete in a certain time period.

I've always seen estimates of story cards to be a relative thing - on all the teams I've worked on after initial cards have been estimated we've looked at the difficulty of upcoming cards and tried to score them relative to the ones already estimated.

Re-estimating cards (presumably) individually means that you lose the benefits of this approach and end up with a fairly meaningless value.

We are also ignoring the inherent uncertainty involved in estimating if we do so afterwards and I don't really see it helping us that much for future predictions since there is still going to be uncertainty with regards to the implementation of future cards no matter what we try to do.

If data needs to be collected after a card has been played then I would say the time it took to complete a card might be a more useful metric although there are more than likely going to be some cards that take longer than expected and some that take less than expected, so I'm not sure what extra value this data would provide.

As Chris points out if there are times, when we come to play a card or just after we start work on it, when we realise that some of our assumptions are incorrect therefore meaning that the estimate is inaccurate.

In this case I think it's reasonable to talk through the new assumptions and re-estimate the card so that we have a more accurate estimation of its difficulty.

When trying to work out how much work we can do in a certain time box, averaging the data we have from the original estimates is likely to provide the most accurate prediction in my opinion.

Apart from times when we have story cards overflowing from one iteration to the next, meaning that we end up with one high scoring and then one low scoring iteration, I have found on my projects that the amount of work points wise doesn't tend to vary very much which lends credence to the theory that the estimates eventually balance out.
C#: Object Initializer and The Horse Shoe
Date: 2009-02-16 22:04:20

The http://davidhayden.com/blog/dave/archive/2006/12/04/ObjectInitializationExpressions.aspx[object initializer] syntax introduced in C# 3.0 makes it easier for us to initialise our objects in one statement but I think we need to remember that they are not http://en.wikipedia.org/wiki/Named_parameter[named parameters] and that there is still a place (a very good one actually) for creating objects from constructors or factory methods.

Unfortunately what I think the cleaner syntax does is encourage us to create objects with half the fields populated and half of them null by default.

When we didn't have the object initializer syntax we would have to set properties on objects like so:

[source,csharp]
----

var foo = new Foo();

var bar = new Bar();
bar.Baz = new Baz();

foo.Bar = bar;
----

It takes a lot of extra boiler plate code to achieve this and it looks terrible, hopefully driving us towards using the constructor to initialise our objects.

Object initializers makes it much easier to achieve the same thing but at its worst we end up with code similar to the following which to me *looks a bit like a horse shoe*, an anti pattern in my opinion.

[source,csharp]
----

new Foo
{
	Bar = new Bar
	{
		Baz = new Baz
		{
			Other = new Other
			{
				Value = "value",
				OtherValue = "otherValue"
			}
		}
	}
}
----

I don't think we should write code like this - to me *it's not expressive and it's difficult to understand* why certain fields are set or not set. You end up having to think how this code fits into the bigger picture in order to understand it - extra context which shouldn't be necessary.

From experience we also end up in the debugger much more frequently than should be the case, trying to work out why certain fields are set. I feel this leads to very implicit code where you have to work out what is going on/where you are in the work flow by checking the state of our objects.

Of course the problem here is the reliance on properties (i.e. getters/setters) to instantiate our objects rather than object initializer in itself but the new syntax has made it much easier for us to do it.

Certainly there are some times when it's quite nice to have the object initializer syntax but as with most things we need to be careful not to overdo it.
Collective Code Ownership: Some Thoughts
Date: 2009-02-17 22:32:44

http://c2.com/cgi/wiki?CollectiveCodeOwnership[Collective code ownership] is one of the things we practice on projects using extreme programming and http://aydsoftware.blogspot.com/2009/02/collective-code-ownership.html[Mike Bria's post on the subject] makes me wonder if  code ownership exists on more than one level.

http://industrialxp.org/collectiveOwnership.html[Kent Beck's definition of collective code ownership] is that

____
Anyone can change anything at anytime
____

Mike also gives an alternative definition which goes beyond that:

____
From a more measurable POV, CoCO states that everyone on the team (developer-wise) must be able to describe the design of anything the team is working on in no more than 5 minutes.
____

Fo me this second definition goes beyond just describing a belief system about code and seems to be heading more towards the benefits we achieve from close collaboration on a code base using techniques such as pair programming.

I've worked on several different teams over the last few years and although we've practiced collective code ownership on all of them I've noticed that only really on the projects where the whole team practiced pair programming all the time did everyone on the team have a good understanding of all areas of the code.

In those teams where we didn't pair all the time we tended to end up with people becoming specialised in certain areas of the code, leading to them being asked to do the next story in that area, and so on until other people found it difficult to make changes without consulting them.

It's almost like the benefits of collective code ownership are lost without the belief system of the team actually changing.

We can still change the code if we want to but we don't have the confidence to do so since we haven't done any work in that area.

Even if someone does explain the code to the rest of the team afterwards after they have written it, I don't think it's the same as living through the process of writing it, seeing the tradeoffs, limitations and the reasons why decisions were made.

From my experience this happens far more frequently when pair programming as we get to work on a lot more areas of the code as well as working with people who can provide insight on other areas of the code that we might not have worked on yet.

The *belief of collective code ownership + pair programming* is what leads to that second definition, which surely is the ideal on any software development team.
C#: Extension methods != Open classes
Date: 2009-02-19 06:22:07

When I first heard about http://weblogs.asp.net/gunnarpeipman/archive/2007/11/18/c-extension-methods.aspx[extension methods] in C# it sounded like a pretty cool idea but I wasn't sure how they differed to the idea of open classes that I had seen when doing a bit of Ruby.

After a bit of a struggle recently to try and override some extension methods on HtmlHelper in ASP.NET MVC it's clear to me that we don't quite have the same power that open classes would provide.

To start with we can't access private variables of a class in an extension method - as far as I understand an extension method is just syntactic sugar to make our code look pretty at compile time.

We therefore only have access to public fields, methods and properties from extension methods. Anything protected is also out of our reach.

I'm no expert of Ruby's open classes but from what I have http://memeagora.blogspot.com/2007/05/are-open-classes-evil.html[read] and remember you can override private methods, use private variables and even remove methods if you want to. We could also add methods to a specific instance of a class which we can't do using extension methods.

We therefore tend to be limited to using C#'s extension methods for applying operations directly to an object - applying different types of formatting to strings is one common use.

Before extension methods existed this type of code would typically have gone on a StringUtils class so this is a definite improvement.

We can 'add' more functional methods to a class as long as it only uses data accessible from the class' API but we haven't tended to do this so much on the projects I've worked on.

The ability to override methods added to a class away from its original definition is something that we don't have using extension methods.

As I mentioned we has some problems with this recently when trying to work out how to override some calls to HtmlHelper methods.

In this case it would have been nice to be able to open up the HtmlHelper class and change these methods. Unfortunately since they were defined as extension methods, extending HtmlHelper didn't give access to them so we ended up coming up with a solution which feels http://www.markhneedham.com/blog/2009/02/12/aspnet-mvc-preventing-xss-attacks/[a bit too hacky for my liking].

As http://www.25hoursaday.com/weblog/2008/01/23/C30VsRubyThoughtsOnExtensionMethodsAndOpenClasses.aspx[Dare Obasanjo points out towards the end of his post] we also don't have the ability to create extension properties. Seeing as properties are compiled to get/set methods under the hood I wouldn't have thought it would be that difficult to add this in the next release.

Overall though extension methods are a nice addition but they still don't quite give us the full power that open classes would provide.
Coding Dojo #10: Isola III
Date: 2009-02-19 23:09:33

In our latest coding dojo we continued working on http://bitbucket.org/codingdojosydney/isola[Isola] with a focus on adding functionality following on from http://www.markhneedham.com/blog/2009/02/12/coding-dojo-9-refactoring-isola/[last week's refactoring effort].

== The Format

We used the http://codingdojo.org/cgi-bin/wiki.pl?RandoriKata[Randori] approach with four people participating for the whole session.

== What We Learnt

* Our real aim for this session was to try and get the code into a state where we could reject an invalid move i.e. a move to a square that wasn't adjacent to the one the player was currently on. As we still had the whole board represented as a string this proved to be quite tricky but we eventually came up with an approach which http://bitbucket.org/codingdojosydney/isola/src/c024ba6f708b/src/main/java/gn/isola/game/IsolaBoard.java[calculated the difference between the last and current moves] and was able to tell us whether or not it was valid. This didn't cover diagonal moves, however. We found it pretty difficult to drive this functionality due to the way the board was represented.
* What I've found surprising is how long we've been able to get away with having the board represented like this. Ideally we would have it represented in a structure that made it easy for us to make changes. This would require quite a *big refactoring effort* which we shied away from, I think due to the fact that we would be working without a green bar for quite a while during the refactoring. It wasn't obvious to me how we could refactor the code in small steps.
* http://blog.halvard.skogsrud.com/[Halvard] pointed out that while we don't want to do Big Design Up Front, what we did in the first week of Isola was No Design Up Front which was equally harmful. Finding a happy medium i.e. *Enough Design Up Front* is necessary to avoid the problems we have run into here.

== For next time

* We're planning to try and implement Isola in Javascript next week. Most of the Dojo regulars are working with Javascript on their projects so it makes sense to give it a go.
Coding: Using 'ToString'
Date: 2009-02-26 23:43:20

An interesting conversation I've had recently with some of my colleagues is around the use of the ToString method available on all objects created in Java or C#. It was also pointed out in the http://www.markhneedham.com/blog/2009/02/25/c-wrapping-datetime/#comment-10930[comments on my recent post about wrapping DateTimes in our code].

I think the original intention of this method was to create a string representation of an object, but its use has been overloaded by developers to the point where its expected use is as a mechanism for creating nice output when debugging the code or viewing unit test failures.

The nice thing about it in C# at least is that if you are using an object in your UI you can just put the object into the view and the ToString method will be implicitly called when the object needs to be rendered.

The problem with doing that is its implicitness - other developers might change the ToString method when debugging some code to give more useful output and the display logic of our application has now changed, potentially without us realising until a higher level functional test stops working.

The method name itself is not really that intention revealing anyway - what string format is it creating? A display string? A debugging string? It's not that clear.

The approach we are now taking is a bit more explicit and involves having a more explicit method on objects to achieve the same end result.

Method names such as 'ToDisplayFormat' or 'ToServiceFormat' help us to explain a bit more clearly what we are doing while still getting our object to render a different representation of itself.