Adam Kocoloski

Google App Engine is a new tool that lets web app developers run their codes on Google’s massively scalable infrastructure. It’s in private beta at the moment, with free accounts handed out to the first 10,000 developers who signed up. I was too late to get one, so I had to settle for playing around with the SDK and reading through some of the documentation yesterday. I’ve also done some research into Google’s infrastructure in the past, specifically MapReduce, the Google File System, and Bigtable. The App Engine SDK doesn’t appear to allow any direct access to the first two, but its Datastore API is pretty clearly a wrapper around Bigtable.

Bigtable is not a full-fledged RDBMS; it turns out that certain features of relational databases (joins, for instance) are performance killers when you’re working at this scale. Nevertheless, it appears to do a great job of enabling developers who are familiar with relational databases to store up to petabytes of data in a distributed system. Part of me wonders if this Datastore API will become a de facto standard for petabyte-scale data storage in the future.

In short, Google App Engine looks like a slick solution for web application developers who want to scale up fast. It’s far less flexible than Amazon Web Services — App Engine is definitely not a grid computing solution. They say so right in the introduction, and the significant restrictions Google places on developer codes back that up. In contrast, AWS’s loosely-coupled combination of EC2, S3, and SimpleDB allows for a wider variety of applications with requirements that are much different than those of a traditional web app (say, HEP computing).

The other interesting thing about the announcement is the significant endorsement of Python and Django for web app development. In the private beta all App Engine applications must be written in pure Python. Google plans to support other programming languages in the future, but it seems to me that in these situations the first supported language is always the best-supported one. I’m always happy to see Python rising in popularity — switching my thesis analysis codes from C++ (the default language of HEP) to Python last year has been a huge productivity boon — but I could see where PHP or Rails developers would be upset with this turn of events.

Apple gets a lot of things right. Personal certificate handling in Keychain/Safari is not one of them.

I use a handful of different personal SSL certificates in my browsing. MIT requires one to access certain secure sites, and I have another one for Open Science Grid services. A couple of days ago I generated a third certificate that allows me to login to my OpenID account without a password. As I understand it, the W3C specification requires a browser to try all of these certificates at a secure site until one matches. Firefox does this beautifully, and Camino gets it right as well (modulo a funky bug or two). Safari? It picks one cert and sticks with it, even if that cert has nothing to do with the website in question. What’s worse, if you’re unlucky and it picks the wrong cert for the site, the error message is the singularly unhelpful

Safari can’t open the page “http://example.com/blah.html” because it couldn’t establish a secure connection to the server “example.com”.

In the initial release of Leopard a user could work around this bug by setting up “Identity Preferences” in the Keychain. By ctrl-clicking on a Personal Certificate in the Keychain and selecting “New Identity Preference”, the user could associate a certificate with one or more URLs. Keychain was awfully picky about the formatting of the URLs (i.e., no trailing slashes), but at least it was something. Now it appears that in Safari 3.1 the Identity Preferences in Keychain are no longer respected (rdar://5848801). Come on, Apple!

Apple certainly knows about the issue with multiple certs; here’s a long thread on the discussion forums about it. If you believe the commenters in that thread, it’s an easy fix in Safari, but the changes to the Keychain (upon which several applications depend) are dramatic enough that Apple does not plan to fix it, ever. What a shame. Hopefully we can at least get the Identity Preferences working again sooner rather than later.

Over the weekend I was looking for a way to consolidate my online identities in a single place. I’m blessed with a fairly unique Polish surname, so even in 2008 the adamkocoloski.com domain is up for sale. However, I’ve always thought it a bit strange to host a personal site in a .com, even if that is the de facto standard these days. .net and .org don’t make much sense, either.

Enter .name. This gTLD was introduced in ~2001 expressly for individuals’ personal sites. I particularly like the model where an individual registers a third-level domain (i.e. adam.kocoloski.name) and the entire second-level domain (kocoloski.name) becomes shared. I don’t need to monopolize the entire kocoloski.name domain, after all. I found a startup called FreeYourID.com that really seems to get this idea of a unified online identity. They have a streamlined process where you simultaneously receive

1. an email address firstname@lastname.name
2. the domain firstname.lastname.name
3. an OpenID service residing at this web address

I went through the signup process Sunday, and it was all very organized and slick. In particular, the automatic OpenID account generation and association with my domain is something that would’ve required some extra reading on my part if I’d tried to do it manually. FreeYourID uses myOpenID for it’s OpenID services, which has a couple of neat features that you won’t see with the big providers, including the ability to generate a personal SSL certificate and thus skip out of password authentication once and for all. My only complaint is that their servers seemed a bit flaky and slow, with a couple of failed requests and a significant amount of time spent “Waiting for www.myopenid.com…” in Firefox. Hope it’s not a sign of things to come.

I haven’t quite made up my mind about the web portion of the FreeYourID package. At first glance it looks pretty cool:

• http://adam.kocoloski.name points to my current homepage.
• “Page Tags” are setup so that e.g. http://adam.kocoloski.name/photos always points to my photo-sharing site of choice.
• If I want more control, I can always specify my own nameservers and administer the domain myself.

The homepage forwarding and Page Tags are implemented using a) full-page framesets (the default) or b) redirects (presumably 302). I’m no web developer, but neither solution is really optimal from my standpoint as an end user. If I go with the framesets, people navigating my Flickr site won’t be able to see the real URLs in the title bar; it’ll always be stuck at adam.kocoloski.name/photos. On the other hand, if I use redirects, adam.kocoloski.name/photos only shows up for an instant and is replaced by my Flickr URL, which kind of defeats the purpose of the .name as my permanent online identity. It’d be wicked cool if things were set up so that for any part of my Flickr site I could just do s/flickr.com\/photos\/kocolosk/adam.kocoloski.name\/photos and get a link that works. I have no idea if that’s possible from a technical perspective.

Those minor quibbles aside, I definitely like what FreeYourID is doing. I’m only a couple of days into the 90 day free trial, but I could certainly see myself plunking down the $10.95/year for this setup afterwards.

Not really. Blogging was avant-garde, what, 5 years ago? In Technorati’s last State of the Blogosphere report they were tracking 70 million blogs, with 120k new ones each day. Even allowing that 5% of those new ones are splogs that’s still a crazy amount of material.

So why start yet another blog? I’ve been doing some thinking about online identity over the past couple of days (triggered by my graduation date looming off in the distance and the relocation of emails and webpages that entails), and I’ve come to the conclusion that in the future, every Internet denizen — do we still say netizen? — will have a URL just like he or she has an email. The growing popularity of the OpenID movement only enforces that conclusion. I thought about just putting up a static page with some contact info and a list of research publications, but that’s boring. At least this way I have another avenue for procrastination while I’m banging out that dissertation.

For those who don’t know me, I’m a Ph.D. candidate in MIT’s Department of Physics and a member of the STAR experiment. I’m interested in high-performance distributed computing, software development (especially Python), and Mac OS X. My wife Hillary and I live in Boston, MA.