After spending hours learning to play the fake guitar simply to get a higher score, I often wondered why someone couldn’t make a game to learn useful skills. Where’s arithmetic Hero? Going-to-bed-on-time Hero? Microsoft Office Ribbon Hero?

Well, at least the last one finally exists. Microsoft Ribbon Hero lets you learn to use the Microsoft Ribbon and earn points while doing it. They even have Facebook integration so you can compete against your friends and coworkers. (My FB account is here, if you want to challenge me)

The premise of the Ribbon is based on sound UI design (it’s even won awards), but it’s so different than what we were used to. If you’re like me, you’ve figured out where your most commonly used items are on the Ribbon, but haven’t fully explored the other features and often have to hunt for that one option that you use so rarely. Well, let’s take that need for points and apply it to learning something we can actually use in everyday life.

Finally, a game you can play in front of the boss. After all, you’re increasing productivity!

Last week I undertook a completely unscientific study of the .NET Blogosphere (as much as I loathe that term), to determine which namespaces and classes people are most excited about, confused by, or frustrated with – at least to the point that they would dedicate the time to write in their blog about them. My methods for undertaking this study were rather simplistic. I wrote a quick and dirty console application to reflect through the .NET Framework namespaces and classes, and search the internet for mentions of them alongside the terms .NET and blog. For classes whose namespaces contained no periods, the full name of the class was used as the search term. For those classes whose namespaces did contain periods, the namespace and name of the class were used as separate search terms. For example, the class System.IO.File would result in a search for “System.IO File .NET blog”, whereas the class System.String would result in a search for “System.String .NET blog”.

More than to just do a popularity contest of the different classes, I wanted to try to determine the best sources of information for each component of the framework. I wanted to see which sites seemed to consistently beat out others as authoritative sources with complete coverage of a given area. In preparation for the transition to .NET 4, I also was interested to see if the features new to .NET 3, and .NET 3.5 received similar coverage to those classes/namespaces that are used in nearly every project created. This final concern will require further testing and analysis before any conclusions can be reached.

What I did find, however, was that (perhaps unsurprisingly considering the methods) those classes/namespaces which one might use more often round out the top 10 result getters:

I was surprised at how strong of a showing the Microsoft.VisualBasic namespace had among all other contenders. Another interesting study would be to look into those sites that are represented in the result count and find the ratio of C# to VB code contained within.

When looking only at classes, we find the following in the top 10:

From here it looks like features from .NET 2.0 (List<T>) and .NET 3.0 (System.Windows.Window) have gotten enough traction to make a big splash. Generics have had quite a long time to catch on so that’s not surprising. Features from WPF making the top 10 already is surprising (considering how much longer classes have had to be written about), and in this case may simply come as a result of the search term that the application used, which would split off Window from System.Windows.Window as its own term alongside the rest.

The top 10 sources for information about .NET would appear to be the following:

The number next to the name of the site indicates how many classes/namespaces for which the site is the top result. Further investigation shows that this might be inaccurate since dotnet247 seems to just index the entire framework and aggregate information from other sites in an automated fashion. Sounds like a great way to make some money from ads, but it might not be the best information source (though is still fairly genius). MSDN blogs definitely provide some serious coverage of the .NET Framework, and likely have excellent information about those classes/namespaces for which they were the top results.

Another interesting statistic that came out of this entirely informal study is that 29% of the .NET Framework (3.5) has less than 5 articles of coverage on the internet. In fact there are 389 classes or namespaces that would appear to have nothing written about them at all (according to the semi-flawed methodology described above).

You can use the download link below to download the complete results that contain all of the raw data that was analyzed, as well a pivot table, and some charts that can be used to explore it to some extent. What interesting information can you find? Has anyone else done a more formal survey of the same?

I was lurking around the ESB Toolkit forums yesterday, and got involved in an exchange with someone who was hitting the same roadblock to the Itinerary Designer that a lot of people hit: confusion with the model elements and extenders. Upon my first exposure to the Itinerary Designer it took me a week to get over the learning curve of this, and to understand why every send operation seemingly involved two off-ramp shapes instead of one.

Now in the case of that thread, the problem was actually not having a properly formatted SOAP request for the service that was going to be invoked (also a fairly common issue), but getting to the actual issue took cutting through some of the confusing bits of how the itinerary services themselves are implemented, and what they do.

That being said, I took some time last night to write up an article on the different model elements in the itinerary designer, their extenders, and how they can be used to compose an itinerary. You can access the article here: Making Sense of Model Elements and Extenders in the Itinerary Designer

Side note: The article is now part of the brand new (and still under-construction) QuickLearn Technical Library, which will soon contain many more similar articles and links to technical resources for all of the technologies about which QuickLearn teaches.

That’s all for now!

With Microsoft's announcement at PDC this fall and with the continued growth of Amazon's EC2 service and Google's AppEngine service, the industry seems to have people's heads up in the clouds. With this shift of focus, though, comes a myriad of questions about reliability, security, and portability. Potential customers of the cloud want to know that it can indeed be depended on. Executives want to know that the security of data in the cloud will not be compromised. Software engineers want to know that if a certain provider evaporates into thin air, minimal effort will be required to move deployed assets and keep mission critical apps moving.

With so many questions about elastic hosted services, and an as of yet unclear track record for the same, I cannot help but wonder if the cloud computing model will really take hold, or if it will just be a bridge to an even more impressive generation of computing architectures to follow. Maybe it will be both. This discussion then begs the question -- of what that generation will look like that does follow.

Nearly 10 years ago, a program was created that would compel sci-fi geeks, amateur astronomers, scientists, programmers, and scholars to change their screensaver. SETI@home launched in 1999 and over the next 9 years would bring grid computing into the living rooms and dorm rooms of over 5 million people. The original software was an app and screen saver that would use idle computer time to drive the search for extraterrestrial intelligence. It harnessed the untapped power of millions of computers with unrealized potential. It was built as an experiment, to break free of the constraints imposed by a supercomputer. Even hosted clusters have their limits, and some problems go beyond those limits.

With cloud computing the sky is the limit, but what if this world is not enough? What if a single company's data centers won't cut it? What if you want to maintain your data center, while still being able to tap additional resources on demand? What if you wanted to maximize and monetize under-utilized computational resources, instead of just writing them off as depreciating assets each year?

That seemed to be the aim of now defunct CPUShare. It offered users the opportunity to sell their idle CPU time to people who needed computational resources. What if the spirit of this project was matched with the vision of Windows Azure, or the ease of entry of Amazon's EC2. What if it added storage into the mix, RAM, and even bandwidth? What if each of these was currency in a new economy? This new economy would not be comprised of just one company's slice of the cloud; it would be the whole thing.

Crowd sourcing CPU hours might very well be the future, or it may be a pipe dream that will never be possible. It has the same questions of reliability, security, and portability, and it brings with it the question of control. The way the industry deals with the questions about cloud computing today, could very well pave the way for crowd computing to be the driving force behind Web 4.0 and beyond.

It is no secret that Microsoft has been working on bringing its Enterprise offerings up to date, readying them for the next generation of applications and services, and fixing small pain points that have vexed developers for years. In just a short while, BizTalk Server 2006 R2 will make way for BizTalk Server 2009, and another interesting product from Microsoft will realize next version status. That product is Microsoft Enterprise Service Bus (ESB) Guidance 2.0.

What is an Enterprise Service Bus?

Dmitri Ossipov, a Senior Program Manager for Microsoft working on the ESB Guidance, in his interview on .NET Rocks defined ESB as an "architectural paradigm for policy driven mediation." Nicholas Allen, a Program Manager at Microsoft working on BizTalk Server, argues that "the clearest definition of what companies think ESB means comes from looking at the products that they build." In the case Microsoft's ESB offering we see a solid implementation of the Routing Slip pattern built on top of BizTalk Server sprinkled with ample extensibility points. In the world of the ESB Guidance Routing Slips are called Itineraries, and act like an order placed at a menu of services that is the bus. The ESB Guidance provides flexibility through a loosely coupled design that allows routing and transformation decisions to be made at runtime instead of having to be statically configured at design-time. This enables service composition, dynamic transformation, and adds support for scenarios previously unimaginable in a BizTalk Server environment.

