Brighton ALT.NET show and tell night videos

Back on the 1st February we had a show and tell night at Brighton ALT.NET – Thanks to Keith Bloom, who brought his video camera along and then went through the painful process of uploading them all to Vimeo, we can now present the show and tell videos:

Steve Mason - N2 CMS

A quick tour of the best open source CMS on the planet. Homepage - http://n2cms.com/ Source code - http://github.com/n2cms/n2cms/ (the Google code & codeplex repositories are old & unused) Discussions - http://n2cms.codeplex.com/discussions

Andrew Cherry - Socket Machine

A .NET server toolkit that you can use to build any socket based server on .NET with a very nice fluent API. The source will be opened up soon on Github, for now follow @socketmachine - announcements etc. will always be there from now on. Code will be published under the xyncro org on Github (https://github.com/xyncro) but be aware that there is nothing currently there now - this is intentional.

Jay Kannan - Kinect in .NET

Using the Kinect to control .NET applications. the demo concentrated on a Game Environment using the XNA platform and 3D physics for creating and bouncing bubbles around the screen. a long way to go to make it usable. the Kinect is clearly the best Augmented reality / motion control platform of choice for Kiosk makers and for public user interaction. look at the links below for more information. Kinect Hacks. PrimeSense OpenNI - this is the official library from the CHipset guys that I'm using. OpenKinect. Code Laboratories.

Michael Steele - Netduino

blog My introductory blog for netduino - will update with the burglar alarm & operation game
Netduino forum
.Net Micro Framework
tinyclr Fez community website - Another board running .Net Micro Framework
Scott Hanselman Micro Framework/Netduino podcasts
Build Brighton meet every Thursday at The Skiff to tinker with electronics.

Me - Monads in C#

This is a very compressed, and probably meaningless 15 minute version of my hour long DDD9 talk. Session code on github. The Monad Wikipedia page is excellent, if somewhat intimidating. The references and external links are an excellent starting point for further investigation.

Paul Hazells - Can twitter predict the stock market?

Unfortunately, Keith's video recorder died by this point, so we don't have Paul's excellent session. Very sorry Paul. But here are the links:

http://aws.amazon.com/free/ - AWS Free Usage Tier
http://nodejs.org/ - node.js
https://github.com/isaacs/npm - npm (node package manager)
https://github.com/technoweenie/twitter-node - twitter-node
https://github.com/indexzero/forever - forever
http://omnipotent.net/jquery.sparkline/ - sparklines (for the graphs)
http://html5boilerplate.com/ I forgot to mention the HTML5 boilerplate which I've also used. I saw a few of the group at the DDD9 talk on this so thought it might be of interest. I'd definitely recommend it for new projects, especially if you need to support older browsers.

If you have any questions or comments, please do not hesitate to ask me either at a meeting or via twitter: @paulhazells

Monads in C#-8. Video of my DDD9 Monad talk

This is the eighth part of my Monad series. See the introduction for a list of all the posts.

You can find the code for this post on GitHub here.

Last month I gave a talk at DDD9 loosely based on this series: Monads! What are they and why should I care.

Note: The talk (and audio) starts at 6 minutes into the video.

Mike Hadlow - Monads! What are they and why should I care? - DeveloperDeveloperDeveloper 9 from Phil Winstanley on Vimeo.

Enjoy!

Delegates make great container components

The problem with object oriented languages is that you often have to wrap up single functions in a class even when there’s no real reason for that class to exist. This is especially true for many ‘service’ classes. For example, for a long time I used to have something like this in most of my projects:

public interface IDateProvider
{
    DateTime Now();
}
public class DateProvider : IDateProvider
{
    public DateTime Now()
    {
        return DateTime.Now();
    }
}

I would register my DateProvider with Windsor like this:

container.Regisgter(
    Component.For<IDateProvider>().ImplementedBy<DateProvider>()
);

Being able to set the current time in unit tests is essential if you’re doing any kind of logic that does date computations, and this served me well. But it’s a lot of boiler plate just to get the current date. It also means that I have to build a mock IDateProvider for my unit tests and set stubs on it – more irritating boiler plate.

But C# is also quite a good functional language and Windsor deals with delegates just as easily as it deals with interfaces. These days I no longer have an IDateProvider, but just a simple delegate:

public delegate DateTime Now();

Which I register like this:

container.Register(
    Component.For<Now>().Instance(() => DateTime.Now),
    );

Now any component that needs to know the current DateTime value simply has a dependency on the Now delegate:

public class MyComponent
{
    private readonly Now now;
    public MyComponent(Now now)
    {
        this.now = now;
    }
    public void DoSomething()
    {
        var currentTime = now();
        ....
    }
}

And it’s really easy to stub out for unit tests:

var now = new DateTime(2010, 2, 15);
var myComponent = new MyComponent(() => now);
myComponent.DoSomething();

This is also a great way for providing infrastructure services when your infrastructure isn’t IoC container friendly. How about this:

public delegate string CurrentUser();

...

container.Register(
    Component.For<CurrentUser>().Instance(() => HttpContext.Current.User.Identity.Name)
    );

In some ways delegates are more flexible than interfaces since you don’t have to declare that a particular lambda or method implements the delegate, so long as the signature matches you’re good.

Indeed, if Windsor did currying we could probably remove most of our service classes and simply write our software as static methods. But that’s another blog post ;)

