BDD: Take Two

Yesterday I finished the Codebreaker example in the RSpec book. I spent many hours in a confused state, and then it began to make sense. The book teaches you to follow a red/green/refactor cycle when building tests and code.

Yesterday, I was in the green as far as my understanding went, so I decided to apply that knowledge to my own existing code. Now, I'm back in the red and pretty confused.

This is what my day looked like:

1. Red (go back to the book, beg Google for answers, try something, try something else)
2. Green (something actually worked, sweet),
3. Refactor (try to do something mildly snazzy),
4. And back to red. I spent most of the day in this part of the cycle.

I do like the principles of BDD and the theory behind what I'm learning, even if the practice itself is a bit challenging. It makes sense that one would want to write self-documenting code and build tests that also serve as documentation.

As I work through the exercises, I keep thinking back to web projects that I've worked on the past, and how this process would have made a world of difference if it had been followed by my team from Day 1. This methodology really speaks to my sense of organization, but given how long it took me to work through the first example in the book, I can't say that it speaks to my sense of efficiency (yet). I'm hoping that perspective will change as I become more comfortable with RSpec and Cucumber.

BDD with RSpec and Cucumber

If I had seen the title of this blog post four weeks ago, I would have skipped over the first part and focused on the word that I understand: cucumber. Green, cool, refreshing, delicious cucumber.

But due to a few hours of poring over The RSpec Book yesterday, I can now see that this title is not a vegetable. It is, in fact, a can of worms.

BDD, or Behavior Driven Development, is a methodology that arose out of TDD (Test Driven Development). Wikipedia says that its creator, Dan North, describes BDD as

a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Clearly, it is not a vegetable. It's a system of writing tests in a language that's understandable by people of diverse backgrounds (i.e. non-programmers). By describing what the code is supposed to do in normal language, it's easier to see whether or not you should be writing the code at all. One of the goals of the BDD method is to minimize extraneous work and stop wasting time and money.

RSpec and Cucumber are tools for writing tests and adhering to BDD principles. I'm a Ruby newbie, so a lot of what I'm learning feels as foreign as this post title. However, I accept the process, so I'll continue working through The RSpec Book today and hopefully begin writing some tests for Mastermind.

Mastermind: The Sinatra Edition

Today I had a major success: I got Mastermind to work in Sinatra! It took a lot of trial and error, looking up documentation, and help from Paul, but I finally got a working version. In the future version of this game, I'd like to have some colored elements that you can drag and drop into four spaces.

On top of getting Sinatra to work, I also spilled the news to Doug that I used to be a juggling instructor in Chicago Public Schools. That's right—I taught concepts in physics through circus arts to 6th graders in Pilsen (as in, gravity is always to blame for drops, not poor juggling skills). This meant that I had to do an impromptu juggling show for the entire office. I threw stuff for a few minutes and demonstrated a basic Mills Mess and Burke's Barrage. At some point soon, I'll bring in some props and do a real lesson for the crew. These guys still need to learn about siteswap—the numeric notation of juggling patterns that counts beats per throw and determines which types of patterns are physically possible to execute.

Yes, I was put on the spot, but the Red Velvet Cheesecake totally made up for it.

And here's the Sinatra app for Mastermind.

Building Mastermind in Sinatra

Today I began working with Sinatra, a Domain Specific Langauge (DSL) that allows me to create web applications in Ruby. This is very exciting—there is life beyond green text on a black terminal screen.

Along with learning Sinatra comes new growing pains. I've been having so much success with Ruby that I forgot about the whole point of learning it: to create web apps. Oh, right.

The two most helpful resources that I found for learning Sinatra were the Singing With Sinatra three part series on Net Tuts, and the intro posts on this guy's Sintra blog.

Next step: make it work.

Installing Gems on Tiger

For my apprenticeship at 8th Light, I decided to make some use of my very first laptop: an iBook G4. I know what you're thinking—sweet choice, right? It's the perfect blend of everything you don't want in a laptop—not quite vintage enough to be cool, yet not quite modern enough to be functional. Yep, it's running Mac OS 10.4 Tiger, and no, its processor and internal storage isn't good enough to handle 10.5. This means that I'm stuck installing legacy software and I can only use it for very basic tasks, like checking email and running text editors.

Anyway, here's what I had to go through to install rspec and Rails on my little machine.

