September 01, 2007
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
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
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
September 19, 2007
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
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
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
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.
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
So some brilliant soul invented a new partition naming scheme for Linux.
Instead of using something like eg. /dev/sda1 you can use something
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
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?