Pictures of my Asia trip can be found here. I'm going
backwards, so I currently have Kuala Lumpur, Singapore and
Sri Lanka. This is to avoid boring those of you who have
already seen drheld's
pictures.

That's right, I'm using PicasaWeb, Google's photo
sharing dealy. Why am I using it, as opposed to time-tested
Gallery or Flickr? There are a few reasons:

Dogfood. I work at Google
and I want to help make our products better.

I'm somewhat tired of maintaining a gallery. It's not that
hard, but the gallery UI for captions is kinda slow, and the gallery
UI in general is kinda slow, and I figure Google is better at backing
up all my pictures than I am :P

Features: PicasaWeb has
lots of sweet AJAX-y prefetching goodness to make flipping through
images almost as fast as viewing them on your local machine. (I sat beside
the guy who did their AJAX last term and it was an interesting lesson
in the FireFox JavaScript engine's GC :) Plus
they scale images to the precise size of your browser on the server
using a very high-quality scaling algorithm so your pictures
always look great and you don't have click on something to view a
full-size version.

And how, you ask, did I get my pictures uploaded into PicasaWeb without
Windows or the Windows version of Picasa? I used F-Spot, of course!

Side Rant

The version of F-Spot I used to upload
to PicasaWebrequired
that the gnome-keyring-daemon be running. It crashed without
it. While integration with things like gnome-keyring is good,
completely failing to tolerate situations where the app is not running
in GNOME is really, really bad.

LazyWeb Request

I am starting to re-evaluate NitLog as my blogging software. It works,
but I'd prefer to be a bit lazier and not have to maintain as much stuff.
And with Advogato shutting down, I
feel the same way about having stuff backed up. At least when I
cross-posted to advo I had a backup that way.

So: what blogging software should I use? Here are my criteria:

Preferably a hosted service so I don't have to back stuff up myself.

If it's something I run myself, backups should be easy.

Must have some bulk import mechanism. I don't want to lose all my
previous posts. I can massage my posts into various formats but ideally
I'd be able to just import from an RSS feed.

Must be able to relatively-easily handle posting code snippets, and
they must not look like crap when posted.

Joel discusses Ruby performance.
It's nice to see him taking up the cause on this. So many people are
running around screaming about how great RoR is, and it's nice to have
a bit of a reality check. It's great fun. It makes it really easy to
hack up a prototype of something really fast. But it just doesn't scale.
There are 2 reasons for that:

RoR relies on a relational database. Relational databases are great,
but they don't really scale to millions of users unless you spend tons
of money buying a gigantic machine to run Oracle, at which point you loose
sleep worrying about whether your single point of failure is down, and
the only way to scale up to more users to buy an even bigger machine...

So I see Ruby, as a language, as where Java was in say 1995. It looked
cool, people were playing around with it, but for many things it was just
too slow. Heck, Java was slow enough at launch that the first JDK actually
used JNI for the math library (and a bunch of other things).

But now, 10 years of hardware and software improvements mean that Java has
"made it." No you still can't really do real-time in Java unless you forgo
doing anything with the heap, but for many other things it's just fine,
even for apps that scale to millions of users (eg. GMail).

So maybe in 10 years Ruby will have a good bytecode interpreter with
native JIT compiling and hardware will be many times faster and it'll make
sense to write huge apps in Ruby. And maybe the Ruby on Rail folks will
have a nice, elegant way to partition data across many small databases.
I hope so :)

Macs

Joel also touches on Macs, and
how his annoys him sometimes. So does mine. While writing this post,
sitting literally 1 metre from my wireless router, my MacBook Pro has
decided to drop the connection twice. It also refused to display anything
on our swanky new 42" LCD TV until I rebooted it.

The most inuriating thing, though, is that because everything is supposed
to "just work," when it doesn't, there's no way to diagnose what's wrong.
Becase things are all supposed to be magical and happy, there's no reporting
in the UI about what's going on. Grrr. Just reboot and hope.

I finally got around to purchasing a bike this weekend. Yay me!
I had forgotten how fun it is to blast between lanes on gridlocked
streets at 40kph. Whee! In other news, I'm in pretty bad shape these
days, having not biked in a while. Need to work on that...

Notifications

Not in the programming sense, but in the UI sense. IMO, notifications
have become public enemy number one. There are way too many of them,
and they're almost all for stuff I don't care about.

My music player just started a new song? You know what, I know
that! I can bloody well hear it! No need to pop up a stupid, ugly
yellow box in my face! My software update is complete? Who the fuck
cares? Such-and-such program that I manually started needs
to access the Internet, and you need me to click "yes"? Would I
have started the stupid thing in the first place if I didn't want
to use it?

No operating system is immune here: the above 3 examples came from
Linux, Mac and Windows respectively.

The thing is, notifications are distracting to the user. If you're
going to disrupt the user's train of thought and get in the way of
what they're doing, it better be for a damn good reason. "Your battery
is almost dead," for example. If I don't know that, my computer will
die and that will be even more annoying than getting the notification.
But if the notification does not help the user avoid something more
annoying than the notification itself, it's not worth it.

BTW, Microsoft has an item about notifications in their new HIG.
Though it recommends them for "non-critical" information;
I strongly disagree with that. It does, however,
say to use them "judiciously," whatever that means. As pphaneuf says, you can tell
something is easy when it's done often, badly. Maybe vendors should
make APIs that do annoying things like notifications exceptionally
difficult to use :P

Shiny Thing

I became one of those people with a vanity domain recently. You can
now reach me at caffeine@colijn.ca.

Recently, a Googler blogged about Agile and why he doesn't like
it. Actually, he didn't really blog about why he doesn't like it. He
sort of tried and ended up ranting about a bunch of unrelated things
and coming off very insulting in some ways, and extremely arrogant. I
won't link to the post here, because I don't really want to encourage
people who haven't read it to read it. But it's linked off of Planet
GNOME and Joel (for crying out loud!) if you're really curious.

As a sort of counterpoint, I thought I would blog about Agile, and
why I think it's actually pretty good. And hopefully not come off as
extremely insulting and arrogant. Coming off as arrogant and insulting
is very bad for Google, and I would like to assure everyone that
most Googlers (certainly all that I've met) are humble, insightful,
intelligent and polite.

(While that is the motivation for this blog post, I am not
in any way speaking for Google. These are all my own views
about Agile, about what characterises Googlers, etc.)

My team uses Agile at Google (yes, with a capital 'A' and index
cards). And it seems to work pretty well. Now of course it won't
solve all your problems. It won't turn crappy engineers into great
engineers. It won't magically make all your projects turn out great. No
process will do that. If there were a process that could do that,
everybody would use it and stuff would suck a lot less in general :P

What Agile does do well is transparency. It really
exposes how much work there is left to do and how fast
you can do it. Our estimates so far have been pretty
accurate, within weeks. It reminds me a little bit of Schedulator,
except that Schedulator was something each individual needed to
maintain on their own. And just like anything that requires individual
mantainance, a lot of people neglected it and just looked at it once
in a while and bumped up their load factor. Few people (at least while
I was there) actually used the feedback loop to start making their
estimates better. I think the individual nature of Schedulator came out
of Niti's aversion to meetings. Meetings
can be bad, of course, but in this case lack of peer review may have
been even worse.

Agile, on the other hand, works at a team level. The entire team agrees
on estimates. This makes it less likely that estimates will be vastly
wrong. It's likely someone on the team knows something
about the particular task, and will thus grasp the scope and amount of
work required. At the end of each iteration, there's a post-mortem,
where bad estimates (in particular, why was the bad estimate
bad) are discussed. The effects of that are the following:

Estimates are less likely to be bad in the first place.

Estimates get better with time.

You know from historical data how much work the team can do in an iteration.

So after a few iterations, you start making launch estimates. And
(at least in our case) they're generally pretty good estimates.