Ones and Zeros

I tried the iPad with the ForeFlight app for charts, plates, and airport information on a recent IFR flight.  ForeFlight is an app that for $75/year subscription will supply you with all the charts, plates, and airport information cached on your iPad.  This post is a review of a flight I did with the iPad/ForeFlight combination for charts and plates.

I took an IFR flight that happened to be to CHO from JYO, the return was via OHM.  I was either in the clouds or on top of them for the majority of the flight.  I did my pre-flight brief and filed my flight plan with FF (the iPad/ForeFlight combo).

The brief worked well, the usual DUATS information was broken into separate sections in a table view.  I needed to tap on a section to read it, then tap the back button, and tap the next section I wanted to see.  I would have liked a “next” button to tap on, it would have been smoother.  Not a major issue though, but a “nice to see”.

The flight plan was there in ATC when I called in - so that worked.  I set FF to show my flight plan (that I’d entered in earlier in planning) on the low-enroute chart.  I could have selected high-enroute or a sectional/TAC.  When the iPad has cell reception, I can get radar, satellite, current conditions, etc.

I have the Apple iPad case which has a kind of microfiber coating, it doesn’t want to slide off my knee and stays more stable than my paper charts did.  FF tracked my position, heading, and altitude and showed me a moving map of where I was on the chart and with respect to my flight plan.  The icon that FF used for my plane looks like a larger plane - might be cool thing to be able to change that.

Coming out of JYO the first waypoint is STILL, but ATC turns you before that which I appreciated.  I ended up on radar vectors to CSN, my next waypoint.  I found that the usual buttonology management of the panel GPS was doubled as I had to mess with FF as well.

After CSN instead of going to WITTO, I was redirected to KENNI for the ILS.  More buttonology.  I kept wanting to tap on the airport on the map screen to bring up the airport information.  The approach plates are listed with the airport information in FF.  To get from the chart to the airport the easier way is to 1) make sure the flight plan is showing (tap the flight plan button on the chart screen if not), 2) scroll if necessary to show the airport on the flight plan, 3) tap the airport code on the flight plan.

I’d prefer to just tap the airport on the chart screen.  I can do that for VORs, NDBs, airports, fixes and arbitrary locations to add to my route.  But I can’t get to the airport screen that way.  This was the worst issue I had with FF.

When I broke out at the top of the clouds on the way down to CHO, and even in the clouds, I had a big glare problem with the iPad screen.  I prefer to buy matte screens, but the iPad doesn’t come with one.  While a glossy screen is brighter, it also reflects much more easily creating glare problems.  And with my sunglasses (yes, I had to wear sunglasses in a cloud, it was that bright) the screen wasn’t visible at all.

I found out later that my polarized sunglasses lined up with the iPad polarization in the vertical position to block the screen view.  That’s my problem, but in any case the glare is an issue.  I’m going to look into a covering for the screen to reduce glare.

The battery life was great.  After my leisurely flight planning and preflight brief, a return flight planning and brief, and a 2.7 hour flight, I’d used just half the battery capacity.  More than enough for my purposes, especially since charging is fast.  You can also get a car charger cable for in-flight use too.

I found the iPad/FF combination was, aside from the issues above, very usable.  I need to practice the buttonology, and I hope ForeFlight adds a direct way from the chart to the airport screen.  But there are some things I liked better: Everything was there and available.  The iPad stayed put more easily that paper charts and plates.  And it’s cheaper than paper charts.  I didn’t have the heat shutdown problem that some have reported, and I don’t fly high enough to cause problems with the GPS.

Ah.  That’s the problem.  I’ve been chasing a bug lately, it works fine in the sim but the feature doesn’t work on the iPhone. Turns out the simulator isn’t a perfect simulation.  We all know about the obvious stuff: no GPS for example.  But on application termination with iOS 4 there’s a little detail that can be important:An app exits on the simulator by first calling first applicationWillResignActive then calling applicationDidEnterBackground on the application’s delegate.But on the phone, we get first applicationDidEnterBackground, then applicationWillTerminate. In both cases this is when the home button is pressed. If you kill the app with the debugger then it’s just killed and none of these gets called at all.This isn’t a big deal till you’ve got some data that you want the app’s delegate to save when the app goes background or is quitting.  This is also one of the behaviors that changes in iOS4 too with the advent of multitasking.  Unfortunately the Apple docs on the application delegate don’t go into the order the delegate calls are made, nor the variations between the sim and phone.And, since the test phone is a 3G, it may behave differently on a multitasking phone like a 3GS or 4 model.Sometimes, testing is the only way to find out what really happens.

