Block variable - How is it read in English?

[SW Engineer]

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

 

[Cliff Kachinske]

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:

 

[Jonas Pfenniger (zimbatm)]

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
=C2=A0def self.up
=C2=A0 =C2=A0create_table :users do |t|
=C2=A0 =C2=A0 =C2=A0t.string :name
=C2=A0 =C2=A0 =C2=A0t.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.

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|
=C2=A0t.string :name
=C2=A0t.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
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/

 

[Cliff Kachinske]

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 Cooper.

 

[Cliff Kachinske]

If you are running OSX/*n*x 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:

 

[SW Engineer]

Thanks a lot for your replies.

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

 

[SW Engineer]

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.

 

[John W Higgins]

[Note: parts of this message were removed to make it a legal post.]

Good Afternoon,

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

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/.../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

 

[SW Engineer]

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."
http://langexplr.blogspot.com/2007/09/rubys-yield-statement.html

 

[Mike Stephens]

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.

 

[zuerrong]

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.

 

[Xavier Noria]

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.

 

[SW Engineer]

Thanks for your replies and views.

Michael Hartl, 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=E2=80=99ll 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=E2=80=99s not an all-or-nothing proposition, though: if you start read=
ing =

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/.

http://railstutorial.org/ruby-on-rails-tutorial-book

-- =

Posted via http://www.ruby-forum.com/.=

 

[Jose Hales-Garcia]

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 thos=
e 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 t=
hing perfect.

Jose
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jose Hales-Garcia
UCLA Statistics=

 

[David Masover]

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:

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

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

 

[Rick DeNatale]

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.

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

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale