Programming and Technology Related Stuff

BlackBerry Passport in the Wild

I have seen more BlackBerry Passports in the wild than iPhone 6 Pluses. Shocking, I know. To date I have seen five of the 6+ and six Passports.

I make no absolute conclusions about sales based on this entirely anecdotal bit of info. For instance I obviously don’t in any way take this as evidence that the 6+ has sold poorly. Apple’s outstanding sales figures paint a pretty clear picture there, and it was likely obvious to most that the 6+ would sell less than the 6 (at least in North America). And despite me seeing more Passports, I’m of course not in anyway thinking that it has sold better than the 6+; not only is my sample size small, but that’s just crazy talk. However, I do find it interesting and it does make me wonder if that perhaps the Passport has not sold quite as poorly as I thought it would (though the bar was low; I didn’t think it would sell at all). People have actually bought it.

Of course, what you see in the wild depends on where your wild is. Every time I’ve thought about posting some random observation of what phones I see on a day-to-day basis, I’ve felt that I should give context of where I am on a day-to-day basis. I never get around to that, so I usually don’t post, so here I am posting and so here, finally, is my context:

  • Toronto (and likely much of Canada) has for obvious reasons always been somewhat of a BlackBerry stronghold. Classic BlackBerrys were still available from Rogers and I think still even selling up until the BB10 models came out. I know people who held on to old ones waiting for the Q10 (the BB10 with a keyboard) to be released. They’ve clearly been disappearing, but I still saw a huge number of BlackBerry Bolds long after every tech person I read or listened to online (most of whom are from the US) said they were dead and gone from everywhere except maybe businesses. I still see classic BlackBerrys on a somewhat regular basis (saw one this past week).
  • Until a few months ago, I worked in downtown Toronto, in a building that had a few financial related companies. The first BB Passport I saw was in the elevator of the building.
  • I ride the subway to my job (and my old job), which can skew demographics vs those drive and park in the city.

I can’t say for sure what the above points me, but regardless, that’s where I am when I’m seeing phones. I’ll probably refer to the above in any future random phone musings/sightings.

To sum up, I don’t think that the BlackBerry Passport has outsold the iPhone 6+, or that is has even sold well at all, but of the random people I see riding public transit in downtown Toronto, the Passport so far has been as common as the 6+, which I am very surprised by.

So there you have it. Maybe the Passport is only a bit of a flop, not a complete flop.

Just a Minor Patch

So obviously testing is important. That’s not exactly deeply insightful; we all know this. Even the slightest, most unassuming change can have weird effects. We sometime try to forget this and say things like, “That’s such a minor section, it shouldn’t break anything else.” Talk like that is just asked the universe to remind you.

My latest example of this was a minor patch release we were putting out a few months ago. I’m sure you all remember Heartbleed. We had the patched version of OpenSSL quickly available for customers, but after the dust settled we decided it would be best to roll it into a point release of the product and thus have it in all new downloads and installs by default.

This release was quite simple: update the version of OpenSSL included in the Apache bundled with our installer, and change our version number from “a.b.c” to “a.b.d”. As this was just a repackaging of the patch, the updated OpenSSL was even already in use by customers! What could go wrong?

We made the changes and passed the software over to QA. Everything was fine until one of the final tests involving a somewhat uncommon, but certainly not unused, configuration.

The software always checks its version number against the version number stored in the database to see if any db updates need to be installed for the latest version (and will then install any applicable). However under this particular configuration, which allows for a read-only clone of the application (for reasonsTM), the software compares the two versions and simply won’t start unless they are equal.

This seems fine, except that it turns out that upgrading the software only changes the version number in the database when database upgrades are applied, and there weren’t any for this patch release, thus preventing this configuration from running at all after the upgrade.

So we had to dig in and figure out these conflicting behaviours. This was actually the first point release since the db upgraders had been rewritten (which wasn’t that recently, but we don’t do these sorts of patches often), so this interaction hadn’t been caught before. We made some changes and added an “a.b.d” db upgrader, that had no actual executions, figuring that would hit the problem. Strangely it did not. Turns out that there is a race condition in the upgraders (by some crazy design) between the actual updates and the version update, causing the version update to not run unless the updates take some actual execution time. Lovely.

So what was supposed to be the simplest, non-code-changing release, now required either:

  • A rewrite of part of the db upgrades (which could possibly cause all new bugs to a release with next to no allocated dev time/resources)
  • Disabling the read-only configuration version check (also not desirable)
  • Or adding in a db upgrader that did nothing other than pause for a small period of time (a rather hacky solution that could itself be error prone)

Suffice to say the release took a little longer than anticipated.

As I said, obviously testing is important. Had we not run a full regression test cycle, including uncommon configurations, despite everyone thinking that the changes were incredibly minor and that the OpenSSL patch was already being used by customers “in the wild”, we would not have caught this. But then again, as I also said, we all know this. It’s just useful to see the reminder sometimes.

It’s also a good reminder of how time estimates can go sometimes, but that seems like a topic for another post.

You Are in a Legacy Codebase

Been there.

What if It’s Null?

You find odd bits in any code base, especially one of significant age, with a few dozen different developers, that has gone through massive refactoring and redesign.

In fact, you might come across something like this:

    TimeInterval timeout = this.parameters.getSecondsFromParameter("timeout");
    if (timeout != null) {


Which might make you wonder how it works when the timeout is null, since it’s setting it either way. Diving into the setter yields:

public void setTimeout(TimeInterval timeout) {
    if (timeout != null) {
        this.timeout = timeout;

Ah, well that explains it. No bug, but some code smell.

Of course, even in newer applications you can find weirdness, like this:

def starts_with(value, prefix):
    return value.starts_with(prefix)


Reminded of RealPlayer

I have recently been reminded several times of RealPlayer, an application I had pushed far to the back of my mind.

The first was that RealPlayer Cloud now supports the Chromecast. My first reaction was, “RealPlayer still exists. God no!” I had not even known that Real was still in existence.

The second was The Graph That Changed Me, a piece on how RealNetworks profits were almost exclusively tied to their poor/shady practises.

I have not tried RealPlayer Cloud. It could be great. But I’m not going to even give it a glance unless some amazing reviews randomly come across my path (I don’t even care enough to search for reviews). This is how much Real alienated me as a customer over a decade ago. There was a time when RealPlayer was the bane of my internet media existence, as I’m sure it was for many. I suppose I wish them luck, the company and individuals may be very different now, but the name is not going to win them much in my opinion.