image

How do you grade how well an application is written?

There are many factors that will play a role in such an evaluation, for example (in no particular order):

  • Does the design follow object-oriented principles?
  • Does it work? (i.e. few bugs)
  • Does the code have unit tests?
  • Is the code clean (easy to read, small functions)
  • How much code duplication is there?
  • Is there valuable code comments?

Of all those qualities I will have to say readability is the most important quality, I don’t care how procedural the code is so long as the functions are small and the conditional logic written in a such a way that it is easy to follow. Don’t get me wrong I value object-orientation, the S.O.L.I.D principles and unit tests a great deal. But the majority of existing systems I have been tasked to maintain and develop new functions in seldom exhibited any those qualities.

What is usually found is a mess of procedural code where most of the code is located in the codebehind and with some common code moved to static methods on helper classes). 

What constantly surprises me is how competent and intelligent developers can create complex and functioning systems but fail to grasp the simplest of methodologies of writing readable code.

Here is some really bad code which has some of the characteristics that constantly frustrates me:

System.Web.UI.HtmlControls.HtmlInputFile objFile =
  (System.Web.UI.HtmlControls.HtmlInputFile)objControl;

try
{
  if(System.IO.Directory.Exists(strDir)==false ||
     Request["id"] != null && Request["id"] == "1" && isTpActive)
  {
    System.IO.Directory.CreateDirectory(strDir);
    
    MyApp.Business.Entities.Order order = 
      MyApp.DataAccess.Production.GetOrder((int)Request["id"]);
  }
  
}
catch(Exception ex)
{
  error = true;
  MyApp.Business.Logging.ErrorLog.Append(ex);
}

The code above is not real, I actually wrote it just show what I mean. I am having a hard time understanding how people can write code like above. Why include the namespaces in everything? This is something I constantly see and I have never understood the reason for it. Then there are the classics, like complicated conditionals that don't contain any information as what the intent of the condition is. Exception handling is also misunderstood and misused. I often find excessive capturing of exceptions, it’s like try/catch is used like guard clauses, this is very frustrating because it makes debugging and troubleshooting very painful.

Anyway, this post was not supposed to be a rant on bad code but about my realization that readability is the quality that I value most. Sure you get frustrated with procedural code that could have been so much simplified and reduced if some object orientation principles where applied but at least you don’t get a headache when trying to decipher code that is readable :)

image I have spent the last couple of days trying to find ways to parallelize GenArt WPF using Parallel.For (from the Parallel Extensions Library). In the process I stumbled upon a scenario where using Lambdas/anonymous delegates can have pretty substantial performance implications.

The code in question looked something like this:
internal void Mutate(EvolutionContext context)
{
    context.IfMutation(MutationType.AddPoint, () =>
    {
        AddPoint(context);
    });
        
    ///...
}

The function above was called in a while loop until a mutation hit was generated. I was not seeing the CPU utilization I was expecting. I was expecting 100% but got around 80% which I found strange, there was nothing that I could see that would cause a thread lock. To find the cause I started commenting out code. It was when I commented out the code above that I immediately saw the CPU utilization jump 100%. It must have been the garbage collector that caused the decrease in CPU utilization. Why the garbage collector? Well the code above will actually compile to something very different.

Something like this (reconstructed approximation of the generated IL):

public class c__DisplayClass1
{
    public GeneticPolygon __this;
    public EvolutionContext contex;

    public void Mutate__0()
    {
        __this.AddPoint(contex);
    }
}

internal void Mutate(EvolutionContext context)
{
    var lambdaClass = new c__DisplayClass1();
    lambdaClass.__this = this;
    lambdaClass.contex = context;

    context.IfMutation(MutationType.AddPoint, lambdaClass.Mutate__0);
    
    ///...
}

As you see the C# compiler actually creates a separate class to hold the lambda method body, a class that it will be instantiated every time the Mutate method is called. The reason for this is that it needs to capture the local variables (this is was makes lambdas/anonymous delegates true closures). I was well aware that this was happening but I have never encounter a situation where this has had any noticeable performance implications, until now that is.

The fact that lambda methods that use local variables will result in an instantiation of a new object should not be a problem 99% of the time, but as this shows it is worth being aware of because in some cases it can matter a great deal.

imageDeveloper Summit is a great developer conference held in Stockholm each year. This time it is being held in April spread over 3 days with two conference days between 15-16 April and one workshop day on the 17th. I am going to have talk about Dependency Inversion (the pattern/principle) and how this pattern can help you create more loosely coupled applications. The talk will also be about what Inversion of Control containers are good for and how to use them effectively.

I will also host a workshop about test driven development with ASP.NET MVC. A workshop that will be focusing on the testability aspects of ASP.NET MVC. Lab assignments could for example start with an empty controller test. I will go into scenarios where you need to use mocking/stubbing and scenarios where the MVC framework cleverly avoids mocking (by passing FormCollection to the action for example). There is also going to be lab assignments and examples that show how to use WatiN for integration testing.

Other interesting talks:

  • Good Test, Better Code by Scott Bellware
  • A Technical Drilldown into “All Things M” by Brian Loesgen
  • RESTful Enterprise Integration with Atom and AtomPub by Ian Robinson

There are many more interesting talks, so be sure the sign up if you can.

I have been playing with the WPF framework Caliburn and just to have something fun to work on I ported Roger Alsings "EvoLisa" to WPF (from WinForms).

 genArt_WPF

I have preciously ported this app to Direct3D, and to Silverlight, these ports did not work out as I had hoped (although the native C++ Direct3D port was pretty fast). The application UI architecture was inspired by NHibernate Profiler (I took a sneak peek at the code via reflector, I hope ayende don’t mind). It was the fact that NHibernate Profiler uses Caliburn that got me interested in Caliburn in the first place.

To checkout the code (Subversion): http://tlo.googlecode.com/svn/trunk/GenArtWPF/ (This is just a experimental spike to learn wpf/caliburn so no unit tests)

I recently read CODE – The Hidden Language of Computer Hardware and Software by Charles Petzold. It was a great read and a book that I can recommend to anyone who whishes to understand how computers really works at the most basic level. The book goes into great detail on how binary systems work, and how computers use binary numbers to encode things like positive and negative numbers, alphabet characters, fractions, etc. But the main part of the book is about how to solve logical problems using simple relays (i.e. transistors) connected in different ways.

During the different chapters Petzold  is building a more and more complex logical machine that ultimately resembles how a real modern computer work. He starts out with building simple logical gates (AND, NAND, OR, etc) out of relays, he then combines these into more complex units, for example a 1-bit adder and a 1-bit latch.

Most of the stuff in the book was not really news to me but it was interesting non the less. I had forgotten how computers actually perform subtraction by using addition for example. It is pretty neat trick. The trick is to convert the number you are subtracting into two’s complement. Here is an example showing how you can calculate 7 – 5 with only using NOT and ADD operators.

image An easier way to understand how this works is to try it with the number range 0-59.

  59
-  5
====
  54
+  1
====
  55
+  7
====
   2

Here we actually have to use subtraction to calculate the complement, the nice thing about twos' complement is that it can be calculated using the binary NOT operator.

Ok, back to the book. The last chapters cover how computers are programmed, he describes in great detail how for example the stack work, how you call and pass parameters to subroutines and how interrupts are used to respond to hardware events like a button being pressed on a keyboard. Again nothing new to someone who has worked with assembly language or taken some basic classes in computer science, but it was nice to to refresh the knowledge and fill in some gaps.

I first bought this book to give to my father who has trouble understanding and working with computers. He is constantly frustrated by the simplest things so I thought that it would help to have some understanding of how computers work. However I am not going to give this book to my farther, after the first couple of chapters the book quickly becomes very technical and tedious for someone who isn't that interested. But for any programmer who doesn't already know the fundamentals of computer hardware and software or just want to refresh their knowledge it is a great read.

In Atwood's latest post The Ferengi Programmer, he argues that the OOP design guidelines and specifically Robert C Martin's S.O.L.I.D principles are rules that hinder critical thinking and can be dangerous. It is a complete straw man argument, there is no one who advocate that these principles should be viewed as absolute rules that should be followed blindly without critical thinking.

The most interesting and scary thing with Jeff's post are the comments, like:

"I'll tell you one thing, the Gang of Four book is probably one of my most disappointing programming reads of all time. Completely useless to me. Strange that I can have a successful programming career without understanding that book..."
Anyway, in Rob Conerey's response post there was this great comment by David Nelson in which he makes an analogy with chess rules:

"In chess there are a set of rules that are taught to every beginning player: a queen is worth three minor pieces, develop knights before bishops, always castle, etc. But as a player improves, he learns that these are not actually rules, they are generalities. Over the course of analyzing many hundreds of thousands of games, good players have discovered certain strategies that are more likely to lead to a winning position. But just because they are more likely to be better, doesn't mean they will always be better.

As a young player, I would often see an opportunity that I thought would lead to a quickly won game, by trying something other than what the "rules' would indicate. More often than not, I discovered that I was falling into a trap. Had I only followed the rules, I would have been better off. A player has to get very good before he can reliably understand when the rules don't apply.

The point is that just because I know that the rules don't always apply, doesn't mean that I should ignore them and go my own way. I have to factor in both my own experience, and the "rules", which are derived from the experience of thousands of players before me who were better than I am. And I have to weigh each of those factors appropriately. The better I get, the higher I can value my own experience. But even grandmasters work from a standard opening book.

I know of no other industry in the world where the craftsman are so strongly resistant to learning from the mistakes and lessons of those who have come before. I think that it is mostly the result of the technological boom in the last two decades; we haven't had time to develop the educational process to teach programmers what they need to know, but we need the warm bodies, so we will take anybody who will sign up. Even those who are ignorant and unwilling to actually learn what they're doing."

It is a great analogy, not that I know much about chess. I did read a book about chess strategy many years ago but can't say I remember much from it.  What I like about the analogy is the way it pictures guidelines and principles as a way to turn novice chess players into masters and how experience will eventually let you know the scenarios where the principles don’t apply. I also like the line “But even grandmasters work from a standard opening book” :)

