Saturday, February 12, 2011

Working with the Standard Library in Ruby

Aww yeah, lots of progress today! I got through chapter 6 and 7 of Beginning Ruby. Chapter 6 took me through making a basic text-based dungeon, including designing and manipulating classes for the dungeon, rooms inside of it and a player character. I also defined a means of navigating the dungeon.

However, when I said basic, I meant just that. It's just a four room dungeon with no easy way to get input from players and interpret that into changes in the dungeon itself. Apparently I won't be learning about collecting data until chapter 9. I'm getting impatient, since I've wanted to use variables defined by a user from the beginning, since it's obviously more practical than a static variable. All in good time, I suppose.

Chapter 7 was all about the require command, libraries and Ruby Gems.

Wrong Gem! Beginning Ruby walked me through installing and including various Gems. Easy enough!

The require command and why you'd want to use it is another concept that came easily to me. I find the more I learn about Ruby, the more I get why people like it so much. Some of the syntax itself gives me trouble, but the basic concepts are simple. Maybe that's true for most programming languages, but it's especially true for Ruby.

I did have a question about Ruby. Is code that is easier to read later usually preferable to code that's more efficient? I know a lot of things can be done on a single line, but are usually spread out over a few lines for readability. If I'm correct and readable code is typically preferred, is that unique to Ruby? Seems like it is.

Thursday, February 10, 2011

Mix-Ins and the Indianapolis Ruby on Rails Community

Last night I headed to my first Ruby meet up, with the Indianapolis Ruby Brigade. I knew a few people that would be there, but the room was packed with around 40 people with varying degrees of experience with Ruby.

There were three presentations and while most of it went over my head, I understood more than I would have two weeks ago. I try to keep things in perspective. I can't expect to know and understand everything right away, but I've definitely been making progress. After the presentations, I spoke with a few guys about Ruby and got some great input.

Everything I've been reading about how to get started learning Ruby stresses the importance of becoming part of the community, both locally and online. A local developer told me his own learning and understanding grows exponentially when he's talking to other developers. Overall it was a great experience and I can't wait to go back in March.

In more concrete news, I've been learning about mix-ins tonight. The way I understand it is like this: You build a module with a specific set of attributes. Then you can create a class and include the module, so the class has all the features of the module as well as any class specific features.

Inheritance works as a single unbroken chain, but with mix-ins, separate classes can share some of the same features. Maybe you've got code like so:


Now say I wanted to add information about Fur and Whiskers. Assume this information is the same for both Oskar and Biscuits. As Oskar and Biscuits are children of the Cat and Dog class, which is a child of the Pet class, I'd have to add the information in twice somewhere (assuming I didn't just want to throw it into the Pet class)

DON'T WORRY, Mix-Ins to the rescue! (I'm already pronouncing this as "mixin's" in my head. That may not strictly be correct.)

So what about doing it this way?


I just create two new modules: Fur and Whiskers, then use include Fur and include Whiskers to attach that info to both the Oskar and Biscuits classes. Perfect!

Monday, February 7, 2011

Subclasses and Superclasses in Ruby

So last night I began learning about Classes and inheritance. A class can only inherit from one other class. Makes sense, but the thing I was wondering about all day is this:

Say you have a parent class with a child class, that child class (child1) has a child class of its own.(child2) I am sure this kind of thing is a regular occurrence. So does child2 also inherit from the parent class in addition to inheriting from child1? My guess was yes, it does. So I came home and whipped up some code to test this theory.

class Pet
  def method1
    puts "I am a good pet."
  end
end

class Cat < Pet
  def method2
    puts "I am a cat. Meow!"
  end
end

class Oskar < Cat
  def method3
    puts "I am the BEST cat of all time."
  end
end

oskar = Oskar.new

puts "Oskar says:"
oskar.method1
oskar.method2
oskar.method3

Success! Oskar is a child of the Cat class, which is a child of the Pet class, and Oskar inherits all the logic from the previous generations. Just as I suspected. So a class can only inherit directly from one class, as in Oskar < Cat, but it inherits directly from all classes that come before its parent in the great circle of life.

Is there a bit of code to list all the inherited logic for a particular class? Also, what do you call more than one child class? Childs? Children? Chirren?

Sunday, February 6, 2011

More about Class and Inheritance in Ruby

I'm starting to understand what my Rubyist friends mean when they talk about how awesome and intuitive Ruby is. For every concept I have a hard time understanding, it seems there are two or three that come quickly and make immediate sense.

I'm a little way into chapter 6 in Beginning Ruby and learning about classes and inheritance. Later in this chapter, I'll be walked through making a functional text-based dungeon adventure game, similar to Zork. I'm excited to get more practical experience with Ruby, especially learning how to manage and work with information supplied by users.

Anyway, back to classes and inheritance. It's a concept that's coming really easy to understand, but maybe just because it IS easy to understand. I am immediately suspicious of characters and/or bits of code I haven't seen used before. The first time I saw code written as:

class Shape
end

class Square < Shape

I understood the < meant that any instance of the Square class would also have all the features and logic of the Shape class, as well as any additional features and logic of its own. Aha! I don't think there is going to be one big EUREKA! moment when it comes to learning Ruby, but a series of small (eureka) moments.

Another couple of things I've noticed about learning Ruby are the effects it's had on me. I feel sharper, like my brain works more efficiently now. I haven't felt like this since college, and it's likely just a matter of spending so much time thinking about new ideas.

I also feel more open to meeting new people and I'm really looking forward to my first Ruby meetup this Wednesday.

One last thing: Does anyone else see Ruby as a sort of benevolent version of HAL, and when you get a syntax error it's Ruby's way of saying "I'm sorry, Dave. I'm afraid I can't do that,"?