Phillip Trelford's Array

POKE 36879,255


Last weekend I set about mining all the links from Alvin Ashcraft's Morning Dew excellent link blog site which has been documenting .Net goings on since 2007.

In the back of my mind was the idea of applying some machine learning techniques to automatically generate blog article recommendations using the labelled links as training data. Each link in Alvin's site has a date, category, title and author.

I took 2 passes:

  • programmatically find all the post urls
  • parse the HTML posts using the HTML Agility pack to extract labelled links

I now have a CSV file with over 80K links – that’s a lot of reading from Alvin.

This week I've been manually running queries over the dataset like top N authors in a category by volume of posts. One of the most historically prolific bloggers I found was Davy Brion who has some really interesting material. One article I particularly enjoyed was the Advantages Of Being A Polyglot Programmer from 2011 which describes part of his journey from a C# developer focused on one platform/language and dependent on Visual Studio and Resharper, to learning new languages like Ruby, JavaScript and Haskell and using strong text-editors like TextMate and Sublime Text 2.

It struck accord with me and quite a lot of the people I shared it with on Twitter:

I also posted some quotes from the article including:

This is one of the responses:

It reminded me of a recent vociferous exchange I'd seen on Twitter:

Judging by those comments as I’m not using Resharper when writing C# I must be "silly", "stupid" and "retarded".

Seriously though, this is not the first heated discussion around Resharper, and name calling doesn't feel like a grown up way to have a discussion, wouldn't it be better if we could just agree to disagree and live and let live.

So why am I not using Resharper?

The short answer is that I want to like Resharper and I've tried it a number of times, but each time I've found it overly intrusive in my workflows and ended up uninstalling it after a few days. If Resharper works for you though, honestly I'm happy for you. Even though I don't use Resharper, it doesn't mean I don't use or like tools, I use TestDriven.Net to run my unit tests, REPLs for getting quick feedback and I've been happily using the built-in basic refactoring tools in Visual Studio since they were introduced way back in 2005.

Longer answer

C# is not the only language I program in, you can also find me happily coding in C++, JavaScript, Python, Erlang and F#. Because of this I tend to favour simple workflows that work across languages, for example as Davy Brion describes I find "Find in Files" searches work pretty well, along with Visual Studio 2012's new search in solution explorer.


Code smells

Back in 1999 Martin Fowler wrote about the idea of code smells in his Refactoring book. I consider finding myself typing the same thing over and over or jumping back and forth through the source code frequently, both as good forms of discovery of code smell. The former of code duplication, the later of high coupling. From bitter experience, instead of making code duplication easier through code generation, and code coupling easier through navigation tools, I want to get strong early signals of the problem and tackle it head-on before it gets out-of-control. That said there are times when both code generation and navigation tools can be handy too, and yet others when they feel more like I'm taping over gaping wounds with temporary bandages.

Step away from the tools

Sometimes when I’m stuck in the debugger for a while, I begin to feel like a gambler who’s trying to gamble his way out by doubling down instead of cutting their losses and walking away. Sometimes the best way to solve a problem is to step back from it and take some time to think about it (picture via Edwin Brady):


And sometimes the solution isn't easily found in the code or the tool, but rather from stepping back and taking time to discuss it with your co-workers.

F# in the Enterprise

Last night I popped down to Southampton to talk about F# in the Enterprise at the Developer South Coast meetup started by John McLoughlin. The group has grown quite a bit since last time I was down in 2010, and the hall was packed with about 50 members. It’s a really friendly group with a lot of interesting activities going on including hack weekends covering everything from electronics all the way through to games programming.

John contacted me after interest in a deep dive session on F# from the group.


At the start I covered a selection of testimonials captured on the F# Foundation site which gives some idea of where people are applying F# and the kind of benefits they’re seeing. .Net Rocks is another good source featuring interviews with F# developers talking about their experiences on projects, most recently Yan Cui from GameSys and Kit Eason on F# in Insurance.

order of magnitude increase in productivity, GameSys

performance is 10× better than the C++ that it replaces, Aviva

Take a look for yourself:


The F# community has a strong testing focus with plenty of posts and libraries on the subject. As F# is a .Net language it works with all the regular .Net testing frameworks including NUnit, xUnit and MsTest:

open NUnit.Framework

