How not to import and export your blog posts

This was going to be a post about how to export and gather together the posts from the various blogs you've got knocking around on the internet and import them into Blogger (which I chose because of its reportedly excellent import/export facility) however I made quite a hash of it, garbled a few posts, lost a load of formatting and hyperlinks, had a little cry...

That'll teach me to be so promiscuous, running off with every trendy new publishing platform that comes around. It's time to settle down with a blog I can depend on, that's all I'll say since I'm not the best person to be advising anyone on how exactly to do that.
The Windows Communication Foundation (WCF) api has been a part of the .Net framework for a good few years now, and if you're a .net developer you've probably dabbled in it or at least heard the name batted around. It offers a handy and flexible set of tools for letting external systems and programs (regardless of language or operating system) run your code and receive data as a response, in a similar way to how you interact with Amazon Web Services or Google Adwords API.

Very useful if you're writing software for distributed systems, or perhaps if you're trendy enough to be writing iphone & android apps or even if you just want to make sure that your system is scalable longer term; but there's an incidental feature in WCF which is so useful, I'm now using WCF in every web project I write.

It's this little sucka:

The WCF Test Client - isn't it beautiful?

The WCF Test Client allows you to individually execute your WCF services in a similar way to how you would execute a stored procedure, supplying the data and receiving the response. You can see why it was necessary, you need to be able to test your services.
As a developer, it's an incredibly easy way to quickly test a piece of code I've just written, but as a development manager who has had many a night's sleep ruined by nightmares of messy code, it's game changing.

Why WCF is Inadvertently Brilliant

What I've taken to doing is setting up a WCF Service project as the gateway to the business layer (a class library project), in the same way we use Linq as a gateway to the data store, and setting up our presentation layer project (usually a website project, but could be a windows forms app, or an iphone app, or all of the above) to interact only with the WCF Service project.
This way, when planning a development, I can schedule the development and testing of the business layer code completely separately from the development and testing of the presentation layer, even to the extent that I can assign them to entirely separate developers.

For example, we need a webpage to show a list of customer orders, Geoff the efficiency expert can write the stored procedure and the code to organize the customer order data, it can be fully tested and Geoff can move on to something else; then Alan who knows his drop-downs from his radio buttons and better understands user behaviour can come in a put together an effective interface without getting bogged down in SQL quirks.
(Actually in this situation I'm more a fan of exposing developers to the areas of development they are less familiar with to give them more rounded experience - but you see my point).

This gives more flexibility in scheduling but more crucially, enforces a healthy barrier between business layer and presentation layer code - even if it was late at night and in a pizza & caffeine fueled daze Alan attempted to write some processing method in his presentation layer code, it wouldn't work (or make sense) since our processing code is already written and tested and the format of the input and output data is fixed - so the code stays clean, readable and testable, and the development manager sleeps soundly.