So I was extremely lazy this weekend and only spent a couple hours working with Ruby. Awful! However, I think a little time away from actively learning caused a few things to click in my head. Imagine a pair of gears, left to their own devices after hours of meddling and tinkering, that suddenly come together and begin to move. Not smoothly, perhaps, but real motion!
It's hard to describe what clicked for me. The syntax seems to make more sense the more I work with it. While working through Beginning Ruby, I've been typing every bit of code out, then attempting to run it. It's good practice, both to get used to how Ruby is written as well as learning what will cause Ruby to throw up AND how to fix those little problems. How often do you guys do something stupid like this?
class Person
attr_accessor :name, :age
end
fred = Preson.new
fred.name = "Fred"
fred.age = 35
puts fred.name
puts fred.age
Only to have Ruby throw up everywhere because of two little letters that got switched?
I'm guessing this transposition kind of crap is something that will haunt me FOREVER, but I'll get better at spotting it as I go along.
Also I would like to say that I wrote this bit of example code almost ENTIRELY from memory. So things are sticking. I still have a hard time believing how easy some of this is, but there's still plenty I don't really understand yet. Still, let's not get ahead of ourselves here.
Still working through Chapter 9. I just installed my_sql. How do you pronounce this, anyway? I heard a guy at the meetup a couple weeks ago call it "My Sequel" which seems better than "MY SQL" but I don't know.
Monday, February 21, 2011
Thursday, February 17, 2011
Ruby and Databases
I started digging into Chapter 9 in Beginning Ruby tonight. It's all about databases and while I never, ever thought I'd be excited about working with databases, this chapter is something I've been looking forward to for a while.
Let me tell you why.
Up until now, for all the little programs and tests I've been making, I've been inputting static variables. It's my understanding static variables have limited real-world application. I want to learn how to write code that can write, interpret and modify data and this database work is the first step to understanding that process.
So far, I've been able to get Ruby to create a new text file, write something in that file and then close it. I've learned how to open files in read or write only mode, in read AND write mode, in append mode and so on. Fascinating! But it's a bit difficult to grasp. Still, I think I've got the basics of how it works, now I just need to keep working through and figuring out what I can do with these commands.
Is there a site you can join to write and publish Ruby code for testing? Is that what Heroku is for? Anyone?
Bueller?
Let me tell you why.
Up until now, for all the little programs and tests I've been making, I've been inputting static variables. It's my understanding static variables have limited real-world application. I want to learn how to write code that can write, interpret and modify data and this database work is the first step to understanding that process.
So far, I've been able to get Ruby to create a new text file, write something in that file and then close it. I've learned how to open files in read or write only mode, in read AND write mode, in append mode and so on. Fascinating! But it's a bit difficult to grasp. Still, I think I've got the basics of how it works, now I just need to keep working through and figuring out what I can do with these commands.
Is there a site you can join to write and publish Ruby code for testing? Is that what Heroku is for? Anyone?
Bueller?
Tuesday, February 15, 2011
Learning about testing, debugging and optimizing Ruby code
I just finished up chapter 8 in Beginning Ruby. It was mostly about documenting, debugging, testing and optimizing code. Not the most interesting chapter, but it's still important to understand.
Writing custom exceptions is easy enough to understand. Begin and Rescue makes sense. Once again, I'm amazed at how easy Ruby is to grasp. You want Ruby to do something 100 times?
100.times do
puts "DO WHAT NOW"
end
Maybe it's just because I've got some experience now, but this bit of code is easy to break down. I'm looking forward to the day that more complex bits of code are as easy to grasp! One step at a time.
But here's a question about optimizing code. Do you typically try to optimize as you write the code, or do you write the code and then optimize it? At first, it seemed logical to try and optimize as you write the code, because it seemed like the most efficient way to work. However, once I read further, writing code and then optimizing it seemed more efficient, since you could figure out which parts of your code need to be reworked. This way you wouldn't waste time thinking of ways to optimize code that wasn't really a problem to begin with.
Benchmarking code is another concept that made sense immediately. Since Ruby offers you the ability to do something in multiple ways, being able to figure out if one method is inefficient is important.
Next up is Chapter 9: Files and Databases. OH YEAH! Never thought I'd be so excited to learn how to call a database for information and then manipulate that information and display NEW information to the user! This is what I've been interested in since I started reading Beginning Ruby.
Writing custom exceptions is easy enough to understand. Begin and Rescue makes sense. Once again, I'm amazed at how easy Ruby is to grasp. You want Ruby to do something 100 times?
100.times do
puts "DO WHAT NOW"
end
Maybe it's just because I've got some experience now, but this bit of code is easy to break down. I'm looking forward to the day that more complex bits of code are as easy to grasp! One step at a time.
But here's a question about optimizing code. Do you typically try to optimize as you write the code, or do you write the code and then optimize it? At first, it seemed logical to try and optimize as you write the code, because it seemed like the most efficient way to work. However, once I read further, writing code and then optimizing it seemed more efficient, since you could figure out which parts of your code need to be reworked. This way you wouldn't waste time thinking of ways to optimize code that wasn't really a problem to begin with.
Benchmarking code is another concept that made sense immediately. Since Ruby offers you the ability to do something in multiple ways, being able to figure out if one method is inefficient is important.
Next up is Chapter 9: Files and Databases. OH YEAH! Never thought I'd be so excited to learn how to call a database for information and then manipulate that information and display NEW information to the user! This is what I've been interested in since I started reading Beginning Ruby.
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.
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!
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?
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,"?
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,"?
Subscribe to:
Posts (Atom)