If you go to the root of your solution and run the command below from PowerShell it should clear the contents of all of them, then a quick clean/rebuild from the IDE gets it up and running again.

get-childitem .\ -include *.licx -recurse | foreach ($_) {set-content $_.fullname $null }

Hope that helps someone else :)

The App

Along side last years features of the full schedule, the ability to select sessions and see a personalised schedule, I’ve added some new Twitter related related features, these include:

• #DDDNorth Twitter Search Alongside the schedule and your personalised schedule is a search of twitter for the DDDNorth hashtag so you can keep with what everyone is saying!
• Halo Tweet When you first launch the app you see one of the last ten tweets from the #DDDNorth hashtag.
• Auto Schedule Update the app now has the ability to check for schedule updates (handy as DDDNorth still has TBC sessions).

Again nothing fancy and completely unoffical so please redirect all queries/complaints to me and not the excellent DDDNorth team.

You can download it from here.

My Session

My session this year is called “Test All The Things Or Maybe Not” and I want to talk through my experiences of unit testing. From complete beginner who took the advice literally to where I am today. Where is that? With hard won battle scars from poor, difficult to maintain and flaky unit tests.

I’m not trying to be an expert, but I hope people starting out will avoid making the same mistakes I did and others will realise it’s OK to break the rules :)

When choosing a new way to host it I looked at Heroku and GitHub pages but neither (at the time of writing) offered redirects without hitting Ruby middleware and I wanted to keep my old links working. So I choose to host it myself and serve it up using Nginx.

I found a number of posts on how to make the move but none covered how to deal with links or comments. So I thought I’d document the steps I took and hope it help others.

1) Goto the Octopress site and follow the directions to get up and running.

2) Setup Disqus for your current Wordpress blog and import all the comments (this can take a while).

3) Export all your posts from the Wordpress admin area and then run exitwp to convert all your posts to markdown. It might choke at this point on the XML so it’s just a case of fixing the errors and trying again

4) Run through all your posts and fix them, the Wordpress editor and Windows Live Writer produce some interesting output that doesn’t convert to well.

5) Run wp2oct-links with the exported XML to generate nginx rewrite rules for all your old urls and add them to the nginx conf.

6) Test, deploy, etc then when you’re happy change the DNS over.

7) Go back to Disqus and get it to spider your site and it should update all the links.

That should do it.

Have fun cursing at Markdown :)

So I wrote one for fun using C#, mono 2.10 and Nancy. When looking at the Nancy docs, it is slightly lacking in how to host on Linux so I thought I’d do my bit by writing a quick overview.

Options

There is a couple of options when hosting on Linux, one is to create your Nancy project as a mono ASP.NET project then serve it using xsp (the mono ASP.NET server) and proxying to it or using FastCGI. This is fairly well documented at the mono site and writing a Nancy app using ASP.NET for hosting is also well documented. However, I wanted to take a different approach to try and host it in the minimum amount of RAM on an LEB (LowEndBox), because I have a 256MB Xen Debian VPS just sat around doing nothing.

So to minimise RAM I went for self hosting, using pretty much the stock sample with a slight mod (see below). When self hosting the Nancy app will listen on the loopback address at a specified port so we are going to use Nginx to serve static content and forward all requests to our mono process and use Supervisord to monitor the process.

Pull it all together

For this you’ll need the following installed on the Linux machine:

• Mono 2.10
• Supervisord
• Nginx

The first we’re going to do is configure Supervisord. Supervisord is a process monitoring application that can run any normal process as a daemon and automatically restart it if it crashes. I first came across this when working with Python sites to keep FastCGI processes running. The configuration should look something like:

The important bits are:

• command – this specifies the command believe it or not,
• user – by default supervisord runs all processes as root, this is bad for webapps.
• directory – this sets the working directory, so if you’re app needs anything off disc this needs to be correct.

As I said above I needed to make a tweak to the sample self hosting project. The sample uses Console.ReadLine() to stop the process from exiting, but under Mono when running as a daemon this returns EOF and causes the application to close. So I updated it to sleep (shamelessly stolen from xsp source ):

Moving on we need to configure Nginx. The strength of Nginx is serving up static content quickly so we’re going to intercept all requests for static files and then forward the rest to our Nancy app. The configuration below defines an ‘upstream’ which is typically used for load balancing we can use it here for just forwarding requests. Also note we are intercepting and serving requests for /Content using Nginx. At debug time the default conventions in Nancy will serve this up correctly so we get best of both worlds

How well does it do on our LEB?

Impressively, idle the combination of Debian Sid, Supervisord, Nginx and the Mono process takes up just 37MB of RAM, but the most important question is can it handle load? Beware completely unscientific results below

Lets take a look at hitting one of the json API methods* using ApacheBench (that is bundled with OSX ):

• 1000 continuos requests with a max of 10 concurrent connections peaks memory at 53MB
• 1000 continuos requests with a max of 25 concurrent connections peaks memory at 54MB but 18 out of the 1000 failed with connection reset by peer, which is more the box failing than the app
• 1000 continuos requests with a max of 50 concurrent connections peaks memory at 55MB but my own boardband gave up after 700 connection, clearly not enough upspeed

It’s important to note that this app is one static html page with ajax queries back to a JSON api served by Nancy

Wrapping Up

I hope someone finds my configuration snippets useful and it is worth noting that my LEB (£2.20 a month for 256MB Xen) failed before the my app did, so I find this very encouraging for it’s performance under Mono and Linux.

Source for the link shortener and conf files can be found at https://github.com/Dotnetwill/vfy.be The shortener running on Mono http://vfy.be

Bear in mind I’m not an VCS geek, I’m not going to start talking about how the extensionalist index metabear does not quite model that of the intrinsically 4D nature of time and application architecture. This is just how I get on with it while trying to get shit done.

I’m only going to cover the two parts we use, source control and build management.

TL;DR; It has lots promise but sadly missing features and poorly thought functionality severely hamper it.

Editing Files

Let’s cut the crap, working on a file and checking it in is the same in virtually every VCS. And TFS is not exception here, you work away, see your changes, check them in and if there is a conflict you get a diff. Not rocket science and works well enough.

However, this does quickly breakdown if you want edit files outside of Visual Studio (VS). The problem is files need to be “checked out” before you can make edits. If it didn’t happen while it was checked out it, it didn’t happen. I’ve lost count of the number of times I’ve tweaked an XML file, build file, none cs file and done it in Programmers Notepad only to check in and break the CI build because the tweaks have been missed.

Editing and merging csproj or sln files is a complete and utter nightmare and I’ve never understood why.  Let’s face it if you’re using TFS you’re fairly invested in the MS ecosystem so you’re using VS and one of TFS’s big features is integration into VS so why oh why, for the love of God why, can’t TFS parse and merge sln and csproj files? They are MS formats, produced by an MS tool and managed in an MS tool W. T. F.

Merging And Branching

Personally I’ve been completely spoilt by local branching in DVCS (Distributed Version Control System) and I sometimes get lost in what branching means in a more centralised context. In TFS and svn branching can only be done on the server allowing multiple people to work on the same branch. Whereas with DVCS and local branching only you can make edits and commits then when you’re ready to integrate your work with your team you pull the upstream, merge it and push it. So it’s in your best interest to keep the two as close as possible to minimise your own pain.

The more centralised models put the onus on nobody to sync the branch with upstream because somebody, IE not you, will have to do the merge. Many teams will try to manage this through policy to varying degrees of success and lets not forget that it is entirely possible to get into the same mess with DVCS.

For me the secret sauce of branching with DVCS is that it moves the emphasis of the responsibility and management of the branch on to the individual developer. No amount of nifty features or tooling can make up for the fact that a branch that hasn’t been synced with its parent for 3 weeks and has lots of code churn is going to be a nightmare to merge.

So I don’t think it’s fair to pick on TFS over branching, yes it doesn’t support local branching but at the same time that has the same issues of good branching requiring proactive syncing, thought about management and discipline.

One area where TFS has massively improved recently is in history across branch. Pre-2010 there was no easy way to follow the history of an item cross branch but thankfully this has now been added.

Checking Out, Moving Files and IDE integration

For those that don’t know when you do a pull in TFS every file is readonly by default if you want to edit a file you have to go source control explorer, find it and check it out.  If you have VS integration turned on (and if you don’t you’re a mentalist) it is all quickly taken care of for you when working inside of VS.  There is, of course, an option to make files readable on pull but that only introduces a whole new, more annoying, problem, working out what has actually changed.  There is no “Hey TFS, I’ve change some things figure out what’s different and list them as pending changes for this checkin”, I’ll run that by you again if you don’t check it out TFS doesn’t know what has changed.  This is complete lunacy and is a significant barrier when trying to get shit done.  To be fair, it does have this functionality when your connect goes offline and when coming back online it will look for changes and generally find them.  But there is no way to do this from the IDE normally.

Checking out files is a completely moronic concept.
I said earlier that if it wasn’t checked out it didn’t happen, let me amend that to if didn’t happen inside source control explorer with the correct verb then it didn’t happen.  This is most frustrating with file moves, recently I restructured one of our main solutions splitting several new projects from one monster. I created the new projects then cut and paste the required files via Solution Explorer with TFS integration enabled, expecting TFS to pick up the moves but it did delete/adds and completely f’ed up the merges for everyone else and the history.

For me all this TFS having to be explicitly told what you’re doing shouldn’t be a problem when working in VS, this should be it’s killer feature.  It should be don’t worry just work as normal, TFS is watching and will know what to do but nothing could be further from the truth.

Oh and on moving, you can’t multi select files to move them in source control explorer you either do the whole folder or the files one by one :-/ (I think it’s because “moves” are actually “renames” so it needs to know the filename but WTF)

Shelvesets

Shelvesets on the surface seem a pretty nice feature, it allows you save a copy of your current changes without checking them in.  They get stored centrally so can move between machines and even users, handy if you want a code review or you want to quickly spike something out then share it without checking it in or branching.

Over time I have found the omission of features deeply frustrating. Shelvesets themselves do not have any history, I find this fustrating because the first time I seen them I thought great, I can make changes and have lots and lots of small checkpoints before checking in the finished bits and it doesn’t matter if they don’t build or cause tests to fail.  But nope, shelvesets overwrite each other if they have the same name.

The other use case is using them as a stash, so you’re working away on a feature or a bug and you discover you’re working on the wrong branch or something else high priority comes in so you shelve your current changes. Later you go to unshelve them on another branch so you can finish up, nope can’t do that shelves can’t move cross branch for reasons known only to MS.

Again another should be a killer feature but so widely misses the mark.

Builds

I work for an MS shop so we use MSBuild for builds and TFS build is all MSBuild based so it integrates nicely.  It can schedule builds, run the CI, the build machine setup is a little clunky but it makes sense.  Overall running and managing builds it does a good job.  The only major frustration is notifications.

Not only is it really difficult to set up a notification, the UI is horrendous and none obvious, but if someone has setup a notification on your behalf then you can’t delete it, see it or see who created it.  So if you want to piss someone off you can setup for them to be notified on every build that is done ever and there is nothing they can do about it.  Yes, you can go to the TFS database and remove them but that’s a bit extreme and not many developers have that kind of access.

Overall

TFS has so much promise but the combination of idiotic concepts, poor integration and lacklustre features really harms productive.  A sign of a good tool should be one that doesn’t get in the way and in this respect TFS fails massively.  I would even go as far to say it actively promotes bad VCS habits from individual developers.

Features:

• Full session list stored locally, so it will work when you have no wifi or signal
• Includes the title, full description, room, time and presenter of every session
• The welcome screen gives you a heads up of your next session
• A “My Schedule” view, once you’ve selected the sessions you want to attend you can see them all at a glance.

It’s nothing ground breaking, or pretty :), but I hope you find it useful. You can download it from:

Market Link

And the source is up at https://github.com/Dotnetwill/DDDNorth-Schedule- Android so if you want to add features you’re more than welcome just send me a pull request!

Disclaimer Although I use the official DDDNorth logo and colours this is 100% unoffical so please direct all complaints and issues to me, not the wonder DDDNorth team :)

My Session

My session is an introduction to Android development from my .Net perspective, I’m going to go over the basics you need to get an internet facing application up and running using Java and the Android SDK.  I’ll cover, roughly, Activities, basic XML layout, AsyncTask, Intents, permissions, list adapters and, of course you can’t miss, context.  Along the way I’ll share with you bits of Java that have caught me out or are relevent to help get these things done.

If you’ve written an Android application I doubt there is going to be much there for you.  If you’re an experience Java developer I’ll probably just make you angry as I butcher the language.  But if you’ve got experience with .NET and would like to learn about Android native dev and bare in mind that this isn’t best practice or even particular wonderful code then please come and long and enjoy it.

Hope to see you there!

• It only works on Vista or later
• It can be used for file and folder links
• You can not create a link on a network location back to your local machine
• If a sym link created on Vista/Server 2008 (or later) is in a shared folder, XP machines will not be able to use it.  As they don’t support sym links, only junction points.

As usual don’t hesitate to raise any bugs or give any feedback

Prerequisites

Some people are just really bad at writing bug reports and work items (I’m looking at you developers) but this is the most important thing you need when reviewing the code, apart from the code.  You need to able to read the original bug report and understand it then see the developers analysis and proposed solution so you know what you’re looking at when you review it. Without this it becomes extremely difficult and time consuming to redo all the work that has already been done to identify the problem.

Leave your style at the door, at the office we don’t have one complete standard, we have general rules about casing, and what not, but there isn’t one enforced style. I find it really helps to tune out to subtle differences in style, so long as it’s readable it really doesn’t matter.

The Review

I like to start with some simple things:

• Run it - Check that the bug has been fixed or the work item has been implemented.  Take it through some basic sanity checks with the debugger attached, if possible, with stop on EVERYTHING enabled and see what it does.  No point in reviewing code that doesn’t do what it’s meant to do.  If it has unit tests run them, step through a few with the debugger to get a feel for how it’s meant to work.
• Check for build warnings - Ok that might sound petty, but I generally think warning should be treated as errors.

• Is it readable – This is the most important, if you can’t read it how do you expect it to be maintained?  Or you don’t understand the change enough to give it a good review. By this point we have checked that the code is working and that we understand it. Now for the hard part, looking at it.  At the business end of a code review I generally look for the following things (C# specific):

• Delegate Registration – Whenever I see a delegate being registered I always look for a corresponding deregistration.

• Resources Being Release – If a resource (file, db, etc) is opened, make sure it is released again at some point.
• General Exception Handling – I always look for things I know, from experience, are likely to throw and see if there is exception handling around it.  Whenever there is a catch block, I look at how it is dealt with and what is caught.
• TryParse v Parse – Parsing values is always error prone, and we do a lot of it in our codebase, so I’m a stickler for correct exception handling or using the TryParse methods.
• Null Checking (or Use of a Null Pattern) – Defensive coding should be our bread and butter so this should always be present
• General WTF-ery – Anything that makes me utter those three little letters. I think this covers most points, it’s not an exhaustive list but I think code reviews are more about checking maintainability than quality, although it definitely helps with it.

When giving feedback I like to try and speak to the person first and ask them about it, remember one person’s WTF is another person’s complex issue. Alternatively, I jot a few points down in an email.  I don’t see the need for a separate code review tool when other forms of communication are effective and flexible.  Finally, always be constructive, it’s hard to get people to listen if your just being negative so state your reasons clearly, ask them why it’s like that and always resist the urge to say “W.T.F is going on here dude”.

I started off this blog post with a view to clarifying in my own mind how best to do code reviews, but looking back and rereading my approach I feel there is room for improvement.  So I ask you my dear readers:  What do you think makes a good code review?

As I’m sure you can imagine, I was devastated but not entirely shocked.  You see I used to rush through a task or bug to get to the next one or get distracted by something shiny.  The best way I can describe it, is as a Magpie effect and, as I was being made aware of at that moment in time, developers are expected to be completer finishers and meticulous to a fault.

I was aware of TDD and I had tried to write some tests but I really struggled with how to make code testable and good unit tests that didn’t just test “stuff”.  But this time I was determined to learn more and put it in to practice, it seemed like the perfect answer.

Present Day…

That was nearly two years ago now, I’ve grown massively as a developer since that day and TDD has been my gateway drug to professionalism. When I started off with TDD I thought it was about testing but when I look back at my journey thus far, it’s about anything but.

One of my biggest problems was rushing, I was always desperate to finish and I missed things or didn’t think them through properly.  The first thing that writing unit tests helped me to do was slow down and break problems into much smaller chunks.  Just taking a few minutes to consider how best to write the test normally exposes any concerns that need to be separated, edge cases and how the class or function will be interacted with.  If I’m ever struggling to make a test pass, write a test or if I can’t make all the tests pass, it normally means I need to go back and look at the tests to see if I’m trying to solve too much in one go or if it has contradictory responsibilities.

The tests provide excellent documentation that is hard to argue with and stays in step with the code.  This is key because it gives me an insight in to what I was thinking and how I intended on it being consumed.  It’s, also, the closest to an interactive interrupter for C# I have used, which is great for rapidly checking assumptions and questioning your own code.

Overall it has taught me so much about architecture, design, good practice and maintainability of code.  One conclusion I have to come is that unit testing has a very low regression value.  At this moment in time I rarely, if ever, find bugs using unit tests.  Yes they help to identify failure points but it’s not very often I find regressions using them.  All they have done is shifted the pain point from if the logic works to if it all works together.  My next challenge is step deeper into the world of the integration testing.

For the past few weeks I’ve been living with it, but it’s becoming increasingly annoying.  So today I finally worked out how to stop it:

1. Go to the Team Members item in Team Explorer and right click on it
2. Select _Personal Settings _
3. On the dialog there is a Collaboration setting, change the provider to None
4. Be free of annoying dialog.

Hope this helps some else regain their sanity

The main arguments against having more than one assert statement seems to be it’s not as readable and it’s sometimes difficult to understand what is failing because of it.  My normal response is to create my own asserts that accurately describe what the multiple asserts do and hide the real asserts in there.  For example:

   1: public void AssertIsValidClone(Customer oldCustomer, Customer actualCustomer)




   2: {




   3:     Assert.AreNotSame(oldCustomer, actualCustomer);




   4:     StringAssert.AreEqual(oldCustomer.Name, actualCustomer.Name);




   5:     StringAssert.AreEqual(oldCustomer.Address, actualCustomer.Address);




   6: }




   7:  




   8: [Test]




   9: public void Clone_ValidCustomer_ValuesAreTheSameReferenceIsDifferent()




  10: {




  11:     //Some setup




  12:  




  13:     var result = aCustomer.Clone();




  14:     




  15:     AssertIsValidClone(aCustomer, result);




  16:     




  17: }

Ok so this is a very contrived example but we can clearly see what the intent of the assert is rather than having several making it harder to understand. But what this doesn’t do is address the second concern. IE anyone of those three asserts could fail, so we fix it then the next fails, etc.

Enter an nUnit plug in called OAPT, this allows you to have multi asserts that generate multi unit tests in the runner so you can see exactly what is failing.  I won’t warble on too much about the details because it’s all in the link But let’s just rewrite our unit test:

   1: [Test, ForEachAssert]




   2: public void Clone_ValidCustomer_CloneIsNewItemWithValidData()




   3: {




   4:     //some setup




   5:     




   6:     var newCustomer = originalCustomer.Clone();




   7:  




   8:     AssertOne.From(




   9:         () => Assert.AreNotSame(originalCustomer, newCustomer)




  10:         () => StringAssert.AreEqual(originalCustomer.Name, newCustomer.Name)




  11:         () => StringAssert.AreEqual(originalCustomer.Address, newCustomer.Address));




  12: }

Much more concise and it will run as three separate tests.  I still do have an issue with it though, each test uses the test name with an appended number. It would be nice if you could pass in some text for it to append.  But then again it is open source so maybe I could add that feature myself :)

