Please join me at my new location bryankyle.com

Friday, April 16, 2010

The iPad, iPhone OS 4.0 and Dropbox

From the looks of the iPad it's designed to be used primarily as a content consumption device with support for content creation. It's a good position for a first release since consumption doesn't require Apple to work out all of the kinks around how to use this brand new computing device as a way to create content. However, Apple seems to be slightly schizophrenic about the device with the release of the iWork applications for the platform. From what I've been reading the problems with using the device as a content creation platform are numerous. Most of the complaints I've read fall into one of two buckets: the device is designed as a touch screen device and input is fraught with problems, and there's no built in support for syncing work between the iPad and another machine.

Obviously Apple is aware that people aren't going to get any serious work done with a touch screen keyboard, hence the iPad Keyboard Dock and support for Bluetooth keyboards. But allowing users to hook up a keyboard to the device is only a half solution; you still need to interact physically with the device to perform some operations. John Gruber of Daring Fireball sums this up nicely in his article about the iPad:

The iPad is fundamentally a touchscreen device. You absolutely do not need a hardware keyboard for it. But if you re hoping to do any amount of serious writing with it ... you re going to want one. There are a few places in the iPad UI where I really wish the keyboard was useful but it isn t. For example, Safari location field suggestions. ... On the iPad, you must use touch to select from the list. Since you re already typing if you re entering a URL, this is just begging for arrow key support. (Ditto for suggested results from the Google search field in Safari.) The Esc key does not dismiss popovers, but that s probably OK. It s only possible to invoke popovers via touch, so it seems OK that you must dismiss them via touch as well.

As an aside, it's nice that Apple's including the Bluetooth functionality for the iPhone as well. I'm not sure how much use it will be, but it's a nice little feature that other phones won't have.

The other issue that's been brought to light is that the sync story for apps on the iPad, as well as the iPhone and iPod Touch, is really weak. Apple hasn't provided an API to allow apps to sync their data with a Mac. In fact, given that the iWork apps don't sync with the Mac I'm not even convinced that the functionality exists. Sure, you could say that since the iWork apps are smaller, lighter versions of the iWork applications for the Mac they might not want to automatically sync since there isn't feature-set parity between the two suites.

The lack of any syncing support is really surprising to me given that Apple is trying to position the iPad as a light-weight computer. The fact that it wasn't available in the initial release is forgivable but when the iPhone OS 4.0 announcement came and went without any indication of it being in the pipeline I was annoyed.

The lack of a native sync story for 3rd party apps has really turned out to be a ghetto. Each application has its own way of synchronizing data between the sattelite - the iPad, iPhone, iPod Touch - and the mothership - the Mac. Developers are forced to come up with their own way of syncing data between the two devices. Obviously this isn't a good place to be in for developers or users.

From the developer's perspective they have to either write their own custom syncing protocol or use something like WebDAV, FTP or iDisk to transfer the data to location that's accessible to both the Mac and the device. Clearly this is a waste of time on the developer's behalf and it's not even that good of a solution since it has the fatal flaw that the app can only sync data if it's running on the mobile device.

As for users: it's a complete usability nightmare. Each app has to have its syncing configured separately. The app on the mobile device has to be running for the sync to work and potentially so does the sibling application on the Mac. If either isn't running the sync will fail and user's will have to figure out why. This shouldn't be. Syncing is one of those things that users just expect to work. Period.

Synchronizing data is a common enough problem that the platform really should address it in a standard way. The fact that sync support didn't make it into iPhone OS 4.0 but iAds, an advertising API did is just appalling.

So, if you read the title of this post I think you'll know where I'm headed: Dropbox. For the un-initiated, Dropbox is a service that automatically keeps a directory on multiple machines synchronized. Best of all, for small amounts of data - up to 2GB - it's free! Dropbox could provide the infrastructure needed for mobile and desktop devices to keep their data synchronized, a great place to be. The fact that Apple's dropped the ball on such an important piece of the puzzle leaves an opening for Dropbox to become a de-facto standard for synchronizing between mobile and desktop devices.

There's only one slight problem: as of this moment there is no public API available for Dropbox. This means that even if developers want to integrate with Dropbox they can't. From what I've heard an API is in the works, but it's not ready quite yet. All I have to say is that they had better get their act together and soon before Apple comes along and eats their lunch with an integrated solution.

Tuesday, April 6, 2010

What is Source Code?

Bryan
Hey, I've got a question for you. Can you define source code?
Kyle
Seriously? Source code is source code. What's wrong with you?
Bryan
No, seriously! I'm having a philosophical debate with myself about what source code is and so far I'm losing. I need an outside opinion.
Kyle
Let's see. Hmmmm. Well, I'd say that source code is some human readable form that tells a computer what to do.
Bryan
What do you mean by 'human readable?' Do you mean that it's made of letters and numbers and other things that humans write with?
Kyle
Yeah, human readable, like with words and numbers and stuff.
Bryan
Does it have to make sense to people in order for it to be human readable?'
Kyle
Well, I guess so. To a certain degree anyway. I mean you wouldn't expect just anybody to be able to read it and make sense of it.
Bryan
Ok, so source code is something that's human readable, in the sense that some people may be able to make sense of it, that tells a computer what to do.
Kyle
Yeah, how does that sound?
Bryan
Full of holes!
Kyle
Such as?
Bryan
Well, your definition seems to imply that the human readable form is run directly by a computer. So basically everything that most people think of as 'source code' falls outside of your definition.
Kyle
Like what?
Bryan
How about source code that's run through an interpreter, or a compiler, or a VM!?
Kyle
You know what I mean!
Bryan
Suppose I don't! That's the point of the debate!
Kyle
Alright. Source code is something that's human readable, in the sense that some people may be able to make sense of it, that is processed in some way to produce some output that then tells a computer what to do.
Bryan
That's better. But let's say hypothetically there is a computer that can understand and follow the instructions in the human readable form?
Kyle
I think you're splitting hairs here.
Bryan
Humor me.
Kyle
Fine. Source code is something that's human readable, in the sense that some people may be able to make sense of it, that may be processed in some way to produce some output that then tells a computer what to do, or is interpreted directly by the computer. Satisfied?
Bryan
Not even close. What's this computer you speak of?
Kyle
You're kidding me, right?
Bryan
Nope.
Kyle
A computer, ya know? A thing that runs the source code or the stuff output by the process that processes it.
Bryan
Interesting take on things. Ya know, I seem to recall the word 'computer' has many meanings. Before there were computing machines there were people whose job was to run computations. They were called computers. So far both the machine and the human definition of 'computer' fit your definition of 'source code'.
Kyle
Oh god, what's wrong with you?
Bryan
Pedantry. But I wouldn't say it's something that's wrong with me. Can you define computer for me?
Kyle
...
Kyle
A computer is an electronic device that performs computations.
Bryan
Humans use electrical impulses...
Kyle
ARGH! Fine, an electronic device that you plug in that performs computations.
Bryan
Well, that definition seems rather crude, but I'll accept it just to keep the ball rolling. So what about configuration files? They're human readable and tell a computer what to do. Take emacs for example, its configuration is a bunch of data structures that get interpreted by emacs, well the lisp interpreter part of emacs anyway and are run.
Kyle
What's with you and that stupid editor?
Bryan
What's with you and your stupid editor? What's it called again? 'six?'
Kyle
It's called 'vim' and if you're truely going to be pedantic, VIM in roman numerals is 6000.
Bryan
Whatever, both the fact and question remain.
Kyle
What fact?
Bryan
Your editor sucks.
Kyle
It does not suck, it's awesome. You just don't grok it.
Bryan
Look, why are you arguing with me about text editors? We're supposed to be talking about source code.
Kyle
Very well. I'm not sure that I agree with your assertion that configuration counts as source code. It doesn't tell the computer what to do, it tells a program what to do.
Bryan
That's true, it does tell the program what to do not the computer. But the configuration is still human readable, and processed, and tells the computer what to do. Maybe there's no intermediate form that's produced but I don't see that as being the sole determinant between source code and configuration. If that were the case then source code for an interpreted language would be considered configuration if the interpreter simply walked over the AST.
Kyle
Yeah but, it's configuration. I think you picked a bad example since most people think of lisp as a language, not configuration. What about simple configuration files that are just key-value pairs.
Bryan
I would argue that it could still be considered source code depending, of course, on what's reading and interpreting the configuration. I would say Turing-completeness shouldn't enter the picture at all. Simple configuration or extremely rich configuration doesn't matter. Some people consider HTML and CSS to be source code, but neither are Turing-complete. Conversely what about TeX and PostScript? Both are Turing-complete but nobody considers documents in either to be source code.
Kyle
Look, I'd love to debate with you about what is and isn't source code but I have some work to do that involves writing source code, not just thinking about it.