First, a bit of background: iGoogle, Google's personalized-homepage service, offers developers two methods of application development:

• build a native gadget by wrapping custom HTML, CSS and JavaScript in an XML wrapper.
• build a sandboxed gadget by wrapping an externally hosted web application in an iframe.

Because of cross-domain security issues, gadgets that require authentication must be built using the iframe sandbox method. As it turns out, this method's a lot easier. Instead of building a whole new interface, you can just tart up your existing app with an iGoogle-optimized user interface. Why replicate your existing view logic with a bunch of iGoogle-specific JavaScript when you can just reskin and call it a day?

As it turns out, though, reskinning a Rails app for iGoogle isn't as simple as it might seem at first glance. I can think of three options. All have drawbacks:

1. Serve up your existing application using all the same controllers and actions. Just build a new iGoogle layout that works well within the small viewport of an iframed gadget. Of course, you'll need a mechanism to distinguish between iGoogle requests and normal requests. Your gadget could initially call up a one-off iGoogle controller that sets a session flag (session[:igoogle] => true) so that all subsequent requests get the iGoogle layout. The only problem is that visits to your normal application in the same browser will get polluted by the iGoogle flag. The iGoogle interface that works so well in a tiny iframe renders your main application almost unusable in a full browser window.
2. Use the same approach as above, but use a URL flag or a URL rewriting scheme to differentiate between iGoogle and normal requests. This keeps your normal application from having its layout accidentally toggled to the iGoogle one. But it's a lot of work. Accepting requests with an iGoogle flag is easy, but it's much harder to make sure that every link or form submittal within your application propagates that flag.
3. Build out a complete iGoogle controller that replicates every action from your normal application that you wish to expose to the iGoogle gadget. Depending on the number of actions and the complexity of each, this could require a lot of duplicated controller code. Of course, smart use of partials would reduce the amount of view-layer effort. Still, you've now got a ton of essentially identical controller actions that have to be maintained in two places.

None of these solutions is ideal, so let's hear from you, readers. How do you build Rails apps that lend themselves to efficient re-use within iGoogle or other sandboxed "gadget" contexts? Let us know in the comments.

Related posts:

1. GWT, Gadgets and OpenSocial, Part 2
2. RSpec and Rails Custom Form Builders
3. Integrating Design Drafts Into Your Rails App

ESPN.com 7 out of 10
Fairly simple, two color, semi transparent control bar, appears only when moused over--a design pattern I'm seeing more and more lately.  It's there when you need it, it shows you what you want and it gets out of the way quickly.  It's got a single play/pause button, a timer, a playback countdown, a volume control which displays only on mouseover, reducing clutter, and a menu which when clicked brings up some additional options for embedding sharing and the like.  A nice touch: Mouse over any point on the timer and you get a little tooltip that displays the time at that point.  Another nice touch: the small (no morethan 10 pixels vertical) bar at the bottom which displays how much has already played as a portion of the total.

Youtube 7 out of 10
Gets the job done.  Period.  Simple consistent interface.  Youtube also allows publishers to add annotations and captions to their videos, and naturally allows viewers to turn either on or off, with a simple hover menu at the very right side of the control bar.  Youtube is actually doing some really cool stuff to allow publishers to make their videos more interactive, including adding hyperlinks within a movie.  The evolution of online video will be interesting to watch (and maybe take part in) but that discussion is beyond the scope of this post.

NYtimes.com 6 out of 10
Elegant interface, but could be better.  The control bar stays present throughout the video playback, and occupies a significant portion of the total video player.  However its muted style--3 shades of grey--makes it easily ignored when not needed.  The playback control is done superbly.  When moused over, a small draggable button smoothly and elegantly appears, it's affordance as a scroll mechanism to move to any point in the video is crystal clear.  The volume control is nice and large, with the same measure of affordance, however it looks like it was designed separately, as it doesn't conform to the rest
of the control bar's aesthetic.  Also, I may be nit-picky, and I'm sure this won't bother 99% of nytimes.com viewers, but there's a large empty space in between the play button on the left, and the full screen button
on the right, creating an odd asymmetry which, the more I look at it, the more it bothers me.

MTV.com 6 out of 10
Nice minimalist design.  Allows you to change the video quality during playback.  Also nice, allows you to choose from 3 sizes; standard, large and full screen.

Viddler.com 6 out of 10
Lets the video publisher skin the player interface.  This great tools allows users to comment on and tag the video in the timeline.  The interface is ugly, though, and some of the buttons aren't self explanatory, nor do any of the buttons have tooltips.  At the end of the current video it automatically plays the next video, whereas most other players present a menu of videos to choose from.

MSNBC.com 5 out of 10
Slick looking.  I like the fact that the playback bar is given the entire width of the video, allowing the viewer to be more precise in navigating to a specific point in the video.  The other controls are slightly confusing.  It looks like the interface was over designed.

Virb.com 5 out of 10

Beautifully minimalist design.  No full screen mode, but it does have a cool feature that "turns off the lights" on the rest of the page.
Facebook 5 out of 10
Fairly simple interface.  Standard controls, done adequately.  Its got none of the useful social media features of Youtube. No ability to tag or comment in the timeline.  Pretty basic for such an important part of such an important website.

Metacafe 3 out of 10
Poorly designed.  It's distracting when trying to watch video, and ugly to look at when interacting with.  The big blue shiny play and stop buttons look unprofessional, and why is there even a stop button.  The draggable playback scroll mechanism moves from left to right as the video plays, but it could have been made much more subtle.   There's no need to see it unless you want to move navigate the video.  And why does the entire playback bar glow when I mouse over it?  Also not cool is the visually loud menu underneath the control bar.

As with any list, much o this is subjective.  I'm looking forward to hearing your opinions.  Also, there are so many web video players out there, this is just the tip of the iceberg.  Let me know which ones you find especially appealing, or truly horrible.

Related posts:

1. Humor: Bubble Video
2. YouTube Killed the Video Star
3. jQuery plugins: Five tips for separating the good from the bad and the ugly

Related posts:

1. The Blogs Have Moved
2. PureMVC, Spanning the Platform Spectrum?
3. Touch Screen Kiosk in Adobe Air

While developing OpenSocial applications can be a bit tricky, getting set up to develop can be a real pain in the neck. For this installment of OpenSocial and GWT, I'm going to go through the basics of setting up a simple Hello World gadget with iGoogle. We'll get into the details of signing up for other OpenSocial containers, testing, and so on, later. Right now we're just going to do the basics.

So, what do you need to build a Google Gadget with GWT for iGoogle? You need the following:

1. The Google Web Toolkit
2. The GWT Google Gadget API
3. An account on iGoogle
4. Access to the iGoogle sandbox
5. Some public server space so you can serve up your gadget to iGoogle

Pretty much everything else is self explanatory, but the sandbox can be a little bit confusing. Let's talk a little bit about the iGoogle sandbox. It's an experimental space where you can test things out without polluting your regular iGoogle account. Eventually you'll want several accounts in order to test. But every journey starts with a single step.

First, you need to sign up for iGoogle. I'll assume this isn't your first rodeo and you've done this before. Once you've got your iGoogle access, you'll want to go over to this page to sign up for the developer sandbox and add the developer tools to your space.

When developing, make sure that there's a message towards the top left of the page that says "Welcome to the iGoogle Developer sandbox." If you don't see that message, you're not in the sandbox. If you have to, navigate to http://www.google.com/ig/sandbox. You may have to "sign up" again to drop into the sandbox.

Once there, you can add those developer tools. Just clicking this link will get you started.

The developer widgets are:

• My Gadgets: let's you set inlining and caching on the Gadgets on your page from a handy interface
• Sandbox Profile Editor: let's you modify your profile in the sandbox so you can test a few things out.
• Sadbox Friends: lets you view and edit who your friends are. Important for OpenSocial applications.
• Updates:shows activities posted to your friends while interacting with the gadget.

The Hello World Gadget

In this part we're not doing anything OpenSocial related. We're just setting up a Google Gadget. That's a necessary first step for the OpenSocial stuff.

Let's get started. In my example I'll be working in ~/src/HelloGadget. Create a lib directory and put the gwt-gadgets.jar library file from the GWT Gadgets API project in it. Next, we run the GWT projectCreator to create our ant and Eclipse files:

./projectCreator -ant HelloGadget -eclipse HelloGadget -out ~/src/HelloGadget/ -addToClassPath ~/src/HelloGadget/lib/gwt-gadgets.jar
Created directory /Users/dkappe/src/HelloGadget/src
Created directory /Users/dkappe/src/HelloGadget/test
Created file /Users/dkappe/src/HelloGadget/HelloGadget.ant.xml
Created file /Users/dkappe/src/HelloGadget/.project
Created file /Users/dkappe/src/HelloGadget/.classpath

Now we create a simple sample application using the applicationCreator tool:

./applicationCreator -eclipse HelloGadget -out ~/src/HelloGadget/ -addToClassPath ~/src/HelloGadget/lib/gwt-gadgets.jar com.pathf.demo.app.gwt.client.HelloGadget
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/client
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/HelloGadget.gwt.xml
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public/HelloGadget.html
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public/HelloGadget.css
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/client/HelloGadget.java
Created file /Users/dkappe/src/HelloGadget/HelloGadget.launch
Created file /Users/dkappe/src/HelloGadget/HelloGadget-shell
Created file /Users/dkappe/src/HelloGadget/HelloGadget-compile

You now have a nice little application that you can run using the hosted mode script HelloGadget-shell in the src/HelloGadget directory. Congratulations, you have a sample GWT application.

But we want a Google Gadget. In order to make it a gadget, we have to change the code a bit. First, import the project into Eclipse. Then open the HelloGadget.gwt.xml and add the following inherit statement.

<!-- Other module inherits                                      -->
	  <!-- Inherit Google Gadgets API -->

Now let's open up the HelloGadget.java file. We're going to change it around a bit so it can be a gadget. The critical part of the original looks like this.

public class HelloGadget implements EntryPoint {
 
  /**
   * This is the entry point method.
   */
  public void onModuleLoad() {

We change our class to extend Gadget and change the onModuleLoad method to init.

@ModulePrefs(title = "HelloGadget", author = "Dietrich Kappe", author_email = "dkappe@gmail.com", height = 300, description = "A simple gadget.")
public class HelloGadget extends Gadget {
 
	/**
	 * This is the entry point method.
	 */
	@Override
	protected void init(UserPreferences preferences) {

You have to also import the following three classes:

import com.google.gwt.gadgets.client.Gadget;
import com.google.gwt.gadgets.client.UserPreferences;
import com.google.gwt.gadgets.client.Gadget.ModulePrefs;

Running the Darned Thing

Done! Well, not quite. While changing the EntryPoint to a Gadget was pretty straightforward, we now need a container to run the thing. Mind you, it will still run in it's current form in hosted mode, but all of those things it's expecting from iGoogle are not going to happen. So it's time to inject it into iGoogle.

Go ahead and compile the code using the shell command HelloGadget-compile. The resulting compiled JavaScript and sundries is under the www directory in your projects home. If you take a look, you'll see a new file that you likely haven't seen before, namely com.pathf.demo.app.gwt.client.HelloGadget.gadget.xml. This is the gadget manifest. Essentially, this is what your gadget container needs to load to display the app. Many of the parameters are set by the parameters to the @ModulePrefs annotation.

Bundle this app up and upload it to your publicly available server. In my case, I've uploaded the app here. This is the link to the XML file. You can now go to the sandbox and, using the My Gadgets gadget, add it to your sandbox.

You can tweak some of the settings having to do with caching of he Gadget resources with the MyGadgets gadgets, but more on that later. Next time we'll set up our simple Gadget in various other containers and perform something a little bit more useful with it (but only a little).

As always, comments and questions are welcome.

Related posts:

1. GWT, Gadgets and OpenSocial
2. Ask the readers: How do you keep DRY when exposing your Rails apps to iGoogle?
3. New GWT Theme: Pinky?

This is a bit different from Didier's gOpenSocial library, which was an early success at building OpenSocial gadgets with GWT. But the google gadget library isn't really quite ready for OpenSocial. I've skinned my knee here and there, so I thought I'd give others the benefit of my experience.

So, first thing, how the heck do I get GWT to generate the

line into my manifest?

Is it a parameter to the @ModulePrefs annotation? No. It's not. The way the GWT gadgets API deals with required features is by defining an interface that the Gadget class then implements.

package com.pathf.gwt.simplegadget.client.api;
 
import com.google.gwt.gadgets.client.GadgetFeature.FeatureName;
 
@FeatureName("opensocial-0.7")
public interface OpenSocial {
	void initializeFeature(OpenSocialFeature feature);
}

The feature itself extends com.google.gwt.gadgets.client.GadgetFeature and looks like this.

package com.pathf.gwt.simplegadget.client.api;
 
import com.google.gwt.gadgets.client.GadgetFeature;
 
public class OpenSocialFeature implements GadgetFeature {
	private OpenSocialFeature() {
	}
}

The class declaration for my simple gadget then looks something like this:

@ModulePrefs(title = "SimpleGadget", author = "Me", author_email = "me@gmail.com", height = 300, description = "A simple gadget.")
public class SimpleGadget extends Gadget implements OpenSocial {

There are some drawbacks to this particular approach, specifically that the version of OpenSocial is hardcoded into the interface. Future versions of the GWT gadgets API should probably approach this in a different way.

Anyhow, I hope I've saved some folks the trouble of figuring out how to write the OpenSocial requires into the manifest. I'll show how to overcome a few of the other stumbling blocks on the way to building a full featured OpenSocial gadget.

Related posts:

1. GWT, Gadgets and OpenSocial, Part 2
2. GWT 2.0 RC1 Released
3. Grails: Delegating to GORM Persistence in Java

During a recent GTD weekly review, I suddenly realized how many distractions had worked their way into my daily office routine: personal email, personal instant messaging, entertainment feeds, Facebook. I suspect such time-wasters pose a bigger danger to web developers than to other professionals, if only because the programs they run in are so central to our work. I run Firefox for web development, Adium for instant messaging, and NetNewsWire for industry news all day out of necessity. If I allow my personal distractions to jump out at me from those programs, my productivity plummets.

This weekend, I worked hard to de-tangle my professional and personal lives. My tools? Flock, the Mozilla-based "social browser," and Meebo, the browser-based IM aggregation service. My goal was to separate all personal bookmarks and RSS feeds from NetNewsWire and Firefox into Flock, then move all my personal IM accounts from Adium to Meebo. The end result was a self-imposed firewall between productive time and fun time. (Thanks to many a Lifehacker article for the basic idea, if not the implementation.)

Getting started with Flock

Flock represents a noble attempt to shoehorn social networks and other web utilities into the chassis of a Mozilla-based browser. Sure, many of its features could be achieved in a standard Firefox install. But I didn't want to have to run two copies of Firefox, one for work and one for play, and manage separate user profiles for each. Besides, my goal was to create a hub for my online social activities, so why not use a browser specifically designed for that purpose?

I also could have moved my social stuff to Safari, but that would have required adjusting to the quirks of a browser I'd previously employed only for cross-browser development. Flock 2 beta is essentially a tricked-out Firefox 3, so it offers a pretty seamless transition for this Mozilla. It even runs my essential Firefox 3 extensions, such as Foxmarks and Tab Mix Plus. With those in place, Flock looks like a souped-up sedan version of Firefox - slower, sure, but with more bells and whistles and a pretty coat of paint.

One feature that especially interested me was Flock's RSS integration. Sure, Firefox does this, too, but Flock's interface is nicer. You can interact with your feeds in a familiar two-pane interface rather than simply viewing headlines from a Live Bookmark. Flock's UI doesn't yet match the convenience of the keyboard-friendly NetNewsWire, but that's fine. I can live without power-user features when I'm just perusing The Consumerist or Whedonesque.

After a few days of using Flock to browse Facebook, scan FriendFeed, check Gmail, update Twitter and attend to my online banking, I'm sold. I don't really use the widgets on the My World splash page very much, but the integrated toolbar for interacting with Web 2.0 destinations works seamlessly. It's nice to be able to check for unread mail without firing up the entire Gmail interface. And I'm certain I'll use some of the blogging tools pretty frequently. One downside, though: You can't adjust fonts in the People Sidebar and other Flock-specific XUL widgets. My poor, aching eyes will forgive this misstep for now.

Getting started with Meebo

Instant messaging wastes as much time as it saves. Commingling of friends and coworkers on the same buddy list has always been dangerous. But even if you're careful, you'll get bleedthrough. Today's valued colleague often becomes tomorrow's high-maintenance friend once somebody switches jobs. Unless you want to give everybody you've ever known equal power to interrupt your work, you need a strategy for separating IM accounts. Creating a new account each time you start a job isn't enough. Hence my decision to segregate my accounts into two separate programs.

Cross-platform IM clients continue to proliferate, but web-based Meebo offers an interesting take on the concept. With its clean interface, soothing palette and lightning-fast Ajax interface, Meebo applies tried-and-true Web 2.0 design techniques to dowdy old chat. I used to have five IM accounts in my local Adium instance, but now I've moved four of them into Meebo. When I want to chat with friends, I can fire up Flock and open a Meebo tab. But when I need to focus on work, I can just shut it down and leave Adium open for agile team interactions at Pathfinder.

As with Flock, there's nothing about this setup that I couldn't have accomplished without Meebo. I could manually log off my non-business IM accounts whenever I want to focus on work. But I'm sufficiently prone to procrastination that such measures don't work. I need to trick myself psychologically, creating a completely different context for work chat and personal chat. Warm, inviting Meebo generates some much-needed contrast with cold, functional Adium.

Now the hard part: Sticking to the rules

Of course, prying apart the personal and the professional does no good if you're constantly firing up your fun apps alongside the work ones. Now that I've segregated all my time-wasting feeds, distracting chatter and enticing games, I've got to stick to the single rule that makes everything work: Only run Flock-plus-Meebo at specific intervals. I'm giving myself 15 minutes during morning coffee, 30 minutes at lunch, and unlimited time once I'm home at night.

It may seem counter-intuitive to get down to work with the help of two applications designed primarily for fun. But the work/play firewall helps me stay disciplined.

Related posts:

1. Application Watch – Kool, a Meebo IM Competitor
2. Icons are evil; so are menus – unless you do them right
3. Category and UI changes on Pathfinder blogs

The changes underway with groups have some positive and negative attributes. First, as a negative, LinkedIn is imposing a cap of 50 groups that any member can belong to. Changes have already started but effective 9/12/2008 if you haven’t already reduced the number of groups down to 50 LinkedIn will do it for you based on the sequence of when you originally joined various groups. While 50 may sound like a lot to some people, I was in 1,351 groups and deciding which groups to keep has been difficult, especially since I initiated and sponsored over 10 groups myself.

On the positive side groups will now have the ability within LinkedIn to support discussion groups, blogs. That means for a lot of groups you won’t need a Yahoo Group or something akin to that as a base and although the feature set may be more limited you’ll have tighter integration. Another negative is that LinkedIn could ultimately control your group since they control membership in LinkedIn. Stay tuned for updates as to how this is progressing.

If you haven't experienced what's available in terms of groups from LinkedIn, here's a way to check it out. Groups are free to join and when you perform a LinkedIn search, you can specifically search within specific groups. Support Chicago’s 2016 Olympic bid by clicking the link below and Joining the Chicago 2016 LinkedIn Supporters Group:
http://www.linkedin.com/e/gis/54811

Related posts:

1. Chicago Front-End Web Developers group forms on LinkedIn
2. Chicago JavaScript Meetup Group draws a big audience with varied skill levels
3. Who values your product and do you value them?

In this blog post I'll tell you the best way to integrate Facebooker into a new Rails project so you can start developing social networking applications quickly and easily, and how to hook them in to Facebook's new profile plan. The goal is that by the end of this post you'll have a totally working Facebooker Rails application and you'll understand how to develop in it at least a little bit.

Getting Started

ails test
cd test
rm public/index.html
script/plugin install git://github.com/mmangino/facebooker.git

Now go to the Facebook developer application and add it in.

Click on Allow, then on Create a New Application to get the ball rolling. Come up with a good name for your future masterpiece, read and agree to the Facebook TOS, and create your application.

You'll be dropped to your application page which lists your API key and your secret. Let's get those into our application. After you installed the Facebooker plugin, you'll find a new yml file in config called facebooker.yml. Copy and paste the API key and secret into facebooker.yml under the correct fields in the development environment (and also the production environment if this copy of the application will eventually be going live).

Now there are some settings we have to monkey with. Click on Edit Settings and you'll be taken to your application settings page. There are a couple hyper important things to do here.

The first is to fill in the callback URL. This is the real URL of the server that will be hosting your application. For development purposes, this should be a non-standard port on a server that you can open non-standard ports on. We'll change this to a more accessible port once we've finished development.

Secondly, the canvas URL specifies the location people will see in their address bar when they actually access your app. This is the point of access to your application for users -- if they go to the actual URL of your server (like www.test.com), they'll be redirected to this canvas page by Facebooker. So make it something memorable and sensible.

Third, ensure you've selected "yes" for "Can your application be added to Facebook?" Otherwise you're not going to be seeing your application in its full FBML glory anytime soon. When you click "yes" the "Installation Options" area appears. Check "Users" for who can add your Facebook application to your account, and also check the "Development Mode" box so only you can your team can install the app.

Once you've made those changes, save your application, and add in the canvas URL and canvas_page_name to facebooker.yml (in my example, http://www.test.com:8000 and pathfinder_test, respectively). Once you click save you'll be returned to your application settings page.

When you're returned to the application's setting page, click on the "View About Page" link. (It's in the lower right of the screen shot right above this). You'll then be looking at the application's about page, which should look a lot like this:

If it does, we're on the right track.

Digging a Tunnel

When you're developing Facebook apps, having a remote server to develop on is completely integral. If you're developing in FBML (and in the new version of the Facebook profile system, FBML is practically required), to see the results of your hard work you'll have to actually allow the Facebook servers to interpret your markup. That means they need access to your development machine, or you need a tunnel from your development machine to a remote server that's already accessible from the Internet, or you set up a staging server by following the advice of Noel Rappin's excellent blog post, Facebook Application Logistics for Team Development.

I recommend the latter route.

But if you don't have the resources to come up with your own staging server, we have to choose either your own computer or a tunnel. Opening up your computer to the Internet is a bad thing; development machines and networks have firewalls for a reason. So select a remote server that you have sudo rights to and let's get started building a tunnel.

Sudo rights are necessary because you'll likely have to edit your remote host's sshd config. (At least, I did.) Append this to the end of sshd_config:

GatewayPorts clientspecified

Now return to your handy-dandy facebooker.yml. Under the tunnel section for development, put in the username you have on the remote machine, the machine's URL, the port you can open on the remote machine (under public port), and the server you'll be running on your local machine (3000 is the Rails default).

Starting the tunnel is simple. From the root of your app:

rake facebooker:tunnel:start

You'll be asked for your SSH password to the remote server. If the connection is successful you will see nothing on this terminal session. Open up a new terminal and start your local server on your local port.

Navigate to http://apps.new.facebook.com/canvas_path and your server will report this routing error:

Congrats, we're up and running... sort of.

Getting on the Rails

We're seeing this error because Facebooker expects a route to be generated with :conditions => {:canvas => true} if it's intended for consumption by Facebook. We have no such route and there's nothing in our app at this point anyway. But now that we've finished with the Facebook side of this application, let's work on getting something in Rails that Facebook can understand.

A good place to start is our first scaffold.

script/generate scaffold airplane model:string pilot:string destination:string arrival:datetime
rake db:migrate

Unfortunately scaffolding won't do a whole lot to help us right away. We have to modify the Rails-generated files fairly significantly before our Facebook page will work. To start with, open up config/routes.rb. At the top you'll see map.resources :airplanes. Change that to:

map.resources :airplanes, :conditions => {:canvas => true}

And while we're here go ahead and uncomment map.root and change it to:

map.root :controller => "airplanes"

Now our controller is connected correctly, but if you try to refresh you'll see we're getting 406 errors: the format that the request is coming in is unacceptable to the webserver. Fixing that is as easy as opening up config/initializers/mime_types.rb. Append this line to it:

Mime::Type.register_alias "text/html", :fbml

Restart your server after you save.

FBML will now be correctly processed by Rails, but your application still doesn't understand when to call FBML pages. You'll need to go into the airplanes_controller and change every format.html in a respond_to block to format.fbml. For example, after I altered the index action, it looked like this:

app/controllers/airplanes_controller.rb
 
# GET /airplanes
# GET /airplanes.xml
def index
  @airplanes = Airplanes.find(:all)
 
  respond_to do |format|
    format.fbml # index.fbml.erb
    format.xml  { render <img src='http://www.pathf.com/blogs/wp-includes/images/smilies/icon_mad.gif' alt=':x' class='wp-smiley' /> ml =&gt; @airplanes }
  end
end

After you've finished that, there's another fun task awaiting you. Now our application knows that it's receiving FBML and that it has to call FBML pages when it gets a request formatted in FBML. Unfortunately we have no files that are formatted with FBML: they're all HTML right now. So, open up app/views and change every file there from *.html.erb to *.fbml.erb. Yes, this is kind of painful, but it's over quickly.

When you're done, your views should look like this.

Finally, you need to edit layouts/airplanes.fbml.erb. <body> tags are illegal in FBML and must be removed before Facebook will process our page. For simplicity's sake, I usually remove <html> and <head> as well, since you can't change the head of the page anyway. My layouts/airplanes.fbml.erb ended up looking this simple:

app/views/layouts/airplanes.fbml.erb

<p style="color: green"><%= flash[:notice] %></p>

<%= yield  %>

The Fun Stuff: Getting Information

Finally! Now that this is all accomplished, if you go to your canvas page in your browser, you should see your local server receive the request and render the airplanes index. You can go through the regular scaffold actions here but it's honestly not very exciting. Didn't I promise some FBML at the beginning? All we've really got here is HTML. Sure, it's cool and all, but can't we do something more with it?

The key to that 'something more' is inserting the following line at the top of airplanes_controller:

ensure_application_is_installed_by_facebook_user

This is a standard before filter and it accepts :except and nly just like a regular one might. If a user encounters this filter they'll be forced to install your application. Installation empowers an already-existing controller method that I haven't referenced before: facebook_session. facebook_session is the Facebooker object that allows you to make calls to the Facebook API server but it wasn't doing us a whole lot of good before now, since almost no API calls can be made before a user installs an application.

After a user installs your application, this changes dramatically. We can now leverage the power of the Facebook API to pull from and push to the user profile.

A good, straightforward idea at this point is to automatically identify the Facebook user when they visit to your application. Create a user model and make sure it has a uid string field in the migration. Once that's done, let's put in a quick before filter in our airplanes_controller:

app/controllers/airplanes_controller.rb
 
  before_filter :get_user
  ...
 
  private
 
  def get_user
    @current_user =
      User.find_or_create_by_uid(facebook_session.user.id)
  end

Now you'll automatically load the @current_user every time they return to your Facebook app. You'll probably want to tie most of your application data to this user: their posters, their songs, whatever your Facebook application does, this is the easy way to identify the incoming Facebook user and get their stuff accordingly.

You can call any of a user's profile information from the facebook_session.user object, like facebook_session.user.name, facebook_session.user.books, and so on and so forth. (id obviously returns the Facebook user id for our subject.)

The Funner (More Fun) Stuff: Setting Information

Of course, our application can't reasonably be considered cool unless it can put messages all over a user's profile. Facebooker provides an amazing utility to do this that is almost hilariously under-documented: it allows you to set up ActionMailer-style models to deliver information straight to a user's profile!

Before we actually update the user's profile, though, we must have permission to do it. The new Facebook profile system requires you to specifically request permission to add your application to a user's profile; if you send information to their profile before you request information, you'll get a success message but nothing will appear on the user profile. Let's put in a cute little block in the airplane layout to bug a user to add our app to their profile:

app/views/layouts/airplanes.fbml.erb

<fb:if-section-not-added section="profile">
  <p>Add Airplanes to your profile to see it listed there.</p>
  <fb:add-section-button section="profile" />
</fb:if-section-not-added>

Thanks to the magic of FBML the if-section-not-added tags appear only if the section isn't added for the users; the add-section-button presents them with a button to add your application to their profile. Once they've added your application this section will disappear and you'll be able to update their profile as per normal.

To add information to a user's profile, make a new file in the models directory, and name it as if it were an ActionMailer.

app/models/user_mailer.rb
 
class UserMailer < Facebooker::Rails::Publisher
 
  def profile(user)
    send_as :profile
    from user
    recipients user
    fbml = "This is some test FBML that will be inserted into a user's profile."
    profile(fbml)
    profile_main(fbml)
  end
 
end

Obviously, the mailer is descending from Facebooker::Rails::Publisher instead of the regular ActionMailer. send_as :profile instructs the Publisher to send this as a profile update, rather than a mini-feed update or other Facebook content type. You can designate the user the profile update is from and the one that it's to: in my application they're both the same, but they might differ for yours. You can render the FBML from a file here too if you want.

Setting profile is the deprecated way of updating a user's profile: profile_main is the way used in the new Facebook styles, but for backwards compatibility include both here.

Now, from your controller, simply include this line in an action to update their profile:

UserMailer.deliver_profile(facebook_session.user)

The profile information will be packaged and sent off to the target user and will appear immediately in their profile (provided they've added your app).

Going Further

Obviously this is a very broad overview of the power of Facebooker, concentrating more on its installation and setup then how to really leverage its power. If you want to figure out everything it can do, the Facebooker tutorial on the Facebook is sure to be a great help to you. Otherwise my suggestion to you is to inspect the source of Facebooker to really understand its functionality. As I said at the beginning of the document, it is unfortunately not very well documented at all, but at least if you follow the advice I've posted here you'll have an excellent start for developing your Facebook applications.

Related posts:

1. Facebook Application Logistics for Team Development
2. Getting Started With Rails Testing Guide Now Available
3. Facebook Connect

One of the major barriers to entry for companies offering services around processing healthcare data has been access to data. Who has the data? Typically the insurance companies. At least they have it in the kind of quantities that makes doing serious data analysis worthwhile. Managed care organizations are in second place, but from there you get to piddling amounts quickly. As you move from the heavily consolidated payer end of the industry to the heavily fragmented provider end, the comprehensive data view of the patient is balkanized to the point of uselessness.

This data problem even effects the valuation of companies. I've seen healthcare analytics companies that provide services to hospitals and clinics valued at less than $10 million, while another company that provides the exact same services to insurance firms is valued at ten times that price. Here, as in all things, follow the money.

There have been public/private efforts to consolidate healthcare data in a central store, such as Regional Health Information Organizations (RHIOs). The architects of the RHIOs realized that doing a national information organization would be too unwieldy and smack a little bit too much of Big Brother, but the regional ones have been bad enough, turning into debating societies between vendors, technocrats, and politicians. This has lead many regional health organizations and hospital networks to start their own pseudo-RHIOs. Still, service vendors would have to strike deals with these local entities to get access to data.

Google Health seeks to level the playing field by providing a data repository for personal health data. Individuals would access a Google Health aware service by granting it access to their data. Provided that enough individuals join and enough provider organizations make it easy to import your data, the battlefield now moves from getting data to getting customers. Bring your data, we'll tell you if your doctor is any good or if that surgery is really necessary. We'll help you find the best Medicare prescription plan based on your actual health data and identify generic alternatives instead of the pricey medication that some former-college-cheerleader-turned-pharma-salesperson pitched your doctor.

Some other nice things about Google Health is that it has support for SNOMED. SNOMED is a newer form of encoding clinical data than what is typically used in the US today. There's a whole host of reasons to prefer SNOMED over our current systems (yes, more than one) of encoding today. One example would be that most clinical data that gets collected today is all about getting paid by the insurance companies. What do providers get paid for? Procedures, not diagnoses. Very often in clinical claims data you will run across individuals who have been diagnoses with something like asthma, just so the provider can be paid for treating them. There's no concept like "I am working this individual up on suspicion that they have asthma, but he may not actually have asthma." So the clinical record is littered with expedient diagnoses made just for purposes of getting paid. You can imaging the havoc this plays with doing meaningful data analysis. Anyhow, SNOMED has a richer set of codes that would enable providers to express these sorts of concepts.

Of course Google isn't alone in trying to crack the healthcare data puzzle -- Microsoft is pushing its HealthVault and WebMD and various health insurers with their own PHR (Personal Health Record) walled gardens may yet open them up to other service providers. Regardless, I think the next 5 years promise to be exciting for those of us that develop healthcare software. Finally, the chance for something besides Ajax and social networking to come out of the Web 2.0 cauldron.

---

Read more about Pathfinder's Healthcare Analytics Practince

Related posts:

1. Google Analytics Tracking Component for Flash Platform
2. Web Serice and Mashup Pros and Cons and the First Google Clone
3. Google Pitching Services to Small and Medium Sized Businesses

LinkedIn's Groups feature hasn't quite reached maturity yet, but my friend and occasional colleague Zack Frazier hasn't let that get in his way. Zack recently launched the Chicago Front-End Web Developers group as a way to help UI specialists network and connect.

According to their site, the LinkedIn folks are apparently hard at work making Groups more useful:

The groups directory is not currently open. We are working on creating a searchable directory for all groups. If there are groups you wish to join, you may click on the group logo from the profile of a group member and request to join.

In the meantime, you can join Chicago Front-End Web Developers using this direct link. Joining allows you to put your loyalties on display to prospective contacts (see screenshot).

UI folks, stand and be counted!

Related posts:

1. Big Changes Underway at LinkedIn for Groups
2. Chicago JavaScript Meetup Group draws a big audience with varied skill levels
3. Working effectively as a team of one: Five tips for front-end developers on Agile teams

I recently, belatedly started playing Scrabulous with various friends and I'm shocked at the just-okayness of its UI. The lack of an on-screen legend for the mechanics of the variously shaded bonus squares? Puzzling. The drag-and-drop interface for shuffling tiles around in your tray? Maddeningly persnickety. The mismatch between the word lookup feature, which uses thefreedictionary.com, and the application's own, internal whitelist of valid words? A real bummer.

Scrabulous provides an adequate ripoff of a venerable and justly loved board game. But the rough edges of its user experience suggest that Facebook still has plenty of room for folks who know how to polish a UI till it gleams. Sure, first-to-market advantage gets magnified on social networks. But as these new application platforms mature, I'm convinced user experience design can provide a compelling means of product differentiation.

Related posts:

1. Facebook Connect
2. Gmail, agile development and user experience design
3. The Importance of User Experience – Do You Understand It in Your Bones?

Mitchell Baker on the future of the mobile web

In a keynote titled "Opening the Mobile Web," Mozilla Foundation CEO Mitchell Baker argued that there should only be one web: Developers should be able to focus on building great web experiences, while only end users should have to worry about what which device they happen to be using. Data should be 100% portable. Search results collected on a desktop at home should be accessible from a smart device when that same user is on the road. What the end user can get to and do shouldn't be dependent on the type of device they have or the location they're in at any given time. That hasn't been the case so far in the mobile space; right now, device and service limitations cut off huge chunks of functionality for users on the go. Ultimately, however, there's no such thing as the mobile web. There are only mobile users who want access to everything no matter where they are.

Baker also made a strong case that the mobile space offers an opportunity for innovation; without 35 years of desktop GUI convention and 15 years of web-based expectations to bog them down, mobile user-agents are free to evolve in interesting directions. Mobile payment systems suggest that people want to do all sorts of unexpected things with their internet devices; browsing is an outdated metaphor. We should use the mobile web as an opportunity to abandon the mental constraints of the desktop and the browser. (This point echoed Mosaic/Netscape veteran Marc Andreesen's keyonte, in which he expressed surprise that the browser had lasted this long as a standalone application.) According to Baker, the problems with today's mobile browser are all engineering problems, which our industry is good at fixing. But we must also expand our creative vision of what the mobile experience can become.

Up to this point, I was totally down with Baker's analysis. But when she used that analysis as a springboard for Mozilla cheerleading, she sort of lost me. She highlighted some of Mozilla's ongoing mobile experiments - such as Fennic - and suggested that they would play the same function in the mobile web that Firefox has played in the open web/Web 2.0. But she didn't provide much supporting data as to why and how.

I'm about the biggest Firefox cheerleader there is, but to date, Mozilla has played almost no role in the mobile space. Competitors Opera and Safari actually have a foothold on today's devices. Mozilla has a lot of catching up to do if it wants to be a player. I kept expecting a concrete product or distribution announcement to support Baker's claim that Mozilla would lead us to a better mobile future. In the end though, she had nothing but vague promises and specious logic. It's a shame that somebody with so many smart things to say had to undercut them with meaningless PR.

Jonathan Zittrain on the lure of the walled garden

Jonathan Zittrain proved more persuasive in his examination of the "gated communities" that are starting to undermine the open web. An Oxford and Harvard law professor and author of "The Future of the Internet - And How to Stop It," Zittrain didn't bother to hawk his book explicitly. Instead, he condensed its ideas into a 10-minute video lecture about the dangerous allure of the programming model used by systems such as the iPhone. It's tempting for both users and developers to adopt closed systems in which a central gatekeeper handles security and decides which applications are allowed to be run. The stability and predictability of such a platform make it seem far less scary than a completely open model. But there are hidden costs.

The "winner take all" network effect makes data portability a huge issue. If Facebook becomes "tomorrow's Friendster" - i.e., a must-miss destination - then what happens to all the information "mouse droppings" you've accumulated there? What happens when platform developers reserve the right to toss your application on the scrap heap after you've invested enormous assets into building and marketing it? And how might the power you cede to these platforms make it easier for government to step all over your civil rights? If your personal data happens to live in the Google cloud, does that mean you should be entitled to less protection?

Zittrain wasn't all doom and gloom. He didn't offer specific solutions to all of the problems he identified, but he did suggest that we should put pressure on platform developers to architect their walled gardens in ways that protect application developers and end users. If all of your personal data migrates to the servers of a few companies, government gets a free pass - a single point of access to snoop on you. It's up to platform developers, then, to "tie [their] hands to the mast" - to architect in a way that protects privacy and portability.

Venturing into historical analogy, Zittrain described the Constitution as "U.S.A. 2.0." In the early days of the country, if you didn't like somebody, you could just "move west." But as time went on, we needed an operating system for government, and that's what the Constitution became: a big shell game in which power was spread out among many entities. Many lessons from that era resonate today as we build powerful social communities and knowledge-sharing endeavors. "Whom do we trust ultimately to clean it up," Zittrain asked of malware, spam, wiki vandalism and other open-web dangers. His answer? Ad hoc community networks in which we add more elements of citizenship to the net. Instead of writing a check to Norton Antivirus to protect us - "the Pinkerton model" - or turning to the government, we should share responsibility among the citizens of the web. "If your ethos is just to call an 800 number to get help, then we deserve the future we're going to get."

Related posts:

1. My Web 2.0 Expo slides now available online
2. My talk at Web 2.0 Expo this Friday
3. Which Mobile Platform Should You Target – Other Points of View

Using case studies from Blogger, Flickr, YouTube, Digg and Wikipedia, Newitz explored the various ways in which user-generated content can be flagged by community members and summarily banished to the void. She harshed on services - Blogger, Flickr, Digg - with poor transparency into their processes and insufficient recourse for those flagged. She also showed the love to services - Wikipedia, YouTube - with more complex, detailed and "byzantine" rules for flagging content.

Her logic? Such complex rules force would-be community censors to get specific about why they're flagging particular items. Wikipedia, for instance, offers seven different directives for its content. To flag content for removal, users must cite the specific directives that have been violated. Lots of discussion ensues.

Newitz's advice for those creating social platforms and user-generated content networks? Offer users clear content guidelines and an easy way for them to filter the content they don't want to see. Offer authors transparent and fast methods of redress when they feel they've been unfairly flagged.

Her closing remark: "We need to protect against the mania of crowds" as well as celebrating their wisdom.

Related posts:

1. The Expert List – An Idea to Improve Online Social Bookmarking
2. Web 2.0, Communism, Pet Rocks and the Wisdom of Crowds
3. Web 2.0 Expo keynotes

Facebook is a unique platform for application development -- Facebook applications have a powerful API, a large user base, and low barrier to entry. With the Rails Facebooker plugin, a Rails programmer can treat the Facebook user data as an extension of existing Rails session features. It's all very nice, and I'm not going to talk about any of that this time around.

I'm going to talk about the logistics of doing Facebook apps. When a user sends a request to a Facebook app, Facebook intercepts it and forwards the request to the third-party app server, along with some specific Facebook data, like the ID of the user making the request. Applications have to be registered with Facebook, and have a unique URL prefix at apps.facebook.com. You also provide the URL for your third-party server.

This sets up some challenges for a development team. First off, your application probably relies on Facebook services, meaning it can only be fully tested from within Facebook. This implies that the external Facebook server needs to be connected to your development server. Since many Rails developers run off their own development machine behind a firewall, this is potentially awkward. Similarly, the fact that the Facebook application has a single URL mapping makes it difficult for multiple developers to work on the same application without tripping over each others' work.

How can a development team make this work?

The Facebooker plugin offers a service to create an SSH port tunnel from the open URL and port you designate on your development laptop. This works, although depending on your network setup, you may have some firewall hoops to jump through. Furthermore, your IT or networking department may have qualms about letting a tunnel from Facebook through to your developer subnet.

So, the question becomes how to put the developers work on some kind of staging server without putting too much friction in the system from the developer's perspective. I'm not sure that we've completely licked the problem, but the solution we're starting with seems reasonable.

What we've done is set up a staging server with a series of open ports. Each developer works on the program locally, and we've set up a fast mini-deploy from the developer's machine to the staging server for testing.

Each developer sets up a public-key SSH connection with the staging machine and signs up for a specific port. Within Facebook, each developer sets up a scratch application for use on whatever project they happen to be working on and points that application at the staging machine and that developer's port.

Moving files back and forth between the developer and staging severs is managed by a series of Rake tasks. Each developer sets up a staging.yml file in their config directory:

remote_username: nrappin
remote_host: x.x.x.x
remote_directory: staging_app
remote_port: xxxx

The main rake task is a simple rsync call to the staging server based on the parameters in the YAML file:

require 'yaml'

namespace :remote do

def ssh_host
"#{@remote_username}@#{@remote_host}"
end

task :config do
staging_yaml = File.dirname(__FILE__) + '/../../../../config/pathf_staging.yml'
config = YAML.load_file(staging_yaml)
@remote_username = config['remote_username']
@remote_host = config['remote_host']
@remote_directory = config['remote_directory']
@remote_port = config['remote_port']
end

task :rsync => :config do
sh "rsync -az . #{ssh_host}:#{@remote_directory}"
end
end

With that in place, the command rake remote:rsync will transfer the entire app to the staging server.

All kinds of single commands can be run remotely -- this batch opens an SSH shell, runs database migrations, and then mongrel starting, stopping and restarting.

task :ssh => :config do
sh "ssh #{ssh_host}"
end

task :db_migrate => :config do
sh "ssh #{ssh_host} 'cd #{@remote_directory}; rake db:migrate'"
end

task :mongrel_start => :config do
sh "ssh #{ssh_host} 'cd #{@remote_directory}; mongrel_rails start -d -p #{@remote_port} -e staging'"
end

task :mongrel_stop => :config do
sh "ssh #{ssh_host} 'cd #{@remote_directory}; mongrel_rails stop'"
end

task :mongrel_restart => :config do
sh "ssh #{ssh_host} 'cd #{@remote_directory}; mongrel_rails restart'"
end

Rake lets you combine these into some useful combinations

task :deploy => [:rsync, :mongrel_restart]
task :start => [:rsync, :mongrel_start]

That's a reasonably easy deploy to the staging server (which doesn't stop me from forgetting to do it now and then). You can make it even easier by binding it to a key command in your text editor, or if you are feeling really ambitions you can bind it to fire anytime a file in your application is saved (the way autotest works).

This setup lets each developer work in their own sandbox with only a minimal amount of deployment overhead. When the time comes to go to production, the application is registered for real with Facebook, and gets its final API key and URL information.

Related posts:

1. Ideal team size for your next Facebook project
2. Getting Started with Facebooker
3. 20 useful Facebook/FBJS developer resources

The first release candidate for Songbird 0.5 is now available for download. Songbird, as you may remember is the open-source, Mozilla-based media player/web browser we've been enthused about for the past several months. There are lots of bug-fixes and API changes this time around, but the big news from a UI standpoint is the debut of "Media Pages," which are extensions that rewire the main music-browsing interface using HTML or XUL.

As the Songbird website puts it:

As of this writing, Songbird ships with two default views: a simple traditional playlist view, and a second playlist view incorporating three filter panes across the top for choosing a subset of your music.  Views can be extended via extensions that implement Media Pages.  Developers can easily create new views as HTML pages or XUL pages which provide custom visual interfaces to Songbird libraries, and playlists.

Developers looking to play with Songbird 0.5rc1 will find the following resources useful:

• Announcement
• Release Note
• Tutorial: Getting started with Media Pages

The Songbird team is targeting a final release of 0.5 later this month.

Related posts:

1. Songbird 0.6rc2: Finally, editable metadata!
2. Coming soon: Songbird 0.4
3. Songbird 0.3: Why aren’t Ajax folks more geeked about “the Firefox of media players”?

While there were many architectural considerations at hand, one of the interesting aspects of the project for me dealt with how we structured our team and went about tackling the problem.  As a result, I have a bit of advice on team size for those of you considering similar projects with an existing team at your company.  But first, a little history...

The only thing that was clear to all of us before the project kicked off was this: that the scope of the project was anything but clear.
While we had worked on some preliminary analysis and modeling of the
problem domain (i.e. the 'what'), building services for use by Facebook
as well as the existing infrastructure required addressing a few
technical issues (i.e. the 'how').  By the time we were given the green
light to start work on the Facebook component, we scoped out enough
work for a team of only four developers-- a much smaller team than some
had guessed at earlier.

I think everyone in the team (both Pathfinder employees such as
myself, as well as the in-house developers) would agree that the small
team size ultimately worked to our advantage.  Much of our initial work
involved investigation, weighing our options based on what we
discovered, and evolving the architecture accordingly -- activities
which require too much internal coordination in larger or more
distributed teams.

So how did it work?  We had morning standup meetings (the occasional
afternoon standup on particularly busy days when issues came up).  We
were sure to talk through any changes in design or direction.  We
documented things on the wiki that made sense to document, etc...

You might be wondering by this point what team size has to do with
Facebook per se (after all, 'Facebook' appears in the title of this
post).  And there lies the lesson in it: developing a Facebook
application for an existing infrastructure is less about understanding
Facebook than it is about managing technical risk-- particularly when
it comes to the question of scalability.

"How scalable does it need to be?" is not just a question
posed on the last slide of a PowerPoint presentation while you are
waiting for the lights to turn back on in a room full of your peers.
When the size of your user base is unclear (as it often is with sites
like Facebook), scalability is the essential question.
That said, the question is almost rhetorical when the work involves
integrating disparate systems.  And it is a question that I'll tackle
in future posts, but I mention it here because I believe it is the kind
of question that a small team, working on-site and iteratively is
best-suited to answer.  And it is rhetorical in nature because the
"answer" to the question is never really "the answer", but rather a
series of approximations to "an answer".  And this is not a number in
some guy's head or a series of lines on a chart somewhere-- it is a
combination of design + testing + profiling, backed up by a certain
amount of contingency planning along the way.

This contingency planning aspect involves making parts of the system
malleable enough as-you-go so as to allow quick changes in response to
issues that arise (or are likely to arise).  And this planning
can not be done up-front.  It requires a bit of creative thinking along
the way, and occurs primarily through the development process itself.
Your team starts to see how the parts of the system scale in proportion
to best-case, worst-case, and likely-case scenarios, and you make a few
educated guesses.  But more to the point of team size, you need to
communicate all of these thoughts and ideas effectively across the
team, distill them and plan those contingencies accordingly for the
life of the project.  Everyone needs to understand these issues and
feel comfortable explaining them to each other.

To an experienced team this all comes as second nature no matter the
size, but when starting out on a new project, small teams tend to get
better at it faster. Throw in an unfamiliar API and a short deadline,
and prepare for the realization that less is sometimes more.

So what's the answer?  Is it four? Is it eight?  Is it ten?  Well,
the answer depends largely on your development team, how much
integration work you require, where you need to budget, etc..  And only
after painstaking analysis and hours of meetings will you arrive at the
right answer for you*.

*(and, oh, that answer?  It's 'four').

Related posts:

1. Facebook Application Logistics for Team Development
2. 20 useful Facebook/FBJS developer resources
3. Getting a team over the fear of daily scrums