method aliasing

It's possible to create aliases for methods in Ruby:

Now we can call either say_hello or greet and have the same results:

> h = Hello.new
=> #<Hello:0x9390ba8>

> h.say_hello
Hello!
=> nil

> h.greet
Hello!
=> nil

posting by chance

I had a delightful day with my girlfriend yesterday. =)

But just before I went to bed, I realized I hadn't written a single line of code all day, and that's bad luck. =)

It was already late and I after searching for ten minutes or so (man, it's hard to find a website with real simple exercises) I chose a trivial problem: write a program that simulates rolling a par of dice (I wanted something really simple, just to write my bit of code for the day and not upset the Coding Spirits).

I started writing a test, something like:

def test_roll_dice

  die = Die.new

  result = die.roll

  # assert... wait, what?

end

What would be my assertion? That the result had to be between 1 and 6? But if I write a roll() method which returns numbers between 1 and 7, the test would pass 85% of the time. I thought about it for a while, and I really don't have any clue of how to test random stuff. I hope Kent covers that in his book...

The really fun thing is that something trivial like this led me to a meaningful question, something interesting that I will surely look into later.

I guess programming is like a box of chocolates... =)

rewriting history 2

Continuing from my last post:

I've discovered how to get back to an old commit. I was at chapter 16 and that's what I did:

git checkout chapter_14_SHA1_id

Took me back to chapter 14 again. After working through chapters 14 and 15 for a second time, I commited the code just before chapter 16. To make my HEAD revision point to this last commit, I did:

git reset chapter_16_SHA1_id

I re-coded chapters 14 and 15, and went from chapter 16 on. The first chapter 14 and 15 commits went to hell, but that's ok for now.

And I also found a way to correct the last commit, which is great if we forget do add a file or something like that. After adding the files as usual, that will do the trick:

git commit --amend

Awesome! =)

rewriting history 1

As I said before, I'm coding in Ruby as I follow through Kent's book. Whenever I start a new chapter, I commit the code. If I want to start over the chapter I'm in, I just revert my changes. I haven't discovered how I would revert my code to an old commit yet (for instance, if I wanted to work through the second chapter again), but I'm pretty sure there is a way.

Between chapters 14 and 15, I made some minor changes to the code. My history was something like this:

commit - going to chapter 14
commit - minor changes
commit - minor changes
commit - deleted file
commit - going to chapter 15

I wanted to go back to chapter 14, but I didn't want to lose the minor corrections I did before chapter 15. I was wondering if there was a way of merging multiple commits, and after some googling, I've found this article. It is possible and very easy to do. I've merged my commits and now the repo is just like I wanted.

I think git will never cease to amaze me.

blast from the past

Yesterday, when I wrote the last line of that code snippet, I felt weird. It didn't feel right.

Today, when my friend and mentor The Fridge read the post and saw it, he said that last line was practical, but could be a bad idea in Rails views, because it could bloat the code in no time.

Thinking about it reminded me of the pairing session I had with one of Thoughtworks guys. Then I decided to revisit the code we wrote on that day. I've discovered some really cool stuff:

• The true magic of git: I was running my code on an Ubuntu VM at the time. After I was lured to the dark side of the Force I deleted the VM and saved all my Ruby stuff in a tar.gz file. After more than an year, I extracted it all to a folder in Windows, and EVERYTHING was there: the repo was working, all the commit history, even the files' statuses was untouched. It was really mind blowing. Would it happen if I was using SVN? I don't think so. I guess Linus is right.

• All my tests were green: yay!

• My code was broken: damn! That boot camp was one of my first experiences with TDD, so that's ok, I guess. I had all my classes and methods covered by tests, but my main source file wasn't. Or maybe I had tampered with the code recklessly after the boot camp, I don't know. But the cool thing was: I had and old piece of code that wasn't working. Then I wrote a new test for and old broken feature. And I was like "I wonder if that's how it feels like to deal with legacy code using TDD". I haven't got to that part on Kent's book yet, and I know there are some good books on this topic.

• Yep, that code was bad. I remember Netto telling me that stuff like that exposes the guts of your class and that's bad. (his wording was better, for sure)

So a better way of doing it would be something like this:

Ah... That's much better... =)

private rovering

The code in Kent's book is all Java, but as I follow through I'm coding in Ruby, and this change led to some interesting discoveries.

After changing an attribute in my class to private, my code stopped working for no apparent reason. After some googling I've found this article. The access specifiers (public, protected, private) have slightly different meanings in Ruby and Java. For my code to work, I had to use protected, while in Java I'd had used private. Interesting.

I've also learned about the Value Object design pattern. This is a cool pattern to implement small things like a pair of coordinates (x,y) and such. And that reminded me of last year's Thoughtworks Boot Camp I attended. They presented the Mars Rover problem to us. The rover position should be represented by two coordinates and the orientation, for example: 0,0,N. In this case, The rover would be on the top bottom left corner of the map, facing north. The position would be represented perfectly by something like this:

I don't know if there's anything more to this pattern, but Martin Fowler's book which describes it is already in my to do list.

first off

Okay, so where should I begin?

Ruby is the language, Rails is the framework, so the Ruby language would be a good place to start.

I know the basics of Ruby, but before I delve deeper into it and start coding like crazy, there's something else: there's no point in learning the most awesome language in the world and use it to write crappy code. So, before I write any Ruby, I have to make sure I do it right. Therefore, the first step of my journey will be Test Driven Development.

I'm starting to read the classic Test-Driven Development By Example by Kent Beck, and doing my coding using Ruby and test-unit. I know rspec is the big thing in unit testing nowadays, but the goal now is to learn TDD itself and not worry about the framework. Test-unit will do for now, as it's simple, intuitive and didactic.

wtf?!?

Despite of what you're thinking, this blog is not about oral sex and ancient constructions, although that would make a really hilarious topic. Imagine the pictures! Machu Picchu! The Colosseum! Stonehenge!

This blog is about my journey to become a good Ruby On Rails developer. Oral By Ruins is just an anagram for Ruby On Rails. Sorry to blow away your expectations...