Don't Forget Your Pilot's Guides!

I recently upgraded my airplane's panel with an Aspen EFD1000 along with some other engine and transponder avionics. Now, instead of "steam" (analog) gauges, I get many of the benefits of a glass cockpit.

Since nearly all of the avionics have been replaced in my plane since it was built, the original airplane manual, which must always be on board the aircraft while in flight, is no longer current. The simplest solution to this problem is to carry the pilot's guides for all of the equipment that's been installed over the last four decades. Obviously, this can be bulky since it includes manuals for the autopilot, GPS, radios, PFD, transponder, engine monitor, tachometer, etc.

iOS to Lighten the Load

Since I never fly without my iPad and iPhone I realized that I could add the pilot's guides – which are all available in PDF format – directly to my iPad and iPhone.

There are two simple ways to add a PDF to your iPad or iPhone so you can read them in the iBooks app:

1. E-mail the pilot's guides, in PDF format, to yourself as an e-mail attachment. When you receive the e-mail on your iPad or iPhone open the PDF attachment, click on the arrow in the upper right, and select Open in "iBooks" which will copy the PDF to iBooks. I've created another "collection", in iBooks, called Aviation, in addition to the two default collections (Books and PDFs), and moved my pilot's guides into this new collection.

2. Drag the pilot's guides, in PDF format, to your iTunes library. The next time that you sync your iPad or iPhone with iTunes, check that each PDF manual is selected under the Books tab, in iTunes, to be sure that it's transferred to your iPhone or iOS.

More Than You Bargained For

The beauty of having these PDFs on both devices is not just that I have two copies with me when flying, but also that I can bookmark pages on one device and those pages will be bookmarked on the other device after syncing with iTunes. Also, most of the hardcopy pilot's guides tend to be printed in black and white by the manufactures to save costs, but the PDFs are in full color.

Additionally, I can run a text search to find what I'm looking for in case I hadn't already bookmarked it. So, how do I lean out my airplane's engine, during cruise, to 100° rich of peak? No problem, it's a snap to find that page in my pilot's guide since I've bookmarked it.

But why stop with my pilot's guides since I also bought the FAR/AIM in the iBookstore, too? The only feature that's missing for the PDFs is that you can't highlight text, as you can in a regular iBook. So, my FAR/AIM, which is not a PDF, but, rather, a genuine iBook, is not only well bookmarked but also "highly" highlighted.

Apple's Worst Product Design (and it's not really that bad). Due to Steve Jobs Attire?

Without a doubt, I believe that the mic on the earphones that ship with iOS devices is currently Apple's worst designed product.

When I worked at Apple, high praise was, "This doesn't suck too bad." And, that's true, for the most part, about the earphone mic.

However, this problem is not an issue of sound quality or intended functionality. I love how a single click on the middle of the mic can either answer or hangup a phone call - or how it will pause and resume music. Two clicks of it will skip to the next song. I also love how convenient it is to have the volume adjustment on the mic too.

But, what I can't stand is the mic's industrial design. Its poor functionality reminds me of the old hockey puck mouse that shipped, for so many years, with the original iMac.

The problem with the design of the mic on the earphone cord is that it has tiny, right angle, edges that are about a sixteenth of an inch. While this is a tiny lip, it's a huge pain when trying to use the earbuds while speaking on the phone and turning your head because it constantly gets caught on my shirt collars and pulls the ear buds out of my ears. Obviously that's a distraction we can do without while driving.

The solution to this problem is obvious: simply taper the edges of the mic. It seems like a simple fix.

I wonder if Steve Jobs is overlooking this problem since he always wears an uncollared mock turtleneck shirt?

Harry Chapin - Thirty Years Later

Thirty years ago, today, Harry Chapin died on the Long Island Expressway. He's probably best know for Cat's in the Cradle - which is one of my favorite songs. Ten years ago, this song was ranked number 186 of 365 on the RIAA list of Songs of the Century.

Harry Chapin was driving in the left lane on the LIE near exit 40 in Jericho when he put on his emergency flashers because of either a mechanical or medical problem (possibly a heart attack). After veering into a couple cars he was rammed by a tractor trailer. The official cause of death was a heart attack, but it couldn't be determined if it happened before of after the initial car accident.

Harry Chapin would have been 68 years old if he was still alive. Last summer, I was back in my hometown (Huntington Station, NY) helping my former sixth grade teacher, Ms. Cooke, scan her 30+ years worth of student photos into Facebook. As soon as I mentioned to Ms. Cooke that I was planning to stop by the local cemetery to visit Harry Chapin's grave, she pointed to the following framed concert poster that hung on the wall in her condo. Harry Chapin died while he was driving to this concert.

Tonight, at 8:30 p.m., there will be a celebration at Hekscher Park to honor his life and work. People are encouraged to bring canned goods to be donated to charity.

Running with a virtual buddy

Today, I went running with my virtual running buddy. I've been using my Garmin Forerunner GPS / heart monitor since 2005, but I've never used the running buddy feature before today. It's a cinch to configure - you just tell the unit what pace and how far you want to run. During your run, you can see how far ahead or behind you are compared to your running buddy.

I'm a big fan of using heart rate monitors during runs since it'll tell you your exact effort level. If you're sick or not well hydrated, that info will reflect in a higher heart rate compared to a typical run.

My resting heart rate is average: 65-75 beats per minute (bpm). But, my max heart rate has always been high - well over 200 bpm. Today, on the long, steep, uphills around mile three of my four mile run I pushed my heart rate up to 207 bpm, yet I still kept falling behind my running buddy. I had built up a solid one tenth of a mile lead at the beginning of my run knowing that the uphills were coming, but I ended up giving back all of my lead, plus I fell behind my running buddy by a tenth of mile. Luckily, the last three quarter miles of the run were down hill and I managed to sprint it and beat my running buddy by about 75 feet.

When I first started using a heart rate monitor in 1995 I was concerned that my high max heart rate was an issue. But, it turns out that it's not. Just like a person's height, your max heart rate is mostly a factor of hereditary. Statistically, your max heart rate will drop about one bpm/year as you age throughout adulthood. However, your resting heart rate is a factor of fitness - so, the better shape that you're in, the lower your resting heart rate. Less heartbeats equals a longer life - all things being equal.

Carlsbad to L.A.

This weekend I flew from Carlsbad to La Verne, in L.A., to visit a high school classmate. It was a perfect opportunity to snap some great photos since there wasn't a cloud in the sky.

This was my first flight where I preprogramed the flight planning navigation system for my route and used the auto-pilot tied to the GPS steering. It's an amazing way to reduce the single pilot work load. You can just sit back and relax... while keeping an eye out for nearby airplanes.

Father's Day Special: How to Shave Like a Man

Most every guy in the world learned how to shave from his father. When I joined the Marines at 18 years old, what I learned from dad didn't change, but what did change was the fact that I was now required to shave every single day.

Running a razor over your face once a day, every day, will give most men razor burn. Luckily, the shaving technique that my father taught me, which most women already seem to know, is to replace your shaving cream with the type of skin cream that you find in a simple jar of Noxzema.

The key component in this type of skin cream is menthol. This ingredient, which comes from peppermint and other mint oils, literally has the same cooling effect on your skin as ice.

The Shaving Secret
1. For starters, you'll need a cheap, stiff, shaving brush. This is one time when cheaper is better, so don't use a high end, soft as silk, badger hair, shaving brush, since Noxzema doesn't lather like traditional shaving cream.

2. Simply apply the Noxzema skin cream to your face, with the shaving brush, like you would any other shaving cream. While shaving your face, you'll notice that you can get a closer shave with less of a burn.

3. Here's the real secret to preventing razor burn: When you're done shaving, put another coat of Noxzema on your face. Let this coat dry on your face, for at least a couple minutes, before jumping into the shower to wash it off. This post-shaving coat makes a huge difference at reducing razor burn.

Bonus: To get the closest possible shave, shave in the shower with a fog free mirror. This will leave no whisker uncut.

I've tried many different types of shaving creams over the last 27 years, from aerosol cans and old fashion shaving soaps, to high end products; but none provide the same level of comfort as a basic jar of Noxzema skin cream. So, give it a try – it just may change the way you shave.

Evolution of Computer Languages

It's interesting, yet not unexpected, to see how a next generation computer language becomes everything the previous generation wanted to be.

Java became what Ada wanted to be (write once, run anywhere), and JavaScript has become what Java applets wanted to be (web browser executable code).

Apple Languages

Over the last 15 years, or so, Apple has tried new languages while never giving up their tried and true Objective-C. One nice thing about Objective-C, which eased its learning curve, is that it's a superset of ANSI C. Most any ANSI C code will run in Objective-C.

Apple's current Cocoa API goes back to the birth of NeXT in the late 1980s. In the early days, app kit and foundation kit, which carried over into Cocoa, were the bees knees. If you didn't code on NeXT technology before 1995, then you probably didn't write object oriented code, commercially, until Java was released by Sun Microsystems. If you've ever coded in Objective-C, then you've probably figured out that all of those classes beginning with NS came from NeXTSTEP.

In the late 1990s, Java was too big for Apple to ignore, so they integrated it into WebObjects 3.5. Java and Objective-C are very similar. Java code is almost a one-to-one mapping to Objective-C and the two languages can be "bridged" such that code written in Java can be automatically and seamlessly converted to run in Objective-C and vice versa.

Trivia: The communication between Java and Objective-C is handled by a Java to Objective-C Bridging Specification, aka a .JOBS file. Get it?!?

War of the Languages

The best feature of Java is that it's a strongly (static) typed language.

The best feature of Objective-C is that it's a weakly (dynamically) typed language.

This type of thinking can lead to holy wars between coders as they argued which language was better. To avoid sending mixed messages, Apple made it clear about a dozen years ago that Java was Apple's server language of choice, while desktop apps would be developed in Objective-C.

Apple did experiment with Java desktop apps when Mac OS X was released ten years ago by integrating Java into the operating system. But Java, just like Flash, isn't a good desktop environment for many reasons. If memory serves, I believe Steve Jobs referred to Flash as a CPU hog and Java as a pig. Both Java and Flash run inside virtual machines which is a completely isolated operating system within your own operating system. It's literally the equivalent of speaking to someone else through a translator. The virtual machine must first be loaded and then translate the Java or Flash code into machine language at run time. Compare that to Objective-C which can be compiled directly into machine code that runs natively.

It seems strange that a language developed almost 30 years ago is still cutting edge, today, until you realize that Unix has been around since 1969.

What Happens When You Give Apple A Good Idea?

Last year, an iOS developer created the "WiFi Sync" app which allowed the iPhone and iPod touch to sync wirelessly with iTunes over WiFi. Unfortunately for the developer, Apple rejected his app and then implemented the same WiFi sync feature which Steve Jobs announced at last week's WWDC keynote presentation.

There's no way that Apple can say they didn't know about the WiFi sync app. AppleInsider reported that the developer was told by Apple that the app didn't "technically break the rules" and that Apple engineers "were quite impressed." Should Apple get away with this?

In many ways, the App Store is a just store, like amazon.com or drugstore.com. Vendors can present their products to the store and the store can stock their shelves with the vendor's items or reject them. It seems that this WiFi Sync incident is the equivalent of asking Walmart to sell your widget and then, after they turn you down, they manufacture and sell the widget themselves.

Vendors are free to sell their products elsewhere if they're turned down. So, where does an iOS developer take their app when it's rejected by Apple? You can either port the app to another platform, such as Android, or you can sell it at Cydia, which is a store for jailbroken iPhones, iPads, and iPod touches.

But, there is still one very interesting question: Why did Apple reject the WiFi Sync app in the first place? Apple has never had a policy of not introducing new features for fear of making third party apps obsolete. In one swoop, last week, iOS 5 made not only a few apps, obsolete, but it also antiquated entire categories of third party apps.

Apple’s Unsolicited Idea Submission Policy

When I worked at Apple, we highly discouraged people from telling us their ideas. There are practical legal reasons for this: history has no shortages of two parties simultaneously inventing the same thing at virtually the same time. When I was in college, my roommate told me that he had an idea for a laptop keyboard that was backlit so you could, as I'm doing right now, type in the dark. Lo and behold, Apple was the first company, that I'm aware of, to sell such an invention and I never communicated my roommate's idea to anyone else.

Apple's idea submission policy basically says:

Don't send us your ideas. If you do, their contents will automatically become Apple property and you will receive no compensation.

Click to see Apple's full policy

So, legally, this WiFi Sync incident might not be any different than the Walmart scenario. But it just doesn't feel right. It feels very... Microsoftish.

Tricks I Learned At Apple: Steve Jobs Load Testing

When I worked at the Apple Online Store, we would never load test the live website. There was rarely a need. However, it was always an interesting experience to turn the store back on after Steve Jobs walked off stage following one of his keynote presentations. As part of our postmortem, once the store was back online, we'd ask ourselves where the servers were constrained: CPU, network bandwidth, disk I/O, or memory? While it's hard to predict exactly how the entire system would behave in the real world, we had a good idea, before we flipped the switch, thanks to our thorough testing strategies.

Load Testing
Many companies use load testing software to see what kind of load their web app can handle. A common, but flawed way to load test a website is to launch the website and then turn on the load testers. The problem with this technique is that it doesn't give you any idea of how the website will perform if it goes down while it's live. When a website, that is in production, goes down, it must be brought up while under load and things will behave very, very differently. For example, it was discovered, when the iTunes Store first launched, that one of its trusted WebObjects components wasn't thread safe and this bug only presented itself under very heavy load.

Cutting My Teeth
When I first joined the Apple online store, I was paired up with an experienced software engineer so I could get up to speed on the code repository, build process, and unit and component testing. Since the online store was already live, we would never roll out new code without first testing it and gathering detail metrics.

My first task with my coworker was to implement a simple web service which retrieved product information, in the form of a plist, over the network. A simple service like this could normally be written in a day or two, but it took us most of the week as my mentor explained each step to me while we pair programmed our way through the process. (Although we pair programmed, our software methodology was Agile/Scrum, not Extreme Programing. Each team used whichever development technique they agreed on as long as they could stay on schedule. The teams I worked with were fortunate to have formally trained scrum masters who were supported by management.)

