Exercise 24: More Practice: Learn Ruby the Hard Way: Practicum

At this stage, we are actively engaged in and focusing on getting the core competency down. Much of what we have done at this point has been really basic. I understand that. It's usually about now that, after the basics of the language are presented and looping and case statements are demonstrated, that the beginner books stop and the user is then thrown into the deep end and trying to make sense of real projects. In this case, again, there's a benefit to focusing on the language directly and hammering out the code by typing everything in as it's seen (i.e. doing it the hard way). Do them, get them exactly right, and do your checks. Oh, and it looks like my idea to "copy everything into one file" as a practice was unnecessary. Looks like we'll be doing that here :).

What You Should See

$ ruby ex24.rb
Let's practice everything.
You'd need to know 'bout escapes with \ that do
newlines and tabs.
--------------

The lovely world
with logic so firmly planted
cannot discern
the needs of love
nor comprehend passion from intuition
and requires an explanation

where there is none.

--------------
This should be five: 5
With a starting point of: 10000
We'd have 5000000 beans, 5000 jars, and 50 crates.
We can also do that this way:
We'd have 500000 beans, 500 jars, and 5 crates.
$

Extra Credit

Make sure to do your checks: read it backwards, read it out loud, put comments above confusing parts.

[The one thing I found helpful was the return value for the function being spelled out. Again, I'm used to seeing the return values for functions spelled ut, so seeing the specific return value I felt was a positive. It also helps to make the section where the function is used to show where and how the string values are printed out more easy to understand. Otherwise, I didn't feel I needed to comment anything in the file. It feels pretty straightforward.]

Break the file on purpose, then run it to see what kinds of errors you get. Make sure you can fix it.

[Changed names and added misspellings to the file to see what the outcome would be (changing variable names so that they are unreferenced). The problem with this approach is that I understand what I'm breaking. It's one thing to break something on purpose, see the error and then fix it. It's another thing entirely when you inadvertently break something, and then rack your brain to try to figure out why it's not working. Still, seeing the breaks you create and seeing the error messages can help you understand what and why that may be happening can help you understand what might be causing it.]

TESTHEAD's TAKEAWAYS:

It's important to keep practicing each day and to use the skills that you are developing and do a bit of poking and refactoring each day. I think this will work well with the chart of values we created a couple of days ago. Things we actively do will be better remembered than things we do once and then forget.