Garrick van Buren

Day 10 – Program organization, Part 2 of 3.

As an experienced information architect, I’m familiar with the challenges of declaring an organizational structure. Whether its for books, furniture, clothing, or software, every structure has it’s biases – somethings are easier, others more difficult. With this in mind, the goal is always to net a more sustainable, maintainable, self-evident state.

Ruby’s include (for modules) and require (for files) commands make organizing code into separate files for easier maintenance possible. The question is how.

Jen once quipped about working in retail, “I can’t sell it, if I can’t see it.”

The same is true in programming, Slagell reminds us, “…for Ruby to include a module, it has to be able to see that module.”

Therefore, the chunk of code to be included should either be in the same file as the include command or the appropriate file should be required. Otherwise, mixing metaphors, the product isn’t really on the floor.

In today’s exercises, Slagell asks us to think about how to organize a program that shuffles a deck of cards.

Here are my initial thoughts:

• Both “deck” and “hand” are collections of “cards”, differing by the specific number of “cards” contained. Therefore, “deck” and “hand” should be subclasses of a larger “collection” class.
• It maybe desirable to reorder both the “deck” and a “hand”. So, the action of “shuffle” should be applied at the “collection” level.
• “Card” should be it’s own class with “suit” and “rank” properties.

---

This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.

---

Day 9 – Program organization, Part 1 of 3.

Back in my review of The Object-Oriented Thought Process, I talked about the difference between is a and has a in programming world. Dave was then kind enough to clarify.

Today’s chapter was that. In practical, We’re-Writing-Code terms, rather than the abstract, This-is-How-To-Think-About-It way of the previous book.

Here’s a quick background in Object-Oriented Design for the non-programmer:

• Methods are chunks of code that do Useful Things.
• Classes are collections of, among other things, Methods.
• Rather than rewriting a Method to reuse it in another class, it can be imported into both Classes – as a Module.
• Multiple Modules can be imported into a single Class
• If 2 Modules imported into the same Class contain 2 different Methods with the same name, Ruby says the last one imported is the default.

Sometimes, the only way to stay responsive and relevant is to process things on a ‘last in, first out’ manner. I’m glad Ruby feels the same way.

---

This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.

---

Day 8, What are regular expressions?

If you don’t know about regular expression matching, or regex, it’s basically a language to find the useful needles in haystacks of text and code. Think ‘find and replace’ turned to 11.

I do just enough regular expression matching to forget how it works. I always end up googling for a quick reference, not quit finding what I need. My text editor of choice, SubEthaEdit has a nicely-formatted pattern reference in the Help menu, though it lacks ‘How RegEx Works’ documentation.

Enter Day 8 of Teach Yourself Ruby in 21 days. Everything about regex is covered; groupings, greediness, repetition, alternators, everything. A while back, I was thinking of picking up one of the many books specifically covering Regex. Now, I’m sure this one chapter will serve me well as that reference.

---

This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.

---

Day 7, playing catch-up.

I’m continually impressed with how concise the Ruby language is. As I mentioned in Day 4, Ruby frowns upon loops. I’m getting the impression Ruby also frowns upon taking up 2 or more lines to describe an action. Slagell’s examples of doing something a traditional way take up multiple lines, his here’s-a-better-way examples are single line. If we compare writing code to writing words and say each a chunk of code is a paragraph and each line of code is a sentence. Writing Ruby is more like dialog than narrative.

Note to self:
In Ruby, double quotes acknowledges backslash-escaped characters, i.e. "n" = new line. Single quotes will not, i.e. 'n' = n. Same is true for evaluating expressions within #{...}

Two Cool Things in Ruby:

1. Chained Assigment
   Want to give a number of variables the same value?
   DaveSpeaks = JoeSpeaks = KatSpeaks = FrankSpeaks = "English"
2. Multiple Assignment
   Want to quickly set the values of multiple variables at the same time?
   DaveSpeaks, JoeSpeaks, KatSpeaks = "English", "Dutch", "German"

The start of the day has quite a bit on binary numbers. I’m not sure when binary arithmetic will come in handy (a position I also expressed regarding Jr. High Algebra) but it’s nice to know it’s here when the need arises. The example Slagell offers at the chapter end feels like a band-aid for a poorly designed system. If any of you following along can provide a comment on when it’s beneficial to use binary arithmetric, I’d be extremely grateful.

As I finished up today’s exercises, Bic Runga’s ‘Listening for the Weather’ came through my iTunes. What an excellent way to wrap up Day 7.

---

This post documents my journey through Sam’s Teach Yourself Ruby in 21 days. I’ll be joining Al Abut in his effort to learn Ruby and blog along the way.

---