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.

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)
    @assigned_value=value
  end
  def not_an_assignment
    @assigned_value
  end
  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!
  end
end

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.

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)
END UPDATE
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."
  end
end

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."
  end
end

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"
  end
  class <<self
    def my_class_method1
        "Weirdo"
    end
    def my_class_method2
        "But use it if you want"
    end
  end
end

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"
  end
end
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"
end

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
    self.x
  end
end

is equivalent to :

class Test
  def self.class_method
    Test.x
  end
end

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.

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)
    if(an_obj.respond_to?(:to_int))
      #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
    else
      #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
      some_method_no_int_value(an_obj)
    end
  end

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.

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.