4/26/2011

New gesture video for BlackBerry PlayBook

If you've ever tried a BlackBerry PlayBook, you'll agree that it's one heck of a multi-tasking machine. Mind you, that should come as no surprise. After all, the PlayBook's underlying QNX Neutrino OS has supported multi-tasking since the early 1980s and symmetric multiprocessing (SMP) since the late 1990s.

Still, a true multi-tasking tablet can't simply process multiple tasks all at once. It must also allow the user to interact with those multiple tasks in a fluid, intuitive manner. And that's where the advanced gestures of the BlackBerry PlayBook come into play.

Recently, a couple of my QNX colleagues put together a video to show how those gestures can help you make the best use of the PlayBook. So, without further ado, roll the tape:


 

4/21/2011

Ellen Degeneres doles out 400 BlackBerry Playbooks

Okay, this one's just for fun.

On April 19, the executive producer for the Ellen Degeneres show traded in his laptop for a BlackBerry PlayBook, and proceeded to use the PlayBook to read out tweets from the show's viewers. The studio audience goes nuts (jump to 4:15 mark) when Ellen announces that she is giving them all a free PlayBook.


 

4/17/2011

Critter of the week: House cat

Hey, have you ever wondered how cats manage to stay healthy even though they don't eat fruits and vegetables? Of course you haven't. But now that I've raised the question, I'm sure you're dying to know.

Well, I'm no expert in cat physiology, but here's one reason cats survive without fruit smoothies: They manufacture their own Vitamin C. Neat, huh?

Now that we've got that out of the way, back to the world of cars, tablets, and other cool stuff. But before you go, check out this photo I took of a friend's cat a few months ago. Behind that (seemingly) menacing stare is probably the gentlest kitty you've ever met:



Have a great week.

4/13/2011

The tablet PC, then and now

It was billed as the "portable web browsing device that could enable mass adoption of Internet access." So okay, they got that part wrong. In any case, the NatSemi WebPAD offered a tantalizing hint of things to come.

It was, first of all, a hand-holdable tablet, albeit a bulky one by today's standards. And sure enough, it let you surf wirelessly via a 2.4 GHz base station. But despite these capabilities, it was doomed to fail — not because it was deficient, but because it was ahead of its time.

You see, the WebPAD made its debut in 1998, long before Facebook, Twitter, and YouTube came on the scene. There was no social media, no Web 2.0, no eBay, no Wi-Fi hotspots, and few broadband connections. By today's standards, the web could be defined by what it lacked. So while something like a wireless tablet was extremely cool, it wasn't compelling as a consumer product. There was only so much you could do with it.

Fast-forward to 2011. The challenge of building a tablet has changed radically. In 1998, NatSemi built a tablet and hoped the web would catch up. Now, the web is rich beyond measure and needs an extremely powerful tablet to take full advantage of it. If you've seen videos of the BlackBerry PlayBook's web fidelity, wicked-fast multitasking, or HD video, you know what I'm talking about.

More to the point, the web really has caught up. As a result, the tablet concept, which was simply cool in 1998, has become simply huge in 2011. So, hats off to the folks who pioneered the concept so many years ago. And kudos to my many colleagues at QNX and RIM who are transforming that concept into a thing of beauty. Consider me blown away.
 

4/10/2011

New focus group aims to cut down driver distraction

A few years ago, I read about a town plagued by a growing beaver population. People were worried, quite justifiably, about the damage the rodents might inflict on the local landscape. After all, beavers can quickly denude an area of trees and cause considerable flooding. But here's the part that stopped me in my tracks: A local politician cum self-appointed safety officer expressed the concern that townspeople would fall on the pointy tree stumps and grievously hurt themselves.

I kid you not.

Clearly, it didn't matter to this person that, in all of history, there probably isn't a single case of someone fatally impaling himself on a beaver stump. And it didn't matter that the probability of actually falling on a beaver stump is about the same as having a meteoroid bonk you on the head. I mean, why worry about such details when beaver stumps are so patently evil?

The fact is, a disconnect often exists between perceived danger and real danger. For instance, many people worry that the increased use of microelectronics, mobile devices, and software in cars will drive up driver distraction. And, of course, they have a point, provided these technologies are deployed incorrectly or used irresponsibly. Problem is, people fail to realize that, properly implemented, these technologies can help reduce distraction and make us safer drivers. Imagine that.

Fortunately, my colleague Scott Pennock is doing more than just imagining. He has just been appointed chair of a spanking new ITU-T focus group on driver distraction, established last month in Geneva.

The group has a clear objective: to reduce injuries and fatalities by minimizing the cognitive demands associated with both driving and non-driving tasks. To achieve that goal, the group will work collaboratively with standards organizations, governments, academia, and industry.

The group's activities will run the gamut: from proposing reliability and transmission performance requirements for automotive services, to investigating information flow in the automotive cockpit, to identifying new techniques that can reduce the driver’s cognitive load.

I plan to keep a close watch on the group's progress and keep you posted on its progress. Stay tuned.
 

4/05/2011

Whitepaper: Building functional safety into complex software systems, Part II

Recently, our local town councillor called a neighborhood meeting to discuss the construction of a new apartment building at the top of my street. Halfway through the meeting, one of my neighbors stood up and made this demand:

    “I want a 100% guarantee that the blasting required for this project won’t damage the foundation of my house.”

Let’s face it. When it comes to anything that could threaten our property, our family, or our health, we all want a 100% guarantee. Problem is, the one constant in life is that there are no absolute guarantees.

This rule applies to software as much as to anything else. Just try to create a software system that is both reasonably useful and absolutely dependable. It’s well-nigh impossible. Unfortunately, the same rule also applies to software validation methods: no method is absolutely foolproof. The more complex a software system becomes, the more this rule applies.

A difficult pill to swallow? You bet. But acknowledging it is key to designing a system that successfully achieves functional safety.

Which brings me to Chris Hobbs’ latest paper, “Building Functional Safety into Complex Software Systems, Part II.” For Chris, functional safety must be built into a software system from day one. Moreover, all work should follow from the premise that software always contains faults and that these faults may lead to failures. We must, as a result, include multiple lines of defense when designing a system:

  • isolate safety-critical processes
  • reduce faults
  • prevent faults from becoming errors
  • prevent errors from becoming failures


  • All this begins with the best available expertise and a crystal-clear definition of the system’s dependability requirements — what Chris refers to as “sufficient dependability.” This definition is essential: It not only provides an accurate measure for validating the system’s functional safety, but also eliminates vague (and therefore meaningless) requirements.

    We must also follow rigorous standards and practices throughout the system design and development, and implement a comprehensive validation program that includes not only traditional state-based testing at the module level, but also statistical testing and design verification.

    I’m just scratching the surface of Chris’s paper. For the full story, download the paper here.