Laughing Meme

from __future__ import the_cloud

the_cloud.twitter.me.unfollow.everybody
the_cloud.me.addressbook.known_twitterers.each |identity|
   the_cloud.twitter.follow.(identity) 
      if the_cloud.geolocator(the_cloud.dopplr, the_cloud.fireeagle).nearby?(identity)
end

Last year I wrote a SxSW Twitter killbot, but what I really wanted was the above. I almost wrote it, but there were one of two annoying problems, and I figured someone else would write it for me.

Its one year later, I’m starting to realize that I’m about to go into conference mode again, which on top of a sleep deprived delirium, and a certain disconnect form external data sources, also is the only time when I have Twits come to my phone. And I still can’t do the above! What have you people been working on all year! Don’t make me come back there and start a start up.

Other questions I’ve asked my addressbook lately, and failed to get a response:

Please partition my social graph into a Dijkstra Nikon/Canon split.

Does Bob like cilantro? And is Alice lactose intolerant?

Do any friends.known_vegetarians.have_yelp_reviews(Austin)?

Lots of others, all unanswered.

Mike released HTTP_Request_OAuth today, so I spent a little while this evening coding up Service_Twitter as helper class for making OAuth authorized requests against the Twitter API.

Both are early enough in the dev cycle to be called proof of concepts.

Mostly I wrote it because I had always envisioned there being wrapper libraries around the low level OAuth implementations that wrapped the calls, and constants, and as Mike graciously went out and wrote a low level library I felt compelled to write a wrapper.

Also twittclient, an interactive client for getting an authed access token, essential to bootstrapping development.

And nota bene, HRO currently only supports the MD5 signing algorithm, which is undefined in the core spec, and subject to change. (Just in case you didn’t believe me about the early state of things.)

update 2008/4/18

This code no longer works because Twitter has taken down their (slightly non-compliant) OAuth endpoint. When they add OAuth support back in, I’ll link to it.

The writing was on the wall.

Jack Dorsey: Taking the subway to Union Sq. The NYC one. (July 23rd)

(actually I missed that one, but Twitters from Jack regarding the White Stripes were a dead give away!)

Bit late, but congrats to both Twitter and WeSabe on closing funding with Union Sq. Ventures.

Like Tony said, “All my friends go with Union Sq.”. I’ve been fan (a fan of a VC!?!?) since shortly before their del.icio.us investment, and they continue to fund my favorite start ups.

We walked by their office today, but too busy to stop in and say, “Hi”.

Via the HA blog (an obviously unserved niche in retrospect), a very interesting 30 minute presentation on the Google Talk architecture.

ConnectedUsers * BuddyListSize * OnlineStateChanges

Interestingly people keep independently re-discovering that maintaining presence is the hard part of scaling these systems.

Its something that really came home hard in my talking with Twitter helping with their scaling challenges (so much so that we took a slide out of our “Social Software for Robots” talk to talk about it, and Blaine mentioned it again in his “Scaling Twitter” talk)

So by way of a PSA:

Presence isn’t easy.

Growth in social systems in non-linear. Ignore the network effect at your peril.

Kick the Tires

Also interesting was “Real Life Load Tests”. The GTalk team deployed to Orkut and GMail weeks before actually turning on the UI for the features to be able to monitor the load. These are the practices that make Bill’s recent observation on HA systems possible:

An interesting takeaway is that it’s clearly possible to re-architect data storage on super-busy production systems seemingly no matter where you start from.

For the rest of bullets see the HA blog post.

Blaine and my slides from XTech07. (Oh, and SlideShare needs co-presenter features!)

More XTech ‘07 slides.

Alex gave a phenomenal interview on Twitter and Rails a couple of weeks ago. This morning its all over the Net — but folks I think are taking the wrong lessons from it.

1. Ruby is dead slow. This is not news, though it can be surprising when you’re used to thinking about scripting languages as all being roughly equal.

2. Rails trades developer performance for framework performance. Also not news, as this has been the mantra of Rails since day 1.

More importantly he gives a quick insight into the how of making social software scale. It’s hard, it has ugly network effects, it makes databases cry. Alex mentions cache like mad. (because frankly no one but the content creator needs to see fresh data)

Also denormalize like mad, federate like mad, and prune features that make your site slow. (and these are the same techniques that they’re working on behind the scenes at Twitter, and that we use to scale Flickr).

You’ll never build a successful site if you build to scale from day 1, scaling is always a catch up game, but it’s the best game there is.

(And yes, this is my all Twitter all the time blog week)

update: Blaine, lead Twitter engineer, is giving a talk on how they scale Rails/Twitter next weekend at the Rudy SD Forum. (which has done a terrible job of publicizing its existence, but has a pretty killer looking line up)

It’s been “big news” that Twitter and Jott are vulnerable to CallerID spoofing. Can’t speak for the Jott kids, but I know this isn’t news to Twitter kids, given that Blaine and Rabble were demonstrating CallerID spoofing (and related techniques) over Asterisk several years ago.

This is one of those security problems that everyone knows about and quietly agrees not to speak too loudly about because alternatives like Nitesh proposes are usability disasters.

The carriers have designed their networks around the assumption of monopoly practices and zero information sharing, and it means they’re slow and make dumb mistakes. (I always think of it as a nice parallel to the current U.S. administration — organizational tactics constrain your imagination and your coping techniques)

Jabber, btw doesn’t have this problem.

j = Jabber::Simple.new(jid, pass)

j.received_messages.each do |mesg|
    if mesg.body.match(/austin|sxsw/i)
        sender = mesg.elements['//screen_name'].text
        j.deliver(’twitter@twitter.com’, “leave #{sender}”)
    end
end

Though truth be told, it isn’t running.