Initializing Classes in Ruby

I definitely tend to jump around a bit when it comes to learning to code. I was working on Manticore quite a bit, then jumped into Learn Ruby the Hard Way, and now I've hit a bit of a snag so I checked out Code School and the introductory Ruby lesson. (This lesson is based on Why's old lesson, by the way, and is awesome so far) I'm a big fan of Code School so far, because hands-on, practical tutorials have always been one of the best ways for me to learn.

Much like Learn Ruby the Hard Way, it's a lot of review, but I've been interested in seeing what Code School has to offer for a while. Not to mention, switching gears slightly seemed like a better use of my time than sitting around frustrated because I wasn't understanding defining Classes and initializing them properly. I also think the more time I can spend having fun with Ruby, the better. I end up coding longer and enjoying it more, which leads to me learning more and it all kind of snowballs from there until I can build a sort of half-ass snowman with string literals for arms and instance variables for eyes.

Still, Ruby isn't all string methods and arrays, so I'll get back to my problem with Learn Ruby the Hard Way pretty soon. Probably tomorrow!

Here's the basic problem: I have one Class, Game, and the extra credit for this particular exercise is to break the Game into two Classes: Engine and Map.

Here's a link to a gist of what I've got:

Gothons Attack!!

What I'm assuming I need to do is break the rooms a player goes through (methods such as :central_corridor, :bridge_access, etc) into the Map method, and put the code that drives the game into the Engine method. So now I need to learn what initializing a class does, how to do it, how to call a method in one class from another class, and how to make two classes work in concert. For example, Engine will be starting the game (I assume) and moving the player through the rooms that are defined in Map (I also assume) Any input on this problem is, as always, HIGHLY appreciated!

I used to think of learning Ruby as unearthing this huge artifact, but now I think of it as being inside of a mostly darkened room, where I'm stumbling around and looking for switches. Once in a while, I flip a switch and it might illuminate a far off corner, or a whole corridor, or just a tiny little piece of the room. Does that make sense? Or in other words, learning how to do new things is really frustrating right up until it's not, and then it's awesome.

Using class_eval to add methods to a class

So I finally slogged my way through Chapter 10 in Beginning Ruby. It wasn't nearly as helpful or interesting as I thought it would be. I mostly got hung up on MySql for a few days and had a hard time working through it.

I don't think I need to learn how to interact with databases just yet, so I moved on to Chapter 11: Advanced Ruby Features. Aha! Now we're talking. I spent some time working with class_eval, which allows you to add methods to a class dynamically, and exec, which allows a script to run another script.

Here are some questions I've got, though.

What's the benefit of using class_eval to add methods to a class instead of just defining those methods within the class itself? This isn't a temporary definition, right? So it seems like you'd end up writing about the same amount of code, but defining methods within the class instead of adding them later would keep the code more organized.

And when it comes to exec and fork, what's the benefit of using these commands to spread the functionality between scripts? I'm seeing this as similar to using mix-ins. For example, you could have a script that checks the time on the user's system, then either does or does not do something based on that time. It might be useful to run this script from various parts of your overall program and that's why you would want to do it. Am I thinking about this in the right way?

I'm also starting to wonder where I should go once I'm done with Beginning Ruby. The book is already warning me the last section is mostly just appendices and reference, so any recommendations are welcome.

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.

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!

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,"?