Hoopla!

now with extra whiz-bang!

Hoopla!

RESTless design - do I need a session controller/model?

August 19, 2006 · 11 comments

Today the underground team of rorBB (an as-yet-unannounced Rails BB) saw that the application was almost completely RESTful – except in it’s login/logout actions on the users controller. It was Ben who pointed out that it was the single thing destroying our otherwise pretty URLs and we decided to do something about it.

I admit that I’ve been slow to get on the REST bandwagon. Why is that you proverbially ask? To tell the truth it’s largely because I CAN’T FIND A DEFINITION ANYWHERE. I went to Wikipedia, oracle of all wisdom, only to be told how it differs from RPC. I have a long, rich history of coding in PHP. That means I dont know shit about real programming and I had to then go and lookup RPC.

So forgive me if I act like this is the biggest, most amazing discovery ever. I’m just really happy that I discovered it before everybody had moved on to the Next Big Thing©.

So, regarding our controllers: the code we had was fairly generic. On the users controller there were the standard `new`, `create`, `update`, `edit`, etc. actions but then we had two others:

UsersController with RESTless actions:

  def login
    if request.post?
      user = User.authenticate(params[:name], params[:password])
      unless user.nil?
        session[:user_id] = user.id
        redirect_to users_url
      else
        flash[:error] = 'Username or password is incorrect'
      end
    end
  end

  def logout
    reset_session
    redirect_to :action => 'login'
  end

In other apps I’ve written this was pretty standard. Sometimes they’d be in a ‘users’ controller, sometimes in an ‘auth’ controller that contained just these two actions.

It wasn’t until I saw a lot of high-quality REST programming that I started to see there was a better way of doing things than just throwing actions in controllers that might fit.

So we talked about the possibility of overhauling our code to allow for a sessions controller that followed the basic verbs of REST. I figured it would take a while but might eventually pay off.

Boy was I surprised to find that even an idiot like me could put it together quickly. Here’s the final code from the sessions controller:

class SessionsController < ApplicationController

  def create
    user = User.authenticate(params[:name], params[:password])
    unless user.nil?
      session[:user_id] = user.id
      redirect_to users_url
    else
      flash[:error] = 'Username or password is incorrect'
      redirect_to new_session_url
    end
  end

  def destroy
    reset_session
    flash[:notice] = "You are now logged out" 
    redirect_to new_session_url
  end

end

If you ignore a couple of slight improvements in the second piece of code you might notice that I ONLY RENAMED THINGS. Can you believe it? Our whole app fit back into REST with some very minor changes.

So, what’s the benefit of the sessions controller? Well, besides getting a free API (though you may never need to build a session over API) the tests got simpler, the routes.rb file got WAY, WAY simpler (back to just one line of code for all our controllers), and our team got just a little bit happier.

And who doesn’t like to be happy?

Update: By request, here’s the original and the modified routes.rb file:

1
2
3
4
5
6
7
8
9
10
11
12
13
ActionController::Routing::Routes.draw do |map|

  map.connect '', :controller => 'forums'

  map.resources *%w[forums topics posts users]

  map.resources :users, :collection => { :login => :get }
  map.resources :users, :collection => { :login => :post }
  map.resources :users, :collection => { :logout => :post }

  map.connect ':controller/:action/:id'

end
1
2
3
4
5
6
7
8
9
ActionController::Routing::Routes.draw do |map|

  map.home '', :controller => 'forums'

  map.resources *%w[forums topics posts users sessions]

  map.connect ':controller/:action/:id'

end

You might notice that even in the first file the routes are using the new map.resources command (normally used for this REST stuff).

→ 11 comments Tags:

AOL's enormous mistake

August 06, 2006 · 0 comments

reports today that AOL has decided to publicly release the combined search data of thousands of it’s users. This is quite possibly the dumbest thing AOL has done in years.

They’re offering a free download of the statistics for research purposes here. It’s their research department that’s releasing this in an attempt at goodwill – but it’s certain to backfire.

There’s no telling how long the file will be offered for download but I’m 28% of the way to a full file transfer and I’m already building a front-end so folks can seaerch the results.

Come visit aol.6brand.com in a few hours and you’ll be able to search through this “research data” on your own.

→ 0 comments Tags:

How to Launch a Website

May 29, 2006 · 1 comment

I wrote out a lengthy essay before I realized this is a rather straightforward endeavor. The how to’s of launching a (successful) website are simple and few. I’ll make this short. In fact, I’ll make it a list.

How to Launch a Website:

  • Make something that has value to a certain, specific group of people
  • Release it as soon as you have the minimal amount of functionality required for it to work.
  • provide your users with an easy way to contact you
  • Listen very closely to what your users tell you (and respond!)
  • Surprise your users with your candor
  • Surprise your users with innovative new changes shortly after launch
  • Never (NEVER) allow data that your user has added to the site to become lost or irrelevant.

That last one especially. You can have all the bugs in the world and the users will understand – unless you make them fill out the same form twice. That’s unforgivable.

→ 1 comment Tags: