Learning Rails » Ruby Language

Finally, Up and Running! Part 1

joelg — Mon, 05 Feb 2007 03:46:29 +0000

The story to date: When I picked up Agile Web Development with Rails : A Pragmatic Guide, I thought to myself, “OK, I’ll just read the tutorial to get what I need and then create my own first website because I know what I want and it’s not their example.” But, I ran head long into problems that prevented me from getting my first simple rails app working.

After a lot of on again, off again learning…life taking priority…I finally got my first app working, without going step by step through the tutorials. I decided to use InstantRails on my PC. Installation is as simple as unzipping. It works. So, here are the steps I went through to create the app, which was a simple program consisting of two related tables. Assume the name of the app is “myapp”.

1) Design the Database

List out the attributes of each thing you want to track. The “things” are the table(s); the attributes are the “fields” in the tables.

2) Design user actions

Decide what you want people (well, you) want to be able to do with your app. Then, figure out what your app has to do. Actually, you don’t have to do much here to get a basic CRUD application, so if you don’t do anything, Rails will still you’ll get something up and running.

3) Create Database (command line & sql file)

You can create the database using visual tools, like Webyog. However, I used the mysql command line. Open a console window from Instant Rails and type:

mysql -u root -p myapp_development

…which means “root” is the user name; you’ll be prompted for a password. Just hit enter (this is all fine for development on a local machine).

This gets you into mysql. Next, create the three databases you’ll need (a production one, a test one, and a development one–you’ll be working on the development one) and give them appropriate permissions:

mysql> create database myapp_test;

mysql> create database myapp_development;
mysql> create database myapp_production;

mysql> grant all on myapp_test.* to ‘@localhost’;
mysql> grant all on myapp_development.* to ‘l@localhost’;
mysql> grant all on myapp_production.* to ‘prod@localhost’identified by ”;

Then, create the tables in the database. This is where the design from the first step comes in. I’m not going to get into the details here, but I found the discussion in Ruby for Rails to click for me on database design. Also, there are many examples in Rails books (and online) for creating a table. Assuming you have your tables defined in a text file, run this command at the command line:

mysql -u root -p youtubeutils_development < myapp.sql

This treats the myapp.sql file as if it was typed at the command line, one line at a time. This creates the tables in your database. Note that it you’ll be prompted for a password. Just hit return.

Up next: YAML files, Rails, and generator.

The values returned by || and &&

joelg — Sat, 03 Feb 2007 07:45:35 +0000

Ruby has logic that appears to me…well…logical. I feel there’s a “groove” to thinking in Ruby. I’m not able to articulate it further, probably because I’m not that familiar yet with the language. But there’s something about the way things work in Ruby that makes sense to me. It’s taken me a lot of reading and playing in irb, but by experimenting, I’m starting to understand Ruby’s groove.

One example is the caparison operators for and (&&) and or (||). At first glance, there’s nothing really different about them. But, let the narrative in The Pick Axe Book sink in and I have an “a-ha” experience. “That’s why they do it that way!”.

Turns out, Ruby does only as much as it needs to do in order to return true and false. Take && , for example. && is true if both expressions are true. It’s false if one expression is false. So, if you end up with a statement

false && true

Ruby returns false, obviously. With ||, if the first expression is false, Ruby goes on to the second, which determines the value of the expression. In other words,

false || true

returns true. And,

true || false

returns true. Pretty straightforward stuff; it explains the common Â Â Â idiom:

variable = expression || default value

But Ruby also has the value nil. Here’s where things get interesting. With &&, nil behaves much like false,

true && nil

returns nil. But with &&, Ruby only goes so far as the first expression if it finds it’s not true (in other words, nil or false). Eg:

nil && false

returns nil, NOT false. Conversely,

false && nil

returns false, NOT nil.

not true

returns false.

not false

returns true

not nil

returns true

Interesting, no? Most of the time, nil and false behave the same. The only exception is under the following three statements, which all return nil:

nil && true
true && nil
nil && false

Wacky, but true.

Ruby on Rails Cheat Sheet

joelg — Wed, 31 Jan 2007 04:29:26 +0000

A shout out to Adrian, who left a message on one of my posts encouraging me to keep going with rails. He pointed me to a nice Ruby on Rails Cheat Sheet written by a technologist named Pascal. It succinctly lists out commands you’d need to create a Rails application.Â I wish one of the books I bought had this list; it’s really handy.

Ruby for Rails by David A. Black

joelg — Fri, 26 Jan 2007 05:58:00 +0000

