You have probably heard that Ruby has multiple parentages.

• LISP for its syntax tree and functional enumerators
• Smalltalk for it’s object orientation
• Eiffel for it’s blocks
• Perl for it’s regular expressions

Ruby has four parents, and it takes Matz’s favorite aspect of that language and blends them together into a hybrid, multi-paradigm, utility language that would do everything he wanted to do, and to say it with less ceremony.

Now Ruby certainly gets more ideas from each of these parents as listed above, but for a moment let’s focus on the most mind-blowing, language specific aspects of at least 3 of them.

In this chapter we will explore the first if them, LISP

Please note - for the experts in these languages

I am attempting to limit scope to what is important to the subject at hand. I am not an expert at these other languages by ANY means. I am a Rubyist with a bit of exposure to a few of these.

LISP is essentially boiled down into this for the Rubyist: you have lists, which can contain not just data, but code (functions), and to do that, sometimes a function can become a piece of data, be added to a list, queried as code again when the time calls for it. All in a lazy manner. Let me try to illustrate this for you in Ruby.

I get asked this question a lot from developers I coach. Or I get the question in it’s other form, “So how do you learn to write clean, uncoupled ruby?” Or the other question, the one I tend to hear from people who disagree with me… “Why do you have such strong opinions? How did you choose your opinions?”

The 3rd form of the question I will answer like this. I did not choose my opinions… They chose me. Every single one of them was either me losing an evidence and reason based contest of opinion, and the other was experiencing developer pain but not having the solution. The solution was this list below for the most part.

A path to becoming a great Ruby programmer

I have been on a journey for some time now. It started when I was a 8 year old kid who decided to take his Dad’s Betamax apart to see how the movies got in there. It continued when I was 10 and I got a Commodore and played tape-drive games like Red Baron. My future was forever set in stone when I arrived at a new Jr. High School @ 13 and they had AppleIIes in my home room, math lab, and computer lab.

I would obsessively play Zork and more than anything, I wanted to know how to write such a game. I didn’t get very far on that front, but I did start writing BASIC. I took anything that resembled a computer class, or even a class which had computers in it. By them we had some clone IBM at home, and there I would POKE sounds out and obsessed with learning more.

I am nearly 40 now. In a couple of years I will not be the young crazy guy I once was. I will be a middle-aged life-long programmer. And honestly, shit ain’t so bad yo. I couldn’t be happier. But enough about me, let’s get to my secret for writing solid ruby code that always gets an A on CodeClimate, and rarely has bugs. My secret for writing Ruby code that is easy to extend and change.

This article was spawned in response to a comment on Pat Shaughnessy’s awesome article Use An Ask, Dont Tell Policy With Ruby asking about TDDing the example.

Take the following text (The Lake Isle Of Innisfree)

I will arise and go now, and go to Innisfree, And a small cabin build there, of clay and wattles made: Nine bean-rows will I have there, a hive for the honeybee, And live alone in the bee-loud glade.

And I shall have some peace there, for peace comes dropping slow, Dropping from the veils of the morning to where the cricket sings; There midnight’s all a glimmer, and noon a purple glow, And evening full of the linnet’s wings.

I will arise and go now, for always night and day I hear lake water lapping with low sounds by the shore; While I stand on the roadway, or on the pavements grey, I hear it in the deep heart’s core. W. B. Yeats

We want a script to be run against this text and to match a word against it. If a match is made, that line, and all lines after it will be returned.

We already know what the code should end up looking like, we have the post. But we need to TDD it, so where do we start? To me the obvious entry point is the domain logic.

Reading a file is not domain logic. Matching a word against text and return a value is, so we will start with the lines_after test.

We will need some lines to test against, so lets load those into an array directly from the Yeats poem. We will also need our first test!

If the target word is not found anywhere in the poem, then we want to return an empty array.

• This is part 2 of a multi-part series. Read part 1 here.

If you do not already know who Avdi Grimm is then please, go check out his Confident Ruby when you have time. It is an AMAZING read. If you know about Confident Ruby already then you get to see some examples here.

Essential this style of coding uses liberal casting to keep nils and conditionals out of your code. It is also a style of Ruby that adheres to the Tell, don’t ask principle. Because co-opting nils is evil, as is reaching into an object’s state in order to decide what it should do.

Let’s go back to our deck of cards. I put it into a repository for you this time so you can work along with me. Once that is forked, clone it down. You will find all the tests are there, just like I promised in part 1!

You can also compare that to the origin gist to see where I started from if you aren’t down to read part 1.

Step 1 - Change the Structs to an immutable object

Since we are going for a mostly functional approach here, I don’t want the option to mutate these cards. To get closer to accomplishing that, we need to replace the structs that Deck is composed of, Card and Suite, with Value objects from Tim Crayford’s library, Values

These are pretty much like structs, however they are immutable. I will point out here that there is a bug in the gem version that doesn’t seem to be in the github version. Because of that bug we will use the Class version instead of my preferred ‘struct block to const’ method.

Old

New

I made one more change here to be “Confident”. I cast rank to a string. That removes any chance of getting a nil value! I may get an empty string, but I wont get a nil. Then for style consistency I capitalize the first letter and lowercase the rest.

Let’s build a deck of cards today using a hybrid approach, that is to say, lets use good Object Oriented design but keep our objects stateless and our functions idempotent, a la Gary Bernhardt style, Faux-O, or “Functional Core/Imperative Shell”.

I am going to skip the tests for brevity - the test ‘noise’ in non-testing articles is a bit much for this format. I however do have tests, and I encourage you to write tests!

We are going to need to describe a deck of cards using objects, so let’s look for some logical boundaries and give them names. One way we can do this by describing what we want in a paragraph and a title. Let’s do that now!

After I wrote that paragraph I underlined what I would call actors, which may or may not become objects or collections of objects. These are usually the recurring nouns.

I have previously been over the extraction pattern, Extract Method. Today we will explore it’s big brother, Extract Method Object.

The Extract Method Object pattern is used to take a method or groups of methods from coupled, untestable code into code that adheres to the Single Responsibility Principle, or an object/method/construct should have 1 and only 1 reason to change.

Let’s jump right into some very scary, real, untestable (mostly) controller code:

Whew! That is one big ball of mud!

Have you ever needed to load a VERY large file in ruby? No I don’t mean your 500 line rails model. I mean a several gig binary or text file.

Try it. Watch your machine become unresponsive. Cry a little inside. Then reach for enumerable.

Ruby’s Enumerable module gives you a way of iterating over collections in a lazy manner, loading only what you need, when you need it. But it gives us so much more than that.

Today I am going to walk you through a couple of highly useful methods from Enumerable that has come up in a few coding challenges I have done over the years.

each_cons, any?, all?, none?

I use these methods when I need to determine the ‘distance or difference’ in a set of numbers or objects. each_cons simply gives us a ‘sliding’ window of our list so we can compare multiple items in our list.