bradygaster.com

WebMatrix on Web Camps TV

Thu, 26 Jan 2012 05:58:48 GMT

This week I had the absolute privelege of hosting the Channel 9 Web Camps TV show. The show featured WebMatrix, and our guest was Vishal Joshi, Lead Program Manager for the product. Vishal highlights some of the great new features available in the new version of WebMatrix, which you can download for free in under 2 minutes. The product is impressive and offers just about every single thing a web developer would need. From database edits to code completion across C#, CSS, HTML, and even PHP code completion, WebMatrix has you covered. Take a few minutes and check out the new features you can get for free on Web Camps TV.

Codemash SignalR Talk

Tue, 17 Jan 2012 16:32:57 GMT

If you attended my SignalR talk at Codemash, thank you so much for your time. I had a blast at Codemash, and really enjoyed the talk. It was a great audience with some good conversations in the hallway afterward. If you attended the session and want to get your hands on the deck and code, this is the place.

The deck and code are here!

Safe travels home, everyone! I look forward to next year's Codemash!

The Azure Service Bus Simplifier

Thu, 29 Dec 2011 22:03:00 GMT

One of the things that makes enterprise service development of any type difficult is the requirement to learn that ESB’s programming model. The Windows Azure has a very simple programming model already, but for those developers getting started with Azure Service Bus programming for the first time who mainly want a simple publish/subscribe-style bus architecture limited to a few types of custom messages, I’ve created a NuGet package called the ServiceBusSimplifier.

If all you need from the Azure service bus is a simple implementation of the pub/sub model there’s no longer a need to learn all the plumbing and deeper detail work. Of course, there’s nothing wrong with learning the plumbing and doing so is encouraged, but for those just getting started with Azure’s Topic-based messaging, the ServiceBusSimplifier package might be just the answer. It provides extremely basic access to publishing and subscribing custom messages through the Azure service bus. The video below demonstrates how to use the package, and there is some detailed usage instruction below the video.

Usage and Source Code

If you’re just trying to use the package to simplify your entry into using Azure’s service bus, just pull down the package from NuGet.

If you’d like to peruse the source code, which the remaining sections of this post will take a slightly deeper dive into an element at a time or you’d like to add functionality to it, the code is available as a GitHub repository.

Setting up the Connection

To set up the service bus connection, call the Setup method, passing it an instance of the class the package uses to supply authentication and connectivity information to the service bus, the InitializationRequest class. The ServiceBus abstraction class offers a Fluent interface, so the methods could be chained together if need be.

Subscribing

As mentioned earlier, the ServiceBus abstraction offers very simple usage via self-documenting methods. The code below has been augmented to subscribe to an instance of a custom class.

Note, there are no special requirements or inheritance chain necessary for a class to be passed around within this implementation. The class below is the one being used in this example, and in the GitHub repository.

Finally, here’s the HandleSimpleMessage method from the program class. Note, this could have been passed as an anonymous method rather than a pointer to a class member or static member. The video demonstration above shows such a usage, but it’s important to note that either a static, instance, or anonymous method would be appropriate being passed to the Subscribe method.

Publishing

The final piece of this demonstration involves publishing messages into the Azure service bus. The code below shows how to publish a message to the bus, using the self-explanatory Publish method

Hopefully, the ServiceBusSimplifier package will ease your development experience with the Azure service bus. Even though the Azure service bus is dirt-simple to use, this handy utility library will give your code 1-line access to efficient publish/subscribe mechanisms built into the cloud. Happy coding!

Blob Storage of Kinectonitor Images

Wed, 28 Dec 2011 21:39:34 GMT

The Kinectonitor has received a lot of commentary and I’ve received some great ideas and suggestions on how it could be improved. There are a few architectural aspects about it that gave me some heartburn. One of those areas is in that, I failed to make use of any of Azure’s storage functionality to store the images. This post sums up how Blob Storage was added to the Kinectonitor’s architecture so that images could be stored in the cloud, not on the individual observer site’s web servers.

So we’re taking all these pictures with our Kinect device. Where are we storing the images? Are they protected by disaster recovery procedures? What if I need to look at historical evidence to see photos of intruders from months or years ago? Where will all of this be stored? Do I have to worry about buying a new hard drive for all those images?

A legitimate concern that can be solved by storing the photographs taken by the Kinect into the Azure cloud. The video below shows a test harness I use in place of the Kinect device. This tiny application allows me to select an image from my hard drive. The image content is then sent along the same path as the images that would be captured and sent into the cloud by the Kinect. This video demonstrates the code running at debug time. Using ClumsyLeaf’s CloudXplorer client I then show the files as they’ve been stored in the local development storage account’s Blob storage container.

Now we’ll take a slightly deeper dive into the changes that have been made in this update of the Kinectonitor source code. If you’d like to grab that code it is available on GitHub.

The Kinectonitor Worker Role

This new project basically serves the purpose of listening for ImageMessage instances. There’s not a whole lot of code in the worker role. We’ll examine its purpose and functionality in more detail in a moment. For now, take a look at the role’s code in the Object Browser to get a quick understanding of what functions the role will provide the overall Kinectonitor architecture.

In the previous release of the code, ImageMessage instances were the only things being used to pass information from the Kinect monitoring client, to the Azure Service Bus, and then back down to the ASP.NET MVC client site. This release of the code simplifies things somewhat, especially around the service bus area. The previous code actually shipped the binary data into and out of the Azure Service bus; obviously this sort of arrangement would make for huge transfer rates. Before, the communication was required because the images were being stored in the ASP.NET MVC site structure as image files. Now, the image data will be stored in Azure Blob Storage, so all the ASP.NET MVC client sites will need is the URL of the image to be shown to the user in the SignalR-powered HTML observation client.

If you haven’t yet taken in some of the great resources on the Microsoft Windows Azure site, now would be a great time. The introductory how-to on Blob Storage was quite helpful in my understanding of how to do some of the Blob Storage-related functionality. It goes a good deal deeper into the details of how Blob Storage works, so I’ll refer you to that article for a little background.

The worker role does very little handiwork with the Blob Storage. Basically, a container is created in which the images will be saved, and that container’s accessibility is set to public. Obviously the images in the container will be served up in a web browser, so they’ll need to be publicly viewable.

The SaveImageToBlobStorage method, shown below, does the work of building a stream to use to pass the binary data into the Blob Storage account, where it is saved permanently (or until a user deletes it).

Note how the CloudBlob.Uri property exposes the URL where the blob can be accessed. In the case of images, this is quite convenient – all we need to be able to display an image is its URL and we’ve got that as soon as the image is saved to the cloud.

Simplifying the Service Bus Usage

As previously mentioned, the image data had been getting sent not only to the cloud, but out of the cloud and then stored in the folder tree of an ASP.NET MVC web site. Not exactly optimal for archival, definitely not for long-term storage. We’ve solved the storage problem by adding in the Blob Storage service, so the next step is to clean up the service bus communication. The sole message type that had been used between all components of the Kinectonitor architecture in the first release was the ImageMessage class, shown below.

Since the ImageMessage class is really only needed when the need exists to pass the binary content of the image, a second class has been added to the messaging architecture. The ImageStoredMessage class, shown below, now serves the purpose of information the SignalR-driven web observation client that new images have been taken and saved into the cloud.

With the added event concept of images being stored and the client needing to only know the URL of the last image that’s shown automatically in the browser, the message bus usage is in need of rework. When the worker role spins up, the service bus subscription is established, as was being done directly from within the MVC site previously. The worker role listens for messages that come from the Kinect monitor.

When those messages are received, the worker role saves them to Blob Storage using the PublishBlobStoredImageUrl method that was highlighted earlier.

Finally, one last change that will surely be augmented in a later revision is within the SignalR hub area. Previously, Hubs were wired up through a middle object, a service that wasn’t too thoroughly implemented. That service has been removed, and the Hubs are wired directly to the service bus subscription.

Obviously, this results in all clients seeing all updates. Not very secure, not very serviceable in terms of simplicity and customer separation. The next post in this series will add some additional features around customer segmentation and subscription, as well as potential authentication via the bolted-on Kinect identification code.

The Kinectonitor

Mon, 12 Dec 2011 13:02:36 GMT

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.

You might not be there (or want to be there) when some maniac breaks in, but it’d be great to have a series of photographs with the dude’s face to aid the authorities in their search for your home stereo equipment. The video below is a demonstration of the code this post will dive into in more detail. I figured it’d give some context to the problem this article will be trying to solve.

I’d really like to have a web page where I could go to see what’s going on in my living room when I’m not there. I know that fancy Kinect I picked up my kids for their XBox can do that sort of thing and I know how to code some .NET. Is it possible to make something at home that’d give me this sort of thing?

Good news! It isn’t that difficult. To start with, take a look at the Kinectonitor Visual Studio solution below.

At a high level it’ll provide the following high-level functions. The monitor application will watch over a room. When a skeleton is detected in the viewing range, a photograph will be taken using the Kinect camera. The image will be published to the Windows Azure Service Bus, using a Topic publish/subscribe approach. An MVC web site will subscribe to the Windows Azure Service Bus topic, and whenever the subscriber receives a ping from the service bus with a new image taken by the Kinect, it will use a SignalR hub to update an HTML client with the new photo. Here's a high-level architectural diagram of how the whole thing works, end-to-end.

The Kinectonitor Core Project

Within the core project will exist a few common areas of functionality. The idea behind the core project is to provide a domain structure, functional abstraction, and initial implementation of the image publication concept. For all intents and purposes, the Kinect will be publishing messages containing image data to the Azure Service Bus, and allow subscribers (which we’ll get to in a moment) their own autonomy. The ImageMessage class below illustrates the message that’ll be transmitted through the Azure Service Bus.

A high-level abstraction will be needed to represent consumption of image messages coming from the Azure cloud. The purpose of the IImageMessageProcessor service is to receive messages from the cloud and to then notify it’s own listeners that an image has been received.

A simple implementation is needed to receive image messages and to notify observers when they’re received. This implementation will allow the SignalR hub, which we’ll look at next, to get updates from the service bus; this abstraction and implementation are the custom glue that binds the service bus subscriber to the web site.

Next up is the MVC web site, in which the SignalR hub is hosted and served up to users in an HTML client.

Wiring Up a SignalR Hub

Just before we dive into the MVC code itself, take a quick look at the solution again and note the ServiceBusSimplifier project. This is a super naïve, demo-class wrapper around the Windows Azure Service Bus that was inspired by the far-more-complete implementation Joe Feser shares on GitHub. I used Joe’s library to get started with Azure Service Bus and really liked some of his hooks, but his implementation was overkill for my needs so I borrowed some of his ideas in a tinier implementation. If you’re deep into Azure Service Bus, though, you should totally look into Joe’s code.

Within the ServiceBusSimplifier project is a class that provides a Fluent wrapper abstraction around the most basic Windows Azure Service Bus publish/subscribe concepts. The ServiceBus class (which could probably stand be renamed) is below, but collapsed. The idea is just to get the idea of how this abstraction is going to simplify things from here on out. I’ll post a link to download the source code for this article in a later section. For now, just understand that the projects will be using this abstraction to streamline development and form a convention around the Azure Service Bus usage.

A few calls are going to be made in calls to the ServiceBus.Setup method, specifically to provide Azure Service Bus authentication details. The classes that represent this sort of thing are below.

Now that we’ve covered the shared code that the MVC site and WPF/Kinect app will use to communicate via the Azure Service Bus, let’s keep rolling and see how the MVC site is connected to the cloud using this library.

In this prototype code, the Global.asax.cs file is edited. A property is added to the web application to expose an instance of the MockImageMessageProcessor, (a more complete implementation would probably make use of an IoC container to store an instance of the service) for use later on in the SignalR Hub. Once the service instance is created, the Azure Service Bus wrapper is created and the ImageMessage messages are subscribed to by the site MessageProcessor instance’s Process method.

When the application starts up, the instance is created and shared with the web site’s server-side code. The SignalR Hub, then, can make use of that service implementation. The SignalR Hub listens for ImageReceived events coming from the service. Whenever the Hub handles the event, it turns around and notifies the clients connected to it that a new photo has arrived.

With the Hub created, a simple Index view (and controller action) will provide the user-facing side of the Kinectonitor. The HTML/JQuery code below demonstrates how the client responds when messages arrive. There isn’t much to this part, really. The code just changes the src attribute of an img element in the HTML document, then fades the image in using JQuery sugar.

Now that the web client code has been created, we’ll take a quick look at the Kinect code that captures the images and transmits them to the service bus.

The Kinectonitor Monitor WPF Client

Most of the Kinect-interfacing code comes straight from the samples available with the Kinect SDK download. The main points to be looked at in the examination of the WPF client is to see how it publishes the image messages into the Azure cloud.

The XAML code for the main form of the WPF app is about as dirt-simple as you could get. It just needs a way to display the image being taken by the Kinect and the skeletal diagram (the code available from the Kinect SDK samples). The XAML for this sample client app is below.

When the WPF client opens, the first step is, of course, to connect to the Kinect device and the Windows Azure Service Bus. The OnLoad event handler below is how this work is done. Note that this code also instantiates a Timer instance. That timer will be used to control the delay between photographs, and will be looked at in a moment.

Whenever image data is collected from the camera it’ll be displayed in the WPF Image control shown earlier. The OnKinectVideoReady handler method below is where the image processing/display takes place. Take note of the highlighted area; this code sets an instance of a BitmapSource object, which will be used to persist the image data to disk later.

Each time the Kinect video image is processed a new BitmapSource instance is created. Remember the Timer instance from the class earlier? That timer’s handler method is where the image data is saved to disk and transmitted to the cloud. Note the check being performed on the AreSkeletonsBeingTracked property. That’s the last thing that’ll be looked at next, that’ll tie the WPF functionality together.

If the Kinectonitor WPF client just continually took snapshots and sent them into the Azure cloud the eventual price would probably be prohibitive. The idea behind a monitor like this, really, though, is to show only when people enter during unexpected times. So, the WPF client will watch for skeletons using the built-in Kinect skeleton tracking functionality (and code from the Kinect SDK samples). If a skeleton is being tracked, we know someone’s in the room and that a photo should be taken. Given that the skeleton might be continually tracked for a few seconds (or minutes, or longer), the Kinect will continue to photograph while a skeleton is being tracked. As soon as the tracking stops, a final photo is taken, too. The code that sets the AreSkeletonsBeingTracked property value during the skeleton-ready event handler is below.

Some logic occurs during the setter of the AreSkeletonsBeingTracked method, just to sound the alarms whenever a skeleton is tracked, without having to wait the typical few seconds until the next timer tick.

That’s it for the code! One more note – it helps if the Kinect is up high or in front of a room (or both). During development of this article I just placed mine on top of the fridge, which is next to the kitchen bar where I do a lot of work. It could see the whole room pretty well and picked up skeletons rather quickly. Just a note for your environment testing phase.

Summary

This article took a few of the more recent techniques and tools to be released to .NET developers. With a little creativity and some time, it’s not difficult to use those components to make something pretty neat at home in the physical computing world. Pairing these disciplines up to create something new (or something old someway different) is great fodder for larger projects using the same technologies later.

If you’d like to view the Kinectonitor GitHub source code, it’s right here.

The Red Pill

Mon, 12 Dec 2011 13:02:36 GMT

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.

Admittedly, I was relatively late to the Azure party. I’ve been seeing so many colleagues do amazing things with it - Brian Hitney with Rock, Paper, Azure, Mike Linnen with his Netduino/Service Bus/WP7 solution, and Mike Diiorio’s presentation at the Richmond Code Camp. Once I dove in, I couldn’t look back, and now, I’ll be finding just how far the cloud goes.

My team is amazing and I’m honored to be a part of it. I’ll be working with/for Wade Wegner, Nathan Totten, James Conard, Drew Robbins, and a lot of other bright, talented folks in Building 24. I’m not sure what specific Azure areas I’ll focus on out of the gate, but API’s and SOA’s are areas of interest to me and I hope to focus in those areas. Right now, I’m just thankful to have the opportunity and look forward to getting started.

The next few months will be interesting, to say the least. The position is based out of Redmond, so after years of wanting to near Seattle (my favorite city so far), my family will finally have the opportunity. We’ve started investigating our options and preparing ourselves, and we have been overwhelmed at how hospitable and helpful Microsoft is being to help in the transition.

Testing SignalR Connections with NUnit

Mon, 12 Dec 2011 13:02:35 GMT

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.

Creating Custom SignalR Connections

The first step is to create a custom SignalR connection. For the purposes of this example a simple connection implementation will do just fine. Borrowing from the example on the SignalR GitHub site is the EchoConnection class below.

The implementation of the EchoConnection should be relatively self-explanatory. Whenever the connection receives a message from a client, it turns around and sends that message out to all the connected clients using the Broadcast method.

Unlike SignalR Hubs, which are automatically wired up and routed, SignalR Connection classes aren’t (at least, I don’t know that they are). There’s an additional step with SignalR connections; they must be routed similarly to how MVC routes or WCF Web API routes are set up. The code below is from an MVC 3.0 application’s Global.asax.cs file, but you could accomplish the same sort of thing using a custom module.

The point here is to define a route that will provide HTTP access to this connection class. Next, the client code needs to be written. That’ll be accomplished using an NUnit test (it’s really an integration test, but that’s semantic sugar).

Using the SignalR.Client NuGet Package

The example source code contains a simple class library project. This project references the SignalR.Client NuGet package to provide .NET client communication functionality to an application written in managed code. You can use the SignalR.Client project in your desktop applications or in back-end services or Azure Worker Roles. The class library project is shown below, so you can get an idea of the minimal dependencies necessary to support .NET client SignalR support.

SignalR.Client makes use of Newtonsoft.JSON, so that project gets pulled in automatically when you update your NuGet package references. Caveat/Gotcha: I had to explicitly redirect this class library project’s App.config file to the newest version of the Newtonsoft.JSON assembly. You might not need to do that, but just in case, here’s how.

Writing the Test

At this point, the project is properly set up and everything should be ready for setting up the unit (or integration, depending on your stance) test to communicate with the SignalR connection.

It is important to point out that this test makes use of the AutoResetEvent class to wait for the asynchronous process to complete. This is done because SignalR’s communication via either the connection or hub approach implies that the communication is asynchronous.

If this test is run when the web server is turned off, it will obviously fail, as the test output below from NUnit demonstrates.

Once the web server is started and the test re-run, the client receives a message almost as soon as it finishes sending it, and the test passes.

Summary

SignalR is an asynchronous messaging library designed to provide push-like functionality and continuous connectivity for web clients. However, it isn’t just for the web; SignalR connections can be used from within .NET code to provide instant communication and constant connectivity between multiple clients.

Happy coding!

JSON-based WCF in Azure

Mon, 12 Dec 2011 13:02:35 GMT

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.

WCF Can do JSON, and it isn’t Difficult

I promise. Most of the examples you’ll see cover possibly too much of the configuration specifics and focus on how Visual Studio can generate proxies for you. Though that’s a great facet of the IDE, there are some natural limitations to comprehending the moving parts within WCF if you always let the IDE take care of the plumbing. Once you get into implementing JSON services in WCF, the IDE generation can actually make things more difficult. If you'd like to follow along in the Visual Studio solution you can download it here.

To start with, here’s a snap shot of the Visual Studio solution. Each project should be relatively self-explanatory in purpose. Each will be examined in a moment.

At this point, a closer examination of each project is in order. Don’t worry, there’s not a lot to each project. This won’t take long. You’ll be amazed how easy it could’ve been the whole time and even more amazed how easy it is to get your JSON API’s into Windows Azure.

Service Contract and Implementation

This example will be a simple and familiar one; the service layer will expose calculator functionality. Hopefully, a later blog post will go into more detail on complex messaging, but for now, a calculator serves the explanation well.

The screen shot below demonstrates the ICalculator service interface. Note it has been decorated with the typical service model attributes, as well as the WebInvoke attribute. Within the WebInvoke attribute’s constructor, JSON is being used as a request and response style.

This attribute code simply says “when the application hosts this service, use JSON as the serialization syntax.” It’ll be important that those attributes are on the interface later on in this post. For now, just take a look at the implementation in the screen shot below.

As you’ve seen, the service contract interface is not only where the abstraction is defined, but how the service is used from within WCF. The next piece of the puzzle is how the service will be hosted within a Windows Azure worker role process.

Hosting WCF JSON Services in Windows Azure

There are a number of great resources on StackOverflow or CodeProject on the details of hosting a WCF service in Azure, so this article won’t dive too deeply into the intricacies. Rather, this next section will dive right in and get things done.

WCF Services can be hosted in numerous ways. A few options are available via Windows Azure, from hosting in a typical web application environment to being hosted and configured manually in a Worker Role. The code below demonstrates the second option via a worker role class.

The important method, HostService<TService, TImplementation> is closed in the screen shot above, as it’ll be examined in somewhat more detail below. The HostService method does just what it says – it hosts a WCF service implementation as represented by a decorated WCF interface in the Windows Azure worker role.

This method just declares a new ServiceHost instance, then sets that instance up on the WebHttp binding so that JSON communication can take place. In particular, the code requires one step of configuration take place. The code that looks at the Worker Role environment’s end points collection is shown below.

This stipulates a convention. That each service endpoint will be named in the endpoints configuration according to it’s type’s name. In this example case, the Calculator class is the one that’ll actually be placed on the WCF binding. The screen shot below demonstrate how and in which file this can be set using Visual Studio 2010.

At this point, the worker role should be configured and ready to run. If the project is run in debug mode at this point the computer emulator will open and the trace output is visible. The screen shot below shows the compute emulator running. The highlighted sections are the custom trace messages the code writes at run-time.

The final step is to write a client to consume the service while it is being hosted in Windows Azure.

Calling via a Unit Test

This service only exposes one small unit of functionality, so it stands to reason a unit test could be a good method of testing the service. Sure, it’s test-after, but that argument is for another time! For now, let’s finish this example up by calling the WCF service being hosted in Windows Azure. Just to prove there are no smoke and mirrors, here’s what the URL from the compute emulator will expose when suffixed with the UrlTemplate format from the ICalculator service definition from earlier.

To know about the service, the unit test project will have a reference set to the contracts project. So that the unit test will know how to call the service in the cloud, the unit test project will need a tiny bit of configuration added to it’s app.config file. The screen shot below demonstrates both of these steps.

I mentioned early on that this post would demonstrate proxy formation without the use of the service references functionality of Visual Studio. The class below demonstrates how this can be achieved. By inheriting from the ClientBase<T> class and the interface being exposed by the service, you can create a custom proxy class in a minimal amount of work.

Finally, the unit test can be authored.

When executed, provided the calculator service is being hosted in Azure, the results should be immediate. The test passes, the result of the calculation yielding a correct result.

Looking back at the compute emulator that was running when the unit test client was executed, the evidence the service is handling requests is apparent. The screen shot below highlights a pair of executions from when the test was executed.

Summary

This article took a no-nonsense approach to demonstrating how simple it is to host JSON-serialized WCF services in Windows Azure. Azure is an amazing resource for developers who want to expose aspects of their application in open web API’s. Hopefully, this example has demonstrated how easy it is to get started doing just that. Soon, you’ll be RESTing in the Cloud, with your very own WCF JSON API’s.

Download the Visual Studio.NET solution for this article.

The Robot Factory Kata

Mon, 12 Dec 2011 13:02:34 GMT

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.

So, I took the example problem domain of a robotic assembly line that I've been using since I was training full-time under the guidance of J. Michael Palermo IV and implemented it using SpecFlow and Moq. So far, the Robot Factory Kata video series has two videos.

The first of these demonstrates the project setup and configuration, and starts solving the problem using SpecFlow specifications and NUnit tests.

The second part helps demonstrate how mocking method verification using callback expectations to demonstrate testing interaction between two objects. Sure, this is getting into integration testing, but the idea is to demonstrate BDD using a legitimate problem domain that's slightly more interesting than the construction of a calculator. Not that there's anything wrong with that, but you know, it helps to have variety.

Hope you enjoy these video demonstrations and that they motivate you to start BDD'ing today.

From the Cloud to the Client

Mon, 12 Dec 2011 13:02:34 GMT

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.

Azure and AppFabric can seem like huge, daunting problems. I was shocked how simple both were to use and admit that, like many technologies, the problem isn’t in their difficulty but in my willfulness to just learn how it works. Once I dove in I had a queue up and working in about 5 minutes on the first try. Mike Diiorio gave a great introduction into how AppFabric works at the Richmond Code Camp. Some of the code in this blog was inspired by the code he presented there. He really made the Azure service bus seem quite easy and made my adoption of it a lot more rapid. I’d highly recommend you check out his talk if the opportunity arises.

Service Bus Namespace Authentication

To make authentication seamless from both the publication and subscription ends of the Azure Service Bus conversation, one class will be used to persist the authentication information. The CredentialDetail class below serves to represent the service bus and the namespace under which it resides in the Azure cloud.

To give this some context, the corresponding service bus is shown below in the Azure management site. Note the red boxes; that string matches the string property Namespace in the credential class we’ll be sharing for all clients of this service bus. The IssuedKey and Issuer properties can be obtained from clicking the View button in the Azure management site.

Sending Messages to Azure

This application is a regular, boring old Console application, but you could send messages into Azure Service Bus from pretty much anything or you could host a WCF service or MVC site in Azure to publish messages to it from the Internet. Whatever the case may be, message transmission into Azure isn’t verify difficult; if you’ve done any message-based coding in the past it should appear relatively familiar in structure. The application first makes a connection to the Azure service bus using the data stored in the CredentialDetail class from earlier in this article.

Next, the Sender class connects to the Azure namespace. Then it either connects to or creates an Azure queue.

Next, the Sender class gets user input at the console and transmits that data into Azure via the queue client.

When the sender application runs, the output should be relatively obvious and simple. It just lets us enter some messages and send them into the Azure queue, then confirms the transmission was completed.

A Service Bus-Aware SignalR Hub

From the title it should be obvious we’re not going to stop by just being able to send messages into the queue. This sample will receive messages from the queue, too, and then notify all connected HTML 5.0 clients instantaneously when messages are pulled from the Azure service bus and processed.

The first step in completing this is a service that will listen for messages. The interface contract for the IQueueReceiver interface is below.

The first implementation for the IQueueReceiver interface will be expecting to get a string message. The StringQueueReceiver service watches the Azure service bus and, when messages arrive, it fires the Received event to notify any of its observers that it has a message for them.

The observer, in this case, is going to be a SignalR Hub. Since SignalR Hubs do the heavy lifting of pushing data from the server to the client browser, a custom Hub is a perfect candidate; the Hub will receive the data coming from the Azure bus, then hand it off to all the HTML clients. The ServiceBusListenerHub will depend on the StringQueueReceiver so it’ll be passed in via constructor injection.

This is where a deeper dive into how SignalR can use your favorite IoC container comes into play. Since Hubs are transient, and the nature of listening to a queue indefinitely is a more permanent type of thing, we’re going to inject the listener service into our SignalR Hub. My favorite IoC container is Unity, so I’ve rolled my very own Unity startup implementation per the specs from the SignalR team and using the WebActivator NuGet package.

Once the Unity container is set up, the service can be added.

The Hub will have one method, Initialize, that HTML clients will call at page ready. This call clears any previously bound event handlers on the IQueueReceiver.Received event, then binds to it to make sure that incoming messages are then passed to the HTML clients.

Client Code

The client code is quite simplistic. Just a few lines of JavaScript files to set SignalR and to get everything wired up.

Then a few more lines to initiate communication with the Hub.

Once that’s finished the client should start to receive messages as they’re being sent in from the service bus.

Summary

This article introduced the idea of creating an Azure Service Bus implementation (which was what I’d planned on learning through the exercise, so I met my personal goal). The messages are taken from the bus, thrown into a SignalR Hub, which then transmits those messages directly to HTML 5 browser clients. Hopefully this will inspire you to create a few Azure bus or SignalR toys yourself. The possibilities are pretty staggering!

Doing BDD with SignalR and Jasmine

Mon, 12 Dec 2011 13:02:33 GMT

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:

So how testable is SignalR? If the magic of it is based in some form of maintained connection, the implication of how one has to code asynchronously against it makes testing p-r-e-t-t-y difficult. Testing in JavaScript is pretty difficult to begin with, so now what?

There’s this amazing TDD/BDD micro-framework called Jasmine that lends itself extremely well to all sorts of different JavaScript problem domains. I learned about Jasmine from some colleagues in the Ruby community, then found some pretty awesome resources on Jasmine, and have been waiting for an opportunity to try it out. This seemed like a perfect opportunity, so I dove in.

The Calculator SignalR Hub

This example will offer a solution to the simple problem of providing basic numeric calculations. Obviously, the first operation most users will need is some addition functionality.

The implementation of this method might look a little strange if you’re new to SignalR. It’ll make sense in just a moment when you see the corresponding JavaScript code. Think about it this way; the Clients property of any Hub is dynamic object that will represent a corresponding JavaScript method on each of the clients connected to the Hub.

The controller action for the client has no special glue or magic in it. It’s basically a shell to adhere to the requirement of having an action for the views.

On the client, there will be a few script references to make sure SignalR works properly.

This is the part where the dynamic client thing should make sense. The JavaScript code below demonstrates how to call this dirt-simple SignalR Hub and to generate some action on the client.

The call earlier, within the implementation of the Hub, is basically a way of the server telling the client, would you please run this method and pass it this data? It isn’t a really sexy example when you see it execute, of course, but it drives the point home. SignalR makes push ridiculously simple.

Bring on the BDD!

As if SignalR isn’t nifty enough, Jasmine gives us the ability to set up specifications and unit tests to make sure things are working properly and to guide development. Now, we get to put them together to answer the problem of how to test the client. (I’m not knocking other methods, like WaTiN or other automated testing implementations, here, this is just another way of skinning the same kitty.)

We’ll need to include the basic script references and CSS file to make Jasmine light up. You can download those from the Jasmine site, or they’re included in the GitHub repository I’ve created for the purpose of my continued tinkering in SignalR.

Once the Jasmine files are in place, it doesn’t hurt to create a pulse-check specification to make sure the glue’s dry. The JavaScript object shell below will be a roadmap for how we’ll solve this problem.

Once the specifications have been written up, Jasmine’s environment is created and the tests are executed.

If you’ve pinned the tail on the donkey to this point, the results should be quite self-explanatory when you view the calculator page again. If you don’t see the tests, check the passed checkbox and the passing test will appear.

At this point, to test that the SignalR CalculatorHub is communicating with the client properly all that’s really needed is a way to call the Add method from in a unit test and to verify that the JavaScript code’s showSum method executed with a parameter of 4.

The first step in getting this working is to modify the test fixture class so it can be supplied any dependencies it might have. In this case, we plan on testing the calculator hub, so it’ll be passed into the fixture in it’s constructor. Also added is the addCallback field. At this point it’ll be set to false, but the plan is, to set this variable to the callback method that will be called when the calculation is completed by the hub.

Since the constructor’s changed it’d be wise to change the calling code, our jQuery ready method. This time, we’ll go ahead and create an instance of the SignalR CalculatorHub and it’ll be provided as a construction argument.

Next, a new specification is added to the init method. This specification is the unit test that will demonstrate the calculator’s being called properly from the client JavaScript.

It’d help at this point to take a peek at the Jasmine Wiki article on Spies to get an idea of how this sort of verification can be accomplished. Jasmine’s Fluent syntax makes it pretty self-explanatory (and including vsdoc files to provide Intellisense in Visual Studio brings in the Jasmine methods). Jasmine, like Moq and other mocking frameworks, offers unit tests the capability of checking to see if methods have been executed properly.

If your Jasmine tests are executed at this point, you’ll see some p-r-e-t-t-y interesting results. For about 5 seconds the browser will let you know something’s happening by making the current test’s background color yellow.

Then the test will complete execution and fail. Jasmine is assuming via those calls earlier assume they should wait for an asynchronous response and if it doesn’t arrive, the tests will fail. They fail because the callback methods are never executed, and the tests expect them to be.

That addCallback field that was added to the test fixture is how this can be accomplished. The client’s showSum method is the one thing that’s been omitted from the JavaScript code. That’s the method that the SignalR hub will try to call on each client whenever it needs to do so.

Within the test fixture resides the onAdd method. It just executes the fixture’s addCallback method and feeds it the results from the SignalR CalculatorHub call.

Once that’s all wired up, the test should pass!

If you’re obsessive about verifying, just change the expected value to be something wrong and re-run the test. Obviously, if the math fails, so should the test. Otherwise it’d be a pretty useless calculator!

Recap

SignalR and Jasmine work quite nicely together. If you apply a little OO elbow grease and take the time to wire things up with callbacks and to verify the execution of those callbacks, SignalR can be tested rather effectively. All it takes is to properly stage, and then verify, that the Hub’s method is called and that, when the Hub fires the client callback, that the callback is executed as your code expects it to be executed.

Thanks for taking the time to stop by. Happy Coding!

Richmond Code Camp

Mon, 12 Dec 2011 13:02:33 GMT

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.

My favorite observation from the weekend is that it seems like the Microsoft community is finally beginning to realize how much work Microsoft is doing for it and either appreciates, or finally admits in public that it appreciates the contributions Microsoft has been making. There were a few participants and discussions I heard in hallways that were inspiring. I heard a few discussions between OSS enthusiasts who were speaking favorably, rather than with fear and loathing, about a few different .NET projects produced both within Microsoft and independent. That's inspiring, considering that just a few years ago the public opinion of Microsoft's support of OSS a joke, and I heard more snickers and doubt than I did appreciation. That's motivation for myself, those out there who are ISV'ing themselves, and those who want to utilize open-source contributions to ease their own development pains.

What's frustrating about that is that projects like SignalR might go un-noticed by participants who lack the time or knowledge to maintain a very active level of involvement. Yes, SignalR is new and I'm probably being impatient in wanting the community to get on it yesterday, as is a lot of other technologies within and outside of the .NET stack that need discovering. I fear that, after years of bickering about how Microsoft fails to support the open-source community, that once Microsoft does openly begin supporting the open-source community and the open-source community begins to admit to itself that Microsoft really is supporting it (that was the hard part IMO), that Microsoft misses a few golden opportunities because it fails to market its own efforts effectively. I think we need to do our best to keep researching these young micro-frameworks and pushing the envelope of what's possible in our development framework. That shared contribution thing... it really works!

I didn't get to spend a lot of time with my out-of-state colleagues this weekend, but it was nice to see everyone for the brief conversations and dinner last night. Looking forward to seeing everyone at the next event!

MyNuGets - An Orchard Module for NuGet Fans

Mon, 12 Dec 2011 13:02:32 GMT

If you enjoy using NuGet to obtain and distribute your open source work and you maintain a blog or a site using Orchard, this post's for you. I've written a widget that will allow you to enter your author name. Then, the widget will hit the NuGet OData API and find any packages published with that author name. From that, the HTML is build up through the Orchard pipeline and what you get is a nice list of NuGet projects. Check it out for yourself on the MyNuGets project page or in the Orchard Gallery.

Custom Authentication with MVC 3.0

Mon, 12 Dec 2011 13:02:32 GMT

During a friendly code review discussion a week or so ago I realized I’d forgotten my favorite lore of custom authentication/authorization functionality in lieu of ASP.NET P&M. Though I definitely prefer P&M to rolling my own from scratch to the extent that I’ve gone as far as to use it as a pass-through there are some times when P&M is too much – or too little – so custom schemes must be developed. The thing that surprises me each time I observe a custom scheme is the lack of usage of the IPrincipal/IIdentity interfaces. With MVC 3.0 as my major weapon of choice in web development and my recent adoption of P&M, it became obvious that an opportunity had popped up for mixing my favorite old-school .NET trick into my favorite new-school paradigm.

Here’s the thing. If you don’t use the IIdentity and IPrincipal interfaces when you create a custom authentication/authorization solution you’ve completely missed the boat and I guarantee you you will write 100 times more code, that will be more brittle, than you would have ever written had you just used them in the first place.

A quick look into what these two interfaces offer is in order. The graphic above sums it up visually. You’ll see that the IIdentity interface is typically considered a requirement for the IPrincipal to exist; obviously this model fits in rather well with MVC’s favoritism to IoC/DI practices. The principal wraps around the identity, supplying access to a user’s roles. So long as your classes implement the requirements, they can be bound to the HTTP Context, the current thread, basically attached the process so that all the niceties like use of the [Authorize] attribute and role-based location security via the web.config file are possible without tons of rework.

The first class needed in any custom implementation is the identity class. The main purpose of this implementation is to represent the user’s name, really, as well as how the user was authenticated and if they are authenticated. Should the IsAuthenticated property be set to false at run-time, code later on assumes the user is an anonymous user.

Next will be the CustomPrincipal class. Since this class implements IPrincipal, it can be used to bind itself directly to a thread (or an HTTP Context). Since it can be used in that manner, all the functionality and support offered via web.config-based authorization, use of the [Authorization] attribute, all of that – it will be maintained and you won’t have to write it (or support it, or debug it, and so on). Note how the constructor’s argument is highlighted to illustrate the connection between the two classes.

To wrap these classes up via a native event handler or inherited method we’ll create a BaseController. It could – and probably should – be done via an injected service, obviously, but I’m honoring the KISS principle [you say principle, I say principal] for the purposes of this walk-thru. The base controller is shown below and its main purpose in existing – to authorize the active user account prior to allowing execution of the controller action.

Caveat: This next part isn’t a recommendation, it’s only used for the purposes of keeping this explanation simple. Forgive me.

Now that we’ve satisfied the authorization part we’ve got to authenticate the user and store their login information somewhere for the life of their… yeah, you guess it, for the life of their session. We’re going to use Session here, okay, but just for the demo. It isn’t a recommendation. Please turn off the tape recorder.

The SimpleSessionPersister class below persists the user’s name into a session variable [ducks under flying tomato]. The login controller action below the utility class just validates that the user provided something for their username and password and, if so, the user’s username is persisted to session for use – by the BaseController, specifically – later during the HTTP request.

You can relax now, that part’s over.

Now that the user has been authenticated we can assume that each controller we create (provided it inherit from our custom base) will authorize each individual request per the best-practice role-base security means. Take the following controller action below, which requires the user be authenticated via the [Authorize] attribute and the web.config, also below, which indicates the login page URL as our Login controller action.

Should a user try to hit the non-anonymous page they’d be redirected to the login page (see the URL highlighted below).

To review the process we went through to accomplish our very own custom-made end-to-end security paradigm that still allows usage of the .NET built-in role-based security resources, here’s what we had to do:

Implement the IIdentity interface in a custom class
Inherit from the IPrincipal interface in a custom class
Create a way to authenticate the user
Create a way to persist the authentication information [a.k.a. username in this example]
Override the OnAuthorization method in a base controller and then use that base controller in future controllers

Happy Coding! If you’d like to take a peek at the code for this demo and debug it for better observation as to how it all works together you can download the code from my DropBox account.

NHQS NuGet Package

Mon, 12 Dec 2011 13:02:31 GMT

This evening I was finally able to get the NHQS library up on NuGet. As always, you can use either the NuGet package explorer or the command-line tool to grab yourself NHQS.

I'll be maintaining most of the general information about NHQS on the main NHQS page here on my site, which you can see in the navigation bar above. Hope NHQS makes your life with NHibernate a little easier!

Happy coding!

Announcing the Release of NDecision

Mon, 12 Dec 2011 13:02:30 GMT

A pet project of mine for a few months, NDecision is finally going to be allowed to see the light of day. You can get it as a NuGet package right now.

If you'd like to see a video of NDecision being installed and used in a brand new project, there's a video below. Finally, click the NDecision link in the navigation bar above if you'd like to read more about NDecision. There's not a lot to it, but that's kind of the point.

Keep watching this blog and the NDecision page, though, I've got some more stuff related to NDecision I'll be talking about in a few days. For now, grab it and start using the BDD decisioning goodness that NDecision offers!

Introducing NDecision.Aspects

Mon, 12 Dec 2011 13:02:30 GMT

If you've not gotten up to speed with the core functionality provided via NDecision it might be good to take a look at the release announcement, which you can find here.

If you're into Aspect-Oriented Programming or you like things to be a little more dynamic and automatic, a second option exists that you might find interesting. The NDecision.Aspects package makes use of the amazing AOP product PostSharp, by SharpCrafters, to enable logic execution automatically at run-time. Rather than write your logical specifications inline, you implement the IHasSpec<T> interface. This interface's single method, GetSpec(), allows you the freedom of wiring up your logic in one place (or in many places, if you prefer to have your specifications split into individual classes based on your own need or preferences).

Refactoring the Example for NDecision.Aspects

I'll build on the previous example and refactor the code to use the NDecision.Aspects package and to provide some insight into the difference. First of all, the logic from the original code has been moved into an implementation of the IHasSpec<BugsBunny> interface.

Once your IHasSpec<T> implementation has been written, the majority of the work is complete. To use the specifications outlined in the IHasSpec<T> implementation, the ApplySpecsBeforeExecution (or ApplySpecsAfterExecution) attribute class can be used to decorate the methods whenever the specifications need to be applied. The screen shot below demonstrates how, using the ApplySpecsBeforeExecution attribute, the rules will automatically be applied prior to the method's logic being executed.

If a second parameter for which there existed IHasSpec<T> implementations were placed on this method, specifications for that parameter would be picked up too. In this way, AOP takes over - for any parameter added to this method for which there exists an IHasSpec<T> implementation, the specifications will be dynamically found and executed on the parameter instance at run-time.

Your rules, in a sense, are automatically applied whenever you want them to be applied.

NDecision with AOP, Option Two - Self-Awareness

Now, there may exist a circumstance where your object instances - in this case our favorite childhood cartoon character - should be allowed to do their own work based on the specifications and how they should be applied. In these cases it would be more optimal to have the capability of applying the ApplySpecsBeforeExecution or ApplySpecsAfterExecution attributes to the target class itself (or specifically, to methods of the target class). The code from above has been refactored with this idea in mind. Specifically, we've given Bugs his own method, also decorated with the ApplySpecsBeforeExecution attribute.

Likewise, the program code will need to be changed so that it allows Bugs his autonomy.

Both methods result with the following obvious output - a console window showing the directions Bugs takes on his journey, in the order they were taken.

Just like the NDecision core project, NDecision.Aspects is available for free via NuGet. Don't worry about the dependencies or having to install both packages; simply installing NDecision.Aspects will bring down everything you need, including the PostSharp assembly, as SharpCrafters so generously offer it up as a NuGet package too.

Happy coding! I hope you give NDecision a spin. If you do take the time to play with it, please let me know how it works out for you via the comments form. Or, you can find me on Twitter at @bradygaster.

Developers Guild AOP and PostSharp Presentation

Mon, 12 Dec 2011 13:02:29 GMT

Last night I presented PostSharp and AOP at the Charlotte Enterprise Developer's Guild. I had a great time and the audience seemed to enjoy the topic.

I've put the code samples and presentation deck in my public Dropbox so feel free to download it and should you have any feedback it is welcome. In fact, I've set up a SurveyMonkey survey for the participants, so if you have a moment and you attended the presentation I'd appreciate you taking 1-2 minutes and completing the survey. Every little bit of feedback helps me improve these sessions, so anything you can provide would be helpful. Below you'll find links to the code and the evaluation, as well as links to some of the resources I mentioned in the presentation.

Thanks for attending the session if you were there, thanks to the Guild organizers, and thanks to my boss Dan who let me remote into my laptop from his when the mini DVI jack failed for a second time (at least now we think we know what it is, though).

Netduino Controlled by Kinect

Mon, 12 Dec 2011 13:02:29 GMT

Update: I've uploaded the code I wrote for this demonstration project to GitHub into my KinectControlledNetduino public repository. I also forgot to mention that the Kinect code makes use of the excellent gesturing engine created by David Catuhe, which you can read about on his blog or download from CodePlex.

I'll put the code up here tomorrow once time and energy permit, but for the time being the title says it all. There's a Kinect, it controls a WPF app, that app sends messages to an HTTP server running on a Netduino, which is connected to a servo.

Using hand gestures like "SwipeRight" or "SwipeLeft," a user can literally wave to the Kinect to tell it how to tell the Netduino server how to angle the servo. Pretty neat, and quite easier than I'd expected. I'll post the code ASAP but for now here's a video demonstrating how it works.

Introducing the NHibernate QuickStart (NHQS, Part 1)

Mon, 12 Dec 2011 13:02:28 GMT

If you’ve worked with me over the past year or you’ve seen one of my alt group meetings, chances are I’ve mentioned, demonstrated, or maybe stuffed down your throat, the NHQS thingamabob. With the improvements in NHibernate following .NET 4.0 and the experiences I learned in a few projects in the previous release I’ve decided to rewrite NHQS for NHibernate 3.xx. I like the improvements in NHibernate and with those and a slightly renewed focus on my goal for NHQS I felt it might be worthwhile to introduce it on its own into the wild. This post will introduce the world to NHQS and provide a guideline for its usage.

As usual the project is only as effective as is the goal it intends to serve so let’s get that out of the way.

A lot of developers want to use NHiibernate, or Fluent NHibernate, or some flavor therein, but don’t want to learn the layers and layers of how-and-why it works just to get up and running. NHQS should mitigate this confusion and ease the transition into usage of NHibernate. A secondary goal of NHQS is to make it easy for a developer to have access to any and all persistent storage mechanisms supported by NHibernate in a fluent and domain-centric manner. At the highest level, a developer facilitating object persistence via NHQS should neither need to know nor be exposed to the underlying persistence mechanism.

To accomplish that goal we’re going to walk through the steps of setting up and using NHQS to access multiple databases via the almost-too-simple-to-be-legit fluent/generic interfaces exposed almost solely via extension methods. I’m sure I’ll get burned at the stake for failing to follow someone’s NHibernate Best Practice 101 list, so I’ll apologize up front. With that, here’s the synopsis of the blog series, which I aim to complete by the end of this week.

NHQS in 30 Seconds

There are a few steps one must follow to get their persistence mechanism accessible via NHQS. Here they are:

Implement the ISessionFactoryCreator interface via a class of your own (we’ll cover this in a moment)
Add code to the startup of the calling application (or in your TestFixtureSetup method) that calls the Create method of that class to create an NHibernate ISessionFactory object instance
Take the resultant ISessionFactory and store it using the SessionFactoryContainer class
Write DDD-like code to get objects from databases and perform CRUD operations via an arsenal of extension methods attached to areas of NHibernate

The second post in this series will begin the process of using NHQS in a real-world situation by simplifying the art of creating ISessionFactories and storing them in a container, so check back soon.

If you’d like to skip the blogs and look at the source, feel free, I keep the NHQS source in Github.