To get your two-finger swipe navigation back, just go into the Mouse preferences and over to the More Gestures section. Change the first option (Swipe between pages) to use two fingers.

This will disable the full-screen swiping and get you back up and running. Doing the same thing on your laptop should work as well, except you’ll pick three-finger swiping instead of two.

Enjoy.

In the course of building the frontend application for Earbits, I’ve been constantly annoyed with the responsiveness of my local development server. As a pretty complex AJAX application, there are lots of little (and some bigger) calls to the Rails backend APIs to do lots of potentially slow things. This means that there are lots of calls that are originating in the browser and being served by one mongrel, so the server ends up handling requests too slowly. Which leads to me being frustrated. Which leads to me finding a nice solution to the problem.

Warning: This May Not Apply To You

If you have slow running requests that have to run in series, or if you’re not doing AJAX-y things, this isn’t going to help you much. This setup is only useful if your app sends a bunch of parallel requests to the backend. For instance, if after your main page loads, you need to do AJAX requests to a) load the user’s friends, b) get their comment history, c) calculate some suggestions, and d) check to see if you should show a popup promo to the user, then this might help you out. But if you need the results of request (a) to get (b) and the results of (b) to get (c), then you’re out of luck and this will be a waste of your time.

Ok, ready to do this?

Step 1 – Install Nginx

This is much simpler if you have macports installed. So go do that first if you haven’t already. If the first step below doesn’t do anything, you don’t have macports. Once you have macports, it’s a simple two-command process to install nginx.

$ sudo port -d selfupdate
$ sudo port install nginx +ssl +debug

Now, while nginx is installing you can open a new terminal window and keep going. The install will take a few minutes.

Step 2 – Configure Foreman

Foreman is a great tool released by David Dollar to make running web processes and workers crazy easy. It uses a Procfile to define the different things it controls and you should refer to his blog or a Google search to learn about the finer points of Foreman. We use a pretty simplistic file here as an example.

To get started just run:
$ gem install foreman

Then create a file called Procfile in the root of your project using the text editor of your choice. My Procfile has just one line that define a web process using the standard Rails server:

web:    bundle exec rails server -p $PORT

Step 3 – Configure Nginx

Now that nginx is probably finished installing, we can get it configured to act as a local Load Balancer for our Rails server. I’m going to set it up using port 80 locally. If you are running an HTTP server locally already on port 80, then you should adjust your configuration accordingly. But if you’re not using port 80, Rails redirects might cause you some headaches. So I suggest you stick with the standard port.

First, you’ll need to find your nginx.conf configuration file. If you used macports to install it, it’s probably in /opt/local/etc/nginx/nginx.conf but if you can’t find it, run nginx -V to see where it’s hiding.

If you’re not familiar with nginx at all, there are two main directives that you’ll be using, server and upstream. The server directive defines the front-end part of nginx (i.e. where it listens for incoming requests). The upstream directive defines the back-end (i.e. where to send requests so that Rails can handle them). Both of these snippets should exist within the http section of your config file. I’ll provide a complete nginx.conf at the end of this section so that you can just replace the default file and then tweak it if necessary.

Upstream section

This is the configuration that I’m using, I will explain it in a second:

upstream foreman4000 {
  server localhost:4000;
  server localhost:4001;
  server localhost:4002;
  server localhost:4003;
  server localhost:4004;
}

Here on line 1 we’re defining the upstream which we will reference later. Note that “foreman4000″ is just an arbitrary name used to reference it within the config. Then since we plan on running 5 web processes starting at port 4000, we list out each of the ports where our Foreman will be listening for requests.

Server section

This will define a server so that nginx will listen to requests on port 80 and direct them to the upstream we created above (line 6). We also pass the real IP of the request and the hostname along to the server (lines 7-9, in case you need either of these bits of data.

 server {
    listen       80;
    server_name  localhost;
    access_log  /opt/local/var/log/nginx/foreman4000.access.log  main;
    location / {
      proxy_pass http://foreman4000;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $remote_addr;
    }
 }

Test the config

After you’re done making the changes above (or if you download my nginx.conf example file), you should run $ sudo nginx -t to test the config and make sure it’s all good. If it fails, double check everything. If it’s good, you’re ready to start it up.

Step 4 – Start your Engines

Now all we have to do is start everything up. In your Rails project directory:
$ sudo nginx
$ foreman start -p 4000 -c web=5

Note: I use the non-standard port 4000 as the starting point so that other random servers can run on 3000 (rails default) and 5000 (foreman default) without conflicting with this setup.

If it’s working you should be able to open up http://localhost in your browser and your Rails site should load. In the terminal running Foreman, you should see it handing requests to each of the 5 web processes (web.1 – web.5) like this:

Now, enjoy your new, super-responsive AJAX server! I know I do.

Notes and Extras

There are a few reasons my local development environment is slow. Firstly, I’m using a hosted mongodb that is shared among a few of our developers so that we can more easily collaborate on work. It makes it possible for me to add a new feature and seed the database with some good example data, then hand it off to our UI guy to style it up with zero configuration on his end other than a git pull. Secondly, we make heavy use of the Facebook Graph APIs which can at times be sluggish over my mere-mortal internet connection. Getting someone’s friends might take a full second, posting something to a wall might take a couple seconds. You can imagine how with just one process running, it would get a bit slow.

The third reason our site is slow in development is the simple fact that it’s designed to be chatty. Instead of large monolithic views getting rendered for the user, we do a lot of client-side template rendering using underscore.js based on json data requested by the client app (which leverages backbone.js for much of the interaction logic). In production, this works great because we can fire up a bunch of web processes and everything scales on out. But in development, between the slow database access and the numerous calls, things can take seemingly forever to fully load. But not anymore!

BTW – if you haven’t tried Earbits out for your online radio needs, you absolutely should. Great way to discover new music, share with your friends and really just have a great time. And you should stop listening to so much Genesis anyway. It’s time for something fresher.

But while we’re working on the algorithm, it just does some neato analytics on your data. We’ll be adding more analytics once we get the friend import stuff working – we we can analyze how you interact with your friends and look for trends. Then we’ll really start to tackle the suggestion engine. We have what we think are some pretty cool ideas for that part.

Stats Dashboard

Fullscreen Map View

This is just a quickie screenshot set of what the stats look like for me (and I’ve only been using Foursquare for 2 weeks while building this app). If you want to sign up and play with it, let me know and I’ll get you the link to the beta site!

In your Gemfile, update the authlogic line to be:

gem 'authlogic', :git => 'git://github.com/odorcicd/authlogic.git', :branch => 'rails3'

Now you should run $ bundle install to grab the new gem. Then, there are just a few more deprecated things in Rails3 that you’ll need to change in your upgraded app. I’ll try to enumerate here from memory, so please forgive me if I forget something.

First, you need to update your ApplicationController because #requesturi is outdated. Replace it with #fullpath:

def store_location
  session[:return_to] = request.fullpath
end

Second, you need to drop the filter_parameter_logging setting from your ApplicationController because it’s now handled in the new application.rb file. Just remember to add the :password_confirmation field to the default array like so:

# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password, :password_confirmation]

Third, if your migration script (or the steps you followed manually) didn’t get rid of the /config/initializers/cookie_verification_secret.rb file, delete it now. Cookie secrets are now handled in the /config/initializers/secret_token.rb file.

Fourth, the f.error_message construct isn’t available anymore in core rails, so you should take this opportunity to create your own better more customizable error messages. If you really really want to keep using f.error_message you can install the dynamic_form plugin, but don’t do that. Railscast.com did a very nice explanation of how to create your own shared _error_messages.html.erb view (along with some other validation-related stuff.)

Finally, you need to make sure your generated pages include the csrf_meta_tag. Check out my previous post if you’re getting an InvalidAuthenticityToken error when you hit the Logout link.

That should be all you need to do to have Authlogic working in Rails3 without deprecated warnings.

This is the error message shown:
ActionController::InvalidAuthenticityToken in User sessionsController#destroy

actionpack (3.0.0) lib/action_controller/metal/ request_forgery_protection.rb:96:in `verify_authenticity_token'

And the solution is simple, you just need to add the new csrf_meta_tag helper to your generated page (probably in the /views/layouts/application.html.erb file).

...
<head>
  <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
  <title>Some Title</title>
  <%= stylesheet_link_tag :all %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>
</head>
...

Line 7 is the one you care about and need to have in your html.erb file.

This helper includes the appropriate meta tags which make the authenticity_token available to the handleMethod javascript function. In Rails3, links generated with the link_to helper which use a :method other than GET get passed through that handleMethod function in rails.js. That function creates a temporary form, sets some parameters and submits it. And if you’re using protect_from_forgery (you should be) all non-GET requests are checked to prevent Cross Site Request Forgery (CSRF). So, if those meta tags don’t exist on your page, the handleMethod function doesn’t know what your authenticity_token is, and the request will be rejected with the error above.

Line 5 below is an example of my main nav logout link that was causing the problem when clicked. No change was required to this code after doing the above fix.

<% if !current_user %>
  <%= link_to "Log In", new_user_session_path %> |
  <%= link_to "Register", new_account_path %> |
<% else %>
  <%= link_to "Logout", user_session_path, :method => :delete %> |
<% end %>

This isn’t specific to Authlogic’s logout click – any time you are using link_to now in Rails3 with non-GET methods, it uses unobtrusive javascript. And if you’re missing the csrf_meta_tag helper, any unobtrusive javascript posts will fail to validate.

I’ve been involved in the minor capacity of building the actual player used on the website and for embedded players on partner websites. It’s been a nice refresher of using my javascript skills. And now, I’m expanding my role into building the first mobile Earbits app for the iPhone. Since I’ve been trying to learn Ruby on Rails over the past week or so, I decided that I might as well also try and learn Objective-C and that whole mess too.

Keeps life interesting. But here’s the teaser shot taken right after the first time I actually deployed the radio app to my iPhone.

Hope to have a beta version done in a week or so, depending on API availability, and get it into the App Store sometime in September.

This method and code is inspired by two blog posts, which got me started but neither of which really fulfilled my complete requirement. The first used two records per friendship and the second was a twitter-style friend/follower without the approval process.

So, here I break down my Friendship model which hopefully you will find useful and/or insightful as a complete solution or a starting point for your own implementation.

First step is to generate a new model that we’ll call Friendship.  A Friendship will connect two users, tracking who made the request, who the friend is, and whether the request has been approved. So we generate it like so:

$ script/generate model Friendship user_id:integer friend_id:integer approved:boolean

This will create the db migration script and the app/models/friendship.rb file which we’re going to edit to include relationships to the User model. When first created, the Friendship model will be mostly empty so we need to add two lines.

class Friendship < ActiveRecord::Base
  belongs_to :user
  belongs_to :friend, :class_name => "User", :foreign_key => "friend_id"
end

The first line is obviously creating a relationship to the User model, but the second line is a little more complex. It also needs to create a relationship to the User model (there isn’t a Friend model) but we want to refer to this as the friend. So we have to specify both the :class_name and the :foreign_key so that Rails knows how to hook up this :friend field to actual models.

Now that we have a Friendship, we need to configure the User model to allow for these self-referential relationship through the Friendship model. Before we hit the code, let’s walk through the concepts here that define the state of friendships and friends.

A friendship is a two-way relationship which is initiated by one user and approved by the other user. So, we have two states of a friendship (not-approved-yet or approved) and we have two directions of friendship relative to the current user: friendships requested by the current user (we’ll call these “direct” friendships), and friendships requested to the current user (we’ll call these “inverse” friendships).

So using this terminology, we have 4 possible states of Friendship:
1) direct approved
2) indirect approved
3) direct not-approved
4) indirect not-approved

States #1 and #2 are simply what we will be calling “friends” – they are approved relationships, no matter the direction. Because we don’t care who requested the friendship once it’s approved, we will group these together.

State #3 is what we call “pending friends” – other users whom the current user has requested to be friends with and which are awaiting the other user’s approval. These are out of the control of the current user, and just waiting to be approved or rejected.

State #4 is what we’ll call “requested friends” – other users who have requested that the current user be their friend, and are awaiting the current user’s approval. These are the actionable items for the current user to approve. Ignoring a friend request simply deletes the non-approved Friendship, which is the Facebook method (doesn’t tell the other person they were rejected, but allows them to send another request if they want.)

Now that we have that groundwork, here is the User model:

class User < ActiveRecord::Base
  [...]
  has_many :friendships
  has_many :inverse_friendships, :class_name => "Friendship", :foreign_key => "friend_id"
  has_many :direct_friends, :through => :friendships, :conditions => "approved = true", :source => :friend
  has_many :inverse_friends, :through => :inverse_friendships, :conditions => "approved = true", :source => :user

  has_many :pending_friends, :through => :friendships, :conditions => "approved = false", :foreign_key => "user_id", :source => :user
  has_many :requested_friendships, :class_name => "Friendship", :foreign_key => "friend_id", :conditions => "approved = false"

  def friends
    direct_friends | inverse_friends
  end
  [...]
end

The first two lines are pretty self-explanatory as the first references our “direct” Friendships and the second our “inverse” Friendships which we’ll be using as the basis of all of our friend lists. Lines 5 and 6 simply create our direct and inverse friend lists, only looking at friendships which have been approved. These are states #1 and #2 from our discussion above and are complete, approved bi-directional friends lists.

Line 8 here creates the list of pending friends (state #3 above) by looking for direct friendships which have not been approved. Then finally in line 9 we handle state #4 which are the “requested friendship” waiting for us to approve them, by taking all the non-approved Friendships where the current user is the target of the request (which is why we specify the foreign_key of “friend_id”).

And finally, because it would be a hassle to deal with two lists of approved friends, we create a method to simply combine them under the name of “friends”, in lines 11-13.

That’s it! You should be able to create and manage facebook-style friend requests now.

I’m not going to cover creation of the Friendship controller here in this post, but I may in the future if people would find it helpful. In short, the controller needs to handle just five actions: index, create, approve, ignore, delete. In my implementation, all actions except for index are used only for ajax calls through link_to_remote, so they’re pretty lightweight.

Updated: the direct_friends line in the User model above was incorrectly using “:source => :user” when it should be “:source => :friend” so that the returned models are the Friends you requested, not yourself the requestor.

Yeah, the software puts the songs which have ratings above the songs without ratings, which in itself isn’t a bad idea. But this means that if you just start playing down the list of your favorite songs right after your favorite songs it’s going to play the songs you hate the most. Then it continues with the rest of your library in alphabetical order.

Come on, Microsoft… you can do better. Just put the most hated tracks at the bottom of the playlist when I sort by rating.

Long-term, I will probably host the app myself at my colo, but to keep things simple at first I don’t want to learn the intricacies of Rails hosting right now…

Clipped from RescueTime which is a fantastic freemium app that tracks everything you do on all of your computers and then does analysis of how you spend your time.

Pretty cool, huh?