Before writing any production code, we'd write our unit tests. All software engineers should be taught to write their API unit tests first – it's a good discipline to learn. Next, we coded using WebObjects/Java with Eclipse/WOLips and we always ran the app in debug mode with key break points so that we could step through the code. I've frequently seen too many software engineers, elsewhere, who just code away as if they're throwing something against the wall to see what sticks.

As soon as we checked in our code, the repository would automatically build all of the applications and run the unit tests against them. If you broke the build then everyone on the team, plus a project manager or two, would receive a notification e-mail identifying you as the culprit.

Token

We had one, highly specialized piece of software code which could only be checked out, worked on, and checked in by a single engineer at a time. You were only allowed to touch this piece of code if you possessed a physical token. In our case, the token was a Darth Tater doll, which had to be conspicuously displayed on the top of your cube or bookcase.

Gathering Metrics

Once our service was code complete, bug free, and checked into the repository we began component testing to gather metrics on the new code. This is another step that's commonly overlooked in novice teams. I suspect that this "gather metrics" step isn't included in The Joel Test because Joel Spolsky's product was a desktop app and not a web app under heavy load (or, perhaps it's implicit in Spolsky's "Do you have testers?" step).

Before we could even consider including our code in the live code branch, we would hit it with many millions of requests. At Apple, we had very sophisticated caching algorithms which could store any number of entries we wanted, depending on our goals. Did we need a cache with only 500 products in it or 50,000? After a cold start, would we need to "warm up" the cache with specific products? How long should we wait, after no hits, before removing a product from the cache to free up memory?

As a side note, our caches were always hash tables. The beauty of a hash table is that it has a Big O notation run time that's constant: O(1). When you're asked, during a job interview, which is the fasted lookup function, don't, as is very common, say, "a binary tree." Perfect hash tables always win, hands down.

Tweaking and Done

We would tweak our code until we had acceptable metrics. Our metrics would measure how much memory the cache used and how long it took for each service request/response to be fulfilled. Depending on our needs, we might shoot for a goal to have 99.7% of our service requests returned within 35 ms, while 95% were returned within 10 ms with no single request taking longer than 50 ms.

These tests were run against a copy of the live database in a production environment. It's not a perfect indication of how the web app would perform once it was live. But it doesn't take long for this to be a great way to set expectations.

At the end of our sprint these metrics would be demoed as part of the Agile definition of "done." The code was now ready to be checked into the QA branch for functional testing before going live.

Push Notifications on the Cheap

One of the problems with feed updates, such as an RSS or a podcast feed, is that they're not real time. Each client, that subscribes to a feed, will continuously poll the server for updates (usually every thirty minutes). The two leading solutions to solve this problem are rssCloud and PuSH.

Real time notification can be somewhat of a challenge due to the fact that most clients are behind a firewall. Punching a hole through a firewall is too much to ask of the casual user, plus it could potentially open the client to security issues.

Even for a client that has solved the problem of negotiating the client's firewall, there's still a bandwidth issue. Each push notification server must maintain a connection with its subscribed clients so that it can notify them of updates; this is usually done via a socket which is a constantly-open IP connection. The problem with this is that there's a bandwidth cost to keep this connection open.

Push Without The Bandwidth Overhead Costs

A workaround that I'm visualizing can avoid any unnecessary bandwidth push notification costs charged to the publisher/aggregator by simply using Amazon's Simple Email Service (SES). Here's how it would work:

1. The client app would be configured to check a client's e-mail address for notifications.

2. Notifications would be sent to subscribers using SES.

3. When the client received the notification e-mail, it would then ping the publisher to receive the update.

The cost benefit of this is realized by shifting the notification bandwidth channel from the client and publisher notification server to the client and their mail server. Most data centers will charge their customers based on bandwidth, so there's a cost for a publisher to maintain a push notification channel with all of their clients. But, there is no cost for a client to maintain a connection with their mail server. In the past, new e-mail notification relied on client polling (usually once per minute). However, most modern mail clients now rely on the IMAP IDLE feature for immediate notification. New notifications would be received within a few seconds by having the subscriber's client implementing IMAP IDLE.

The e-mail account notification could be implemented two different ways. The publisher could maintain their own e-mail account which all of the clients check or, each client could maintain their own e-mail account. The former option would only work with a small number of clients. The latter option allows the publisher to manage traffic by pushing out notifications over a short timeframe to manage the "thundering herd" problem if scaling is an issue.

While this is not the most elegant solution, it eliminates all unnecessary bandwidth overhead costs involved with maintaining a notification channel. The only costs incurred by the publisher are for bandwidth used to publish the notifications and updates.