My combination of a Microsoft USB Natural Ergonomic Keyboard 4000 and a Microsoft USB Dual Receiver Wireless Mouse was causing my PC to immediately wake after hibernating.  This was also causing S4 sleep mode in Vista to fail to wake up.

Normally the wireless mouse has a wireless keyboard as part of the package, but I'm only using the mouse so I think this was causing problems - my device manager showed two keyboards even though I only have one wired keyboard.

To fix this I ended up disabling both the keyboard and mouse (receiver) from being able to resume the PC.  You can do this using the command line tool powercfg.  Here's what I did:

powercfg -devicedisablewake "Microsoft USB Natural Ergonomic Keyboard 4000 (IntelliType Pro) (001)"

powercfg -devicedisablewake "Microsoft USB Dual Receiver Wireless Keyboard (IntelliType Pro) (001)"

You can verify the device are disabled using: powercfg -devicequery wake_armed

After disabling both of those, S4 and hibernation started working again.

Over the years I've struggled with naming conventions for unit test methods, picking up various habits from different projects and people.  Roy Osherove (who reminds me of Adam Sandler) at one point recommended the following format for your unit test names:

[MethodName_StateUnderTest_ExpectedBehavior]

Although workable, and certainly an improvement over chaos, I don't find it all that appealing.  Non-programmers probably won't get it, and even programmers might have to read it a couple of times - at least that's what I ran into.  It does organize a group of tests in a fixture nicely, but beyond that...  its just not for me.

I've tried varying other methods, but I've generally always started my test names with some sort of assertion like "Should" or "Can".  This makes the test at least state what the expected behavior that is supported in a semi-fluid way.

Beyond that I like my unit test method names to convey exactly what is being tested, not just the class or method name being tested along with a state - I want a full sentence describing the expected behavior.

Up until recently I've been following the .NET naming conventions for my unit tests, but the simple fact is my method names are too long to be readable sentences.  You see, my test method names tend to be sentences which may or may not come from the user story or task itself. 

Here's an example method name from my current project using the .NET naming conventions: ShouldRedirectToShippingPageWhenShippingIsRequiredAndShippingAddressIsMissing.  Not only is this long, but its also unreadable except to programmers.  Even to programmers this isn't pretty, its just too long.

Now here's how I've been formatting my test names as of recent:

Obviously I'm breaking .NET naming conventions left and right here, but I don't care who you are, that's waaaaay more readable. Even more importantly I can discern what the test does just by reading the method name.  I find this handier than reading comments since it also shows up in your test runner. 

There's little need to go back through and re-read the test itself to figure out what the test does, its clearly stated in the method name. With this style anyone can go back and read the unit test method name and figure out the expected behavior.

I've never been too happy with the .NET naming standards especially in regards to unit tests.  The world is bigger than .NET, so take that convention!

I spent most of the day reading the language tutorials for Boo after realizing that an internal DSL for discounts and promotions would be one giant leap forward in our e-commerce web front end.  Unfortunately as a side affect of spending most of the day learning just how flexible Boo is, C# has lost a lot of its luster to me.  Boo is a fantastic language (more on that another day), but C# still has ReSharper and Visual Studio on its side.

Scratch that, Boo now has Visual Studio support too!

It seems for any language in the .NET world to gain wide acceptance it must first be integrated tightly with Visual Studio.  With BooLangStudio Boo becomes a first class .NET language.  Currently BooLangStudio is under early development, and as such it has a ways to go to become comparable to the VS C# experience, but despite the rough edges, its very usable.  I did run into some issues getting started, all very minor considering how early in development the add-in is.

First off, you need to install the MS Visual Studio 2008 SDK, then finally install the BooLangStudio add-in.  The BooLangStudio add in is installed from the command line by running the "install.bat" file which essentially bootstraps an NAnt build script.

With that out of the way, you start Visual Studio 2008 using the "development hive".  This is done from the start menu from the VS 2008 SDK start menu folder.

After which we can create a new boo project using one of the installed templates.

Choosing the Boo Console Application creates everything for a "boo hello world" application, as seen here.

The nice thing about the .booproj files is that they are MSBuild files just like in C#, which also means they should work in SharpDevelop which includes Boo support.  From my standpoint its important that MSBuild is supported for automated builds and customization.  Once a boo project is created, building and running is simple as hitting F5.

If you have any compilation errors they show up in the Errors List just like in any other Visual Studio language.

The on issue I did have, is with my tab settings for Boo.  Boo uses indentation to track code blocks rather than braces or end statements, so unfortunately it's white space sensitive.   Here's my really "super awesome" Car class that I added to my project.

Notice that the syntax highlighting isn't perfect, but that's very minor.  Slightly less minor, to get a new Car class to compile I first had to go into the Visual Studio Tools | Options menu and set the tab spacing for Boo.  Before I did that I was getting odd, "expecting DEDENT" and "expecting INDENT" errors all over the place.

Once I set the tab size and re-did the tabbing for my class, everything worked just fine.

July 1st is right around the corner and for e-commerce based companies in Washington this means that Senate Bill 5089-2007-08, or the "Stream Lined Sales Tax" bill takes effect.  In short this means that online retailers in Washington need to collect destination based sales taxes.

Washington state is not alone on this.  In fact Washington is joining 21 other states under the Streamlined Sales and Use Tax Agreement (SSUTA).  Notice the "Use Tax" in the wording.  This is what empowers the state to tax based off destination shipping address.  This is just like when you go to register a boat in Washington that you purchased in Oregon, you are paying a use tax, which is legal according to the constitution.

Fortunately the Supreme Court ruled in Complete Auto Transit vs Brady that states cannot tax interstate commerce, which really means that an online retailer in Washington does not have to collect California state sales tax, unless that online retailer also has offices in California. 

With the passage of Stream Lined Sales Tax bill there are several winners here:

• Washington state tax coffers.
• Local brick and mortars.
• Lawyers and possibly accountants.
• Tax integration consultants.

Online retailers that only have an online presence previously had a nice loophole around collecting state sales tax since they are generally located in only one or two states.  Chain based brick and mortars (like Barnes and Nobles) that decide to go online are at a district disadvantage since they have presences in most, if not all states, which means they need to collect sales taxes from online sales in just about every state.

The absolutely ridiculous part of this law is the extra complexity to ensure the right local sales tax is collected.  In other words the shipping address dictates the sales tax rate, and in Washington each locality has its own sales tax rate with local governments setting local sales tax.  This means the sales tax rate can vary widely, and you, Mr. e-tailor need to figure it out.

Fortunately we all have zip codes here in the US which we can use to figure out the local sales tax rate, unfortunately we also have zip+4.  Well, zip+4 isn't bad, in fact its actually useful, but most people have no idea with their zip+4 is.  I know I definitely fall into that category.  And wouldn't you know it, the shipping zip code isn't enough to figure out the correct sales tax, you need the zip+4.

We can't start asking customers for their zip+4, since they probably don't have any idea what the last 4 numbers are, but we can ask them for their address and regular zip code which we can then use in a cleansing call to the USPS webtools APIs.  This address cleansing call, as you might now suspect, fills in the zip+4 based off the street address and zipcode.

With zip+4 in hand we can query our local database of sales tax rates and charge the customer the locally correct sales tax rate.

Just today I realized that I'm using a fair number of Visual Studio 2008 addins. Visual Studio is starting to look more and more like Eclipse to me, a general work bench of tools. Which is surprising considering how painful it can be to write a Visual Studio addin in the first place.

So what addins am I using today?

• VisualSVN - Seamless and painless, I almost forget that its there.  If you use SVN and Visual Studio, do yourself a favor and fork over the $50 for it.
• ReSharper 4.0 - My refactoring/template tool of choice.  Coding without Re# is like digging a hole without a shovel.  I also use it to drive my unit tests, but TestDriven.NET is superior IMO.
• TargetProcess - This shows all my current tasks and bugs right from within Visual Studio so there's no need to jump over to my web browser to find work or update status.
• GhostDoc - I use this to bootstrap any XML documentation I might need.
• ActiveWriter - I just installed this, so we'll see how it goes.  I'm going to use this to map some entities to a new view or two.

Yesterday I blogged about detecting IIS version from MSBuild, or more accurately, OS version.  Detecting whether my MSBuild script was running on XP allowed me to skip the application pool creation that would otherwise error out the build script.

What I didn't expect was that the website creation task would actually succeed in creating a secondary website in IIS 5.1.  I vaguely remember from other blog posts how its possible to programmatically create secondary websites in IIS 5.1, but didn't realize it was so easy.  Just for the record the following snippet also works against IIS 6 and 7.  The following build script does exactly that.

That takes care of new site creation, only optionally creating the site if it doesn't already exist, but always modifying it to ensure consistent settings.  The final piece we need is to stop running "Default Web Site" and start the new site.  IIS 5.1 can only run one site at a time so this is why we stop the default site and explicitly start the new site.

Once the script finishes we can check in inetmgr to see the new IIS 5.1 site right along side the default web site.

Are you wondering why I would go to all this trouble of monkeying around with IIS for development?  Well you should be.  The reason is that the Visual Studio web server does not support ISAPI filters, and since I'm doing URL rewriting at the ISAPI level, running under IIS is the only option.

I've been using the Microsoft SDC tasks to deploy IIS websites, and for the most part this has worked well once I grabbed the latest source from CodePlex; I ran into a few bugs that have been fixed since the last release.

Anyways, I've run into an annoyance with regards to local development builds on Windows XP.  Most of our devs are still using XP for their development platform which as you may know uses an old version of IIS - IIS 5.1.

• No app pools
• Single site only
• No SSL

So, what does this have to do with the SDC tasks?  Well, I want the MSBuild script to fail gracefully with an intelligent error message when run on Windows XP.  Something like:

This version of IIS is not supported, IIS 6.0+ is required.

I couldn't find a decent built-in supported way in MSBuild to get the IIS version, let alone the operating system version.  You would think this would be supported without resorting to C#, but I couldn't find a way.  So what I ended up doing was using the command line "ver" command and piping that to a text file and then reading it back in.  Here's what that looks like:

I needed to create an xml fragment that had optional elements that was serialized from a class.  The optional elements were integers and decimals, types that are not nullable by default in .NET.  Well, we can wrap those types in Nullable<T> and then add an another ignored property that helps out the .NET serializer.

[XmlElement(Order = 10)]
public decimal? Height
{
    get { return height; }
    set { height = value; }
}

[XmlIgnore]
public bool HeightSpecified
{
    get { return height.HasValue; }
}

With the additional HeightSpecified property, the XmlSerializer will only write out the Height property element if its non-null.

Initially I tried using [XmlElement(IsNullable=false)] on the Height property, but that ended up throwing an InvalidOperationException when I went to serialize my class.