Block variable - How is it read in English?

Following the “Ruby on Rails Tutorial”, and under section “6.1.1
Database migrations”
http://railstutorial.org/chapters/modeling-and-viewing-users-one#top

There is the following migration:

class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
.
.
.

How do we read this line in English?

create_table :users do |t|

Why should we write the following line with “t.”?

t.string :name

I know that block variables are used to pass parameters, but what is it
trying to tell us here?

So the “do |t|” part is actually the part that is confusing me.

Any clarifications would be appreciated.

Thanks.

create a table named users as described in variable t

Or, in a more generic sense,

create a table named users with variable t

SW Engineer wrote in post #972878:

Following the “Ruby on Rails Tutorial”, and under section “6.1.1
Database migrations”
http://railstutorial.org/chapters/modeling-and-viewing-users-one#top

There is the following migration:

class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
.
.
.

How do we read this line in English?

create_table :users do |t|

Why should we write the following line with “t.”?

t.string :name

I know that block variables are used to pass parameters, but what is it
trying to tell us here?

So the “do |t|” part is actually the part that is confusing me.

Any clarifications would be appreciated.

Thanks.

2011/1/6 SW Engineer [email protected]:

 t.string :email

t.string :name

I know that block variables are used to pass parameters, but what is it
trying to tell us here?

So the “do |t|” part is actually the part that is confusing me.

Any clarifications would be appreciated.

Thanks.

The do…end notation is the syntax to describe a block. Blocks can
also be written with the {…} notation, which is equivalent.

create_table :users {|t|
t.string :name
t.string :email
}

create_table will accept two arguments, the :users symbol, and the
block.
notice there is no comma between the two arguments, this is because
blocks have
a special status, they are only described as the last argument of a
function-call.

the block in turn, is like a function, but that has no name. instead
of defining arguments
with the (…) notation, it uses this special |…| notation.

when create_table is called with those two arguments, it will itself
call
the block, and provide an object, that we named ‘t’.
t.string further calls the string function on the t argument.

I hope I made it a bit clearer, but if I didn’t persist. Once you
understand this,
you will feel much more empowered :slight_smile:
Also, I see you took the example from the old Pickaxe book. It doesn’t
do a really good
job of explaining blocks, so maybe it’s worth to buy the new edition.

This seems to be a good introduction too:
http://eli.thegreenplace.net/2006/04/18/understanding-ruby-blocks-procs-and-methods/

If you are running OSX/nx you can learn more by opening a terminal
session and issuing this:

ri ActiveRecord::Migration

It will pull up a very helpful document.

I don’t recall if ri is bundled with the distribution for Ruby < 1.9.

But if you are following the rails tutorial, you already know how to use
gems to install it.

SW Engineer wrote in post #972878:

Following the “Ruby on Rails Tutorial”, and under section “6.1.1
Database migrations”
http://railstutorial.org/chapters/modeling-and-viewing-users-one#top

There is the following migration:

class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
.
.
.

How do we read this line in English?

create_table :users do |t|

Why should we write the following line with “t.”?

t.string :name

I know that block variables are used to pass parameters, but what is it
trying to tell us here?

So the “do |t|” part is actually the part that is confusing me.

Any clarifications would be appreciated.

Thanks.

Thanks a lot for your replies.

@zimbatm, the example is actually from http://railstutorial.org

Actually the Pickaxe book confused the heck out of me with regard to
blocks.

Plowing through the examples at railstutorial.org helped a lot, as did
the nooby-friendly explanations in Beginning Ruby by Peter C…

Good Afternoon,

On Thu, Jan 6, 2011 at 10:11 AM, SW Engineer
[email protected]wrote:

 t.string :email

.
.

This is rather easy to explain actually. What occurs is this - you are
calling the create_table method. This method is getting two parameters -
the
:users symbol which is used to define the table name and then the “do”
block. The block acts as a sort of internal proc to the create_table
method.
The magic happens when the create_table method “yields” back to the
block.
In this case the yield call from the create_table method is passing in a
parameter which is referenced as “t” by the block. Then what occurs is
that
the block is executed as a procedure using the object passed into it by
the
create_table method as the “t” variable. It simply is a helper concept
to
ease the creation of your table. So you can sort of view it as “create a
table named users and then with that table do the following - add a
string
column called name and a string column called email”

As you can note here
http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html#method-i-create_table-
there is no requirement to use the block form at all - it’s simply a
convenience and aesthetic method for the most part. It’s also good to
hit
the view source “button” at the bottom of the method definition. You’ll
notice that there is a

yield table_definition if block_given?

line. This line is where the table_definition variable that is created
within the create_table method is passed back to the block which has
been
setup to refer to it as “t”. That table_definition variable is then
modified
via the string method calls on it. Then at the end of the block the
create_table method continues and thus you get your create table
statement
fully populated and then executed.

Hope this helps

John

I’m actually still confused regarding understanding how the code I asked
about works.

Can you kindly just give a detailed explanation of just the code and I
think this will be very helpful especially for the migrations part at
least.

Thanks.

Thanks @John for your nice and thorough clarification.

Also, I liked the way how this blog describes “yield” when saying:
“Ruby’s yield statement gives control to a user specified block from the
method’s body.”

2011/1/9 Mike S. [email protected]:

I would have thought this discussion is symptomatic of a lot of Rails
activity.