For more comments, read Justin Etheredge response.

I have been working with a WPF app on my spare time. I decided to use the WPF application framework called Caliburn. Caliburn is a lightweight framework that aids WPF and Silverlight development considerably.

Caliburn Goals:

  • Support building WPF/SL application that are TDD friendly.
  • Implement functionality for simplifying various UI design patterns in WPF/SL. These patterns include MVC, MVP, Presentation Model (MVVM), Commands, etc.
  • Ease the use of a dependency injection container with WPF/SL.
  • Simplify or provide alternatives to common WPF/SL related tasks.
  • Provide solutions to common UI architecture problems.

How does Caliburn work? A big part of WPF is it’s strong data binding functionality, however WPF control event handlers are normally defined in the control or view code behind. Caliburn lets you route using a declarative syntax control events to normal methods on your data bound presentation model.

Example:

<UserControl x:Class="GenArt.Client.Views.TargetImageView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Action.Target="{Binding}"
    >
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto" />
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>

        <Border Style="{StaticResource TargetImageBorder}">
            <Image x:Name="TargetImage" Source="..\Resources\Images\ml.bmp" Grid.Row="0" MinHeight="150" MinWidth="150"></Image>            
        </Border>
        <Grid Grid.Row="1">                            
            <StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">
                <Button Height="Auto" Message.Attach="[Event Click] = [Action BrowseForTargetImage] : TargetImage.Source">Select Target Image</Button>
                <Button Height="Auto" Message.Attach="[Event Click] = [Action StartPainting] : ">Start Painting</Button>
            </StackPanel>
        </Grid>
    </Grid>
</UserControl>

The first interesting Caliburn part is the attribute Action.Target="{Binding}" set on the top UserControl. This tells Caliburn that the action target is the current data binding instance (that is a presentation model). The second is the attribute Message.Attach="[Event Click] = [Action StartPainting]” set on the last Button Control. This two is a Caliburn WPF extension to declaratively attach the button click event to the method StartPainting.

The StartPainting method is defined on the class named ApplicationModel (this is the top, root data bound class for the entire WPF app).

public class ApplicationModel : PropertyChangedBase, IApplicationModel
{
  private DrawingStatsModel stats;
  private PaintingCanvasModel paintingCanvas;

  public ApplicationModel(GenArtDispatcher dispatcher) : base(dispatcher)
  {
      stats = new DrawingStatsModel(this, dispatcher);
      paintingCanvas = new PaintingCanvasModel(this, dispatcher);      
  }

        
  public ImageSource BrowseForTargetImage()
  {    
    //...
  }

  [AsyncAction(BlockInteraction = true)]
  public void StartPainting()
  {
      ///...
  }

}
As you can see Caliburn can route WPF control events to normal methods, methods can have arguments taken from other WPF controls, methods can return values that Caliburn can use to update control properties (as in the case of the BrowseForTargetImage that returns a ImageSource). This is very powerful as it almost allows for an MVC like separation between UI and the underlying presentation behavior.

Threading

Caliburn also makes async actions dead simple, if you need to have a WPF event handled in a background thread (so that it doesn't lock the UI) you only need to add a AsyncAction attribute. When the BlockInteraction parameter is set to true Caliburn will disable the WPF control that initiated the event and re-enable it when the action completes.

Almost all logic in a WPF app should be handled in a background threads however all UI interactions need to be done on the main UI thread. This can be handled easily by using a Dispatcher and a base class PropertyChangedBase.
public abstract class PropertyChangedBase : INotifyPropertyChanged
{
    protected GenArtDispatcher dispatcher;

    public PropertyChangedBase(GenArtDispatcher dispatcher)
    {
        this.dispatcher = dispatcher;
    }

    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    #endregion

    protected void RaisePropertyChanged(string propertyName)
    {
        var ChangeEvent = new ChangeEvent();
        ChangeEvent.PropertyName = propertyName;
        ChangeEvent.Source = this;
        dispatcher.Invoke(ChangeEvent);
    }

    public void RaisePropertyChangedEventImmediately(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}
This class is very important if you want your data bound WPF presentation model to be able to automatically update the UI by just raising a PropertyChanged event. The WPF infrastructure will subscribe to this event for all data bound classes. The dispatcher part is used so that the event is always raised on the UI thread, this is powerful as you can set presentation model properties without having to think about which thread you are in. Example:
private void UpdateStats()
{
    Fitness = Math.Max(0, MaxFitness - model.EvolutionProcess.CurrentFitness);
    Generations = model.EvolutionProcess.Generations;
    SelectedGenerations = model.EvolutionProcess.SelectedGenerations;
}

public double Fitness
{
    get { return fitness; }
    set
    {
        fitness = value;
        RaisePropertyChanged("Fitness");
    }
}
I was very impressed with Caliburn and how it makes WPF development easier. It allows you to move some of the code you would normally write in a code behind class or in a presenter directly into the presentation model and at the same time making this code easier to unit test. There are still scenarios that would require presenters but I think a majority of UI interactions could be handled using Caliburn in this way. There are more to Caliburn than I have mentioned in this post, so be sure to check it out yourself!