Friday, March 27, 2009

Developers are artists AND craftsman not ONLY craftsman.

Let me take some time to quote and comment a friend of mine:

Forget about the “creation” part of the job. As you are developing your first application, you are not creating something. You are building something. Mind you, it’s not like building a bridge as in engineering or a plane.

from Software development is not an art. It’s a craft. by Maxime Rouiller

Developer are not just craftsman they are also artist. It’s even more true for architect. Architecture is not just about building something by assembling parts and make sure its functional. Most building architect will spent almost as much time on the look of building as on its internal structure. If that wasn’t true, our cities would have been only an ugly pile of grey steel and concrete. But when we look around we can clearly see things that are as beautiful as they are useless like sculpted arches, round towers or multicolour spotlights.

This is also true in sofware design. You just have to compare Vista to the first version of Windows (Windows 3.1 in my case) to see how much more beautiful  it is today than back then. Does that make it more useful? Does that make it stronger? Does all that is really necessary? No, no and no. In fact, some will tell that this is so useless that Microsoft shouldn’t have spent a dime on all those things. But now the trend is to talk about “user experience” and how it is important to feel great when you use a product as they said at MIX09 opening keynote. In some very successful product advertisement you don’t even see the product itself but people happy just because they own that product.

Building an application, even today, is not just putting parts together to make it work. Software development is not mature enough to be considered an exact science. You just have to think about how difficult it is to commit youself when you have to give an estimate on how long it would take you to build something. Why? Baecause every case is unique. In my life (tank god) I rarely had to build exactly the same thing twice. That would be boring for me. Every time I start something new I have to think about what would be the best solutiion to the problem in hand. Even with the same problem, solution may change based on the customer priority and constraints.

I think that develeoper and architect alike are not only craftsman, they are also artist. Let them express themselves, you will be surprised. Where are now on the eve of new era of tools that will open new possibilities of expression, tools like the Expression Suite. The reign of ugly and boring application is over. Over the next year we will witness all kind of new designs and user experiences.

Time will tell us which will survive and which will not.

Wednesday, March 25, 2009

Good practice to use Dispatcher in WPF background thread

Here is a good way to use extension method in a multi threaded context. Everybody knows that when you try to update UI from any other thread than the UI you get an “InvalidOperationException” with message “The calling thread cannot access this object because a different thread owns it.”. Look at the following sample:

Let say somewhere in your code you have this

private void Button_Click(object sender, RoutedEventArgs e)
{
    // ...
    ThreadPool.QueueUserWorkItem(DoWork, this);
    // ...
}

If you implement DoWork Like this…

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        win.progress1.Value = i;
    }
    win.progress1.Value = 100;
}

…you will be in trouble.

Because you can’t update UI from a thread other than the UI one you will get the InvalidOperationException as stated before.

The solution is to use the Dispatcher object. As from microsoft documentation:

Only the thread that the Dispatcher was created on may access the DispatcherObject directly. To access a DispatcherObject from a thread other than the thread theDispatcherObject was created on, call Invoke or BeginInvoke on the Dispatcher the DispatcherObject is associated with.

Subclasses of DispatcherObject that need to enforce thread safety can do so by calling VerifyAccess on all public methods. This guarantees the calling thread is the thread that theDispatcherObject was created on.

So our previous sample should look like this:

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        win.Dispatcher.Invoke(new Action<ProgressBar, int>((p, v) => p.Value = v), win.progress1, i);
    }
    win.Dispatcher.Invoke(new Action<ProgressBar>(p => p.Value = 100), win.progress1);
}

This is a little more work but not it works. Because we don’t want to call the Dispatcher object when it’s not needed we sould do this:

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        if (win.Dispatcher.CheckAccess())
            // We can call on the current thread
            win.progress1.Value = i;
        else
            // we need to call Invoke
            win.Dispatcher.Invoke(new Action<ProgressBar, int>((p, v) => p.Value = v), win.progress1, i);
    }

    if (win.Dispatcher.CheckAccess())
        // We can call on the current thread
        win.progress1.Value = 100;
    else
        // we need to call Invoke
        win.Dispatcher.Invoke(new Action<ProgressBar>(p => p.Value = 100), win.progress1);
}

Ouch! This is a lot more work. We cannot do that every time. That’s when extensions method comes handy. We can replace this whole process of choosing the right implementation with a single extension method. It will make our code more readable and more managable.

