On iPhones

So we got an iPhone at work to play with, and I went to an iPhone Tech Talk in NY yesterday. At the iPhone Tech Talk it was fairly obvious to me that having web apps and Safari be the only "development platform" for the device is more or less a cop-out. There will of course be the dedicated folks who go to extraordinary measures to make their web apps look and feel just like iPhone apps. But going to excruciating pain to make CSS styles so that your lists look just like a native iPhone list does not a development platform make. Nor does writing thousands of lines of JavaScript so you can make animation effects that look like the native ones. I mean, Apple could have at least written some CSS and JS libraries themselves before officially blessing web apps as the "platform".

There is a bit of irony here in my bitching, because I have previously mentioned and agreed with pphaneuf's assertion that when development becomes really easy, you get lots of crap. That may be true, but one person's "crap" may be another person's killer app, and it is the so-called "long tail" of weird and quirky applications that make a platform interesting. However, on the upside, by making iPhone development such a pain in the ass, the iPhone "apps" we do get will probably be quite high-quality, because only really serious developers will attempt them. The Facebook one is definitely pretty awesome.

And if you look at the native applications already developed for the iPhone, without Apple's blessing and through painstaking reverse engineering, you can get an idea of the kinds of things we are missing out on, simply because Apple doesn't think they're a good idea or worth their time. No offense to the iPhone team at Apple; they've done some brilliant engineering. But that team simply doesn't have resources to code up every app anyone will ever want. I mean for me, a Nintendo emulator is wicked cool. Yay! Super Mario on my phone! But most people don't care about it, so it's not the kind of thing Apple would do, and it would be nearly impossible to do as a web app, especially without Flash or Java.

Will I get one?

Maaaaybe. It's hands-down the best mobile browser ever. But since I mostly run Linux these days, and you can't even use it like an iPod in Linux, it would amount to a very expensive mobile browser for me. Plus, EDGE is teh suck. I feel like if I'm going to have a kick-ass mobile browser, I'll want a decent network to go with it. Sure, it does wifi, but I don't want to pay $10 every time I'm in an airport to read my email, that's the whole point of an unlimited wireless data plan.

September 13, 2007 (link)

Calendar it up

If you, like other Waterloobians, started classes this week, do not fear! All course schedules for Fall 2007 have been imported in to Google Calendar. Just search for them using the search feature, eg. "cs 452 waterloo". Also, real-time is at 8:30 this term. That's just cruel. It's like enforcing all-nighters.

September 19, 2007 (link)

Joel's Latest

Joel's latest article, like most of his articles, is pretty interesting. There are a couple points I don't agree with, though.

Joel tells the story of how Lotus went to incredible lengths to make their new spreadsheet app work on DOS with 640K of memory, and how that was ultimately a bad decision, since by the time they shipped it computers were much faster and had much more memory (ooh, a whole 4Mib!) and Lotus' competitors (mainly Microsoft) had made a great platform and a better, more resource-intensive spreadsheet, but the resource usage ultimately didn't matter because computers got faster and cheaper so fast.

He then goes on to say that history is repeating itself with AJAX, giving Google, and Gmail in particular, as his choice for the contemporary Lotus. However, the comparison isn't entirely apt. First of all, contrary to Joel's belief, we don't just sit on our asses all day at Google feeling smug. Google has had lots of failures, and we work very hard to learn from those failures. Nobody I work with thinks Google is invincible; in fact, quite the opposite. With web software, competition is even more intense, since competitors are literally a click away. Keeping users means hard work and making genuinely good products, not just making inscrutable file formats.

The main point of Joel's story, though, was that current AJAX developers (and in particular Google) are busy doing the present-day equivalent of rewriting inner loops in assembly, i.e. tweaking and heavily optimizing JavaScript and dealing with annoying browser compatibility issues and so on, and that soon this won't matter because there will be some great platform that abstracts all of these details away. I find this hard to believe, for a number of reasons. JavaScript execution may get much faster, both due to hardware and software improvements. There are new JS engines that are much better than Spidermonkey, which is Gecko's default. But that's only a small part of the problem. Once you have the JavaScript on the client, it is already executing fast enough most of the time. It's not the bottleneck.

The bigger problem is bandwidth and latency. Bandwidth does not increase at a pace at all similar to Moore's law. A lot of people have broadband now, but the networks themselves are overloaded (the tubes, if you will, are clogged). I have a 5mbit connection at home. In theory I should get ~625KiB/s. I rarely see over 200, and during the evenings it's more like 50. This is not likely to improve any time soon. Similarly for latency; a typical HTTP request has about 50-100ms of latency each way on a very good connection, and that's not getting any better any time soon. This means that doing frequent or large (or both) network requests will be problematic for some time to come. So a sloppily-written AJAX app that does 90 HTTP requests just to load is slow today, and guess what? It will still be slow in 6 months!

So no, I don't agree with Joel's assertion that we should just be banging out features and letting hardware catch up with us. Hardware isn't the problem; bandwidth and latency are, and it's not just going to catch up while we go take 6 months off. The fact that you need to batch requests, prefetch data and do synchronization in AJAX apps to make them performant in terms of network resources makes them complicated. Google already has good platforms for handling browser compatibility and writing nice JS widgets (eg. GWT), and we have GData which, used in JSON mode, handles a lot of the data batching and synchronization issues. (XML is of course ridiculously stupid for anything where bandwidth is a concern.)

Could a great new SDK come along that both abstracts browser differences and provides a framework for bandwidth- and latency-aware data synchronization? Sure. But Joel's assertion that Google doesn't understand the big problems and isn't working on general solutions to those problems is patently false, as is his suggestion that all work on optimizing AJAX apps will be wasted in 6 months.

Heathrow

I recently flew through Heathrow on my way to St. Petersburg. It has a bad reputation, but I was through there a few times in 2002 and didn't recall it being all that traumatising. It was a serious hell hole the other day, though. I now understand where the Brits get their reputation for being professional "queuers". They have queues to get into other queues to get on a bus to get into another queue that takes you to some more queueus! Though they're still not as bad as CDG in my opinion, since at least they didn't force me to needlessly go through customs.

September 25, 2007 (link)

Rant: by-uuid

So some brilliant soul invented a new partition naming scheme for Linux. Instead of using something like eg. /dev/sda1 you can use something like /dev/disk/by-uuid/266a660b-80ab-4dd6-8b43-a81a2f6b9b3d.

I guess the ostensible reason you would want to do this is that the UUID is written somewhere on the partition or in the partition table, and then when Linux reads your partition table it can set up the /dev/disk/by-uuid directory, so that if your partitions ever move to different devices or get reordered, you can still mount them by the same device name.

To me, this seems like a solution in search of a problem. How often do you re-order your partitions or move them to a different device? Almost never! How often does Ubuntu fuck up and write the wrong UUID into the grub.conf when you install a new kernel? Almost always! So this new scheme that's supposed to be more flexible and prevent mount failures actually tends to complicate things and make things worse.

The only remotely plausible use case I can see for this is something like hot swapping drives in a server, where you always want to mount a partition using the same device name. But I'm not running a server with hotswap, I'm running a desktop! Ubuntu should know better...

Am I missing something? Or is this by-uuid crap really as useless as it seems?

Back: August 2007

Next: October 2007