I'll add links to all of this stuff someday, so that the poor unfortunate souls out there who are still running Tiger will at least have a shot at installing Rails.

1. Get XCode
1. With 10.4 Tiger, you need a legacy version of XCode 2.5.
2. This means that you need to sign up for an Apple Developer acccount. If you sign up under Safari, it's free.
3. It's really difficult to find XCode 2.5. Go to the Apple Developer Downloads Page (you'll need to sign in), and then click back a couple of pages.
2. Once you have XCode, you should be able to install MacPorts. 
1. This can take awhile. You need version 2.0.3
3. Once you have MacPorts, you can install Git. 
1. This took me about 5 or 6 hours to download and compile. Since I was working with a relatively fresh install of 10.4 and didn't have any of the other resources installed on my machine, it took a long time to catch up with all of the necessary files. (such as Python, GCC, etc)
4. Then you will need to update your version of Ruby to 1.8.7
1. Check your ruby version with ruby -v
2. The version that came preinstalled with the 10.4 OS on my machine was 1.8
3. I had to update twice: once to 1.8.2 and then to 1.8.7
4. I don't know if 1.9.3 works on 10.4
5. Finally, you can install gems 1.3.7. Make sure you get the right version!
6. Then you can install RSpec and Rails!

Mastermind

Remember that game with four colored pegs where you had to guess the correct colors and order in 15 tries? Well that's what I'm trying to build. Surprisingly, it's going really well. A couple of weeks ago, I wouldn't have even known where to begin. Now I'm getting to the point where I can actually build stuff and understand it. It's incredible to see such progress in such a short period of time.

When I get frustrated or don't understand what to do next, I take breaks to read intro programming books or study Ruby documentation. I'm not sure how accurate this theory is, but I still believe that knowledge osmosis will sink in—that my brain will store little bits of information, and someday, at just the right moment, that knowledge will come back into my consciousness and add the missing piece to a puzzle. Regardless of whether or not that's true, taking a break from staring at broken code does help me to refresh my thoughts and approach the problem more effectively.

I still have a lot of work before Mastermind is complete, but I'll post the code to GitHub soon.

Supermarket

Instead of banging my head against the wall trying to figure out how to complete the dice game, I decided to try something easier that would still give me a chance to learn by doing. I began working on a kata to determine the price of a shopping cart filled with fruit.

The trick is that supermarkets often have tricky sales: three for a dollar, 25% off when you buy $5 or more, buy 2 get one free, etc.

Building this application allowed me to keep moving forward when I felt very stuck. I'm hoping that I can go back to the dice game after completing this project and approach the problem with fresh eyes and more hours of experience.

Here's the link to Fruit Stand on GitHub.

Dice Game

I began building the Dice Game at the end of the Ruby Koans sequence. It's an extra credit project, but it turned out to be a very helpful exercise in helping me to work through a more complicated project than any I had encountered before. The game built off of previous work in the Koans sequence, specifically a scoring project and defining a dice class.

This command line game allows you to choose how many players, enter the players' names, and then it rolls five dice for each player and determines the winner based on a separate scoring rubric.

The most challenging part of this app was adding the option for more than two players. It was relatively easy to return the highest number in the array, match the score to the appropriate name, and announce the winner. However, finding and announcing a tie was much more difficult. I was psyched when I finally got the tie announcement to work.

Here's the code.

Coin Changer

You know those little machines at Walgreens that spit out coins after you buy your gummy bears? Have you ever thought about why those machines give you three quarters and three pennies, rather than 78 pennies? I hadn't, although if I ever came across a poorly programmed coin machine that spat out 78 pennies, you can be sure that I would start thinking about it (that is, I would think about it after I finish whining about my heavy pockets).

On my first afternoon at 8th Light, I sat down with Paul and he walked me through the process of building a coin changer.

We first built the coin changer to return the correct number of pennies. Using Test Driven Development (TDD), Paul and I went through the red/green/refactor process of creating failing tests, fixing those tests, and writing more efficient code. Eventually we worked through nickels, dimes, and quarters, and by the time we had finished, you could have added 78 cent pieces to the mix and it still would have worked.

It was a great intro to Ruby and TDD, and it became my kata for the week. Here's a link to the Coin Changer Kata on GitHub. It isn't quite finished; I still need to remember how to take out all of that nasty duplication.

I will attack this problem again soon.