explorations in test driven, idiomatic, functional, beautiful ruby code with a veteran

Free Ruby TDD

Weekend Workshop

"google hangout and - sundays 12pm-2pm central time"

posted in:
Blog News
22 April 2014
by: James OKelly

So I am in the middle of a lot of planning for “Ruby Workshops in the Tropics” this summer, where myself and a few other advanced programmers will be holding sessions to help you write tests, more concise, idiomatic ruby, and more….

It got me thinking I should just do some group pair programming on a weekly schedule. I already do several hours of consulting pair programming via CodeMentor and it has been a lot of fun.

So here we go! This Sunday, the 27th from 12pm to 2pm Central Time I will be holding a Ruby TDD session where I answer your questions and do some live coding for you. To participate in the session, you will need to have the Google Hangout plugin installed in the browser of your choice, and know how to open your terminal and ssh.

If you plan on participating, please send an rsvp to In the body please answer these questions so I can better prepare:

  • Ruby level (1-5)
  • Test experience (1-5)
  • Years of general programming
  • Operating System of choice
  • Editor of choice

Then click this button to subscribe to the calendar event and get the link!

I hope to see you there!


Writing Software that is

Easy to Change

"my manifesto for clean, beautiful Ruby"

posted in:
18 April 2014
by: James OKelly

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.

TDDing Pat Shaughnessy's

Ask, Don't Tell

"prefer the explicit over the implicit"

posted in:
Functional Ruby
30 March 2014
by: James OKelly

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.

Applying Design

Patterns To Ruby

"Making our deck of cards more beautiful still"

posted in:
Design Patterns
29 March 2014
by: James OKelly
  • 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.


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.

A Faux-O Deck of Cards

a la Gary Bernhardt

"Mixing functional and OO styles to win"

posted in:
Design Patterns
24 March 2014
by: James OKelly

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.

An Exercise in

Refactoring in Ruby - Part 2

"Using Extract Method Object to refactor large methods"

posted in:
Refactoring Ruby
22 March 2014
by: James OKelly

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!

A Deeper Look at

Ruby's Enumerable

"the most powerful part of ruby you don't use"

posted in:
Standard Library
14 December 2013
by: James OKelly

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.

An Exercise in

Refactoring Ruby


posted in:
Refactoring Ruby
6 December 2013
by: James OKelly

Today I want to examine one of my favorite refactoring patterns, Extract Method.

  • When a method does too much or is too long? Extract method.
  • When you see a conditional with an if and an else. Extract method.
  • When you see a comment… EXTRACT METHOD!

Consider the following code: