The Daily Parker

Politics, Weather, Photography, and the Dog

W-8, W-8!

This morning I installed Microsoft Windows 8 on my laptop. As a professional geek, getting software after it's released to manufacturing but before the general public is a favorite part of my job.

It took almost no effort to set up, and I figured out the interface in just a few minutes. I like the new look, especially the active content on the Start screen. It definitely has a more mobile-computing look than previous Windows versions, with larger click targets (optimized for touch screens) and tons of integration with Windows Accounts. I haven't linked much to my LiveID yet, as I don't really want to share that much with Microsoft, but I'll need it to use SkyDrive and to rate and review the new features.

I also did laundry, vacuumed, cleaned out all my old programming books (anyone want a copy of Inside C# 2 from 2002?), and will now go shopping. And I promise never to share that level of picayune personal detail again on this blog.

Why you should always "sleep on it"

If one of the developers on one of my teams had done this, I would have (a) told him to get some sleep and (b) mocked him for at least a week afterwards.

Saturday night I spent four hours trying to figure out why something that worked perfectly in my local Azure emulator failed with a cryptic "One of the request inputs is out of range" message in the Cloud. I even posted to StackOverflow for help.

This morning, I spent about 90 minutes building a sample Cloud application up from scratch, adding one component at a time until I got to the same failure. And, eventually, I got to the same failure. Then I stepped through the code to figure out

And I immediately saw why.

The problem turned out to be this: I have two settings:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceDefinition name="Cloud" ...>
      <WebRole name="WebRole" vmsize="Small">
        <ConfigurationSettings>
          <Setting name="MessagesConfigurationBlobName" />
          <Setting name="MessagesConfigurationBlobContainerName" />
        </ConfigurationSettings>
      </WebRole>
    </ServiceDefinition>

Here's the local (emulator) configuration file:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceConfiguration ...>
      <Role name="WebRole">
        <ConfigurationSettings>
          <Setting name="MessagesConfigurationBlobName" value="LocalMessageConfig.xml"/>
          <Setting name="MessagesConfigurationBlobContainerName" value="containername"/>
        </ConfigurationSettings>
      </Role >
    </ServiceConfiguration>

Here's the Cloud file:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceConfiguration ...>
      <Role name="WebRole">
        <ConfigurationSettings>
          <Setting name="MessagesConfigurationBlobName" value="containername" />
          <Setting name="MessagesConfigurationBlobContainerName" value="CloudMessageConfig.xml"/>
        </ConfigurationSettings>
      </Role >
    </ServiceConfiguration>

I will now have a good cry and adjust my time tracking (at 3am Saturday) from "Emergency client work" to "Developer PEBCAK".

The moral of the story is, when identical code fails in one environment and succeeds in another, don't just compare the environments, compare *everything that could be different in your own code* between the environments.

Oh, and don't try to deploy software at 3am. Ever.

Deployments are fun!

In every developer's life, there comes a time when he has to take all the software he's written on his laptop and put it into a testing environment. Microsoft Azure Tools make this really, really easy—every time after the first.

Today I did one of those first-time deployments, sending a client's Version 2 up into the cloud for the first time. And I discovered, as predicted, a flurry of minor differences between my development environment (on my own computer) and the testing environment (in an Azure web site). I found five bugs, all of them minor, and almost all of them requiring me to wipe out the test database and start over.

It's kind of like when you go to your strict Aunt Bertha's house—you know, the super-religious aunt who has no sense of humor and who smacks your hands with a ruler every time you say something harsher than "oops."

End of complaint. Back to the Story of D'Oh.

Azure build error messages aren't helpful

When working with Microsoft Windows Azure, I sometimes feel like I'm back in the 1980s. They've rushed their development tools to market so that they can get us developers working on Azure projects, but they haven't yet added the kinds of error messages that one would hope to see.

I've spent most of today trying to get the simplest website in my server rack up into Azure. The last hour and a half has been spent trying to figure out two related error messages that occurred when trying to debug a Web application project that I converted from a Web site project:

  • Failed to debug the Windows Azure Cloud Service project. The output directory ' { path }\csx\Debug' does not exist.
  • Windows Azure Tools: Can't locate service descriptions.

The first error message seems straightforward enough: when the project got created, it never added the \csx\Debug folder. After creating the empty \csx\Debug folder, the second message occurs.

When an Azure project builds, it's supposed to create the \csx\Debug folder under the Cloud Service project root. It then copies the service definition (.csdef) and configuration (.cscfg) projects into the folder, which the Azure compute emulator can hook into.

In my project, this wasn't happening. So I created a new Cloud solution to see if this was a system problem or a configuration problem. (First I uninstalled and reinstalled all the Azure tools...which wasn't as big a time-suck as it could have been because I walked Parker while that was going on.)

The Deleteme solution built fine; mine still had the problem. So then I started comparing the configuration, project, and solution files...and completely missed the significance of this:

...except it gnawed at me for a few minutes, until I looked at this:

Why it created a configuration and then decided not to build it I just don't know. The solution to my hours of pain is simply to do change the solution platform to Any CPU (or check "build" on the .NET platform):

I am now going to fix the hole in my desk where I've been pounding my head.

When I started getting these messages, I Googled and I Googled, but the technology is so new that no one else appears to have had exactly this problem. I hope this post pays back some of the Karmic debt I've taken on from all the times when someone else had the right answer.

Troubleshooting software installation on Windows 7

I have just spent an hour of my life—one that I will never get back—trying to figure out why I couldn't install any software from .msi files on one of my Windows 7 machines. Every time I tried, I would get a message that the installer "could not find the file specified."

I'll spare you all the steps I went through to figure out why this was happening, and get to the punchline:

>

Yeah, you see, the SYSTEM account needs full control over any file you're trying to install on Windows. Here's how it should look:

So, if you're a security-conscious individual who's locked down his PC thoroughly, and you can't seem to install anything on Windows anymore, check the permissions on the folder containing the .msi file.

As we say in programming: herp-a-derp.

Time zone pet peeves

In general, people using words they don't understand, presumably to sound smart, drives me up a tree. In specific, I wish against reason that more people knew how time zones worked. Microsoft's Raymond Chen agrees:

One way of sounding official is to give the times during which the outage will take place is a very formal manner. "The servers will be unavailable on Saturday, March 17, 2012 from 1:00 AM to 9:00 AM Pacific Standard Time."

Did you notice something funny about that announcement?

On March 17, 2012, most of the United States will not be on Standard Time. They will be on Daylight Time. (The switchover takes place this weekend.)

Now, I'm one of the few people in the world who has implemented a complete time zone package for Windows systems, and regular readers will already know about my vocal defense of the Olson/IANA time zone database. So I don't expect most people to know the ins and outs of time zone abbreviations. But this is the point Chen makes, and I would like to make: if you don't know what you're writing, don't write it. Say "Central time" or "local Chicago time" instead of "Central Standard Time," if for no other reason than you'll be wrong about the latter 8 months out of the year.

Quick updates

A couple of things have happened on two issues I mentioned earlier this week:

That is all for now. We in Chicago are bracing for 15 cm of snow tomorrow, so there may be Parker videos soon.

Oh, and: Kodak actually did file for bankruptcy protection today.

Local time zone displays

The new feature I mentioned this morning is done. Now, in addition to the "where was this posted" button on the footer, you will notice the entry's time zone. Each entry can have its own time zone—in addition to the site-wide default.

I still have to fix a couple of things related to this change, like the fact that the date headers ("Thursday 24 November 2011," just above this entry) are on UTC rather than local time. But going forward (and going backward if I ever get supremely bored), you can now see the local time wherever I was when I posted.

Incidentally, if you want to bring the tzinfo database to your .NET application, I have licensing terms.

Simplified explanation of tzinfo mess

The AP has picked up the story about the tzinfo database moving to ICANN:

The organization in charge of the Internet's address system is taking over a database widely used by computers and websites to keep track of time zones around the world.

The transition to the Internet Corporation for Assigned Names and Numbers, or ICANN, comes a week after the database was abruptly removed from a U.S. government server because of a federal lawsuit claiming copyright infringement.

Without this database and others like it, computers would display Greenwich Mean Time, or the time in London when it isn't on summer time. People would have to manually calculate local time when they schedule meetings or book flights.

Ah, I do love the popular press, trying to explain things. AP writer Anick Jesdanun generally did all right explaining the problem and the move, except the story has no information about the tzinfo community's response to the mess. (I'm just sad they didn't mention The Daily Parker.)