As or Rails 3.1, CoffeeScript is available by default and a coffeescript file is created in /app/assets/javascripts every time you run the scaffold generator.

A few of my favorite features of the language are:

• I can ignore parenthesis (mostly), semi-colons, and curly braces
• Function notation
• Objects with nested notation
• Variable safety (not creating globals)
• Splats on lists
• Classes
• Always returns last expression
• String interpolation

I don’t like:

• Operator aliases

Resources:

• CoffeeScript Webpage
• CoffeeScript Cookbook
• CoffeeScript Basics (video)
• CoffeeScript: The Cool Parts (video)

Generators are actually relatively simple. They are made up of two parts. The generator itself, and the generator’s templates. In the Ruby on Rails source code there’s an assets generator and the javascript template and stylesheet templates it uses.

I’ve also created a model generator for my Sandra ORM. You can find it here.

Understanding how models work, you can see how simple it is for the Rails Core Team to build in generators for other things like models, controllers, helpers, tests, assets, mailers, etc.

To see the full list of generators available in a Rails application run `rails generate` or `rails g`.

To create your own generators in your project, put them under /lib/generators or better yet, use the generator for generators like this: `rails generate generator widget` and you’ll get a widget generator all set up for you in the /lib/generators folder that’s ready for you to customize.

In a lot of cases, there are gems for these. I’ve used several of them such as the gems for managing Cassandra, couchDB, and mongoDB.

From the main page, you can search or select your Ruby version.

From the core page, you can narrow down the class or method you’re looking for.

From the std-lib page, you can read docs and see where different aspects of the programming language are implemented.

On each class’ page, you can find the specific functionality you need in the menu on the left.

MacVim: http://code.google.com/p/macvim/

Janus: https://github.com/carlhuda/janus

I’ve also found a few resources to help me get better with Vim as well. Here are some of my favorites:

VimCasts: http://vimcasts.org/

VimGolf: http://vimgolf.com

@post.comments.count

When you run this code, you wind up with another query to the database to get that number. That’s not a big deal until you have that count being called for each post in your stream. To avoid this, you can use a counter cache.

To use the counter cache, add a <other_model_table>_count to the primary model’s table. In this example, it would be called “comments_count”.

class AddCounterCacheToPosts < ActiveRecord::Migration
  def change
    add_column :posts, :counter_cache, :integer
  end
end

With that migration in place, all you need to do from there is add :counter_cache => true to your other model—in this case Comment.

class Comment < ActiveRecord::Base
  belongs_to :post, :counter_cache => true
end

Now, whenever you create or delete a new comment for a post, it’ll update that counter_cache column on the posts table.

A few things to keep in mind are:

1. If you’re adding this to an existing system, you’ll probably have to add a data migration to set the counts.
2. This number is not checked each time it’s changed, so if you change the number, you’ll get results in the future relative to that number.

<% @user.posts.each do |post| %>
  <%= render post %>
<% end %>

(I know that partial has a collection option for things like this. I feel that this code sample is more expressive for our discussion.)

In this case, assuming that @user was loaded by calling User.find(1), your Rails application is going to go to the database for each post. So, if the user has 40 posts in the system, the Rails application will make 40 trips to the database to get the posts.

The problem is that if there is any latency on the database connection, it adds up.

The fix for this is the use of the ‘includes’ method when querying for the user. User#includes tells the query to pull in whatever associated records you specify in its arguments. So, if we found @user by calling User.includes([:posts]).find(1), it would pull the user’s record and all of the user’s posts records and cache all of the user’s posts on the user’s object.

The argument for ‘includes’ is an array. The objects in the array can be symbols or hashes. Symbols represent that associations the Model has. Hashes are used for including nested associations. For example, if we wanted to pull all of the comments on the user’s posts. Here’s another example:

# In the controller
@user = User.includes([:address, :phone_number, {:posts => [:comments]}]).find(1)

# In the view 
<% @user.posts.each do |post| %>
  <%= render post %>
  <% post.comments.each do |comment| %>
    <%= render comment %>
  <% end %> 
<% end %>

Assets in Rails before version 3.1 were kept in the /public folder. In Rails 3.1 they’ve been moved to /app/assets and function in a slightly different way. Here are some of the highlights:

• Javascript assets written in Coffeescript will now be compiled to Javascript.
• CSS assets written in SASS or SCSS will now be compiled to CSS
• Other templating languages like ERB can be used in assets
• JQuery is now the default Javascript framework in Rails 3.1
• You can combine Javascript files with the new directives
• Pre-compiled assets

When compiling from SASS, SCSS, CoffeeScript, or ERB, you simply add the appropriate extension to your .js or .css file. (.sass, .scss, .coffee, or .erb respectively)

To combine several Javascript files into one file, (for example application.js) just do something like this.

For several CSS files, it’s the same commands, just *= instead of //= and wrapped in /* … */. Here’s a quick example:

require pulls in a file. require_tree gets everything in the specified path. require_directory pulls in all the files in a given directory (no nesting).

You can precompile your assets by running bundle exec rake assets:precompile (For example, if your server doesn’t have a Javascript runtime on it capable of compiling Coffeescript.)

Here are some resources for CoffeeScript:

• The Coffeescript Website
• CoffeeScript Basics (video)
• CoffeeScript: The Cool Parts (video)

class UserObserver < ActiveRecord::Observer
 def after_create(user)
   UserMailer.sign_up(user).deliver
 end
end

Observers should be included in your app/models folder and named using the same convention as your models. So in this case, this observer would be saved to /app/models/user_observer.rb.

To load the observer in your application, you need to include this line in your config/application.rb

config.active_record.observers = :user_observer

Finally, you can observe more than one model with the same observer.

class SignUpObserver < ActiveRecord::Observer
 observer :user, :admin

 def after_create(user)
   UserMailer.sign_up(user).deliver
 end
end

I personally like Observers when they help keep you from repeating code or increase code readability. In many cases, I simply keep callbacks in models and violate the Single Responsibility Principle.

Here are some of the features you can add to your classes with ActiveModel.

• Attribute Methods
• Callbacks
• Dirty Attributes (knowing which attributes have changed)
• Naming (allows you to reference the class and model by the object)
• Observers
• Serialization (to JSON or XML)
• State Machine (a really basic one)
• Translation
• Validations

So, if you’re looking to add your Ruby class to a Rails app, or want this sort of behavior in Sinatra, etc. this is a great way to get it.

The first way of building a form that is probably the most common is by using the ‘form_tag’ helper and the form helpers to build forms. Here’s an example.

<%= form_tag ‘/login’ do %>
 <%= label_tag :username %>
 <%= text_field_tag :username %>
 

 <%= label_tag :password %>
 <%= password_field_tag :password %>
 

 <%= submit_tag “Login” %>
<% end %>

Pretty straightforward and it builds a standard login form. I’d get confused because there are also helpers that correspond to ‘label_tag’, ‘text_field_tag’, and ‘password_field_tag’ that do something very similar.

Here’s a user signup form that use these similar tags:

<%= form_tag ‘/signup’ do %>
 <%= label :user, :username %>
 <%= text_field :user, :username %>
 

 <%= label :user, :password %>
 <%= password_field :user, :password %>
 

 <%= label :user, :password_confirmation %>
 <%= password_field :user, :password_confirmation %>
 

 <%= submit_tag “Sign Up” %>
<% end %>

You’ll notice that these helpers use two parameters to build the form’s elements. It effectively scopes or namespaces those form parameters. They’ll be named “user[username]”, etc.

If you’ve gotten that much, then ‘form_for’ won’t be too much of stretch. ‘form_for’ takes a model object as a parameter and binds the form to that object. It does the namespacing implicitly, which means that ‘label’ and ‘text_field’, etc don’t need two parameters to name the element. Just one.

<%= form_for @user do |f| %>
 <%= f.label :username %>
 <%= f.text_field :username %>
 

 <%= f.label :password %>
 <%= f.password_field :password %>
 

 <%= f.label :password_confirmation %>
 <%= f.password_field :password_confirmation %>
 

 <%= submit_tag “Sign Up” %>
<% end %>

So, you’ll notice that the ‘form_for’ passes a parameter to the block. That parameter is a FormBuilder that contains the object, scopes the elements, and sets their values.

Finally, go sign up for the Rails course at http://railscoach.com/ruby-on-rails-courses/.

Generally people call these associations “something-able”. In this case, it would be commentable.

Here’s a quick code sample:

class Comment < ActiveRecord::Base  belongs_to :commentable, :polymorphic => true
end

class Page < ActiveRecord::Base  has_many :comments, :as => :commentable
end

class Post < ActiveRecord::Base  has_many :comments, :as => :commentable
end

The only other thing you need to know is the database structure. On the database, you need two columns. A [polymorphic-association-name]_type string column and [polymorphic-association-name]_id integer column. In this case, it would be “commentable_type” and “commentable_id”.

One to many is usually achieved by calling has_many on the model representing the “one” to state that it “has many” of its counterparts. The model that represents the “many” calls
belongs_to . Here’s an example:

class User < ActiveRecord::Base
 has_many :posts
end

class Post < ActiveRecord::Base
 belongs_to :user
end

In addition, the model that represents the “many” needs a reference column or foreign key for the “one”. In this case, the posts table would have a user_id column.

One to one works the same way one to many works except it uses has_one instead of has_many.

Many to many is implemented in one of two different ways. The first–and generally default–way of doing this is has_and_belongs_to_many. As you can imagine, this is used just like has_many or belongs_to except you call it in both models.

class Tag < ActiveRecord::Base
 has_and_belongs_to_many :posts
end

class Post < ActiveRecord::Base
 has_and_belongs_to_many :tags
end

Before filters are run on requests before the request gets to the controller’s action. It can return a response itself and completely bypass the action.

The most common use of before filters is validating a user’s authentication before granting them access to the action designated to handle their request. I’ve also seen them used to load a resource from the database, check permissions on a resource, or manage redirects under other circumstances.

After filters are run after the action completes. It can modify the response. Most of the time if something is done in an after filter, it can be done in the action itself, but if there is some logic to be run after running any of a set of actions, then an after filter is a good place to do it.

Generally, I’ve seen after and around filters used for logging.

Around filters may have logic before and after the action being run. It simply yields to the action in whatever place is necessary. Note that it doesn’t need to yield to the action and may run without doing so like a before filter.

You can use around filters for exception handling, setup and teardown, and a myriad of other cases.

Callbacks are a handy way of insuring specific behaviors on your models as well as managing the events that follow the callbacks.

For example, a before_destroy callback can be called to destroy associated objects. (This is best done on the association with :dependent => :destroy, but it makes sense here too.)

You can also stop the destroy process if you have dependent objects you can’t destroy by returning false.

I’ve used ActiveRecord Callbacks to:

• Set default values
• Format specific fields (like phone numbers)
• Send emails when an object is updated or deleted
• Create child objects from comma delimited lists in a string
• Change an object’s state

Last week I talked about extending your Ruby on Rails application. This is because in many cases in order to avoid repeating your logic across multiple classes (models or controllers) you need another place to put your functionality.

Mix-in modules, plugins, and single table inheritance all allow you to codify your knowledge into a single place depending on what you’re working with.

The DRY principle is more than just a way to avoid having to update multiple files when something changes. Rather, it’s a way of assuring yourself that things are done in a consistent manner.

It also helps you when you’re trying to find something in your application because there’s only one place where it can be found.

There are a couple of standard places people put code that isn’t a Model, View, Controller, or Helper:

