Learning Rails

Finally, Up and Running! Part 1

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

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.

Agile Web Dev with Rails vs Ruby for Rails

joelg — Tue, 30 Jan 2007 06:08:07 +0000

I gave a talk tonight to Bootstrap Austin’s web SIG on Second Life. I brought the ad agency where I work into Second Life and am advising clients on the best way to use it. It was a small, but interested group of folks…less than ten. With one exception, we were all programmers or former programmers.

After we exhausted talking about Second Life, the talk turned to Ruby. I was astounded by the fact that everyone was either working in Ruby, learning Ruby, or, with the exception of the one non-programmer, involved in discussing whether or not to use Ruby. All were talking about using Rails for web development.

A consensus emerged. Professional programmers, those who program for a living, love Agile Development with Rails. Those that are learning, but who haven’t programmed professionally for a few years (almost a decade for me), get more out of Ruby for Rails. An small, but interesting, observation.

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.

Rails and Relationional Databases - Why is this so Hard?

joelg — Sat, 06 May 2006 23:00:17 +0000

I’ve found that Rails is really easy to create CRUD. Create/retrieve/update/delete databases is really easy. You set up the database, run a ruby command at the command line, and you get the basic web forms you need to create, list, update, and delete records in a database. Then, you dress up the html with CSS and you’re on your way.

Rails is a great way to easily create database applications on the web.

Until you need a relational database.

Figuring it out relational databases are hard, primarily because you have to: 1) name the relationships correctly, and 2) tell ruby about the relationships. I haven’t figured all this out yet and I have felt really frustrated seeing as single tables are easy.

I thought it was me, but then I found Rails Ridiculous Restrictions, Rant, which outlines the problem with Rails nicely. Basically, the ranter’s argument is that Rails should be smart enough to figure out the relationships without having the programmer tell it what those relationships are. And I agree.

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.

Writing my first rails app with a database

joelg — Sat, 22 Apr 2006 19:13:49 +0000

So, yesterday I figured out that I could connect to the MySQL database using a different port: 3306. Today, I tried using MySQLFront. Bummer, but I still couldn’t connect to a database. I looked for a free MySQL client and found SQL Manager 2005 Lite. That finally worked. So, I created my first database-driven Rails app, following along in Agile Web Development With Rails.

Finally, on my way to learning Rails!

Can’t Make MySQL Table for Rails

joelg — Fri, 21 Apr 2006 14:00:37 +0000

I ran into my first “bug” the stopped me cold. I define a “bug” as anything that prevents me from moving forward, whether it’s code, configuration, poor interface, etc. It’s a practical definition based upon the fact that I’m programming to solve a problem, to get something done, and if I can’t, then I need to fix it so I can.

The problem was permissions on the MySQL database when following along on pg. 55 of Agile Web Development with Rails : A Pragmatic Guide. It’s the first exercise of hooking up a database to Rails.

As part of building the MySQL table, the exercise has you execute the following line:

depot> mysql depot_development

Up to this point in the exercise, connecting to the database was done with the username “root” and no password. Everything worked fine. But executing the above line caused the following error.

ERROR 1045 (28000): Access denied for user 'ODBC'@'localhost' (using password: NO)

Can’t finish creating the database. Rats!

The Solution

Long story short, the solution was found in the MySQL Error Log. In it, I kept on seeing citations that had “port:3306″ in it.

Instead of trying to connect and build the database from the command line, like it’s illustrated in the book, I decided to use MySQL-Front to connect to the database. But I still could not.
Now, the server that ships with Rails, WEBrick, apparently is on port 3000. I tried that port in MySQL-Front. No luck.

So, I tried using port 3306. It connected just fine!

Now, I haven’t actually tried to manipulate the table in MySQL-front, or Rails, just yet because I’ve run out of timing trying to solve this problem, but I think I solved the problem.