Day 12 – When repeating yourself is the preferred method is repeating yourself.

Today’s topic is recursion – iteratively calling a function numerous times with a single minor change. On face value, it sounds like something computer technology should help us avoid. In addition, it seems to directly conflict the Ruby on Rails mantra Don’t Repeat Yourself. Though recursion is inherently resource intensive (repeating yourself over and over is often tiring), the prime benefit seems to be highly concise code without resorting to loops or iterators. Yeah, this is alpha-geek stuff.

All snarkiness aside, Slagell is positioning recursion as a tool to help clearly define the necessary action at the smallest level and using recusion to focus.

I should probably read this chapter again.

---

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 11 – Program organization, Part 3 of 3.

Today, Slagell clarifies the difference between classes and modules. As I mentioned back in my review of The Object-Oriented Thought Process, a ‘class’ in object-oriented programming is a noun, a Thing. Like a chair, a sweater, or Slartibartfast. Modules are like adjectives. All the nouns I mentioned above could, in fact, be furry. So, if the chair, sweater, and Slartibartfast were classes, they could be all include the same Furry module.

He also offers an solution for the deck of cards exercise. Rather than creating a ‘collection’ class, Slagell subclassed Ruby’s own Array class for Deck. Fine enough. He starts with the shuffle method within the Deck class, finally moving it to the Array class (as made more sense to me) before wrapping up the chapter.

---

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 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.

---