Main Contents
November 30, 2009
I just heard the news announced at PDC that the Managed Extensibility Framework, or MEF, is now slated to be included in Silverlight 4. Great news!
I did a bit of proof of concept work using MEF about a year ago. MEF is all about composition of providers and consumers. MEF’s main job is to connect the providers to the consumers so that when the consumer code executes, the providers they require are “just there.”
As trivial as that sounds, it significantly changes how you think about programming. It forces you to think in terms of composition instead of in terms of plumbing and bushwhacking. As a result, you can focus more energy on solving your actual problem instead of spending the majority of your time building the plumbing and scaffolding so that you can get to the point where you can begin to solve your problem.
For example, if you’re writing some code and you require “X” to get your work done, you write your MEF code module to declare your need for “X”. When your module is loaded by MEF, MEF will take care of the dirty details of finding a provider to fill your need for “X”. The provider may be the one you had in mind when you wrote the code, or it may be completely different, but as long as it implements “X” faithfully, you don’t really care. The application defines the list of providers to choose from - whether a fixed list determined at build time or a list gathered at runtime - the point is, you and your code don’t need to deal with the how, just declare the what and keep going.
MEF alters your coding thought process from
“I need to figure out how to load and connect to something to get the X that I need”
to
“I need X. I can rely on X being here when my code executes. If for whatever reason X isn’t available, my code won’t be loaded so I don’t have to mess with all that.”
This change in thought process is similar to the shift that can and should occur when you go from writing traditional fire-brigade error handling code to writing code in an exception handling environment. For most of the code in your app (the middle layers), you can operate under the mantra of “If execution gets this far, then everything prior to this must have succeeded. If anything back there failed, it would have thrown an exception so I wouldn’t be here now.”
I’ll see if I can get clearance to blog about my little MEF experiment from awhile ago.
Tags: .NET, exceptions, MEF, Microsoft, Silverlight
Filed under: Programming, Work |
Comments (0)
November 24, 2009
Mike Wickstrand of the Windows Azure team has created a Windows Azure Feedback Forum to solicit feedback from you about what sorts of things/features/services you would like to see Windows Azure provide. You can enter your own suggestions and vote for the features that you want the most. This feedback will go directly to the Windows Azure product planning team to help them determine where we should be focusing our energies next.
Check it out!
Tags: Azure, cloud, feedback, Microsoft
Filed under: Work |
Comments (1)
November 17, 2009
Windows Azure, Microsoft’s platform for cloud-based applications, just rolled out a major update to sync with PDC09. We of course also rolled out a major update of the Windows Azure Tools for Visual Studio in the same push. Jim Nakashima and others will be showing our latest tools at PDC09 this week.
Windows Azure Tools also received coverage on Soma’s blog - woot! Soma is Senior Vice President, Developer Division, and my nth degree boss’s boss.
While Jim is out working hard at PDC, back at the ranch we’re taking advantage of the calm following the PDC prep and product release storm to get a head start on the next round of features for Windows Azure Tools.
Tags: Azure, cloud, cloud tools, Microsoft, PDC, Visual Studio
Filed under: Work |
Comments (0)
October 20, 2009
One of the great things about using VirtualPC in software development and testing is that the VirtualPC “virtual machine” really only has one hardware configuration. The virtual machine defines a virtual hard disk, virtual display, virtual network, and even its own virtual BIOS for booting up the virtual machine.
The downside to that uniformity is that the VM can’t access any kind of hardware on your real PC that is beyond what VirtualPC already knows about. Sure, you can install device drivers in the VM, but those device drivers won’t be able to find their hardware because it doesn’t exist in the virtual machine.
For example, how do you plug a USB flash drive into your virtual machine? Or how do you use your SmartCard reader to perform a secure login from your virtual machine? You can’t. At least, not using the VirtualPC terminal.
I stumbled into this sand trap when I was setting up a new VM and needed to pull source files from version control onto the VM. The version control server (TFS) is on the private corporate network, but I’m not. I normally access corpnet via a Virtual Private Network (VPN), which requires use of a SecureCard (encryption keys stored on your corporate photo ID badge) to log in.
One solution would be to pull the sources to my local hard disk across the VPN, then share those files using a network share so that the VM can see them. That would work if the VM only needed read-only access to the files, but since I would also be making changes to the source files inside the VM and from my local machine at the same time (multiple irons in the fire), sharing one copy of the source code wouldn’t work.
I could copy the source tree from the local drive into the VM’s local drive, but that just makes it harder to check in changes made to the files in the VM.
The ideal would be to configure the VM to connect to corpnet via VPN and pull the sources directly from version control. Changes made to the sources in the VM could be checked in and managed independently of the source files on my local machine. But the VPN client requires access to the SmartCard reader to complete the VPN login, and the VM doesn’t have access to the SmartCard reader hardware.
Or does it? Turns out, there is a way to do it. Instead of using the VirtualPC terminal, use Remote Desktop to connect to the virtual machine.
Remote Desktop’s terminal window supports transporting certain kinds of device information from your local machine to the remote machine. This allows you to print from an app on the remote machine and have it print on your local printer, for example, or access files on a USB drive plugged into the local machine. The Remote Desktop client also supports sharing SmartCard reader access across the Remote Desktop connection.
Here’s how to set it up:
First you need to configure your VM to accept Remote Desktop connections. Fire up the VM in the VirtualPC terminal, click on Start in the Windows task bar, right-click on My Computer, click on Advanced System Settings, and select the Remote tab. Under Remote Desktop, select one of the two Allow settings depending on your needs, then click on Select Users and use the next dialog to add user accounts that can access that machine remotely. Accounts with administrator privileges automatically have remote access once Remote Desktop access is allowed.
Make sure your virtual machine is set up for network access. If the VM isn’t on the network, you can’t connect to it with Remote Desktop. If you can open a browser in your VM and browse web sites, you’re good to go.
Make sure your virtual machine has a computer name. You’ll be connecting to it by name (IP address also works, but less friendly), so make sure you know what its name is. You can find (and change) the computer name on the My Computer properties page. Make sure it is different from your local computer name.
Minimize the VirtualPC terminal window on your local desktop. Launch Remote Desktop and type in the virtual machine’s computer name. Click on Options to configure Remote Desktop.
Local device sharing is turned off by default in Remote Desktop. Click on the Local Resources tab, then on the More button near the bottom of the dialog:
This will bring up the Local Devices and Resources selection dialog where you can select which local drives and devices to make available to the remote machine:
Check the Smart Cards checkbox to enable sharing your local SmartCard reader with the remote machine, then close the dialogs and click Connect on the original Remote Desktop dialog.
You should be prompted to log into the remote machine (log in with a user name and password on the virtual machine, not the local machine) and voila - you’re looking at your virtual machine through Remote Desktop’s eyes!
From here I can fire up my VPN client, connect the VM to corpnet using the SmartCard reader, and access the TFS server to manage source files in the VM directly.
Remote Desktop can share local printers, local disk drives and drive letter mapped network shares, serial ports, and SecureCard readers to the remote machine. It can also share some types of Plug N Play media devices such as digital cameras (to access image files on the camera via USB perhaps). USB devices that don’t behave as a file device or as a printer probably won’t be shareable across the Remote Desktop connection. A USB webcam, for example, cannot be shared across a Remote Desktop connection.
Remote Desktop is by far my preferred client for working with VirtualPC VMs. RD’s mouse, keyboard, and clipboard integration between the remote and local desktop is more seamless than the VirtualPC terminal and RD just feels snappier overall.
Tags: remote access, Remote Desktop, SmartCard, virtual machine, VirtualPC, VPN
Filed under: Work |
Comments (0)
October 19, 2009
Microsoft announced today the release of Visual Studio 2010 beta 2 and .NET Framework 4 beta 2! It will be available immediately for download by MSDN subscribers and for general release towards the end of this month.
I can’t begin to describe all the stuff that is new and improved in this beta 2, so check out the official site for all the details.
Note that MSDN gets a major facelift as part of this rollout as well.
Tags: .NET Framework, beta, Microsoft, MSDN, release, Visual Studio
Filed under: Work |
Comments (0)
October 14, 2009
Thawte has announced it will discontinue its “Web of Trust” peer to peer identity assertion program later this year.
Web Of Trust enables individuals to obtain personal digital certificates without having to go through costly corporate or government paperwork. The idea is that if several trusted WoT members (notaries) assert that they have met the person and verified their government issued identity documents (passport, drivers license) match their WoT identity claims, then the person is probably legitimate and can be issued a trusted WoT digital certificate containing their actual name and email address. The main purpose of WoT is to enable people to create trustworthy online identities by eliminating fake accounts (”sock puppets”) and impersonators.
WoT personal digital certificates can be used to to cryptographically sign or encrypt email text using S/MIME standards. Encrypted emails cannot be read except by the person the message is addressed to. Cryptographically signed emails are sent as clear text, but the recipients can verify that the message was sent by you and has not been modified in transit.
I joined WebOfTrust at its inception in the summer of 1999. My WoT identity was essentially signed by ‘root’ - I met with a vice president of Thawte in San Francisco to verify my documents and chat briefly about the program. Thawte is based in South Africa (acquired by Verisign in 2000) and sent a small team on a coast to coast tour of the US to seed the WoT trust system with notaries. As I recall, San Francisco was also the first city in that tour. WoT notaries make identity assertions to help others achieve trusted status with very little involvement (or expense) to Thawte. You need trust assertions from at least 3 WoT notaries to achieve trusted status.
As a WoT notary, I’ve made quite a few identity assertions for folks in the Santa Cruz area over the years. Nothing particularly interesting to report there. What is interesting is the number of folks who would contact me to request a WoT identity assertion, but then vaporize as soon as they found out that they had to present photo id and meet me in person.
I guess I’m just continually amazed at how many people have enough interest and motivation to request that their identity be validated, but then back out because a) they don’t want to use their real name or b) they don’t have government issued photo ID documentation for the identity they’re trying to create.
It’s a shame to see WoT go. I started using WoT certificates to sign all my personal and business mail after learning folks were receiving email with my return address that I didn’t write. Signed mail was a nice techorati touch, even if most of the folks I corresponded with didn’t know what that S/MIME attachment was for. It was also a bit viral - folks would ask me about the attachment, I’d explain digital signatures, and they’d get interested enough to get their own certs and join the fray. Once someone had sent you a signed email, you could store their public key and use it to send them encrypted email. I’ve never sent anything through email that required encryption, but it’s fun to encrypt a few now and then just for fun. Stick it to the man, so to speak.
My use of signed email came to an abrupt end when I found GMail. I loved the gmail feature set, “net nomad” availability, and spam abatement, but gmail did not (and still does not) support cryptographically signing outgoing emails with digital certificates. To a degree, I understand why this has never been a priority for gmail - in order for gmail, running on the web server, to sign your outgoing mail, the private key of your digital certificate would need to be stored on the web server. That’s a security risk - or at least, more opportunity for risk than storing the cert on a local hard disk. But I also feel that excuse is a cop-out. It can be dealt with, but GMail never tried.
Personal digital certificates are handy in another way: If you’re working on code to handle X509 certificate chains (as I have been lately - more on that eventually), it’s always nice to have a few valid X509 certificates to test with. Sure, you can create fake self-signed certs with makecert, but fake certs don’t exercise all the code paths and don’t work on other machines. WoT personal digital certificates are a quick and easy way to get an X509 certificate that is signed by a real root CA that is recognized by every modern Windows system. As an extra bonus for code testing, WoT certificate chains have a depth of three: leaf, intermediate CA, and root CA.
Alas, WoT is no more. So long Web Of Trust. It’s been a great run.
Tags: cryptography, encryption, GMail, smime, thawte, verisign, weboftrust, x509
Filed under: Web |
Comments (1)
October 2, 2009
Dion Almer and Ben Galbraith, cofounders of the Ajaxian web development news portal, have left their digs at Mozilla to head up the developer relations team for Palm’s webOS. Dion and Ben moved to Mozilla just short of a year ago to work on Bespin, a project to develop tools for building cloud applications.
Tags: Ajaxian, Bespin, Mozilla, Palm
Filed under: Web |
Comments (0)
October 2, 2009
When you’re writing a rich Internet application (RIA) in HTML and JavaScript, sometimes you need to programatically place a DOM element relative to the right or bottom edge of the visible browser window. For example, if you want to popup a help balloon near an item of interest, you probably want to make sure that the balloon is fully visible on the screen - not hanging off the edge of the screen, partially obscured. I haven’t found a CSS way to accomplish that, but here are some tidbits I have found:
A quick web search on calculating browser window height reveals that different browsers have different ways to find the browser’s window client height. In Netscape / Mozilla browsers, you can use window.innerHeight. For IE, some sources suggest using document.body.offsetHeight, but I’ve found this falls short when the HTML content does not completely fill the browser window. document.documentElement.clientHeight returns the actual window client height in IE.
The jQuery JavaScript library has some handy functions for calculating an element’s pixel location and pixel width and height, with or without consideration for borders, padding and margin. $(”.myclass”).outerHeight() will give you the pixel height of the first element with a CSS class of “myclass”, including borders and margins.
$(”body”).outerHeight() returns the same value as document.body.offsetHeight, which will be less than the window height in a short HTML document and could be much larger than client height in a scrolling window.
Tags: HTML, JavaScript, Programming, RIA, web app
Filed under: Programming, Web |
Comments (0)
June 29, 2009
If software programming logic and statements were viewed as literature, what form of literature would yours be?
- Novel: multiple independent story lines that you hope will eventually converge to make a point.
- Short story: a limited number of characters with only one point to make
- Essay: tell ‘em what you’re going to say, say it, then tell ‘em what you said
- Tragedy: everything that can go wrong usually does
- Sonnet: ornately crafted for no particular reason
- Ode: behold my skillz, and despair!
- Thriller: I’ve got a bad feeling about this…
- Murder Mystery: when things go wrong, top priority is on placing blame
- Self-Help: You can do it! Please do.
- Epic Saga: “Help! I can’t stop writing!”
- Technical Documentation: Useful bits hidden in a sea of jargon, surrounded by a narcoleptic field
- Government Bulletin: Technical docs sans useful bits
- Billboard: all flash, no substance
Since I come from the school of “simple elegance”, I’d have to say that my ideal software’s literary equivalent would be
Comedy: If you have to explain it, it’s not very good.
Tags: humor, literature, Programming, software
Filed under: Glimpses, Programming |
Comments (0)
April 15, 2009
Have you ever run into a situation where you need to bridge between code that uses the old custom EventHandler pattern for events and code that wants to use the new parameterized EventHandler<> code style? EventHandler style delegates are not assignment compatible with EventHandler<> delegates. You’ll run into this if you’re writing a new API that sits on top of older code. You probably want to expose events in your new API using the newer EventHandler<> pattern, but you can’t easily wire up events from the old lower level code to fire events in your new API.
You could create an event handler method to catch each of the old style events fired by the old code and turn around and fire the corresponding new style event in your API, but who wants to write all that mind numbingly repetitive code?
There is a simpler way. The two incompatible event patterns do have one thing in common: the Invoke method.
But first, some background.
Custom EventHandler Types, 1.0 Style
In .NET 1.0 the pattern to define an event property was to define an EventArgs class to carry the arguments of your event and define an EventHandler delegate type which uses that EventArgs class as its args parameter. Like this:
public class ActivityCompletedEventArgs : EventArgs
{
public ActivityCompletedEventArgs(int resultCode, string result)
{
ResultCode = resultCode;
Result = result;
}
public int ResultCode { get; private set; }
public string Result { get; private set; }
}
public delegate void ActivityCompletedEventHandler(object sender,
ActivityCompletedEventArgs e);
class Bar
{
public event ActivityCompletedEventHandler Completed;
}
Generic EventHandler<> Types, 2.0 Style
With the advent of generic types in .NET 2.0, the generic EventHandler<> parameterized type was born. This parameterized EventHandler<> delegate type simplifies how you declare and use event handlers - you don’t have to declare a custom event handler delegate type to match your event args class every time you create a new kind of event. This is exactly the kind of thing that parameterized types (aka generics) were created to solve. Like this:
public class ActivityCompletedEventArgs : EventArgs
{
public ActivityCompletedEventArgs(int resultCode, string result)
{
ResultCode = resultCode;
Result = result;
}
public int ResultCode { get; private set; }
public string Result { get; private set; }
}
class Bar
{
public event EventHandler<ActivityCompletedEventArgs> Completed;
}
However, the downside is that EventHandler<> delegates are not assignment compatible with the old style non-generic EventHandler style delegates.
The Invoke Bridge
Both styles of event delegate have an Invoke method with a signature of (Object sender, EventArgs args), where EventArgs is the arguments class specific to this particular event. You can use this point of commonality to convert between event styles without too much trouble. The trick is to use the .Invoke method in one style of event as the callback method registered in the other style of event:
class OldStyleClass
{
public event ActivityCompletedEventHandler OldStyleEvent;
}
class NewStyleClass
{
public event EventHandler<ActivityCompletedEventArgs> Completed;
public void blah()
{
var obj = new OldStyleClass();
obj.OldStyleEvent += new ActivityCompletedEventHandler(Completed.Invoke);
}
}
The code above hooks up the events so that when OldStyleClass.OldStyleEvent fires, it will fire the NewStyleClass.Completed event.
The main catch to this technique (in C#) is that the reference to the event’s .Invoke method must be made from within the context of the class that defines the event. C# doesn’t allow access to the members of an event delegate outside of the class that defines the event. The rules may be different in other .NET languages.
If you want to use this technique in the opposite direction (to have a new style event fire an old style event), you will need to be able to modify the source code of the old style class that defines the old style event. This is much less common than making old style code to fire new style events.
Tags: .NET, C#, EventHandler, generics, Programming, tricks
Filed under: Programming |
Comments (0)