When you create anything serious on Ruby on Rails, you will most definitely need to start thinking about caching. As Ruby is a high-level language, a lot of crunching goes on to make the magic work. So in order for all this magic to work you should ensure that the heavy-lifting is done only once and after that you just use the results.

Good news is that caching in RoR is very powerful standard feature.

When should you start thinking about caching? It definitely pays off to know the proper ways to cache in RoR before you start coding anything serious. However, the optimization could be done at some later point, analyzing which queries, screens and views give you the most trouble.

Here’s how you should start with caching:

1 – View all the railscasts.com caching tutorials first. Although Ryan Bates does not go into details on the theory behind the caching, the ability to see a real-life example and get an easy explanation is priceless.

2 – After that read the “official” introduction to caching on the RoR site. You might want to skip some parts at the first reading.

3 – Finally, you should invest your time in the advanced video casts on Rails scaling by true experts NewRelic. These courses are made free for all to use – perfect!

Something that you might have to watch out for when working with Ruby is how it works with variables. Ruby variables are only references (pointers) to objects. Therefore, you might experience a subtle behavior that you probably don’t expect. Try this out in your irb:

irb(main):001:0> a = "some text"
=> "some text"
irb(main):002:0> b = a
=> "some text"
irb(main):003:0> a.object_id
=> 23109650
irb(main):004:0> b.object_id
=> 23109650
irb(main):005:0> a.gsub!(/ text/, "thing different")
=> "something different"
irb(main):006:0> b
=> "something different"
irb(main):007:0>

First, we assign a String object “some text”. We could have written it fully as a = String.new(“some text”).

Second, we say b = a, and for Ruby this means that b will now point to the same object as a, and you can verify it by running object_id on both variables. But now comes the catch – if you modify a, b will be automatically modified. So, by running gsub! on a, we also modify b.

However, if you assign a new value to one of those linked variables, the link breaks down, as now one of the variables points to another object. So, if you type a = “some new text”, b will not change, and actually a and b will now point to 2 different objects.

If you want to create a copy of an object and point a variable to it, instead of b = a, you could have cloned the object: b = a.clone.

If you are wondering, like me, what was the “timing attack” fix update in the latest 2.3.4 for, you can read this post here. Basically, if a comparison is made between two strings, it’s done one character at a time, and it stops when the first differing character is encountered. Therefore a potential hacker could measure how much time it takes to check a cookie hash to see if it’s correct or not.

It all seems far fetched, given that surely there must be the overhead in terms of routing from attacker’s PC to your server and Internet Protocol actually works that way that the packets are sent using different nodes, but there are guys who think it’s practical. It’s claimed that most Java programs are exposed under this theoretical vulnerability, so it’s actually not a problem particular to Rails.

However, the bad news about this 2.3.4 patch is that it doesn’t work under Ruby 1.9.1.

1 – Hashes in method calls

You must have seen this syntax in Rails a lot, for example when using this Paperclip plugin, you would put this in your model:

has_attached_file :photo, :url => "/:class/:attachment/:id/:style/:basename.:extension"

While it looks pretty natural, you might have harder time understanding that has_attached_file is really a method, and there’s a considerable amount of trickery involved to make this method call much easier on your eyes. This post will not only help you read the Ruby code better, but actually create the methods with flexible parameters yourself.

Consider this equivalent call:

has_attached_file(:photo, {:url => "/:class/:attachment/:id/:style/:basename.:extension"})

Now, it’s more clear that has_attached_file method passes 2 values, where a second value is a hash. Allowing hashes in method calls gives a great freedom for both the developer and user of the method – you do not need to remember what’s the correct sequence of the parameters for the method and it’s possible to omit some parameters altogether. So, instead of some_method(first, second, third), you can use a more flexible some_method :second => second, :first => first, :third => third.

Do note, that if you omit the round brackets, you should also omit the curly brackets, so that the hash is not confused for a block, which also uses the curly brackets.

Actually, if you look at how the method was defined in paperclip plugin, you will see this:

def has_attached_file name, options = {}
  ...
end

This method definition (def) uses the fact that Ruby makes brackets optional even for method definitions, so it’s equivalent to this definition:

def has_attached_file(name, options = {})
  ...
end

And what it means is that has_attached_file method expects 2 parameters. The one called options is a hash and it defaults to an empty hash. Actually defaults are quite powerful in Ruby – you can pass any arbitrary Ruby expression to them and call any variables in scope and link to any other parameters. You could have said, for example – def has_attached_file name, options = name.size.

So, how would you access those values passed in the hash? This is very easy, you would do something like this:

def has_attached_file(name, options = {})
  size = options[:size] || 0
  file = options[:file] || "undefined"
end

So, you would check for a hash element with a key :file and if it exists, assign it to the file local variable. If it does not exist, you will (by using ||) set a default.

2 – How many parameters do you want?

Another common way to define a method is like this:

def some_method(*args)
  ...
end

This means that however many arguments can be provided and they will all be moved into array called args, so that you can access them as a normal array. You can also do something like:

def some_method(first, *args)
  ...
end

This will move the first parameter to first local var, all others (if any) will go into the args array.

