The Daily Parker

My latest entry is up on the 10th Magnitude tech blog:

We've taken a little more time than we'd hoped to figure out how to deal with Azure deployment credentials and profiles properly. In an effort to save other development teams some of our pain, we present our solution. First, the general principle: Publication profiles are unique to each developer, so each developer should have her own management certificate, uploaded by hand to each relevant subscription.

When you deploy a project to a Windows Azure Cloud Service instance, you have to authenticate against the Azure subscription using a management certificate. The Publish Windows Azure Application wizard in Visual Studio presents you with a helpful link to sign in to your Azure subscription and download credentials. If you do this every time you publish to a new subscription, you (a) rapidly run up against the 10-certificate limit in Azure; and (b) get ridiculous credential files called things like "WorkSubscription1-AzDem12345-JoesSubscription-MySecretProjectThatMyBossDoesntKnowAboutSubscription.publishsettings" which, if you're not paying attention, soon shows up on a Subversion commit report (and gives your boss access to that personal project you forgot to mention to her).

Don't do that. Instead, do this:

1. Create a self-signed certificate using IIS. Name it something clear and unique; I used "david.10thmagnitude.com," for instance.

Then export it to a private folder.

2. Import the .pfx file into your local certificate store.

3. Export the same certificate as a .cer file.

4. Go to the Azure management portal's management certificate list.

5. Upload the certificate you just created to the subscriptions to which you want to publish cloud services.
 

Now you have a single certificate for all your subscriptions. Next, create a publishing profile with the certificate:

6. In your Azure cloud service project, right-click the project node and choose "Publish…" to bring up the Publish Windows Azure Application wizard.

7. Drop down the "Choose your subscription" list and click "<Manage...>"

8. Click "new"

9. In the "Create or select..." drop down, find the certificate you just created and choose it.

10. Continue setting up your publishing profile as you've done before.

That's it. Except for one other thing.

If you have more than 0 developers working on a project, at some point you'll use source control. Regardless whether you have Subversion, Mercurial, or whatever, you need to avoid committing keys, certificates, and publishing profiles into your VCS. Make sure that your VCS ignores the following extensions: *.pfx, *.cer, *.publishsettings, and *.azurePubxml.

You want to ignore pfx and publishsettings files because they contain secrets. (I hope everyone knows this already. Yes, pfx files use passwords, but publishsettings don't; and anyway, why would you want to risk anyone else authenticating as you without your knowledge?) Ignore cer files because they're not necessary in an Azure project. And ignore azurePubxml files because every developer who publishes to Azure will wind up overwriting the files, or creating new ones that no one else uses.

I haven't any time to write today, but I did want to call attention to these:

• Parker is fine, though it appears likely he pulled a hind leg muscle on Sunday. He spent much of Sunday crying and really, really hating the stairs; today he was able to stand up and grab a treat from my hand. Tomorrow he'll get a 3 km walk in the morning.
• Alex Brown, my boss, has a new blog entry up.
• The Smithsonian wrote about a CIA burglar who went rogue.
• Reuters' Felix Simon argues against high-frequency trading.
• Andrew Sullivan is freaking out about the President's debate performance. Twice.
• Both Chicago newspapers have endorsed Tammy Duckworth in the 8th district U.S. House race against right-wing nutter Joe Walsh.

Back to the mines...

Last night, around 11:30pm, the power went out in my apartment building and the ones on either side. I know this because the five UPS units around my place all started screaming immediately. There are enough of them to give me about 10 minutes to cleanly shut down the servers, which I did, but not before texting the local power company to report it. They had it on again at 1:15am, just after I'd fallen asleep. I finally got to bed around 2 after bringing all the servers back online, rebooting my desktop computer, and checking to make sure no disk drives died horribly in the outage.

But unlike the last time I lost power, this time I did not lose email, issue tracking, this blog, everyone else's site I'm hosting, or the bulk of my active source control repositories. That's because they're all in the cloud now. (I'm still setting up Mercurial repositories on my Azure VM, but I had moved all of the really important ones to Mercurial earlier in the evening.)

So, really, only Weather Now remains in the Inner Drive Technology Worldwide Data Center, and after last night's events, I am even more keen to get it up to the Azure VM. Then, with only some routers and my domain controller running on a UPS that can go four hours with that load, a power outage will have less chance of waking me up in the middle of the night.

It seems that the more I have to do, the more I'm able to do. In other words, when I haven't got a lot of assignments, I tend to veg out more. Right now I'm on a two-week development cycle, with an old client that predates my current job anxious for some bug fixes. Oddly, the old client tends to get his bug fixes when I have more to do at my regular gig.

Of course, blogging might suffer a bit. In fact I just submitted a draft blog entry for the 10th Magnitude Developer Blog that should hit tomorrow sometime. Until then, it's embargoed (which I hate because it's a timely and useful topic), and I have a feature to finish.

I guess all of this means, with apologies to René Magritte, ceci n'est pas un blog post.

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...

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.

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...

Sometimes things just work.

Last weekend, I wrote about moving my last four web applications out of my living room the Inner Drive Technology International Data Center and into the cloud via a Microsoft Azure Virtual Machine.

Well, if you're reading this blog entry, then I've succeeded in moving The Daily Parker. Except for transferring files (the blog comprises 302 megabytes over 13,700 files), which happened in the background while I did other things, it only took me about 45 minutes to configure the new installation and make the necessary changes to DNS.

Despite the enormous volume of data, this was the easiest of the four. DasBlog has no dependencies on outside services or data, which means I could move it all in one huge block. The three remaining applications will take much more configuration, and will also require data and worker services.

I'm still surprised and pleased with the smoothness of the transfer. If the other three migrations go anywhere nearly as easily as this (taking into consideration their complexities), I'll be an Azure Evangelist for years.

My latest missive for my employer, "When to use Microsoft Azure’s IaaS instead of PaaS", is now available on the 10th Magnitude blog. It's similar to a post from last weekend, but with better writing and editing.

According to Jeff Atwood, today's the day:

When you're hired at Google, you only have to do the job you were hired for 80% of the time. The other 20% of the time, you can work on whatever you like – provided it advances Google in some way. At least, that's the theory.

Although the concept predates Google, they've done more to validate it as an actual strategy and popularize it in tech circles than anyone else. Oddly enough, I can't find any mention of the 20% time benefit listed on the current Google jobs page, but it's an integral part of Google's culture. And for good reason: notable 20 percent projects include GMail, Google News, Google Talk, and AdSense. According to ex-employee Marissa Meyer, as many as half of Google's products originated from that 20% time.

He goes on to ask if your company is ready, and offer some suggestions how to implement it. I think it's easier to do when you don't have billable-hour pressure, but still, we at my company do manage to get some goofing-off time in.

Or, put another way, "why is this day different from all other days?"