My Favorite Programming Tool

The index card

Coding Should Be Fun

Call me a nerd, but reading this made me laugh out loud (in a good way) :

public interface IHeisenView
{
    void ShowView();
    void HideView();
}

WinForms MVP & IoC

I’m an avid advocate of the Inversion of Control principle. I’ve used Castle Windsor on a couple of occasions in the past, and everytime it has saved me a lot of code and a lot of headache.
It had been quite a while since I had been involved in a project that has a Gui. The one I’m involved with now has one, a WinForms one. We went for the MVP approach (seemed a bit like old wine in new bottles to me, but hey what’s in a name).
I wanted the Program.Main to look something like this :

static void Main()
{      	  
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    AuthorizationInfoDto authorization = 
		new CommandLineArgumentParser(Environment.GetCommandLineArgs())
			.GetAuthorizationDto();
    IMainFormPresenter presenter = IocContainer.Resolve<IMainFormPresenter>();
    presenter.Initialize(authorization);
    Application.Run((Form)presenter.View);
}

So of we go registering presenters & views as components into our container. This works fine if we have only one View. Leaving us with this familiar looking ‘thang’ :

Unfortunately the WinForms designer generates this kind of code for any of the child views :

this.childView = new ChildView();

Replacing this by :

this.childView = Container.Resolve<IChildView>();

would MakeItWork, but it’s not very elegant, and, even though I found this a minor issue as I don’t use the tool, it breaks designer support. My colleagues however, who are convinced that spending fifteen minutes dragging controls around on a screen until you get them all alligned, is more productive than quickly changing the coördinates in code, would start a riot.
Castle Windsor to the rescue. In the constructor of the ParentView we now register the attribute as an instance in the container, like so :

Container.Register<IChildView>(Component.For().Instance(this.childView));

And we end up with something like this :

Which makes the Program.Main behave just as I wanted to.

Hey Man, Now You’re Really Living, Part II

For those amongst you, who like their music slightly less polished than P12 sanding paper, live near Antwerp, and have nothing particularely interesting planned for the evening : I-H8 Camera will perform at Salle Jeanne Simons, Turnhoutsebaan 5, 2100 Deurne. Details are sketchy as choatic e-mails about P.A.’s, mic’s and kitchen-sink’s have been passing me by. The kitchen sink, I found dissapointing, isn’t going to be able to make it, as it’s musician seems to have recording engagements somewhere else.
Possible lineup :
Craig Ward, Heyme Langbroek, Younes, Boots, Elko Blijweert, Teuk Henri, Bert Lenaerts, me, Jeroen Stevens, Eric Thielemans, Rudy Trouvé.
Not sure about the last three and I can’t put a face to this Younes guy.
It seems Sleeping Dog will also perform.

Hey Man, Now You’re Really Living, Part I.

using( GetRepository<Product>().Save( product ) ) { }

Avoiding Having to Resort to Net-Psychology.

‘Coz I ‘ken hate psychology. Probably even more than Elton John. Cris Martin could give it a run for it’s money, maybe. And no, not as much as Phil Collins.

I’ve had quite a bit of views. Mainly due to incoming links. Yet, not one single comment. Apparently there’s a scientific reason for this. But, as I’m really not interested in investigating and/or exploiting this, I’m just gonna get down on my knees and beg for someone to be the first one to comment on what he’s read on this blog.

QuickNet Pre Alpha

Well the source is on google code, so anyone who’s interested, has a subversion client, and possesses some googling skills can download the code and play around with it.

For now it’s just the core code, and a project containing some examples of usage.
I’ve produced quite a bit of experimental code regarding QuickNet, but managed to keep it external to the core logic. In the experimental phase, amongst others there’s a QuickNet.Gui (look and feel quite similar to the nunit gui runner), a QuickNet.AssemblyRunner (for easy integration with TestDriven.Net), a QuickNet.FactRunner which allows you to define transitions and properties in a more imperative way, a plugin for SharpDevelop, … .
The source on google code is stripped of all of this. It contains just enough logic to run the examples demonstrated in the previous QuickNet blogposts, with the exception of the ForEachProperty functionality described in the ‘Testing QuickDoc’ post. This has been moved out of the core. There now exists a FunctionalTestRun extension dll that provides this functionality.

As I said : PreAlpha.
Some things you should notice quite soon after getting the source :
- Some of the code is a mess.
- There’s not a lot of unit tests.

I’d say both issues are related.
I believe tests are required as soon as more than one person gets involved in a project. Helpfull before then, possibly, and even likely, but not required. When I develop something on my own, most of the time, writing tests speeds up development, so most of the time I write tests.
Not so with QuickNet. TDD’ing it just didn’t work. For one, it is pretty damn hard to test a tester, particulary so if the tester displays non-deterministic behaviour.
However moving towards an alpha release and in getting other people involved, the need for automated tests is becoming increasingly apparant. Hence I’ve commited myself to documenting every new feature, or change to existing functionality, with a test. So far this turned out to be doable (there’s only six of them right now though, … early days).

I’m hoping that now that I have a vague idea about what is going on, defining (human-readable) tests for the more complicated stuff will become a possibility.

For the ‘alpha release’, which should become reality in about two weeks from now, I’m thinking about getting the QuickNet.VisualTestRunner extension working. It contains a Visualizer which is intended to become the Facade for any QuickNet Gui test runner.
A concrete implementation should be included, and I’m probably going for the SharpDevelop plugin option.

If you try it out, please do let me now what you think about it.

Talking ’bout my Generation

As shown before QuickNet’s shrinking capabilities comes from a concept known as Generators. Let’s dig a little deeper. Here’s the code for the IntGenerator class :

public class IntGenerator : BasePrimitiveGenerator
{
    private readonly int min;
    private readonly int max;

    public IntGenerator(int minValue, int maxValue) { min = minValue; max = maxValue; }

    public override int[] SimpleValues()
    {
        return new int[] { -1, 0, 1 };
    }

    protected override int RandomValue()
    {
        return Seed.Random.Next(min, max);
    }

    public override IGenerator GetProtoType()
    {
    	return new IntGenerator(this.min, this.max);
    }
}

As you can see it derives from (the rather messy at the moment) BasePrimitiveGenerator class and overrides some methods.
RandomValue() is the interface that, you guessed it, supplies a random value.
GetProtoType is required mainly for cloning generators.
SimpleValues is used for shrinking. Suppose we have a function taking one int as a parameter and somehow it chrashes when it receives a 10. When QuickNet generates this and the testrun fails, The value 10 (from the IntGenerator) is replaced (one at a time) by the values in SimpleValues and the test run is retried. If the test run fails not only with the original value, but also with all of the simple values, we know that the input is irrelevant. If however passing in one of the SimpleValues succeeds the test, the input is relevant and needs to be reported. This is one of the shrinking strategies in QuickNet.

Imagine the following class :

public class Calculator
{
    public string Model;
    public int Price;
    public override string ToString()
    {
        StringBuilder sb = new StringBuilder();
        sb.AppendFormat("Model : {0} ", Model);
        sb.AppendFormat("Price : {0} ", Price);
        return sb.ToString();
    }
}

The (too verbose) definition of a generator for this :

public class CalculatorGenerator : BaseGenerator
{
	public override IGenerator GetProtoType()
	{
		return new CalculatorGenerator();
	}
	
	public CalculatorGenerator()
       {
            AddGenerator(
    		new EmbeddedGenerator()
        	{
        		Label = "Model", 
        		Getter = (target) => target.Model,
        		Setter = (target, value) => target.Model = value,
        		Generator = new StringGenerator( 4, 8 )
    		},
    		new EmbeddedGenerator()
        	{
        		Label = "Price", 
        		Getter = (target) => target.Price,
        		Setter = (target, value) => target.Price = value,
        		Generator = new IntGenerator( 0, 20 )
    		});
	}
	
	protected override object RandomValue()
        {
    	    return Generate(new Calculator());
        }
}

I’m sure you can see the possible refactoring in the constructor, where I use quite a bit of code just to hook up a generator to a property.
This class inherits from a BaseGenerator class, which defines the shrinking algorithm for complicated objects.
All this together with an abstract CollectionGenerator class is enough to get a shrinkable random value of any class, although at the moment it still takes quite a bit of code to put it all together.
For instance suppose we have a CalculatorSalesManGenerator class and

new CalculatorSalesManGenerator().GetRandomValue().ToString()

returns:

FirstName : \lweow 
LastName : qeutpwm\fooq 
HourlyWage : 75 
HoursWorked : 31 
TimesBrokenTheNightlyCalculator : 1 
BusinessTrips : 0 
CalculatorsDropped : 2 
CalculatorsSold : 
    Model : s[iwl Price : 10 
    Model : hd^h Price : 16 
    Model : ulj` Price : 12 
JustAnIntList : 
    4
    4
    2

This shows you the class's properties.
The class also contains the following method :

public int DivideSomethingByThePriceOfTheLastCalculatorSoldIfAny()
{
        if(CalculatorsSold.Count==0)
            return 0;
	return 100 / (CalculatorsSold[CalculatorsSold.Count-1].Price);
}

Testing this, QuickNet correctly only shows us the list of CalculatorsSold, displaying irrelevant elements as ‘-’ and rendering the guilty Calculator (not showing the property Model as it is irrelevant to the failure).

FAILURE
CalculatorSalesMan.DivideSomethingByThePriceOfTheLastCalculatorSoldIfAny : Success
An unexpected exception of type System.DivideByZeroException was thrown !
After 1 tests, 53 transitions.
------------------------------------------------------------
Transition : CalculatorSalesMan.DivideSomethingByThePriceOfTheLastCalculatorSoldIfAny : 
Input : CalculatorSalesMan
  CalculatorsSold : 
    -
    -
    Calculator : Price : 0

The original QuickNet (which was not intended to be a reusable solution) used a custom shrinking strategy. The input for the project it was used for at first, was quite easy to simplify according to a couple of rules. QuickNet itself did not have shrinking capabilities. The generators’s only purpose, at that time, was to supply random values.

Getting this feature fully working in the new QuickNet made me smile .