With the sudden proliferation of cloud-based services it no longer seems like much of a novelty to have an elastic infrastructure capable of on-demand scaling provisioning of virtual resources. Instead it has become something almost taken for granted, and it may even be expected that this can be easily provided given enough on-premise machines. New terms, however misleading, have even been coined to describe such an internal elastic architecture, and software custom tailored to the challenge has already been developed many times over, with even more offerings still in development.

However, working in technology education layers an additional set of requirements on this common expectation. Customers themselves must be able to trigger the provisioning of virtual resources, and access them directly from out in the wild wild web. What I am describing, albeit rather cryptically, are Virtual Labs.

The concept of a Virtual Lab is that a student can access a web page, and after a short period of boot-up time, be connected directly into a virtual machine that is set up and ready to provide a hands-on learning experience. These activities are typically limited in duration and do not provide persistence of a student’s work between sessions. This is less than ideal for typical classroom learning where a student will be using a single machine all week, but makes perfect sense for self-paced learning offerings wherein the student may spend many weeks working through the same material and computing resources cannot be tied up for the entire duration.

Right now QuickLearn is working to deliver some of its core .NET, SharePoint 2010 and BizTalk Server 2010 training offerings in a self-paced format. As part of this effort, it was decided that the lab activities for these new courses should be provided as Virtual Labs available from anywhere and on any device or platform containing a capable RDP client. An additional requirement was that we must be able to use existing VHD files for the classes, without having to rebuild anything or re-install software.

After existing solutions were evaluated (including Microsoft’s Virtual Machine Manager Self-Service Portal), it was decided that the solution should be built internally. Development was completed at the beginning of this week, and the resulting experience was even better than I had initially imagined.

(click for a larger view)

The solution ended up ultimately consisting of four separate components. The first was QuickLearn’s online player application. This provides the interface through which a student can initiate a Virtual Lab. Once the student decides to begin a virtual lab, a request is sent to a Virtual Lab Service. The Virtual Lab Service is a WCF service that is responsible for managing a pool of Hyper-V servers, and routing control messages to start / stop virtual machines. It is also responsible for providing the client with updates about the status of their request. Once the Virtual Lab Service receives the request, WMI is used to spin-up the requested instance (from a known save state). Within each instance, an application is running that will call back to the Virtual Lab Service when it realizes that the machine is back online. Once the Virtual Lab Service knows that the machine is online, it provides the client with connection details for accessing the Virtual Machine. Throughout all of this there is a processing loop that ensures VMs are properly destroyed whenever the time allocated for a given lab has expired.

Since RDP is being used for connectivity, the student can be offered an embedded connection within their browser (given that they are using Internet Explorer). If their browser will not support an embedded connection, they are provided connection details and instructions to connect directly to the image. One really interesting implication of this is that students running Windows 7 will be able to access newer Virtual Labs with true multi-monitor support.

The implications of using Hyper-V on the back-end is that we are able to share machines with up to three students and still provide a killer experience with multiple cores and up to 4GB of RAM per instance.

Overall, the development was more or less straight-forward, only requiring ~30 human-hours of time, and the reward for students will be incredible.

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.