Saturday, December 29, 2007

OpenSocial talk at Google

I went to an OpenSocial talk at Google about a month ago. Sorry it's taken me so long to write a summary. Hopefully it won't be completely out of date ;) Here are a bunch of random notes:
  • The talk was held in the same room that the Bay Area Python Interest Group normally holds its meetings. However, I knew right away that something was different when I got there a half an hour ahead of time, and the room was already filling up. During the meeting, I counted rows and columns, and estimated there were about 200 people present.

  • Google was making a big deal of the meeting. They were providing dinner, which they don't do for our group.

  • Looking at the JavaScript examples, the code looks strangely verbose.

  • Security is not defined in the spec. Dealing with third-party JavaScript is a challenge. Facebook's answer was FBJS. At least at that point in time, OpenSocial didn't have a well-defined answer to that problem.

  • One of the demos crashed.

  • They're taking the lowest common denominator approach and letting people build extensions on top of it.

  • There were something like nine speakers. One thing that was really strange was how many of them had strong foreign accents.

  • If you have an OpenSocial application running on multiple networks, and the same person has an account on multiple networks and uses your app on multiple networks, there's nothing implicit in the spec allowing you to know it's the same user. If one of the networks allows users to sign up without verifying their email address, it'd be really easy to masquerade as another user, totally sabotaging all the OpenSocial applications.

  • Facebook has a policy against caching a user's friends for more than a day. OpenSocial does not define any such policies. It's up to the individual networks. This may prove to be a challenge for app writers and policy enforcers alike.

  • OpenSocket is a Facebook application that acts as a socket for OpenSocial applications. It is iframe based. Facebook said, "We think it's cool." However, it may have legal difficulties because the apps that plug into it must obey Facebook's TOS, yet it has no way to enforce that.

  • The OpenSocial spec still has a lot of ambiguities.

  • Apache Shindig is an open source container for OpenSocial applications.

  • Many people obviously want a way for their identities to span networks. I've argued for a long time that OpenSocial was solving the wrong problem. I don't want something to make it easier for me to write apps for multiple social networks. I want something to make it easier for me to cope with the fact that my friends use multiple networks.

  • Strangely enough, Windows laptops dominated among the speakers. A few of the speakers used Macs, but it was a lower percentage than usual.

  • OpenSocial is an improvement because it let developers move away from screen scraping MySpace, and it lets users get away from cut-and-pasting code snippets into their profiles.

  • It was a very long meeting.

  • One of the speakers was German. He was writing an application to let users collaboratively solve jigsaw puzzles. He took a dig at Americans saying, "Collaborate? We just like to blow things up!" It wasn't a very popular application.

  • A lot of the people who were excited about OpenSocial are developers who were "late to the Facebook party" and viewed OpenSocial as a chance to be ahead of the curve.

Books: Isaac Asimov Predicted Wikipedia

I'm reading Isaac Asimov's book, "The Beginning and the End". I can't get enough Asimov, which is good, considering he's the most prolific author that ever lived.

"The Democracy of Learning" (Chapter 3 of "The Beginning and the End") is a short essay that appeared in "Know" magazine, which was a short-lived magazine that was put out by the makers of the "Encyclopaedia Britannica". It's ironic that Asimov was writing for the "Encyclopaedia Britannica" when he wrote:
And I look forward to the time when computerization will place in every home a terminal connected to some central library which will place, in facsimile, or on the television screen, the resources of human generations at the very fingertips of even the least of humanity. But that, alas, was not in my time.
Well, Asimov, you're right. Wikipedia is incredible, and I'm sorry you missed it.

Tuesday, December 25, 2007

Python: Some Concurrency Tricks

Here are a few concurrency tricks if you're stuck using threads. I used these tricks years ago to write a Swing application in Jython, and I found them to be helpful enough to warrant a blog post, albeit a few years delayed.

First, let's suppose you have a UI and you want to talk to an external program written in another language that might occasionally block. Use the main thread for the UI and use a separate thread to coordinate with the external program. In general, most things that might block should have their own thread.

Name your threads.

It's likely that certain code should only be run by the UI thread and vice versa. At the top of each method, do an assertion on the thread name.

Avoid sharing data. Sharing data involves mutexes, etc. which is generally painful and easy to mess up. Instead, constrain each bit of data to a single thread. If you need to interact with that data from another thread, "ask the other thread for help".

The way I like to do this is to use the queue module which takes care of its own locking. You can pass requests from one thread to another via a queue. In some cases, I even found it helpful to pass a callback on the queue. That's like saying, "Call this callback, but do it from your own thread."

Much of this approach now falls under the label of "actors". An actor is the combination of an input queue, a thread, and an object. I like to think of them as "living objects that you talk to asynchronously." However, even years before I had heard the term actor or knew how to code in Erlang, these tricks were still useful.

Friday, December 14, 2007

Python: Using PyFacebook in Pylons

I overhauled the WSGI, Paste, and Pylons support for PyFacebook. Large portions of it had suffered from bit rot. Everything should be working now. I wrote a demo application in Pylons and it went smoothly. Best of all, I even documented my work ;)

Wednesday, December 12, 2007

Books: Ajax in Action

This is a review of Ajax in Action.

It's amazing how much the JavaScript world has changed.

This book has a relaxing style, and it was enjoyable to read. However, it no longer represents what I think of as "modern" JavaScript. For instance, it doesn't cover closures until appendix B, and even then it tells the reader to avoid them. These days, having studied Dojo, jQuery, and Douglas Crockford's videos, it's clear that closures are at the heart of how modern JavaScript is written.

The copyright for this book is 2006, yet the index doesn't even mention Firebug, YUI, dojo, or jQuery which are now staples of the JavaScript community. Dojo is at least mentioned in the list of Ajax frameworks and libraries, but the others aren't.

This book is an interesting relic from that period when Ajax was first gaining popularity, before the major JavaScript frameworks had gained a foothold. These days, for those wanting to learn modern JavaScript, I recommend watching Douglas Crockford's videos instead.

Thursday, December 06, 2007

It Had Too Many Functions

Just in case you haven't seen this, this is frickin' hilarious:

It Had Too Many Functions

Python: Getting Genshi to Output FBML in Pylons

This took me quite a while to figure out, so I'm going to blog it for the sake of Google. To get Pylons to tell Genshi to output XHTML so that you can output FBML for Facebook, edit your environment.py and do:
# Customize templating options via this variable
tmpl_options = config['buffet.template_options']

# Without this, all the FBML tags get stripped.
tmpl_options['genshi.default_format'] = 'xhtml'
My templates now start with:
<fb:fbml xmlns="http://www.w3.org/1999/xhtml"
xmlns:py="http://genshi.edgewall.org/"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:fb="fbml">