Here's a post I put onto the story posted at StackOverflow regarding its sale to Prosus. As of this morning, it's been a day or two and it still hasn't passed moderation. I mean, that's their right, but let's say it doesn't speak well for their willingness to listen. Makes you wonder how many more critical comments are in moderation limbo.

Once this acquisition is complete, we will have more resources and support to grow our public platform and paid products, and we can accelerate our global impact tremendously.

But what ways are you unable to impact the globe now? That is, shouldn't I substitute "impact" with "financial growth" to decode this sentence?

My guess is that StackOverflow is doing exactly what we appreciate it doing right now. That is, THE GROWTH IS OVER. I couldn't care less if you spin out opportunities based on the same codebase in some wholly owned subsidiary that chases cash, but within stackoverflow.com? I can't recall anything changing over the last almost 10 years that's a knock it out of the park, revolutionary advance. And I don't need one!

There are some interesting problems that could use solving at stackoverflow.com, certainly. How do you keep answers fresh when the answers to questions change over time, and old accepts are now objectively wrong? How do you manage moderation to ensure it's not tone deaf (or worse) at times? Maybe even, "How can I pay to get an answer to my question beyond simple point bounties?" That last one is the only one I can think of quickly that increases revenue (and only as a middle banker, not as the primary entity paid) and usefulness of the site.

But growth? What growth? Are the servers crumbling over the load? No. Are there too many low quality answers? Maybe, but it's been reasonably easy to get past the chaff. Do you need a better mobile app for countries with less infrastructure? Well, actually, yes. Yes you do. But beyond that...

Convince me this isn't about the money, or -- and I'll give you a softball here -- even primarily about the money. What is this "impact" primarily about that's not income?

Labels: fail, hats o' money, stackoverflow

Labels: apple, fail, privacy

I've always wondered why Nationals Park doesn't face the Anacostia River, which it sits right beside.

You've seen the Pirates' new stadium, right? It's beautiful. I want to go, even though I live nowhere close to Pittsburgh and the team's, um, not great right now.

Every time I watch a game at Nationals Park I spend at least a few minutes lamenting that I don't have a view anywhere close to as beautiful as the Pirates' even though one is waiting for me behind first base.

Luckily this time googling around I found an answer for this incomprehensible situation at Sports Illustrated.

Spoiler: The answer to all of your questions is money.

During the design phase, the prevailing thought was to face the 41,500-seat stadium — situated on 25 acres in Southeast Washington adjacent to the Navy Yard — toward the Anacostia River​. But Joe Spear, Populous architect and designer of Nationals Park, told SI.com that for Nationals Park to become a success, the neighborhood about three-quarters of a mile from the Capitol needed to be let in.

“The site was selected by the mayor’s office to add value and create value in that neighborhood,” Spear said. “It was a pretty sketchy part of D.C., and they knew (the park) would attract development.”

Spear, having designed Petco Park in San Diego, also knew that the more neighbors were able to see into a ballpark, the more value was being created. Spear told a story of hosting a D.C. contingent in San Diego to meet with then-Padres owner John Moores, who offered up a tour of the stadium, including its view of the surrounding neighborhood.

“The owner of the Padres said, ‘See those buildings? If they can see even a quarter of the playing field, they can add value,’” Spear said. “That was a pretty effective answer to which way we should orient the ballpark.”

[emphasis mine -mfn]

Ugh. So the outfield faces away from the river so that the high rises that have finally been built there would be worth more. 

Who does that benefit? The folks that own the construction companies and the real estate, that's who. Maybe DC if they charge property tax fairly.

Who loses? Everyone who rents in the neighborhood and everyone watching a game, in the park or on TV. The DC area as a whole. The Nats as an organization. Everyone but the real estate big wigs. I've never enjoyed looking at the car park and high rises in the outfield. There's zero DC character there.

I wish there was some way to convince them to poke a hole in the first base line through to the river. It wouldn't be that hard to take out a few seats and expose a beautiful, iconic view. Hire some avant garde architect and tell them to get creative with sections 131-134 and 223-227 (even and odd). I bet we can have view and a good percentage of seats in an unforgettable piece of architecture.

Heck, just take out section 132. I'd rather you take out about three times as much, but let's start small.

There's already an entryway there. Minimal disruption, maximum reward. Heck, some of the high rises would suddenly have a river view too! Market value up! Win-win!

It would turn a concrete monster where you can just barely see the Capitol if you're high enough up in the cheap seats into something that really is a memorable site. You'd lose some great seats, sure, and seats behind the home dugout, but you'd be giving back to everyone else in the stadium.

It's so close.

Labels: DC, fail, hats o' money, nats, Other Stuff

See previous post about too many bad devs running around. It's not brand new. They are and have been everywhere.

From newscientist.com:

Parking meters, cash registers and a professional wrestling video game have fallen foul of a computer glitch related to the Y2K bug.

…

Programmers wanting to avoid the Y2K bug had two broad options: entirely rewrite their code, or adopt a quick fix called “windowing”, which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s. An estimated 80 per cent of computers fixed in 1999 used the quicker, cheaper option.

“Windowing, even during Y2K, was the worst of all possible solutions because it kicked the problem down the road,” says Dylan Mulvin at the London School of Economics.

Because of course they did.

Utility company bills have reportedly been produced with the erroneous date 1920, while tens of thousands of parking meters in New York City have declined credit card transactions because of the date glitch.

Would non-windowing require a deeper refactor? Yes. Should they have done that then? Maybe?

The real question is if the developers let their management know the limitations of the fix, and if the managers told the customers.

Because if there's one thing that's lacking as much as good developer instincts in software development, it's managers who can spell "success".

From the same article:

“Fixing bugs in old legacy systems is a nightmare: it’s spaghetti and nobody who wrote it is still around,” says Paul Lomax, who handled the Y2K bug for Vodafone.

"Old legacy systems" you say? That's where code is spaghetti? Lolls.

What you should say is, "any mature codebase". There are always stupid edge conditions captured in that code, which makes it look less like a useless textbook example that faints at the first site of The Real World (c) MTV and more like something that's doing its job.

There is no clean code in production. I mean, there is, and if you handle your method signatures correctly, there's more in your code than elsewhere, but, um, there's not much idealistically pure, ivory tower type sample code making people money. And if there is, it's about to let them down in some serious-yet-unexpected way.

Related..., if you wrote the preceding blog entry in Markdown:

Adding support for a strikethrough syntax is a longstanding request for Markdown, but I omitted it by design. For one thing, there is no good punctuation to represent strikethrough. Tildes don’t look like strikethrough at all — tildes are squiggly, but a strike is a straight line. 

You know what doesn't look like a strikethrough at all, John? <strike></strike> ;^D

Labels: developers, development, fail, markdown

Labels: business, fail, podcast, start-up

If, for example, you knew that the file had bob somewhere in the file, you would type:

dir *bob*.* /s

Labels: cmd, fail, noteToSelf, windows

Samsung previously explained the problem by noting that the ultrasonic fingerprint was mistakenly “recognizing 3-dimensional patterns appearing on certain silicone screen protecting cases as users’ fingerprints.” As a temporary solution, Samsung recommends that users either remove the problematic screen protectors in question and reregister their prints or use a different authentication method (like a regular password) until the patch is released.

Labels: fail, samsung

Labels: advertising, fail, privacy

From nytimes.com:

If there were a Mount Rushmore of Lakers basketball, the visages of West, Johnson and Bryant would be chiseled onto it.

Seems like they're missing one. Just going to leave this right here.

Or maybe this one. Seems they're talking about some animal in the NBA called a GOAT.

Strangely, only one of the Times' three Laker Rushmore candidates is up there, well, up there with Kareem.

I mean, seriously? Kobe before Kareem? You're kidding me, right?

Labels: fail, NBA, nyt, Other Stuff

Something tells me this wasn't an official use case.

I guess I'm missing the real story here -- somebody thought to ensure "negative" time values are reported with the word "ago" appended to them.

Labels: fail, testing, windows

If there's one often-overlooked feature in Windows that I really enjoy using, it's the "Cascade all windows" feature for the taskbar.

I've been told -- unprovoked, so you know it's bad -- that I tend to have a lot of windows open when I'm working. It's true. I do. And when it's time to clean them all up, it's nice not to have to declare "windows management bankruptcy" and close everything I have open in an app before closing it out.

To dodge this, you can hold down shift as you right-click a taskbar icon, and select the option from this menu:

Well, often you can do this and quickly go through whatever the app has open. What Chrome does is less than particularly helpful.

It's hard to see there, but you can't read any window titles other than the very first one. You can click the image to make it full-sized. What's displayed sort of gives you an idea of how much you're going to have to sift though, but it's otherwise not insanely helpful.

Here it is, up close.

I can tell my order has shipped in the front window, and how many tabs I have open in the other five, but that's it. Done.

Look at what Edge does.

It's a little hard to see the details in the picture, but you can get a feeling of how absolutely beautiful (and by "beautiful", like any good engineer, I mean "practical" and "useful") that is. I can see every window, every tab, every title. Now I can quickly hit the X at the top right to close any window I'm done using & that needs to go away.

Here's what Edge shows when "cascaded", zoomed in.

Being a good resident

Edge gets Windows. You might say you're not surprised, but what is surprising is how badly Chrome flubs it. I mean, I understand the, "They even use Material Design on iOS, man!" argument, but I'm not buying that doing so requires that you be a bad Windows resident.

Edge looks distinctly different from Internet Explorer, for instance. You've got plenty of leeway before you lose your design language, so to speak. And even though Apple, for instance, completely ignored all the good Windows resident requests with iTunes and WinSafari, two wrongs don't make a right.

In short, it's not that hard to push the titles up into all of that dead white space in Chrome.

Why not use that for displaying real information, even if there wasn't the option to cascade windows? And since there is, well, let's just say that it's a horribly efficient, beautiful thing when the title bar/browser tabs are done right.

Labels: chrome, coding, design, edge, fail, style, windows

Don't you hate it when you get a call from whatever buried bureaucracy it is that you need to reach and agreement with today -- legal, customer service, health insurance, whatever -- and you get someone who is actively unhelpful? Where they give you some party line, and if you have more questions, they get uncomfortably agitated?

Drives me crazy. I had a question today with someone about taxes and credits who was a government worker, and she initially gave me the, "I was contacted by X and have asked your question, as relayed by X, to Y. Y's answer to X's question is Z. The end," spiel.

You already know it's going to be a bad day. There's at least three levels of plausible deniability already. Maybe that's the wrong phrase. Three levels of pass-the-buck-ability?

"That's not what I was asking, exactly," is usually followed with, "That's what X told me your question was." /sigh I think I might be the subject expert on this issue. (And, in this case, X had my question down pat, so either there was a communication problem from X to this person, call them B, or B wasn't trying really hard, which I feel is the case here.)

Or, "My question is really A," which bags, "I will forward your question to Y." Why in the world would I want B to poorly translate another Q & A, this time from Y, to me in a week?

Of course I want a little more than a powerless go-between -- as that's how they're actively positioning themselves. That's what bureaucracy is. Lines of incompetence between the parties looking for action or, in cases like this, likely inaction. It's like a rebate.

I want to be able to say, "I understand that you're answering what you thought I was asking after speaking with X -- let's call that question X₁. That's not precisely the question. I'm really asking about X₂ [with a short explanation]. Does that make sense? Can you see how X₁ is different than X₂?" and get an answer in the affirmative.

Because otherwise we're going to be playing The Telephone Game, literal and figurative, all over again when you relay question X₃ to Y, and we'll be stuck in this conversation all over again.

And these bureaucracy folks all too often refuse to listen to what you're saying, because they feel if they say they understand X₂, that means they're saying X₂ is okay or right, and they must feel even hinting that someone's got a point can cause them trouble in their own job. That's not what's at issue at all. You're just helping me be more confident you're going to relay the right question to Y so that we're not doing this dance again.

I don't need a written reply to X₁ or X₃. I need to talk to Y about X₂ and get that down in an email or doc. If you ask that question as a devil's advocate, which requires understanding exactly where I'm coming from, that's perfect. But if you can't -- and if you say X₂ doesn't make sense to you, you can't -- please step aside so we don't waste any more of X or Y's (or your or my own) time.

Sound good? /sigh Sorry. Vent over.

Labels: fail, Other Stuff

Labels: apple, fail, iTunes

Note to self: Never create images for documentation until you're done with your release. No, no no. ALL the way done with your release. I thought I could "get started" on my docs a little early, so I did. Not the worst idea ever, but I recently added a new toolbar button or two. I got lucky, I think, and can use my old images, like this one:

... since it's so tiny you can barely see what's in the toolbars. But if it'd shown one extra in the bottom or all of the top, I'd be remaking them now.

See that header button way over on the right? That's new.

And then for some strange reason I put the "Find" button on the bottom. Argh. That was close.

I won't say anything about that tab close "X" in the first image next to the "New 0" file tab. Except that if you'd been reading, you'd know I just added that. That may or may have been retroactively added to the original image. Ms. Paint, indeed.

Labels: fail, images, indie, markupdown, paint

Tried to update an app from the Windows App store.

So that was useful.

Labels: design, fail, windows

Labels: bitbucket, fail, UI

This page about Firefox claims:

Location-Aware Browsing is always opt-in in Firefox. No location information is ever sent without your permission. [emphasis mine, of course]

That's so not Scottish, it's crap.

In case you think I'm overstating, or screwed something up, here's my full Firefox history (full disclosure: I've erased about 12 pages between "Internet for people, not profit" and the Yahoo search for AAA that'd tell you what bank I use):

I can tell you, I haven't opted in to giving out my location everywhere in those pages.

And when we check about:config, it's turned on anyhow.

Explain that, Mr. Mozilla Privacy is Job 1.

(In other news, AAA still uses WebObjects.)

EDIT: Run the EFF's Panopticlick page now. I always kinda wondered about this (if you get all my browser metadata, you'll kinda know who I am, won't you?), but it's scary to see it in practice.

Even worse is learning about this canvas fingerprinting, which is a much more specifically identifying source of metadata that I had no clue existed. /sigh

They know exactly who you are.

Labels: fail, firefox, geolocation, privacy

Gruber weighs in on the rumored iTunes reboot:

What do you see when you open the Spotify or Pandora apps? Just the streaming music you have access to. That makes them less complicated, by definition. “Everything you see is in the cloud, and you have access to it because you are a subscriber” is easy to understand. “Some of this is in the cloud, some of this you own” is more complicated.

He's joining a reasonably long list of Apple pundits with the request to split Apple Music into its own app, the most recent I can think of offhand was Jared Sinclair, whose step two of four ways to reorg Music was, "Bye, Bye, iPod - Break out all the legacy iPod features into another app."

The worst part is that, sort of like the Big Jennifer Null stuff I've mentioned recently, the iTunes confusion really was preventable.

Gruber leaves the door open on the preventable part, saying,

Maybe there’s a way to design “all your music in one app” that is completely clear, convenient, and obvious.

The four sets of Apple Music

Well, the idea Apple had was bang on. It shouldn't matter where your music lives, you should be able to sync it all. There are really only four sets of music files from iTunes' perspective:

1. Files that you brought to Apple music (no DRM)
2. Files Apple thinks it's matched from 1.) on another of your devices (no DRM)
3. Files Apple didn't match from 1.) and allows you to copy to your other devices via their cloud (no DRM)
   • This is really another version of 1, just copied to a new device.
4. Files you've only ever gotten from an Apple Music subscription (DRM)

Apple should keep 1.) around like those files are gold. Never let the user whack those without going through some sort of "locked button with cover" removal process. As Jason Snell points out, there's a real UI issue here, but also a serious functional one. "Remove download" should never throw your original files in the trash. Warn that those are files that you brought to Apple Music, and that deleting them will irrevocably remove the originals. And even then, after they're deleted, make sure users can redownload matched versions at the worst, if they were matched, without DRM, until their subscription lapses. Better is to immediately create a backup of that original file, though I realize there are cases where the user might really rather that original disappear immediately.

Files from 2.) should similarly always be downloaded without DRM. There should also be the possibility of saying, "That's a bad match; give me my original file." Maybe in version two you let the user pick from other possible matches, and then you cloud source the right matches after you get a better idea what goes where.

Files from 3.) are pretty simple. You didn't match 'em, so you let folks copy them anywhere they are logged into iTunes. It's pretty much what Dropbox does.

For the fourth, well, the only real gotcha is when they really do match something from 1.), and Apple mismatched it. But then you've already got both files. If someone tries to delete their original because it's now "duplicated", you should send them through that "locked button cover" process, and possibly have a, "duplicate match" reason there. Then you should delete the file from 4, not 1.

Note that there's another category that we're going to ignore to make things simpler -- things that should be matches that aren't matched. I'd provide a mechanism to say when something's mismatched, but if there isn't a match found and should've been, having the original file from 1.) on another machine isn't too bad. That is, there's Category 5: Things Apple should've matched with AACs they have on file and didn't. Instead of providing a way to say so in order that you get more 2.), just leave them in Category 3 until you get everything else straight. That often happens now, and it's fine.

When your Apple Music subscription lapses, you should probably also be given a final download session (that could take weeks to finish), possibly even on more than one device. "Your Apple Music subscription has ended. Would you like to download your matched and/or original files that are currently missing on this Mac/PC?"

Notice that the first three categories make up iTunes Match.

iTunes Match should've let Apple know that they weren't doing a great job of providing its eponymous function -- matching -- and they really needed to make sure they could get 1.), 2.), & 3.) right before going whole hog into a unified Apple Music. But it's still just a database management problem. They "simply" should have been much more defensive with Apple Music for when matching failed. If your user doesn't have a file three places, don't delete it.

But as long as you have a space for a flag on each file to say which it is -- an unDRM'd original*, an unDRM'd "likely match", or a DRM'd file that's never been matched -- you don't have this trouble.

It takes some great QA, but it's a straightforward, at worst tedious, process. I could make such a system without the issues Apple's seen in, let's say, six months, and I could recommend a good five or so folks that could as well.

• "UnDRM'd" could also included files purchased before iTunes removed DRM.

Labels: apple fail, Apple Music, coding, fail, gruber, iTunes, qa, rdbms

So here I am, happily streaming songs from Prime via Amazon Music, when I hear a song from Garbage I know (#1 Crush*). I know this isn't in my favorites playlist on iTunes. Why not?

I check, and sure enough, it's a B-side, and I haven't shelled out for the Garbage 20th Anniversary Super Deluxe edition. ;^) So let's see if I can just buy the single file to "add" to my plain wayne version of Garbage (the album).

Search a little, and...

Nothing. I tried a few other options, and still nothing. Lots of crush, not so much crush from Garbage. That's interesting.

Surely (Shirley?) they have the song, right?

Yes they do. And now I'm previewing it. (See it, down there at #18?)

This is as bad as the "Big Jennifer Null" problem I blogged about a while back. THIS IS NOT LITTLE BOBBY TABLES. It'd be bad enough if it was, as even "real" SQL injection should be caught by anyone worth their salt these days. But not being able to search for special characters? No, past that, not being to able to find a title that contains special characters? That's just sad. Unforgivably sad.

It's not difficult to search for a string that begins with "#", dang it. Grow up, Apple. I'm dying to fix this. Please let me fix this. As I said before about J-Null, this isn't Little Bobby Tables. This is stoooopid.

Insult to injury? When I started writing this, iTunes decided it'd take 23.7% of my CPU. I'd noticed Garbage had a new release, and was on that page, doing nothing. Not playing any music on a page without even a rotating photo carousel (thanks a lot, Draper) takes 23.7% of my CPU.

Fail, Apple. That's a huge fail.

* Ha, I can't even make an affiliate link to #1 Crush.

Pro tip: Do not search for "Hooper Mix" on the affiliate link tool for the iTunes Music Store. Borderline NSFW. Thanks again, Apple.

Labels: apple fail, coding, fail, iTunes, SQL

Caught this gem from the BBC via Michael Tsai's blog:

“We moved almost immediately after we got married so it came up practically as soon as I changed my name, buying plane tickets,” she says. When Jennifer Null tries to buy a plane ticket, she gets an error message on most websites. The site will say she has left the surname field blank and ask her to try again.

Instead, she has to call the airline company by phone to book a ticket – but that’s not the end of the process.

“I've been asked why I'm calling and when I try to explain the situation, I've been told, ‘there's no way that's true’,” she says.

Sorry to say I pulled a legitimate LOL as soon as I read her last name. Ouch.

But my reaction? Gosh, which websites and what horrible programmers? I mean, even if you're a two-equals coder (you should use three, natch) in JavaScript, the weakest place I could think of off-hand, null != "null", and you've got no problem.

And...

INSERT INTO Users (Name) VALUES ('Null') -- (as the result of a parameterized query)

... screwed up nobody ever. Which leads me to say...

This is not Little Bobby Tables.

This is stoopid.

We're all stoopid sometimes, but that's what this is. It's stoopid.

???

After a little more digging...

Seems I ran through the same steps in my head as the SO post the BBC includes, but the answer seemed obvious; this is the "worst case" I could think of going in...

The only reasonable workaround I can think of, short of fixing this bug in every damn version of ActionScript, is to test fields for "null" and escape them as CDATA values.

Well, duh. Though extend my sympathy for those who have a legacy system that still uses XML, not JSON. ;^)

What this really shows is...

• There's waaaaaaay too much NIH syndrome in the enterprise
• We're exceptionally bad at creating test cases
• We need more imaginative coders.

If the name "Null" is still an issue three to six months from now, SHAME. No, ALL CAPS SHAME. FOR REAL. Horrible.

Wow. Seriously, I'm embarrassed for the profession. At worst, you needed to see why your client-side was "letting through" names that were empty so far that they got serialized to XML. Does nobody check the logs? Or are your logs so chatty you wouldn't see this error?

/facepalm

Labels: coding, fail, SQL