Adventures while building a Silverlight Enterprise application part #27

It's been a while again, but it's been a bit of a hectic time. I've been approached by the good people of silverlightshow.net, who have invited me to write some articles for them, but more on that later. I've also been struggling with something I've seen coming, but underestimated, fear of change. That's what today's post is about, fear of change in a software company.

The background
When I got hired at the company I've been working for, for over a year now, the main purpose was to take the current development team, which has been developing in older technology for a long time, and help them to take full advantage of the latest Microsoft technology. Back then I took some time to think about the challenges I might face. One of the things I quickly realized is that fear of change would eventually become an issue. I never imagined it to be this strong and though to overcome.

As we started discussing how the new system should look the other developers where thrilled and everything looked good, but as time progressed and team members became more aware of the changes on different levels, some team members started to revert back to old ways. At times this has been fed by non-technical colleagues, some times it is fuelled by the fact that a lot of custom code is outstanding with customers, and quite a few times this is caused by a fear of change by some of the developers themselves.

Now, this all sounds very negative on a team I'm part of myself, however I've seen it happen a lot of times and I know a lot of others are struggling with the same thing. Do you hear sentences like "We've always done it this way and it works" and "I've seen that approach fail catastrophically once" as if they are arguments to not change anything? I hear them at least once every couple of weeks.

Why is fear of change a problem?
One might argue that this is not a problem. Just do your job and that's that. As long as the software you build fulfills the users needs, you're a winner, right? Well, no. With the old version of the software we keep seeing issues with maintenance, deployment and running it in a web environment. This makes maintaining the software expensive and complicated and it limits us in what we can do. All the more reason to do things differently, right?
So from a business perspective not changing things will eventually cause problems. Does that mean that the old software was bad? No. The point is that the environment the software has to work in combined with the requirements that are put on it, change. This means changing the software becomes inevitable.

Take Windows for example. The kernel that was originally build for Windows NT back in the late eighties was a great peace of software engineering and it worked fine for many years providing great stability to several incarnations of the Windows OS. Only in the past couple of years, the IT landscape started changing in terms of what was expected from a kernel. More and more people started using multi-core CPU's even in their PC's and multi CPU PC's are starting to emerge in the market place more and more. So Microsoft made a decision to rewrite part of the NT kernel to better support these multi core systems in a more efficient way. Though? Sure. Scary? I'd say so. But that didn't stop them from doing it and this change is now part of Windows 7. Again a stable OS, no end-of-the-world-as-we-know-it scenario's, just another major release of Windows. Sure, it must have caused the people working on it some blood, sweat and tears, but they can look back at a great achievement.

So "we've always done it this way and it works" is not really an argument to not change anything. The fact that it works doesn't mean it can not be improved upon, adapted to new possibilities and requirements. In fact, whenever someone says this to me, it makes me want to change it even more, not for the sake of it, but because it makes it all the more evident that the team needs that change in order to move forward.

The other one, "I've seen that approach fail catastrophically once" and less drastic expressions along the same line are another expression of fear. So it failed last time you've tried it? Great, that means you have experience and you know some of the pitfalls already. All the more reason to try that approach again and succeed.

So now what?
So what am I going to do about it? Fight. This may sound simplistic, but it starts with that. I realize that every change I'd like to make to the system is possibly going to be a struggle. Some of these might even fail.
Preparation is key here. It will take a lot of thought to determine what changes might be subject to resistance and what arguments I'm going to bring to the table to convince both technical and non-technical colleagues that this change is necessary and good.
Another help in this is to get others aware that this fear of change is actually there and is a problem for moving forward. In the end any help is welcome.

That concludes this episode, which I hope helps people to better understand this problem. Another great article on this I came across is written by Alexander Johannesen and can be found here.

Message framework design considerations

A while back I posted some thoughts on using a message framework as a way of abstracting part of the distributed computing problem. I stated I would start and write some code and so I have. On the way I had to make some interesting design decisions I wanted to share with you. This article is about these decisions and what where some of the reasons I made these.

Targeting the right objects
One of the first things I had to make a choice about, was how to target the right objects. Basically I needed two scenarios.

The first scenario is that Object A needs some task to be done by an object of type B. In this case Object A doesn't care what instance of type B actually does the job. It doesn't even care where this instance might be. In this case Object A should send out a message targeting type B. This means using a fully qualified class name as the receiver address.

The second scenario is that Object A sends out a message to notify other objects but it doesn't know which objects might be interested in the message. In this case other objects should register themselves with a dispatcher, stating that they are interested in some type of message. In this case Object A shouldn't include a receiver address at all.

