Rails Coach

The idea behind convention over configuration is that rather than having several or one large configuration file to set up the framework for you to use, Rails uses conventions to determine how things should work without configuration. In many cases in Rails, there are ways to override the default convention, but most people stick to the conventions.

The conventions make it easy to set up and get started with Ruby on Rails. They also make it extremely easy for a person unfamiliar with your Rails project to step in and figure out what is going on.

Some of the conventions in Rails are the following:

A model's class is the camel cased singular version of its table name. The file name is the underscore cased version of the class name. The table name is the underscore cased pluralized model name. So, for example, the User model will be /app/models/user.rb and correspond to the "users" table in the database.

Similar conventions apply to controllers, helpers, views, and tests.

Ruby on Rails routing can be a little confusing. Here are some of the high points.

The root path is specified by the 'root' method. It matches the '/' path and behaves like 'match'.

The 'match' method will match the requested path to the string passed to match and route to the controller and action specified.

# Sends requests to /users/list to PeopleController#index

match "users/list", :to => "people#index"

You can also extract variables from the path.

# Matches /user/1/edit and passes '1' in params[:id]

match "users/:id/edit", :to => "users#edit"

You can specify which HTTP request methods are valid for a route.

get "users/index"

match "users/index", :to => "users#index", :via => :get

You can also name a route and use the related helper methods.

match "users/index", :to => "users#index", :as => "user_index"

#In some controller or view

user_index_path

# => "/users/index"

user_index_url

# => "http://localhost:3000/users/index"

You can also create RESTful resources around a model. See the Rails Guides for details.

resource :user

Finally, you can add to a RESTful resource when needed.

# allows you to post to '/users/1/make_admin' and get '/users/show_admins'

resource :user do

post :make_admin, :on => :member

get :show_admins, :on => :collection

end

Rails Engines are a terrific way of mounting on Ruby on Rails application into another.

A Rails Engine is basically a Rails application with an Engine class installed. The main application—the application your engine is mounted into—uses the generators, rake tasks, and routes from engines automatically. As of Rails 3.1, rake tasks are provided to move migrations and assets into the main application.

You can use Engines to add features to your current application or you can use it to provide an entire section of your website.

Ruby has a package manager for its libraries or gems. It should be a concept familiar with other package managers like apt, yum, or yast.

Gems are libraries for Ruby. Many gems are built to extend Ruby on Rails and are a great way to add functionality to your application. You can see available gems at RubyGems.org. In order to install Rails, you typically need Rubygems installed via a "gem install rails". To get a pre-release version of Rails, you can run "gem install rails --pre".

Gems for use in your Rails application are included in your Gemfile. Once you've specified the gems, run "bundle" or "bundle install" to get the gems you need. You can set up a test group to include testing and debugging libraries and exclude them in production environments.

Bundler handles dependency problems by evaluating dependencies and then chooses the libraries that meet all dependencies.

Rails Migrations are generally pretty straightforward, but there are a few things that people do that wind up giving them headaches later on.

First, don't change migrations once they've been committed or deployed. This causes problems because ActiveRecord tracks migrations that have already been run. So, editing a migration that's already been run will result in your changes not being made.

Second, use Rails' built in migration and model generators. It generates the id number in the front of the migration from a timestamp which minimizes that possibility of having a collision on the migration's identifier.

Third, create mapping tables in your migrations so your connections work. When you do these migrations, make sure you have ":id => false" on your "create_table" call.

When creating mapping tables, eliminate the meta data on the mapping unless you're using a "has_many :through =>" relationship. Adding meta fields to mapping tables will be deprecated in Rails 3.1.

Fourth, add indexes to all foreign id's. Those are the "_id" columns in your tables. I've used the rails_indexes plugin for this.

Fifth, don't reference Models in your migrations. If your Model implementation or attribute sets change, your migrations may no longer work. Instead, call "execute" with your SQL queries to update and save data in the database in your migrations.

Finally, go check out the Ruby Rogues podcast! You can also get my interview with Tom Preston-Werner from Github here.