From what I’ve seen of Rails, it’s quite clever clever, but it’s also
quite complicated. I really question whether people should assume they
can download Rails, switch on the ignition and just drive off. I would
have thought you would need to have quite a bit of basic Ruby experience
before moving on to Rails.

Rails has lots of meta-programming, it’s complicated, I don’t much like
it.

I would have thought this discussion is symptomatic of a lot of Rails
activity.

From what I’ve seen of Rails, it’s quite clever clever, but it’s also
quite complicated. I really question whether people should assume they
can download Rails, switch on the ignition and just drive off. I would
have thought you would need to have quite a bit of basic Ruby experience
before moving on to Rails.

Thanks for your replies and views.

Michael H., the author of the “Ruby on Rails tutorial” says the
following:

One common question when learning Rails is whether to learn Ruby first.
The answer depends on your personal learning style. If you prefer to
learn everything systematically from the ground up, then learning Ruby
first might work well for you, and there are several book
recommendations in this section to get you started. On the other hand,
many beginning Rails developers are excited about making web
applications, and would rather not slog through a 500-page book on pure
Ruby before ever writing a single web page. Moreover, the subset of Ruby
needed by Rails developers is different from what you’ll find in a
pure-Ruby introduction, whereas Rails Tutorial focuses on exactly that
subset. If your primary interest is making web applications, I recommend
starting with Rails Tutorial and then reading a book on pure Ruby next.
It’s not an all-or-nothing proposition, though: if you start reading
Rails Tutorial and feel your (lack of) Ruby knowledge holding you back,
feel free to switch to a Ruby book and come back when you feel ready.
You might also consider getting a taste of Ruby by following a short
online tutorial, such as can be found at http://www.ruby-lang.org/ or
http://rubylearning.com/.

On Jan 9, 2011, at 4:00 AM, Mike S. [email protected] wrote:

I really question whether people should assume they
can download Rails, switch on the ignition and just drive off.

I don’t know how Rails has gotten the “it’s easy” reputation. It’s for
those looking for an MVC web framework, which I think is a good fit for
database backed web apps. And it’s written in an interpretive language
which, along with its emphasis on convention over configuration, speeds
development.

Then, it’s written in Ruby, which, for my tastes and needs, makes the
whole thing perfect.

Jose

Jose Hales-Garcia
UCLA Statistics

On Sun, Jan 9, 2011 at 1:00 PM, Mike S. [email protected]
wrote:

From what I’ve seen of Rails, it’s quite clever clever, but it’s also
quite complicated. I really question whether people should assume they
can download Rails, switch on the ignition and just drive off. I would
have thought you would need to have quite a bit of basic Ruby experience
before moving on to Rails.

In general, to program in L you need to learn some L. Rails is Ruby
programming, ergo you better learn some Ruby.

I have the feeling that Rails is not for beginners. It abstracts web
programming in a way that I think makes more sense for someone that
already knows web programming. In that situation you get a Ferrari to
run. It is just an opinion, it could be the case that you are
presented first with the framework and work fine… I’ve seen that
with Java people. But I doubt you’ll understand what you are doing.

I think that learning web programming passes through HTTP and bare
CGI, where you’re naked, you value as gold even being able to have the
query string parsed for you. There you understand what’s all about,
and can build from that. Then the abstractions make sense and act as
shortcuts.

Other than that, I would not say Rails is complicated. Rails is rather
big, you need to invest time to master it.

On Sunday, January 09, 2011 01:37:19 pm Jose Hales-Garcia wrote:

On Jan 9, 2011, at 4:00 AM, Mike S. [email protected] wrote:

I really question whether people should assume they
can download Rails, switch on the ignition and just drive off.

I don’t know how Rails has gotten the “it’s easy” reputation.

I think it’s partly because of all the generators, and partly because it
really is easy, considering some of the competition. Yes, there are a
lot of
moving parts, but that’s really just the nature of the beast for web
apps. If
you understand them at all, you’re building actual web apps faster than
it
would take me to install and configure a database on some other systems
I’ve
tried.

I don’t know whether Rails is a good platform to learn on, though I do
think
anyone learning Rails also needs to put a significant amount of effort
into
learning Ruby itself, outside of a Rails context. That’s on top of
understanding how to talk to your datastore directly (SQL for most
people) and
how it thinks (relational DBs for most people), all the frontend stuff
(HTML,
CSS, JavaScript), and all the communication stuff (DNS, TCP/IP, and
especially
HTTP).

It’s possible to do interesting things in Rails before you understand
that
stuff. Still, the difference between Hello World and an actual app, and
the
difference between a few minutes of debugging and an impossible problem,
is
that background. Do you know how to grab the HTTP headers out of your
Rails
app, and what they mean? Can you play with your app using curl from the
commandline? If you don’t understand these things, there are certain
problems
which will be much more difficult to solve, no matter how easy Rails (or
anythng else) gets.

In other words:

“the abstractions save us time working, but they don’t save us time
learning.”

I think that’s what I feel about Rails. I don’t know if it’s a good
beginner
language. Regardless, it’s to save you time working, not to save you
time
learning – although if it happens to be easier to learn than other
platforms,
that would be cool, too.

On Sun, Jan 9, 2011 at 9:17 AM, Xavier N. [email protected] wrote:

and can build from that. Then the abstractions make sense and act as
shortcuts.

Other than that, I would not say Rails is complicated. Rails is rather
big, you need to invest time to master it.

My two-cents
http://talklikeaduck.denhaven2.com/2011/01/16/abstract-vs-concrete-approaches-to-learning


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale