RoryCom 1.0.0.0

Some times I get a little bit bored on the weekends and like to be stir things up a bit. So in the few minutes before I go to bed I decided to whip up this handy little utility.

Its a unique messaging application which allows you to send messages to Rory Blyth via his Google referrer logs. You can download the source here – note that VS 2005 BETA 1 is required.

Steve Smith: Big Guns

Yeah, this is pretty much what Steve looked like when he was kicking my arse on counter-strike.

Nick Wienholt speaks up for the humble DataSet

Nick Wienholt has posted up about a project that he is working on where the age-old (well, at least as old as .NET) DataSet discussion has kicked off.

I “think” I know the project he is working on, so I also know some of the other people involved and can tell you that the debate isn’t going to be light-weight and many good points will be made, although it’ll probably result in dead-lock like it always does, so I won’t go over the same old arguments again.

Everyone knows you can model most businesses using either a relational database or a set of domain objects so its not really a question of capability. The conclusion that I am fast coming to is that no matter which approach you take you almost always end up modelling the wrong thing.

So let me put a little bit of a side-ways spin on the argument. How many of you end up with a class or data-set called “Customer” or something like it? If I was to guess I’d say that 65% of you would be nodding your head, of the remaining 35% (does quick check of math) it would probably be because “Customer” has no place in the problem space, for example, if you are building CRM apps for Australian toll-ways you’d probably have a “Victim” class.

OK, now that you’ve thought about your object model a little bit, think back to how the business might have operated without computer assistance. When the relationship began with a customer they might have filled in some kind application form (some industries don’t require this). Once that was done that form would probably have been posted to head-office where they created a file (you know, the type that sits inside the filing cabinet).

Lets say our customer moved house and as a result changed their address and phone number. Well, they would probably have filled in a change of address form and posted that to the head office too. Someone at the head office would have filed that request along with their application and probably updated the customer details on the top of the file and maybe forwarded to another relationship manager if they happened to move between service regions (although the transfer would probably have been transparent to the customer).

This second interaction is where things get interesting. If you didn’t want to drive your customer nuts you wouldn’t ask them to re-enter all their details, you’d probably just ask for some key information like a customer reference number and the new address information.

Compare that to what you might be doing in your existing business application when you transfer the the entire customer representation back and forth between the client application and the source of truth. I can understand read-only interfaces where you do that, but it just doesn’t make sense when changing data, because thats not the way the business operates.

In business individual operations against customer representations in the system are significant. When I want to increase the credit limit on my credit card the bank will launch a whole bunch of associated processes, such as sending me a snail mail informing me of the change. If the interface into the system only allowed you to transfer the entire customer representation from client to server, when it gets back to the server it is going to be tricky to intercept the various subtle operations that got performed on it and trigger the background processes.

So, whichever modelling mechanism you choose please look at modeling the “messages” between the customer and the source of truth, not the customer itself.

Now that I have that off my chest, I will outline a few of my concerns about data-sets. Firstly, the tool support is great, but it tends to drive people towards producing in memory representations of the source of truth – therefore you end up passing the customer across the network again (typically). That doesn’t mean using objects alleviates this, but because the tool support is still fairly poor you tend to get a bit more creative in what you send across the wire.

End rant.

Clarke gets a .NET rocks mug.

I want one of these mugs. Now I just need to find something interesting enough to send to Carl and Rory.

Dave Winer on Longhorn

I wasn’t surprised to read this post by Dave Winer on Longhorn, after all, its not like the software industry is a stranger to slipping on delivery dates. What did catch my eye however was this quote.

“Longhorn isn’t designed to solve anyone’s problems. I think they all know it, but they can’t say it out loud because they’ve all drunk the Kool Aid on this.”

Thats pretty savage, and its also wrong. The exposure of the shell to managed code along will give rise to a new breed of “always on” applications. Take for example the panel bar which is typically docked over to the right hand side.

Recently I worked with a government customer who needed to integrate a prototype .NET application with an IVR system. If we had the panel bar we could have EASILY hooked up information like call-stats, queue status and incoming call information.

They keyword here is EASILY, you see all of these things are possible today if you are willing to wade through a mountain of less than friendly COM interfaces but when the pressure is on to deliver core functionality these usability features tend to get pushed down the priority list.

In the end we had to compromise, when a call came in we popped a balloon window attached to a tray icon and when it was clicked fade in a caller info window (keyed on info provided by the customer during initial prompts from the IVR system).

So I think it would be fair to say that Longhorn has a lot for business application developers.

Leading Australian Publisher adds support for RSS

As Frank points out, The Sydney Morning Herald and The Age have started offering up RSS feeds. Its disappointing that they didn’t opt to include atleast some content with the feed and not just a link to the article.

Upgraded to Windows Media Player 10

I installed Windows Media Player 10 yesterday and I have to say that I am impressed. The new glassy look really rocks (maybe I am a closet Mac fan?) and the performance is a huge improvement.

Anyway, I clicked on the Online Store link and was a little disappointed that no stores are available for Australian users, of course that doesn’t stop you hopping on to music stores manually and pulling down a few tracks, but I was kind of hoping for an integrated experience.

Was Microsoft right to de-couple WinFS from Longhorn?

So everyone has heard the news about WinFS delivery slipping until after Longhorn has shipped. As someone who has worked on projects with tight deadlines I can appreciate why these tough decisions are made. However, one of the things that I didn’t consider when I made this post is the rise of PC search engine software (hopefully everyone who is using Outlook is also using Lookout already).

There has also been some talk about Copernic Desktop Search which teams to take the shell integration even further. So what was it that I didn’t consider? Well a lot of people have loose files hanging around on their machines which aren’t part of any centralised data-store. WinFS could really help in organising these files by attributing them with meta-stuff. That meta stuff would then be searchable.

If you want proof that this is important just look at Lookout and Copernic.