3. Define your own method on fly?

Another thing you will notice a lot in Rails, is the possibility to define the methods on the fly. And great thing about it is that you can create the method name using any variables and Ruby expressions. Here’s another example from the Paperclip:

define_method "#{name}=" do
  ...
end

This will create a method using the name variable, so that you can have access to this method based on the name of your choice. For more info you can see Ruby docs.

Rails 2.3.4 is out, just a few weeks after the 2.3.3. There are no new features, the reason for this quick release are the 2 vulnerabilities found in the Rails code (one is a possible XSS epxloit and the other is a cookie hack. The release notes state that over 100 small bugs were fixed as well.

However, given the amount of problems some users have (see some comments here) – mostly as it seems with Ruby 1.9, you might want to just patch the vulnerabilities for now, or at least test before you upgrade on production .

Updating Ruby, Rails and other installed gems is pretty easy.

1 – Run the command “gem outdated”, to see which of your installed gems need updating.

2 – Update the gems itself by running

gem update --system

3 – Then if you want to update all the gems, simply run the command “gem update”. If you’re running the command in Windows, you should probably run “gem update > result.txt”, which will output the results of the command in the text file, so that you can take a look if any error were reported in the process.

4 – Finally, if you made an update of Rails, you will need to manually change the version your project uses by going into config/environment.rb and finding and changing this line:

RAILS_GEM_VERSION = '2.3.3' unless defined? RAILS_GEM_VERSION

When making project of any size you will most probably find yourself repeating code from one model in the other, be it similarities in models, controllers or views. This time I would like to explain how you can take out any repeated code in your views by using partials.

In order to call a partial from your view, you will need to use a render(:partial) method, like this:

<%= render :partial => "common/tags", :locals => { :thing => @artist } %>

1 – So, “common/tags” tells Rails to look for your partial called _tags.html.erb (remember the underscore in front – this is an easy visual way to say that the view template is a partial) in directory app/views/common.

2 – The :locals hash sends all needed variables to the partial. In our case we are sending @artist variable as a local variable called thing. You can send as many local variables as you need.

Now, let’s look at the partial:

_tags.html.erb:

	 <b>Tags:</b>
	 <% thing.tags.uniq.each do |tag|%>
	 <%= link_to tag.name.capitalize, tag_path(tag.name) %>
	 <% end %>
	 <%= link_to "Add more tags", edit_polymorphic_path(thing) %>
     <% end %>

1 – You see that the partial works with whatever the view passed to it in the local thing variable. As it’s a local variable there is no @ in front.
2 – As the partial does not really know what thing really is (and doesn’t need to in our case, apart from the fact that the thing should have tags method), if you want to include links in the partials, there are some easy to use methods for you:

link_to "Show this thing to me", thing
link_to "Edit this thing", edit_polymorphic_path(thing)

1 – The first notation is very useful short form of link_to – you can pass whatever object in place of the link and Rails will generate the right link to this object’s show method (it works with RESTful resources).

2 – The second is the same but for editing any object. Just use edit_polymorphic_path(thing). It will create an edit path for your object automatically. You can read more about polymorphic routes here.

So, this way you can make your partials generic and not dependent on the type of object being passed to it. If you will need to know what the thing being passed really is an object of, you can always check the thing.class.name property, which will return a string with the name of its class. But if you need to branch your code based on class of the object passed, you might not need to move it to a partial in the first place.

These sites are extremely helpful for anybody starting out with Ruby on Rails:

1 – Rails API. A must for getting any information about Rails methods, etc. Can be a bit overwhelming for a total newbie, but becomes vital for any intermediate developer. Sometimes the descriptions are not detailed enough or do not provide enough examples to “get it”, so additional search in google may be in order

2 – Ruby Docs. Unofrtunately Rails API doesn’t include the Ruby methods and classes descriptions, so you sort of need to move between the two, if you don’t remember if include? is a method of Rails or Ruby.

3 – Stackoverflow. A really great resource for quickly getting your questions answered or searching for a solution to a problem. Some of the very experienced Rails guys give free and valuable advice there, highly recommended!

4 – Rails Forum. A good resource for searching solutions for encountered problems. Some questions do not get answered though .

5 – Railscasts. Great free short video tutorials on many, many topics. The pace, level of detail, comprehensibility are all top-notch, you should spend as much free time watching those as possible

Hope it helps. Do include additional suggestions in the comments to share with others

A good post on the official Ruby on Rails blog goes through advice of the Ruby development team on how to start learning Ruby.

Ok, you’ve installed the Ruby on Rails and you want to run a quick tutorial to see what can be done. Let’s do a simplified Journal application that allows to create users & posts.

1. Create a new rails project by running a rails name_of_the_project command, like this:

rails journal

You will see a bunch of “Created xxx” messages, that will create or copy over a bunch of directories and files.

2. Next, let’s create a Scaffold for our users. Scaffold is a basic structure of Model, View and Controller that allows you to quickly create, edit, show and delete objects. Let’s assume that each user will have a name, a biography and email for now. We will use a generate script in order to automatically prepare all required files for us. Here’s the command:

ruby script/generate scaffold user name:string bio:text email:string

3. So, in the step before we have created a User model, user controller and user views for each of the basic functions of create, edit, show and delete.

The model now consists of three attributes which will be recorded in the database columns, named name, bio and email. In your Rails code you will access those attributes by something like @user.name, @user.bio or @user.email.

However, the generate script does not create the model in the database, it just creates the migration file in the db/migrate folder of your project. You can check out the directory to see that a file create_users.rb (with a timestamp in front) is actually there. If you will need to extend the model later, it can easily be done by running another migration.

Ok, let’s run the migration by typing the command:

rake db:migrate

4. Now, run the server to check that everything works as expected:

ruby script/server

And try out the following address: http://127.0.0.1:3000/users

It should show you an interface to create / edit / delete users

5. Let’s then create a model for our posts. Here’s the same command we used for creating users:

ruby script/generate scaffold post title:string post:text

And, as before, you need to modify the database by running a migration:

rake db:migrate

6. Now, we want to be able to merge these two models together. What we want to say is that a User can write (have) many posts and each post has to be written by a (belong to) user. This is very simply done in the model definitions:

In app/models/user.rb add has_many :posts association

class User < ActiveRecord::Base
 has_many :posts
end

In app/models/post.rb add belongs_to line:

class Post < ActiveRecord::Base
 belongs_to :user
end

Now Rails knows that Posts and Users are related and you should be able to get a list of posts of a particular user by simply typing @user.posts and vice versa – an author of the post will be @post.user. This is really cool!

Before it all works, however, you need to provide Rails with a place in the database to store the relationship. It’s done by including the id of user to the Post model (you don’t need to store / modify anything in the User model). The notation Rails follows is [related_model_name]_id, in our case user_id. And then Rails will be able to do all the wonderful relationships.

You can use the already used generate script, but this time a command migration will be used:

ruby script/generate migration add_user_id_to_post user_id:integer

And run the migration again (you should start to get used to that command by now):

rake db:migrate

7. Now it’s time to modify our default views to take advantage of the new relationship. First, let’s show the author’s name of the post. Go to app/views/posts/show.html.erb and add lines 6-9 to it.

<p>
  <b>Title:</b>
  <%=h @post.title %>
</p>

<p>
<b>User:</b>
<%= link_to @post.user.name, @post.user %>
</p>

<p>
  <b>Post:</b>
  <%=h @post.post %>
</p>

<%= link_to 'Edit', edit_post_path(@post) %> |
<%= link_to 'Back', posts_path %>

Let’s analyze what this command does – link_to @post.user.name, @post.user

First, I already mentioned that you can get the author by accessing @post.user. @post.user is actually an instance of user and you can access any attributes of user, so in order to get the name of the user you write @post.user.name. link_to is a clever method that allows you to create a link to a controller or object. The first parameter is the title of the link, the second is the url. As link_to is a smart method, you can simply pass an instance of a class to it and it will figure out how to link to it.

8. Now, let’s show all posts of a user when you show a user. For that we need to modify the user’s show view (app/views/users/show.html.erb), adding lines 16-23:

<p>
  <b>Name:</b>
  <%=h @user.name %>
</p>

<p>
  <b>Bio:</b>
  <%=h @user.bio %>
</p>

<p>
  <b>Email:</b>
  <%=h @user.email %>
</p>

<p>
  <b>Posts:</b>

  <% @user.posts.each do |post| %>
    Post: <%= link_to post.title, post %><br/>
  <% end %>
  <%= link_to "Create new post", new_post_path %>
</p>

<%= link_to 'Edit', edit_user_path(@user) %> |
<%= link_to 'Back', users_path %>

Ok, this one took 4 non-HTML lines, let’s go one by one:

@user.posts.each do |post| — we access the array of user’s posts and iterate through each of them by using iterator each. each is the easiest way to go through all the object in an array. The iteration passes control to block and puts each element one by one of array in local variable post.

link_to post.title, post — this is almost the same as we did for post’s user earlier.

end – this is to say to Rails that it’s the end of the iteration block

link_to “Create new post”, new_post_path — By this line we allow a new post to be created. First parameter is the string for a name of the link, second – is again a cool way to link to action of a controller [action]_[controller]_path

9. Finally, when we create a new Post we need to be able to select who is the author of the post by selecting the author from the list of available authors. In app/views/posts/new.html.erb before the lines <p> <%= f.submit ‘Create’ %> insert the new field:

  <p>
    <%= f.label :user_id %><br />
    <%= f.collection_select(:user_id, User.find(:all), :id, :name, {:prompt => true}) %> </p>
  </p>

The first line simply creates a text label of the field. The second creates a drop down list of all users in your system. The most important are the first 2 parameters – :user_id, which tells the form which variable to store the result of selection in and User.find(:all), which provides a list of all users to the drop-down.

10. Now save all changes and run the application at http://127.0.0.1:3000/users

This is an impressive application given that it took you only 5 minutes, 15 lines of code and couple of command-line commands. Of course, you will need to extend it with a proper user authentication and you will want to modify models and views to make the app useful, but it’s a great start.