I was quite confused when I saw lines like this in controllers that I was working on:

class SessionController < ApplicationController
  def create
    user = User.find_by_email(params[:session][:email])
    password = params[:session][:password]
    if user && user.authenticate(password)
      sign_in user
      redirect_to user
    else
      redirect_to sign_in_path
    end
  end
end

Sign in user? Is it that easy? Do I just type what I want in plain text, and the computer will know what I’m talking about?! Well, no, of course not...but as someone new to the system, these sorts of conventions can be really confusing.

If you find yourself in this position, then you are probably coming from another language where class inheritance worked differently from Ruby. I come from a JavaScript background, where the mechanics of prototypical inheritance and the syntax of calling an instance method make it less likely to find unexpected methods floating in free space.

The key thing to remember with Ruby is that, not only is inheritance easy (‘ class Foo < class Bar’), but that classes and modules can be opened and modified again and again throughout its life. This is a wonderful and flexible feature of the language, but it also makes it difficult to track down where something was defined (and more importantly what it does!). This problem is especially pronounced when you are a Rails newbie jumping in on a team project, as there are often third-party libraries and custom architecture at work in deeper levels of the application where they may not be apparent to you.

I’ve found it fruitful to check the following three places if you’re wondering, “where the heck did this method come from?” :

1) Is it a built-in Rails method?

Don’t forget that almost all of the objects you will use to architect your application inherit from a Rails class. These parent classes, aside from gluing together different Rails sub-systems, provide the developer's subclasses with tons of useful instance methods. Seemingly free-floating methods you might call in your controller (‘params’, ‘session’, or ‘render’), for example, were all defined upstream of your particular controller by Rails and thus are automatically available as instance methods, even though you don’t explicitly see them defined. For those of us from JS backgrounds, it can be helpful to remember that these method calls could all be rewritten as ‘self.params’, ‘self.session’, or ‘self.render’, (the ‘self’ referencing the controller instance just as ‘this’ references a new instance object in JS). The Rails documentation is a great place to look to get a list of these methods and their purpose, as well as the relationships among Rails objects.

1. For models you’ll want to start with ActiveRecord::Base. All of your models inherit from this by default.
2. Controllers inherit from ActionController::Base, but they are flush with methods that are provided by a wide array of ActionController modules.
3. Views - The ActionView::Helper module will get you started on learning all of the helper methods Rails exposes to your view templates.

One thing to keep in mind here is that much of the functionality available in a particular class will be provided to it by a module. The list above references some modules, like the ActionView::Helper module. This module is included in the ActionView::Base class, which is why methods such as ‘link_to’, etc. are available in your templates. Reference the ‘Included Modules’ section of the documentation above to start to map out what modules are available in these classes by default.

module AuthorizationMethods
  def sign_in
    cookies.permanent[:remember_token] = user.remember_token
  end
end

class ApplicationController < ActionController::Base
  include AuthorizationMethods
end