Using Git alongside other version control systems

I love Git. If you haven’t yet discovered the awesomeness of distributed version control, you are really missing out. Git is now the version control system of choice for a huge number of open source projects. That’s probably got a lot to do with GitHub, the best cloud based version control system on the planet, but the ease with which you can branch and merge with Git is also a major factor.

But even if you’re not building open source software development in the cloud, even if you’re stuck in some enterprise shop with TFS, you can still use the power of Git’s branching and merging to help you get your work done. Because Git is a distributed version control system it makes it trivial to set up a local repository. You can use that local repository create small local branches for particular features and to help you merge them together before you make a big check-in to your corporate VCS.

The trick to getting Git to work well in this scenario is to make sure that Git and your main VCS ignore each other.

For example, I’m still using subversion and Google Code for Suteki Shop. Yes, I know I should move it over to Git and GitHub, but I’m lazy and I quite like the Google Code project page, so I haven’t had the time or the inclination to do it yet. But I use Git locally to manage small changes. To get Git and subversion to ignore each other is pretty easy. Git places its repository in a folder in the root of your project called ‘.git’. I just ask subversion to ignore that folder. Using TortoiseSVN you do it like this:

Getting Git to ignore subversion is similarly easy. Subversion tracks its status using files in an ‘.svn’ folder in each folder under source control, so I simply add ‘.svn’ to my .gitignore file:

Here’s my .gitignore file:

[Oo]bj
[Bb]in
*.user
*.suo
*.[Cc]ache
*.bak
*.ncb
*.log 
*.DS_Store
[Tt]humbs.db 
_ReSharper.*
.svn

I’m currently working on a stock control addin for Suteki Shop. While I was writing it I came across a bad design choice that I made in the past that stopped me from being able to properly decouple my addin from the core Suteki Shop project. Rather than executing a large refactoring directly in my stock control branch, I created a new branch from master, refactored away my bad design, tested it, merged it back into master and committed it to svn without having had to change or commit my in-progress work on stock control.

This ability to go off on tangents without one piece interfering with another is very powerful. It gives you the confidence to make very radical experimental changes that would have seemed like too much of a commitment previously.

Monads in C#-7. Turning our parser into a Monad

This is the seventh part of my Monad series. See the introduction for a list of all the posts.

You can find the code for this post on GitHub here.

Do you remember our parser delegate from part 6? If you haven’t read it yet, I’d recommend reviewing it now before reading the rest of this post.

public delegate Maybe<Tuple<T, string>> Parser<T>(string input);

Remember the pain we had to go through to combine these parsers? Let’s try a different approach by turning our parser into a Monad. Up to now we’ve just looked at turning classes or interfaces with a single type parameter into Monads, but we can do just the same with a delegate.

First let’s write a ToParser method. It’s pretty easy we just return a parser that returns our item without consuming any of the input string:

public static Parser<T> ToParser<T>(this T value)
{
    return s => new Just<Tuple<T, string>>(Tuple.Create(value, s));
}

Next we need a Bind method. This is a little harder to write, but if we ‘follow the types’ it appears relatively painlessly. Let’s think about the signature of bind, remember this is the same for any Monad:

public static Parser<B> Bind<A, B>(this Parser<A> a, Func<A, Parser<B>> func){}

Now we’ll digest the signature step by step. First let’s look at the return type: Parser<B>.  Remember Parser<B> is a function from a string to a Maybe<Tuple<B, string>>, so we need to return a lambda for that function:

public static Parser<B> Bind<A, B>(this Parser<A> a, Func<A, Parser<B>> func)
{
    return s =>
    {
        // ...
    };
}

That lambda needs to return a Maybe<Tuple<B, string>>, we can get one of those by invoking func, getting the returned Parser<B> and invoking that:

public static Parser<B> Bind<A, B>(this Parser<A> a, Func<A, Parser<B>> func)
{
    return s =>
    {
        var bParser = func( ??? );
        return bParser( ??? );
    };
}

We need an A to pass to func and we can get one of those by invoking the a parser, getting it’s return value and grabbing the A from that:

public static Parser<B> Bind<A, B>(this Parser<A> a, Func<A, Parser<B>> func)
{
    return s =>
    {
        var aMaybe = a(s);
        var aResult = aMaybe as Just<Tuple<A, string>>;
        
        // short circuit if parse fails
        if (aResult == null) return new Nothing<Tuple<B, string>>();

        var aValue = aResult.Value.Item1;

        var bParser = func(aValue);
        return bParser( ??? );
    };
}

Notice how we short circuit the parse if the a parser fails. This means that any combination of parsers will return Nothing if any one of them can’t parse its part of the input string.

Lastly we need a string value to feed to our bParser, which we can get from the a parser result:

public static Parser<B> Bind<A, B>(this Parser<A> a, Func<A, Parser<B>> func)
{
    return s =>
    {
        var aMaybe = a(s);
        var aResult = aMaybe as Just<Tuple<A, string>>;
        
        // short circuit if parse fails
        if (aResult == null) return new Nothing<Tuple<B, string>>();

        var aValue = aResult.Value.Item1;
        var sString = aResult.Value.Item2;

        var bParser = func(aValue);
        return bParser(sString);
    };
}

That’s it, we have built a Monadic parser. To use it with Linq syntax we need to write a SelectMany, but that’s a mechanical operation because we already know what it looks like, it’s exactly the same as the Ident<T> SelectMany and the Maybe<T> SelectMany that we’ve already written, except with Parser<T> substituted:

public static Parser<C> SelectMany<A, B, C>(this Parser<A> a, Func<A, Parser<B>> func, Func<A, B, C> select)
{
    return a.Bind(aval => func(aval).Bind(bval => select(aval, bval).ToParser()));
}

Now we can write our little Hello World parser in three lines of code:

var helloWorldParser =
    from hello in "Hello".Find()
    from world in "World".Find()
    select new {Hello = hello, World = world};

var result = helloWorldParser("HelloWorld");

Console.WriteLine(result.AsString(x => x.Hello));
Console.WriteLine(result.AsString(x => x.World));

// outputs 
// Hello
// World

That is a thing of beauty.

Hopefully you can start to see how Monads can let you simply build some very complex systems.

If you want to dig deeper into Monadic parsers, Nicholas Blumhardt has a very nice implementation called Sprache.

Happy Parsing!

AsmSpy: A little tool to help fix assembly version conflicts

Do you ever get these kinds of messages when you compile your project?

------ Build started: Project: Suteki.Shop.CreateDb, Configuration: Debug x86 ------
No way to resolve conflict between "System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
and "System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". 
Choosing "System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" arbitrarily.
Consider app.config remapping of assembly "NHibernate, Culture=neutral, PublicKeyToken=aa95f207798dfdb4" 
from Version "3.0.0.2001" [] to Version "3.0.0.4000" 
[D:\Source\sutekishop\Suteki.Shop\packages\NHibernate.3.0.0.4000\lib\NHibernate.dll] to solve conflict and get rid of warning.
Consider app.config remapping of assembly "System.Web.Mvc, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
from Version "2.0.0.0" [C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 2\Assemblies\System.Web.Mvc.dll] to Version "3.0.0.0" 
[C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies\System.Web.Mvc.dll] to solve conflict and get rid of warning.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3247: 
Found conflicts between different versions of the same dependent assembly.
Suteki.Shop.CreateDb -> D:\Source\sutekishop\Suteki.Shop\Suteki.Shop.CreateDb\bin\Debug\Suteki.Shop.CreateDb.exe

The problem is that the build output doesn’t tell me which of my assemblies references version 2.0.0.0 of System.Web.Mvc and which references version 3.0.0.0.

If you’re writing software using lots of 3rd party assemblies like I do, it’s a constant problem. I’ve written a little bit of code that I drag around with me that outputs lists of assemblies that my assemblies reference. I’ve found it very useful for resolving these kinds of issues.

Now I’ve wrapped it up as a little console app, AsmSpy, and put it on github here:

https://github.com/mikehadlow/AsmSpy

Or you can download a zip file of the compiled tool here:

http://static.mikehadlow.com/AsmSpy.zip

How it works:
Simply run AsmSpy giving it a path to your bin directory (the folder where your project's assemblies live). E.g:

AsmSpy D:\Source\sutekishop\Suteki.Shop\Suteki.Shop\bin

It will output a list of all the assemblies referenced by your assemblies. You can look at the
list to determine where versioining conflicts occur.
 
The output looks something like this:

....
Reference: System.Runtime.Serialization
3.0.0.0 by Microsoft.ServiceModel.Samples.XmlRpc
3.0.0.0 by Microsoft.Web.Mvc
4.0.0.0 by Suteki.Shop
Reference: System.Web.Mvc
2.0.0.0 by Microsoft.Web.Mvc
3.0.0.0 by MvcContrib
3.0.0.0 by MvcContrib.FluentHtml
3.0.0.0 by Suteki.Common
2.0.0.0 by Suteki.Common
3.0.0.0 by Suteki.Shop
2.0.0.0 by Suteki.Shop
Reference: System.ServiceModel.Web
3.5.0.0 by Microsoft.Web.Mvc
Reference: System.Web.Abstractions
3.5.0.0 by Microsoft.Web.Mvc
....

You can see that System.Web.Mvc is referenced by 7 assemblies in my bin folder. Some reference
version 2.0.0.0 and some version 3.0.0.0. I can now resolve any conflicts.

The MVC 3.0 IDependencyResolver interface is broken. Don’t use it with Windsor.

I’ve been spending today moving Suteki Shop to MVC 3. One of the cool new features of MVC 3 is a much greater focus on allowing the various components (Controllers, Views, Filters etc) to be composed by an IoC container. It’s been possible since MVC 1 to provide your own custom controller factory, but the promise with MVC 3 is that you can provide an implementation of IDependencyResolver that wraps your IoC container of choice, and no longer have to bother about implementing various factory classes.

Here’s IDependencyResolver:

public interface IDependencyResolver {
    object GetService(Type serviceType);
    IEnumerable<object> GetServices(Type serviceType);
}

But there’s a huge problem with this. Can you spot it? That’s right, no ‘Release’ method. You can provide a service from your IoC container, but there’s no way to clean it up. If I was going to use this in Suteki Shop, I would have a memory leak of epic proportions.

According to the MVC team, this isn’t an issue because they will call ‘Dispose’ on any service that implements IDisposable, but that won’t work in many cases. Let me explain. Say I’ve got a controller like this:

public class HomeController : IController
{
    private readonly ICustomerRepository customerRepository;
    public HomeController(ICustomerRepository customerRepository)
    {
        this.customerRepository = customerRepository;
    }
    // ... does some stuff with customerRepository
}

My controller doesn’t implement IDisposable. So no Dispose method gets called.

 

Now say this is my implementation of ICustomerRepository:

 

public class CustomerRepository : ICustomerRepository, IDisposable
{
    // ... etc
}

CustomerRepository does implement IDisposable. But the MVC framework doesn’t know this, indeed my HomeController doesn’t know it either. That’s the whole point of using an IoC container in the first place, it worries about component lifecycles, not the client service. If I resolve HomeController from Windsor it will create all its dependencies and if it finds any that implement IDisposable it will track the entire dependency graph. If I then call ‘Release’ on my HomeController instance, Windsor will know to dispose of CustomerRepository correctly. But if Release is never called CustomerRepository will never get disposed and my web application will gradually consume more and more memory, database connections, file handles, or whatever should have been cleaned up when Dispose gets called.

 

Krzysztof Kozmic has a great post here about how Windsor tracks components. It’s a ‘must read’ if you’re a Windsor user.

 

So the upshot is that all this nice new work in MVC3 is unusable, certainly with Windsor. It’s also a very dangerous trap for the unwary. My advice is that you shouldn’t implement an IDependencyResolver for Windsor. I don’t know how other IoC containers handle releasing components deep in their dependency graph, but I would make sure you understand exactly how they work before going down this route.