Friday, September 17, 2010

The nightmare scenario

What do you do when your primary computer dies?

I'm sure for many people a feeling of panic sets in. All of the files. Is there a recent backup somewhere? The dread of reinstalling all of the software and reconfiguring the settings. Oh no, what about the usernames and passwords for all of the mail accounts and website logins?

If you're prepared, there is no need to panic.

In fact, it's hard not to smile as the system does it's magic.

I'll explain...

My trusty MacBook Pro (early 2008 edition) started behaving erratically a couple of days ago. I took it to the Apple store, and the friendly Apple Genius prescribed a replacement logic board as a fix. It will take a couple of days. That MacBook went everywhere with me. My digital life is on that computer. What will I do in the meantime?

Step one. I created a user account for myself on my daughter's MacBook Pro. Step two. After logging in to her computer, I logged into MobileMe from the System Preferences panel and checked some settings:


A couple of minutes later, all of my setting had synced in. Launching mail started retrieving my messages. All 563 of my contacts are there. My calendar started repopulating itself. Within the hour, my new account began to feel like home.

Step three. I'm tempted to say, 'there is no step three'. In reality, there's still a bit of configuration remaining, and a few programs I'll need to install to be productive on my borrowed machine for a few days. But, I can't help but smile because of how painless MobileMe made the transition. That, and knowing that I have an up-to-date time machine backup of my entire machine at home, just in case the worst happens.

Still, it's an evolving, learning experience. I use (and really like) 1Password as a password manager. I do have it syncing with my Dropbox account, but before installing it I did need to reference some passwords using 1Password on my iPhone. A web-based tool like Lastpass might have made password management an access easier. Thankfully, I did enter many of my software serial numbers into 1Password, but some are in mailbox folders on my dead MacBook Pro. Overall, though, things are not as bad as they could have been.

So, are you prepared for a total system failure? How difficult would it be for you to get up and running if your primary computer suddenly died?

Saturday, April 10, 2010

No, Apple does not hate Adobe

What a week. First, the iPad is unleashed opon the waiting masses to great fanfare. Next, Apple teases us all with a glimpse under the tent flaps of iPhone OS4. Then, the blogosphere blows up with stories that Steve Jobs has gone mad, is a control freak, will lose the mobile market the same way Mac OS lost to Windows on the desktop, is supposed to screw himself, and that he kills babies. Ok, I made up the part about killing babies, but the rest are true, and couldn't be farther from how I see the story. Except for maybe the control freak part, but I'm ok with that. Let me explain.

The problem seems to be the revised (reviled?) text in the iPhone SDK. The part that tells developers they have to use Apple's tool chain, and only Apple's tool chain to build iPhone apps. Not tools like Adobe's upcoming CS5 Flash to iPhone cross compiler. The fact that Apple changed the wording in their developer agreement literally days before the release of CS5 is what has people's tempers rising. How could Apple do this to Adobe? Steve must really hate Adobe! That was dirty!

Uh, no. I wonder if Adobe perhaps ever went to Apple, to maybe check if this sort of thing would be acceptable, or not, before creating that tool in CS5? It's not as if Apple formerly supported Adobe development on the iPhone and suddenly pulled a fast one on Adobe by kneecapping them with the new developer agreement language. The writing has been on the multitouch screen of the iPhone since day one, in 2007, (no native development) and was emphasized in 2008 with OS2 (no interpreters—Java, no emulators—game/console engines, and no FLASH), and re-iterated time and again after OS3 and the iPad unveiling (no FLASH—ever. It's buggy, and slow, and a resource hog). We all knew this. Apple, Adobe, and even all the people who keep wailing about the iPhone's lack of FLASH knew this.

I know. You're going to tell me how CS5 is different! CS5's latest trick isn't about getting native FLASH support, or a FLASH run-time into the iPhone. It's a FLASH tool that creates an iPhone program, which then gets compiled by Apple's own iPhone SDK into native iPhone code. Apple's prior developer agreement didn't specifically prohibit this. And, the process makes an actual iPhone program. What can possible be wrong with that? Why does Steve hate Adobe so?

He doesn't.

And, if you know enough about any of this to have an opinion on it, the iPhone may not be for you. It's for the other 98% of the people in the world (98%, 99%, 97%—who cares? I think it's close to the real number). The iPhone is designed for the vast majority of people who don't have clue about what makes computers tick, who understand the iPhone because it runs—well, appears to run—one app at a time (for now), and who are perfectly happy that this is finally the first phone that they've owned that they can actually use all the features of. And then, as a bonus, they can easily add their own apps from the App store to the iPhone to personalize it and make it better. Steve loves these regular people so much that he's deliberately blocking any attempt to subvert their experience. If you're reading this, it's probably not about you, it's about them.

Yes, Steve Jobs is a control freak. But, he's exercising his will for all the right reasons. People have come to expect the iPhone to work a certain way. If you've owned one for long enough, you know. Some app developers 'get it'. Their apps are simple, self explanatory, logical, and work the way you expect them to, without getting in the way of doing things. Other apps are literally a nightmare. By keeping the bar set high though, these nightmare app developers will eventually learn they have only two options: conform to the Apple way, or leave. Conforming to the Apple way means investing in learning the Apple tools, re-evaluating their user interface, and polishing the rough spots in their apps before re-submitting them to the store. The fact that developers who do this well can be richly rewarded only helps the process. Which reminds me:

Gee, do you hear any of the top app producers in the Apple ecosystem complaining about the new rule change? No! Why do you think not?

The programmers who already follow the rules understand that they will be able to produce the best quality apps for their users by sticking with Apple's tools. The developers complaining about the change were the ones hoping to make a quick buck porting some dreck from a previous FLASH existence to the iPhone with the minimum amount of effort in order to maximize their profit. I DON'T WANT THEIR APPS ON MY IPHONE! Good riddance.

But, you say, it won't be that bad. And you're probably right. Some developers will put a lot of effort into making their apps good, and would have made decent enough cross-platform programs given the chance. But decent is not good enough. The App Store already has enough decent programs, and gets thousands more added every day. I want the best iPhone programs, not just more programs. And the best programs can only be made with the best tools.

Now for the nerd angle. I program in assembly code for fun, and what Apple is doing is perfectly logical. The biggest issues to consider here are peoples' expectations of how the iPhone works, and the limitations of the processor and battery in a mobile device. Think about these factors for a moment.

It's not an iPhone app

Every once in a while, while travelling, we hit a well known and familiar burger joint. Why? Comfort. We know what to expect. No surprises. The software that makes the iPhone great is just like the software that made the GUI great, but different. No surprises. Mac or PC, you can tell me what's in the file menu of any program, right? On the iPhone, you want programs to look like they were made for an iPhone, and belong on an iPhone. No surprises. Ever run a Java JAR file? Works on Macs, PCs and even (gasp!) Linux, but it doesn't look like it belongs on any of them. Surprise! Given the choice, I'm sure you'd rather run an app that was made for your OS of choice. It's more familiar, and there are fewer surprises. Yes, games are exempt from this point. Remember, Steve wants the experience of the iPhone to always be familiar to all users. No surprises. No funky cross-platform look or operation. Every app should feel like an iPhone app.

Code efficiency

Every additional level of compilation is going to generate worse code. Ever hand code HTML? Ever look at FrontPage's HTML? Enough said. My first 'Hello World' program in C was 34k bytes long. My first 'Hello World' in Assembly code was under 200 bytes! It's also why I decided to learn assembly code before C. Less efficient code takes more memory space, uses more processor cycles to execute (and therefore also runs slower), and uses more battery power as a result. More is less, and less is more. Nowhere is that more true than in a memory- and power-constrained device like the iPhone. Apple understands this. Steve wants the magic to stay, not die out prematurely running from running inefficient code.

Too little, too late

Adobe CS5 will be released in days. I imagine they've been working on it for a while. Too bad it't targeted to work with the iPhone OS3 SDK. Apple just released beta OS4 tools. All of the code that CS5's FLASH to iPhone tool will make, will not be compatible with OS4 until Adobe updates CS5. When will that be? Dunno. Neither does a developer that starts to develop code using CS5. Let's say CS5 is not updated until after Apple mandates OS4 compliance in the App Store. Who does the developer get mad at? Apple for not approving an app that doesn't support the current OS? I don't think so! The reality is that any cross platform tool will be trying to chase Apple's moving target, on will only hit it sometimes.

If you want it done right...

If a developer has a fanatical obsession to create the best app in a particular category, they'll know how much work lays ahead of them. They'll have to have drive, determination, research, planning, and they'll want to be in total control of all aspects of their work. Why? Because they'll remember that time they were let down by someone who didn't quite produce what they wanted, or didn't get something done on time, or... well, you get the picture. It's happened to all of us. When you want to be absolutely sure that your work is going to be the best, you put all of your time and effort into it, and you don't rely on anyone else.

I think Apple feels the same way.

Apple doesn't hate Adobe, or anyone else for that matter. Apple has a fanatical focus on doing what they do, the way they do, to give iPhone users the best experience possible. They're not going to please all developers. They're not going to please all users. But I bet the 98% of average iPhone users, the 'regular people' who own an iPhone, will still be happy with it a year from now, because it's still as familiar as the day they bought it, but with newer and better software.

Wednesday, March 10, 2010

Technology as a two-way street

It's nice when technology works for you. It's even better when technology works because of you. Let me explain.

A few months ago I used my GPS to find the fastest way to the veterinarian's office from a different part of town than I am normally in. The vet's office is at one end of a street that formerly joined both another street and a set of highway on and off ramps in a weird five-way intersection. Now, to simplify the intersection and traffic flow, my vet's street has been disconnected from the rest of the streets at the intersection. The GPS did not know about this road change and tried to route me to my vet's office through the newly created green space at the end of the street. I knew the streets no longer connected, so I entered my vet's street one block from the intersection and got there just fine.

After arriving safely at the vet's and noticing that the GPS thought the streets still all joined at the intersection, I explored its menus and found a way to make modifications to the maps - TomTom calls the ability to send and receive user-made changes 'Map Share Technology'. I entered the change, and later that week synced the GPS with TomTom's servers.

Today, I needed to pick up some special food at the vet's, and once again used the GPS to get me there from an unusual direction. Surprise! The GPS was now fully aware of the changed intersection and directed me to the vet's the new way. I can't help but think that the change I submitted, perhaps in conjunction with some other people's, caused TomTom to revise their maps. And, if so, it goes to show that the power of technology can be improved by adding to it the power of its users, in a two-way relationship.