Internet rules!

I so love the internet. I messed up my satellite dish today and needed to know where to point it so I found this... http://www.dishpointer.com/

What a brilliant idea! I found that all I need o do is point the dish at a landmark nearby and wiggle the elevation till it locks on. Too cool!!

WPF FAQ

I am working on my new WPF FAQ which will be available on my site shortly.

Although I know there are many out there, in my new role as a WPF developer I will use it as a target for noting down all those things I find useful during my learning curve.

Hopefully it will benefit others too.

WPF same-old sameold.

I am currently trying to immerse myself in WPF from a practical and useful standpoint. My usage of this new system has been fairly light and fluffy up until now, I have been puzzled by some of the new concepts, realised that the framework has taken a totally different direction recently and been have wowed by the promise of "A New Hope" or, if you'll forgive me, a paradigm shift.

However, when I began seriously looking into what can be done on a practical level with XAML and how data and XML can be used to build pretty cool applications I find myself coming to the conclusion that its all really business as usual in the world of the programmer.

When you look at XAML and the various cool looking demo applications that are out there you will see in fact that XAML is only as good as the components you can use on your pages and windows. The supply of these components requires programming skills that are firmly based in traditional methods and despite the fact that XAML provides a declarative way of creating an interesting look and feel, when one begins writing a custom control, one is still forced to roll up the sleeves and get to work with good old C# or Visual Basic in the codebehind file.

Certainly XAML is a great way of defining a user interface and incorporating the design elements we need now but the need for strong architectural skills and a supply of high quality controls for all these markup-jockeys to consume is still of paramount importance.

Problems with source-control and ItemGroup entries in .CSPROJ files

Here's an interesting one that just happened to me.

I work in a ClearCase source control environment and recently had to have access to a VOB from another team so that I could do a bit of trouble shooting.

The problem arose as soon as I tried to compile their code; the source-control complained that the xxx.csproj couldn't be written because it was write protected. This was normal because I hadn't touched anything or made any checkouts.

The problem was that the system seemed to want to overwrite the files that were not checked out.

After much detective work I found that the XML:





was being inserted into the IN_MEMORY copies of the CSPROJ files.

After some detective work in the registry I found that this was associated with something called STextTemplating which has to do with the template system in Visual Studio and seems also to be associated with Domain Specific Languages (DSL)

After more searching I found that it was necessary to remove the following keys:

{B4F97281-0DBD-4835-9ED8-7DFB966E87FF}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0Exp\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}

After this, the problem went away.

Here is the link I found after about two hours of digging and pain...

http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework/topic61709.aspx

2.NET|!2.NET

Arthur C. Clarke once said "Any sufficiently advanced technology is indistinguishable from magic"

A few times recently, I've been in a situation where I just wanted to hold my head in my hands and groan "Noooo not again!! make it stop!!". Why? Well, because even after seven years of .NET people still don't get the idea of what advantages there are in fully embracing the framework's philosophies to create really great applications or components.

Imagine dumping a medieval man into the middle of London. Aside from the obvious initial shock, he'd become used to the idea that cars travelled about without horses attached to them, he could even learn to drive a car. He would become used to the idea of lighting without flames and he'd eventually become a consumer of fish and chips or MacDonald's burgers without necessarily understanding how it all happened or what made it all tick. After his short period of adjustment that went from screaming fits and soiling himself with fear, we would eventually get someone who can function just fine in the environment. Whether he could design a car or grasp the concepts of electricity would be however, a different subject entirely.

This is the sort of thing that happens when someone who is "expert" in 1990's technology gets hold of the concepts of third millennium .NET framework. They become a perfectly adequate programmer, able to apply their concepts of programming to C# or VB.NET and as long as their efforts are contained within a single sealed up application all is well and you can't tell the difference from the outside.

What happens however when that person, however innately intelligent they may be, applies 1990's ideas to .NET architectures and has the responsibility for creating, say, a huge data management framework of industrial proportions? You guessed it. A complete and total disaster that does nothing but make people groan with disbelief.

For me, the best aspects of .NET architecture are the ones that don't fall readily to mind, even if you're a world-renowned C++ guru and have 20 years of experience in your field. For example, the idea that your objects may take part in a design time environment. This was not even a possibility in the old world of C++ but now you should seriously consider whether your objects should at least carry the attributes such as Browsable, Description, Category etc. Furthermore, you should ensure that your object has a type-conversion strategy, should implement ToString correctly, provides a design-time editor, possibly a graphic editor, certainly a smart-tag, some designer verbs and so-on.

When designing an architecture today, we also need to look to current trends in data-binding. It used to be that tying an object to a GUI was a laborious process that required either brute-force, the preferred C++ method, or implementation of some pattern such as Model View Controller (MVC). Any remotely skilled Windows Forms engineer will immediately use data binding which neatly sidesteps these issues. However, the objects in question need to either provide changed events for properties or implement INotifyPropertyChanged. So, I hear everyone reading this beginning to say "Well, if the object is some deep part of a framework and not exposed to the GUI, why bother?" The answer here of course is that data-binding is no longer a GUI only issue. .NET 3.0 and 3.5 already has data binding that can take place between any two properties so that otherwise invisible objects can be bound. This is not only interesting for WPF maniacs but for anyone who has an object that receives input from another.

Finally, meta data and reflection coupled with new type description systems are so powerful that it adds vast new aspects to object orientation that are so outside the realms of the classic Encapsulation, Inheritance, Polymorphism triad that classes have ceased to become immutable definitions and have entered the realms of chimeric virtual objects that appear to be one thing when they are, in reality, something totally different.

If you're an architect and expecting to create a framework for your flagship product by all means pick .NET. Just don't go blundering about like a medieval peasant when you could be using magic instead.

A strong business case for WPF?

Hot issues in the computing universe include the advent of Vista and the .NET framework 3.0 including technologies such as Windows Presentation Framework (WPF). Even the most disconnected developer will be aware of the hyped images of videos playing on the faces of spinning cubes and photo-albums that float in a plasma-filled void. All very pretty, amazingly attractive to geeks who understand what it takes to do such a thing, but how do you explain the need for early adoption of such a technology to someone who doesn’t see the need for these sorts of things in their application?

Recently I’ve been working in a company where I’m responsible for the GUI end of a complex data architecture and I am faced with diverse problems on a daily basis. Firstly, the company is a large institution with a phenomenal IT overhead. Everything must be certified; everything must be accepted and verified. As a result it’s only recently that the company moved onto Windows XP systems and even more recently that Service Pack 2 has been accepted and even that is installed on a very few machines. Imagine then how difficult it might be to persuade the people in the system to adopt such a new technology as WPF. When we see WPF we see video games, we see spinning cubes, we see applications that are so much fluff and that have little or no use whatsoever for a company that just needs to display values from a database in a grid. A project manager who sees such demonstrations will dismiss them out of hand, indeed, they have.

However, the managers are very hot on the subject of performance. The data architecture I work with has the possibility to swallow and process large amounts of real-time data. This data comes from complex calculation systems that can change a couple of hundred lines on a data grid in a matter of moments. Using conventional systems, the best commercial grid software we can find and every optimisation technique available to us we still see processor consumption rates climbing to the 100 percent mark on simple machines and the 50 percent mark - this is to say one processor totally consumed - on multi-core systems. Why is this? Simply, because instead of using the processor for doing work, we’re using it to paint the constantly changing cells in a grid. Our graphics and our UI are destroying our ability to do work.

Where does this leave us? In order to liberate the processor we need to stop it from drawing the graphics. We still need the graphics so this implies that they need to be managed somewhere else. By the graphics card itself possibly.

Strangely WPF is here with a system that can make even the most bogged-down two dimensional application fly. With the power of graphics processors on even simple display cards today, the rendering of a grid can become a trivial matter, even when it’s data-bound to a constantly changing stream of data.

Forget spinning cubes, forget cards that bounce and shatter in a waterfall of broken shards, forget plasma fields with smiling babies and dogs catching Frisbees. Show the managers in your company the benefits of freeing up those expensive processors for doing real work and leave the graphics where they belong, on the video card.

What is the most important technology today?

With the recent release of .NET 3, Vista, WPF and the WCF systems one might think that the choice was large. However, from everything I've seen recently the most impressive and important technology of today isn't what one might imagine.

I think that there is only one truly outstanding thing in all of todays new technologies and in fact it's probably one of the most fundamental concepts because, after all, what we do as programmers is normally to enable our users to visualise otherwise cryptic data.

The technology of which I speak is, of course, data-binding.

As an architect of systems that manipulate otherwise boring and complex data, I've found that the method of databinding used can make the difference between a mediochre application and a truly fantastic one.

Data binding techniques are in the process of evolving. Look at the ideas in .NET 3.0 and you'll see that not only can the properties of data objects be bound properties of user-interface objects but just about any property may be bound to any other.

The binding mechanism is also becoming more of a presentation mechanism with the ability to add inline bi-directional conversions to the data so that raw data in a property may be treated in some way before it gets to the user interface.

These ideas may seem to be spurious at first glance. Who needs to bother how data binding works on a deep level? The answer may surprise more than you imagined. Why? Consider this.

For many years, since the early days of MFC and since the work of The Gang Of Four, design patterns have been talked about in the industry and many attempts have been made to implement them correctly. The Document-View model in MFC, the implementation of patterns such as MVC (Model, View, Controller) and more recently MVP (Model, View, Presenter) as used in the CAB (Composite Application Block) have all been the subject of various implentations attempts that were more or less successful.

My own experience with these classic patterns is that the ideas are usually great, the pattern has a logic and a simplicity that suggests that the implementation should render good results but the implementation, when left open to developers who use classic quick-and-dirty methods or just don't understand the architecture, usually falls short of expectations. One of the biggest problems I've seen in many applications is the blurring of the line between the boundaries of the pattern components. The way that we build applications, such as an MFC, Windows Forms or even WPF application, leave so much open to interpretation that developers will often write complex code into a form, dialog or user-control so that the functionality of what should be only, say the view, becomes part view, part controller, part model.

How does databinding solve this problem of interpretation of a pattern and the consolidation of an architecture? Well, the way we use databinding enables us to remove all aspects of business logic from the view and to move the intelligence of the application into the presentation portion where it belongs.

I'm in the process of preparing a number of articles on this subject which I will be posting over the next few weeks. If you're interested in the follow up to these ideas, watch this space.