markhneedham/blog huggingface dataset:
Mercurial: Early thoughts
Date: 2010-04-10 11:43:23

We're using http://mercurial.selenic.com/[Mercurial] as our source control system on the project I'm working on at the moment and since I've not yet used a distributed source control system on a team I thought it'd be interesting to note some of my initial thoughts.

One of the neat things about having a local repository and a central one is that you can check in lots of times locally and then push those changes to the central repository when you want everyone else to get the changes that you've made.

So far we've been pushing much more frequently than would usually be the case using something like http://subversion.tigris.org/[Subversion]. For example I checked in after doing some tidy up on unused references whereas with Subversion I'd probably have included that as part of another checkin.

It actually makes development more fun and reminds me of http://www.markhneedham.com/blog/2009/08/24/rock-scissors-paper-tdd-as-if-you-meant-it/[a kata I did while checking in almost every minute last year].

We're all still very much learning Mercurial but these are some of the commands that we've found ourselves using a lot so far:

* To check if there are any changes to pull from the central repository: ~~~text hg incoming hg in ~~~
* To check if we have any changes that we haven't pushed to the central repository: ~~~text hg outgoing hg out ~~~
* To add any unversioned files and remove any missing files: ~~~text hg addremove ~~~
* To remove a file from the repository and from the file system: ~~~text hg remove /file/name ~~~
* To remove a file from the repository on the next commit but not remove it from the file system: ~~~text hg forget /file/name ~~~
* To pull any changes from the remote repository and update your repository with them: ~~~text hg pull -u ~~~ This one only completely works if you don't have any changes locally on the files you're pulling in. Otherwise you'll need to do a 'hg merge' afterwards. It seems like there's a lot more merging to do when using Mercurial than with Subversion which we're still getting used to but seems to be more natural as we use Mercurial more.
* To undo committing a file locally: ~~~text hg rollback hg ci -X /file/to/not/commit -m"message and so on" ~~~

I've found http://hgbook.red-bean.com/read/[Mercurial: The Definitive Guide] by Bryan Sullivan and Joel's http://hginit.com/[hginit] to be useful resources for learning more about this tool.
Coding: Maybe vs Null Object patterns
Date: 2010-04-10 11:21:30

On the project I'm currently working on my colleague http://christianralph.blogspot.com/[Christian Blunden] has introduced a version of the http://www.haskell.org/all_about_monads/html/maybemonad.html[Maybe] type into the code base, a concept that originally derives from the world of functional programming.

The code looks a bit like this:

[source,csharp]
----

public interface Maybe<T>
{
	bool HasValue();
	T Value();
}
----

[source,csharp]
----

public class Some<T> : Maybe<T>
{
	private readonly T t;

	public Some(T t)
	{
		this.t = t;
	}

	public bool HasValue()
	{	
		return true;
	}

	public T Value()
	{		
		return t;
	}	
}
----

[source,csharp]
----

public class None<T> : Maybe<T>
{
	public bool HasValue()
	{	
		return false;
	}

	public T Value()
	{		
		throw new NotImplementedException();
	}	
}
----

We would then use it in the code like this:

[source,csharp]
----

public FooRepository
{
	public Maybe<Foo> Find(int fooId)
	{
		var foo = LookUpFooFromDatabase();

		if(foo == null)
		{
			return new None<Foo>();
		}
		return new Some<Foo>(foo);
	}
----

[source,csharp]
----

var maybeFoo = fooRepository.Find(1);

if(maybeFoo.HasValue())
{
	// do something with it
}
// fail in misery
----

The benefit we get from using this pattern is that we're explicitly defining in the contract of 'FooRepository.Find' that the method might not return a 'Foo' rather than leaving the callee to work out whether or not they need to check for a null value.

It's effectively the http://msdn.microsoft.com/en-us/library/1t3y8s4s(VS.80).aspx[Nullable pattern] except we can use it for reference types and not just primitives.

An alternative approach which http://twitter.com/dermotkilroy[Dermot] pointed out is the http://en.wikipedia.org/wiki/Null_Object_pattern[null object pattern].

Typically when using that pattern we would treat the result of calling 'FooRepository.Find' the same regardless of whether we get a real 'Foo' or not.

That pattern would work quite well if we have to show a list of items in a grid, for example, and just showed blank cells if there isn't a real 'Foo'.

In our case we want to distinguish between whether we did or did not find a 'Foo' because the application behaves differently if we can't find one. Therefore in this case the null object pattern doesn't work so well.
Coding: FindOrCreateUser and similar methods
Date: 2010-04-09 07:09:28

One of the general guidelines that I like to follow when writing methods is trying to ensure that it's only doing one thing but on several recent projects I've noticed us breaking this guideline and it feels like the right thing to do.

The method in question typically takes in some user details, looks up that user in some data store and then returning it if there is an existing user and creating a new user if not.

It would probably look something like this:

[source,csharp]
----

public class UserService
{
	public User FindOrCreateUser(string username)
	{
		var user = userRepository.FindUserBy(username);
		if(user == null)
		{
			user = CreateUserFrom(username);
		}	
		return user;
	}
}
----

My initial thought when we wrote it was that it seemed wrong but the method name does clearly describe our requirement so I'm not so sure it's a bad thing.

NHibernate has a 'SaveOrUpdate' method which to me seems to cover similar ground although Save/Update are much closer in functionality then Find/Create so maybe that's more justifiable.

I'd be interested to know whether you think this type of method is perfectly fine or whether we're very very bad people for writing it!
hg: Reverting committed changes
Date: 2010-04-15 22:35:53

Continuing with our learning with Mercurial, yesterday we wanted to revert a couple of change sets that we had previously committed and go back to an old version of the code and continue working from there.

As an example, say we wanted to go back to Revision 1 and had the following changes committed:

[source,text]
----

Revision 3
Revision 2
Revision 1
Revision 0
----

My original thought was that we could merge revision 1 with the current tip:

[source,text]
----

hg merge -r 1
----

Sadly that won't work because we can't merge with an ancestor:

[source,text]
----

'abort: can't merge with ancestor'
----

I http://twitter.com/markhneedham/statuses/12189578740[put the question to twitter] and got a few different suggestions.

The first was to use 'revert' and go back to revision 1 like so:

[source,text]
----

hg revert -r 1
----

This works pretty well although http://twitter.com/BestFriendChris/statuses/12190736162[my colleague Chris Turner pointed out that we could also use 'backout'] like so:

[source,text]
----

hg backout -merge 3
hg backout -merge 2
----

The neat thing about that approach is that we get 2 changesets checked in showing the reversing of the changes that we previously checked in. We therefore have a http://twitter.com/BestFriendChris/statuses/12191376829[better history of what exactly we're reverted].

With this approach we could also back out changes which weren't right near the tip of the repository as was the case in my example.

Another alternative is to clone the repository from the revision that we want to keep:

[source,text]
----

hg clone -r 1
----

With this approach we would lose the history of anything beyond that revision but if that's what we want then it's another approach to achieve our goal!

It'd be interesting to hear your opinions on which approach you take and if there are any others to solve the problem I described.
F#: The 'defaultArg' function
Date: 2010-04-12 18:21:41

While reading through http://codebetter.com/blogs/matthew.podwysocki/archive/2009/04/13/from-imperative-to-functional-transposing-maps.aspx[an old blog post by Matthew Podwysocki about writing F# code in a functional rather than imperative way] I came across the 'defaultArg' function which I haven't seen previously.

It's quite a simple function that we can use when we want to set a default value if an option type has a value of 'None':

The type signature is as follows:

[source,ocaml]
----

> defaultArg;;
val it : ('a option -> 'a -> 'a) = <fun:clo@0>
----

And the definition is relatively simple:

[source,ocaml]
----

let defaultArg x y = match x with None -> y | Some v -> v
----

We could then use it if we were looking up a key in a dictionary but wanted to return a default value if there wasn't an entry for that key.

For example:

[source,ocaml]
----

let myMap = Map.add "key" "value" Map.empty
let result = defaultArg (Map.tryFind "nonExistentKey" myMap) "default"
> val result : string = "default"
----

This is just another of the utility functions we can use in F# to allow us to keep composing functions even when we can get more than one type of result from another function.
Agile: Slimming down stories
Date: 2010-04-14 22:53:07

On the project I'm currently working on we have several stories around writing the code that does various different calculations based on user input and then shows the results on the screen.

The original assumption on these stories was that we would be looking up the data of the business rules from a local database. The data would be copied across from a central database into that one for this project.

After some discussion about one of the stories, http://twitter.com/christianralph[Christian] pointed out that the only reason that we needed to have that data in the database was so that it would be configurable in production without having to make code changes and redeploy the application.

I'd been working with the assumption that these stories could only be considered done when the data was coming from the database but we've extracted the 'configurability of data' out into another story which the business can choose to prioritise if that's more valuable than other features we're working on.

It didn't even occur to me that we could pull this type of thing out but it seems like a useful approach as part of our drive to deliver the core functionality of the application as quickly as possible.

If we then need to go back and put in the configurability of the data, the lookup of that data is all hidden behind an interface so we shouldn't see too much pain by choosing to delay doing that.
Haskell: parse error on input `='
Date: 2010-04-22 23:35:27

I've been trying to follow the 'http://irekjozwiak.com/entry/2009/06/13/Monads-for-Java-C---programmers.html[Monads for Java/C++ programmers]' post in ghci and getting the following type of error when trying out the code snippets:

[source,haskell]
----

Prelude> a = 3

<interactive>:1:2: parse error on input `='
----

I figured there must be something wrong with my installation of the compiler since I was copying and pasting the example across and having this problem. Having reinstalled that, however, I still had the same problem.

I eventually came across http://greenokapi.net/blog/2007/02/19/chapter-1-of-hudaks-haskell-school-of-expression/[this blog post] which points to a http://ircarchive.info/haskell/2007/2/19/27.html[mailing list thread from a few years ago] where pjd explains that the 'let' construct is required when defining a variable from ghci and wouldn't necessarily be needed in a normal program:

____
*pjd* osfameron: about the ghci thing, you have to prefix definitions with "let" as in: let simple x y z = x * (y + z) *pjd* the reason for this is that ghci is in an implicit do block *pjd* so it's not exactly like top-level haskell
____

We have to use a 'let' in front of any variable/function definitions and then it will work as expected:

[source,haskell]
----

Prelude> let a = 3
3
----

http://book.realworldhaskell.org/read/getting-started.html[According to Real World Haskell]:

____
This syntax is ghci-specific The syntax for let that ghci accepts is not the same as we would use at the "`top level`" of a normal Haskell program.
____
Iron Ruby: 'unitialized constant...NameError'
Date: 2010-04-25 17:27:25

I've been playing around a bit with Iron Ruby and cucumber following http://blog.webintellix.com/2009/10/how-to-use-cucumber-with-net-and-c.html[Rupak Ganguly's tutorial] and I tried to change the .NET example provided in the http://github.com/aslakhellesoy/cucumber/tree/v0.4.2/examples/[0.4.2 release of cucumber] to call a class wrapping Castle's WindsorContainer.

The feature file now looks like this:

[source,ruby]
----

# 'MyAssembly.dll' is in the 'C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.6.4/examples/cs' folder
require 'MyAssembly'
...
Before do
  @container = Our::Namespace::OurContainer.new.Container
end
----

The class is defined roughly like this:

[source,csharp]
----

public class OurContainer : IContainerAccessor
    {
        private WindsorContainer container = new WindsorContainer();

        public SwintonContainer()
        {
            container.RegisterControllers(Assembly.GetExecutingAssembly()).AddComponent<IFoo, Foo>();
           // and so on
        }

        public IWindsorContainer Container
        {
            get { return container; }
        }
    }
----

When I tried to run the feature like so:

[source,text]
----

icucumber features
----

I kept getting the following error:

[source,text]
----

uninitialized constant Our::Namespace::OurContainer (NameError)
C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.6.4/examples/cs/features/step_definitons/calculator_steps.rb:13:in `Before'
----

I've come across a few posts where http://blog.benhall.me.uk/2009/01/rubygems-ironruby-and-systemnet.html[people described the same error] and they all suggested that IronRuby was unable to find the class that I was trying to call in the code.

I decided to try calling another class from the assembly to see if that was the problem but that worked fine so there wasn't a problem with locating the class.

Somewhat by coincidence I was looking at the assembly again in Reflector and tried to look at the constructor of the 'OurContainer' class and was asked to give the location of the 'Castle.Windsor' assembly which it uses internally.

I didn't have that assembly or any of its dependencies in the 'C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.6.4/examples/cs' folder but once I'd included those it all worked fine again!
Small step refactoring: Overload constructor
Date: 2010-04-25 22:48:37

I've previously written about some approaches that I've been taught with respect to http://www.markhneedham.com/blog/2010/02/24/refactoring-small-steps-to-pull-out-responsibilities/[taking small steps] http://www.markhneedham.com/blog/2009/05/26/refactoring-removing-duplication-more-safely/[when refactoring code] and another approach which a couple of colleagues have been using recently is the idea of *overloading the constructor* when refactoring objects.

On a couple of occasions we've been trying to completely change the way an object was designed and changing the current constructor would mean that we'd have to change all the tests against that object before checking if the new design was actually going to work or not.

Given a simple example where we want to change the following object to take in a completely different type and not use 'field1' or 'field2' anymore:

[source,csharp]
----

public class Foo
{
	public Foo(string field1, int field2)
	{
		// and so on
	}
}
----

One approach would be to change that constructor to take in the extra parameter and then gradually phase out the other parameters:

[source,csharp]
----

public class Foo
{
	public Foo(string field1, int field2, Bar bar)
	{
		// and so on
	}
}
----

An alternative is to create another constructor and leave the old one as it is before changing the tests one by one to make use of the new approach.

[source,csharp]
----

public class Foo
{
	public Foo(string field1, int field2)
	{
		// we gradually phase this one out
	}

	public(Bar bar)
	{
		// the new constructor
	}
}
----

Even if we want to still use 'field1' and 'field2' we can still make use of this approach and just default the extra value until we've migrated our tests across.

[source,csharp]
----

public class Foo
{
	public Foo(string field1, int field2, Bar bar)
	{
		// and so on
	}

	public Foo(string field1, int field2) : this(field1, field2, new Bar())
	{
	}
}
----

I quite like this approach as it allows us to keep the code compiling while we're making changes to it to improve the design.

The main thing to remember with this approach is not to keep the old approach around for too long and to make sure we move our code across to use the new approach as quickly as possible otherwise it can become very confusing for other pairs which come across the code in this half way state.
Coding: The Kestrel
Date: 2010-05-03 00:28:04

Reg Braithwaite has a http://github.com/raganwald/homoiconic[cool series of posts where he covers the different combinators] from Raymond Smullyan's 'To Mock a Mockingbird' book and one of my favourites is the http://github.com/raganwald/homoiconic/blob/master/2008-10-29/kestrel.markdown#readme['Kestrel' or 'K Combinator'] which describes a function that returns a constant function.

It's described like so:

[source,text]
----

Kxy = x
----

The Kestrel function would take in 2 arguments and return the value of the first one. The second argument would probably be a function that takes in the first argument and then performs some side effects with that value.

Braithwaite descirbes the 'returning' function from Rails as an example of this combinator whereby instead of writing code like this:

[source,ruby]
----

def registered_person(params = {})
  person = Person.new(params.merge(:registered => true))
  Registry.register(person)
  person.send_email_notification
  person
end
----

We can write this:

[source,ruby]
----

def registered_person(params = {})
  returning Person.new(params.merge(:registered => true)) do |person|
    Registry.register(person)
    person.send_email_notification
  end
end
----

i.e. we can group all the side effects together and it's more obvious to the reader that we're returning the value of 'Person.new(...)' from this method.

I've been writing a bit of code in F# to generate some test objects and I realised that I had code like this in a few places:

[source,ocaml]
----

let build (t:Type) =
      let theType = Activator.CreateInstance(t)
      theType.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null))
      theType
----

We're creating 'theType' and then mutating it straight away using reflection before returning the value.

We can implement a 'returning' function like so to simplify the code a little:

[source,ocaml]
----

let returning t f = f(t); t
----

[source,ocaml]
----

let build (t:Type) =
    returning (Activator.CreateInstance(t)) (fun t ->
        t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))
----

I think this is the same as what Martin Fowler refers to as a http://martinfowler.com/dslwip/NestedClosure.html[nested closure] and it seems quite a neat way of encapsulating side effects and making the code a bit more expressive.
F#: The Kestrel Revisited
Date: 2010-05-04 18:36:58

A couple of days I wrote about http://www.markhneedham.com/blog/2010/05/03/coding-the-kestrel/[a 'returning' function] that I'd written to simplify a bit of F# code that I've been working on.

It's defined like so:

[source,ocaml]
----

let returning t f = f(t); t
----

And can then be used like this:

[source,ocaml]
----

let build (t:Type) =
    returning (Activator.CreateInstance(t)) (fun t ->
        t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))
----

While I quite like this function it didn't quite feel like idiomatic F# to me.

With idiomatic F# we would tend to design our functions in such a way that we can pipe data through a series of them by making use of the http://www.markhneedham.com/blog/2009/01/06/f-forward-operator/[forward] or http://www.markhneedham.com/blog/2009/01/12/f-partial-function-application-with-the-function-composition-operator/[function composition operators].

With that idea in mind I decided to try switching the arguments to 'returning' around and renaming it so that the code would read more naturally:

[source,ocaml]
----

let andApply f t = f(t); t
----

[source,ocaml]
----

let build (t:Type) =
    Activator.CreateInstance(t) |>
    andApply (fun t ->  t.GetType().GetProperties() |> Array.iter (fun p -> p.SetValue(t, createValueFor p, null)))
----

[cols=2*]
|===
| We partially apply the 'andApply' function to create a new function which takes in a type which is provided on the left hand side of the '
| >' operator.
|===

I think this now reads better than the original version.

What I find interesting is that when writing functions which I intend to be used like this the way I name them is different and the name only makes sense if it's used in that context.

Using the 'andApply' function on its own without making use of partial function application wouldn't read as cleanly as it does at the moment.
Coding: Make the mutation obvious
Date: 2010-05-04 18:32:28

Although I'm generally quite opposed to coding approaches whereby we mutate objects, sometimes the way a framework is designed seems to make this a preferable option.

We came across a situation like this last week when we wanted to hydrate an object with data coming back from the browser.

The signature of the action in question looked like this:

[source,csharp]
----

public class SomeController
{
	public ActionResult SomeAction(string id, UserData userData)
	{
	}
----

We were able to automatically bind most of the values onto 'UserData' except for the 'id' which was coming in from the URL.

We could have included the 'id' in a hidden field in the page to get around this problem but that seemed like a more complicated/hacky solution.

Instead what we needed to do is the following:

[source,csharp]
----

public class SomeController
{
	public ActionResult SomeAction(string id, UserData userData)
	{
		userData.Id = id.ParseIntoId();
	}
----

'ParseIntoId' is an extension method which converts a string representation of an 'id' into an object representation.

While this method is fine as it is, I find that as code gets added it can sometimes be less than obvious that we've actually mutated 'UserData' so I now prefer to explicitly call that out like so:

[source,csharp]
----

public class SomeController
{
	public ActionResult SomeAction(string id, UserData userData)
	{
		var userDataWithId = UpdateUserDataWithId(userData, id);
	}

	private UserData UpdateUserDataWithId(UserData userData, string id)
	{
		userData.Id = id.ParseIntoId();
		return userData;
	}
----

We would then want to use 'userDataWithId' after this point in the function.

Of course the original 'UserData' has still been mutated and it doesn't seem worth the extra code that it would take to avoid this so we'll just trust that anyone reading the code would realise that they should use 'userDataWithId' instead!