Writing a Facebook application

Facebook is the largest social network in the world (300 million users) and it is surely a showcase for web applications. You can easily write a self-hosted application that interacts with the Facebook Api, obtaining access to the user details and relieving from registration and preferences management issues.
There are two ways to code such an application: FBML, a markup language created by Facebook, versus creating an iframe application. In the latter case, which is the most interesting, the application will run on your hosting server and will be embedded in a Facebook page. This choice gives you more freedom in data processing and technology since the application will be a real web application, with the addition of an interface to Facebook data.

The starting page for creating a web application is http://developers.facebook.com/get_started.php; there is a list of steps to complete such as:

• downloading the official php library and placing it wherever you want, for inclusion in php scripts; of course there are other libraries to take advantage of the same Api, written in other programming languages, but php is the most comfortable choice for the majority of this blog's audience.
• Register the application in the Developers application.
• insert the callback (url of your server) and canvas (official url of the application) urls; canvas is the generic term for the Facebook page where your application resides.
  

After a successful setup, the Developers application will very friendly provide you some sample code to list the first 25 friends of an user that visits the application, with your application keys already inserted in the bootstrap code.

To try out Facebook's environment, I decided to write a throw away php application that automatically declines events whenever they contain a list of spamming keywords chosen by the user. The keywords are stored in a mysql database on its own server.
Currently NoSpam runs on my home server because I could not find a free php hosting service which has Pdo_Mysql and stream_context_wrapper() enabled at the same time. (Do you know any?)

XFBML
A standalone hosted app is very easy to create because there is no difference with the web application that we all know. But it's a matter of fact that it will need to create Facebook widgets: for instance requiring authorization for doing almost anything interesting is commonly achieved with a Facebook javascript popup that prompts the user for extended permissions. In my case, I had to require authorization to rsvp to events in the user's place.
The solution for taking advantage of precooked Facebook widgets resides in XFBML, an Xhtml namespace that allows you to embed Fbml tags in your html and having them parsed when the iframe is loaded, much like Dojo declarative model.
A guide for setting up XFBML can be found on the Facebook developers' wiki: http://wiki.developers.facebook.com/index.php/XFBML
Everyone says that xhtml sucks, but it is a standard for this really useful feature. Once XFBML is set up, creating a button that asks for extended permissions is as easy as:

<fb:prompt-permission perms="rsvp_event">Allow NoSpam to respond to your events invitation.</fb:prompt-permission>

Php
The role of Php in this adventure has been fantastic: it scaled down just enough to allow me building a throw-away application, since my goal was learning how the facebook infrastructure works. I wrote only 1 class, and all the setup was in my index.php (which is only ~100 hundred lines of code long).
I am trying different hosting services (which usually are the driving force of php, but they have always interesting features and extensions disabled or not compiled at all), and all it takes to deploy the NoSpam app, to judge if it can work in an hosting environment, is uploading the files and create the mysql database. No compiling, no packaging, no dependencies resolution, no libraries of any kind but the Facebook official one. Php can create monsters sometimes, but it's certainly the path of least resistance between a web developer and a working prototype.

Note that I have not TDDed this application since I plan to throw it away. When you're working in a new environment, the best thing to learn how it works is to dive in the code.

Twitter virtues and vices

After some weeks of Twitter usage, I came to the conclusion that it's a good networking tool and I do not regret opening my account. Some technological faults however are preventing me from fully enjoy the experience.

Rapid conversation: +1
Communicating via twitter is like sending phone text messages: the conversation flows and there is a need to rephrase to get to the point quickly. Shortened words and messages are normal as in informal sms communication.

Following @weierophinney: +1
It is often said that people who get things done have no time to tweet, but it seems that Twitter does not kill productivity if used correctly. And if it's the lead developer of Zend Framework, it must means that it's more a matter of choice: reserving a bit of time once a day to answer questions and to formulate ones it's not an action that will kepp you from doing real work. In fact, it will kill you if you keep staring at the screen trying to read every new tweet, but it is different from rss: you don't have to check them all.