He is the whole extension class with all possible overload for a method called Dispatch. This method will dispatch the process only if needed:

public static class DispatcherExtensions
{
    public static TResult Dispatch<TResult>(this DispatcherObject source, Func<TResult> func)
    {
        if (source.Dispatcher.CheckAccess())
            return func();

        return (TResult) source.Dispatcher.Invoke(func);
    }

    public static TResult Dispatch<T, TResult>(this T source, Func<T, TResult> func) where T : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source);

        return (TResult)source.Dispatcher.Invoke(func, source);
    }

    public static TResult Dispatch<TSource, T, TResult>(this TSource source, Func<TSource, T, TResult> func, T param1) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source, param1);

        return (TResult)source.Dispatcher.Invoke(func, source, param1);
    }

    public static TResult Dispatch<TSource, T1, T2, TResult>(this TSource source, Func<TSource, T1, T2, TResult> func, T1 param1, T2 param2) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source, param1, param2);

        return (TResult)source.Dispatcher.Invoke(func, source, param1, param2);
    }

    public static TResult Dispatch<TSource, T1, T2, T3, TResult>(this TSource source, Func<TSource, T1, T2, T3, TResult> func, T1 param1, T2 param2, T3 param3) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            return func(source, param1, param2, param3);

        return (TResult)source.Dispatcher.Invoke(func, source, param1, param2, param3);
    }

    public static void Dispatch(this DispatcherObject source, Action func)
    {
        if (source.Dispatcher.CheckAccess())
            func();
        else
            source.Dispatcher.Invoke(func);
    }

    public static void Dispatch<TSource>(this TSource source, Action<TSource> func) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source);
        else
            source.Dispatcher.Invoke(func, source);
    }

    public static void Dispatch<TSource, T1>(this TSource source, Action<TSource, T1> func, T1 param1) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source, param1);
        else
            source.Dispatcher.Invoke(func, source, param1);
    }

    public static void Dispatch<TSource, T1, T2>(this TSource source, Action<TSource, T1, T2> func, T1 param1, T2 param2) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source, param1, param2);
        else
            source.Dispatcher.Invoke(func, source, param1, param2);
    }

    public static void Dispatch<TSource, T1, T2, T3>(this TSource source, Action<TSource, T1, T2, T3> func,
                                                     T1 param1, T2 param2, T3 param3) where TSource : DispatcherObject
    {
        if (source.Dispatcher.CheckAccess())
            func(source, param1, param2, param3);
        else
            source.Dispatcher.Invoke(func, source, param1, param2, param3);
    }
}

That seems a lot of code to write but see how it simplifies the code when you use it:

private static void DoWork(object state)
{
    Window1 win = (Window1) state;
    for (int i = 0; i < 100; i++)
    {
        // do some work
        win.progress1.Dispatch((p, v) => p.Value = v, i);
    }

    win.progress1.Dispatch(p => p.Value = 100);
}

This is almost as simple as our first implementation of DoWork. The only difference is in this version we call “Dispatch” with a lambda expression that will always be run on the UI thread.

Let me know if you find this helpful or if you think of something better.

Friday, March 20, 2009

Code Camp Montreal 2009

The next Code Camp Montreal will take place on Saturday, May 30th 2009.


Thursday, March 19, 2009

Parallel Extensions presentation @ Quebec city

I want to thanks Luc Gauthier for letting me speak at his user group. I hope that was helpful for somebody.

For those who were there (or not) here is the links where you can find the slides and everything you need to try this at home.

Wednesday, March 11, 2009

Security breach: control or trust?

I saw something disturbing today while I was visiting a big enterprise. Many people were using company property for their own needs.

I saw an employee using an enterprise’s pencil. He was using this pencil to draw pictures unrelated to his job. We couldn’t even say that was some napkin architecture. I immediately conclude that pencils can leads to unproductive work time.

Later, I saw another employee take a pencil with him when he went out to lunch. He used it to write potentially confidential information on a napkin and left it on the table. I’m now convinced that pencil can be responsible for confidential information leak.

Worst, I also saw many other things with enterprise’s pencils like, writing gross things with them, gnaw them, steal them and lost them. Have seen all this I thought, maybe we should ban all pencils! Sadly I haven’t got a chance to talk to the CPO (Chief Pencil Officer) of this enterprise.

