Tom Quinn's Blog

Are you a developer / development manager? Do you / your team practice TDD? Do you want to?

Do you want to become an accomplished practitioner and learn advanced techniques?

Do you want your team, or yourself, to be taught by a master of the art?

Then sign up for Roy Osherove’s TDD Master Class, brought to you by iMeta technologies.

We ran the second Southampton coding dojo today.

In attendance were:

• Mark Heath
• Neil Rees
• Paul McCaskie
• Grant Sutcliffe
• James Watson
• Michael Webb
• Stephen Goodman
• Tom Peplow
• Tom Quinn

The session was ran using the Randori Kata. We decided that we would implement the lessons learned form the last dojo and more strictly follow the red, green, refactor pattern. We also discussed the problem space before we embarked on writing any tests; the idea being to ensure we were all on the same page.

We decided to run a Kata based on the popular TV game show Countdown; specifically the numbers round. We decided to start by building a problem generator which then could be used to generate test cases for the solver. In Countdown contestants start the numbers round by picking from a selection of large and small numbers. The set of large numbers consists of 25, 50, 75 and 100. The set of small numbers consists of two sets of the series 1 through 10. The contestants can select between zero and four large numbers, and up to six small numbers. The computer ‘CECIL’ then selects a number that is below one thousand. The contestants have thirty seconds to get as close to the answer as possible using the six numbers chosen. The number chosen by ‘CECIL’ is not always achievable using the six numbers chosen. The contestant who gets closest to the number achieves the most points.

We decided that for our purposes the problem number should be achievable using the six input numbers chosen. We also decided that the problem generator should accept two parameters as inputs; representing the number of large and small numbers chosen. The generator should return an object that details the following about the problem:

• The number to be ‘solved’
• The six input numbers
• The formula that was used to achieve the number to be solved.

Once everyone in the room had taken a turn leading the pair we stopped and had a quick retrospective. The group were all happy with the process we were following. We again noticed that we were not covering as much ground as we initially thought we would; we noted that we did not need to start from a green field each dojo. There were some people in the group who had never used TDD before and they commented that is was very interesting to see how the solution was unfolding.

We had some good side discussion on the use of the var keyword. Specifically around how it enables test driven.

At the end of the session we had not finished the generator part of the problem, perhaps we will continue this problem next time? The group did have some discussion on TDD during the session. Specifically we noted we would love to see how Uncle Bob would TDD our problem. How about it Bob?

The source code from the session will be posted soon and I’ll blog with a link to the location once it is available. On which note sadly we ‘lost’ the code output from the last dojo, so this will not become available; Apologies.

Hopefully we will get another good mix of people next time. The next session will be: Thursday 8th October and will again be held at iMeta’s Southampton Office. If you want to come along, all we ask is you register first. Hope to see you there :-)

I’ve recently embarked upon a series of posts covering mocking. During this time I have also been involved in a wholly different kind of mocking, User Interfaces. I also recently gave a short talk (a nugget) for the NxtGen User Group. The subject of my talk was Balsamiq.

Balsamiq is an application that can be used to rapidly produce mockups of User Interface screens. You can produce mockups of web based applications as well iPhone type applications. The user interface to Balsamiq is very intuitive, whatever you need being easily found with rarely the need to resort to the documentation. It can produce PNG images of your mockups as well putting a PNG into your clipboard ready for pasting into your word processor or slide show application of choice.

Balsamiq allows you to save your mockups in BMML format to disk as well allowing you to export an XML representation of your mockup.

Mockups can be linked to other mockups very easily; this facilitates the very useful presentation mode. Presentation mode does exactly what it says on the tin, it allows you to use a linked set of mockups in an interactive presentation.

There is a good community providing free, pre built mock up templates and the like. Examples include MockupsToGo and Mock4U, a set of UML diagram add-ons.

In addition there is now a fantastic sister application called Napkee. Napkee can take your BMML files and produce HTML from them, what a fantastic way to quickly produce templates for your actual UI when it comes to implementation time.

I recently wrote an article for the UK MSDN Flash, my topic of choice was mocking. Mocking is something that I personally have been doing for a very long time. Over time the word I have chosen to represent what I have been doing has changed as I have encountered other like minded individuals. I have at times referred to my use of mocking as faking, stubbing and mocking.

When I did some further background investigation before writing the Flash article I discovered a whole vocabulary exists for this area. Martin Fowler has a good article on Test Doubles in which he briefly discusses the vocabulary used arund mocking. So although my article was initially called and about mocking, I changed the title to Test Doubles. It seems that the action of using a Test Double is still referred to as mocking; go figure ;-)

In the article I briefly covered the fact that several frameworks exist to assist with mocking. I am going to produce a series of posts acting as a getting started guide for each of the following three mocking frameworks:

• MOQ
• Rhino Mocks
• Typemock

In addition I intend to write an article giving concrete code examples of each of the types of Test Double.

If you have something you would like to covered in this series of posts then please let me know using the comments or shout at me on twitter: @tommyjmquinn

We ran the first Southampton coding dojo today.

In attendance were:

• Tom Peplow
• James Watson
• Grant Sutcliffe
• Jason Deabill
• Stephen Goodman
• Mike Blake
• Mike Godfrey
• Mark Heath
• Tom Quinn

The session was ran using the Randori Kata. We used the list of pre-prepared Kata from the coding dojo site.

We decided to run with the Roman Numeral Calculator Kata. We used the four rules as per the prepared Kata.

We decided to follow Kent Beck’s advice, as per Grant’s recent blog post and start with a list of test cases we wanted to cover. We started with a fairly short list as we didn’t know what our velocity would be:

