HPC Windows Project back on track

After a turbulent winter, I have now resumed work on the beowulf cluster project. All my weekends and evenings for the next quarter are already spent. I wonder how I will sell this proposition to the girlfriend. Perhaps a chilvarous pitch might do the trick..."Darling, it's a climate change calculation engine..."

The next few weeks will see me configure the head node and install the SUN GRID ENGINE tools. Then the slave nodes will be configured and the obligatory benchmarking LINPACK tools will be executed to determine the cluster performance.

We have a release candidate

After weeks of tireless effort, we have a candidate release for the product I am currently working on. It's WPF all the way through. We have successfully ported a Winform application to WPF. The WPF Toolkit has proved in making this migration painless. We can use controls that we have come to know and love on the Winform UI. Datagrids, DatePickers, DateTimePickers you name it the WPF ToolKit has them. We have had to make changes to the way these controls work and this is all possible because we have the sourcecode available.

Good offshore code

Is as abundant as chicken teeth.

MVVM a view gone too far?

After spending a week spiking this for a tablet PC application, it  quickly dawned on me that the ViewModel, the data specialised for the view is really an adapter pattern. The model is adapted to suit the expectations of the WPF UI. Adapting the model for the view means that you can essentially ignore converters.

//TODO:Add code

“But it’s auto-generated, so why does it need to be unit tested?”

I recently overheard a conversation in which one developer was explaining the legacy code he had inherited to a new starter on the team. The developer described the code generators and the accompanying unit tests for the generated artifacts. Naturally the new developer asked why they needed unit tests if they were automagically making this stuff. This is a valid question and one which does beg a decent answer. I will try to answer the question based on my experience as a test-infected developer.

My response is as follows:

1. Auto-generation of software artifacts does not guarantee correctness. This is a garbage-in-garbage-out view of code generation. Engineers need to be sure that the changes that will inevitably occur in the code generation templates do not introduce defects. By running unit tests against the generated code you are testing that the generators works as they should and that specified inputs produce predictable outputs. The unit tests enforce the implied contract which stipulates that my code generator should always produce artifacts that do X.
2. Unit tests provide a reliable and repeatable way of regression testing the outputs of the generated artifacts. A change to the code templates might introduce subtle bugs. How else would you be able to detect these in the absence of automated unit testing. You are covering your own hide by having a battery of tests.
3. Unit tests allow you to develop with courage. You get immediate feedback when defects are introduced into the codebase (this assumes you are continuously running your tests, which you should).
4. The quality of the unit tests also dictates the testing experience. Several heuristics exist for developing good tests.
   

Working with legacy code

I have recently been tasked with migrating an MVC winform application to WPF. Looking at the existing codebase, I cannot reuse any of the controllers because they are very aware of the winforms view. This is fine because the controller handles gestures from the view and should thus know the view for which it controls. So we are faced with migrating the behaviour in our winforms-centric controllers to WPF controllers.

The model code is well developed as is the accompanying repository. However the need for master/detail views in WPF means that we are going to have to alter the readonly properties in the domain objects. But do we really want to change the legacy code?