The Daily Parker

Politics, Weather, Photography, and the Dog


Whatever I've been fighting the past few days is taking a really good whack at me today. I may post more substantially later; right now, not so much.

Saturday, though, I had five hours of Bach, and it rocked, as much as a harpsichord, piano, and organ can rock.

1.07 mass shootings per day

Welcome to the Shining Beacon on a Hill, the example to the rest of the world, where we've had 294 mass shootings in 274 days so far this year:

We've gone no more than eight days without one of these incidents this year. On six days in September, there were 3 mass shootings or more. If the initial casualty figures in Oregon hold up, that would bring the total of deaths by mass shooting this year to 380 so far, with well over one thousand injured.

And of course, there's the broader universe of nearly 10,000 people killed and 20,000 wounded in nearly 40,000 gun violence incidents so far this year.

This is the United States, where a group dedicated to selling guns has successfully captured firearms regulations, subverted a Constitutional protection for states (not individuals) against central government over-reach, and shut down rational argument on the merits of having this much firepower available to this many people for this long.

The Internet self-corrects (sort of)

Canadian Julia Cordray created an app described as a "Yelp for people," and apparently failed to predict the future:

Except of course it took the rest of the world about two seconds to figure out that filtering the world to only include those with positive feelings was not exactly realistic, and all the app was likely to do was invite an endless stream of abuse, bullying, and stalking.

It wasn't long before people were posting Cordray's personal details online – seemingly culled from the Whois information for domain names she owns. Just to highlight how out of control these things can get, one heavily quoted tweet providing her phone number and home address actually provided the wrong information.

Meanwhile, the company's website at has fallen over.

We'll have this app, of course. I'm interested to see how U.S. and U.K. libel laws deal with it. Or not.

Update: Just looking at their Facebook page, I can't help but wonder if this is just a parody. But no, these women are delusional, and their app is not a new idea—just one that no one before them has ever had the immorality to produce.

Sadly, I think it will be a success.

So kludgy

I noted earlier that this code base I'm working with assumes all file stores look like a disk-based file system. This has forced me to do something totally ugly.

All requests for files get pre-pended with a hard-coded string somewhere in the base classes—i.e., the crap I didn't write. So when I want to use the Azure storage container "myfiles", some (but not all) requests for files will use ~/App_Data/files/myfiles (or whatever is configured) as the container name. Therefore, the Azure provider has to sniff every incoming request and remove ~/App_Data/files/ or the calls fail.

Don't even get me started on how the code assumes HttpContext.Current will exist. That has made unit testing a whole new brand of FFS.

Assumptions in your code may cause annoyance (wonky)

I've been playing around with BlogEngine.NET, and I've hit a snag making it work with Microsoft Azure.

BlogEngine.NET was built to store files inside the application's own file system. So if you install the engine in, say, c:\inetpub\wwwroot\blogEngine, by default the files will be in ~/App_Data/files, which maps to c:\inetpub\wwwroot\blogEngine\App_Data\files. All of the file-handling code, even the abstractions, assume that your files will have some kind of file name that looks like that.

You must never store files locally in an Azure cloud service, because at any moment your virtual machine could blow up and be reconstituted from its image. Boom. There go your files.

You really want to use Azure storage. In its purest form, Azure storage organizes files in containers. A container can't have sub-containers. You access a container by its name only; paths are meaningless.

But because BlogEngine.NET assumes that all file stores use path names (which even works for the database file store plug-in, for reasons I don't want to go into), creating an Azure Storage provider for this thing has been really annoying. I've even had to modify some of the core files because I discovered that it applied a default path to any file request no matter what storage provider you used.

Don't even get me started on the bit of BlogEngine.NET's architecture that pulls all files around through the UI instead of allowing them to live in a CDN...