Monday, October 26, 2009

Visual Studio 2010 beta 2 side-effect - SQL2008 autoupgrade

I went wild the other day and installed VS2010 Beta 2 on my development machine.

Without asking it upgraded my \SQLEXPRESS instance to MS SQL2008 fro MSSQL2005.

I then had to jump through flaming hoops to install the update MSSQL Management studio express, installing 2 pre-requisites, Windows Installer 4.5 and Windows Powershell 1.0. (I'm on XP , I hope these are on Vista or Win 7) and then when I eventually could run the installer I perhaps the most confusing installation screen in the world, ever.

I think I went for a full installation on this page and it just installed me Studio, I can't be sure as I went round the houses several times and now I can't even find out how to uninstall the little s***t to test.
R2 Management Objects?

Very naughty VS2010.

It also prompted me to restart mid installation with this gem of a dialogue box.

Remote Pairing - a quick guide

Today I spent most of the most of my morning and afternoon honing my TDD skills with Rob Cooper. Whilst none of the work we did was particularly earth-shattering it was great to delve in code and discuss at length. We tackled a TDD Kata in depth rather than discussing the 'form' elements we concentrated on discussing how the design emerged and the different approaches to testing. We had a few technical issues and ironed most of them out but I wanted to outline the setup as it seemed fairly easy to arrange.

Remote Pair Recipe

  • IDE of choice - (helps if these match)
  • Git - (or other DVCS)
  • GitHub Account - (or other hosted service)
  • Skype/GTalk/Live Messenger - for Audio Comms
  • MS SharedView - see what the other pair is doing

MS SharedView deserves a special mention here as it worked extremely well for screen sharing.


Check your setup

Before starting make sure you can both access and commit to Github. This is the place where you are both going to be passing your code back forth to. Make sure your equipment works (someone in this pair had a crappy mic in his headset - no names mentioned (*cough* - me)). This slowed us down and upset flow a little. Thankfully the other pair was not blameless. If you are going to use other tools agree what they are, including version, before the event so you don't have to spend time scrabbling around the internet for requisite software.

Have a plan

Do not go into a session unprepared. Without a plan a session will lose direction. I think we were over-prepared with things to do but its better to have more than less.

Don't be scared

Having someone watching your every keystroke may seem like a daunting thing but hey you can always have your revenge when its their turn to drive in general you are both here to write better code so if you make a mistake and your pair notices it or if you have a bad habit you should be grateful it is being pointed out. That way you can fix it.

Don't be offensive either

There are many ways to convey that your pair has not removed the duplication in that class other than by comparing his intellect to that of an amoeba. Pick a nicer one.

Swap driver-navigator often

Rob and I swapped mid-scenario in our TDD session. I would red-green (to the simplest possible case) then Rob would grab the session add a further test and refactor. We thought this was a nice way of doing things as we both had our input in creating the feature. I would make the fixture and pass it over to Rob as tested. Rob double checks with a further scenario and makes the call to refactor.

Embrace your differences

Rob and I had a slight difference in our approach to testing. We stopped and talked about it afterwards but it was not a problem in this case as the code was 'throw away'. The issue may have been more pressed if we wanted to keep the code.

Take breaks

I'm ashamed to say that even though Rob and I are both Pomodoro Technique practitioners we took 1 break in the multi-hour session. This was wrong. I found that towards the end of the session I was losing concentration. With pairs I think this especially important due to the intense focus you have with two of you.


We approached the exercise like so:
  1. Driver picks feature
  2. Driver writes test.
  3. Driver passes test.
  4. Driver commits and pushes to GitHub
  5. Navigator pulls from github
  6. Navigator becomes Driver
  7. Driver adds 'confidence' test and refactors.
  8. Go to 1.
As mentioned above this did have a nice side effect of us both touching the same features and meant we swapped often. The code was clean and I hope we both got as much as I did out of the exercise. I'll certainly be doing this again.

Saturday, October 03, 2009

TDD Kata: Do not attempt this alone.

There has been some talk of TDD Katas over the last couple of days on Twitter that I think originated from something Roy Osherove did in his TDD Masterclass. I find the concept intriguing.

So what is Code Kata?

A code kata is a set of programming exercises designed to improve your coding skills through pratice and repetition.

Dave Thomas of Pragmatic Programmer fame describes it as such:
How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practising; applying the theory over and over again, using feedback to get better every time.
and as a failed musician (through lack of practice) I see sense in it. When you learn to play a piece of music you don't just play it all the way through. You practice parts of it. To attain the skill to play parts of the piece you learn scales or chords and practice them on their own.
So I thought I would have a go at Roy's TDD Kata.

30 mins later

Finished. Would you believe I finished within 30 mins? (Note: my 1st attempt at this kata was a cutdown version but I crammed everything into the allotted time, just!
That leads me to one conclusion, I MUST BE AWESOME.
So there we have it. I've'done' Katas.
In the next blog I'll be talking about

But what exactly did you do?

Oh yeah what did I produce? Well I got it reviewed by someone hot out of Roy's TDD course and it had a number of issues. It seems that over the years I have picked up a couple of bad habits. It was like I was playing the tune but holding the instrument upside down. So I swapped reviews with the reviewer and attempted to try again using the feedback I was given.

I didn't even get halfway through it! :(

This is great I've got lots to learn now. I can improve my process and really learn how to Test Drive my code quickly and effectively and also improve on the actual code itself.

But then I read Roy Osherove's blog entry on the kata and I'm confused. Roy says:
The point about the Kata is that you should know it by heart. you should not be thinking about the solution, your fingers should by typing it "blind", including all the refactoring work, the renaming and whatever else you do.
So am I blurring the intent of the kata? By reviewing the code and improving it am I breaking the ethos of the kata? If the pupose of the kata is getting to know your tools and output better, then surely the most productive way is to have snippets at every section. Or to be utterly ridiculous to just copy paste the code in.
The idiot programmer like me will just be practising its awful solution to the problem and will be blissfully ignorant in the fact that it is improving its craft. And yes it may be able to do it in under the allotted time but when someone else comes to pick up its code, they may well spend a lot longer sorting out the unorthodox way it was done.
This is obviously wrong.

Not a solo activity

Its plain to see that you need a someone else to see where you are going wrong. Where you can improve even if that someone else is you! Do a retrospective, read a book on "cleaner code" or perhaps on the "art of unit-testing"? (No books spring to mind right now - I'm sure a web search may bring some up though).
If you do have the luxury of another person be subjective about their critique, they may have things you disagree with but try not to take it personally.

An improved kata?

I love the idea of the kata but I can see where I could go horribly wrong.
What I would like is the idea of a community kata. A bunch of developers do single kata over a fixed period, say a month. Over that month each time they complete the kata they commit it to a version control system where the other devs can access it and review the code. An annotation of tips and hints (e.g. was mouseless, used this snippet) is included in the commit notes so everyone can compare techniques. Time to complete would be a nice to have but more importantly an indication of improvement of time would be preferred. My single finger seeking typing my not be 150wpm but I if improve by 20% that would indicate my other methods are working. At the end of the month the developers can choose to stay on or try another.

I'll be doing more kata as I think it's a great concept in the right circumstances. You want to improve your ability to use your tools but if your music is crap...