Ideas are the Bomb

Image by cogdogblog via FlickrI'm currently working on a provisional patent application for this idea I have, which will make life significantly better for older people.

I'm also reading a book on the topic called Patent Pending in 24 Hours. A good resource, but its taking way more than 24 hours!

Modelizer

Image by Shutterhack via FlickrI wrote a little Rails app called Modelizer back when I was first learning about Rails model associations.

Modelizer looks at the databases that your other Rails are using and identifies possible associations based on the naming conventions Rails uses for database table and column names.

Modelizer creates an ActiveRecord object that connects to the selected application's database using the credentials in each app's database.yml.

What should normally go in the model for an MVC app was pretty hard to pin down for this app, so most of what should be in the model is stuck in the controller. The model isn't specific to one schema, but actually would have to use databases instead of tables and hadn't really wrapped my head around how to do that. Basically, ActiveRecord handles tables, not entire databases and this app treats all of your schemas as the model.

This also uses AJAX when you drill down into tables and the possible associations for each.

Using REST for a Facebook Application

Image via CrunchBaseIf you're into Ruby on Rails, you've probably heard a lot about REST. It supposedly simplifies your life, but in many situations, things actually get more complicated.

Building Facebook apps is one of these situations. I've been using the Facebooker Rails plugin that helps you interact with the Facebook API.

Facebooker gives all requests from Facebook an "fbml" format. You need to add this line to your config/initializers/mime_types.rb file:

Mime::Type.register 'text/html', :fbml

You need to handle this format when you call respond_to:

def index
@facts = @topic.facts

respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @facts }
format.fbml end
end

The meaning of RESTful requests depends on which method or HTTP verb is used.

When GET is used and the path is "/topics/4/facts", the request is routed to the controller's "index" action. In this example, all the facts for topic 4 will be returned. But if POST is used, the request is routed to the "create" action, which will ry to add a new fact to topic 4 (these are nested resources).

But all Facebook requests are made with GET, so your code or your plugin needs to look at a request parameter called fb_sig_request_method to see which method was used initially.

One problem I had was deleting something RESTfully from a Facebook canvas page.

Normally, clicking a RESTful delete link created by Rails causes Javascript to run that creates the confirmation popup and a form that passes the authenticity_token variable required for deleting something.

But Facebook doesn't allow you to execute javascript so you can't rely upon the javascript normally created by the link_to tag to create the form when the page is loaded.

You can't create the form in HTML and then use FBJS to submit it either; Facebook rewrites your forms, dropping the name attribute. So you can't call the form when you click a link.

In the end I had to settle for confirming the deletion on a page of its own. And a less than desirable button had to be used instead of a link because Facebook links can't submit a form. So I'm still not happy with the outcome.

Facebook Plugins

Image via WikipediaThere are two Facebook plugins for Ruby on Rails. Both help you deal with the Facebook API.

RFacebook was the first Facebook plugin introduced and is basically a wrapper around the Facebook API enabling you to call it through plugin methods whose names map to the corresponding call in the API. If the API changes, the plugin supports that. You can use Facebook docs to figure out what to do and you can get data in XML or JSON.

RFacebook was intended to be quick and dirty and the author even stated early on that developers should eventually move to Facebook. But many people stuck with it.

Facebooker does things "the Rails Way", and gives you methods that follow Rails conventions. Data is delivered in arrays and hashes Ruby developers are used to working with. In addition, there are classes that help you with publishing to feeds and sending notifications.

With Facebooker, being able to deal with ruby objects saves development time. But you aren't always aware of whats happening under the covers. Sometimes a call to Facebook is initiated when you don't expect and that costs you time. Its an even bigger deal on Rails because your Mongrel can't service any other requests while its waiting for Facebook to respond.

The support for Facebooker has been questionable at times also, since the original auther Chad Fowler left the project. Code has been checked with typos, the entire project was simply moved to github without sufficient notification (even the Facebook app for the plugin pointed to an unusable SVN version for weeks) and some of code was baffling to use. The template registration stuff, for example, took me some major digging through the code to figure out what to do and it didn't even work.

Of course, some of these issues are due to Facebook changing so frequently, but at least with RFacebook, you're rely upon Facebook documentation rather than on the ability of Rails developers to code against each version of the API. Either way its still a moving target sometimes.

Facebooker does give you some help with REST, but even that took me quite a while to figure out how to use that successfully. I do use Facebooker for my grokLokker Facebook app and its stable enough for what I'm doing. But I doubt I'd use it if I had t to due over.