• I + I = II
• I – I = string.Empty //Is there a zero in roman numerals?
• V + I = VI
• IV + I = V
• III + I = IV

Pairings started with Grant leading the pair with Jason and then followed round the list in the order shown at the top of this post. The session was ran using TDD.

After everyone had taken a turn leading a pair we stopped for a quick open table review. The group agreed that five minutes was a good time box. The group noted that on some occasions the right of the pair to have no interruption was being violated; it was agreed that is was the responsibility of the pair to push back if they didn’t want to be interrupted.

One thing we found over the course of the session was that it became hard to maintain direction without some form of strategy in place. Some pairings would re-factor out another pairings work, only for the next pairing to then introduce it again. Ordinarily when using TDD and working in a pair there are only ever two minds involved. When rotating using the Randori there are many minds and therefore it is hard to stick to the tenets of TDD. We found that introducing a group agreed strategy allowed us to pick up momentum again. Sadly this only occurred 15 minutes from the end of the session; a lesson for the next session ;-)

The source code from the session will be posted soon and I’ll blog with a link to the location once it is available.

Hopefully we will get even more people next time, on which note the next session will be: Thursday 24th September and will again be held at iMeta’s Southampton Office.

On the project I am currently working on we recently decided to adapt the SCRUM process to include some LEAN flavoured sauce.

Specifically we found the way we were running sprints was not working for us. We are in a period in the UK where lots of people take their annual holidays, as a consequence of this we have project members dropping in and out of the project. Planning sprints using previous velocity had become a bit more complex than it should be; so we decided to not decide up front what our sprint would deliver.

We wanted to start each sprint with just one story per developer, so they had initial work to do, and no more. As each developer finished a story they could pull a new one into the sprint. We recognised that we would need to impose Work In Progress (WIP) limits to eliminate waste. If a developer found they had finished a story but the WIP limit had been hit, they would have to change hats and pull a story from the Developer done queue and into the Test queue AND test it.

We decided that a Kanban board would be the best way for us to visualize how the sprint was progressing. Here is our Kanban board.

The Backlog column represents all stories that could be worked on, these all having been ranked on priority by our customer.

The Selected column represents those stories which should next be pulled into the sprint.

The Developer column has been subdivided into ongoing and done, the jury is still out on these names effectively done here means in the test queue.

The Test column has also been subdivided into ongoing and done; done being a state the story is still in until it meets our Done, Done criteria.

When giving training courses I often tell the attendees that people never learn without going through some pain and suffering of their own. This always leads me nicely into the very practical style of my courses, where people can feel some pain and suffering ;-)

Well this morning I have been through some pain and suffering myself; only a little, but very important none the less.

So what did I learn? Nothing! What did I remember and consequently will never forget again?

‘At the end of your working day, always leave a failing test.’ This sage piece of advice comes via Kent Beck and his awesome TDD book.

Now if I could just remember what I was thinking yesterday, I could get back to work…….

recently I have been getting an error from Visual Studio:

Creating an instance of the COM component with CLSID {B69003B3-C55E-4B48-836C-BC5946FC3B28} from the IClassFactory failed due to the following error: 8007000e

OK so what the hell is that about?

Well after some digging I find that it is to do with some funky MSN Messenger integration in VS.

It seems that everyone in your team is expected to have a Windows Live ID with an email address that matches that on their domain account. Now while this may be very useful someday, right now it is causing my VS to blow up and become unusable.

Well, after must head scratching (ok googling) I found a solution:

Once you click ok and wait for what seems like an age the Team Explorer will become usable again.

Right Click on the 'Team Members' section in your project and select 'Personal Settings'.

Click the 'Change' button in the 'Collaboration' section.

Select '<None>' as your collaboration provider.

Problem solved, no more annoying exception and VS is usable again ;-)

There is a trend in the IT industry that really gets my back up.

A new technology comes out, people ignore it for a while.

People come to understand the technology and start to use it.

Before long said technology is being used to do EVERYTHING, often things it was not intended to do.

I've struggled for years to come up with some way to describe this succinctly. Well, Jeffrey Snover has come to my rescue; he has coined the term 'Beer Cardinality' in this excellent post on PowerShell and DSLs.

Recently I had cause to perform a wildcard search in LINQ to SQL.

Originally I had something like:

database.Table.Where(p => p.Column == SomeValue).ToList()

The customer came back with an update to the requirement, as they do. They now wanted a wildcard search not a straight equality test. Being new to LINQ to SQL I had a quick chat with Neil and he pointed me straight at .Contains, .StartsWith and .EndsWith.

I got to wondering what the generated SQL for .Contains, .StartsWith and .EndsWith would look like.

It's fairly simple, and obvious, when you think about it;

.Contains will spit out ..... LIKE '%YourSearchTerm%'

.EndsWith will spit out ..... LIKE '%YourSearchTerm'

.StartsWith will spit out ..... LIKE 'YourSearchTerm%'

A quick Google shows me that David Hayden has already covered this, here.....

There is more to add to this story, however.

Performance.

Any SQL dba worth their salt will tell you that when using the LIKE statement, 'YourSearchTerm%' will perform much better than either of the other two options.

Again, this is fairly simple and obvious when you think about it;

'YourSearchTerm%' will result in an Index seek, the other two will result in an Index scan.

Again, a Google shows that John Kane has already covered this, here.....

Neither of these provide a full end to end picture, now you have one ;-)

So if you need to perform this kind of wildcard search in LINQ to SQL, use .StartsWith.