I recently upgraded to Windows 7.0 and I have to say that I'm liking it and it's a heck of a lot better than Vista.  I can't really put my finger on it, it just seems easier to navigate through stuff and get to what I want.  But one of the things I found disappointing was the performance of Windows Virtual PC, which is currently in Release Candidate (as of this posting).  I've got a nice machine with a quad-core and 8 gigs of RAM, and VPCs in the past have been like working directly on another box.  But even with the RAM maxed out for a VPC, the VPC machine was running horribly slow.  I soldiered through working on a VPC for a night, and I think it took about 8 hours to do about 2 hours worth of work.

In the end, I moved the VPC from my host drive (C:) to a USB 2.0 hard drive.  It was like day and night - the VPC was back to running at full speed.  I'm not sure why having the VPC image on your host drive is such an issue (it wasn't in Vista), but if you're having performance issues with VPC on Windows 7.0, I highly recommend moving the image.

I'm a big fan of enabling XML comments when you're working on a project (either alone or as a team) because it helps you quickly identify what has and what has not been documented.  When you have XML comments enabled, the compiler will show warnings for any public and protected classes / class members that do not have XML comments.  To enable XML comments you just check the XML documentation file option in the build tab of the project properties page. 

One of the issues that you run into, however, is that there can be a number of code generated files in your projects, and you have no control over that code.  But, if that file is no re-generated often, then you can insert a bit of code to suppress XML comment warnings from that file:

The next time you compile, XML comment warnings from the file will not be display.  If you're wondering, the 1591 is the specific warning number for XML comments.  If you remove the XML comment warning number from the pragma statement, then all warnings from the file are suppressed, not just XML comment warnings.  no warnings will come from the file.  You can also tack on additional warning codes to suppress additional types of warnings, if desired.  How do you figure out what the numbers are?  I find one of the easiest ways to go about it is to read the output window (NOT the Error List window).  When a warning is generated, it normally looks something like the following:

[filename]: warning CS1591: Missing XML comment for publicly visible type or member 'VSeWSS.TargetListAttribute'

Notice there is a number right after the warning (in this case its CS1591)?  Just drop the alpha prefix and you've got your warning number.  Since this is in the output window, you may have to scroll through the text a bit to actually find the warning, but it should be in there somewhere.

SharePoint sites normally have a 'Name ActiveX Control' used to communicate you're online presence back to the Office system.  If you've ever seen a site where it shows you who is 'online' and who is 'offline' then know that this is the mechanism that marks someone as being 'online'.  That is all fine and well for internal application, but it kinda sucks for public facing sites because users are asked to install some weird ActiveX control that they know nothing about.  I find it particularly odd that it's included on the default publishing site.  Whatever.  Fixing it should be relatively easy because there is a knowledge base article outlining what to do:

Knowledge Base Article 931509

Unfortunately, that only gives you part of the solution.  It basically tells you to comment out two function headers in the init.js file.  If you follow the instructions in the Knowledge Base article exactly, you'll see a little JavaScript error notification when you refresh the page.  Probably because, now, let me guess . you commented out a function header without commenting out the rest of the function?  Also note that one of the functions you commented out gets called later, which is a bit of a syntactical no-no in just about every language of which I can think.

So, if you want to avoid the 'Name ActiveX Control' message on your SharePoint site AND have it work correctly (novel idea), you need to entirely comment out both functions, and comment out any references to those functions anywhere else in the JavaScript file.

I was reading an article today about how GoDaddy removed a customer's domain name from their registry at the request of MySpace.com.  You can view it here:

GoDaddy Pulls Security Site After MySpace Complaints

Apparently someone had posted usernames and passwords of MySpace users to SecLists.org, and MySpace wanted the offending material to be removed immediately.  Instead of contacting the website owner, MySpace contact GoDaddy and requested the domain deletion.  This effectively took the entire site offline, not just the offending material.   I think there are going to be more than a few people who are a bit miffed at GoDaddy for going along with the request, but what can you do?

And that's when I saw something interesting.  Immediately following the article was a "Sponsored Links" section containing Google ads.  And guess who was right at the top of the list?  GoDaddy.  Check out the article and scroll to the bottom, it will probably be there for you as well.

This got me thinking.  Google Ads, from what I understand, work on a per-click basis.  You click on an ad, and Google charges the company for that click.  So you can exact some menial form of personal vengeance on companies that you feel deserve your wraith by clicking on their Google Ads with no intention of buying anything.

Or you employ your friends, family, coworkers, and people on the web to wage an all out vengeance ad click war to broadside the advertising efforts of a company.

I'm sure the day is comming.

I can imagine how the conversation must have gone.  A slick salesman stood in the board room staring down a room full of business savy executives.  "Just image how much money you will save," said the salesman, producing a break even analysis and complex charts backing up the claims of his product.  Everything looked good on paper.  All of the numbers made sense.  And aside from being a great economical decision, the technology they were about to buy into would also help save the environment!  What choice did they have but to buy in and send their money straight to the crapper?

Yes, restroom technology.  The loo.  It's becoming a more interesting journey each time nature calls because you never know what you're going to find next.  But is it really worth it?  I was recently out at a client-site where they spent who knows how much money outfitting their restrooms with the most up-to-date technologies a restroom has ever seen. Theoretically, the concept is great.  Embedded in all of you're favorite restroom fixtures are infrared sensors that determine how close you are to the item in question and whether you are coming or going.  When you walk away from a toilet, it auto-flushes.  When you put your hand near the soap dispenser, it auto-dispenses.  And the faucets only run when you're hands are in the sink.  At least in theory.

Reality, however, is another story.  Take the toilets and urinals for example.  Although they are great at determine when you're leaving, they are not so great at determining when you're not leaving.  Make one wrong move during your transaction and you'll set it off.  And if it catches you off guard and makes you jump, well, you'll probably set it off again.

Soap dispensers and faucets can also be problematic.  They're fun at first because you wave your hand under the soap dispensers and they fire a little squirt of soap on your hands.  Then you move your hands under the faucet and a torrent of water comes shooting out.  But while you're hand is under the faucet it’s only about 4 inches from the soap dispenser, so the dispenser continues to squirt soap because it's still sensing your hand.  When it's all said and done, you end up with clean hands and a gooey pile of soap in the sink. 

But sometimes it works out because you'll walk away and the faucet sensor gets stuck and the water never turns off (which in turns helps rinse away the soap).  You wave your hand back and forth under the sink hoping that you'll be able to turn the water off, but you only succeed in setting off the soap dispenser again.  You look for a way to turn off the water, but there are no knobs or buttons because it's a hands free system, so you're pretty much helpless. 

And as you away down the hallway and hear the fading sound of running water coming from the loo, remember, that's the sound of progress.