But what about interaction with the system? This wouldn't be sufficient in a multi user scenario, because you can't target a specific instance of an object, which would be needed to actually give feedback to the user. I've decided that being able to target a specific object is not part of the low level messaging. To achieve a scenario where you need users to only receive their own messages back, there should be a layer on top of the existing messaging.
I chose this approach because it would be highly impractical to keep track of individual object instances across the entire ecosystem. Remember that one statement is that an object can be anywhere and it shouldn't matter for sending a message. By introducing unique addresses per instance, now it starts to matter, because a sender needs to know these unique addresses.

Interprocess communication
Another important aspect of the messaging framework is the communication between different processes. Again an object can be anywhere, but also anything .NET should work. I've investigated on using WCF, because this is obviously a very flexible and configurable way of communicating, scaling out from local (on the same machine) to global (across the internet). However it does put some bloat on the framework for people who don't want to use it.

I've also considered using Microsoft Messaging Queue, which kind of makes sense for a messaging framework. However this would involve building several tools around MQ to make sure all process types would be able to access the message queue and it would also put a deployment strain on the framework, beyond what I find is acceptable.

I settled on WCF, which doesn't mean that MQ is completely discarded. In the future it might prove valuable to actually build libraries around MQ to incorporate it into the framework. It does mean that by default every process includes code for both a WCF host and a client. However these are only instantiated as soon as a process is attached to another process.

IMessageReceiver
To indicate that an object can recieve messages, it is needed that it implements the IMessageReceiver interface, which only contains one method (at least for now) that's called RecieveMessage. It takes a single parameter of type IMessage. The IMessage type has two properties, Sender and Receiver which are both strings (for containing the fully qualified classnames of the objects involved in the communication).

MessageDispatcher
To make sure objects don't have to worry about getting a message to the receiver, every process should have exactly one MessageDispatcher object, who's sole responsibillity is to collect messages and dispatch them to the right objects and/or to other processes as needed.

To attach to another process in the ecosystem, the process in question has to make a request to the other process. Because we already have a message in the processes interface, that's exactly what I want to use. I've introduced a FrameworkMessage type that implements IMessage, so I can send it across to another process, in effect registering as a client to that process. To make sure the other process can also communicate back, it's response is to send a registration message as well, to make itself known as a client process as well.

Conclusion
As you can see there is a lot to think about when building a messaging framework. I'll keep working on this every now and then. Next time I'll try to get some code in.

Adventures while building a Silverlight Enterprise application part #26

The other day I ran into a scenario where I would need to databind to some primitive type variables like a bool or a string. As I didn't want to build class after class to solve this, I sought after a more generic solution. This article describes that solution.

The requirements
The requirements are simple:

• I should be able to databind to any primitive type
• The solution should be easy to use
• The solution should require as little code as possible

Analysis
Analyzing this I quickly realized a generic class, wrapping the actual variable might would be a nice solution. I started with this:

public class BindableObject<T>

A simple class declaration taking in any type. Obviously I needed the class to support binding to it's properties, so I included the INotifyPropertyChanged interface in the declaration and I implemented the PropertyChanged event and a method to trigger that event.
I also needed to expose a property to contain the actual value, so I included the Value property and it's private field.

Now I would write something like:

BindableObject<bool> someObject = new BindableObject<bool>();
Binding someBinding = new Binding("Value");
someBinding.Source = someObject;
someBinding.Mode = BindingMode.TwoWay;
textBox1.SetBinding(TextBox.IsEnabledProperty, someBinding);

As you can see, this is still quite elaborate. I decided on adding a method to do the binding inside the BindableObject class. I ended up with a class that looks like this:

public class BindableObject<T> : INotifyPropertyChanged
{
private T _value;

public T Value
{
get
{
return _value;
}
set
{
_value = value;
DoPropertyChanged("Value");
}
}

public void BindTo(FrameworkElement element, DependencyProperty property, BindingMode mode)
{
Binding binding = newBinding("Value");
binding.Source = this;
binding.Mode = mode;
element.SetBinding(property, binding);
}

#region INotifyPropertyChanged Members

private void DoPropertyChanged(string propertyName)
{
if (PropertyChanged != null)
{
PropertyChanged.Invoke(this, newPropertyChangedEventArgs(propertyName));
}
}

public event PropertyChangedEventHandler PropertyChanged;

#endregion
}

It's a fairly simple class. You can now write the previous example like this:

BindableObject<bool> someObject = new BindableObject<bool>();
someObject.BindTo(textBox1, TextBox.IsEnabledProperty, BindingMode.TwoWay);

I'm pretty happy with this and I hope it proves useful to you too.

Developers 42 online for one year!

Today is the day, Developers 42's first anniversary!
In this post we'll look back to see what was hot and what was not. We'll also look forward to the coming year. You now, make plans, decide where to go from here, etc.. And of course their will be some words of gratitude as I couldn't have done it all by myself.

The past year
On October 1st 2008, I started to work for a new company in a role I hadn't been in for years. I was going to work on a product again. I decided I needed a blog to keep track of what I do and to share some of my experiences with you out there. It took some preparation, but on October 9th 2008 my first post went online. It was about a trick to layout a report in Reporting Services 2005 and in the first week it got... wait for it... zero hits, nothing. Obviously no one actually knew about my blog and I felt I needed to keep it that way until I was having some more content online.
This went on for a while, until I posted this article, called Lookup Combobox in Silverlight 2. Now hits started dribbling in, still one at a time, but they did come. This article proofed to be a winner. It is actually the single most visited article of the past year, with 1169 unique page views, it is only second to the home page.

My big break came on October 26st, when an article I wrote a couple of weeks before was picked up by Dave Campbell and put on his Wynapse Blog. All of a sudden page views skyrocketed to 148 unique views the next day! Things didn't slow down until March 2009. By then I hit a pique of 306 unique views on February 20th, which is still the all time high.

But having page views isn't the only thing. I looked at the RSS feed stats and there is the real cool stuff. The feed has seen a steady growth throughout the past ten months, from 5 to 10 subscribers in December all the way up to around 85 subscribers right now. How cool is that?
Check out the graph:

And I've done some stuff as well. I published beta 1 of CodeEmbed4Web (not with great success unfortunately). I've written 25 posts in the Adventures series and I now have my articles published on CodeProject.com as well. Some of my articles are getting serious hits there, exceeding anything I get on my blog. Overall it's been a hectic year with ups and downs, but I'm still happy to be here.
What kept me going was a comment every now and then with a 'Thank you, I needed that.' or a 'I was stuck on this and you fixed it' kind of message. These are a great encouragement to keep posting.

Plans for the coming year
As I promised, I'll also give a peek into what we want to do next year. Off course I'd like to see some growth in traffic, both through the site as well as through the RSS feed. But that's not the only thing. I'm still working on moving the blog to a new custom platform. In fact I've got something to show you right now:


This is the new logo. The music was done by Kevin MacLeod. You can find his website here.

I'm still planning on releasing CodeEmbed4Web RTM. As for true content, I'm looking into doing more nitty-gritty stuff on C# and .NET, maybe diving into some of the inner workings of the framework, especially with the launch of C# 4.0 coming up.

Some words of gratitude
There are some people I'd like to say thank you to. First of all I'd like to thank Dave Campbell for sending all this traffic my way. I'd also like to thank Sean Ewington from CodeProject.com for being a great help with publishing my articles there. Another thank you must go to Drew Bennet from I'm not a famous blogger. His work encouraged me to go on when things didn't go so well.
The last big thank you goes out to you! Yeah, you there on the other side of the line, thanks for being here.

Callout to all readers
Please let me know if there are things you'd like to see changing on my blog. It could be there is some subject you'd like to see discussed, it could be you'd like to see a different format, have more content or less, or you just don't like the font I use, but please give me feedback so I can improve.
Another thing I'd like to ask you all is to spread the word if you really like my blog or a particular article. Please let your peers know.

Thanks again, and I'm looking forward to your comments.

Adventures while building a Silverlight Enterprise application part #25

In the previous episode I discussed how an enum can be used to encapsulate char values in a database, in this case using a Gender enum as an example. As cool as that was it does pose a problem with databinding in Silverlight that I'd like to share with you. Part of that explanation leads us into the realm of reflection (that would make for a cool blog title :) ) and then into some cool trick in binding, all to end with a bit of a dissapointment. So if you already feel depressed, stop reading now :-P.

The story
First there was a BussinessObjectBase. This class handles a lot of stuff around transporting data between the service and the client and back. It also helps in keeping track of property changes and notifies about them. It's a very generic class and it serves as a base class for all our 'business' objects.
In this case let's say there is a PersonBase class, that is derived from BusinessObjectBase. PersonBase is generated based on some metadata, so we don't want to touch this source. The PersonBase class has a property called Gender that is of type string.
Then there is the Person class, which was generated but is meant to be used for custom code, so this is where we will write some code to make our Gender available as a Gender instead of a string.
We could simply write something like this in the Person class:

private char GetGender()
{
string gender = base.Gender;
if (gender.Length == 0)
{
return DefaultGender;
}
return gender[0];
}

public Gender GenderValue
{
get
{
return (Gender)GetGender();
}
set
{
base.Gender = ((char)value).ToString();
}
}

Our intention here is to hide the base implementation of the Gender property and have our own implementation that returns an actual Gender enum. Nothing special so far.
Next step is to use this new property in a databinding scenario. Here is what the binding statement in XAML would look like.

{Binding Path=Gender, Mode=TwoWay}

Now if you'd try to use a binding statement like this and run the code, what would happen is, that you would get an AmbiguousMatchException, the reason being that the binding engine can't distinguish between PersonBase.Gender and Person.Gender.
What? But we wanted to hide PersonBase.Gender, right? Absolutely, but both properties are public, so both are actually available.

Reflecting on the 'new' property
To get a better understanding of why this was happening, I decided to write some reflection code:

object person = newPerson();
object personBase = newPersonBase();

Type personType = person.GetType();
PropertyInfo personGenderProperty = personType.GetProperty("Gender");
MessageBox.Show(personGenderProperty.GetValue(person, null).ToString());

Actually trying to get the value of the Gender property through reflection threw the AmbiguousMatchException, just like it did when databinding to it. Actually calling personType.GetProperties from the Immediate Window in Visual Studio returned both properties. Then the exception all of a sudden makes sense.

What might seem a bit akward is the fact that both properties are there. If I'd try to write string gender = somePerson.Gender where somePerson is of type Person then it would not compile because I can't implicitly cast this, proving that the base property is actually hidden. Still, having the property available is needed, because the derived class needs to be able to call the property in the base class.

Trying to bind to it anyway
Still, I needed to find a way to bind to this property. I came up with some simple solutions:

1. Make the base property protected
2. Rename one of the properties to remove the problem all together
3. Find a way to distinguish between the two properties in databinding

The first solution doesn't work for me, because I can't touch this code (it was generated, remember?).
The second solution would mean that I'd have to rename the property in the derived class, which doesn't seem very nice.
The third solution was a long shot, but I had to give it a try. I did actually find this syntax to use for a case like this, however it wasn't very well documented, so I did some experimentation to get a better understanding of it. I started writing this in XAML:

{Binding Path=(local:Person.Gender)}

This failed with an exception telling me that this was an invalid value for the attribute. I was surprised an puzzled, because I read about other people using it and it is actually in the documentation like this. Some further investigation learned me that this only works on dependency properties. I've build a small example of this and it actually works very well, however...

...having a dependency property with all the plumbing involved is best done by deriving your class from DependencyObject (which contains stuff like GetValue and SetValue). I obviously can't derive Person or PersonBase from DependencyObject, because I have already derived them from another class. This means I now have to rename the property in the derived class :(.

You can find the example of binding to a new property here. Hopefully it is helpful to you. It was a great learning experience overall. Just to bad it didn't lead to a better solution for me.

Adventures while building a Silverlight Enterprise application part #24

Recently I was working out some details to include in our applications framework, when I encountered some old school enum stuff, that I'd like to share with you. It's all about using char implicitly as sort of the underlying type of an enum and why you might want that.

The story
As I was working on one of the modules we need in our application I had to figure out a way to store a persons gender. As it turns out, we don't have any data in the database specifying a list of genders. As this is all about what gender is on someones passport, we only needed two values (obviously 'male' and 'female') and we decided to only store the first character of these values in the database. The reason we didn't want to have a Gender table in our database was because of clarity. We have introduced this rule, saying that all primary keys should be of the SQL type uniqueidentifier (.NET type Guid) and having a foreign key for gender would result in storing a Guid for each and every gender in the database, which would not only be overkill, but it would also make things complicated.

So on the database side we had a char(1) column. But that's not what you want throughout your .NET code. Having an enum for this scenario is the obvious choice and that is what I went for. Luckily Silverlight is very well equipped for data binding enum types. There was one possible issue here. .NET enums only support int types as their underlying type...

...or do they? Obviously specifying something like enum Gender : char would not compile, but what about this:

public enum Gender
{
Female = 'f',
Male = 'm'
}

This is actually valid. But what happens then? Is char now the underlying type for this enum? Let's find out. I ran the following code to find out:

MessageBox.Show(string.Format("Enum underlying type: {0}", Enum.GetUnderlyingType(typeof(Gender)).Name));

As it turns out the underlying type is Int32. Hmmm, would this actually work? What value is it actually storing?
I expanded my code to the following:

MessageBox.Show(string.Format("Enum underlying type: {0}\r\n" +
"Enum value as int: {1}\r\n" +
"Enum value as char: {2}",
Enum.GetUnderlyingType(typeof(Gender)).Name,
((int)_person.Gender).ToString(),
((char)_person.Gender).ToString()
));

Now it would show me the int value and the char value casts for the selected gender value. In this case _person.Gender was Gender.Male. The actual int that was stored was 109, which is the byte value of the 'm' char. The ToString method on the char cast returned the 'm' char.

That's just great. Now I can store my Gender enum values by casting them to char at some point. But how about loading it pack into the Gender enum? As it turns out, you are allowed to cast this both ways, so something like this works:

_person.Gender = (Gender)genderCharTextBox.Text[0];

Duality rocks, man! So now we can store enum types without an underlying model with ease. Simple but powerful stuff, which I hope helps you out.

I've uploaded a simple project, which I used to test all this, here.