After a number of months hiatus, I’m back to learning Ruby, again because I have ideas I want to sketch out in code. If I’m going to be learning a new language anyway, then Ruby seems to give me the most bang for the buck and seems to be easy to wrap my head around. My experience with object oriented coding has been with Lingo, Director’s language (back in the multimedia days), Java, and a Forth-like language called Magic/L back in the pre-cambrian period of programming. What’s really nice about Ruby is once I understood things like iterators, I saw how compact and English-like the language really could be. Odd, seeing as the language was invented by a Japaneese speaker whose second language is English.

I was talking about my frustrations about learning Ruby and Rails to my friend, David Sedlow, using the Agile Development with Rails book. We both come from a we-used-to-be-programmers but-haven’t-done-it-professionally-in-years background. (To me, the book needs to be user tested because it makes some assumptions that you already know Rails…inadvertently, or not.) David suggested Ruby for Rails by David A. Black. I have found Ruby for Rails easy to understand. It explains things in a logical sequence and explains them thoroughly. It’s also a nice mix between Ruby and Rails, making the reasonable assumption that you need to understand Ruby if you want to understand Rails.This book is enough to get started with Rails development. I believe between this and the The Pickaxe Book, I have what I need to get going with Ruby and Rails. I may not even need to the Pick Axe book, it’s that good at providing a basic understanding of Ruby.

Indeed, last night I hacked out a little screen scraper that prints out the items viewed from a youtube.com page. Not much, but with many ad agencies and brands putting their commercials on YouTube, I believe it could be a simple, useful tool. Give it a list of YouTube url’s to track and it returns a simple list of desired videos with the number of times they’ve been viewed. This tracking guide would be useful to folks in the marketing world.

Initial Tips

joelg — Wed, 03 May 2006 14:25:23 +0000

Here are some initial Ruby operators and conventions that tripped me up, hopefully with coherent explanations so they won’t trip you up as well.

“!” in method names

It’s a convention that Ruby method names that end in “!” actually change the data. Eg:

