Hiring remote workers versus local

DHH recently posted a blog entry Stop whining and start hiring remote workers.  I posted a comment on this that I think deserves its own blog entry.  I think DHH is in a very unique position at 37signals that allows him to hire the best of the best, which means he doesn't have to deal with as many issues with remote workers that most other companies will run in to.  Here is my comment:


"I partially agree with some of the points here. But in my experience people are much more open and frank if you're in the same room as them versus a Skype call. And from a management stand point it is easier to keep tabs on people, help them if they're struggling, etc. if you can just walk up to them and strike up a conversation directly.  If you have nothing but the best of the best developers, like 37signals, this isn't really an issue.  But most companies our there just don't have the reputation that 37signals does to attract the best devs, so we have to settle for many devs that aren't the best.  Especially if you're in consulting and contracting, and need to staff up.  Having remote devs that aren't the best of the best is much more difficult than if these same devs are local.

My experience has also been that remote devs are much less interested in doing any sort of management work.  And when they do management work they're typically less engaging than managers in the office.  They'll do OK managing those they work with day to day but once they need to interact with people from other teams at the company, someone else in the office is usually needed to facilitate the communication.

And there is the social aspect too that others have mentioned.  Several devs that worked remote at previous jobs but are in the office now at my job have said they're much happier in their lives because they have friends in the office, they can go out to lunch and socialize, etc.  This despite having to deal with commuting every day.  There are some devs that socially feel better working remotely but these are in the definite minority from what I've seen.

There is an environmental factor here too that no one has mentioned.  Many cite the environmental benefit of working from home - you're not driving to work every day. But this is not a valid point typically. If you're flying everyone in to the office 3 or 4 times a year, these 3 or 4 flights will usually have more of an impact on the environment than that person driving to work by themselves every day.  A lot of factors can throw this calculation off (like if the person only needs to take a direct 500 mile flight to get to your office, if the person commuting has a 50 mile commute, etc.) but overall 3 or 4 flights per year will equal or surpass commuting every day as far as environmental damage. "

Fixing FBML Facebook apps that use Facebooker

If you've written an FBML Facebook app using the Facebooker (not Facebooker2) library for Ruby on Rails, I'm sure you've noticed by now that it's not working any more. In early to mid November, Facebook changed the way they send requests to all canvas apps (FBML and iFrame). Previously, Facebook would send a bunch of parameters called fb_sig_... where each parameter represented something, like the ID of the user. Then there was an fb_sig parameter which you could use with your secret key to validate that the request came from Facebook. The Facebooker plugin/gem is coded to use this.

In early/mid November they switched to using a single parameter, signed_request. This contains all of the info encoded as JSON, along with a validation signature. They no longer use a "session" to grant access, access is now granted with an OAuth2 key.

Unfortunately if you're still using the original Facebooker library like me, you've got some work on your hands to get your app back to a working state. I'll describe everything I did to get my app working again here.

Install Facebooker2 as a plugin
Development on the Facebooker plugin stopped long ago, the original maintainer started a new Facebooker2 plugin/gem. Unfortunately Facebooker2 doesn't have support for all of the FBML capabilities. There are some similarities between the two but overall Facebooker2 was designed to be MUCH simpler and easier to use, and it definitely is. To put Facebooker2 in your project:

1. Download Facebooker2 to your vendor/plugins directory
2. Install the mogli and ruby-hmac gems (how you do this depends on your Rails version, either install it on to the system, specify it as a required gem in your environment.rb file, etc.)
3. Download the original Facebooker gem/plugin to your lib folder (or just copy it from your vendor folder if you put the code in your project previously).
4. Edit your config/facebooker.yml file, and change secret_key to secret for your environments.
5. Edit config/facebooker.yml, and add an app_id property to each environment for your App ID (which can be viewed from the Facebook app page for your app).
6. Create a file config/initializers/facebooker2.rb and put a single line of code in it:
   
   

Modify your ApplicationController
Now that you've got Facebooker2 installed, you'll have to modify your code to use it instead of Facebooker. Modify your ApplicationController to include this code:

Now that you've got this in place, you'll have to edit the rest of your code.

Client and User
Instead of using facebook_session and facebook_session_secured, you'll want to call the methods current_facebook_user and current_facebook_client. current_facebook_user will return a Mogli::User object. Here is some code showing some of the common things you may want to do:


Facebooker Helpers
To include all of the FBML helpers that the Facebooker library includes, add the following code to your application_helper.rb:


You'll also need to make a few changes to the Facebooker helper file. Edit lib/facebooker.../lib/facebooker/rails/helpers.rb and add the following:


Views
If you have named your view files .fbml.erb, you'll need to rename them to just .erb. The .fbml type isn't registered with Facebooker2.

Publishing Stories
Facebooker had this whole publisher syntax to post stories to the users wall. None of this is necessary any more. If you wish to publish stories to a users wall, as long as the user has granted the offline_access permission to your app, do the following:


OK I think that's all there is to it. I have my Facebook app working with these changes.

The Future of FBML
You probably know that Facebook is completely abandoning FBML on June 1, 2012. Converting your app as I described here gives you some time to convert your app's views over to iframe instead of FBML. However, don't be surprised if stuff stops working before then. For instance, I can't get my app to display with https. I'm doing everything correctly but Facebook appears to not support this. Hopefully this blog post will give you some breathing time before June.

Verifying Facebook's signed_request in Ruby

Facebook's signed_request parameter can be quite complicated to parse in Ruby. Facebook's examples are of course entirely in PHP. signed_request is their new way of delivering data to your app instead of individual fb_sig_ parameters for everything. Here is the code to properly verify the signed_request parameter, and return a hash with all of the data from the request. Just call parse_signed_request passing the received params from the HTTP request, and your app's secret key (issued by Facebook). An exception will be thrown if verification fails, otherwise, you'll get a hash of the data back.