The Daily Parker

We're doing some very cool things at 10th Magnitude. Here's my boss, CEO Alex Brown, explaining:

Notice, by the way, how often I have mentioned an employer on this blog. I'd discuss the company more right now, but I have to get back to writing some pretty cool Azure code...

The Wind Map is one of the coolest things I've ever seen:

And apparently, Isaac is going to hit Valparaiso (and, um, us):

After installing Windows 8 yesterday, I discovered some interaction problems with my main tool, Visual Studio 2012. Debugging Azure has suddenly become difficult. So after installing the OS upgrade, I spent about five hours re-installing or repairing a whole bunch of other apps, and I'm not even sure I found the causes of the problems.

The next step is to install new WiFi drivers. But seriously, I'm only a few troubleshooting steps from rebuilding the computer from scratch back on Windows 7.

Cue the cursing...

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.

I should really learn to estimate networking and migration tasks better. The last time I upgraded my FogBugz instance on my local web server, it took about 20 minutes. This led me to estimate the time to migrate it to a Microsoft Azure Virtual Machine at 2 hours.

Well, 2½ hours later, I'm a little frustrated, but possibly closer to getting this accomplished.

The point of a virtual machine, of course, is that it should appear the same as any other machine anywhere. But using an Azure VM means either using an Azure SQL Database or installing SQL Server right on the VM. Obviously you'd want to do the former, unless you really like pain. Unfortunately, FogBugz doesn't make it easy to do this, and in fact puts up roadblocks you'll need to get around.

Here, then, are the steps I went through trying to get FogBugz moved to an Azure VM:

0. First, before anything else, I copied my FogBugz database in its entirety up to a new Azure SQL Database using the incredibly useful SQL Azure Migration Wizard tool.

1. Ran the FogBugz installer on the VM. It didn't accept my database connection because SQL in Azure doesn't have the xp_msver extended stored procedure that lets FogBugz know what version of SQL it uses.

2. Checked Fog Creek Software's support forum. They don't support FogBugz on Azure SQL Databases.

3. Attempted to create the xp_msver stored procedure on the SQL Azure master database; permission denied.

4. Installed SQL Server 2008 Express on the VM.

5. Re-ran the FogBugz installer. It can't connect to the IIS configuration file, and therefore thinks I don't have IIS on the machine.

6. Re-ran the FogBugz installer, this time just extracting the files to a folder under the VM's Web root.

7. Set up a new application in IIS pointing to the FogBugz folder.

That put me in the weeds, because the application has no configuration settings available. Opening the app in a browser gives me the error message: "The FogBugz database is down or could not be found." It further suggests that I need to change the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Fog Creek Software\FogBugz\{application folder}\sConnectionString. So I did, and I got the same error.

The reason is that on 64-bit servers, the FogBugz configuration keys aren't in HKLM\Software; they're really in HKLM\Wow6432Node. I figured this out because, remember, I have a running FogBugz installation, and I was able to search the server's registry directly.

All right, moving on:

8. Copied my existing server's FogBugz registry keys (from the right registry folder) to the VM.

Nope. FogBugz still gave me the same error. I also copied the connection string to the registry key FogBugz claimed it was looking in, with the same result.

OK, I'm going to now uninstall everything and reboot the VM, then try again to install FogBugz pointing to SQL Express. Back in a flash...

(20 minutes later...)

OK, FogBugz installed cleanly, but at the moment it's pointing to the local SQL Express database. So: change the connection string to SQL Azure...and bam! It works.

Excellent. Only two applications left to move...

Groupon, now trading somewhere around 25% of its IPO value, continues to unimpress people:

The disclosure that I found most revealing in last week's financial report was the relationship between Groupon's marketing spending and its growth rate. Traditional daily-deal revenue declined 6.9 percent from the first quarter to the second, as Groupon dialed back marketing outlays by 24 percent.

Hawking Groupon shares in the IPO roadshow, Mr. Mason said the company eventually would be able to cut back on marketing without sacrificing growth. This was meant to assure prospective investors that money-losing Groupon would become “wildly profitable,” as Executive Chairman and co-founder Eric Lefkofsky put it in an illicit media interview during the IPO registration process.

My guess is that another quarter or two like the last one will be enough to ease Mr. Mason into a position better suited to his eclectic interests. The challenge will be finding a replacement with certifiable executive skills and strategic vision.

Which prompts the question of what a better strategy for Groupon might be. Mr. Mason talks about becoming the “operating system for local commerce,” jargon that could mean anything—or nothing. Corporate mumbo-jumbo won't help Groupon now. It needs a new business.

I've noted before, Groupon's IPO benefited only one group of people: Groupon investors. The company has an easily-copied idea, and appears to lose money on every coupon it sells. Good on them for having $1 bn in cash; they'll need it.

The title says it all. I've moved Hired Wrist, my dad's brochure site, up to my Azure VM, leaving only Weather Now, plus my bug tracking and source control applications, in my living room the Inner Drive Technology Worldwide Data Center.

I'll move the two third-party apps next weekend. My experience moving Hired Wrist this morning suggests that moving Weather Now will be, as we say, "non-trivial" (i.e., bloody hard).

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.

While trying to move a customer's app into the cloud yesterday (and well into this morning), I encountered a problem that doesn't make any sense. I now very much want to find the guys who wrote Microsoft Azure's error handling and punch them in their faces.

When you access an Azure storage container, you have to use only lower-case letters, or Azure will throw a StorageClientException with the thoroughly unhelpful message "One of the request inputs is out of range." So, in all the code I've written that uses Azure storage, it makes sure everything that needs to be lower-case is actually lower-case.

So why am I getting the exception now? No one seems to know.

Worse, the exception only happens in actual deployments, not in the Azure emulator (which you use to test your code on your own computer).

I hope to have this figured out soon. Because I'd really like to get some sleep.

Remember all those Azure migrations I've done over the past month? Well, I have another one that I wasn't expecting, and for a variety of reasons including a failed web server, it must be completed by Monday morning.

Remember I'm going to San Diego tomorrow? Good thing the airplane has WiFi.

And people wonder why I eat chalk a lot...