Rails : Consider the view as stupid

It’s not a secret, putting business logic inside a view is a bad idea. Views should only contain HTML and presentation logic.
This is bad :

 some html here
<%  if(@my_nbr * 2) > 55 -%>
  Some more HTML
<% end -%>

This is better :

some html here
<%  if(@number_big_enough) -%>
  Some more HTML
<% end -%>

This is VERY bad :

some html here
<% if User.find_by_name("john") -%>
  The view is interacting with the model... not good.
<% end -%>

this is better :

some html here
<% if @john -%>
  @john has been resolved in the controller
<% end -%>

Consider the view as your most stupid MVC component (I’m sorry, view. I didn’t want to make you cry). Aside from “if” and “each”, the “V” component just doesn’t understand ruby code that much. That’s why you should set convenient instance variables in the controller that the view will find easy to use. When the view is rendered, every business rules must already have been resolved in the controller. The view don’t want to think by itself, it wants to be instructed what to do.
Moreover, a view should never interract with a model. The view is completely clueless about database related stuff. When it wants to know what to display, it queries the variables that have been set by the controller (with it’s very limited ruby knowledge) and expects a simple yes/no answer.
When the view needs to iterate through a collection, that collection must have been created and tested by the controller. The view just knows how to loop and how to display stuff, not how to fetch data.
I know that all of this may be pretty basic stuff to you, but sometimes it can be tempting to make a view looks more intelligent than it should. Views shine when they are clueless and stupid about everything that isn’t related to presentation in the same way that models shine when they are clueless and stupid about the application flow. When you think about it, the remaining component is the only smart guy out there. The controller knows how to query the model and how to prepare instance variables that will be consumed by the not so smart view. In fact, the controller is the only component able to see “the big picture”.
So let’s keep our views simple and stupid!
#UPDATE 04/28/2007
Dan and Alan made me realize that I didn’t talk about helpers. Helpers are indeed very handy when you want to keep your view clueless about all the nitty gritty details of your application. Instead of letting the view works by itself, it can remain lazy and instead call services (helpers) that will do all the complicated stuff and return a nice and ready to display result.

Are you concerned about ruby being slow?

This is a real question, I’d like to hear your opinion on this matter.
Ruby is known to be slow, even compared to other interpreted languages like python. It’s sad, but it’s true. Does it bother you? Well, don’t be shy, i’ll answer first : it bothers me. You probably heard of the recent twitter performance issues. Well, it appears that ruby is partly blamed for this. Of course, there are probably some implementation details that could be improved in this application (just speculating here) and Rails itself should also take a good part of the blame (e.g. some ActiveRecord features are known to be costly on the performance side of things). But for now let’s forget about Rails costly features and let’s focus on the programming language behind it.
We cannot hide behind hardware-is-becoming-so-performant-and-cheap-that-it-doesnt-matter kind of excuses anymore. While it’s true that buying better and faster hardware will mask the fact that ruby is inefficient, it seems like we’re just trying to put a plaster on the real problem. Ruby performance shortcomings must be addressed at it’s heart, that is, in the source code of it’s official interpreter.
Could YARV be the saving grace?
What is YARV? YARV is another virtual machine for Ruby like are JRuby, Rubinus and the official interpreter written in C (ruby 1.8). In other words, it’s simply another implementation of the programming language we love. YARV humorously stands for Yet Another Ruby VM. The smart guy behind this project is SASADA Koichi and his goal with YARV is crystal clear. Like he said : The goal of this project is only one, to develop the fastest Virtual Machine for Ruby in the world.
Is it faster than, say, JRuby? I don’t know, but I know what I like the most about it : YARV is expected to get merged into the official implementation of the language. What does it means? It means we would still be able to call ourselves rubyists and not yarvers (phew). Big deal huh? This detail aside, I think it is quite important that the official interpreter stops being qualified as the worst of all. For a lot of people (myself included), the official ruby interpreter IS ruby (we can hardly blame us for wanting to use “the real thing”, can we?). To me, the importance of having an official virtual machine that is efficient is crucial.
Now, I have two questions for you :

  1. Are you concerned about ruby being slow?
  2. Do you have faith in YARV?

Enumerations and Ruby

Enumerations are an elegant way to make your code more readable. Unfortunately, Ruby doesn’t have a built-in enum type. However, if you only want to use an enumeration like a set of constants logically grouped, it’s super easy to do. You only have to create a class and define constants in it :

class Color

If you need a more elaborate enum, that is, if you want to iterate through every items like if it was a collection, you’ll have some more work to do (but not that much) :

class Color
    def Color.add_item(key,value)
        @hash ||= {}
    def Color.const_missing(key)
    def Color.each
        @hash.each {|key,value| yield(key,value)}
    Color.add_item :BLUE, 1
    Color.add_item :RED, 2
    Color.add_item :YELLOW, 3
#That's it! We can now use our enum :
my_color = Color::RED if some_condition
#And we can loop
Color.each do |key,value|

Basically, we just used a hash in our class to make our enum behave like a collection.

  1. The add_item method is used to fill the hash and is called inside the class because we don’t want to give that responsability to the user of our enum. You’ll note that the calls to add_item are directly in the body of the class instead of being in the initialized method. That is because initialized is only called when you create an instance of a class (x = MyClass.new) and we don’t need instances of class Color.
  2. the const_missing method is used for convenience. We want to use Color::BLUE, not Color.the_internal_hash[:BLUE]. const_missing is called automatically when you try to access a constant that doesn’t exists. We then use that hook to return the hash element corresponding to the name supplied. We take for grant that this “missing constant” is in fact the desired key for our hash.
  3. We defined an iterator “each” to iterate through the collection. We could also have created an attribute reader that returns the hash and let the user of our class iterate from there. (like that : Color.items.each do …)
  4. We don’t create instances of class Color because we don’t need to. Everything happens at the class level, or if you prefer, in the object called Color. I could have enforced that behavior by preventing (if such a thing exists in ruby) users to create instances of that class, but I don’t think it was essential.
  5. In a recent article, I said that it wasn’t useful to use an instance variable (@) inside a class method. Well, this example demonstrates that it isn’t strictly true. If your class is also the only instance you need, variables that only live in this instance are useful.

How to access a class method from an instance

If you bet that this post would fall in the “short & sweet” category, you won… a new car! (The price is right music starts while Bob Barker looks at you with a subtile smile)
To access a class method from an instance, you have to use a reference to that class (because that’s where the method resides). The attribute reader returning that reference is named class :

class Monkey
  def Monkey.laughs
     "Ou ou ou Ahh ahh AHHH!" #that's how a monkey laughs
mvp = Monkey.new

Use self explicitly

When you are inside a class, you are not always forced to use the self receiver explicitly when calling a method residing in the same class (or higher in the hieararchy). However, there is a time when you HAVE to use self or else it just won’t do what you want : This time is when you call an attribute writer.

class Test
  def assign_fiesta=(value)
  def not_an_assignment
  def some_method()
     not_an_assignment # <== self is implicit
     assign_fiesta = "Hello!" # <== self is not implicit! assign_fiesta is a local variable
     self.assign_fiesta = "Hello!" # <== Now we're talking!

Why is this so? Well, it makes some sense when you think about it. If your attribute writers (methods trailing with an = sign) would'nt require to be called with an explicit receiver, how could you tell ruby when you want to assign to a local variable instead of calling a method? Sure, ruby could check if the thing to the left corresponded to the name of a method in the current class and, based on the answer, call a method or assign to a local variable. But what if the method did not reside in the current class but in the parent class... or in the parent class of the parent class (and so on)? It would become a great source of confusion, don't you think?
Say for example you had a method in your class that was setting the local variable color (color="blue"). This method could work without any problem for months... until you decide to add a new attribute writer with the name color= in the parent class. From now on (that is, if ruby would be using some detection technique like the one mentionned earlier), your initial method would not deal with the local variable color anymore, it would call the color= method in the parent class! This could get really messy and error prone.
So, instead of trying to guess if the thing to the left is a method with a trailing = sign or a local variable, ruby assumes that it is always a local variable and that the whole expression is a standard assignment. That being said, you could use self only to call attribute writers and omit it for other methods... but personally I don't like that kind of inconsistency.
I like to remind myself that a method never floats in the air and that it is always contained into an object. That's why most of the time I prefer to specify the receiver before the name of a method... no wonder if I'm outside or inside the object.

Understanding class methods in ruby

First of all, let’s go back to the basics. What we generally call a class method is a method that resides at the class level. On the opposite, an instance method is a method that resides at the object level.
#UPDATE 2007/04/15
I changed the previous paragraph and removed the word ‘shared’ when talking about class methods because it was confusing. A class method isn’t ‘shared’ since it’s instances cannot access it without using explicitly the reference to the class, like that : my_obj.class.class_method. And no, unlike someone have suggested, the super keyword won’t work. I’ve just been too quick to update my post… sorry)
In ruby, classes are also objects, so the methods you define as class methods only exist in the object that defined them (the class) and nowhere else. If you define my_class_method in a class named Test, my_class_method will only live into the object Test, which is an instance of a built-in ruby class named Class. If what I just said sounded like mandarin, you might want to read this post first.
Every instances that you create contain a variable that points to their corresponding class. Say you create a new instance of class Test and that you name this instance x (x = Test.new). x will contain every instance variables/methods that have been defined as such in the class as well as a reference to the object Test, which will contain the variables that need to be shared among every instances of this class (class variables) as well as methods that will be local to this object (class methods). That’s the reason why ruby complain when you write something like x.my_class_method. It complains because my_class_method just doesn’t reside in x, it resides in Test.
You have 2 ways for defining a class method.
1) You can use the name of the class directly

class Test #Test is now an instance of a built-in class named Class
  def Test.class_method
    "I'm a class method."

2) You can use the self variable, which is always pointing to the current object

class Test
  def self.class_method
    "I'm a class method."

Once you understand that classes are objects, this use of the self variable to define a class method finally makes sense.
In fact, there is another way to define a class method. I personally find it a little bit more obscure. it consists of building a new anonymous class only for the current object (self). To create the anonymous class, we use the << notation.

class Test
  def some_method
    "bla bla bla"
  class <<self
    def my_class_method1
    def my_class_method2
        "But use it if you want"

Remember what we have to do to add a new instance method in a class :

class Test
  def hello
    "Hello! I'm an instance method"
    "I'm accessible in every single instance of class Test"
x = Test.new
#Add a new method to an instance of class Test
def x.goodbye
  "Goodbye! I'm an instance method"
  "I only exists in x"

When you look at it, it’s exactly the same trick that we previously used to add a new class method. The only difference is that instead of adding a method to an instance of class Class, we added a method to an instance of class Test.
The value of self
Not too surprinsingly, when you are inside a class method, the value of self refers to the object that holds the class structure (the instance of class Class). This means that :

class Test
  def self.class_method

is equivalent to :

class Test
  def self.class_method

When you are inside an instance method, the value of self still refers to the current object. This time however, the current object is an instance of class Test, not an instance of class Class.

to_i Vs to_int

Have you ever come across an object that was implementing both to_i and to_int? Did you find that it was a little bit redundant (say yes please)? What is the difference between the 2?
First of all, neither to_i or to_int is meant to do something fancier than the other. Generally, those 2 methods don’t differ in their implementation that much, they only differ in what they announce to the outside world. The to_int method is generally used with conditional expressions and should be understood the following way : “Is this object can be considered like a real integer at all time?”. This can be useful when using some ducktyping technique.

def my_method(an_obj)
      #Ok, this object can be considered like an integer!
      #some_method_int_value will take care of
      #this object!
      some_method_int_value(an_obj.to_i) #could use to_int as well
      #Ahhh... it doesn't have a direct representation in the integer
      #form. I will pass the object without touching it and
      #some_method_no_int_value will decide what to do from there

As you can see, to_int has been used in conjunction with the respond_to? method to check if the object could be considered like an integer. We’re not saying that what was contained into the object at this time could be converted to an integer. We are saying that this object can always be considered like an integer, regardless of its actual value. Big difference here.
The to_i method is generally used to do the actual conversion and should be understood that way : “Give me the most accurate integer representation of this object please” (I added “please” because it is important to be polite when we talk to an interpreter).
String, for example, is a class that implements to_i but does not implements to_int. It makes sense because a string cannot be seen as an integer in its own right. However, in some occasions, it can have a representation in the integer form. If we write x = “123”, we can very well do x.to_i and continue working with the resulting Fixnum instance. But it only worked because the characters in x could be translated into a numerical value. What if we had written : x = “the horse outside is funny” ? That’s right, a string just cannot be considered like an Integer all the time.
Float, on the other hand, is a class that implements to_int as well as to_i. Both of these methods return the same result but the presence of to_int announce that a float can always be treated like if it was an integer. And it’s okay, because in a sense a float always contains an integer part. By the way, if you convert a float with to_i or to_int, the float will be truncated an you will be left with the integer part only.
Note that there are other methods from other classes that have the same purpose like to_s Vs to_str and to_a Vs to_ary.

Appending to a string

If you come from another language, you might be tempted to use the += operator when appending to a string.

my_str = "Marco "
my_str += "Polo"

It works… but there is a better way to do it : the << method.

my_str = "Marco "
my_str << "Polo"

I have removed my initial claim about operator precedence as it isn't really accurate. There is a much better reason to use << instead of += when appending to a string... something I didn't even realize (Thanks to Gregory). += will create a new String instance and will assign it to your left object. On the other hand, << will append the new string directly into your already existing left object. One could argue that += is only different than << and not better, but to me << is what you'll want to use 99% of the time (if not 100%) when appending to a String. I have yet to see a real case where one would want to "lose" it's existing String instance just to get a new one containing the exact same value. You can also use the << method with arrays :

[1,2,3] << 4 #gives [1,2,3,4]

Be careful however when using << with Fixnum/Bignum instances. With these objects, the << method will shift the bits of your integer to the left. If you want to do a summation (append style that is), you will have to use +=

Check for nil and initialize on a single line

Sometimes, you want to initialize a variable to some value only if that variable is equal to nil. If you like to write your methods as short, clean and readable as possible, you can do that task in a single line instead of taking the traditionnal 3 lines approach. You have two options :
1) You can use the if modifier

x = get_some_object if x.nil?

Very easy to read. This is my favorite.
2) Or you can use the ||= operator

x ||= get_some_object

This one is even shorter. The ||= operator is a little bit less verbose and might confuse a ruby newcomer… but I’m not saying that it should be a reason for not using it. This is more a matter of personal taste than anything else.
Both of these methods are better than this :

#eeww... we don't like this one.
  x = get_some_object

Understanding Fixnums

Ruby truly is full of surprises. Until recently I was under the impression that Fixnum objects were like every other objects. A discussion emerging from one of my article made me realize that it was not the case. I then decided to understand once and for all what Fixnums were really made of.
You don’t create a Fixnum, you just use it
Not unlike symbols, you cannot create a fixnum that way : x = Fixnum.new. That just won’t work. Fixnum are immutable objects, meaning that you cannot change them once they have been created. And it is Ruby duty to create a Fixnum object, not ours. All we have to do is to use these fixnum instances and be happy.
You don’t work with a reference, you work with the object itself
When you write : x = 5, you could be tempted to think that you just created a space in memory for the variable x, and that this space is pointing to the immutable fixnum object 5. Well, it looks like this is not what’s really happening (Official doc). As I understand it, the integer value is stored directly into the variable x (more on immediate values in the update below). Moreover, no copie of a Fixnum object can be created. There may exists only one Fixnum instance for a given integer value. When ruby sees x, it scratch it’s chin for a few seconds and says : “x? Oh, he’s talking about 5!” and then it uses the Fixnum object 5. That’s why x and 5 share the same object id (x.object_id == 5.object_id). When you think about it, it’s better that way, otherwise it would have been overkill. Why having 10000 representations of the number 5 instead of only 1?
Is it useful to know?
Yes and no. After all, the only thing that really matters in our day to day programming is the fact that Fixnums are objects and that we can invoke methods on them. But if you’re like me, sometimes you just have to know how things work or you just can’t sleep well. =)
#UPDATE 04/02/2007
Fixnum are objects that contain immediate values
What does it means? It means that if we write x = 5, the number 5 will be stored (encoded) directly into the variable x like if it was a primitive data type (with ruby traditional objects, x would have contained an address corresponding to the object stored in the heap). So, when we write x = 5, x knows everything it needs about the number 5. In fact, x IS the object and not a reference to it.
How can you call a method like x.times if x doesn’t point to some object in memory?
What’s even more confusing is the fact that you can actually use x as a receiver and call some Fixnum methods even if the value of x doesn’t resides in the program heap. Honestly, I don’t really know how it works but I’m starting to wonder if it’s really that important. I think it’s just safe to say that the folks behind ruby really put a lot of effort to make Fixnum objects behave like every other objects. They probably wanted to hide those details as much as possible to avoid confusion. But still, Fixnums are not like every other objects.
I like the comment by RifRaf, who says :
This is done for efficiency. The object stuff is just fakery.
Fakery, yep! That’s a nice way to look at it. Fixnums are fake objects… but as ruby programmers, we can still see them as real objects without any danger of doing something wrong.