var1 =[9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

var1.sort

>> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

You may think the above changes the values held bay the variable “var1″.Â But if you print out “var1″ again, you get the array in the original order:

var1

>> [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

The “sort” method returns the sort, but doesn’t change the actual order of the items in the array. But, The “sort!” method does: Eg:

var1.sort!
>> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

var1

>> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

If your method actually changes the data, have it end in an exclamation point.

“?” in method names

It’s a Ruby convention that methods that end in a question mark are tests that return “true” or “false”. Eg:

var1 =[9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

var1.include?(5)

>> true

var1.include?(10)

>> false

If your method is intended as a test and returns “true” or “false”, name your method with a question mark.

“=” in method names

It’s a Ruby convention that method names that end in “=” are assignment methods. For example:

my.address= “1808 Ruby Way” or

my.address= (”1808 Ruby Way”)

assigns “1808 Ruby Way” to a variable (class, or instance).

%w{} is a Quick Way to Assign a List

You can create a list quickly out of a text string with %w{}. For example,

ary=%w{This is a test}

returns

["this", "is", "a", "test"]

class#method means class.method

In the documentation, you’ll find things things like

class#method (note the hash mark)

referring to something in code that’s actually writen

class.method (note the dot)

I don’t know the reasons why, but it’s confusing at first. But at least now you know.

Nice Little Tutorial

joelg — Fri, 28 Apr 2006 03:31:56 +0000

http://tryruby.hobix.com/

is a nice little, interactive tutorial. It is an IRB session in a web page, with a tutorial you type along with. Nice intro to Ruby.

Everything’s an object!

joelg — Thu, 20 Apr 2006 18:06:50 +0000

One of the first things that made me go, “hmm…..” was the idea that in Ruby, everything’s an object and as such, can have methods associated with it.

Here’s a trivial example:

>> puts 22.to_s

=>”22″

The number, 22, is an object of type Integer. Integer objects have a number of methods, one of them is “to_s”, which transforms the number into a string. “puts” means “put string”, or print the string. The convention of using an arrow (=>) to point to a value means, “This is the value of the line above.” This is what IRB (interactive ruby) does. (The “>>” is the IRB prompt, so all the code is copied and pasted from IRB.)
In this case, the value of “puts 22.to_s” is the string “22″, NOT the number 22.

Arrays make a more interesting example, like this:

>> var1=[4,2,5,1,3]

=> [4,2,5,1,3]

Arrays are easily sorted using the “sort” method.

>> var1.sort

=> [1, 2, 3, 4, 5]

But, if you look at the value of var1 again, you’ll get:

>> var1
=> [4, 2, 5, 1, 3]

Which means the array isn’t sorted any longer. What’s going on?

Changes to Data and Method Naming Conventions

Sort doesn’t actually change the data in the array, it simply returns the sorted data. To actually sort the data, you’d need to use the “sort!” method:

>> var1.sort!
=> [1, 2, 3, 4, 5]

Looking at the value of the array, you’ll see the array is now sorted.

>> var1
=> [1, 2, 3, 4, 5]

! at the end of method names

Ruby programmers have developed a convention that methods ending in “!” actually change the data. The exclamation point is there to remind you that you’re really doing something to your data.

? at the end of method names

Likewise, Ruby programmers have developed a convention that methods ending in “?” are tests that return true or false. Eg:

>> var1.include?(3)
=> true

Which tests to see if the number three is in the array var1. If the number is not in the array, “include?” returns false. Eg:

>> var1.include?(15)
=> false

Getting Started with Books and Websites

joelg — Wed, 19 Apr 2006 15:42:25 +0000

So, I went to the local bookstore and loaded up on two popular books on Ruby:

Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition
This is a comprehensive book on the Ruby language. It looks like a good choice to learn the language. I know there must be other good books out there, though. I just don’t have the time to go through them all to find the best one. This book is informally known as the “Pick Axe” book because of the front cover. The first edition of the book can be found online, here.

Agile Web Development with Rails : A Pragmatic Guide
Looks like a fairly comprehensive guide to Rails. Of course, you need to know Ruby to get the most out of it. It’s also helpful to know a little bit of MySQL syntax for creating tables. Here’s one MySQL tutorial. Here’s another.

I’m also using a few websites in my quest to learn Ruby:

Ruby-doc.org: A great resource. Online documentation for classes found in the Ruby Core as well as the Standard Library. Has nice, tight introduction of Things That Newcomers to Ruby Should Know.

Ruby-lang.org: The official Ruby Language site. All things ruby, learning is only one part, so it’s a bit overwhelming for someone new to the language.

RubyGarden.org’s Wiki. Haven’t spent much time, but looks more useful to a beginner than the overwhelming Ruby-lang.org.

What’s Missing?

There’s one thing missing from the above list of resources: a good Ruby idioms resource. Idioms are ways to code things that are specific to Ruby. Idioms are typically confusing to people new to the language, but make sense on their own terms. I’m on the look out for a good idioms resource…

All the above assumes you have experience in at least one other object oriented language. These are not good resources to learn object oriented programming; so, if you’ve never programmed before, you’ll be lost.

Begining to Learn Rails

joelg — Sun, 16 Apr 2006 22:23:34 +0000

This blog follows my (Joel Greenberg)’s attempt to learn Ruby and Ruby on Rails. I’ve got a few business ideas that I’m trying to bring to life with friends and we need a programming framework to quickly make interactive, database-driven websites.

Who am I?

I haven’t programmed professionaly in about nine years. However, in my past I’ve programmed in C; a forth-like language called Magic/L; the iconic language Authorware; Macromedia Director (Lingo); Multimedia Toolbook (yeah, I’m showing my age), Apple Script (which is a great, object oriented language–too bad it wasn’t well supported), and a little Java a long time ago. I’m trying to generate extra income by creating a community site with a friend around women exercise enthusiasts. He’s a designer; I’m a strategy guy. We could hire a programmer…if we had the cash. So, I figure, being an old programmer, why not give development a shot? Then, when the sites at a point where we have a small audience, we can think about paying a programmer to take it to the next level.

Why Ruby on Rails?

Well, the choices were Ruby on Rails, Python with Django (or some other framework), or a Content Mangement System (CSM)…say, Mambo. I ruled out a CMS because our idea isn’t heavy on articles and I’d have to end up programming anyway to get a CMS to perform the way I wanted it to. With that kind of effort, why not just learn a language and a framework?

I’ve kind of wanted to learn Python, but I bought the hype that Ruby on Rails is quicker. I viewed some of the presentations at RubyonRails.org and felt that if I was going to put the time into learning a new language anyway, why not go for something that promises to be Really Quick for development.

Ruby is used by 37Signals for their project management tool, Basecamp. I heard Jason Fried, of 37 Signals, on a panel at SXSW and on a podcast from IT Conversations. I liked his philosophy of people over process and code over 3 inch binders of documentation. Ruby was designed with those types of principals in mind. To me, coding is about solving problems and providing value NOT about tomes of documentation that no one ever reads. (And I’m an old tech writer, too. I’ve written those tomes and stopped doing it early in my career).

Ruby holds the promise of quick development and has a development philosophy that appeals to me. I won’t be trying to bend a language built for corporate America into my freewheeling idea.Â I’m programming for my own needs.Â I don’t intend to go back to work for hire programming.
So, the potential’s there. Follow along with me to see what it takes to learn Ruby on Rails and see if the potential becomes realized.

Joel