Version 1.0 of the Guidance was a paradigm shift for many BizTalk and .NET developers, but version 2 has the potential to take it to the next level. It introduces some killer new features such as the Itinerary Designer that can reduce XML induced eye-strain, Generic On-Ramps that allow you to send a message into the bus on the consumer's terms, and support for Server-side Itineraries that can place ESB developers back in control of the content of their Itineraries.

Itinerary Designer

Someone once said, "XML is like violence, if it doesn't solve your problem, you're not using enough of it." I'm not going to debate the truth of this one way or another, but I do find it interesting that XML is compared to something that causes such a universal adverse reaction. When color-coded, perfectly indented, and collapsible, I can handle XML. However, at that point I have already resorted to looking at a more human friendly representation of the data instead of the raw data itself.

Those who have downloaded the January CTP of the Guidance, have found themselves in the midst of peace – no XML to be seen (don't worry it's still there if you dig). The January CTP now includes a Visual Studio designer for Itinerary models. Creating Itineraries is now as simple as dragging On-Ramps, Itinerary Services and Off-Ramps into a visual model that can be exported to a repository, or as XML – even mere mortals can do it.

Server-Side Itineraries

Yes, I just said the word repository. Version 1.0 of the guidance was awesome, but it did leave developers with a puzzle: "How do I get the itinerary I need to route this message, and how do I get it to the server?" The answer of course was that you have the XML of the itinerary that you send within the header of the message when submitted to the Itinerary Processing web service.

But where do you get the XML from? How do you know it's valid? Well, with CTP2, you know an itinerary is valid because it was modeled in a designer that validated it before each save and export. With CTP2 the XML can be retrieved from a SQL database (which bears a striking resemblance to the rules set database in BizTalk Server), and applied to the message in a pipeline component.

BizTalk and WCF enthusiast Bram Veldhoen remarked on his blog that it would "be a good idea to have the ESB be responsible for assigning the Itinerary headers." Microsoft apparently agreed, and this is exactly what should be expected from this new version of the ESB Guidance.

New Resolvers

The latest ESB 2.0 CTP adds three new resolvers for resolving itineraries: BRI, ITINERARY, and ITINERARY-STATIC. This means that not only can consumers rely on the ESB to apply itineraries for them; the ESB can do it dynamically. For the ESB Guidance uninitiated, Resolvers are these wonderful classes within the ESB Guidance that can take a configuration string, parse it and execute a query of some sort to look up information necessary for transformation, routing, or some other custom process.

The first is the BRI resolver; a typical resolver connection string would look like this:
BRI:\\policy=SamplePolicy;version=1.1;useMsg=True;

This string, when interpreted by the BRI resolver (the BRE moniker was already taken for a resolver that cannot retrieve itineraries from the repository), will tell the resolver to use the Business Rules policy named SamplePolicy to determine the Itinerary to use for routing. It will also include the message as a fact when calling the Rules.

The second is the ITINERARY resolver; a typical resolver connection string would look like this:
ITINERARY:\\name=Zebra;version=1.0;

This is a static choice of an itinerary named Zebra. Its sister resolver ITINERARY-STATIC does exactly the same thing but is implemented using the Unity Application Block, but that's a discussion to save for another posting.

You would use such resolver connection strings in the configuration of the ESB Itinerary Selector pipeline component, which is part of the ItinerarySelect* family of receive pipelines included with the ESB Guidance 2.0 CTP. Since this is all part of a pipeline, that means that in 2.0, you can create Itinerary On-Ramps that are first class citizens in the ESB which use transports other than an ASMX web service or WCF web service. The possibilities are limited only to the adapters installed.

Getting it Right

The new version of the ESB Guidance brings new features, enhancements, and fixes that really make it feel like a polished product. With version 1 they got it shipped, but with version 2 they're getting it right.