At the Forge - Facebook

 in
Learn how to connect your Web applications to Facebook, the highly popular social-networking suite.
The Web Application

Facebook now is ready to communicate with our Web application—we had better create one! As I mentioned previously, I'm using Ruby on Rails to create a simple Web application that speaks with Facebook.

Now, I could do all the hard work myself. I could read the Facebook documentation, learn the APIs and debug things. Or, I could benefit from some amazing work that others have done, and think about my application, rather than communicate with Facebook.

If you are using Ruby on Rails, you can do this by installing a Ruby gem (that is, a prepackaged bundle of code and documentation):

gem install rfacebook

The rfacebook gem includes everything you need to speak with the Facebook server from an application. But, it doesn't include some of the glue that a Rails application needs. For that, you need to install a Rails plugin. So first, let's create our Rails application, specifying PostgreSQL as our database:

rails -d postgresql rmlljatf

After Rails creates all the files it needs, we now can install the rfacebook_on_rails plugin:

cd rmlljatf
script/plugin install 
svn://rubyforge.org/var/svn/rfacebook/plugins/rfacebook_on_rails

Note that in order for this to work, you need to have a Subversion client (svn-client) installed. You also will discover, as I did, that if you don't have the Ruby SSL libraries installed, RFacebook will fail mysteriously. On an Ubuntu machine, such as I'm running, I installed that by typing:

apt-get install libopenssl-ruby

With all these things in place, we now can use the plugin to configure Facebook for our system:

rake facebook:setup

Among other things, this creates a configuration file for our Facebook application in config/facebook.yml. As a very explicit note indicates during the execution of rake facebook:setup, we need to open and edit this file in order for things to work. When you open it, you'll see that you need to enter your API key and secret (from the Facebook Developer page on the Web). Where it says yourAppName next to canvas_path, enter your application name. In my case, it's rmlljatf. And, where it says callback_path, replace it with the URL you expect to use for the Facebook application on your server. In my case, that's just /hello/facebook. (This should be a relative URL.)

Let's create a controller for our application:

./script/generate controller hello

Then, remove the file public/index.rhtml.

Finally, create a simple method in our hello controller:

def index
  render :text => "hello"
end

Sure enough, when I point my browser to http://atf.lerner.co.il:3000/hello the controller (hello) is invoked, as is the default action for that controller (index). And, I see “hello” in plain text in my browser. Yay!

Let's write a tiny bit more code to get things ready. First, let's define a new method in our hello controller:

def facebook
end

Notice that we haven't defined anything in the method, other than that it exists. Next, we create a facebook.rhtml file in app/views/hello:


<p>Hello, FacebookWorld!</p>

We can see the results at http://atf.lerner.co.il:3000/hello/facebook, which displays:

Hello, FacebookWorld!

Hello, FacebookWorld

Experienced coders know that looking through log files is a great way to keep track of what is happening. Rails includes a log file for each environment, giving you separate logs for the development and production environments, in case they're installed in the same directory on the same computer.

If I look at the development log (logs/development.log) after my invocation of the index method, I see the following at the bottom:

Processing HelloController#index (for 84.110.255.110 at 2007-09-12 
08:26:08) [GET]
  Session ID: ef0e25ea44f91f3c900f54c4bca93506
  Parameters: {"action"=>"index", "controller"=>"hello"}
Completed in 0.00339 (295 reqs/sec) | Rendering: 0.00016 (4%) | 200 OK
[http://atf.lerner.co.il/]

None of that should surprise us, and it even should make us happy. But, if I look right above that, I see some log file messages that are coming from the RFacebook plugin:

** RFACEBOOK INFO: It looks like you don't have memcache-client,
   so MemCacheStore was not extended
** RFACEBOOK INFO: using default Rails sessions (since we didn't
   find an fb_sig_session_key in the environment)

It looks like even without explicitly asking for RFacebook to do anything, it already has started to look around and act. The first message has to do with memcached; although it might be useful for certain distributed applications, we don't need it for right now. The second note indicates that our method was invoked directly, rather than via Facebook, so there wasn't any Facebook session information to retrieve. As a result, we'll use regular Rails sessions, rather than Facebook sessions.

How can we invoke our application via Facebook? The first thing to do is add the application. Go to the developer page (facebook.com/developers), and click on the name of the application (rmlljatf). On the right side of the page, there should be a big blue button marked Add application. Click that button, click the similar button on the next page, and the rmlljatf application will be installed.

Now, I can point my browser to http://apps.facebook.com/rmlljatf, and what do I see? Yes, you guessed it—a cute little message, saying:

Hello, FacebookWorld!

We managed to point our browser to Facebook, which invoked the application on our server, which returned results that were then displayed inside of the Facebook page. Not bad, right?

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix