RSS
Facebook
Twitter

Thursday, April 29, 2010

Four types of developers you might be doing pair programming with

A Pair Hard at Work by a2gemma.Pair programming is an agile practice – in a nutshell it means that two developers set together using the same computer to write code.

If you look for pair programming definition in Wikipedia you’ll see a very concise and detailed definition of how pair programming should be done. in my experience there are several ways to program in pair and they vary not only between different companies but also with different pairs at the same company.

The following is based on my thoughts and observation and should not be taken too seriously.

Backseat driver

In pair programming there are two distinct roles – the code writer (a.k.a. the driver) and the one who doesn’t write code at that moment (Passenger). in pair programming the driver suppose to write code while the passenger reviews it on the fly.

You’ll know a “backseat driver” pair due to the frustrated look on the driver’s face. The source of the frustration is that the passenger keep interrupting him commenting on every-single-line-he-writes. You’ll hear the passenger saying phrases such as: “This is a good idea but perhaps we can do X”, “On second thought we should…” being repeated over and over again.

If you work with such a person – keep in mind that he means well - he has great ideas and need to express them, one option is to let him drive for a while. If the problem persist tell him that you’re going to do X right now and later if it will still look like a good idea to do Y instead – you’ll refactor!

Keyboard Grabber

You know the type – the impatient developer that gets so excited by the code written that he must grab the keyboard and write code – right now!

Sometimes it happens because your co-worker knows the task better or because he has some kind of ADD, regardless of the reason working with such a person can get very annoying very fast. Be advised - as strange as it sounds this guy may not even notice that he behaves this way, in fact next time you have pair program stop for a minute and think – are you doing that right now? I know I used to.

There are some ways to handle this situation – if you’re feeling assertive you might be tempted to “fight fire with fire” and retaliate by steeling the keyboard back when opportunity arise – this might even work! I saw several such pairs and they had an harmony of sort that worked for them.

Try to set some ground rules – there is nothing wrong with telling your pair that for the next 20 minutes only you can touch the keyboard or at least let him know that his behavior annoys you and is counter productive. And if nothing else helps – try to keep the mouse (and keyboard) as far away from him as possible…

Sprinter

This guy take on look at the problem and starts writing code as if his life depends on it. If you pair with this guy you might have a feeling that you spend most of the time eating his dust.

first you need to STOP HIM, make him understand that he lost you three functions ago and make him explain what he just did.

It might be a good idea to let him rest a bit as in the passenger seat while you write some code, but beware – a sprinter can easily become a keyboard grabber so you need to set a fast pace so he wouldn’t get bored.

Silent sleeper

You’re the driver and you’ve been coding for an hour without even a single word from the other guy, when you look at him you notice that although his eyes are open he’s sound asleep code-wise. You might have run too fast (because you are a sprinter) or you might be working in a domain that you know better - it doesn’t really matter.

Sleepers at Mall - Bangkok by Sailing

The way I see it you have two options: you can act as if everything is perfectly fine and keep on working – not exactly living up to the pair programming methodology, or you need to make him part of the code – fast.

If you’ve decided not to be a selfish pig you have several options – you can give him the keyboard and let him code for a while. If you practice TDD (Test Driven Development) try this “game” – your job is to write the test and he has to write the solution, this way nobody is left out and both of you have “keyboard time”.

Conclusion

I don’t think there is a bad way to do pair programming – I’ve seen successful pairs that found the right dynamics that worked for them –  a pair of two “keyboard grabbers” or sprinters might actually work, there are no rules – some developers will strictly follow the methodology and some will find a way that will work for them.

The bottom line is you have to make sure that the person you work with will want to work with you on the next task as well.




Friday, April 23, 2010

#Nose 1.1 Released

A while back I had a build script used to build a project from its sources and run automatic tests on that code. Each time a new test assembly was added I needed to add a line to my build script to run that assembly. From time to time I forgot to update my build script causing a test suite not to run. I wished there was an automatic way to cause all of the project’s tests to run without me having to specify each assembly explicitly.

Fast forward a few months – to when I discovered IronPython and found out about Python-Nose - a test discovery tool. This seemed like a very good idea – point it to a specific location and it would be able to run all of the tests within.

Because I really wanted a such tool and because I’m convinced that other developers will find it useful I’ve decided to start an open source project - #Nose.

Supported frameworks

This is only the beginning and as such I still have some way to go. Currently only running NUnit tests and running using TMockRunner (Isolator) are supported – mainly because these are the capabilities I needed in a project I’m working on.

Adding additional framework support should be easy – and because MEF is used for the plug-in development. I can be done by anyone.

How does it work

Step 1: Configure the location of the needed “test runners” in SharpNose.exe.config that looks like this:

Under testRunners are the currently available runners – just make sure the path is correct. And if you are not familiar with one of the runners – leave it as it is.

Step2: Run #Nose - the only parameter you need to give it is the target directory.

image

What’s next?

SharpNose can be downloaded from it page on Codeplex.

 

I was thinking on adding MSTest support but I would really like to hear what you think – should I improve performance? perhaps there is a killer feature I need to add?

 

And don’t forget the let me know if you find this program useful.




Sunday, April 18, 2010

Recursion redefined

A co-worker has shown me this today – from The C programming language:

recursion

Funny…




Wednesday, April 14, 2010

Why support more? The story of MSTest…

Frustration by MarkKelley.With the new Visual Studio comes another version of Microsoft’s unit testing framework. This is Microsoft’s take on how unit testing should be done and they got a few things right – as always it’s fully integrated with Visual Studio, and with the new version comes a two exciting new features:

  1. Run tests as 64 bit process – at last I’m able to test that my code works in x64 as well
  2. Parallel execution – run your test suite in half/quarter of the time!

Yet given a choice I still prefer to work with NUnit, and I have a few good reasons – the last strew was Microsoft’s decision not to support multi targeting of the test framework.

What does it means

Not supporting multi-targeting means that once you’ve used VS2010 to run your tests they would automatically be converted to .NET 4 which means that you won’t be able to run them using older versions of Visual Studio – want to read more have a look at this bug report turned feature.

In one of the projects I work on we need to be able to run the same test suite on VS2008 and VS2010 – but we just can’t, we need to maintain two projects just to be able to run the same tests.

So what?

Although this is not such a big deal it seems to me that similar decisions can be found on every step MSTest has done on the road. For example ExpectedException not being able to verify exception message – by design, but still have a message property used for “informative purposes”. Why put a property I’m used to from other frameworks and change the way it work - that’s just confusing. And not to mention the fact that from time to time I get an bonus – instead of running just the test in a specific context all of my tests are run.

Don’t get me wrong I still use MSTest and it’s still my 2nd favorite .NET unit testing framework but sometimes it’s just frustrating to use.

I hope Microsoft will start listening to their costumers before making decisions that make us work harder than we really need to.

Wednesday, April 07, 2010

The day I understood TDD

I’ve been practicing and advocating TDD (Test Driven Development) even before I’ve started working at Typemock but I can point at a specific point of time in which I actually “got it”.

At that time I had a great mentor and I was sure I got the whole “Red-Green-Refactor” routine, In fact I knew it so well that I allowed myself to “speed development” by writing the code before the actual test.

One day while happily coding with a fellow developer we came across an interesting problem: we needed to create a value generator – a class that will return a unique value each time a method (GetNextValue) is called.

Of course being two bright and talented developers we’ve started by debating how this class should be implemented and so that it would support every conceivable type – needless to say after a few minuets we were still “designing”  and every design we had was flawed – it had a bunch corner cases that forced us to search for yet another better-stronger-faster design.

Luckily for us we had someone in the same room that saw our plight and decided to put a stop to it. What he did is remind us how TDD should be done – one test at a time.

“Write a test that checks two unique integers” – he said.

“But it won’t work for strings or even doubles” – we said.

“Do it anyway” - And we did:

[TestMethod]

public void ValueGenerator_GenerateValuesForInt_TwoDifferentValuesReturned()

{

    var val1 = ValueGenerator.GetNextValue(typeof(int));

    var val2 = ValueGenerator.GetNextValue(typeof(int));

 

    Assert.AreNotEqual(val1, val2);

}

Making that test pass was simple:

internal class ValueGenerator

{

    private static int lastValue = 0;

 

    public int GetNextValue()

    {

        return lastValue++;

    }

 

    public void Reset()

    {

        lastValue = 0;

    }

}

Not very impressive is it. We’ve decided to write another test, this time using double:

[TestMethod]

public void ValueGenerator_GenerateValuesForDouble_TwoDifferentValuesReturned()

{

    var val1 = ValueGenerator.GetNextValue(typeof(double));

    var val2 = ValueGenerator.GetNextValue(typeof(double));

 

    Assert.AreNotEqual(val1, val2);

}

After implementing the code for double we’ve decided to refactor and created a new class to handle all “numerical values”:

internal class DiscreteNumberValueGenerator

{

    private static byte lastValue = 0;

 

    public object GetNextValue()

    {

        return lastValue++;

    }

 

    public void Reset()

    {

        lastValue = 0;

    }

}

We’ve also added tests and implementations for string, DateTime and boolean values and after a refactoring the value generator looks something like this:

static ValueGenerator()

{

    var discreteNumberValueGenerator = new DiscreteNumberValueGenerator();

    generators = new Dictionary<Type, IValueGenerator>

                     {

                         {typeof (int),         discreteNumberValueGenerator},

                         {typeof (double),      discreteNumberValueGenerator},

                         {typeof (float),       discreteNumberValueGenerator},

                         {typeof (long),        discreteNumberValueGenerator},

                         {typeof (ulong),       discreteNumberValueGenerator},

                         {typeof (short),       discreteNumberValueGenerator},

                         {typeof (ushort),      discreteNumberValueGenerator},

                         {typeof (byte),        discreteNumberValueGenerator},

                         {typeof (sbyte),       discreteNumberValueGenerator},

                         {typeof (uint),        discreteNumberValueGenerator},

                         {typeof (char),        discreteNumberValueGenerator},

                         {typeof (decimal),        discreteNumberValueGenerator},

                         {typeof (DateTime),    new DateTimeValueGenerator()},

                         {typeof (string),      new StringValueGenerator()},

                         {typeof (bool),        new BooleanValueGenerator()}

                     };

}

 

internal static void ResetGenerators()

{

    foreach (var generator in generators.Values)

    {

        generator.Reset();

    }

}

 

internal static object GetNextValue(Type type)

{

    object ret = null;

    var isNonConcreteType = type.IsInterface || type.IsAbstract;

 

    if (generators.ContainsKey(type))

    {

        ret = generators[type].GetNextValue();

        return Convert.ChangeType(ret, type);

    }

 

    if (type.IsValueType)

    {

        ret = GenerateForValueType(type);

        return Convert.ChangeType(ret, type);

    }

 

    if (isNonConcreteType)

    {

    ...

We didn’t write whole of the code upfront - instead of trying to solve a big problem we’ve solves small simple problems written as tests until we had a fully working solution.

 

Since that day I follow TDD religiously – one test at a time.




Thursday, April 01, 2010

How to data bind to property in WPF

One of the strengths of WPF is its data binding capabilities. Although data binding is not new (in fact winforms has some limited data binding support) WPF takes it to the next level. In this post I’ll show you how to bind an element to a property defined in the code behind.

How it’s done?

In order to bind a property to an element on the control we need to do the following:

  1. Create a dependency property
  2. Name your user control – in XAML
  3. Bind the property to an element of your choice

Step 1 – Create a dependency property

Dependency properties are simple .NET properties done the WPF way. On the surface they look just like the properties we use since .NET 1.x came out, underneath they are actually stored in a dictionary like collection and that implementation is what makes WPF work the way it does.

You don’t need to actually know how dependency properties work in order to create them but if you do want to learn more there is a good overview on MSDN.

Adding dependency property is done by creating a new field and initializing it using DependencyProperty.Register and then using that field in the property’s setter and getter:

public partial class Window1 : Window

{

    public static DependencyProperty SomeTextProperty =

        DependencyProperty.Register("SomeText", typeof(string), typeof(Window1));

 

    public string SomeText

    {

        get { return (string)GetValue(SomeTextProperty); }

        set { SetValue(SomeTextProperty, value); }

    }

Make sure that the name of the property used to register the property is exactly the same as the property name- otherwise it won’t work.

We’re done with the “code” part – now let’s head to the XAML and create the actual data binding.

Step 2 – Define the control’s name

In order to use the property we need to address it and for that we need to define a name for our control. Choose a name and add Name=<user control name> at the beginning of the XAML file. It doesn't matter how you call the control as long as you use the same name in the actual binding.

Step 3 – Bind the property to an element

In this trivial example I’ve used the property to set (and get) the text that appears on a textbox – and the XAML should look something like this:

<Window x:Class="BindToProperty.Window1"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   Title="Window1" Height="300" Width="300" Name="UserControlName">

    <Grid>

        <TextBox Name="textBox1" Text="{Binding ElementName=UserControlName, Path=SomeText}"/>

    </Grid>

</Window>

 

And now whenever you change the value of Window1.SomeText that text will be displayed on the textbox “automatically”




Related Posts Plugin for WordPress, Blogger...