Pete On Software

RSS Feed

Archive for August, 2009

The Greed Ruby Koan

This post is an extension of my last post on the Ruby Koans. Today, I tackled the next Ruby Koan on the block, which was to score dice throws on a simplified version of the game Greed. The first thing I noticed was that the Koans that I got from EdgeCase had a typo in it. It suggested that the following was true:

That first assert should actually total 250, as the 3 2’s are worth 200 and the 5 is worth 50. I searched the web to make sure that I wasn’t crazy and the version of this file checked in to Google Code by Tim Wingfield agreed with me, so I forged on.

The hardest part of this one for me was figuring out the best way to even work this out in English. I play the Farkle game on Facebook quite a bit, so I was really comfortable with scoring the dice, but I just couldn’t figure out a good step-by-step way to do this. I eventually decided on a Hash to tally up the number of each dice present. This choice was made even easier when I found that Hash had an each_pair method that enumerated over the collection.

After that, I tried my best to implement the logic (this code passes the tests, I don’t promise it is bug-free) and have now put this up for criticism. Last time, I learned some great lessons from Nathan Kelley who shared his code in the comments of my last post. If you have any questions, comments, criticisms, or rebukes of this code, let me know and I’d love to hear them.

I definitely am guilty of writing C# in Ruby and had to undo a lot of code where I started to go down that path, so I welcome comments from Ruby enthusiasts on my code.

Ruby Koans

KoansI decided to tackle a little Ruby language learning this weekend. So yesterday, I downloaded the Ruby Koans and went to work. The Koans were created by EdgeCase to help people learn Ruby. Basically, they are a set of unit tests that exercise aspects of Ruby. To begin, all of the tests fail. You have to write code or jump back and forth to the Interactive Ruby Shell (IRB) and get the results of the statements to make the asserts pass.

I went through and did 105 unit tests yesterday, each of them having several parts to them. Having messed around a little with Rails, I was familiar with using IRB and Rake and a little of the syntax. In my opinion, the way this is set up and builds upon itself is really helpful and is a great way to teach Ruby to n00bs. I really salute Jim Weirich and Joe O’Brien for their work in getting these together.

One of the exercises is to create a triangle method that takes three parameters (the sizes of the sides). You then have to decide what kind of triangle it is. After those tests pass, your next assignment is to prevent 0 length or negative sides as well as making sure your triangle validates.

I wrote all the code and passed all the tests except for the triangle validation test. I was having a serious brain cramp and could not remember how you ensured that you’ve gotten the correct sides for any triangle (and not just a right triangle), so I looked for someone else’s example of this code. I found this code:

Okay, I see. The smallest two sides added together need to be greater than the third side. However, I thought that the author of this code greatly over-complicated this process. We are always dealing with a fixed number of sides and the trick is to put them in order and then add away. I figured Ruby had a simple array sort (and they do), so I would place the sides into an array, sort it, and then add the 0 index and 1 index spot and make sure that it was greater than the 2 index spot. Case Closed and (in my opinion) a bit easier to read. Forgiving of course, that I didn’t pass messages in my exceptions, I personally like my code better (of course 😉 ). I also appreciate that Ruby doesn’t mind me putting ( and ) around my if conditions. I just feel safer for them to be contained 😉

As I do these Koans, I’ve been making note of things I’d like to include in future blog entries about things I’ve enjoyed about the language and will be posting them in the near term.