A while back, I wrote an introduction on code blocks. So if you’re not sure what they are, you should read it first.
Something I find interesting with code blocks is that they create the illusion of being executed at the moment they are written. It’s easy to get fooled, because when you look at code like this :

the_array.each {|item| puts item}

what’s between the curly braces surely doesn’t look like a parameter passed to the each method. However that’s exactly what’s happening. While the following example would fail (Array each method doesn’t expect any regular parameter), for understanding purpose we could write it this way :

my_block = Proc.new {|item| puts item}
the_array.each(my_block)

Written that way, it becomes clear that you pass the control over to the each method, letting it manage everything. That being said, most of the time you won’t be able to pass a block that way since most methods expect raw blocks… not Proc objects passed as regular parameters.
Raw blocks and Proc objects
Blocks come in two flavors : Raw and Proc objects. A raw block is not an object, it’s only a chunk of code. Proc objects are blocks wrapped into objects. With a Proc object, your block becomes something more concrete and allows you to invoke methods on it like with any other object. To invoke the block contained inside a Proc object, you have to use it’s “call” method instead of the global yield keyword which is used to invoke raw blocks.
Passing the block
The most usual way to pass a block to a method is to use it’s “raw” form, like so :

@greasy_food_you_eat_on_fridays.each do |meal|
  puts meal.name
end

When you do so, Ruby does some magic to transmit the block to the receiving method. More about that in a few more paragraphs.
You can also pass a block as a regular parameter to the receiving method by converting it to a Proc object like we did earlier, but for this to work the receiving method needs to expect the block as a regular parameter.

code_block = Proc.new { |meal| puts meal.name }
@greasy_food_you_eat_on_fridays.each(code_block)

If the method each is implemented in a way to receive a parameter of class Proc, the code will pass. Else, it will fail. There is no more magic when you pass a block that way.
Receiving the block
if you passed a raw block to the receiving method, that method has 2 ways to deal with it.

1. Use the raw block directly
2. Convert the raw block into a Proc object and use it

if we choose the first option, we can invoke the block with yield :

def some_method()
  yield if block_given?
end

As you can see, there is some magic happening here. We don’t see the block in the method definition, but somehow it is there and Ruby knows it. block_given? returns true or false depending if a raw block has been passed or not (we don’t want to invoke something that doesn’t exists). yield invokes the raw block.
Now if we choose the 2nd option, it looks like that :

def some_method(&block)
  block.call unless block.nil?
end

Again, some magic happened here. If the LAST specified parameter of the receiving method is prefixed with an ampersand, ruby will take the received raw block and convert it into a Proc object. Then, it will assign it to this last parameter. Note that the ampersand sign doesn’t mean “passed by reference” like in some other languages. It is just a character used by Ruby to determine if it must convert a raw block into a proc object. If that bit of information didn’t exist, Ruby wouldn’t know what you are trying to do and “block” would become a parameter like any other one.
#UPDATE 05/30/2007
Ah-ha! Shadowfiend and rx made me realize something. Remember that piece of code ?
> 1. my_block = Proc.new {|item| puts item}
> 2. the_array.each(my_block)
I said it would fail since the “each” method isn’t expecting a normal parameter. Well it’s true… but you can bypass this lil problem by prefixing my_block with an & sign when you call the method, like that :
> 1. my_block = Proc.new {|item| puts item}
> 2. the_array.each(&my_block)
Tada! Thanks for the precision!
What to expect in the next part :

• Code blocks and scope
• lambdas

Understanding the “chain”
In my last article, I explained where the various elements of an object were located. Now it’s time to understand what happens at run time when you write the following :

obj.my_instance_method

Ahh… A method call! Ruby knows what to do in this situation. Remember that inside “obj” resides a reference to MyClass? Well, ruby follows that reference and looks at the methods in there. It tries to find “my_instance_method”… and it finds it! The call succeeds and everyone in the world is happy, dancing hands in hands like shameless hippies.
Now, if we write :

obj.display

Once again, ruby follows the reference to “MyClass” and looks for the method “display”. Unfortunately this time, it doesn’t find it. Instead of crying, ruby doesn’t give up and looks for the method in any module that could have been mixed into MyClass (I’ll talk about modules in another post)… but still it can’t find it. Determined as we know it, ruby now follows the reference to the super class (Object) in hope to find that method. Victory, the method is there! The call succeeds.

obj.my_class_method

Once again, ruby follows the reference to MyClass and tries to find “my_class_method”, it isn’t there. It looks in any mixed in module, it isn’t there. It looks in the super class, it isn’t there. It looks in any module that could have been mixed in the super class, it still isn’t there. Now the chain is over, because “Object” has no super class. Ruby invokes “method_missing” and the story ends in a very bad way (people are crying and sobbing to the point that it gets quite embarassing).
But I want to access that class method!

MyClass.my_class_method

Ah! That looks better. Now the starting point is MyClass instead of obj. Ruby follows the reference to the class of MyClass, let’s call it MetaMyClass (if you hear the expression meta class for the first time, have a look at the first part). Once comfortable inside MetaMyClass, it looks for the method “my_class_method” and guess what? It finds it! The call succeeds.
The chain for class methods
The last paragraph reveals something interesting : there exists a chain for class methods. Now, what if we write :

MyClass.name

Since ruby won’t find the method “name” inside MetaMyClass (it’s just a fictional name I gave to the meta class… it isn’t a real ruby class name), what will it do? It will look into the super class of MetaMyClass, which we’ll call MetaObject. MetaObject contains the method “name”… so the call will succeed!
So that’s how this 2-part serie ends. An important but not so obvious thing is the concept of meta classes. To understand their purpose, just tell yourself once again that classes are objects, it’s the key really. If classes are objects, they need a place to store their own methods like any other objects. “obj” stores it’s methods in “MyClass”, “MyClass” stores it’s methods in it’s associated meta class.

So far I’ve talked about how everything was an object in ruby, even classes. I also wrote an article explaining what were the most important steps to follow when trying to understand ruby classes and objects. This wasn’t a bad idea, but it was a rather simplistic view. I think we’re ready to dive into the heart of the object model. Now my objective is not to give you a vague idea about how the ruby object model might work, I want to show you clearly what’s going on behind the scenes. Since I am not a fan of long posts, I have decided to split it in two parts. Here is part 1 :
It’s not that the ruby object model is hard to understand, in fact it is quite simple and coherent, but in order to understand it you’ll need to be concentrated, open minded as well as having a decent understanding of dynamic languages.
A simple case

class MyClass
   def my_instance_method
      "I'm an instance method"
   end
  def MyClass.my_class_method
     "I'm a class method"
  end
end
obj = MyClass.new

Let’s try to understand where does the various elements are located :
What is contained inside the object “obj” ?

1. some flags (we won’t bother about that in this post)
2. instance variables (describe the state of “obj”)
3. a reference to the class, that is : MyClass

Ok fine, but where are the methods? We have to follow the reference to MyClass to find them.
What is contained inside the object “MyClass” ?

1. some flags
2. Instance variables (describe the state of “MyClass”. From “obj” point of view, it’s the class variables, those you reference with @@)
3. a reference to the super class (if any. In this case, it is “Object”)
4. a reference to the class (what? I’m confused now!)
5. Methods (Ahh! Here they are! From “obj” point of view, these are INSTANCE methods)

You said a “reference to the class” ? I beg your pardon?
First of all, let’s not confuse the super class with the reference to the class. The super class is a reference to the ancestor of the current object (in this case, the ancestor is Object), while the reference to the class contains additional information about the current object.
That’s fine, but it doesn’t explain the purpose of that “reference to the class” thing. Aren’t we already inside the class “MyClass” ? Yes, we are. The reason why we need a reference to something else is because we need a place to store the class methods! We have to put them somewhere right? The methods described at point #5 are instance methods. These methods will only exist in the instances you created for class MyClass. They won’t exist in the object MyClass.
That “reference to the class” is in fact a reference to a special class (the pickaxe book call it a meta class) that will hold the methods for the object “MyClass”. Those are what we call class methods (from “obj” point of view at least). It makes a lot of sense when you think about it. Remember, classes are objects… so there’s no reason they cannot have their own methods. if “obj” is able to store it’s methods inside “MyClass”, “MyClass” has to be able to store it’s methods in some other place too : This place is the meta class. You can’t have access to these classes directly, they are completely hidden.
I’ll stop right there for now. In the next (and last) part of this serie, I will talk about the “chain” that ruby follows to find and invokes instance and class methods.

A neat feature of ruby is the ability to assign more than one LValue on a single line, like that :

a, b = 5, 10

The pickaxe book has a great exemple of use for this feature : It’s when you want to swap two values.
Instead of having to use a temporary variable an go with the following typical approach :

temp = a
a = b
b = temp

You can screw the temp variable and just write :

a, b = b, a

It works because the right values are all evaluated before being assigned to their corresponding left variable. In other words, one assignement doesn’t alter the others.
While these parallel assignements are great, the problem strikes when they become too complicated and hard to understand.
That same pickaxe book goes mad and push the feature a little too far for my taste at page 93 :

b, (c,d), e = 1,[2,3,4],5

I understand this was just an exemple demonstrating the various possibilities, but I personally wouldn’t recommend anyone to ever do that. Putting more than one instruction on a single line may be fun… but we have to learn when to stop.
But let’s understand it anyway :
This example demonstrates that parallel assignements can be nested, meaning that c and d are treated like a single position on the left side (the 2nd one).
Results after that crazy assignement
1 is assigned to b
2 is assigned to c
3 is assigned to d
4 is lost
5 is assigned to e
Since the left variables c and d are located at the second position, ruby extracts the RValue located at the 2nd position. That RValue need to be an array or else every LValue specified in the parenthesized terms, at the exception of the first one, would be initialized to nil. c and d are located at a single position on the left side, so they map to a single position on the right side.
So that’s how it works, but I wouldn’t do something like that anyway. Most of the time, I try to follow these 2 simple guidelines before deciding to use parallel assignements :
1. LValues should be related to each other
I would not do this :

time_of_the_day, favorite_color, clowns = Time.now, :blue, "Not funny"

But I could do this :

favorite_color, almost_favorite_color = :blue, :yellow

2. For simple things only. It should’nt hurt code readability
We like ruby for it’s expressiveness. Too much stuff going on on a single line kills readability. It’s never good when a programmer stare at your code for 2-3 minutes trying to understand some mad one-liners.