All posts by Peter Mangiafico

Doh! Apple

Public service announcement: if you have an iPad or iPhone, please update it now while on a safe wifi network (i.e. yours). If you have Mac running 10.9, use Chrome or Firefox until Apple releases a patch and always be careful on public wifi. If you are running Windows or Linux, it is your turn to gloat. There is a pretty nasty security flaw in OS X 10.9 that is still not fixed and affects Safari, Mail and other Apple apps. If you’re a software developer, read about the absolute ridiculously stupid coding mistake that is causing the problems:http://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/

Three year old –> English Translator

When you are talking to a three year old, use this handy guide to understand what they mean:

  • “I’m tired and hunrgy” = “I’m bored”
  • “But I’m not hungry” = “I don’t want my dinner but I’d be happy to have some dessert.”
  • “I’m not tired” = “I am exhausted”
  • “Just one more book” = “Please read me all of the books in my room”
  • “I’ve already brushed my teeth” = “I am too busy playing to brush my teeth”
  • “But I’m going to wash my hands!!!!!” = “Now that you’ve told me for the tenth time to wash my hands, I will finally do it while screaming at you not to tell me again.”

 

The Downsides of Embedded Software

As a software engineer, I should welcome the increasing penetration of software into more and more everyday devices.  But as a consumer, it’s easy to spot the obvious downsides.

Physical and mechanical connections don’t crash or have bugs.  They usually work well and when they do fail, you can sometimes open up the device to figure out what’s going on (wire came unsoldered, gear broke, etc.).

Embedded software, when written well, is great.  There are a lot of software focused companies that write good software.  The problem is that most hardware companies now have embedded software.  And these companies are not software companies, and they tend to write buggy software, or software with poor user experiences.

These are just a couple examples from our daily life:

  • Our clock radio made by iLuv sometimes crashes when you drop an iPhone into the dock.  This requires “rebooting” the clock radio by unplugging and plugging it back in.  In it’s crashed state, it still shows the time, just frozen at the time of crash.  It also inexplicably continues to play while crashed – the UI is just frozen.  Solution: debug your software.
  • Our Toyota Prius radio system has a physical volume knob – but it’s fly-by-wire.  When you start the car, the radio plays at the volume it was last set at (just like an old school radio).  The problem is, this might have been pretty loud, and twirling the knob down has no effect until the audio system has ‘booted up’, which takes several seconds.  This means you get to listen to a very loud radio while looking at the Toyota logo on your audio screen.  Two solutions: (a) don’t start the actual audio until the user has control over the volume, and (b) allow the user to set a maximum volume at startup, so they won’t get blasted when starting the car.
  • The Prius also has a fly-by-wire shift knob.  More than once, I’ve put it in reverse before the electronics are fully booted.  But unlike a normal car, the Prius does not actually get engaged into any gear unless you are fully booted up.  I do like the Prius, but I still don’t like that behavior.  Our other car is a manual transmission, and there is something deeply satisfying about feeling the mechanical connection between the gears and knowing the whole thing can be done without any electronics.  I have no idea how you’d push a Prius off the road if the electronics system was down. Can you even put it in neutral without booting up?

Let’s just hope that hardware companies bet better at writing software.  A crashed clock radio is one problem, but once software controls items that our lives depend on, you don’t want a crash to lead to a crash.