markhneedham/blog huggingface dataset:
F#: Object expressions
Date: 2009-05-19 01:38:31

One of the things I miss a bit from the Java world is the ability to create anonymous inner classes which implement a certain interface.

We can't do this in C# - you always need to define a named class - but in my latest playing around with F# I was quite pleased to learn that we do have this ability using a feature called *object expressions*.

These come in particularly useful when you are only making use of the implementation of an interface in one place in the code and therefore don't want to expose this type to any other code.

Given an interface:

[source,ocaml]
----

type ICarRepository =
    abstract FindAll : Unit -> list<Car>
----

[source,ocaml]
----

type Car() =
----

The normal way to implement that interface if we are following the C# approach would be like this:

[source,ocaml]
----

type CarRepository() =
	interface ICarRepository with
	    member self.FindAll () = [ new Car() ]
----

We would then reference the CarRepository in our code:

[source,ocaml]
----

let myCarRepository = new CarRepository();;
----

The alternative is to create a value which implements the interface inline, a way of coding which is easier to implement instead of having to create a new type each time we want to implement an interface.

[source,ocaml]
----

let myCarRepository =
{ new ICarRepository with
     member self.FindAll () = [ new Car() ] }
----

This seems to be quite in keeping with the style of programming being taught in the http://manning.com/petricek/[Real World Functional Programming] book which seems to be around getting code working quickly and then working iteratively towards a more reusable solution.

I'd be interested to see how well this technique would work on a real project since I get the feeling that quite a lot of interface implementations are only used in one place and therefore don't really need to have a type defined purely for implementing them - that decision can be delayed until one is actually needed.
Pair Programming: Refactoring
Date: 2009-05-26 23:44:36

One area of development where I have sometimes wondered about the value that we can get from pair programming is when we're spending time doing some major refactoring of our code base.

The reason I felt that pairing on big refactoring tasks might be difficult  compared to when working on a story together is that with a story there tends to be a more defined goal and the business have defined that goal whereas with a refactoring task that goal is often less clear and people have much wider ranging differing opinions about the approach that should be taken.

Having spent time pairing on some refactoring work for most of the last week I have changed my mind and I think that pairing on refactoring tasks is actually extremely valuable - certainly equally as valuable as pairing on story work and perhaps more so.

What I noticed in my time pairing on this task is that actually although there is more conflict over the approach that should be taken this actually works out reasonably well in terms of driving *an approach that is somewhere between pragmatic and dogmatic*.

From my experience, the mentality when you're the driver in a refactoring session is pretty much to want to fix everything that you come across but having someone else alongside you helps to rein in this desire and focus on making the fixes that add value to the code right now.

I was quite surprised to notice that within just one keyboard switch we had both suggested to the other that making a particular refactoring should probably be added to our 'refactoring list' to have a look at later on rather than looking at it now and potentially getting into a http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html[yak shaving situation].

Another thing I noticed was that the navigator was often able to point out things that the other person didn't see - sometimes making a certain change to the code had a bigger impact than the driver had expected and the navigator was able to spot this quickly and initiate a discussion about what the next step should be before we had gone too far down the wrong path.

Refactoring code effectively and not making mistakes when doing so is one of the more difficult skills to learn as a developer and I think it is very difficult to learn by just working on your own since the approach to effectively refactor code by taking very small steps is not necessarily obvious.

While http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_1?ie=UTF8&s=books&qid=1243345240&sr=8-1[there] http://www.amazon.co.uk/Refactoring-Patterns-Addison-Wesley-Signature-Kerievsky/dp/0321213351/ref=sr_1_2?ie=UTF8&s=books&qid=1243345240&sr=8-2[are] http://www.markhneedham.com/blog/2008/09/15/clean-code-book-review/[certainly books] which explain how to do refactorings on our code a lot of the approaches that I like to use have been taught to me by more experienced people that I've had the chance to pair with. *Pairing creates the opportunity for these skills to be passed on to other members of the team*.
The value of a fresh mind
Date: 2009-05-26 00:51:41

I recently http://developer-in-test.blogspot.com/2009/05/why-i-dont-like-over-working-in-project.html[read a post by my colleague Sai Venkatakrishnan] where he talks about some of the disadvantages of over working on a project and it reminded me of something I've noticed a lot recently - notably that after taking a break from solving a problem, either by looking at it again the next day or after lunch or any kind of break I end up solving it significantly more quickly than if I'd kept on trying to solve it without doing so.

I'm not sure exactly why that is, but it seems to tie in nicely with Tip 16 from http://www.markhneedham.com/blog/2008/10/06/pragmatic-learning-and-thinking-book-review/[Pragmatic Learning and Thinking]:

____
Step away from the keyboard to solve hard problems.
____

The idea that Andy Hunt is promoting is that we should take some time away from the keyboard and keep the problem in mind but don't focus on it - the rich mode in our brain (used for intuition, problem solving and creativity) will take over from the linear mode (used for working through the details and making things happen) and probably lead us to the insight that helps us solve the problem.

I think it comes down to the fact that when you are really close to a problem for a long period of time and you're feeling tired you stop seeing the bigger picture and therefore perhaps miss what would be a much simpler way of solving the problem. This has happened on several occasions for me and each time I am surprised that I couldn't see the obvious solution the day before.

Another thing I've noticed is that not only do I start to not see solutions to problems but I start to make more mistakes than I normally would and end up spending time the next day fixing these, meaning the extra time spent didn't really add any value at all - very frustrating!

I think it's fine to sometimes spend extra time working on problems, especially if they are critical ones that need to be fixed within a certain time frame - usually production issues or when close to release - but apart from those occasions it really does seem to be true that maintaining a http://c2.com/cgi/wiki?SustainablePace[sustainable pace]  works out more productive overall than over working and being in a consistently tired state.

An idea somewhat related which I'm keen to try out is the http://blog.staffannoteberg.com/2008/02/22/pomodoro-technique-in-5-minutes/[Pomodoro technique] which I've seen the http://pairwith.us/[pairwithus] guys using during their pairing sessions. From what I've read about this technique it might take the idea of keeping our mind fresh and focused to the next level.

Whatever the technique we choose to use the value of stepping away from the keyboard to solve problems more quickly seems counter intuitive but somehow keeps coming true for me at least.
Build: Using virtual machines to run it in parallel
Date: 2009-05-21 18:02:27

One of the things that we've been working on lately to improve the overall time that our full build takes to run is to split the acceptance tests into several small groups of tests so that we can run them in parallel.

We are using http://studios.thoughtworks.com/cruise-continuous-integration[Cruise] as our build server so the ability to have multiple agents running against different parts of the build at the same time comes built it.

We then had to work out what the best environment to run more agents would be.

I guess the traditional approach to the problem would be to get some extra machines to use to run the build but this wasn't possible so our initial solution was to use our developer virtual machines as build agents.

This worked in principle but the environment became way too slow to work on when the build was running and the selenium windows that popped up when each test was running became amazingly annoying. We could only really use this approach to set up agents on developer machines that weren't being used that day.

We therefore came across the idea of having 2 virtual machines running on each developer machine, splitting the resources of the machine across the two virtual machines.

From experimenting it seems like the agent used to run a build with selenium tests in it needs to have around 1.2 GB of RAM assigned to it to run at a reasonable rate. Our developer machines have a total of 3 GB of RAM so the majority of the rest is being used by the development virtual machine.

Our development virtual machine environments run marginally slower when there is a build running on that machine but we've reduced that problem by ensuring we have the build running across as many developer machines as possible so that it runs less frequently on each machine

I think it serves as a worthwhile trade off for helping to reduce our total build time significantly - running sequentially it would take over an hour to run all our tests but in parallel we've managed to get a 10-15 minute turn around time at worst.

While trying to see if we could make that any faster we toyed with the idea of having two build virtual machines on the same box but that didn't seem to provide the improvement that we expected due to I/O restraints - our build has quite a bit of writing and reading from disc and having two builds doing this at the same time seemed to slow down both of them.

Overall though it's working out pretty well for us in terms of providing us a quick feedback mechanism of whether or not our system is working correctly end to end.
CouchDB/Futon: '_all_dbs' call returns databases with leading 'c/'
Date: 2009-05-31 23:28:20

As I mentioned http://www.markhneedham.com/blog/2009/05/31/sharpcouch-use-anonymous-type-to-create-json-objects/[in my previous post] I've been playing around with http://wiki.apache.org/couchdb/FrontPage[CouchDB] and one of the problems that I've been having is that although I can access my database through the REST API perfectly fine, whenever I went to the https://forge.process-one.net/browse/~raw,r=811/CouchDB/trunk/share/www/index.html[Futon] page ('http://localhost:5984/_utils/' in my case) to view my list of databases I was getting the following javascript error:

[source,text]
----

Database information could not be retrieved: missing
----

I thought I'd have a quick look with FireBug to see if I could work out what was going on and saw several requests being made to the following urls and resulting in 404s:

* http://localhost:5984/c%2Fsharpcouch/
* http://localhost:5984/c%2Fmark_erlang/

The value 'c/' was being added to the front of each of my database names, therefore meaning that Futon was unable to display the various attributes on the page for each of them.

Tracing this further I realised that the call to 'http://localhost:5984/_all_dbs' was actually the one that was failing, and calling it directly from 'erl' was resulting in the same error:

[source,erlang]
----

> couch_server:all_databases().

{ok,["c/mark_erlang","c/sharpcouch","c/test_suite_db"]}
----

I don't know Erlang well enough to try and change the code to fix this problem but I came across a https://issues.apache.org/jira/browse/COUCHDB-307[bug report] on the CouchDB website which described exactly the problem I've been having.

Apparently there is a problem when you use an upper case 'C' for the 'DbRootDir' property in 'couch.ini'. Changing that to a lower case 'c' so that my 'couch.ini' file now looks like this solved the problem:

[source,text]
----

DbRootDir=c:/couchdb/db
----
xUnit.NET: Running tests written in Visual Studio 2010
Date: 2009-05-30 11:51:53

I've been playing around with F# in Visual Studio 2010 after the http://blogs.msdn.com/dsyme/archive/2009/05/20/visual-studio-2010-beta1-with-f-is-now-available-plus-matching-f-ctp-update-for-vs2008.aspx[Beta 1 release last Wednesday] and in particular I've been writing some xUnit.NET tests around the http://www.markhneedham.com/blog/2009/04/13/f-a-day-of-writing-a-little-twitter-application/[twitter] http://www.markhneedham.com/blog/2009/04/18/f-refactoring-that-little-twitter-application-into-objects/[application] I've been working on.

A problem I ran into when attempting to run my tests against 'xunit.console.exe' is that http://twitter.com/bradwilson/statuses/1955212964[xUnit.NET is linked to run against version 2.0 of the CLR] and right now you can't actually change the 'targetframework' for a project compiled in Visual Studio 2010.

[source,text]
----

> xunit.console.exe ..\..\TwitterTests\bin\Debug\TwitterTests.dll

System.BadImageFormatException: Could not load file or assembly 'C:\Playbox\FSharpPlayground\Twitter\TwitterTests\bin\Debug\TwitterTests.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
File name: 'C:\Playbox\FSharpPlayground\Twitter\TwitterTests\bin\Debug\TwitterTests.dll'
   at System.Reflection.AssemblyName.nGetFileInformation(String s)
   at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile)
   at Xunit.Sdk.Executor..ctor(String assemblyFilename)
   at Xunit.ExecutorWrapper.RethrowWithNoStackTraceLoss(Exception ex)
   at Xunit.ExecutorWrapper.CreateObject(String typeName, Object[] args)
   at Xunit.ExecutorWrapper..ctor(String assemblyFilename, String configFilename, Boolean shadowCopy)
   at Xunit.ConsoleClient.Program.Main(String[] args)
----

I wasn't really sure how to fix this but luckily http://twitter.com/davcamer/statuses/1955037499[Dave] pointed out that the way to do this is to add a http://msdn.microsoft.com/en-us/library/bbx34a2h(VS.100).aspx['requiredRunTime' tag in the 'startup' section of the configuration file] (xunit.console.exe.config):

[source,text]
----

<configuration>
...
	<startup>
      <requiredRuntime version="v4.0.20506" safemode="true"/>
	</startup>
...
</configuration>
----

And all is good:

[source,text]
----

> xunit.console.exe ..\..\TwitterTests\bin\Debug\TwitterTests.dll

xUnit.net console runner (xunit.dll version 1.4.9.1416)
Test assembly: C:\Playbox\FSharpPlayground\Twitter\TwitterTests\bin\Debug\TwitterTests.dll
........
Total tests: 8, Failures: 0, Skipped: 0, Time: 0.231 seconds
----
C#: Using virtual leads to confusion?
Date: 2009-05-06 19:30:50

A colleague and I were looking through some code that I worked on a couple of months ago where I had created a one level hierarchy using inheritance to represent the response status that we get back from a service call.

The code was along these lines:

[source,csharp]
----

public class ResponseStatus
{
    public static readonly ResponseStatus TransactionSuccessful = new TransactionSuccessful();
    public static readonly ResponseStatus UnrecoverableError = new UnrecoverableError();

    public virtual bool RedirectToErrorPage
    {
        get { return true; }
    }
}

public class UnrecoverableError : ResponseStatus
{

}

public class TransactionSuccessful : ResponseStatus
{
    public override bool RedirectToErrorPage
    {
        get { return false; }
    }
}
----

Looking at it now it does seem a bit over-engineered, but the main confusion with this code is that when you click through to the definition of 'RedirectToError' it goes to the ResponseStatus version of that property and it's not obvious that it is being overridden in a sub class, this being possible due to my use of the http://msdn.microsoft.com/en-us/library/9fkccyh4(VS.71).aspx[virtual] key word.

You therefore need to look in two places to work out what's going on which isn't so good.

A solution which we came up with which is a bit cleaner is like so:

[source,csharp]
----

public abstract class ResponseStatus
{
    public static readonly ResponseStatus TransactionSuccessful = new TransactionSuccessful();
    public static readonly ResponseStatus UnrecoverableError = new UnrecoverableError();

    public abstract bool RedirectToErrorPage { get; }
}

