WPF - 3D Programming, It's Arrived...

|

Back in July Charles Petzold issued a blog post entitled "Do You Blog About WPF Programming?", which stated the following (note: this offer has now closed):

Do you blog about WPF programming? If so, please send me an email at cp@charlespetzold.com and include the following information:

  • The URL of your blog.
  • A postal address suitable for mailing a book.

Thank you!

Needless to say I requested my personal copy from Charles...  today it arrived:

31082007(011)

What's more the envelope that it arrived in was written in Charles' own fair hand! And the killer feature: he signed it too:

31082007(012)

As I said to Charles in my mail at the time of requesting the book, I promise to read it from cover to cover, then blog my honest opinion.

Thank you Charles.

And We're Done...

|

It is my last day at MessageLabs today and I have just finished clearing everything out - above is my email inbox! I wish it had always been that sparse, probably would not have been as much fun if it had been though.

As a dolphin once said:

So long and thanks for all the fish

The FizzBuzz Question

|

Yesterday a few colleagues and I were discussing the "FizzBuzz" test and how most developer job interviews do not involve actually asking the interviewee to write code!

Sure we'll talk about writing code and ask ridiculous questions about some clever nuance of the target programming environment to "really challenge the developer". This type of question will normally have a binary answer and if the developer has run into that situation then they might know; otherwise not. Would you hire the person if they nail the question? Will you truly think less of them if they don't? Honestly, they're pointless questions, please stop asking them. They will tell you nothing about the developer being interviewed, those questions say more about the interviewer than the interviewee.

Enter FizzBuzz and the many tests like it. Stop asking stupid questions in interviews and get the developer to do what you want to hire them to do: write code. Also, don't get them to solve the actual FizzBuzz problem, this has been done to death on the web, but develop your own test of this type. I also recommend that you have a follow up question that is a little more complicated but is more in line with the type of work you would expect the developer to be doing day to day, for example:

We would like you to build an application that searches for employee phone numbers based on the name of the employee.

Provide a diagram of the target environment and provide all the information that they'll need to solve the problem for you such as database schemas etc. Set a time limit and review the results together in the interview - the object is not necessarily to finish the code in the time (maybe), but to see what code was written and how. This is what you really care about when interviewing, that's what all the other type of questions are trying to figure out, right?

I'm not saying that you want all your developers to write phone book apps when they join you but you might want them to build web UI's and use Web Service middle tiers, something that this application type suggests and maybe even dictates, depending on your environment specification (I can post a full example for those who might be interested - drop me a note in the comments).

I also suggest that you base line the question; get some of the developers within your team to also take the test to get an idea of what is realistic to expect from an interviewee, without this the test is not as useful - if you have developers on your team that you would like to clone then get them to take the test, it will help.

Coding Horror Back to the original FizzBuzz test, for those that are interested I first came across the idea of this test via Scott Hanselman, but he credits the original discussion to Jeff Atwood of Coding Horror fame; if you read Jeff's post on the subject the true source is revealed there (and here for your convenience dear reader).

Like Scott, the thing I find most illuminating reading these posts is in the comments: the number of developer that feel the need to solve the problem and post the answer! Amazing!

Setting the Record Straight - Charles on WPF

|

In a post a couple of months ago I gave this book a hard time:

Some notable absences: Petzolds books on Windows Forms (1.0) and WPF; I have read both and been disappointed to say the least...

I want to revisit that assessment. I have been spending the vast majority of my reading time recently with Petzold and specifically the above book (largely since I finished the 7th Harry Potter book). It's seems that my original criticism of the book was simply due to the fact that I did not know enough about WPF to read it. This may seem a bizarre thing to say, given that this is a book that is supposed to teach you WPF, how can I not know enough on a topic before someone can teach it to me?

Let me explain: The problem is that I'm now ready for Charles' explanation of the topic, this is because I now understand it more. His style of teaching requires time, a lot of time:

Charles says on his blog:

So to me the question becomes: Is 31 days too long to learn the next major Windows programming platform, and learn it in a way where you feel comfortable coding in either C# or XAML, and you really understand a lot of the nooks and crannies? And does it really matter whether you begin with XAML on Day 1 or Day 19?

Yes, Charles, it does. It condemned this book to my shelf (and very nearly the bin) for quite some time; basically until I was in a place where I had a pretty descent understanding of WPF already.

Charles is a wonderful teacher and his way of putting things is a delight to me; however, here's the rub: the way the information is presented means that I cannot consume it fast enough; often I need to be able to understand just enough to know if the topic is something I need to learn more about - this type of tour (for want of a better word) is not in Charles' book. Only once I'd been given that tour (thanks Chris, Chris and Ian) did the need to read Charles really kick in.

I think that this book is for people who know that they want to learn WPF, completely, without compromise - for people just flicking through the topic, for people just browsing WPF, they should put the book back on the shelf. However, for people who want to thoroughly understand WPF they should pick this book up, read it cover to cover, type in and compile every code snippet - you won't regret it, I certainly have not.

Thank you Charles.

Hello / Goodbye

|

One more week and counting as I actually leave MessageLabs on the 24th August 2007; I then have a week in limbo after which I start with Content Master on the 3rd September.

For those that are interested: this is the job that I will be doing for the foreseeable future. My focus will be on all things UI including, but not limited to, WPF, Expression Suite, ASP.NET AJAX and Silverlight.

Hanselman presents: John Lam on IronRuby

|

JohnLamEven if you have no idea who Scott Hanselman or John Lam are, even if you have zero interest in the programing languge Ruby, this is still worth a look. John is a very interesting guy and if you are even mildly interested in language design and programming then I think you'll enjoy the video.

Windows Live Writer

|

WindowsLiveBetaScreenMy last post and this one was written using Windows Live Writer. It Rocks! Download it today and start posting.

The major benefits from my point of view are that it pulls the styles from your blog site, so when you're writing a post you get a more wiki like experience (see the screen shot on the right); also spell checking, plus I can write code snippets without going completely out of my mind get the layout right!

By way of an example here is the quintessential "Hello World" application:

using System;

namespace Samples
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello, World!");
}
}
}

There is no syntax highlighting or anything, but it's still a huge step forward for simple code snippets. Hooray for the Windows Live team - good work and thank you.

WPF - Dependency Properties

|
As with most things WPF, Dependency Properties, are a complete stroke of brilliance on the part of the WPF Architects and Developers. You might wonder why WPF needs another property system? That's a good question and the answer is actually quite simple: sparse storage, performance, data binding and free property change notification to name but a few.

The only pre-requisite for using Dependency Properties is that your class inherits from DependencyObject. This actually is not a "big ask"; DependencyObject is a very low level class within WPF class hierarchy, just about everything in the WPF framework inherits from it already. Here is a screenshot from Reflector, giving you a rough idea of its descendants:

DependencyObject

If you simply want to take advantage of this property system in your own classes there is nothing stopping you from simply inheriting from DependencyObject directly. Once that part of the puzzle is complete you need to define a property, a simple property for storing an integer could be achieved with code similar to the following:

public int Value
{
    get { return (int)GetValue(ValueProperty); }
    set { SetValue(ValueProperty, value); }
}

// Using a DependencyProperty as the backing store for Value. 
// This enables animation, styling, binding, etc...
public static readonly DependencyProperty ValueProperty =
    DependencyProperty.Register("Value", typeof(int),
        typeof(MyObject), new UIPropertyMetadata(1));


This code was spat out by using the Visual Studio 2005 code snippet called propdp, which has kindly been provided by the WPF team. Notice how the existing .Net property system is being employed, this makes it possible to use these easily in the XAML and adheres to one of core goals the designers of WPF from the beginning: be consistent with the current platform.

There is a “gotcha” here that I want to draw to your attention – suppose you want to validate the incoming value before setting the property, let’s say the Value property can only be a number between 1 and 5, how should we go about that?

The most intuitive thing to do would be the put some code before the call the SetValue(...) in the Value setter. This, however, will likely result in your validation code from rarely being executed, if ever, which might not be what you would expect. The reason for this is to do with performance optimizations that the WPF team have done on the property system; a side effect of this is that the traditional setters are not always called.

However, all is not lost, we can still achieve the required validation we need. The answer is in the fourth parameter in the call to DependencyProperty.Register(...) – here is an object of type UIPropertyMetadata, in our previous example we used this class purely to set the default value for the property, but it is fully defined as:


UIPropertyMetadata


This is a nice and simple class. The overload that we’re interested in is the one highlighted. The first parameter is a default value for the property, then there are two callbacks. Logically the two callbacks are fired at exactly the right time to achieve the same effect as having written code directly into the setter, before and after the SetValue(...) call. The code shown below outlines where the two callbacks are logically called:


public int Value
{
    get { return (int)GetValue(ValueProperty); }
    set
    {
        // CoerceValueCallback
        SetValue(ValueProperty, value);
        // PropertyChangedCallback
    }
}

Unfortunately that is not the end of the story. Notice that the definition of the DependencyProperty is static, therefore the event handlers for these two callbacks will also have to be static; which also means there can only be one implementation of the callback per DependencyProperty. Let’s just think about that for a second, consider this:


public class MyObject : DependencyObject
{
    public int Value
    {
        get { return (int)GetValue(ValueProperty); }
        set { SetValue(ValueProperty, value); }
    }

    public static readonly DependencyProperty ValueProperty =
        DependencyProperty.Register("Value", typeof(int),
            typeof(MyObject), new UIPropertyMetadata(0,
                OnValueChanged, OnCoerceValue));

    public static object OnCoerceScore
        (DependencyObject source, object value)
    {
        if(value < 1)
            value = 1;
        if(value > 5)
            value = 5;
        return value;
    }

    public static void OnScoreChanged(DependencyObject source,
        DependencyPropertyChangedEventArgs e)
    {
    }
}

Notice that in the coerce call we're ensuring that the value is always an integer from 1 to 5. What happens now if someone wants to inherit from this class, but their subclass can accept values from 1 to 10?

This question leads me to the crux of this what I wanted to talk about in this post, which is the best practice advice on implementing these two callbacks. The code below outlines how I would recommend solving this exact issue:

DependencyPropertyInstanceCoerce

[Note: The screenshot is showing the incorrect level of accessibility on the static event handlers, they should be set to private, see the comments for this for more details.]

The solution is to simply call virtual instance methods on the target class – this allows any future inheritors of the class to be notified and take any action they so wish. Also notice that another benefit of this approach is that all the type casting is only ever done once, in the static callback handlers.

You might have noticed that this screen shot is actually showing a code snippet being expanded in Visual Studio – yes, I have written a snippet to help the C# developers out there work with this pattern. It is freely available from here, enjoy.