Archive for category Uncategorized

(Re)claiming My Blue Badge

TL;DR: Microsoft offered me a position on the Windows Azure Service Bus team and I took it. I’m ex-Microsoft and I reclaim my blue badge on February 11, 2013.

Longer version: From 2000 to 2006, I worked at Microsoft on MSDN and later on Indigo (WCF). The family loved living in Washington state and I loved my job at Microsoft. However, my wife and I don’t ever want to look at life and see ourselves doing things that we know we will regret. One of the things we were starting to regret was not letting our kids get to know their extended family. In 2006, my wife and I chose to return to the Midwest so that our three children (then 10, 5, and 3 years old) could get to know their cousins, aunts, uncles, and grandparents. Since 2006, we’ve been able to attend graduations, weddings, and generally get to visit family whenever the spirit moved us. We got to know everyone in our extended family quite well. As happens quickly, the families have seen their kids get older, other activities occupy more of their time, and this has limited the ease in all of us getting together. Essentially, Thanksgiving works great- everything else is a crap shoot.

Over the last 2 years, getting together just got tougher, so my family reevaluated our goals and wants. We decided we wanted to go back to the Pacific Northwest and I figured that, if I’m going to move there, why not work for Microsoft again? One of the teams I was interested in was the Windows Azure Service Bus team. They had an opening and after a nice, long day of interviews, they decided to take a risk on an RD and Integration MVP. I really clicked with the team, so I accepted the offer. This choice also allows me to work on one of the largest scale systems in the world on a product that ships on an Internet cadence. I’m extremely excited about this opportunity and can’t wait to get into the code.

I plan to continue recording courses for Pluralsight on the weekends and evenings- the authoring/teaching bug bit me back in 1998. Pluralsight provides a great way to scratch that itch.


New work machine

Back in 1999, I officially gave up on the desktop computer. Since then, my personal machine has always been a desktop replacement quality laptop. I enjoy being able to take a powerful box wherever I go. This past December, I felt a need to get a portable machine that supported Windows 8 with multi-touch. I’m floored by how light a desktop replacement can be! I wound up with a Lenovo X230 tablet. The thing is small- 12.5” screen. I equipped it with a slice battery so that I can work a full day away from a power source. You can also easily enhance the box to make it a wonderful workhorse. I picked up the I5 configuration with the basic memory and HDD. About 2 hours after receiving the unit from Lenovo, the machine had:

  • 16GB RAM (Crucial)
  • 256GB mSATA SSD boot disk (Crucial)
  • 512GB Samsung SSD
  • Screen protector
  • Windows 8

When in its docking station, the machine drives a 27” Planar touch screen over DisplayPort and a second regular 27” Acer monitor over a USB to DVI display adapter. For the past several weeks, I’ve been using this setup to get stuff done wherever I go. I’m impressed with how small and light the X230 is. Travelling with this little machine has been pleasant. It’s easy to get work done with it on a plane, including writing code. This machine also runs virtual machines like a champ, which has been helpful for me to get my experimentation done and in just learning new stuff.

I will acknowledge that this laptop is not for everyone. For me, it met some important requirements:

  1. Support multiple HDDs: I frequently rebuild my system due to the amount of beta software I tend to run. Keeping apps on one disk, data on another means I just need to reinstall my apps—the data is automatically available.
  2. Support a lot of memory: I use VMs a lot. 16 GB seems to be a good min bar for support, though I would have preferred 32 GB as is supported on the W520.
  3. Weighs little: I wanted something that was light. I’m getting older and the W520 kills my back when I carry it in a backpack. The x230 is just tiny—and the power supply is super small too!
  4. Airplane friendly: I like to write code on planes. The W520 wasn’t comfortable to use in coach. The X230 is alright in those small seats.
  5. Docking station: I don’t want to think about reconnecting monitors, USB, keyboard, mouse, microphone, and more when I want to sit at a desk with bigger screens to get “big things” done. Most of the light and portable machines don’t support docking stations. The X230 does.

Given what is coming out for ultralight laptops over the next 6 months, the X230 still looks like a great option. If you are doing Win8 development and need a touch device, or just want a nice, light development machine, I highly recommend this little beauty.

Leave a comment

Revisiting REST Versioning

I was recently asked what my opinion was on REST versioning, a few years after having written and after having recorded some stuff for Pluralsight on versioning as well. The questions were general purpose enough that I thought I’d share my answer on the blog. Here are the questions and my answers:

1. Given 2.5 years since the article, have you seen any shift toward one or the other method in the industry?

What I’ve seen in behavior is that people only change the URL for breaking changes. They try like crazy to always use the same endpoint for everything, including new functionality. I have seen a lot of uptake with the WebAPI bits released in .NET 4.5. Some companies have gone NUTS on the ability to negotiate content types, and this is for applications for big companies with thousands to millions of customers.

For APIs meant to be consumed by less process oriented folks, I see more APIs that just use JSON. The API owner then documents things for internal SDK development teams. What appears to happen is the internal SDK development teams ‘test’ the docs by building APIs in .NET, Ruby, PHP, Java, Objective C, and so on. When this phase is done, the QA’d REST documents and resulting SDK documentation is published. Development of an SDK seems to be done in an effort to make API adoption easier and to reduce the amount of support needed to get API consumers up and running.

If I was leading a REST API development project, I would design a good structure, document whatever the team did for the REST API, and then lean on the SDK as the only well supported mechanism for accessing the API. This move would let the team build a nice SDK without worrying about making sure everyone can understand the REST documentation. The reality is that most developers do not know and do not want to fully understand the intricacies of content negotiation, cache headers, and so on. They just want to build software. Your job is to worry about these things and a good SDK makes it easier for all users to do the right things.  

2. If you were building a new API today what direction would you go?

I’m reading this as a SOAP question as well as a “how do I build a REST endpoint today?” question. The answer is: it depends. If I need the API to be consumed by internal endpoints, SOAP gives me a faster way to build things and, since the app is internal, it’s highly likely that transaction consistency, security, and an RPC-like calling convention fit in well with the existing needs. I’d still version endpoints as much as I could, but reality is that most places roll out new versions of systems that need to be versioned in lockstep due to business and regulatory concerns that versioning simply does not care about. Oftentimes, the reason for the new version is new requirements that make the old version obsolete.

For external APIs, I’d only ever use HTTP based APIs. Then, the question is obviously: do you create new media types and use content negotiation, do you use new endpoints for version changes, or do you use something else? My preference today is to use new endpoints and worry about wiring things up correctly under the covers. Doing this allows me to monitor usage of each version using existing HTTP log scraping tools and seeing which URLs are being used most heavily. For everything else: how RESTful I am vs. just using HTTP as an RPC mechanism, data types, payloads, and so on, I’d stick with building SDKs as the preferred method to interact with the service. I value good design but I hate arguing about things like whether or not the ETags are configured correctly. The SDK documents the API team’s decisions where those arguments happened and let’s everyone else just use things.

3. Do you know of any particularly good resources on the topic of the top of your head that don’t come up in google and bing?

Actually, no. It seems like a lot of great stuff was written about designing REST APIs and what I’ve found on the various search engines all seems pretty decent. Today, tools like WebAPI from Microsoft and others make it easy to do the right things as an API developer.

1 Comment

Body Scanners, Fluoroscopes, and the TSA

