The Daily Parker

Politics, Weather, Photography, and the Dog

Home for the holidays?

Only a little, it turns out. I'm in the second of three weeks without travel, but I'm back on the road for the first two weeks in December. I even have to miss a concert, which is a bad thing, but it's because I'll be doing a technical diligence in freakin' Paris, which est pas mal. I'm also going to see about taking a quick side-trip to London, which, given the agenda for the diligence and flight schedules back to the U.S., might not make a difference as far as my work schedule goes.

I've also noticed that I keep missing posts on Saturdays. Not sure why; possibly because I've had a lot going on during the week, and Saturdays have been a little more vegetative than expected.

One hundred tech tips for non-techies

Microsoft's Scott Hanselman provides a list:

"Knowing computers" today is more than just knowing Office, or knowing how to attach a file. Today's connected world is way more complex than any of us realize. If you're a techie, you're very likely forgetting how far you've come!

The #1 thing you can do when working with a non-techie is to be empathetic. Put yourself in their shoes. Give them the tools and the base of knowledge they need.

  • Backup everything. Is your entire company on your 10 year old computer’s desktop? Look for Backup options like CrashPlan, DropBox, OneDrive, etc. Literally ANYTHING is better than leaving documents on your computer’s desktop.
  • Learn to use search to find your files. Press the Windows key and just start typing on Windows, or use Spotlight (Command-Spacebar) on Mac.
  • Don’t CC more than 10 of your friends or neighbors. At that point, consider another way to talk to them. Some of your friends may not want their email given to the world. Perhaps this is a time to use BCC (Blind Carbon Copy) so you don't expose everyone's email address to each other?

Techies should read this post to understand what their non-techie friends don't understand. Everyone else should just read it.

Cheating

For more than four years, I have not failed to post an above-average number of entries each day. Since its official launch in November 2005, I've averaged about 1.28 entries per day. As of the last entry, the 39th for September, the average was 1.25. This makes it 1.33.

It's a simple target, really: 40 or 41 per month, depending on the number of days in the month. Since one of the stated purposes of the blog is to encourage daily public writing, meeting this target is almost a requirement.

Someday, probably early in 2015, the average daily rate will exceed 1.32, and I'll have to write 41 or 42 per month to keep the long-term trend positive. And someday I'll slip. But not this month. Oh, no. This month, I'm posting 40.

See you in October.

Lost weekend?

Nah, I've just been super-busy the past few days. Regular posting should resume shortly—depending on how this week in Cleveland goes.

What's going on with the Microsoft Azure blog?

For the last couple of days, I've had trouble getting to Microsoft's Azure blog. From my office in downtown Chicago, clicking the link gives me an error message:

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

However, going to the same URL from a virtual machine on Azure takes me to the blog. So what's going on here? It took a little detective work, but I think Microsoft has a configuration error one of a set of geographically-distributed Azure web sites, they don't know about it, and there's no way to tell them.

The first step in diagnosing a problem like this is to see if it's local. Is there something about the network I'm on that prevents me from seeing the website? This is unlikely for a few big reasons: first, when a local network blocks or fails to connect to an outside site, usually nothing at all happens. This is how the Great Firewall of China works, because someone trying to get to a "forbidden" address may get there slowly, normally, or not at all—and it just looks like a glitch. Second, though, the root Azure site is completely accessible. Only the Blog directory has an error message. Finally, the error message is coming from the foreign system. Chrome confirms this; there's a HTTP 200 (OK) response with the content I see.

All right, so the Azure Blog is down. But that doesn't make a lot of sense. Thousands of people read the Azure blog every day; if it were down, surely Microsoft would have noticed, right?

So for my next test, I spun up an Azure Virtual Machine (VM) and tried to connect from there. Bing! No problem. There's the blog.

Now we're onto something. So let's take a look at where my local computer thinks it's going, and where the VM thinks it's going. Here's the nslookup result for my local machine, both from my company's DNS server and from Google's 8.8.8.8 server:

Now here's what the VM sees:

Well, now, that is interesting.

From my local computer, sitting in downtown Chicago, both Google and my company's DNS servers point "azure.microsoft.com" to an Azure web site sitting in the North Central U.S. data center, right here in Chicago. But for the VM, which itself is running in the East U.S. data center in southern Virginia, both Microsoft's and Google's DNS servers point the same domain to an Azure web site also within the East U.S. data center.

It looks like both Microsoft and Google are using geographic load-balancing and some clever routing to return DNS addresses based on where the DNS request comes from. I'd bet if I spun up an Azure VM in the U.S. West data center, both would send me to the Azure blog running out there.

This is what massive load balancing looks like from the outside, by the way. If you've put your systems together correctly, users will go to the nearest servers for your content, and they'll never realize it.

Unfortunately, the North Central U.S. instance of the Microsoft Azure blog is down, has been down for several days, and won't come up again until someone at Microsoft realizes it's down. Also, Microsoft makes it practically impossible to notify them that something is broken. So those of us in Chicago will just have to read about Azure on our Azure VMs until someone in Redmond fixes their broken server. I hope they read my blog.

Fake news for no fun but lots of profit

The Daily Currant's business model, explained:

[I]n The New Republic, Luke O'Neil argued that such stories "could do actual damage to political discourse and the media in general... Juicing an already true-enough premise with more unbelievability simply adds to the informational noise pollutionwithout even the expected payoff of a laugh." 

All legitimate gripes, but perhaps that's overthinking it for a site that's the product of under-thinking. The Daily Currant is trying to maximize clicks and shares, and has found a niche between The Onion and real news: all the believability of the latter, but all the libel protections of the former. There's a Catch-22 to this approach, though. As more people have become aware of The Daily Currantin December, Mediaite whined, "Just Stop It, Everyone: Internet Falls for Daily Currant Fake Story Once Again"suckers have become increasingly rare. The site is a victim of its own success.

No matter. The formula is easily replicable, as other web entrepreneurs and hucksters have discovered. This poor imitation of The Onion has itself spawned a legion of poor imitations, websites so devoid of infotainment value and so cynical in their click-baiting that they make the likes of Viral Nova and Upworthy look staid.

The author goes on to compare the Currant to "a potentially lucrative con predicated on exploiting the worst habits of social media driven news content."

Lunchtime reads

I may come back to these again:

Publishing the Inner Drive Extensible Architecture™ to NuGet is still coming up...just not this weekend.

Even Azure requires maintenance

Yesterday I migrated this blog and four other ASP.NET websites from a Windows 2008 Microsoft Azure virtual machine (VM) to a brand-new Windows 2012 R2 VM. I did this because Microsoft has announced the end-of-life for Windows 2008 VMs on June 1st, so I thought I'd get a jump on it.

VMs usually mean never having to say "reinstall." Unfortunately, since this involved upgrading three steps at once, I decided it would be simpler just to launch a new VM and migrate the applications using FTP.

Seven hours and 25 minutes later, everything works, and I've archived the old VM's virtual hard disk (VHD). Why did it take 7:25 to complete?

Forget it. I'm not reliving those hours. I will say only that at least 90 minutes of that time was completely wasted because my AT&T Uverse FiOS line doesn't...quite...make it to my building, limiting it to 1.5 Mbps. Yes, I have a 1.5 Mbps Internet line. While waiting for things to download and upload yesterday, I spoke with them, and they assured me that I have the fastest Uverse service available to me.

Which brings up the other problem with doing so much in Microsoft Azure: you need good Internet connectivity. Which I don't have. Which meant I spent a lot of time yesterday rubbing Parker's belly and cursing AT&T.

Upgrade!

You can't actually see it, but I've upgraded the Microsoft Azure VM that this blog runs on to a brand-spanking-new Windows Server 2012 box.

In fact, it's so transparent, the only purpose of this blog entry is to make sure I can make blog entries.

Seriously, this means absolutely nothing to anyone else. Except that, since Microsoft was going to kill the old VM automatically sometime in June, this is a good thing.