Ruby on Rails is Agile Web Development

If you’ve been following along for a while, you know I’m on a quest to learn Ruby and specifically – Ruby on Rails. Back in May I started on Sam’s Teach Yourself Ruby in 21 Days. After the fourth time through day 15, I knew I needed some other assistance.

The inspiration to find the other assistance came from the How to set up a Ruby on Rails Weblog in 15 minutes quicktime movie. I ordered Agile Web Development with Rails, and in 2 days, I’m half way through the book with a better understanding of AJAX, web services, and a fairly useful project to show for it. Yes, you’ll start to see the changes.

Ruby and Rails?

Back in Day 1 of Teach Yourself Ruby I talked about the Principle of Least Surprise. This principle is how Ruby on Rails made web development fun again. I know that every two hours, I’ll have at a least one bug fixed and at least new featured added. Thanks David.

Setting up a Web Development Environment in Tiger

This message means the upgrade is complete.

Last week I started the upgrade Mac OS X 10.4 “Tiger” around the house. To my pleasant surprise, it went extremely smoothly. The most tedious and frustrating part was waiting for my newly enclosed external hard drive to copy tens of gigs of files back and forth for 2 machines.

The upgrade was an excellent opportunity to clean house and back up. Something my Powerbook was sorely in need of. After the install, the ease of copying my Home directory and a handful of required applications (NetNewsWire, Transmit, VooDooPad, BluePhoneElite, Skype, SubEthaEdit, Quicksilver) back to the laptop meant I was 85% back to normal almost immediately.

The tough part was getting the web development playground set up; I’ve still got a week left in the 21 days of Ruby, and I’m lost without a local install of PHP.

After un-commenting the PHP modules in Tiger’s default Apache install and setting the permissions on the items within the /WebServer/Documents directory to 666, PHP was working as expected.

After that, Ruby, Rails, and MySQL. For this, I highly recommend TextDrive’s About “Setting up a development environment on my Mac”. It walked me through everything and like everything at TextDrive – straight-forward and friendly. As of this writing, some of the items are specific to 10.3 “Panther” and I was able to skip over those with no consequence. Without it, I’d still be googling for a good tutorial on setting everything up. Now, I’m ready to rebuild my seemingly broken WishRSS.

Learning Ruby – Day 14

Day 14 – Blocks, Procs, and the Others

I get it. Seven pages into Day 14 trying to figure out what other meant in Slagell’s examples and it clicks.

In other languages I’m familiar with (Applescript, PHP, Perl, REALbasic) variables are passed through methods. Example if we have a method that’s friendly,

function SayHiTo($name) {
print "Hi, " . $name;
}

and we tell it our name, SayHiTo("Garrick");
The resulting would be Hi, Garrick.

Fairly straight forward. In Ruby-land, not only can we pass whole objects (or close enough) we can also access the methods within those objects.

Slagell’s other is this object. Pretty cool. Pretty useful.

I say this hesitantly, Ruby is the programming language I’ve always wanted.

In other languages, when it’s difficult to do something (pass an object through a method) it’s usually because it’s a BadThingToDo. At this point, I’m a bit skeptical of Ruby’s simplicity and ease.

The Macintosh made bad graphic design real easy, the web made bad publishing real easy. REALbasic made bad programming real easy. Does Ruby do the same or is there something in Ruby preventing this?

I sure hope for the latter.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 13

Day 13 – Putting the Pieces together

Alright, we’re back to Ruby. My apologies for slowing down, and with only 8 days to go. Let’s jump right into day 13.

On the outset, Slagell explains the notion of Ruby being a ‘glue language’, like Perl. A language coordinating multiple programs or processes. Historically, AppleScript has been my glue of choice. AppleScript’s strength is also it’s greatest weakness – it’s not a real programming language. On the other side, I’m still looking for a comparable Windows-based scripting language.

I was first exposed to dot syntax back when Macromedia shoehorned it into Director’s Lingo language. It took me exactly 1 project to appreciate the simplicity and power. After that, it was REALbasic which has a great dot syntax. Especially useful for asking about files things – can I write to you? are you a folder? do you exist?

Rather than the FileName.exists syntax I’m accustomed to, Ruby prefers File.exists?(FileName). Though it feels a little backwards, I appreciate the question mark.

Ran into a little trouble today. Not sure what to make of it. Slagell, asks us to create two files, one with a puts string in it, and one with a string manipulation in it.

I was able to get them working just fine in the Terminal with: > ruby file.rb

He then uses the pipe character to route a string through the string manipulator: > system("echo foo | repeat.rb")

Terminal responded with: Badly placed ()'s

Hmmmm. Not what I expected. Removing the ()’s returned: No such file or directory

Perhaps one of you following along could illuminate me.

In the last exercise for today, my Ruby didn’t like the line:
Dir.entries(dir)
map {|f| File.join(dir,f)}.

to parse through a directory structure. It gave me a undefined method `map` for main:Object error. Odd I thought, so I read ahead and combined the two lines into:
Dir.entries(dir).map {|f| File.join(dir,f)}.
Looks like the map method needs an explicit list of things to go through. Good to know. Dot syntax to the rescue.

Tonight’s Soundtrack included:
Sing for the Moment‘ – Eminem
Alright‘ – Kinnie Star

Next, we officially start week 23. Exciting.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 12

Day 12 – When repeating yourself is the preferred method is repeating yourself.

Today’s topic is recursion – iteratively calling a function numerous times with a single minor change. On face value, it sounds like something computer technology should help us avoid. In addition, it seems to directly conflict the Ruby on Rails mantra Don’t Repeat Yourself. Though recursion is inherently resource intensive (repeating yourself over and over is often tiring), the prime benefit seems to be highly concise code without resorting to loops or iterators. Yeah, this is alpha-geek stuff.

