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.

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” :)

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.

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:
{
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