Search Engines vs. Decision Engines

Bing seems to have branded itself as something it calls a "decision engine" - whatever the heck that means.  I just did a search for "decision engine" (using my search engine) and the entry that came up told me that a decision engine is Bing!  So it seems to be a circular reference.

On Bing... I get pretty dismayed by the promotional team who mock up screens in the vain hope that they will lead us to believe that their "decision engine" is something more useful than it really is.  They artshop these elaborate landing pages which, on the face of it would lead to the early demise of search engines, wikipedia, and digital news services.

Alas, all it not as it seems.  The proof is always in the tasting (as they say), and so here we are, right in the midst of Soccer World Cup mania.  Everyone is talking about it.  The US are better positioned than they ever have been.  So let's do a Google vs. Bing bake-off and see what we get:

Here is Google (search engine):

Here is Bing (decision engine):

Decision made! :-)

ASP.NET MVC Data Validation

I've started to create a set of guidance for developers to show how to implement common validation concerns in business applications.  To that end I have created a sample project and an accompanying Guidance document to demonstrate these practices.  You can view a copy of these here:

• Sample MVC Project - 317KB
• Guidance Documentation (PDF) - 682KB

What I would like next is to gather more complex scenarios and implement them.  If you have any requests for scenarios that you would like to see implemented, please leave a comment and I will look at adding it in.

Updates
3rd June - Updated to include a new recipe for validating against values bound to dropdown lists

Change

Change is the process of moving from a current state to a new, improved state.  The business world is full of programs that are designed to manage this transition.  An alarmingly high percentage of these programs (some say as high as 80%) are claimed to have failed to have achieved what they were designed to do.

In my experience of actual people using actual technology to carry out actual business processes, this is not really surprising.  In fact, I would suggest in reality, we should be aspiring to acheive a 100% failure rate if change is the thing that we really are aiming for.  Of course in MBA courses, they could never draw it this way as total failure would not fit into 4 quadrants or a concentric circles diagram.

I contend that, in order to know that you need change, you must know that the place you are currently in is not as good as you would envisage.  In fact, I would suggest that for all of the places that I've seen, the current actual state is probably deemed (by those who are bound within in it) to be somewhat closer to a scene from Dante's Inferno - in fact, you might as well have these words engraved on plates above the front doors:

 "Lasciate ogne speranza, voi ch'intrate" (Abandon all hope, ye who enter here)

At this point it is generally decided that change is requiredd and so the business will create a vision to explain where we need to head and how everybody will feel when we get there.  They then "sell" this new vision to the people and this helps to create the feeling of optimism and hope that are required in order to bring about action to enact the change.

Finally - and this is the important part in my story - a formal program is created within the enterprise which is designed to enact the changes that have been agreed upon.  Even better, you might appoint a person to be involved in the change program and annoint them as an "agent of change".

The reason that these agents of change (programs and people) are important at this point is that we now have a physical vehicle to attach blame to for when things are deemed to be bad.  And I'm not necessarily saying this in a bad way, but think about the alternative.  Let me give an example:

1. People complain about using network shares to collaborate citing that they cannot find things and the organization of information is poor
2. A change program is created to improve the situation
3. A modern technology is acquired and installed and training given to the users on how to use it
4. People complain about using the new technology to collaborate citing that they cannot find things and the organization of information is poor

I can substitute the example with pretty much major change movement that I've experienced and the results are pretty similar - even though you may initially get some good results, the final result will mostly arrive at the same point to which I have observed in the example above.

So if this was the best that it gets, business would be screwed, there could be no room for optimism and everybody would feel like a failure.  But having an agent to point towards or to apportion blame against, provides us with the hope that things will become better.  In the example above, you may find people citing that things are worse than they were before because:

• The technology was a poor choice
• The change agent was a poor deliverer
• The benefit that would fix a particular problem or concern was planned for a "phase 2" implementation
• The business has not given us sufficient training or direction

Being able to purge these things from our system actually gives impetus to a new round of change and so the circle continues.

So we change, and we change, and we change again.  Even failed change is better than stasis as it creates activity which motivates people.  And a complete lack of change would lead ultimately to death.

Silverlight and WP7 Learning Resources

Whilst trying to get my head around Silverlight a bit better (it is one of the 2 programming models for Windows Phone) I came across some useful new learning resources:

• Channel 9 Silverlight Training Course 
• Microsoft Design Toolbox 

And if you want to get started with Windows Phone development, the best resources are:

• Free e-book: Programming Windows Phone 7 Series 
• Developer Tools (includes VS2010 Express for WP7) - WP7 Developer Portal
• Install checklist for Silverlight 4 RC, Blend 4 Beta and Windows Phone Developer tools from MIX10

There's also a good video of Mike Harsh going through Developing for Windows Phone 7 with Silverlight and his Slides and demos from his MIX10 Session.

Getting Started with Graffiti CMS

Getting up and running with Graffiti is very easy and one of the things that I really enjoy about using it. One of the things that I've struggled with when using some of the other larger open source products is just getting them going. For example, having to use SQL Server often means that I need to install it, then create the database (and pray that the scripts work) and then do configuration.

Also, some Open Source products are heavily dependant on other open source software. This makes them brittle and tied to what often becomes other unsupported legacy code. This has the knock on effect of making the product harder to get started with as time goes by.

Graffiti on the other hand is lightweight and relatively free of external bindings. This has meant that getting going with an Access database as the backend has not changed significantly in the 3 years that I've been using the product.

To get started, browse to the Graffiti CMS site on CodePlex and work through the "Getting Started" notes that appear on the home page. These lead you through the following steps:

• Download the v1.3 source code
• Download "extra" assemblies from http://graffiticms.com/lib/lib.zip
• Unzip and add the extra assemblies to the \Branches\v1.3\src\Lib folder
• Open the \Branches\v1.3\src\Graffiti.sln solution file with Visual Studio 2008
• Update web.config to use the desired database settings
• If you are not running IIS7 and ASP.NET 3.5 SP1, you should enable the "Generate Folders..." option in the admin >Site Options > Configuration page

Extra Assemblies

The extra assemblies are:

• Telligent.DynamicConfiguration
• Telligent.Glow - Web Controls by Telligent
• Telligent.Glow.Editor - Web Controls by Telligent

These assemblies provide additional functionality and web controls and I believe that they are packaged separately because they needed to be subject to different licensing from the core Graffiti software.

Database settings
The notes for getting a database up and running for your Graffiti installation can be found . Essentially there are 3 parts to this:

• Choose your Provider.  This is set via the "DataBuddy::Provider" key in web.config.
• Update your connection string in web.config. There are samples provided, so just copy the one that is relevant for your database provider.
• Set up your database as per the notes that can be found in the \Branches\v1.3\data\read_me.txt file.

If you are using MS Access for your database then getting up and running is as simple as copying a template .mdb file into your App_Data folder and then running the solution. I like the Access database option as it makes the entire website self contained, making it easy to move around and deploy.

Generate Folders
After you have installed and configured your basic set up, you should read through the Getting Started Guide to gain an understanding of more advanced configuration options that you might need to consider. One of the major things that you need to be aware of is the difference between how the site runs under IIS7 and IIS6.

Running under IIS7, the site uses an inbuilt routing mechanism for serving up virtual paths. When running under IIS6, the inbuilt routing is still used, however for that to work, the folders for paths need to physically exist on disk. To acheive this you need to log in to the Administration section and go to Site Options / Configuration and ensure that the "Generate Folders for Posts/Categories" option is checked.

Running the solution
From within Visual Studio, run the application. You can either click login or browse directly to /graffiti-admin/ and then login as an Administrator to start creating content and managing other aspects of the site. The initial Administrator username is 'Admin' and the password can be found in the Graffiti:User:DefaultPassword key in web.config.

Learning how to use Graffiti CMS

I've been thinking about CMS for a while and recently decided to get back in to using Graffiti CMS as my CMS tool of choice. I've used Graffiti before and I believe that, for a .NET developer, it is probably one of the best CMS tools around.

Late last week I downloaded it and used it to bang out this simple little hockey club website - http://web9ecf9dd.titan.studiocoast.com.au/.  Over the next few days I’m going to add several articles which explain how to get up and running using Graffiti and you will see the topics of these articles from the text in square brackets in the bullet pointed list below.

The things that I like about Graffiti CMS are that:

• It is .NET based. I am a .NET developer and I really need my tool of choice to have a .NET flavor to it so that I can feel confident that I have full control over the final product. [Using Macros and Chalk Extensions]
• It is lightweight. In fact it's probably the lightest of all CMS engines that I know of relative to the number of features and amount of power that it affords. In fact, from the time you download Graffiti CMS, you can be up and running in under a minute if you choose the MS Access data provider. [Getting Started with Graffiti CMS]
• It gives me full control over the rendered HTML - Graffiti CMS layout templates are very powerful. [Understanding Graffiti Layouts and Templates]
• It's extensible. I can create custom extensions very easily to do pretty much whatever I want. [Developing your own custom Chalk Extension]
• It comes with lots of rich features that make it very easy to quickly build and deploy advanced websites. [Users and Permissions], [Themes]
• It's open source and it's free. 

Further Reading
My Move to Graffiti - nice comparison of different tools

Version Control - a reaction to Martin Fowler's article

Recently I've been involved with looking at how our team produces software. This has meant looking across the spectrum of activities, tools, and practices that we undertake to deliver working software to the business. It was with this activity still fresh in my mind that I stumbled upon Martin Fowler's thoughtful article about Version Control on his Bliki earlier today.

As part of my work I actually put forward an argument that we move away from using SVN for source control and to implement TFS. As somebody who has deep personal affection for the simplicity of SVN, the decision to recommend TFS was not made lightly.

In light of my own decision to move away from SVN and onto TFS, I was motivated to respond to Martin's positioning of TFS on his summary diagram which placed TFS outside of the tools that he would recommend for version control.

Whilst he suggests that TFS is not a recommendable product, Martin does not make any real attempt to explain other than to say that people he trusts don't recommend it. In this article I want to put forward some of the reasons that I chose for recommending TFS as our tool of choice.

Integration
I believe that it is unfair to look at version control in isolation because, whilst your version control software sits at the heart of your development system, it lives within a larger ecosystem. This ecosystem is made up of IDE's, Issue Tracking Software, Build Management Software, Continuous Integration Services, Reporting, and perhaps other tools and services too.

In light of all of this software that comprises your development ecosystem, consider the technology soup that you are managing. Patching and keeping these systems soon becomes a science unto itself and unless you're job is as a specialist build master where you are entitled to choose individual best of breed applications, managing this type of environment may not be for you.

Moving to TFS provides us with a single technology roadmap and vastly reduces the complexity involved in configuring and patching our environment when compared with the alternative.

An illusion of simplicity
In light of having uncovered the elements of a development ecosystem, let's reconsider our views on simplicity. First I'll start with a statement from my own observations about developing software - Developing software is a complex business. FULLSTOP! PERIOD!

As shown in my previous discussion about integration, the complexity is there always. You can have a simple version control tool but the cost of this is that you transfer more of the complexity to other parts of the system. In the case of having chosen SVN, this complexity comes in the form of having to run multiple, independant systems using multiple technologies.

With TFS you gain simplicity through technology consolidation but you pay a price for having to learn how to set up and manage it - but is this any more complex than having to learn half a dozen other systems?

The real business world
So far I've focussed my discussion about the development ecosystem on the activities of the developers themselves. However in the real business world, this is still not a fair representation of what is needed to successfully deliver working software.

Even small businesses have stakeholders that the software is being developed for and in mature businesses, there is an instrument which sits between (or straddles) the business and technology domain - this instrument is the PMO.

In light of this discovery, it is no surprise that building successful software is as much about soft skills - such as communication and reporting - as it is about purely technical pursuits such as coding, building, and releasing.

By integrating with common business software such as Excel and MS Project, the TFS work item tracking system makes it easier to align IT projects with projects in the PMO and have those functions be able to communicate using a common language.

Conclusion
In this article I have opposed Martin Fowler's view in relation to the placement of TFS on his summary diagram. I believe that his article is too narrowly focussed to be of real value when considering what tools to choose in creating your own software development ecosystem.

However I do agree with his closing sentiments wholeheartedly and I could not have put it any better then when he wrote:

Remember that although I've jabbered on a lot about tools here, often its the practices and workflows that make a bigger difference. Tools can certainly make it much easier to use a good set of practices, but in the end it's up to the people to use an effective way of working for their environment. I like to see approaches that allow many small changes that are rapidly integrated using Continuous Integration. I'd rather use a poor tool with CI than a good tool without.