Cobalt Edge

At Bring Light, we recently released a Facebook application to serve as a companion to our main site. You can now use the Facebook application to show what projects you've contributed to, what your favorites are, what groups you're in, and tell the world about your philanthropic activities on Bring Light.

If you're already a Bring Light user, you can get to the Facebook application two ways. If you're logged into www.bringlight.com, there is now a Facebook link in the upper right. Or, you can go directly to the app on Facebook, by going to http://apps.facebook.com/bringlight/.

Here's a look at what the wide profile box on Facebook looks like after you add the app:

Uploaded with plasq's Skitch!

I'm using Facebooker, and specifically the new Publisher class it has, with a Rails 1.2.6 app (hopefully I'll get us on Rails 2 sooner than later). But, Publisher uses some methods that are only available in Rails 2 it appears, as well as the mechanism it uses to look up Publisher view templates doesn't work properly in Rails 1.2. Also, link generation doesn't work quite right in all cases, so I have a fix for that too. Documenting my changes here for my own reference, as well as anyone else it may help.

For Publisher, I've made two changes to remedy these issues, both in facebooker/lib/facebooker/rails/publisher.rb:

In the initialize_template_class method, change the line:

returning ActionView::Base.new([template_root,File.join(template_root,self.class.controller_path)], assigns, self) do |template|

returning ActionView::Base.new(template_root, assigns, self) do |template|

The second one is to change the inherited method's call to send! to instead simply call send.

For the link generation, I tweaked the implementation of Facebooker's UrlRewriter#link_to_canvas? method, shown in entirety here:

def link_to_canvas?(params, options)  option_override = options[:canvas]  options[:only_path] = false if !option_override.nil?  return false if option_override == false # important to check for false. nil should use default behavior  option_override || @request.parameters["fb_sig_in_canvas"] == "1" ||  @request.parameters[:fb_sig_in_canvas] == "1"end

I was, and am still slightly a Facebook skeptic. I did not use it in college (it didn't exist "back then" ;-) And, it's just not something I use much, yet. But, I won't deny the incredible viral effects it has. And, I am actively working on Facebook applications (or integrations with existing sites).

I came across a great blog entry, Collision of the enterprise and web 2.0, which talks about how Facebook is being used for business more and more, and how the lines between your friends, and your "business associates is blurring. I couldn't agree more. Besides, I'm both friends with and business associates with many of the same people, a lot of them in fact.

One of the main things that has prevented more use of Facebook for me is simply the lack of "useful" applications. Zobies and movie quizzes are just not something I have time for, or rather, want to spend my time on. But, as productivity, business, and other such "useful" applications start to enter, it won't surprise me at all if I use Facebook a lot more. It is a good social and network property, and downright easy and nice for doing the social networking aspects. So, here's to seeing how Facebook's application space grows going forward.

On the blog Play/Type, there's a great article on how to do asynchronous tasks in a Rails app. Furthermore, they've built a Rails plugin, Workling, that encapsulates asynch tasks and provides a wrapper around Starling, Spawn, and others, making these easy to use.

I came across this tonight as I was figuring out a solution for spawning off Facebook profile FBML updates in the background since these can do a fair bit of data gathering. It is also useful in controllers used in a Facebook app, because while you never want your apps' actions to take more than 8 seconds regardless, if they do for Facebook, Facebook will simply fail to load the page. Therefore, if you have an expensive operation that can occur asynchronously, but is initiated by a controller, this is another place to leverage something like Workling.

For my own needs, I didn't wind up using Workling, as Spawn was sufficient for my needs at this time. Before I go to production, I may switch to Workling simply to provide future growth in case this Facebook app takes off, etc. This will be one to watch for sure.

Facebook's terms of service don't allow "fake" users, or user's who aren't associated with a human. This makes it harder to test Facebook applications which aren't published. However, they do provide a mechanism to mark an account as a test user account (see the Test Accounts wiki page). It falls under a bunch of different rules, some of which make things slightly challenging. For example, non-test user's cannot be friends with test users. This means in order to use a test user, you will have to create at least two of them, so they can be friends. Doesn't exactly parallel real life does it? :)

So, the next problem that crops up, is that you will want to register your developer app using a real account, but if real accounts and test accounts can't be friends, how do you share that app? This is not obvious, but you can extract how to do it from the questions at the bottom of that Test Accounts wiki page. Here's how I set it up (these are streamlined instructions as I had to futz around a bit before seeing how to work with the limitations):

1. Create two new user accounts on Facebook. You'll obviously need a valid email to go with this. I run various domains so just setup users in that, but you could use a Yahoo account or whatever.


2. Add the Developer application to each of the test user accounts. This is required in order for them to use your application which is still in development and not public.


3. Have these users become friends now if you like (they can become friends later as well). Also, have them be friends of the user you have that registered your Facebook application.


4. In your real user account that has the registered app, make the test users developers.


5. In one of the test user accounts, add the application. I start with just one, as I often want to test the Invite mechanism for the application.


6. Now mark the test accounts as test accounts using the URL provided on the Test Accounts wiki page.

Now you're set to have your test user's be what you use to test your application, allowing you to do invites, post messages to the mini-feed, and so on, and see how this works across friends. Hopefully Facebook will improve this in the future, as per various suggestions on the wiki page.