Humblecoder

I was massively honoured to have my session on Android development voted into DDD North and I’ve spent the last couple of weeks thinking about and planing my content to do the honour justice.  While doing this I’ve created a small application that lists all the available sessions at DDD North and lets you keep track of what you’re planning to attend.  Partly to help recentre my Android zen and partly to give something back.  So here it is:

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:

**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!

This morning I have pushed a new version of DirLinker to Codeplex.  The only change, a response to a bug raised on codeplex, is to allow the entry of network paths in DirLinker’s UI because it possible to create symbolic links to network locations on Vista (or later) but the strict validation used would not allow it.  There is a couple of things to be aware of when creating them:

• 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

I love code reviews, I really do.  I like having my code looked at and receiving feedback and I like to look at other peoples to see differing styles, techniques and library functions I might not be aware of.  But I always struggle to find the best way to do code reviews.  So I want to take a look what you need to perform a code review and how to review the code.

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?

“Have you considered working in another area in software, you don’t seem to have the right personality type to be a developer”…Said the head of development sat across the table from me.  I sat, head down, a mere 18 months out of university having just delivered my first major product release being told that I was no good at what I do.  I love programming, it has been my hobby since I got my first computer and it was the only job I’d ever wanted to do.

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.

I’ve recently stopped using Live Messenger (moved to Pidgin) and one unexpected side effect of switching was TFS reminding me every time I went to Team Explorer that Messenger isn’t running with this lovely error message:

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

I’ve read many books and blogs that advocate only having one assert in a unit test and lots of people take that to mean literally assert statement.  I’ve always disagreed with taking it literally, I’ve always thought of it as one logical assert, as in you assert one concept at a time which could lead to multiple assert statements.

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

Today I have pushed new binaries to CodePlex for DirLinker.  This new release brings support for folder links in Windows XP/2003.  It is not able to create file links, this is because of the limitations in reparse points in earlier versions of Windows.

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.

After literally months of procrastination Directory Linker 2 is finally in state that I’m not too ashamed of.  So today I have posted up new binaries on Codeplex.

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.

**Update** Generic variance can be used (and a couple of other things) when multi targeting see here: http://blogs.msdn.com/ed_maurer/archive/2010/03/31/multi-targeting-and-the-c-and-vb-compilers.aspx

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

At the office we use TFS and it pesters me for credentials every time I start Visual Studio because I’m not on the domain.  This does quickly become very tiresome.

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.