The space to say what you want: +1
Many times, during the day, I think about some issues or ideas which does not earn a blog post on their own, but must be kept somewhere "just in case". This is pure tweet material and my timeline is full of thoughts which will could become posts or projects, or simply remain there to give evidence to myself that I always triaged Google Reader entries.

Reply system: -1
Whenever you reply to someone, you start a new tweet. There is no association with which one you are responding to, and neither quoting is present.
For instance, if you are replying to a tweet which has been posted some hours ago and it's not in the top of the timeline, probably no one will understand what are you talking about. Moreover, replies to other people obscure other tweets which might contain some useful links or information.

Limited web interface features: -1
If you want to improve your user experience, you must consider a third party client. I cannot find how to retweet a link in the web interface (the button might be somewhere) as a Tweet has only two ones: favorite and reply. I don't know what happens when I push the former but a star lights up.

Filtering: -1
The only possibility for searching is a full text one with tags such as #php or @giorgiosironi. This is not a problem since Google works in the same manner. Online filtering is unfortunately not possible: I'd like to simply concentrate my timeline when I consult twitter and I have to read all the noise from people who is replying to someone else.

Summing it up, there are pros and cons to manage a Twitter account. I now think that having one is a good move for enhance your networking, since it's much more simple to contact someone with a short tweet than via email (except when twitter.com is down, but it does not result in a -1 since outages are far less frequent than in the past). If you can tolerate the limitations of a system based on unorganized 160 characters messages, you should definitely register. And if you like this blog, remember to follow me.
Any other panegyric or rant?

Twitter vs. Facebook: how to manage a downtime

Yesterday's DDoS attacks on Facebook and Twitter exposed the critical addiction to social networking and the fragility of high-loaded web applications. It is not clear whether there is the same people behind the two attacks, but the system managers and their infrastructures responded differently to the issues in outage, and gave a diverse impression to the end user.


According to Wikipedia, a DDoS is:

A distributed denial of service attack (DDoS) occurs when multiple systems flood the bandwidth or resources of a targeted system, usually one or more web servers.

and that's what happened on August 6. Often the "multiple systems" are remotely controlled by a trojan horse or some similar malware, and are unaware they're being maliciously used.
Let's explore some differences on how both systems reacted to the attack:

• Facebook uptime was less affected than Twitter one. Although it depends on the particular user point of view, it seems from reports that Facebook shows slowdowns and latency increase, but less significant pages that fails to load in respect to Twitter total outage Personally, I encountered some error pages when using a pair of application, but no unreachable main pages (profile, groups) in the period of time when I used Facebook yesterday (afternoon and evening), and it has to managed the users that turned to it while being unable to tweet.
  
• Facebook and Twitter are built on different stacks, althoug it can be a coincidence. Facebook is all php, while Twitter is built on Ruby on Rails. The effective difference depends on what resources the attackers saturated: bandwidth is not dependent by the technology you're using on a webserver, while cpu load and memory usage are affected.
  
• Facebook shows some errors, while Twitter not. As I said, I encountered some error pages while using Facebook while Twitter was failing and letting the http request time out. This was particularly fastidious because of widgets that performs a twitter mashup: I was forced to remove the Last tweets column from the sidebar of this blog because it would never load, expanding the downtime of Twitter to Invisible to the eye.

The last point is a tip on how to annoy your users. Facebook had a 99.9% uptime in 2008, while Twitter has a tradition of being unrechable every once in a while. The statistics shows that in the last year the availability of the service was barely ~99%, with 84 hours offline (despite improving from the six days of outage in 2007). Since the uptime is measured in nines, it is much, and since it seems that Twitter might not know when it is offline, another website has been created to monitor it.
Facebook probably has better servers, or more scalable technology: when even the fail whale is unreachable, Facebook will be still here.