From the 1920s through about 1960, shoe stores used an amazing device to sell shoes: the fluoroscope. Depending on the year, the reason behind the device changed; it helped you fit the shoe better, it revealed any issues in your foot, it was cool to see the bones in your foot move. The fluoroscope achieved this magic through x-rays. By the 1950s, people understood that being exposed to lots of x-rays was really bad for people. Overexposure to x-rays increases the odds you get various cancers. In 1957, Pennsylvania started a pattern of governments banning the devices( The fears were along the lines of the following:

  1. Growing people (kids) shouldn’t be exposed to this many x-rays.
  2. Lots of x-rays were taken of the salespeople.

Think about #2. According to, people got radiation burns and cancers from lots of exposures.

Many shoe salespersons put their hands into the x-ray beam to squeeze the shoe during the fitting. As a result, one saleswoman who had operated a shoe fitting fluoroscope 10 to 20 times each day over a ten year period developed dermatitis of the hands. One of the more serious injuries linked to the operation of these machines involved a shoe model who received such a serious radiation burn that her leg had to be amputated (Bavley 1950).

Interestingly enough, the Transportation Security Administration has installed thousands of x-ray machines as full body scanners. Frequent travelers are getting x-rayed several times a week. TSA employees are getting nearby exposure scans hundreds of times per day. Because of concerns around the health effects, a case was brought and was decided against the TSA that they need to figure out if these machines are safe. Our executive branch needs to enforce this ruling, but so far have chosen not to enforce it.

If you have some time today, I recommend that you go to and sign the petition to get the executive branch to carry out the decision of the judicial branch.

Leave a comment

Validating a WRAP ACS token in node.js

A few friends and I are building a system for home automation. Specifically, it is an application that opens and closes a garage door. One of the design decisions was to write the server side in node.js but to use Azure when it made sense. One of the Azure features we are using is the Access Control Service. When a client presents a token, you need to make sure that the signature on that token is valid. That turns out to be fairly interesting if you are new to node.js and have never used it before. I fit that model well. After a lot of tinkering and learning, I was able to write a function that validated a wrap_access_token using node.js and some associated, standard libraries. Here is the code, in its entirety. I include some ‘test’ code as well to allow others to verify results. I’ve already rotated the ACS signing key so that I don’t breach security too badly. This whole thing works surprisingly well.

In case you can’t read the code too well, here is what it does:

1. Parse the token into it’s constituent parts.

2. Pass the wrap_access_token to the function, along with the associated key.

Within the function:

1. Remove the signature part from the token since we need to verify that we generate the same signature. Since the signature is generated based on the bytes that precede it, the signature can’t be part of itself (this part is obvious when you think of it; the hard part is remembering to think of it!)

2. Unescape the signature and remember the base64 version of the signature, which is really just a byte array.

3. Generate the SHA256 HMAC signature using the shared secret/key.

4. Verify that the base64 encoding of the digest that we generated matches the one that was sent it.

5. If the signature passed in matches the one we generated, then the other entity knows the secret and can be trusted to have signed the tokens.

6. Party on, because the claims are valid.

The code would next need to split out the claims. The claims are just form-encoded key value pairs within the wrap_access_token. That step is left as an exercise for the reader.

var crypto = require(‘crypto’);
var util = require(‘util’);
var querystring = require(‘querystring’);
var buffer = require(‘buffer’);

function ValidateToken(token, key){
var hmacToken = “&HMACSHA256=”;
var indexOfToken = token.indexOf(hmacToken) + hmacToken.length;
var swtSignature = querystring.unescape(token.substr(indexOfToken, token.length – indexOfToken));
var signedPiece = token.substr(0, indexOfToken – hmacToken.length);
var buffer = new Buffer(key, encoding=”base64″);
var hmac = crypto.createHmac(“sha256″, buffer);
var digest = hmac.digest(encoding=”base64”);
return digest == swtSignature;

var theToken = “”;
var theData = querystring.parse(theToken, sep=’&’, eq=’=’);
var theKey = “Bn7TfLML5wK+R5TAa2VrO/9JANwuk3lzt/ykc4no+h0=”;

util.puts(ValidateToken(theData.wrap_access_token, theKey));

Leave a comment

REST Presentation at Chicago Software Development Community in Oakbrook

Thanks again to everyone who showed up for my presentation on REST at the Microsoft Store in Oakbrook. I’ve posted the slides and demos here. It was a great time. I’ve never presented in a store, never had a component of the “audience” that was just shopping either. It was an interesting, unique experience to say the least! I also enjoyed the conversations afterwards.

Leave a comment

My Windows Azure Caching Service talk from DevConnections

I just presented my Windows Azure Caching Service talk. Thanks to everyone who attended. The audience was small, but I love that you all asked so many great questions. Here are the slides and demos from the talk. I’ll be giving this talk again at the Midwest Cloud Computing User Group in the Chicago area on November 15. You can register for it at

The slides and demos from the content at DevConnections is here.

Leave a comment

Talk and demos from CNUG, AppFabric Talk

Last night I had a chance to speak about Windows Azure AppFabric at the Chicago .NET Users’ Group. Thanks to everyone who came out! I had a great time. A few of you really wanted the slides ASAP. I’ve cleaned out my keys and namespaces from the demos, so they don’t run at the moment (but they will build!). You can get them here:

You’ll need to install a few things and create a few accounts if you want to run any of the demos:


1. Getting started links for Windows Azure:

2. Windows Azure AppFabric SDK 1.0: (for production AppFabric)

3. Windows Azure AppFabric SDK 2.0: (for the CTP bits: queues, topics, etc.)

4. More training on Windows Azure: (10 day free trial– totally worth it, but I am an instructor there too;) )

Leave a comment

AppFabricLabs and the ServiceBus

This week, the Windows Azure AppFabricLabs was updated. The major updates are that the Service Bus labs environment now uses v2 of the Access Control Service and topics/queues have been created. This pushes the number of queueing solutions on Azure to 3:

* Queue Storage

* Message Buffer

* Queues

The main difference between the types of storage relates to size and usage patterns. Queue storage allows for messages up to 8 KB in size and is primarily intended for applications running on Azure. The service only accepts one type of credentials, and you probably don’t want to share those.

The Message Buffer stores messages of up to 60KB for about a minute. It is great for volatile queues as a short lived rendezvous point for exchanging messages. This service lives on the Service Bus and allows for authentication with the Access Control Service.

The Queues implementation in the Service Bus allows for larger messages (up to 256 KB) which can last for a longer period of time. Interacting with the queue feature is pretty simple. Go to the page and allocate a Service Bus namespace. The ‘Hello, World’ for the queue looks like this:

static void Main(string[] args)
  var sbNamespace = "your namespace";
  var credential = TransportClientCredentialBase.
    CreateSharedSecretCredential("owner", "[your key]");
  var uri = ServiceBusEnvironment.CreateServiceUri("https", sbNamespace, 
  var client = new ServiceBusNamespaceClient(uri, credential);
  var messagingFactory =
    sbNamespace, string.Empty), credential);
  var queue = client.CreateQueue("demo");
  var queueClient = messagingFactory.CreateQueueClient(queue);
  var sender = queueClient.CreateSender();
  var receiver = queueClient.CreateReceiver();
  var message = receiver.Receive();

Leave a comment

Integrating with the Camera in WP7

There has been a small white lie that many people tell when looking at whether or not a WP7 application can directly interact with the camera. The fib looks like this:

You can only access the camera through the CaptureCameraTask. Direct access is not allowed.

It didn’t seem right when I heard that, so I did some digging around, looking for ways to find out what is really contained in the phone. Some information is out there, and if you assemble the parts, you wind up with a better view into what managed code can do on the phone. I wrote a post earlier that showed what you need to do in order to make your development environment work better. As a result of that effort, you are going to be able to use the camera in your Windows Phone 7 applications today.

Adding live support for a phone is actually pretty easy. You just need to add some references to the right assemblies, add a little markup to your page, and then write a few lines of code.


Go ahead and create a WP7 XAML app. Once you do that, you need to add references to two assemblies that aren’t standard issue:

* Microsoft.Phone.InteropServices

* Microsoft.Phone.Media.Extended

Why two assemblies? The first one allows you to work with the second one-nothing more.

Add some markup to display the camera

To work with the camera, live, here is what you do:

1. Add a reference to the Microsoft.Phone.Media.Extended to the page you want to display the camera output to. For example, add the following to the PhoneApplicationPage element:


2. With that in place, you can then put a CameraVisualizer on to your page. A CameraVisualizer displays the content of a camera on to a surface.

<media:CameraVisualizer Name="cameraVisualizer" Visibility="Visible" 
    Margin="64,4,99,26" Height="426" Width="593" />

Hook up the Camera to the Page

In your page’s code behind, add a Microsoft.Phone.PhotoCamera and attach it to the CameraVisualizer. You do that by calling SetSource on the visualizer. The code looks like this:



Doing something with the Camera

From there, you can access methods telling you what is going on with the camera:

* ShutterPressed: Fires when someone presses the camera button.

* ImageSavedToDisk: Fires when the image you just took is saved to disk, passing along the path to the file.

* ThumbnailSavedToDisk: Fires when the thumbnail is saved. This one also has the image path.

When the shutter is pressed, you still need to tell the camera to take the picture. To do this, fire the CaptureImage method on the PhotoCamera instance. You can also do some cool things like set the flash setting, zoom level, and auto focus.

There are a few gotchas with the camera that do make it difficult to work with and show why it wasn’t available to all of us when the phone launched. First off, any time you use the control just a little bit ‘incorrectly’, you will see a COM exception. Second, any time that the visualizer goes off screen then back again, you need to detach any events, then hook them back up again or you will have a bad experience for your users. If you do not handle the pictures being taken in quick succession, you will have issues.

I invite you to play with the camera but be warned-it is a nasty beast to work with and you will spend quite a few cycles fixing weird little bugs. Microsoft never made a general release of this code because the code needed more QA before burning any cycles documenting the feature. They’ve already announced it will be in better shape for Mango, but if you want to use it now, I’ve given you enough rope. Have some fun (and don’t hang yourself)!!!

Thanks to Jeff Prosise for encouraging me to talk about this. We were chatting in late April at a conference when I was having some fun with a WP7 camera app I had written and he said he wanted to know how I did that.

Leave a comment