Saturday Feb 14, 2009

zembly update

We just finished pushing an update to the zembly production site, if you haven't been there in a while it is a good time to check it out as we have made major and minor improvements to the user experience so we would like to know what you think. 

Monday Sep 01, 2008

Safari Rough Cut release of zembly book

I have been working on a book describing how to use zembly to create the social web (think wiki for code targeted to social networks and other web 2.0 platforms like a blog), which was released via Safari Rough Cuts. There is still time to influence the book's content, so please use the feedback mechanism.

Friday Jun 06, 2008


I have been working hard on zembly that began "perpetual beta" today. At zembly, we are trying to provide a service to easily create social network applications that run on social networking sites like Facebook and Meebo as well as hosting widgets.

One of our focal points is making invoking Restful services easy. There are several difficult (not necessarily in terms of technology) issues to deal with when consuming restful services including API key management, and perhaps one of the most challenging finding and determining relevant data providers.

We have also tried to remove the distinction of code and deployment space by developing and "deploying" applications in the browser. This is a similar model to how blogs or wikis have taken over what in the past was the tedious process of editing and uploading html and other content.

If you are interested in taking a look at zembly, please visit the site. This is currently in private beta but there are some invitations available :)  

Wednesday Apr 09, 2008

Interested in an Internship

The team I am working on has several openings for interns. We are looking for people who want to build Facebook, MySpace, iPhone, and Meebo applications. If this sounds fun to you, please take a look at the job posting.



Sunday Mar 30, 2008

Working with the Facebook data API

I just finished working with the Facebook Data API to see how it compared with other storage services like Amazon S3. According to the documentation there is no intention to charge for normal usage of this service, so if you are building a facebook application it is worth considering this API. 

The Data API requires referencing objects by identity. All objects have intrinsic identity which is returned whenever an object is created. This can be referenced from FQL as '_id'. The Data API also supports the ability to reference an object using a user defined key (referenced in the documentation as a hash key). Just as in object oriented programming, objects can have properties which must be one of the following set of types (integer, string (255 char max), and text storage as a blob).

I used this API to allow associating tags with a user.  I started by defining the data model using the DataStoreAdmin link on application page. Using this tool, you can quickly create object and association types as well as execute FQL queries. I created two object types user (containing user id) and tag (containing the tag value) as well as the tagged association (a symmetric association between user and tag).

When a user is tagged the following operations are performed:

\* Create a tag object by invoking data.setHashValue passing in the tag string for the hash key as well as the value property. This service returns the object id and allows the object to be referenced via hash key in addition to the object id. In this data model, invoking setHashValue is idempotent and thus this can be called every time a user is tagged.

\* Create a user object by invoking data.setHashValue passing in the user id as the hash key and the id property.

\* Create an association using the data.setAssociation service to link the user object and the tag object. The id's returned by setHashValue should be used to collect the id's.

When the tags for a user are displayed, the tagged association can be queried, using fql.query, to determine the set of tags applied to the user. The query for extracting the tags would roughly be:

SELECT value FROM app.tag WHERE _id IN
   (SELECT tag FROM app.tagged WHERE user = tagged_user)

The storage mechanism makes this data model pretty straightforward. This hash key mechanism can store properties of non scalar data such as JSON. This supports the ability to use the getHashKey method to retrieve more than a single property. There is also an interesting feature of hashkey, data.incHashKey, which allows atomically modifying an integer property value.

 The example above could be extended to support a tag cloud, by counting how many instances of the tag have been added. One way to achieve this is by adding a count object with a single count integer property. The count object type would have an association with both the user and tag objects to have a unique count for each user. The count would be obtained through a query over both associations. Another implementation technique would be to use a synthetic hash key and a unique tag object for each user. The tag object would be extended with the count property. The tag object's hash key would combine the user id and the tag name. The count property would be incremented each time the user is tagged.


  • The API would be smaller if only hash keys were required for each object. The object id is somewhat difficult to work with and typically domain data provides unique identifiers.
  • The batch API is required for any significant use of this API, as a single logical operation will translate to multiple service invocations. It would be nice to have more support directly in the data API.
  • A lot of common use cases could be supported by extending the increment hash key capability to any object property. This could be done by passing the last version id and the current update and rejecting the change if an intervening change has occurred. In relational databases, this is implemented using an optimistic locking technique such as a version column.
  • This technology is worth evaluating if you are working with a viral facebook application.


Friday Aug 10, 2007

Working with Facebook Web APIs

I have recently been working with the Facebook APIs. I wanted to see how to incorporate Facebook data in a widget. By widget I am referring to reusable UI behavior which is driven by a set of services available via http. In contrast to the typical Facebook enabled web application, I wanted investigate the feasibility of using Facebook services as part of a mashup. Specifically, I wanted to ensure that without full page control (iframe embedding), it is possible to interact with Facebook services.

Here is what I did:

  1. From my Facebook account, I added the developer application. The developer application lets you create new Facebook applications. Creating a Facebook application generates a public and private key set which is required for invoking the APIs.
  2.  In order to start calling the API's to access Facebook profile information, authentication must be performed. The Facebook platform authentication mechanism is similar to the OpenId mechanism, whereby the Facebook platform actually performs the authentication and provides user information to the application. Since the target use case is to embed the widget within a Mashup and hence the reusable widget would not know the semantics of the page, the callback mechanism for web applications (after authentication on facebook, facebook redirects the browser to the provided URL) is not really appropriate. Facebook also provides a desktop authentication mechanism where a token can be generated, once the user is authentication (perhaps by launching a dialog or another browser window) the token is activated. The application can then obtains a session lease where the user id, the session id, the expiration time, and a session secret are provided. The widget can use the approach to generate the token before launching a facebook login. One problem with this approach is the exact order of obtain token, user authentication, get session must be preserved. If getSession is called before the user actually authenticates, then the token is invalidated and get session returns an error. This is a normal challenge with distributed authentication. The message signing is similar to other web APIs such as flickr, so that will be second nature to most people.
  3. Following, this I used the Facebook Query Language to start extracting data. This allows flexible queries (there are some limitations where the query must contain an index and there are no joins allowed) on different data sets.
Overall, the developer experience was positive. Developing a web application is very easy given the authentication callback mechanism, where a widget is more challenging.




« July 2016