Cory Doctorow and Joel Johnson are debating the closed vs open source issue with respect to the Apple iPad and the Apple software ecosystem.  Cory says he’s not buying an iPad and he doesn’t think anyone should.  That we shouldn’t buy devices that force us only to be consumers, we need to buy products that let us take them apart, customize them, and fix them.  For computers like the iPad, this means to write software outside the DRM box as well.

Joel, on the other hand, points out here that computers becoming consumer appliances is a good thing.  That we don’t want to have to tinker with everything we buy and use, that just being able to use something efficiently and cleanly is a wonderful thing to do.  And that for complex devices, locking the design and internal access down is one way to do that.  Cory and Joel both are making the issues clear so people have a better chance at choosing the techno-ecosystem they want to play with.

They’re both right in a way.  Cory and Joel both are making the issues clear so people have a better chance at choosing the techno-ecosystem they want to play with. We have to make our choices as to what we’re willing to live with.  Apple’s created an ecosystem that’s much larger than the device.  That they’re able to do this in a closed way is impressive. I’ve discussed that before.  When you buy an iPad, iPhone, or iPod you’re buying into that ecosystem.  As a consumer that may be worth it to you, it is to Joel.  It’s not worth it to Cory.  And as a developer there are rules that I have to follow to play in that system too.

But there are rules for consumers and developers in the open source ecosystem too.  Those rules are  unwritten social rules perhaps, or ways of working dictated by the nature of open source projects: installation, updates, system management.  In the end the finished open source product typically requires more tinkering than many would like to see simply because there’s no overriding corporate authority driving a more unified approach.  (I’ve used Linux since the mid-1990s, written software for it, and written a kernel mod (a driver).  I like it and it’s great for my purposes, but requires tinkering.) Those open source rules more reached more collectively than the Apple ones, but as an independent developer I have as much effect on them as I do on Apple’s rules generally.

Basically, you have to decide what you want to deal with.  Sometimes I choose ease-of-use and pay the DRM penalty, sometimes I choose open-source and pay the tinkering penalty.  Trying to use either one for everything would be like trying to use a hammer in place of every tool in my tool box.

In this post Clay Shirky discusses the collapse of complex business models and Tainter’s book The Collapse of Complex Societies.

…a group of people, through a combination of social organization and environmental luck, finds itself with a surplus of resources. Managing this surplus makes society more complex—agriculture rewards mathematical skill, granaries require new forms of construction, and so on.

Early on, the marginal value of this complexity is positive—each additional bit of complexity more than pays for itself in improved output—but over time, the law of diminishing returns reduces the marginal value, until it disappears completely. At this point, any additional complexity is pure cost.

….

When the value of complexity turns negative, a society plagued by an inability to react remains as complex as ever, right up to the moment where it becomes suddenly and dramatically simpler, which is to say right up to the moment of collapse. Collapse is simply the last remaining method of simplification.

As Shirky points out in his post, the same thing can happen in business.  I believe something similar can happen with any over complex structure such as some software projects.  The FAA famously killed their modernization project in the late 1980’s due to this.  Way back in 1975 Fred Brooks in his book The Mythical Man-Month observed, “Adding people to a late project only makes it later.”  In reference to theoretical physics Einstein said, “Everything should be made as simple as possible, but not simpler.”  Sounds like good advice in general.

The study of failed software projects and systems should be part of our standard training for a software engineer.  In aviation accident analysis is an important area of study and civil engineers also do this.  I’m not the only pilot who’s read years of NTSB reports.  However in software we have nothing similar.  Fred Brooks’s book is a good start; it’s a classic.   But due to corporate embarassement and proprietary property issues, there’s no similar study in software engineering.

This lack forces us individually to replicate all of our predecessors mistakes.  The progress of our field suffers.