Intro to my possible Ruby Book

Writing Beautiful, Functional, Immutable Ruby


My own history

I have been coding since I was thirteen, when my Father came home with old IBM clone that he traded for during the 80’s barter craze. Being nearly forty years old now, I have stubbed my toe and left it bleeding in more than a dozen languages now. If I were a construction worker instead of a knowledge worker, I would probably be missing fingers, toes, and possibly a hand or leg.

When I look at my whole career in code, I see a common theme. From BASIC, to C to C++, to VB, to Javascript to C# to Ruby I have been writing imperative, stateful code for my whole career. I have lived with loops, state mutation, and C syntax, and was blissfully unaware of anything else as I had skipped the CS degree and opted to go directly into the workforce at eighteen.

I worked through the 90s as the Internet was in it’s very early years. I had a Geocities page for my Warcraft tips and strategies. It probably didn’t blink, but it must have been fugly. I worked for companies that turned email into snail mail, companies who turned snail mail into email, and companies who made adware for Windows machines and a little bit of everything in between.

When I coded in C, we hated those ‘weird’ C++ guys. We would tease them about using a language before the improvement, since it wasn’t ++C. Then I joined that group to write DCOM and COM+ for Intel. We made fun of the VB programmers. Then I became a VB programmer when ASP exploded, since it was essentially VBScript, and I don’t like context switches. Then it was semi-colons that were stupid.

Continue reading this article..

RubyLoveLive Sunday Sessions

Live TDD - Session 1 - Static Blog Generator


This week we started to outside-in, TDD some code towards a static website generator. Here is the video!

Continue reading this article..

Refactoring conditionals out of your code

Using inheritance and OOP to remove complexity


Today I will be doing something a little different.

I have prepared some Ruby code to show how conditionals can breed like rabbits, and how to spay and neuter those bunnies before it gets out of control.

Along with the code, there is a screencast or as I will call it, a RubyLovecast. In the video, I will walk you through several revisions of the code, first showing how conditionals grow, then how to take a weedwacker to them.

Continue reading this article..

I am now a till time Ruby/Rails coach

Level up your skills with RubyLove


  • Please note, I am not accepting students…. unless I suppose you have an exceptional mind.

I have to apologize for being away so long. I ended a relationship that had drug on for far too long and going nowhere, and at the same time I decided that I will no longer accept clients that refuse to place the proper amount of importance on quality and training.

The two of those catalysts essentially derailed my life and then gave me a hovercraft instead! I started mentoring @ and then was convinced by a friend of mine to also become a full time mentor @

Needless to say, I have been very, very busy.

Along with now mentoring about 12 people from various sources (we do 2 hour sessions monday through thursday and students chose from the morning or evening session) I have been speaking with awesome developers who have been my heroes.

Continue reading this article..

Passing lispy code as data in Ruby

exploration of Ruby's parentage to discover powerful techniques


You have probably heard that Ruby has multiple parentages.

  • LISP for it’s 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.

Continue reading this article..

As a new Rubyist what can I do?

what should I do to become a GREAT developer?


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

Continue reading this article..

Why I can TDD and why DHH Can't

coupling, conditionals, and state are making your life hard


I have been writing Ruby for a long time, and Rails for almost as long. However MOST of my work has been Rails, something that I am VERY grateful to DHH for. His excellent ideas that became Rails changed my life, so:

“Thank you David, you can say what you want and write coupled code and not test first, you will always be a hero of mine for making it possible for me and all my geek friends to play with Ruby every day and make a living doing it!”

At first, I HATED TESTING. I fought it’s adoption arguing the position DHH has returned to, browser testing by humans. I hated it because I sucked at it. But I always have a mentor, and I ended up with one who was a XP’er and an old small talker. That changed my life.

But I was still testing too much, testing the wrong things, mocking too much and in the wrong place. I didn’t apparently REALLY know what a unit test was. I was using RSpec and everything I wrote was highly coupled to Rails and the database.

And these are the reasons why I hated testing and thought it sucked. I had code to write.

Why DHH cant TDD

Coupling is the amount of internal knowledge that “leaks” out of the objects you write. When objects start knowing about each other to the extent that you cannot change one without changing the other, or you can’t swap one out without changing the other. There are many other forms of coupling.

I am not the only who thinks this, and case in point, here is the GREAT Jim Weirich DECOUPLING his logic from Rails, something that DHH would have left alone or put into a concern: Decoupling Rails

Isolation is when your object has NO external dependencies. Isolation is where you want to be. Class A may know that it needs another class, but it doesn’t know it is Class B. If Class C follows the same interface as Class B, then Class A doesn’t care which it gets.

Continue reading this article..

TDD isn't dead because DHH doesn't do it

coupled, stateful, complicated code is ruining your TDD experience


DHH’s original post is here tdd-is-dead

My response: Why I CAN TDD why DHH sucks at it

A better much less ranty post with INFORMATION on how to learn to write amazing Ruby can be found As a new Rubyist What can I do?

There used to be a shitty rant here about being banned from a forum over my heated defense of code craftsmanship, xp, and tdd. It has been deleted because I am a shitty writer and it doesn’t reflect the message I care about, Ruby and Coupling and Demeter and Abstractions, SOLID etc. The kind of shit that I am much better suited speaking about.

What follows is the sliver of what wasn’t shitty, which is shitty. So here it is. You want the original crap? Google it.

I hear the argument time and time again, and I heard it on RR Parley several times. It goes like this:

“My code is awesome without TDDing it. I don’t TDD it because TDDing my code is hard.”

Continue reading this article..