Libraries for Authorization controls in Ruby on Rails are not nearly is prolific as they are with Authorization. The one I typically use is Cancan.

The thing I like about Cancan is that it provides fairly granular model level controls. You have to do the checks—Rails won't do them for you—but they are fairly straightforward. The other thing I like about it is that it provides some Controller level controls through a before filter you can include that will pull up the model, load the object, and check permissions before loading the Controller action.

Ideally, a good Authorization library allows this level of control at all three levels of your application.

In a lot of web applications, you need to control who can access your data. Authentication is the key to this type of security. Ruby on Rails has some plugins and gems that make authentication pretty easy. Here are a few:

restful-authentication

authlogic

devise

When putting authentication together, make sure that your authentication schema provides encryption for your passwords and a salt to make it more difficult for hackers to figure out which users are using the same password.

Also make sure that your failed authentication messages read "Your username or password is incorrect." rather than pointing out which specific field is incorrect. This will prevent hackers from mining your usernames and trying to guess their passwords.

Lost password messages should also report success every time. Since you won't be able to decrypt the passwords, you should always give a message like "An email message has been sent to you to reset your password" even if the username or email isn't in your system.

Finally, to avoid problems where people are sniffing networks with tools like firesheep to get usernames, passwords, and session cookies. Make sure that you're encrypting your logins and sessions with SSL. Use the ssl_requirement plugin to take care of this for you.

Here's the video:

And the transcript:

Rails Coach Podcast episode 6.

Hey everybody and welcome back to the Rails Coach Podcast with Charles Max Wood, that’s me. This week we’re going to be talking about authentication. But before we get started I really want to talk about where things have been going with this podcast. It’s kind of been an exploratory mission for me to kind of figure out how I want to talk about Rails. The thing is that I’ve had the Teach me to Code podcast for awhile, and I really didn’t feel like once I moved it from the Rails Coach podcast to the Teach Me to Code Podcast that I could talk as deeply about Rails, and so I wanted to talk about that there.

The problem is that I’ve been talking about things that I feel like are better explained through demonstration as opposed t o actually talking about principles that people should know when they’re programming in Rails. So what I’m going to do is I’m going to kind of change tactics a little bit. So I’m not going to go into as much things like; you should use this tool, you should use that tool. Well, I am, but I’m not going to go into how they’re used, I’m not going to go into what they are. What I’m going to try and do instead is I’m going to talk about general principles around certain things that are relevant to Rails. So, for example, this week I’m going to be talking about authentication, so I’ll probably bring up a few plugins or gems that you can use for authentication and I’ll talk about a few of the principles that define good practices for these different things.

So in this case I'm going to be talking about authentication, and there are things that I see that people generally get right, and there a few things that I see that generally people don’t get right. I see these things, some of these things, done on these huge sites that have thousands and thousands of users and I’m flabbergasted that this is there because it’s so simple to just write a script that takes advantage of some of this stuff. And so I'm just going to jump right in on the authentication stuff.

First off, I just want to talk a bit about the history of authentication with Rails. It all kind of started, as far as I can tell, with the restful-authentication plugin that was written by Rick Olson. This was probably four or five years ago. And restful-authentication took advantage of the RESTful approach that Rails had implemented at the time and proved an authentication scheme where it used the RESTful paths like GET and POST and PUT and DELETE, to manage sessions, and so sessions were the resources that the restful-authentication handled.

There are a lot of tools for testing Rails. Here are links to several of the ones mentioned in this podcast.

Test Unit

RSpec

Cucumber

Mocha

Flexmock

Factory Girl

You can find my interview with David Heinemeier Hansson here, and my response to his comments on Twitter here.

Finally, here are a few other resources for you to get started with testing Ruby on Rails.

Introduction to Outside-In Development with Cucumber

Here's a transcript of the podcast:

Rails Coach Podcast, Episode 5

Hey, everybody, and welcome back to another Rails Coach podcast. This is Charles Max Wood and this week we’re going to go into testing Rails. You can test Rails in a lot of different ways, and we’re going to talk about some of the libraries that are around for doing that. I’m also going to talk about my approach to it; some of the things that I’m thinking about doing or changing – and I guess we should just dive right in.

First off, I want to point out that there’s been a discussion on Twitter about Test Unit vs. RSpec. Now, if you’re not familiar with Ruby on Rails or who David Heinemeier Hansson is, then I recommend that you go listen to the “Teach Me To Code” podcast. I interviewed David on that podcast and talked a little bit about Ruby on Rails. And that will give you kind of a feel for who he is. He’s the guy that wrote Ruby on Rails and he is the technical partner at 37signals that makes Basecamp and Highrise and a bunch of other products that I used to use. But I don’t anymore. And that’s not the topic for this podcast. Anyway, we’re going to go into some of the things that are available for testing Ruby on Rails. I’m going to go into, first off, the discussion that was had over RSpec and Test Unit. David Heinemeier Hansson, a while back, said that he and 37signals, they used Test Unit, and that Test Unit and Mocha, which is a mocking and stubbing framework were basically all you need for good Ruby on Rails testing. Then he later said that he was a little disappointed by the proliferation of RSpec and Cucumber because he felt like they were a little too complicated and had been cargo-culted upon the Ruby on Rails community. And that started a whole lot of discussion over whether or not RSpec and Cucumber were the right tool. There were people who came out and said, Oh yeah, David’s right. Test Unit all the way. And other people came out and said, Hey wait a minute, RSpec all the way. David, you’re an idiot. And some people had kind of the reaction that I had where we thought about it for a minute and said, I’ve been using Test Unit or RSpec for a while, and I really ought to explore what the differences are and why I might want to use one over the other. I really haven’t had a chance to do that. However, I have used both; I’ve used both on different projects. And so I think it is worth discussing testing tools that are available for Ruby on Rails and what you can do to learn this stuff. So we’ll jump right in here. First off, I use – I’ll let you know – I use RSpec and Cucumber, and I use Factory Girl to generate my objects that I am going to be testing against. And then I use FlexMark for mocking and stubbing. That’s more or less what I use. Now, with Cucumber I use Capybara. And then I’ve recently started using Culerity and Celerity to test my JavaScript. And that has been working, actually, really well.

So, basically I use RSpec to do some of the testing in Cucumber. For example, you can write your assertions or dot-shoulds in Cucumber steps, and if they fail then your Cucumber scenario fails. RSpec I also use for my unit tests. And unit tests are just class-level tests. They usually use some method of mocking or stubbing to isolate your object so that you can test one way or the other, or if you have a dependent object, then you don’t necessarily have to mock that out. It’s a matter of preference as to how deeply and how thoroughly you mock things out. In my case,

You can get the video version of this podcast here.

I've also updated the audio files for episodes 2 & 3 so you can hear them now. Sorry for the trouble.

Ruby on Rails provides some excellent ways to validate the data you save in your models. Validations are methods called within the class definition specifying an attribute to check and what to look for.

class User < ActiveRecord::Base

validates_presence_of :username

end

Validations are called when you call 'save', 'create', or 'valid?'. If there are validation errors, create will return a new but not saved (to the database) version of the object you were creating. 'save' and 'valid?' will return false.

You can get validation errors from the object by calling 'errors'.

I also go over some of the common validations in the podcast.

Single Table Inheritance is a slightly advanced topic in Ruby on Rails. It stems from class inheritance, which is a core Object Oriented Programming principle.

In Ruby, if you inherit one class from another, you use the '<' operator. Here's an example:

class Truck < Car

end

In Rails, this gets tricky because when inheriting a Model, do you use the parent models connection and table? or your own? By convention, you use the parent's table, which means that you need some way of differentiating the Trucks from the rest of the Cars.

So, by adding a 'type' column to your table—which is a string—you activate a Rails convention that stores the subclass' classname in the type column. So, in the case of the Truck class, you'd have all of the Car's attributes and a type column that is populated with the string "Truck" to denote that it's a truck.

When doing a Model lookup on your database, Rails tacks on the "AND type = 'Truck'" for you.

Download this Episode