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.

Discouraging People From Joining Your WiFi Network

Have you ever taken a look at all the personal wireless networks around your home? If you live in a house, you might notice a couple of your neighbors' networks. But, if you live in an apartment or condo, you could easily be within range of ten or more wireless networks.

Each wireless network can be given a specific name to identify it. For security reasons, wireless networks can also be configured to not broadcast their name, but people rarely do this on home networks.

Since your network is broadcasting its name, people can see it. If your network requires a password, then they can attempt to join it by repeatedly trying different passwords.

To avoid this, I've given my home wireless networks names to dissuade people from joining them by naming them with financial rates to look as if they're metered: $4.95/minute is the name of my Airport Express network, and my two home base station networks are named $9.95/minute and $12.95/minute.

Over the years I've had a number of guests over to my house who would try to join my neighbor's wireless networks before asking me the name of my network. They've always had a good laugh when I told them the name. They usually comment that they were trying to access all of the other networks and stayed away from the $12.95/minute network just in case it could some how run up a bill on their device.

Greedy Cupertino Government?

Yesterday, Steve Jobs made a surprise appearance before the Cupertino City Council to present his vision of the new Apple campus to be built on the land that used to belong to HP.

Today, a friend of mine asked if anyone was put off by the Cupertino City Council members because they seemed greedy by asking Steve Jobs for favors.

At first, I just attributed the city council member's question to the fact that they were amateur politicians. There are several different models that city governments follow. Here, in Carlsbad, CA, the mayor is part of the city council (the chairman of the board, so to speak) and draws a base salary of about $18,000. After adding in payments for meetings attended, he or she ends up earning around $23,000/year for being the mayor of Carlsbad. The main responsibility for the day to day operations falls on the city manager, who you can think of as the CEO. The current Carlsbad city manager earns around $220,000/year.

My point is that the city council is usually a side job for many municipal governments making the members "part time" politicians.

At yesterday's city council meeting, one of the members asked if it would be possible for Apple to outfit the city of Cupertino with WiFi. Unfortunately, the city council had no bargaining position. Steve Jobs responded by pointing out that citywide WiFi is the responsibility of the city – that's the reason Apple pays taxes to Cupertino.

This question didn't quite come from left field. It was preceded by a question about how the citizens of Cupertino would benefit from the new Apple campus. But, was this really just a star struck, impromptu request for a favor from the council member? Probably not. There was also a subtle message in this question. Apple's friend and competitor, Google, is known for being a very giving company. From time to time, they have worked with organizations, such as airports, to set up free WiFi.

By asking this question, the city council member was really saying, "Hey, did you see that Google is bringing their next-generation Internet service to Kansas City, KS? Apple should do the same for Cupertino!" It would certainly look good for that council member, during her next campaign, to say that she was personally responsible for getting WiFi throughout Cupertino.

But, the key thing about Google is that they are, first and for most, an advertising company. They've learned how to put tasteful ads in search results, personal websites, e-mail, etc. They understand the advertising industry like no other high tech company. Google's understanding of advertising is one of their core competencies that is a key part of their free WiFi, etc, strategies.

Until Apple runs into a hurdle that requires the city government to act, they'll probably receive no favors. Of course, it will probably never come to this. Jobs made it clear that Apple will stay in Cupertino as long as they're welcomed with open arms – otherwise, it's off to Mountain View.

Soldiers Complain About Extra Baggage Fee

This article about Soldiers' $2,800 in bag fees spark outrage is bugging me; not the part about Delta Air Lines charging an extra fee, but, rather, why the soldiers ended up in this situation.

Since these soldiers are traveling under orders, they'll be reimbursed for their expenses. I experienced the exact same thing the last time I deployed overseas. It's the cost of doing business.

Perhaps Delta could have handled things better at check in, but these soldiers are ticked off and playing their military service card to receive some benefits. But, their frustration is misdirected because they may have been misinformed by the military regarding how many bags they could check, the Stars and Stripes reported. Keep in mind that Delta has to pay the extra fuel expenses to haul the extra baggage and it's a lot of heavy, dense, sea bags, duffel bags, and weapons cases. When I last deployed with my military unit on a civilian carrier, I was concerned that the airline would bump some baggage to a later flight, when we checked in, because we had so much.

Problems and Solutions
After watching this video, I see two problems. First, is the minor issue that these soldiers are protesting while wearing their uniform which is a no-no.

But, more importantly, these military members have to pay these fees out of their own pocket until they are reimbursed after filing their travel claims. Realistically, it's probably not a big deal for the author of this video since he's a staff non-commissioned officer. But, for junior military members, $200 is a very noticeable chunk of change.

The real problem is that the military doesn't routinely provide service members with advance pay to cover these expenses. The military expects its service members to pay out of their own pocket for things that "come with the uniform", sometimes without reimbursement even if it was a reasonably necessary expense. The most common case is that the military rarely reimburses service members for personal fuel expenses when they use their own vehicle to attend meetings, conferences, etc.

If you're upset, then direct it toward the Department of Defense. The DoD should take better care of our sacrificing service members during routine overseas travel.

iOS 5 Just Increased Apple's Addressable Market By 5x

During this week's keynote address at Apple's World Wide Developers Conference (WWDC), Steve Jobs pointed out, with the introduction of iCloud, that Apple's iOS devices, such as the iPhone and iPad, can be standalone devices. In other words, you no longer need a personal computer to configure, set up, or update Apple's mobile devices.

This is more than just a great convenience and I don't think many people get it... yet.



Wall Street
Wall Street, as predicted, always wants more. Yesterday, investors were looking for a pleasant surprise like an iPhone 5. But it wasn't to be and Apple did its best to set expectations with last week's "preannouncement announcement" that this year's WWDC was all about software.

Investors were looking for things that Apple could sell and the most expensive WWDC announcement was that the next operating system version, Mac OS X Lion, which will cost $29.99. Apple also announced that iTunes Match will cost $25/year but everything else was free. On top of that, Apple will stop charging for MobileMe; so that's even more lost revenue.

Growing Market Share
In order for Apple to continue growing, it needs to sell more things and their best bet is to expand their market. Otherwise, just like the iPod, the iPhone and iPad market will become saturated. While Apple is great at making their own products obsolete, they still need to get bigger and iOS 5 is their answer.

In 2005, when you couldn't swing a dead cat without hitting someone listening to an iPod in the U.S. and Europe, I had the opportunity to live in East Africa. As an Apple employee, living in this poor part of the world, I was stuck by two things. First, was the obvious lack of iPods being used by any of the locals. Second, when it came to technology, their life revolved around their mobile phones. I was amazed at the advanced state of East African Cell Phones. They were texting well before it was popular in the U.S.

Leaping the Digital Divide
In a developing country, a $1,000 personal computer is nearly a year's pay when living on $3/day. But, poor doesn't mean that they don't want high tech solutions - I can't afford a yacht, but I'd still like one. The beauty of mobile phones is that even the poorest of developing countries already have the wireless infrastructure in place.

I can easily see people in developing countries skipping over personal computers, much the way they skipped over land lines, and acquiring standalone networked mobile devices, such as iPhones and iPads running iOS 5. Also, many of these people are unbanked, but with services like PayPal and Square, they can find ways to keep their money safe. It may sound strange, but, it's no stranger than when I saw Maasai, who lived in mud huts, pull out their cell phones to text money to each other... and that was six years ago.

The iPhone 4 is hot!

While driving one warm, sunny day, my iPhone 4 was sitting next to me on the car seat. There's nothing unusual about this except that it was in direct sunlight. Even though the inside of the car was cool, thanks to the air conditioner, it was too much for my poor iPhone which temporarily overheated.

While the phone was cooling down the only thing I could do with it was make an emergency phone call or take a screenshot. About 20 minutes after moving it out of direct sunlight it resumed normal operations and all was well.

iPhone needs to cool down before you can use it.