You may have noticed I’ve been getting into Azure recently. You could say my head’s going to be even more in the cloud than usual, because I’ve accepted a position with Microsoft as an Azure Technical Evangelist.

Suppose you had a some scary-looking hoodlum walking around your house when you were out? You’d want to know about it, wouldn’t you? Take one Kinect, mix in a little Windows Azure Service Bus, sprinkle in some SignalR, and mix it all together with some elbow grease, and you could watch in near-real-time as sinewy folks romp through your living room. Here’s how.

Developers need to grok Windows Azure, especially developers who want to distribute consumption of an application in a web-based API. A great use for Microsoft Azure, obviously, is to use it to host an application’s web service API layer. This post will demonstrate how to host WCF services in an Azure worker role in a manner that will offer REST-like JSON API support.

The SignalR GitHub site has an example wherein a SignalR PersistentConnection instance is used from a non-HTML client. The idea of being able to use SignalR connections in applications other than those that run in a web browser raises some interesting challenges. Likewise, there aren’t too many examples on how to use SignalR connections. This post will demonstrate asynchronously testing a SignalR connection in an end-to-end scenario using NUnit.

That title sums up what this blog post will summarize and explain; how to get data instantly from the cloud – in this case, the Azure cloud platform – all the way down to an HTML 5.0 browser. The point of this exercise is to take a slightly deeper dive into using SignalR. Secondary to the SignalR deep dive, this article will explain how to use the Azure Service Bus.

On the drive home from my last Behavior Driven Development talk, I began thinking about the idea of Code Katas and how one might be appropriate in my future disucssions of Behavior Driven Development. Given that BDD tries to solve things in as simple and direct a path as possible, and given that BDD takes some of the lessons learned via TDD and applies them in slightly more business-centric language, a Kata would demonstrate well the effectiveness of BDD when applied to a problem domain. 

The Richmond Code Camp was great. NDecision attracted a lot of participants and enthusiasm and motivated me to keep plugging away at it. There was some excellent audience pariticipation and Twitter-reviews from which I got much encouragement. Both sessions I presented were loaded with enthusiasm that Microsoft is, from all public observation, maturing in its attitude and adoption of OSS contribution. That was uplifting, but not my favorite observation from the weekend.

SignalR is one of the latest (and sexiest) elements in the .NET stack. Expect to hear more about SignalR if you haven’t already, because it delivers on the promise of push technology without the requirement of a fat client. If you’ve not yet read much about SignalR, clone the source code from GitHub or read Scott Hanselman’s post on SignalR for an introduction. The scope and inner-workings of SignalR are somewhat out of scope here, so I’ll just assume you’ve at least heard something about SignalR and that you’re interested in it but have a few questions. I mean, if you’re into BDD/TDD, you should definitely be wondering: