Lex Parsimonae

Well? Did you??

I'm a big fan of RSS feeds -- this isn't news. Google Reader, however, just might be news to you, and if it is, you owe yourself a look. It's reminiscent in design to GMail and other excellent Google web apps (expected). It's not perfect (details in a bit), but it's got a couple really nice redeeming features. I think I'm hooked.
The first time I saw Google Reader, I wasn't all that knocked out. First of all, it's not quite as nice to use as a dedicated windows-based RSS reader. The bar has always been set for me by apps like RSS Bandit, which work well because they're purpose-driven, and Windows-based. This is the same reason Outlook is better than traditional web-based mail readers.

As you probably know, web-based email readers are getting better and better, and I'd say they're starting to give Outlook a run for its money (think Yahoo, GMail, and others). Similarly, the Google Reader interface is pretty nice when it works.

Yes, I've had some problems with it working. Fortunately, the problems seem to be platform-related. Reader doesn't seem to paint quite right in IE7, and in Opera, my mouse's scroll wheel moves down no matter which way I scroll the wheel. Not the end of the world, but if you're going to use an application a lot, these types of issues will drive you slightly batty. Good news, though, for Firefox users. Reader seems to work perfectly on this open browser.

Enough on the warts, though. Where Google Reader really shines is when you start using it from multiple computers. Unlike a Windows-based reader, since Google Reader is server-based, it's going to keep track of what you've read on the server. No more re-reading news from one PC to the next. To be fair, some Windows readers like RSS Bandit support mechanisms to synch read lists to a server, but I never had any luck getting that to work. Google Reader works without you having to think about it.

But the real killer feature is sharing. When you're reading news, you have a one-click sharing button that instantly adds whatever article you're reading to a "share" list that's maintained just for you. Here's mine. Now you can watch this meta-feed (it supports RSS, too!) and see what articles I'm reading that I think are worthwhile for others to read, too.

Waaaayyyy cool!

Fast Company has a great article about the team that builds the real-time mission control software that runs Space Shuttle flights. The team, the mission, and the statistics are all over the top; as the article points out, very few software projects carry the dreams of a nation when they run. There are lesson here for the rest of us, and this software team would have us understand that improvement is more about the process than the technology. To be fair, the software we write every day isn't (ahem) rocket science in the same way that Shuttle software needs to be, and we don't have some of the advantages that this team has:

• A large staff. This team is comprised of 260 men and women.
• Mature code base. This software has been in development for over 20 years. As long as people have been paying attention, there are a lot of lessons that should have been learned by now.
• Stable work force. Many of these engineers have been in place for a good portion of the Shuttle's life cycle.
• Best of the best. Let's face it - few of us can compete with the prestige of working on the Shuttle program

Nevertheless, there are some ideas in here we should consider carefully in terms of how and where they apply to our work. The two themes that keep popping up in this article are process and culture.

The process in this group is tightly-controllled, double-checked, documented, reviewed, and revised. These guys understand implicitly what it means to go off-script, and they don't let it happen often. I've always championed the use of the right amount of process for the job, and in this case, the job calls for planting a handful of astronauts on the top of a large, pointy bomb, lighting the bomb in such a fashion that it squirts into the upper reaches of the atmosphere at a speed approaching 20,000 mph, and then landing the astronauts back to earth aboard the spent bomb. This takes a sophisticated process: there's no service pack in space.

The culture is also striking. Unlike the go-go silicon valley "cowboy" coders, these developers are methodical, measured, and deliberate. They work regular hours and have lives outside work. In a word, they're boring. This, as it turns out, is comforting to the astronauts, who would much rather get their thrills from the great views in space than from "excitement" in their mission control software. This team understands that the mission is the important thing, and the software exists only to support the mission.

Think about your development shop a bit, and then read They Write the Right Stuff.

Abour two years ago, I built a new home PC for myself. I got a nice Antec Sonata case, and a MB with variable-speed fans to cut down on noise. When I put everything together, I was very happy with the sound level except for the stock Intel CPU fan, which idled quietly, but sounded like a vacuum cleaner when it kicked into high speed. I decided to upgrade the heat sink and fan, and decided on an Arctic 7 Cooler, which ran very quietly until the last few weeks.
I started to notice my PC getting noisier and noiser, and when I popped the side off, I could tell that the noise was coming from the fan on the Arctic Cooler. I just got done fixing it, though, so if you've got a noisy Arctic 7 Cooler, don't throw it out -- try some machine oil.

(BTW, in browsing for a picture of the Arctic 7, it looks like they've upgraded the fan in the mean time, so the problem and the fix here very likely only apply to the older units)

First, you'll most likely have to remove the heatsink in order to oil the fan. Next, look for a little plastic plug on the back of the fan assembly (see picture). Pop this off with a knife. Next, just send a few drops of 3-in-1 or similar machine oil down the hole and spin the fan a bit to work it in. That's it! Reassemble everything (you may want to freshen the heatsink compound if you overclock your CPU), and you should be good to go.

Here's a great resource if you're learning VB.Net from a C# background, or vice versa. Frank McCown's VB.Net and C# Comparison page does a really good job of covering the most important differences between C# and VB.Net. I've been using it to do some C# work recently, and it's a real time saver. BTW, this link is also available in our .Net links area, and it also looks like Frank's got a C# to Java comparison page.

I'm convinced yet again that Microsoft's licensing weenies will be the first against the wall when the revolution comes. I just read an article by Paul Thurrott that describes licensing changes for Windows Vista, and it's really, really disappointing to me. In short, Microsoft is cranking down licensing terms to specifically restrict which versions of Vista will be "legal" to run in a VM.
In his article, Paul carefully explains that the Vista licensing terms aren't all that different in effect than XP's, and that the VM restrictions exist because VM users are "fringe" use cases. This is, in my opinion, short-sighted at best, and destructive at worst.

History Revisited

Rewind five years to the release of Windows XP. Virtualization was, at that point, a toy technology. A reasonably computer-savvy person could imagine the potential that virtualization might eventually yield, but the benefits were clearly over the horizon. There was no such thing as dual-core, let alone quad-core, and the idea of CPU's with virtualization accelerators built into them was inconceivable to the average technologist.

Windows XP's licensing terms were, therefore legitimately onerous to computer enthusiasts who changed PC components frequently and faced the headache of repeated product activations, but there we really no virtualization customers against whom Microsoft could discriminate. Bottom line: Microsoft was about as abusive as they thought they could get away with towards the users they knew about at the time.

Back to today. Now, Vista's licensing terms remain similarly invasive for "regular" users, but now, Microsoft's also targeting VM users. Paul points out that most VM users are either professionals or enthusiasts, implying that this is why only the "Pro" and "Ultimate" versions are licensed for use in a VM. If you want to run Vista Home Basic or Home Ultimate, you're out of luck. Can't go there.

This is ludacris from so many angles, it's hard to know where to start railing, but I'll give it a shot.

Special Users

"Currently, the majority of Microsoft's virtualization users fall into exactly two groups: business customers and enthusiasts," says Paul.

Ok -- I'll buy that, subject to one caveat -- "currently". If we've learned anything about virtualization over the last five years, it's that it's here to stay, and, in fact, its use is going to grow. Where do you think we'll be on the adoption curve in another five years?

Next problem: just because your VM users are professionals and enthusiasts, that doesn't tell you squat about the OS's they want to run. In fact, I'd bet that these groups are more likely than other groups to *want* other versions of Vista. The two biggest reasons for VM adoption today are operational management of production servers and testing. Production servers aren't generally going to use desktop Vista, so I'll leave them for another day. Let's talk about testing.

The use of VM's for testing has a number of benefits. One of them is that you can set up a VM for a specific customer configuration. Another is that you can replicate combinations of hardware and software that exhibit "interesting" traits with respect to the software you're testing. Finally, using VM's let you power-on machines when you need them and power them off when you don't, and in the time behind runs, they take up zero extra space in your test lab / office, and they consume zero additional electricity.

This implies that you need to run whatever edition of Vista your customers are running. If you build an application that supposedly runs on Vista Home Basic, you should be expected to test on it. If you're a software developer, that means no VM for you!

If you use a VM's to support custom installs or configurations for your customers, you probably have VM's for each customer, and most of them are probably turned on only when you're chasing a customer support problem. That's a lot of Windows licenses sitting idle most of the time.

What's so Hard?

Now that we know that virtualization is here to stay, why in the world can't we look it in the eye and deal with it? What, exactly, is Microsoft trying to protect itself from by cranking down these licensing terms?

Piracy.

How do you tell the difference between piracy and the legitimate use of VM's for testing, as I described it above?

When you use VM's for testing, most of them aren't on most of the time.

Once more, in small words so the licensing lawyers can get it: Please don't make me pay for an OS that only gets turned on once a year.

Microsoft's got how many gazillion engineers now? I'm pretty sure that Microsoft could divert a couple dozen people off the splash screen team and fix this once and for all. We need concurrent licensing for Microsoft OS's -- especially when run in VM's. It's that simple. VMWare and Virtual PC both have "VM tool" installs they provide for guest OS's to "enhance" operation of the guests. Use these to hook into a licensing service provided at the host level, and (for bonus points) make it networked. VM's don't chew up a license when they're not on.

So, Microsoft, go find the guys who are writing Zune software and put them to work on Vista licensing for VM's. After all, Zune's walking dead.

Other takes

A couple other pundits have words on this subject, too.

Dialogue Box by Chris Pirillo: Vista Will Double Apple’s Market Share

Koroush Ghazi: Windows Vista's Enthusiastic Licensing Restrictions

I'm trying to architect a system for a government department, and we need a few computers. This particular unit is partial to Gateway systems, and I guess he's had some phone conversations with a Gateway rep who was quick to recommend virtualizing at least part of his environment (cool), so I'm happy to spec Gateway systems in this architecture.
As I write the technical specs for this system, I come to the production deployment diagrams, and I've got this diagram that shows all Dell equipment (we started there because we had Dell stencils). Now, it's not the end of the world to have Dell stencils standing in for Gateway equipment, but it dosn't look quite right (and that bugs me). Besides, I figured that Gateway would have an interest in getting pictures of their products plastered all over this spec instead of Dell, so I decided to spend a couple minutes hunting down a new stencil.

This is where it started to get fun.

I searched Google for "Gateway visio stencil", and I found links to Gateway, and a link that would let me buy Visio from Gateway, and even some Cisco stencils that had network gateway equipment, but nothing for a Visio stencil.

Fine, I thought. I'll just go to Gateway's site -- they must have something like this available via search, right. Wrong. But they've got this "chat" link here - maybe that's worth a shot....

So I tried chatting. IE7 launched the window with a little security burp, and then showed what appeared to be a Java applet. But it was grey. I let it sit for a while, and once it was quite apparent that it wasn't going to do anything on its own, I tried to move it. Wait -- what's that?? There's something there -- it just shows up only when I moved or resized the window. It turns out that it wasn't accepting keyboard input either, so that was going to put the hurt on my chat session.

Next browser. Opera. Recent release. I got as far as loading up the chat screen on this one, but it just sat there. No life at all.

Now, in the mean time, I get an email from a Gateway sales rep who noticed that I'd signed on to chat, and I hadn't had much to say. Good for him, and good for Gateway. He asks if I still need help. "Yes," I say, " I need a Visio stencil, because I'm trying to spec some of your servers for a gov't project."

"A gov't project? You're gonna need to call 'major accounts'".

This is where I gave up on Gateway. I've seen "major accounts" groups in action, and I didn't have that kind of time on my hands. So I'm going to use the Dell stencils.

Now, can anyone seriously believe that no Gateway stencils exist anywhere at Gateway? Really??

And if they exist, which I'm quite certain they do, why in the *hell* wouldn't Gateway want to make them easy to get to??

How does any of this make the slightest bit of sense??

If you sell anything through any sort of channel, you're a damned fool if you don't make it easier for your channel to sell your product instead of your competitor's. In this case, I'm acting as an informal channel because I've got a lot of influence over the buying decision. Now, I mentioned earlier that this client is partial to Gateway for some reason, and I'd seen no reason *not* to use Gateway, but if I told him I was more comfortable with another brand, he'd drop Gateway like a hot potato.

My customer is buying a solution, and he's going to buy some hardware to run it on, too. The hardware is the tail in this case -- not the dog. This isn't unusual in VAR situations, and any vendor that sells through any kind of channel needs to understand this.

Finally, I'm picking on hardware here, but this applies to software, too. If you can get your customers to use Infragistics-branded grids & GUI components when mocking up UI wireframes, isn't that better than generic components, or worse, a competitor's screens. How about Oracle? I've already shown you how to make a Visio stencil, so you know it's not rocket science. How cool would it be to have little "Oracle"-branded red database icons start popping up on spec docs?

Is it just me, or is this a stupid-easy way to get closer to your channel and help them sell your product for you?

I was at a Labor Day cookout on Monday, and I was talking to a friend who's been doing some work for a construction company at a job site in Texas. At some point, he mentioned that a lot of the construction workers there are Mexican (not a big surprise), but then he went on to describe the adventures they've got in trying to verify their identities and right to work in the US, and I was dumbstruck at what's going on -- not because it's happening, but because it would be very, very easy to put a big bite on this problem. Read on to see the problem and how we could get on top of this.The scenario we're talking about, once again, is one where workers are showing up and the employer is trying to verify employment eligibility. The problems my friend was describing all had to do with Social Security numbers. I know this doesn't cover all employment eligibility scenarios, but let's start with SSN's and build out from there.

One of the things his company caught was a fraudulent Social Security card. A guy shows up with a card - everything looks just fine, and the guy starts working, in fact. When a second person reviews the paperwork, however, he sees a SSN with "00" in the middle -- an illegal number for a Social Security number. The supervisor calls the guy into his office and explains that the card's fraudulent, and that he needs to leave. The empoyee shows up at the end of the day with -- you guesed it -- a new card that has the numbers "fixed". The company knew what was up, so they turned him away, but he probably found employment somewhere else using his "new and improved" Social Security card.

My first reaction was that there surely must be a way to automate that sort of checking.

There is.

A little quick searching turned up a number of options:

Carnegie Mellon's SSN Watch Lab. This is an academic page that does some basic validation on an SSN to allow you to tell if it's a reasonable number, and to see some real rough demographic data about the person to whom it's been issued. The idea here is that you should be able to spot a person who's way too young for the card they're using, and so on.

SSN Validator. This site does even better - it'll tell you whether a number has actually been issued, and if so, whether records show the person to be alive or not -- a helpful bit of information when trying to find fraudulent SSN's, because a lot of bogus cards use recycled numbers.

Finally, the US government actually does have a facillity to check SSNs: Business Services Online.

The other problem my friend observed also sounded like one that should be pretty easy to stay on top of. Apparently, it's pretty common for these workers to claim *lots* of dependents, so that their tax witholdings drop to nothing. Now, if you've really got that many dependents, this makes perfect sense. But what if you're working under a fraudulent SSN, and you never intend to file a tax return? In that case, claiming a ton of dependents also makes a whole lot of sense.

So, how do you check the number of dependents? If there's never been a tax return filed using that SSN, it's impossible to check. Even if there is a tax return, it will be difficult to tell for sure, but you can probably flag some "unusual" increases for follow-up when tax returns roll in. Worst case, you can watch for SSNs that rack up wages and then don't file a return (hopefully, this is already happening).

But what about privacy? It's not really a problem as long as the only information you get back is "ok" or "not ok". All the information you'd send in is already known to you, since you collect it while starting a new employee anyway. Keeping the answer generic and compact keeps the answer private. If you go the route of the SSA's Business Services Online, the SSA can also track who's requesting information. You wouldn't want to have someone wrap a service in a loop and generate a list of valid SSNs!

So, with a little investigation, it looks like most, if not all, of these checks are already available. Now, how about a little legislation forcing employers to use them? It sounds like the problems my friend described are pretty prevalent, and it also looks like a big chunk of them are easily prevented.

Why in the world wouldn't we want that?

A while back, I read an article on a Joel On Software forum entitled Development Principles. I thought at the time that it made a great deal of sense to me - it seemed to strike a good balance between general and pragmatic. The responses to the article were pretty vigorous, and tended to come down pretty hard on it, I thought. I'll chalk this up to the audience, which has a strong "don't fence me in" contingency. In any event, if you've got a couple minutes, give it a read -- it's worth the time.

As many of you know, I'm a big fan of virtualization -- especially from VMWare. They've been locking horns with Microsoft for a while over this market - both traded shots with inexpensive workstation products, and both have now reached a point where there are free versions of their software, and publicly-available pre-built images are starting to show up. Not only is this validation of the market segment, it's great for us consumers, but do you really have to set up both VMWare and VPC / Virtual Server in order to run all the virtual machines that are becoming available?

Product Comparison

So, what's the difference between these products, anyway? There's a lot in common in the most recent releases, but the scenario at this point is another case of Microsoft trying hard to catch up in a product category where they entered late and lag the competition. Microsoft may eventualy win the day in virtualization, but right now, they're still playing catch up.

I installed MS Virtual Server 2005 about a week ago because the IT manager in our company has decided he likes it better for our virtualization needs, and I figured I'd better see what all the fuss was about. Shortly after I installed it, however, I came across an MSDN download for a VPC image pre-built with Visual Studio Team System server and client -- perfect for some work I was doing to prepare for a VSTS rollout here. I downloaded the image, obviously, so I've now got some experiene with both of these tools.

Here's what I'm seeing so far:

• For a workstation setting, VMWare is a more "direct" experience. Opening a VM in VMWare Workstation or Player results in a machine running visibly in a window within the VMWare application. Multiple open (or even previously-opened) machines are displayed as tabs on the VMWare application window. With Virtual Server, you load a web page to administer your VM's -- including setting up new ones. This is a great way to remotely administer your host, so it makes a great deal of sense for a server product. My only beef with this approach is that I believe it's harder for a VM newbie to understand, and VMWare does a better job of giving you the easy option first, and then letting you graduate to more advanced functionality.
• The application-orientation of the VMWare console, again, makes administration a little easier when you're working on a workstation. Again, for a server-based approach, the web-based admin console in Virtual Server works well. If you're new to virtualization, I'd recommend learning about VM setup, including networking and drive snapshots using VMWare workstation. Transitioning to the web-based admin tools is pretty easy once you understand the basics.
• VMWare has better Linux support. Only VMWare lets you run your host on Linux. Both products support Linux running as a guest OS, but this is a new feature for Micrososft, and I'd be more comfortable doing this in VMWare, both because they've got more experience supporting Linux, and because the community of users has more experience (equals more Google hits when you get into trouble). If that's not enough, there are VMWare "appliances" available already for most major Linux distros so you don't even have to go through an install to get up and running (which brings us to my next point).
• VMWare has a much more active user community. These guys stole a page out of Microsoft's own MSDN playbook and built on their early lead by energizing their user community. They set up a web site to host links to virtual "appliances" that you can download and use in your free VM player. Bam! - instant community. See the links at the end of the article for the VMTM site that hosts appliance links - there are VM appliances for everything under the sun there -- all based on some form of *nix, which helps explain why I've seen exactly one VPC download from MS -- and that's locked up on their MSDN site. Microsoft's OS licensing will prevent this sort of community from ever forming for VPC.
• VMWare runs VPC images! You can open a VPC image in VMWare, and it'll generally work pretty well. I ran into some headaches getting drivers updated, but all-in-all, I'm pretty excited by this capability. I believe it's possible to go the other way, but not quite as easily. See additional details on this below.
• Performance. I haven't done any "hard" testing of performance, but the same VM feels slightly zippier to me when run under VMWare vs. VPC. See links for additional perspectives on this.

Bottom line on both of these tools is that they're a remarkable advancement from the "good ol' days", and it's hard to go wrong with either one of them. If you're not looking into virtualization in a big way right now, you should be!

Using a Microsoft VPC in VMWare

Ok, I promised some notes, so here are the roadblocks I ran into when converting a Microsoft VSTS image to VMWare.

• Gather native files and copy them to the VPC disk drive. I ran into a problem where VMWare can't find driver.cab, and it wouldn't open or import the VPC image until I fixed the problem. I ended up copying driver.cab from my windows install, and after I opened up the VM, it turned out I needed a couple other files, too. By the time I was done, my collection included CmBatt.sys and mousclass.sys in addition to driver.cab. Save yourself a little time and copy these all to your VPC before shutting it down.
• Shut down VPC / Virtual Server. You won't be able to open or import until you do this.
• Merge changes to disk. VPC has a change tracking system for disk changes that works much like VMWare's - it works great when you want to roll back changes you've made to a VM. The other option here is to discard change and drop the change log, which will result in you losing the driver.cab file you so carefully copied above.
• Open the image and "ok" the automatic hardware installs. When you're done with that, and everything looks intact, install VMWare Tools and fix up your resolution.

That should be about it!

Note: Although I suggest copying the driver files you know you'll need to your VM disk before conversion, it's not really necessary to have them on that disk - it's just necessary that you can get to them when you need them.  If you have these files prior to conversion, copying them to the disk file makes them really easy to get to when you need them, but if you want to get to them some other way, that's fine, too.

As indicated in this StackOverflow Article, this isn't abundantly clear from the instructions above.

Additional Links

Opening VPC with VMWare
VMWare product comparison
VMWare Appliances on VMTM

My articles:
SugarCRM for Job Search Management - Part 1
SugarCRM for Job Search Management - Part 2
Administer Virtual Machines like "real" hardware