public class UnrecoverableError : ResponseStatus
{
    public override bool RedirectToErrorPage
    {
        get { return true; }
    }
}

public class TransactionSuccessful : ResponseStatus
{
    public override bool RedirectToErrorPage
    {
        get { return false; }
    }
}
----

When you have more response statuses then I suppose there does become a bit more duplication but it's traded off against the improved ease of use/reading that we get.

It's generally considered good practice to http://www.artima.com/lejava/articles/designprinciples4.html[favour composition over inheritance] and from what I can tell the virtual keyword is only ever going to be useful if you're creating an inheritance hierarchy.

An interesting lesson learned.
Pair Programming: It's not about equal keyboard time
Date: 2009-05-23 16:35:56

My colleague http://ca.rroll.net[Nick Carroll] recently blogged some ideas about http://ca.rroll.net/2009/05/23/is-your-pair-hogging-the-keyboard/[what to do if your pair is hogging the keyboard], suggesting using a timer which keeps track of how long each person has had at the keyboard as a useful way of ensuring that both people in the pair stay more engaged.

While I can see the thinking behind this I think it is addressing the wrong problem.

From my experience we don't always want to be moving the keyboard between the two people quickly at all times - I have certainly seen times where it makes sense for one person to be spending more time at the keyboard than the other.

A particular example of this is when there is a *difference in experience between the two people* at the particular skills required to complete the task they're working on.

On a project I worked on around 18 months ago I was struggling to stay engaged as the navigator as I didn't really understand what was going on and the half/half split in keyboard time wasn't really helping.

Chatting with a more experienced colleague about this at the time he suggested that when I paired with him he was perfectly happy to spend the majority of the time navigating while I drove so that I could get more understanding around the code base and become more useful to the team.

This colleague was clearly keeping the big picture in mind and I haven't come across a situation since then where someone acted so selflessly for the benefit of the team.

The lesson for me from this situation is that *sometimes it makes sense for the person who can gain most from driving to do so* more frequently.

The other thing I think Nick's post is suggesting is that the only way for you to be engaged in a pair is when you are at the keyboard, which I don't believe to be correct.

The http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/[role of the navigator] shouldn't be underestimated as when it's done well it provides a very good complement to the person driving as that person is taking a bigger picture view of what the pair are working on and ensuring that the code being written is still fitting in with the rest of the system. Dahlia has http://dahliabock.wordpress.com/2009/05/23/pairing-what-to-do-when-youre-navigating/[written an informative post about some of the things that she does when navigating in a pair].

Another idea http://dannorth.net/[Dan] suggested to me is to *commentate on what you think is happening/what the other person is doing at the keyboard* when you're navigating and feeling a bit lost.

I've spent quite a bit of time working with http://luning12.blogbus.com/[Lu Ning] on some Javascript on our project recently and have been trying out this approach there and I think it's helped me to understand things better although clearly it takes a lot of patience from the driver if you take this approach.
Coding: Setters reduce trust
Date: 2009-05-23 15:37:34

I've written previously about my dislike of the way the http://www.markhneedham.com/blog/2009/02/16/c-object-initializer-and-the-horse-shoe/[object initialiser is misused in C# 3.0] and although I've also written about my preference for http://www.markhneedham.com/blog/2009/02/28/coding-implicit-vs-explicit-modeling/[explicit modeling] and the need for http://www.markhneedham.com/blog/2009/03/04/coding-good-citizens/[objects to act as good citizens]I've never quite been able to articulate what it is I dislike so much about having setter methods on objects.

I've learnt from experience that it leads to a world of pain in our code by having the ability to setup an object after construction using setters and in a conversation with a colleague about this last week he suggested that the reason it's such a bad practice to follow is that *it makes us lose our trust in not only that object but in all the other objects in the application*.

The thinking here is that if we get caught out (usually by a null pointer exception) when using an object which wasn't completely set up at construction then we are likely to have a seed of doubt in our mind when we come across another object as to whether the same pattern has been followed with that one - we've lost a little bit of our belief that we can just use this object and it will work the way we expect it to.

As a result of that loss of trust we end up spending more time looking at more implementation details of an object just to check how it has been designed to ensure that we don't get caught out.

I don't think this is a particularly useful way to spend our time and it also adds another thing that we have to keep in our mind when looking at code, further dragging us away from the task that we originally intended to do.

Apart from when we're creating http://www.martinfowler.com/bliki/FluentInterface.html[fluent interface] style DSLs I've always felt more pain from using setters than I've gained from that so when I don't see a good reason for them - sometimes Java frameworks might need them (thanks http://dahliabock.wordpress.com/[Dahlia]!) - to exist I pretty much follow http://groups.google.com/group/software_craftsmanship/browse_thread/thread/da5e9c019b559062?pli=1[the boy scout rule] and try and get rid of them.