Pictures!

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 PicasaWeb required 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:

1. Preferably a hosted service so I don't have to back stuff up myself.
2. If it's something I run myself, backups should be easy.
3. 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.
4. Must be able to relatively-easily handle posting code snippets, and they must not look like crap when posted.

Note that (3) rules out Blogger and LJ as far as I can tell.

Whatever I choose, I will ensure that my current RSS URL continues to work, and I will try to keep modified times as they are so as not to spam aggregators.

September 15, 2006 (link)

Ruby

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:

1. Ruby itself. It's entirely interpreted (no JIT, no bytecode, no nuttin') and that's not really changing anytime soon.
2. 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.

September 23, 2006 (link)

Cycling

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.

September 30, 2006 (link)

Agile

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.

Back: August 2006

Next: October 2006