• The ‘lib’ folder – This is sort of a “junk drawer” for your application. In Rails 3 your application does not load these files on its own. You can make it autoload by following the directions I found on StackOverflow.
• Rails Plugins – Rails Plugins are autoloaded by your Rails applications and can contain extensions to Models, Views, Controllers, Helpers, and to the app as a whole through Engines.
• Ruby Gems - Gems can do pretty much anything Plugins can do except they are not included in your application’s source. They are pulled in through Bundler.
• You can also add modules and classes to files within the app directory.

• ActionMailer – The basis for mailers. This is the library that allows you to format and send emails from your rails application
• ActionPack – The components that parse, delegate, and render responses for requests.
  • ActionDispatch – Parses HTTP requests and sends the requests to controllers.
  • ActionController – Basis for Controllers -Takes requests and request parameters and gathers data to render a response.
  • ActionView – Basis for Views. Determines which template to use and builds the response to the HTTP request from the templates based on data provided by the Controller.
• ActiveModel – Defines an interface on non-ActiveRecord classes that helps the behave like ActiveRecord models.
• ActiveRecord – Basis for Models. Manages the connection between the Rails application and a SQL database. Provides means of querying database to manage and find records.
• ActiveResource – Allows the developer to access network REST resources in a simple way.
• ActiveSupport – A collection of extensions to the Ruby programming language that can be used in your Ruby on Rails application.

You can read in more detail what these libraries are about and what they do on the Ruby on Rails github page.

The basic idea is that your set a breakpoint in your application, which causes the application to stop processing and allow you to access the application’s state and step through the methods being called in order to find the cause of your problem.

With the Ruby Debug library, all you need to do is require ‘ruby-debug’ and call ‘debugger’ where you want the application to stop.

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.

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

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.

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.

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.

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.

• 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. So if you logged in it was new session was basically what you were doing. And so you would do GET, a GET on session/new. And if you were doing, when you created your session then you would post a session or sessions, and when you would logout you would post a DELETE to sessions and it would log you out, and it follows the same RESTful scheme that Rails follows. And most of the plugins that you see, nowadays, for Rails follow the same scheme. So they do the same thing, they use the RESTful routes for that resource.

Another one that I used later on was Authlogic. And that was something that I think a lot of people were using a year or two ago. And it worked really well with Rails 2. I haven’t actually tried using it with Rails 3 and that’s because I had a friend of mine turn me on to Devise right after Rails 3 was released.

Devise is nice because it actually includes some generators and does 99% of the work for you. And, authentication, it’s nice to know what’s going on, but Authlogic was kind of complicated and Devise is also kind of complicated but it doesn’t involve as much to get set up, and so it’s a pretty handy little gem there. And all you have to do to get it is just “gem install devise” or include it in your Gemfile in Rails.

Anyway, one other thing that these and most good authentication schemes have is, they actually encrypt the password. And this is important because if somebody steals your database or, let’s say, you do a database dump of your database and you import it to your developer machine so you can work on it, you have all these passwords in the wild and if they’re stored in clear text then you’re just begging for someone to come in and take advantage of them. So you should be encrypting your password.

Now, one of the companies that I work for they encrypted their passwords but they didn’t provide what’s termed a ‘password salt’. And what the ‘salt’ is, is it’s actually a string. It’s added to the password before it’s encrypted. And the reason that you want a password salt is because if you don’t include on and you’re using the same encryption scheme for all of the passwords then if you figure out one user’s password, then you can figure out what anyone else’s password is, if it’s the same. So, for example, if somebody put in the password ‘password’ and you just used an encryption scheme and no salt, then all of those passwords which are just the word ‘password’ would encrypt to the same string in the database. So then all you would have to do is load this database up, do query against it, find all the other ones that have the same string in the password, in the encrypted password, and you’re golden. You have access to probably a few hundred accounts and you can go in and take advantage of them that way.

With the password salt, what it does is because you have like “password-123-salt”, which is, let’s just say that the salt is the word salt, what happens is then when you encrypt it then your password, even though it’s the word ’password’, and John’s password, even though it’s the word ‘password’, he have a different salt so they encrypted different values, different strings. And that works really nicely to help kind of obfuscate what’s going on. It makes it harder to figure out how to get in and you have to, if you can reverse the encryption then that works to get the password, but typically people are using hashes and just a hexdigest on a hash, so they’re using SHA or I’ve seen people use bcrypt, or a few others.

Anyway, so basically it’s not even reversible. There’s no encryption key to get to reverse the encryption on the password because ultimately that’s not the way they work. What they do instead is, when you authenticate what it does is it takes your username and your password that you pass in and it uses the password and it actually re-encrypts the password and it compares the encrypted passwords. If a site is not doing this then what you’ll sometimes see is when you request your password, when you go through their ‘forgot password’ stuff, they’ll email you back you’re actual password. And if they can give you back your actual password, in my opinion that’s not as secure as doing the other way, where you actually hash the password. The reason is, is because then if somebody gets in they can read a little bit of code, they can figure out where the encryption key is stored and then they can get everyone’s password. It’s one or two steps away from storing it in clear. It does protect if they only get the database and not the code that encrypts and de-crypts, but the hashes are pretty solid an really difficult to reverse so it’s a much cleaner and simpler way.

Now, I’ve seen the encrypted password stored in a different database field from the password salt and I’ve actually also seen it where the encrypted password and the password salt are just concatenated and stored in one string. And I think that, I always thought that was interesting, putting it in one string, because ultimately then, they have to figure out what part of the string is the salt. So you could stick it in the middle. You could stick it at the end; I think most of them stick it at the end. And I think that’s reasonable too because basically what you wind up with then is they have to know how many characters long your salt is and how many characters long your encrypted password is. And if they can’t figure that out then they can’t hack your password. So it’s just another step, another way of handling that.

Now, one other thing that I’ve seen done on these, on the ‘forgot password’ pages, that people do that I think is nuts is they actually, you put in your email address, typically, or a user name. And so you stick in the username and then what happens is when you click ‘OK’ like send me my password or send me a link to reset my password, which is what they should be doing (sending you a link, not sending you the password. When you put in a username or email address that doesn’t work, that’s not in the system, it’ll tell you that email address isn’t in the system. And if you can login with the email address then what you just got there is you got a, ‘Hi, this will tell you whether you’ve got a valid account name’, and just knowing that is half the battle. If you have and account name then all you have to do is just figure out what the password is.

So it’s another thing that you want to do. Every time that you fail to login it should tell you that the username or the password is incorrect. It shouldn’t tell you for example, that username is incorrect or the just the password is incorrect. It should tell you that one of the two is incorrect and then they can figure out, the user should be able to determine, OK the username is wrong or the password’s wrong. But don’t tell them which one’s wrong because that’s another way for people to start getting usernames and start trying to figure out how to hack your system. So whenever you give some kind of failure message just give a success message or give a general message that tell them that something is wrong. Or in the case of the ‘forgot password’ that they’ll get an email and then, if they actually own the email address, then they can get an email that says actually this email doesn’t appear in our system. And that’ll protect things.

One other thing I’ve seen with a lot of smaller sites and, you know, it’s kind of, I don’t know, this is the sys-admin in me jumping on this, but it’s something that you should consider, especially if your site does get big or you’re providing a paid service, is do you use an SSL encryption on your authentication. And the reason is is because there are programmes out there like Firesheep, which is a plugin for Firefox , that can actually sniff the network. And they’ll sniff it and if it’s not encrypted they can pick up the username and password off of the traffic. And so if they’re on a public network with some guy that’s trying to hack something, I think the big one for this was actually Facebook. But in general you really want to have that encrypted so that you’re protecting your users against an attack like this. And it’s critically important once start getting big and became a target for this kind of hacking. And if you take care of then what happens is the connection is encrypted and then they’re just getting garbled junk. I understand that getting an SSL key that the browsers will trust costs money, but again, if you’re charging for a service you can probably get one for $40/50, I mean, worst case scenario, I don t remember, last time I priced they were about that, the ones that I was looking at. And they’re signed by VeriSign, or somebody. And that will, the browser will just trust it and then you just make it work from there. So I highly recommend that. There is a plugin that was extracted out of the Rails core that allows you to do an SSL requirement and that’s defiantly something you should look into. Now, in general authentication is important because you want to control access to certain things, just make sure that you’re doing it securely.

In Rails 3 I think the most popular one that people are using is Devise. That’s D-e-v-i-s-e, I’ll put a link in the show notes. In Rails 2 I think it was split 50/50 between Authlogic and RESTful authentication. There are a bunch more out there, you can go and find them, they do all kinds of stuff. There are some that do OpenID, some that do OAuth some that do…I mean; they’re all over the place. So anyway, what I would do is I would just go and check them out. Install them in a dummy project, see what the migrations give you in your database and make sure that they’re encrypting the passwords and that you can set it up so that when you get a failure that your failure messages don’t give away that you’re, the username is correct or incorrect. And that when they forget the password that you provide them a link, a secure link, where they can come back and set they’re password. And by all means, just encrypt the thing.

Now if you need help with any of this, if you need help getting Rails set up or getting authentication working the way you want, feel free to give me a call, 8013676164. You can also email me chuck@teachmetocode.com If you want more of this kind of stuff I’m on Twitter as cmaxw. My name is Charles Max Wood.

• 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, I really feel like in a lot of cases people mock things out that they really don’t need to. Anyway, I’m not really going to go into that either, other than to say if it’s much simpler just to create a dependent object, do it. If there is a deep algorithm around or something that you haven’t implemented, then you can go ahead and mock or stub an object so that it will behave the way that you need it to in order to test the functionality in your unit test. If it is complicated functionality then you probably should be mocking it, just because if the implementation changes, your test result doesn’t change because the output changed. Because basically, in your unit test, when you are testing something that depends on another object, you should really only be testing its dependency on state or output from the other object. So, anyway, I use RSpec and RSpec gives you kind of a name-spacing feature, where you can do Describe, and then you give it a class name and then a block. And the block is a Do with code in between it and an End. And so then inside there you can do It, and then you give it a string that describes the functionality that you are testing, and another block. And then in that block you can do setup; you can do the actual test. So you get in and you can say, If I set this user’s name to Chuck, then when I retrieve the name from the user, it should be Chuck. And that is kind of a contrived example because in a lot of cases, that’s simple enough to where you would just assume that it is the case and you don’t necessarily need to deeply test it.

But anyway, I also use Cucumber. And Cucumber is kind of the top-down testing. It is built around an approach called BDD, or behavior-driven development. And the idea behind Cucumber is that you can write your specifications in plain English, and then you write steps that parse those – well, you write handlers for the steps that parse the step, and take the information from the step and actually execute it.

So what happens is, you can write something like, given I am logged in, and then what that does is you write a handler that can go and actually goes through the motions of logging you into the website. Then the next step could be “and I am on the home page.” So then it takes you to the home page, slash-home. When I click on Log Out, then it actually triggers a click event on the logout link. Then I should see “You’ve been logged out successfully.” And so then it looks for that content on the page. And it does everything from the top all the way down to the bottom, so you are testing not only your controllers and your views and your models, but you are also testing the interactions between them to make sure that it is displaying the right information. When you are testing things like controllers – when you are unit testing your controllers — in Rails if you use Test Unit then under your test folder you will see Unit, Functional, and Integration. And the Functional tests are your controller tests. You may also see tests for your views and other things. That’s something that they’ve added since I’ve started programming in Rails. I’m not a big fan of testing the views, and I’ll go into why in a minute. But anyway, when you are testing your controllers, then a lot of times what you are going to do is you are going to mock out your models. And then that way they are not dependent on the functionality of the model; they’re just dependent on the values that they are going to get back from the model. And so then what you can do is you can test and make sure that if you get a certain thing back from a method that you wrote on the model, then that gets passed through to the view.

Usually your controllers are pretty slim. Most of your functionality is in your model. So testing the controllers is really, really simple. Testing the views is a little tricky because you really can’t test good layout. There’s not a good way of doing that. So you typically wind up eyeballing it. So testing the view really means making sure that the right data shows up. And in that case, I feel like the integration tests are sufficient. Because then what it does is it makes sure that the data is in the database; it shows up in the view. And that’s exactly what you want. So I never really test the views.

You can also test things like routes and other things. And some of those are worth it; some of them probably aren’t. It really just depends on your understanding of things and your making sure that things work the way that you want them to. Now the testing is really important. I do TDD at the very least, and typically quite a bit of BDD. Which means that I write unit tests before I write model code. And I write Cucumber scenarios before I write the overall feature. And the reason that I do that is so that I understand how the interaction should affect the overall behavior of the application.

And it’s nice because if I really need to, then I can actually send the Cucumber feature over to my client, and they can look at it and say, Yes, this is how I want it to work. Or, No, it’s not. Or, I don’t understand. And then we can kind of work from there.

So it really is quite handy to have. And that’s why I use Cucumber. If I weren’t collaborating with my clients, then I would probably be tempted just to use the integration portion of the testing frameworks, either in RSpec or Test Unit. And simply use the Capybara library and test things directly, rather than writing out the English steps, because I find those a little bit tedious as a programmer. But I find that they are useful if I am collaborating with somebody that is not a programmer.

Anyway, those are some general thoughts on testing Ruby on Rails. You can go and find – I’ll put up some links to some resources on Cucumber and RSpec and Test Unit and learning how to use some of these things. And hopefully this helps you get started testing your Ruby on Rails application. You’ll find that as you get into the Rails community that this is a big deal. So, as you continue on your journey of learning Ruby on Rails, you’ll start to pick up – Oh, this is important, testing is important. And you’ll start to see why people do the testing and what they gain out of it.

Real quickly, I feel like I gain a couple of things from testing, especially TDD. One is that I feel like I understand a problem before I approach it, which really helps me write the code better. The other thing is, I know immediately if somebody else has changed something that breaks the expected functionality, because I’ve put these expectations on the code. So if somebody else is coding in the same code base and they break something, when I run the tests then I’ll get notified. And if I am running continuous integration, then that’s something that really works in my favor as far as letting me know immediately, when I checked in, that something broke. And letting them know too. Really, it’s just a good exercise in thinking about these things and writing great code. So that’s what I like about the approach.

Now, if you want to get a hold of me, you can get a hold of me at chuck@teachmetocode.com
If you want some coaching or you want to learn Ruby on Rails, then you can call me at that number or email me. You can call me at 801- 367-6164. That’s my cell, so you can get me just about anytime and I’ll pick up. I’ll be happy to walk you through whatever you are working on and help you get going.

If you have a Ruby or Rails or Sinatra or some application that you want me to build for you, I do that too. You can reach me in those same ways. I’m also working on posting the videos to these. And I just got some new software that does – what is it? – It’s transcription. So I got some software that should help me transcribe these episodes so that you can benefit from them in text as well as in audio. And I’m posting videos. It’s just kind of a talking head right now. On YouTube. So you can go on YouTube and see me talking to you, if you would prefer.

Those are great ways to do it. The show notes are at RailsCoach.com. Thank you for listening.

Finally, here’s the video version:

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.

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

In a nutshell, when a request comes to a Ruby on Rails website, it’s handed the dispatcher. The dispatcher consults the routes provided in the application to determine which Controller and action to pass the request to. A Controller is a class which has methods called actions on it. The request is handled by a particular action on a controller.

The Controller may then respond by gathering data from the database through the Models. I can then convert the Models’ data into text or pass it to a template called a View to return the response.

Most HTML responses (web pages) are returned by rendering Model data in a View.

Download this Episode

That being said, you don’t need to know the ins and outs to get started with Ruby on Rails. I didn’t when I got started.

It does make a difference in understanding how Rails works once you get past the basics.

Download this episode