Rails Coach

CoffeeScript is a language written by Jeremy Ashkenas that compiles to Javascript. Its syntax is much more friendly than native JavaScript. Especially if you're used to languages like Ruby or Python.

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)

A generator is a way of creating code from the command line. Rails has several of these built in, including generators for models, controllers, tests, helpers, scaffold (models, views, and controllers that support Rails' RESTful routing), and much more.

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.

NoSQL is a terrible term for a collection of widely varied databases. You have key-value stores like Redis, Tokyo Cabinet, Memcached, etc. You also have document databases like couchDB and mongoDB. Finally you have column based systems like Cassandra. And still others like HBase.

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.

I've been using Backbone.js for a few weeks and really like the way it helps you manage your data on the client side. It's also a terrific way to keep your UI in sync when your data changes through Javascript events.

One of the most handy websites out there for people trying to find specific API's in Ruby is ruby-doc.org.

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.

I've been using VIM for a while to do my development. It's a terrific text editor that has been around for quite some time. Here's the rundown of what I've got set up.

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

A counter cache is a handy way to speed up queries where you only need the number of an associated model rather than the entire collection. In your code, you might see something like this:

@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 _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:

If you're adding this to an existing system, you'll probably have to add a data migration to set the counts.

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.

Eager loading is a terrific way of speeding up your response times. Let's consider a piece of code that pulls a list of associated objects from the database. For example, a view that displays the posts written by a given user:

<% @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.

//= require jquery

//= require jquery_ujs

//= require_tree .

//= require_directory tooltips

 

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

/*

*= require reset

*= require base

*= require_tree .

*= require_directory tooltips

*/

 

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)

About a month ago, I talked about ActiveRecord Callbacks. Observers are a way of moving callbacks out of the Model. Usually this is done to adhere to the Single Responsibility principle. So, for example, programmers will move sending an email when a record is updated or created to an Observer.

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.