All snarkiness aside, Slagell is positioning recursion as a tool to help clearly define the necessary action at the smallest level and using recusion to focus.

I should probably read this chapter again.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 11

Day 11 – Program organization, Part 3 of 3.

Today, Slagell clarifies the difference between classes and modules. As I mentioned back in my review of The Object-Oriented Thought Process, a ‘class’ in object-oriented programming is a noun, a Thing. Like a chair, a sweater, or Slartibartfast. Modules are like adjectives. All the nouns I mentioned above could, in fact, be furry. So, if the chair, sweater, and Slartibartfast were classes, they could be all include the same Furry module.

He also offers an solution for the deck of cards exercise. Rather than creating a ‘collection’ class, Slagell subclassed Ruby’s own Array class for Deck. Fine enough. He starts with the shuffle method within the Deck class, finally moving it to the Array class (as made more sense to me) before wrapping up the chapter.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 10

Day 10 – Program organization, Part 2 of 3.

As an experienced information architect, I’m familiar with the challenges of declaring an organizational structure. Whether its for books, furniture, clothing, or software, every structure has it’s biases – somethings are easier, others more difficult. With this in mind, the goal is always to net a more sustainable, maintainable, self-evident state.

Ruby’s include (for modules) and require (for files) commands make organizing code into separate files for easier maintenance possible. The question is how.

Jen once quipped about working in retail, “I can’t sell it, if I can’t see it.”

The same is true in programming, Slagell reminds us, “…for Ruby to include a module, it has to be able to see that module.”

Therefore, the chunk of code to be included should either be in the same file as the include command or the appropriate file should be required. Otherwise, mixing metaphors, the product isn’t really on the floor.

In today’s exercises, Slagell asks us to think about how to organize a program that shuffles a deck of cards.

Here are my initial thoughts:

  • Both “deck” and “hand” are collections of “cards”, differing by the specific number of “cards” contained. Therefore, “deck” and “hand” should be subclasses of a larger “collection” class.
  • It maybe desirable to reorder both the “deck” and a “hand”. So, the action of “shuffle” should be applied at the “collection” level.
  • “Card” should be it’s own class with “suit” and “rank” properties.

This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 9

Day 9 – Program organization, Part 1 of 3.

Back in my review of The Object-Oriented Thought Process, I talked about the difference between is a and has a in programming world. Dave was then kind enough to clarify.

Today’s chapter was that. In practical, We’re-Writing-Code terms, rather than the abstract, This-is-How-To-Think-About-It way of the previous book.

Here’s a quick background in Object-Oriented Design for the non-programmer:

  • Methods are chunks of code that do Useful Things.
  • Classes are collections of, among other things, Methods.
  • Rather than rewriting a Method to reuse it in another class, it can be imported into both Classes – as a Module.
  • Multiple Modules can be imported into a single Class
  • If 2 Modules imported into the same Class contain 2 different Methods with the same name, Ruby says the last one imported is the default.

Sometimes, the only way to stay responsive and relevant is to process things on a ‘last in, first out’ manner. I’m glad Ruby feels the same way.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 8

Day 8, What are regular expressions?

If you don’t know about regular expression matching, or regex, it’s basically a language to find the useful needles in haystacks of text and code. Think ‘find and replace’ turned to 11.

I do just enough regular expression matching to forget how it works. I always end up googling for a quick reference, not quit finding what I need. My text editor of choice, SubEthaEdit has a nicely-formatted pattern reference in the Help menu, though it lacks ‘How RegEx Works’ documentation.

Enter Day 8 of Teach Yourself Ruby in 21 days. Everything about regex is covered; groupings, greediness, repetition, alternators, everything. A while back, I was thinking of picking up one of the many books specifically covering Regex. Now, I’m sure this one chapter will serve me well as that reference.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.


Learning Ruby – Day 7

Day 7, playing catch-up.

I’m continually impressed with how concise the Ruby language is. As I mentioned in Day 4, Ruby frowns upon loops. I’m getting the impression Ruby also frowns upon taking up 2 or more lines to describe an action. Slagell’s examples of doing something a traditional way take up multiple lines, his here’s-a-better-way examples are single line. If we compare writing code to writing words and say each a chunk of code is a paragraph and each line of code is a sentence. Writing Ruby is more like dialog than narrative.

Note to self:
In Ruby, double quotes acknowledges backslash-escaped characters, i.e. "n" = new line. Single quotes will not, i.e. 'n' = n. Same is true for evaluating expressions within #{...}

Two Cool Things in Ruby:

  1. Chained Assigment
    Want to give a number of variables the same value?
    DaveSpeaks = JoeSpeaks = KatSpeaks = FrankSpeaks = "English"
  2. Multiple Assignment
    Want to quickly set the values of multiple variables at the same time?
    DaveSpeaks, JoeSpeaks, KatSpeaks = "English", "Dutch", "German"

The start of the day has quite a bit on binary numbers. I’m not sure when binary arithmetic will come in handy (a position I also expressed regarding Jr. High Algebra) but it’s nice to know it’s here when the need arises. The example Slagell offers at the chapter end feels like a band-aid for a poorly designed system. If any of you following along can provide a comment on when it’s beneficial to use binary arithmetric, I’d be extremely grateful.

As I finished up today’s exercises, Bic Runga’s ‘Listening for the Weather’ came through my iTunes. What an excellent way to wrap up Day 7.


This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.