Have I lost my mind with this entire pencil thing? You would tell me that pros of pencils are greater than cons. You would tell me that we must trust people using them. You would tell me that we must inform people of all the danger related to pencil usage. You would tell me that we must find ways to punish the offenders but for everybody else a pencil is a required piece of equipment to do the job they have to do. You would tell me that pencils are so useful to communicate ideas and people need to be informed. Anyway everybody have at least one pencil at home and they all learn how to use it at school.

That’s exactly what we do with technologies. We restrict access to all kind of messenger systems like Live messenger, Google Talk. We restrict access to software like Excel, Visio. We restrict access to email from internet café and sometimes even from home. Acting like that and adding all those restrictions we are doing worst that if we were preventing the use of pencils. I can’t imagine how many projects would have failed if wasn’t able to access my MSN or my Gmail.

Control or trust? Why not both. Control is not forbid, it’s to know what happened and react in case of problem. Trust is not being blind, it’s to inform and equip. We must inform, equip and trust our users.

Free translation from “0 ou 1 – contrôle ou confiance?

Tuesday, March 3, 2009

Why Dictionary indexer is not thread safe and how to make it

If you read my blog about why ++ operator is not thread safe you’ll know that a one line C# code doesn’t mean it is thread safe and Dictionary indexer is no exception.

Recently someone came to me and ask me: I have a static dictionary in a web application, do you think it is possible that two request try to add the same element at the same time and fails. The answer is obviously yes. Let’s see how this happens.

We will buil a sample code that wil prove the point. Of course this is not real production code but it will be easy to expose the problem. First we need a dictionary:

internal static Dictionary<string, string>() dict = new Dictionary<string, string>();

Let say, somewhere in your code you do something like this:

internal static Dictionary<string, string>() dict = new Dictionary<string, string>();

This single line of code looks better than:

if (!dict.ContainsKey(key))
    dict.Add(key, value);

but it is not.

In both cases you can encounter race condition. Take a look at how the indexer is implemented:

public TValue this[TKey key]
{
    get
    {
        int index = this.FindEntry(key);
        if (index >= 0)
        {
            return this.entries[index].value;
        }
        ThrowHelper.ThrowKeyNotFoundException();
        return default(TValue);
    }
    set
    {
        this.Insert(key, value, false);
    }
}

Ok the setter uses a private Insert method. This is where it gets worst:

private void Insert(TKey key, TValue value, bool add)
{
    int freeList;
    if (key == null)
    {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.key);
    }
    if (this.buckets == null)
    {
        this.Initialize(0);
    }
    int num = this.comparer.GetHashCode(key) & 0x7fffffff;
    int index = num % this.buckets.Length;
    for (int i = this.buckets[index]; i >= 0; i = this.entries[i].next)
    {
        if ((this.entries[i].hashCode == num) && this.comparer.Equals(this.entries[i].key, key))
        {
            if (add)
            {
                ThrowHelper.ThrowArgumentException(ExceptionResource.Argument_AddingDuplicate);
            }
            this.entries[i].value = value;
            this.version++;
            return;
        }
    }
    if (this.freeCount > 0)
    {
        freeList = this.freeList;
        this.freeList = this.entries[freeList].next;
        this.freeCount--;
    }
    else
    {
        if (this.count == this.entries.Length)
        {
            this.Resize();
            index = num % this.buckets.Length;
        }
        freeList = this.count;
        this.count++;
    }
    this.entries[freeList].hashCode = num;
    this.entries[freeList].next = this.buckets[index];
    this.entries[freeList].key = key;
    this.entries[freeList].value = value;
    this.buckets[index] = freeList;
    this.version++;
}

That’s alot of code to add an item to the dictionary. As we saw earlier, there’s a lot of “not thread safe” code in there.

The easiest way to resolve this problem is to put a lock around the dictionary operations. First we need an object to lock on. It’s always a good practice to have a separate object to lock on even though it is possible to lock the dictionary itself. We can create that object ourself but every collection already have a SyncLock object but it’s not visible because it’s explicitly implemented. To access it we need to cast the dictionary to an ICollection.

lock (((ICollection)dict).SyncRoot)
{
    dict[key] = value;
}
With this new implementation, our code should run without any problem.