Screencast: Working through Assignment 3
2 Comments »
This screencast goes through the Assignment 3 package. We’ll focus on:
- The package layout. By and large this is a pretty standard layout for a Ruby application. (Not a Rails application — a plain Ruby application.)
- The assignment (in the instructions/ directory).
- The files you need to modify to finish the application.
- What the demo.rb application looks like once your code is working.
- What it would look like if your code passes all of the tests.
- Three strategies for getting the assignment done:
- Think about the big picture, and about how you’d design your own application to determine the strength of a random selection of 5 cards according to the rules of poker. You might even write such an application. Then you would adapt it to satisfy the tests.
- Study the instructions/ web pages, and implement the code according to the various definitions of the classes and methods.
- Try to pass the tests one by one.
- We believe that the best way to proceed is through a combination of 2 and 3. 1 is hard, because it may turn out that the semantics you come up with are at odds with the framework we’ve defined for the tests. So . . . we will walk through a bit of combining strategies 2 and 3, showing:
- The rake command (more on rake: Pickaxe, p. 229 [a bit out-of-date], and this tutorial: http://www.railsenvy.com/2007/6/11/ruby-on-rails-rake-tutorial
- What a test looks like (more: Pickaxe, chap. 12)
- How to interpret what a test “Error” or “Failure” means
- That should be it.
A word to the wise: Writing code to tests will look bewildering at first, but once you start doing it, you will love it.
View (you will want to maximize your browser; to go “full-screen” in Firefox, press F11; then to turn off full-screen, press F11 again)
Errata:
- When I define the reader for @card_number, I say that I’m defining a local variable. In the heat of producing the screencast, I misspoke: It’s an instance variable.
- Also, when I’m nattering on about converting card_number in the appropriate suit, I say: card numbers 2 to 25 are Hearts. Of course I meant 13 to 25. I get these things wrong. That’s what computers are for!
“Computers are useless. They can only give you answers.” — Pablo Picasso
October 8th, 2007 at 1:54 pm
This was very helpful. I have a couple of questions.
Should we copy your descriptions of the public methods into “=begin rdoc =end” blocks in our .rb files ?
Also, I’m trying to run in Eclipse but I can’t seem to run “rake spot” from Eclipse — I was hoping there would be a rake window like there is an ant window — does anyone know how to set that up ?
October 8th, 2007 at 4:04 pm
It could be convenient to rake spot outside of Eclipse. Keep the focus on the Ruby . . . Eclipse could be a distraction.
For the comments question: NO! Do not copy the documentation for the classes and public methods on Card, Deck, and Hand to your own .rb files.
Here’s what I wrote in the “Questions and Answers” section at the end of the instructions/ README:
‘There is no need to write RDoc (public comments before “class” and public methods) for the _tested_ methods in Card, Deck, and Hand. Why? Because the documentation we hand out is what you must code to. If you ADD public methods, provide RDoc comments for them.’
In other words, if it passes the tests, then it is satisfying the docs you see in instructions/ and it would be an empty labor to copy all of the comments.
We do say that if you do something tricky, complicated, impressive, etc., inside of a method, you should add comments for that. But, please, there is no need for repetition of the Card, Deck, and Hand class/method comments that are, in effect, your assignment.
If you *add* stuff, though, you may add simple comments before any new classes and methods. E.g. (what follows is fictional! You probably won’t need additional classes or methods: In the solutions Amy and I have written, many methods are one line each . . .):
# MyWhizBanger represents a method for classifying # Hands using Bayesian statistics. The Hand class # delegates to it. class MyWhizBanger # An entry of collected data should be passed to # this method when it is encountered. def capture_historical_data(entry) # cool stuff here end end