This is something I didn’t think I would do but after releasing Dirlinker 2 on Codeplex, a ticket was raised in the bug tracker because it was failing on XP and I was chatting to a friend on IM about it who basically said “Well why doesn’t it?”.  The main reason was because the API call for creating symbolic links is only available in Vista and later.  XP does have an equivalent but the behaviour of the links they create is subtly different.  In XP they are Reparse Points where as in Vista+ they are hard links (similar to *nix), I will go in to the difference in a future post.

It turns out that with a little help from a CodeProject article, it took less than an hour to put in and test, so it made it in.  I am definitely parking this to new features now.  Only bug fixes will be added from now on.

What’s New?

• Undo Support – If the process of moving and deleting a folder before creating a link at the same location failed, you could end up with some files in the new location, some in old and two partial directory structures.  If this happens now DirLinker will offer to put the original folder back how it was.

If you’re using the just delete option and it fails, undo can not undelete any files but it will put back any folders it deleted.

• File Links – It can now create symbolic links for files as well as directories.  You don’t have to do anything different, just select a file in the link location or the link to field.  There has been a small change to the UI to allow you to browse for files aswell as folders.

In a future post I’m going to talk about the difference between symbolic links and shortcuts.  But for now the important difference is the application opening file doesn’t know the file is only a link when using symbolic links.

• Progress Window Changes – The progress window has been slightly overhaul and now keeps a list of everything it has done.  So if it does fail or something goes wrong, you can work out exactly what it’s done.

With these features I’m planning on parking Directory Linker development, I will of course fix any bugs that may come up but I can’t see any new features being added.

Enjoy!

PS, If you have no idea what Directory Linker is, this is a good place to start.

I’m finally getting stuck into finishing off DirLinker 2.0 and with VS2010 being released I decided to upgrade the project to VS2010 still targeting .NET 3.5 for compatibility.  While enjoying the new IDE features, I discovered some of the C# 4.0 features work when targeting .NET 3.5.

#

Optional and Named Parameters

This is something I’ve been looking forward to, I think it will make my code prettier by removing the ridiculous number of overloads you can some times end up with.  I’m not going to explain the feature because it has been well covered by better writers than I :).  So imagine my surprise when I discovered I could use this feature while targeting .NET 3.5.  Just to test the theory I wrote the following console application and targeted it at .NET 2.0:

static void Main(string[] args)
{
    FunctionCalledUsingNamedParams("str1", "str2");
    FunctionCalledUsingNamedParams(String2: "str2", string1: "str1");  
    FunctionWithTwoOptionalParams();
    FunctionWithTwoOptionalParams(200);
    FunctionWithTwoOptionalParams(56, "Called from main");
    FunctionWithTwoOptionalParams(message: "test", number: 29);  
    Console.ReadKey();
}  
static void FunctionCalledUsingNamedParams(String string1, String String2)
{
    Console.WriteLine(String.Format("{0} : {1}", string1, String2));
}  
static void FunctionWithTwoOptionalParams(Int32 number = 1, String message = "default message")
{
    Console.WriteLine(String.Format("{0}: {1}", message, number));
}

This compiles, runs and outputs the correct information just fine.  I even ran it to a machine that had never seen .NET 4.0 to be sure.  It would appear it’s C# 4.0 feature not a .NET 4.0 feature.  I have only tried this with optional params but I doubt that dynamic and co/contra-variance will work, I think the general rule is if it doesn’t require the Base Class Library or CLR support then it will work.

(The source for app along with a compiled version is available here )

Of Course This is Not New

Within the past 12 months my work place has moved to VS2008 from VS2005 but still targeting .NET 2.0.  One of the things I quickly discovered was that lambdas, auto properties and  object initialization syntax all still works perfectly when targeting .NET 2.0 from VS2008.  Making them a feature of C# 3.0 not .NET 3.5!

So it’s important to remember this simple expression:

Visual Studio Version || .Net Version != C# Version

Solution

I set about trying to cache my credentials this morning after, mixed with a case of the Mondays, I’d finally had enough with it pestering me.  The dialog does not have any remember my password option so the next stop is to save it in my Windows Profile.  To do this:

1. Open “Control Panel”
2. Go to “User Accounts” and select the option “Manage your network passwords”
3. In the dialog enter the path to your TFS server and your credentials, for example

This worked great for Visual Studio but I still had to log into the TFS Sharepoint portal site every time.  I discovered you also have to enter the TFS server address into the “Intranet Zone” in “Internet Options”.  To do this:

1. Open “Control Panel”
2. Go To “Internet Options” and select the “Security” tab
3. Then select “Intranet Zone” and click on the “Sites” option
4. Now enter the address of the TFS server, for example:

Then you should never be harassed again :)  This works / is needed on Sever 2008 and Vista, as per usual the story is a lot better under Win 7 and Server 2008 R2.  It’s just a shame my main development VM is 2008 and I don’t have time to reimage it.

• Life style management – It’s possible to register types as singletons or instance
• Func factories – OCInject from day one supported delegate factories, now you can use Func instead of typed delegates
• Simplified Registrations – In the previous release of OCInject types are registered using TContract –> TImplemenation to enforce programming to interface.  It’s now possible to register with TContract as the concrete type with one call
• Largest Resolvable Constructor – In the previous release of OCInject it simply grabbed the first constructor it found.  It will now select the greediest constructor it can resolve.  It makes the assumption that any known types are resolvable, for performance reasons.
• Unresolveable Callback – It is now possible to supply a call back function if the container can’t resolve a type.
• Child Container Support – OCInject can create child containers that call back to the parent for any unknown types. 

The latest stable version can be downloaded from Codeplex and all stableish development releases can be found at BitBucket.

#

Future Features

One major feature still missing from OCInject is named registrations.  This is because I personally dislike ‘magic strings’, with this in mind a planned future feature of OCInject is factory delegate registration only.  Also, auto generated factories from interfaces.  More to come on this in a future post.

Life Style Management

By default all types registered with the OCInject container are transient. You can register a type as singleton in two ways.  The first method is to use .AsSingleton() this will cause the object to be created the first time it is requested.  The second method is to use .AlwaysReturnObject(obj), this will return the instance you specified.   When using either method, if the type implements IDisposable it will be disposed when the container is.  Usage example:

ClassFactory container = new ClassFactory();  
//Normal Singleton
container.RegisterType<TestClass>()
           .AsSingleton();  
//Preconstructed Singleton
AnotherClass instanceOfAClass = new AnotherClass();  
container.RegisterType<TestClass>()
         .AlwaysReturnObject(instanceOfAClass);

Func Factories

When resolving constructors if OCInject discovers a Func where T is a registered type, it will pass in a func to create the type.  This uses the standard container resolve, so if T is a singleton you will always get the same instance when the factory is called. Usage example:

class FuncConsumer
{
    public FuncConsumer(Func<TestClass> factory)
    {
    }
}  
ClassFactory container = new ClassFactory();  
container.RegisterType<FuncConsumer>();
container.RegisterType<TestClass>();  
//Successfully created with the ability to create TestClass
FuncConsumer f = container.ManufactureType<FuncConsumer>();

Simplified Registrations

Registrations no longer require the separation of contract and implement so just an implementation can be registered.  Usage example:

ClassFactory container = new ClassFactory();  
container.RegisterType<TestClass>();  
var t = container.ManufactureType<TestClass>();

Largest Resolvable Constructor

This is quite a complicated area that is worthy of a blog post itself but OCInject’s behaviour has changed.  When creating a type the constructors are ordered so the largest, in terms of parameters, is first.  It then looks at each parameter and to see if it can resolve it, first by checking ‘resolve time args’ (values passed in when the resolve is requested, normally from generated factories) then by seeing if the type is a registered contract within the container.   It does not check if the type can be created just that it knows about it, if it’s registered it assumes it can be created.

The first completely resolvable constructor will be used to construct the type.

Unresolveable Callback

If the container is unable to resolve the type you can now register a function that is called before the container throws an exception.  To do this you need register a Func<Object, Type> with the CallToResolve propriety.  Returning null will cause the container to throw an exception.  Usage example:

ClassFactory container = new ClassFactory();  
container.CallToResolve = (type) => { return new TestClass(); };  
ITestClass manufacturedType = factory.ManufactureType<ITestClass>();

Child Container Support

Calling CreateChildContainer() will return a new ClassFactory object with no registrations but a link back to the parent.  If a type is not known to the child it will ask the parent to fulfil the request.  Any registrations with the child will not effect the parent and singletons registered with the child will be disposed when it is. Usage example:

ClassFactory container = new ClassFactory();
ClassFactory child = factory.CreateChildContainer();

My biggest annoyance when working with branches is by default all branches are pushed/pulled to the remote repository.  When in reality, I often want to just push the branch I’m currently on.  Mercurial addressed this by adding a branch only option to Push, Pull, Clone, Incoming and Outgoing.  To use the branch only option you append –b to the command followed by the branch name, for example:

hg push -b default

This will only push the default branch back to where the repository was cloned from (You can still specify a location to push to if required.)  This works exactly the same for all the other commands.

A handy shortcut to push the current branch is use ‘.’ as the branch name:

-b .

#

This will perform the command only to the branch you’re currently on.  Since I tend to push more than I do most of the others, I have set up an alias to map push current branch to pc.  You can do this by adding a section to your hgrc like:

[alias]
pc = push -b .

Branching Without Having It In Your History

Cloning locally has always been an option to create a branch or fork of the code that is still linked to the original code base, IE you can push and pull to it, but it doesn’t become part of your history in the other repo unless you pushed it back.  But I’ve never liked it because it takes a copy of everything and sets the current branch to the default branch.  Trivial, maybe, but not something I found desirable.

The new branch options makes cloning locally a lot more attractive to me.  It means I can just clone a branch, make a quick change or two and either merge it back in or delete the directory and pretend I never had that idea!

****

Powershell and Mercurial

As part of my continuous improvement I’ve been learning PowerShell.  One way I’ve done this is by replacing all my cmd.exe usage with the PowerShell prompt instead.  This led me to discover an excellent cmd-let (script or whatever the proper name is, I’m still learning :)) to display the name of the current branch and status of it when you’re in a Mercurial repository.  It looks like:

More information can be found about this here.

When a method is called in C# a copy of the all parameters are given to the method.  This is fairly obvious with value types because if we change the value of an int, for example, the caller does not get the updated value.

However this is not so clear for reference types.  The called method can update the state of the object it was passed, for example append extra data to a StringBuilder, and the caller’s object will have these updates.  This can lead to confusion about what is really happening, it looks as if the StringBuilder was passed by reference but a copy of the reference to it was taken.

It maybe subtle semantics under normal use but it becomes key to understanding behaviour when the ref keyword is used.  For value types this means that if we increment an int we are passed, the caller will have the new value too. For reference types the reference we are passed is actually a reference to the caller’s reference. Meaning if we assign a new reference to it, the caller will get the new reference.

We can demonstrate this with the following code:

static void Main(string[] args)
{
    StringBuilder sb = new StringBuilder();
    sb.AppendLine("Added by Main");  
    AddToSBPassedAsNormal(sb);
    Console.Write(sb.ToString());
    //Output: Added by Main
    //        AddToSBPassedAsNormal  
    AddToSBPassedByRef(ref sb);
    Console.Write(sb.ToString());
    //Output: AddToSBPassedByRef  
    AddToSBPassedAsNormalNewUsed(sb);
    Console.Write(sb.ToString());
    //Output: AddToSBPassedByRef  
    Console.ReadLine();
}  
private static void AddToSBPassedAsNormal(StringBuilder sb)
{
    sb.AppendLine("AddToSBPassedAsNormal");
}  
private static void AddToSBPassedByRef(ref StringBuilder sb)
{
    sb = new StringBuilder();
    sb.AppendLine("AddToSBPassedByRef");
}  
private static void AddToSBPassedAsNormalNewUsed(StringBuilder sb)
{
    sb = new StringBuilder();
    sb.AppendLine("AddToSBPassedAsNormalNewUsed");
}

From the code above we can see that the StringBuilder after the first method contains both strings.  But after the method call, where it is passed by ref, the previously entered data has been lost and, finally, using new when not being passing by reference has no effect on Main()’s reference to the StringBuilder.

Before passing a reference type using the ref keyword you must think carefully about the implications of the caller changing the reference.  As it can lead to some esoteric and difficult to track down bugs.

public void SomeHighLevelFunction(out String feedback)
{
    StringBuilder mySb = new StringBuilder();  
    _WorkerItem1.DoWorkOne(ref mySb);
    _WorkerItem2.DoWorkTwo(ref mySb);
    _WorkerItem3.DoWorkThree(ref mySb);  
    feedback = mySb.ToString();
}

Ignoring the void with the out String, why pass the StringBuilder by ref? This code was written by a migrating C++ programmer; if you’ve worked with C++ at all a little light bulb may have just gone off for you.  It works, even though it might be the very definition of programming by coincidence, so why is this so bad?

#

Why So Bad?

When calling a method in C# all parameters are passed by value.  It is a common misconception that reference types are passed by reference when they are infact passed by value.  This backs up the position of the C++ programmer, so what is the difference?

C# and its documentation has no concept of pointers (outside of IntPtr) when they are used extensively under the hood.  When you call a method and pass a reference type you are actually passing a pointer (that lives on the stack) to a memory location on the heap.    The pointer is copied so you can still manipulate the memory but you can’t affect the reference.  For example:

static void Main(string[] args)
{
    StringBuilder sb = new StringBuilder();
    sb.AppendLine("Added by Main");  
    AddToSBPassedByRef(ref sb);
    AddToSBPassedAsNormal(sb);  
    Console.Write(sb.ToString());  
    Console.ReadLine();
}  
private static void AddToSBPassedByRef(ref StringBuilder sb)
{
    sb = new StringBuilder();
    sb.AppendLine("Added by AddToSBPassedByRef");
}  
private static void AddToSBPassedAsNormal(StringBuilder sb)
{
    sb = new StringBuilder();
    sb.AppendLine("AddToSBPassedAsNormal");
}

Has the output of:

Added by AddToSBPassedByRef

This could be confusing to a C++ developer because all classes, in C++, are created on the stack unless you declare a pointer and use new to create them on the heap.  Having said that a simple rule applies to both to C# and C++, if you have to use new it gets created on the heap and everything else is created on the stack.  Anything on the stack, value types or reference types, is copied between method calls.

Two Expensive Resources Working Slower, Yeah Right!

Let’s not beat about the bush, pair programming means that two expensive resources, developers, are tied up on a task without necessarily bringing two ‘man days’ to a task.  What pair programming aims to do is reduce the overall cost of ownership of code.  It can work as a mentoring technique to develop less experienced programmers but this maybe defeating the object of the type of pair programming that really brings value.

In a traditional software development lifecycle the cost of fixing a bug rises exponentially as you move through the software’s (or feature’s) lifecycle. I’m sure we’ve all seen a graph similar to below at some point in our careers. It shows the costs of fixing a bug versus the stage development is currently in.

The aim of pair programming is to raise the costs slightly at the start, with a view to reducing the sharp curve towards the end.  So we end with a smoother curve and we spend list time in the costly area of the graph.

The Good, the Bad and the Ugly

My experience has been overwhelmingly positive, but the ones that stick out the most are:

• More Focused – I’ll admit I have problems concentrating at times, I’ll see a tweet, Google something related to what I’m doing and find an interesting blog, etc.  Working in a pair has really focused me on the task at hand and I think I’m more productive.
• Less Rabbit Holing – I’ve found just verbalising my ideas about what I want to do with a design, refactoring or while investigating a bug helps to work out problems or see things I’ve missed.  Also, the navigator can ask questions about less clear areas.  All leading to a better design, bug fix, etc.
• Differing Styles – Participating in or watching someone else’s thought process has helped show me areas where I could improve and given me new approaches to try when blocked.

• Naming – One thing I struggle with at times is how best to name things to best express my intentions, having a partner to ask “this is what this does, do you think that’s descriptive?” .  All this leads to better and more maintainable code. The not so good:

• Breaks – It can be awkward to be stuck to someone else’s brew up times, smoke breaks, lunches, etc.  It can break the flow and make it feel like you’re spending time waiting on others.

• Thinking Time – This is very subjective and probably should be a pair activity, but sometimes when confronted with difficult to understand legacy code, a strange bug or just several choices.  It’s nice to go through your ritual, whether that be listen to your favourite music, rock the water cooler or chat to that cute girl in marketing, it all has the same outcome you feel better and have had thinking time.  I’ve found this particular hard when your partner is looking, listening, questioning and waiting for you to carry on. Overall, it’s definitely been a worthwhile experience and one that I will be continuing.

Remember It’s Not For Everyone

We’ve been careful to explain to people that it is not an experiment with a view to introducing it across the team, just something we wanted to do.  It started off with just two of us but a third has joined with one or two more interested in joining if the opportunity came up.  But it’s important you don’t force the issue.  For it to be a success you need people who:

• Check their ego at the door – There is no room for “this is the way I do it and it’s the right way” one of the biggest take aways for me has been learning from someone else’s style and approach, even if I disagreed.
• Are Interested – This is so important, for the navigator role to work well the person needs to want to do it.  Not just be sat thinking “God, when can I drive”.
• Be Strong – I have a strong personality and it can over power people around me.  As much as I’ve tried to rein it in when working with less strong personalities, it’s still important the other person is strong and is willing to defend their opinion.