let [<Test>] ``2 + 2 should equal 4`` () =
    Assert.AreEqual(4, 2 + 2)

Or using the popular FsUnit library you can make your assertions fluent:

let ``2 + 2 should equal 4``() =    
    2 + 2 |> should equal 4

Stephen Swensen’s Unquote library takes a novel approach:

let [<Test>] ``2 + 2 = 4`` () =
    test <@ 2 + 2 = 5 @>

If a test fails unquote can help you uncover what went wrong:

Test 'Tests.2 + 2 = 4' failed: 

2 + 2 = 5
4 = 5

FsCheck a library based on QuickCheck is another F# library worth a look. FsCheck lets you fuzz test your functions which can help find those bugs that are harder to uncover with hand written unit tests. FsCheck can also be called from C#:



Dependency injection (DI) is commonly employed in enterprise C# code. DI can make code more testable by injecting dependencies as interfaces to a class’s constructor:

public class HolidayService
    private readonly IFlightBooking _flights;
    private readonly IVillaBooking _villas;

    public HolidayService(IFlightBooking flights, IVillaBooking villas)
        _flights = flights;
        _villas = villas;

    public bool CanBook(DateTime date)
        return _flights.Available(date) && _villas.Available(date);

This can be expressed in F# as a class type:

type HolidayService(flights:IFlightBooking,villas:IVillaBooking) =
    /// Returns can book status
    member this.CanBook(date:DateTime) =       
       flights.Available(date) && _villas.Available(date)

The F# code generates the same IL as the C# code and works with all the major .Net dependency injection frameworks. I’ve personally used both Castle Windsor and more recently AutoFac.

If you’re using interfaces or abstract classes to inject dependencies you can provide mock instances when you test. This can be useful if for example you have code that interacts with a database or uses the current time.

F# 3 works seamlessly with all the major .Net mocking libraries like Rhino Mocks and Moq. If you’re looking for something that takes advantage of F#’s type inference features you might want to try out my imaginatively named Foq library which has a similar API to Moq:

let [<Test>] ``on no flights available you can't book`` () =
    let flights = 
            .Method(fun x -> <@ x.Available @>).Returns(false)
    let service = HolidayService(flights, mock())

That said it’s pretty easy to create an instance of an interface using F# built-in object expressions, so for many tasks a library is not needed:

{ new IDisposable with member __.Dispose() = printf "Disposed" }

And if you have interfaces with a single method you may just as well pass a function:

type HolidayService(hasFlight:DateTime->bool, hasVilla:DateTime->bool) =
    /// Returns can book status
    member this.CanBook(date:DateTime) = hasFlight(date) && hasVilla(date)

Type Providers

Type Providers are a feature unique to F# introduced in F# 3, that enable easy typed access to diverse data like databases, web services and even programming languages. In the presentation I showed Tomas Petricek’s World Bank sample running in Zach Bray’s FunScript. FunScript gives typed access to JavaScript libraries via a Type Provider to TypeScript and compiles F# code to JavaScript. The 80 line sample uses jQuery and HighCharts to show data pulled from the World Bank:


For more example’s check out Don’s 12 Type Providers in pictures post.


Thanks for all the great feedback on Twitter (here's just a few):


If you’re interested in learning F# I’d highly recommend the F# Koans and the online tutorials on the Try F# site:


Also check out the Progressive F# Tutorials in New York this September and London in late October:

Progressive FSharp Tutorials

We Jammin’

Last weekend I teamed up with other gamers for the Creative Assembly game jam at Rezzed. We had 9 hours to create a game, and were given the theme of the 80s at 9am on the Saturday morning. After some brainstorming we came up with the idea of a platform game that became an endless runner with rhythm and puzzles called We Jammin’:


The main character is a skateboarder, collecting 80s artefacts to build up the volume on each track, while hitting mental blocks depletes the volume. All 4 tracks must reach the required volume level to complete a level:


Here's a short video of the game running in Unity:


Here’s the game presentations made to a packed audience on the Sunday afternoon (skip to 26:20 for We Jammin):

We had a lot of fun making the game and it was a great experience, particularly for my 11yo son Thomas who created sound effects and the base line for the game.

If you’d like to have a go at making a game in a day, check out London GameCraft, a free one day game jam at Skills Matter on Saturday the 10th August: