Note: I’ve expanded on these ideas in a conference talk, which you can see here.

I recently learned about a feature of the Ruby programming language that has shaken me to my very core.

Consider this code:

# dog.rb
class Dog
  attr_reader :name

  def initialize(name)
    @name = name or raise ArgumentError
  end
end

def get_dog
  Dog.new("Milo")
end

thing = get_dog
if Dog === thing
  puts thing.name + " is a dog"
end

What happens when you run this code? Feel free to try.

But I’ll tell you.

$ ruby dog.rb
Milo is a dog

This code seems pretty resilient to unexpected runtime errors.

Looking at the code, it seems pretty reasonable to believe:

when we have an instance of Dog, we will be able to send it the message name and get back a String

Up is up. The sky is blue. We’re living in a society.

Well, ok, but we can’t actually assume that the value will be a String, because it doesn’t check that. If we change our definition of get_dog, things blow up:

def get_dog
  Dog.new(["Milo"])
end

$ ruby dog.rb
dog.rb:15:in `<main>': no implicit conversion of String into Array (TypeError)

But, OK, at least that error message is pretty good. This is user error. When we write thing.name + " is a dog", we’re expressing some amount of faith in ourselves that we expect a String, because values of other types don’t necessarily respond to a + method. This is a leap of faith that we’re all willing to make when we use Ruby. Other languages eliminate the need to make that leap of faith by checking types when you compile your code, but Ruby doesn’t do that.

And that’s fine.

So maybe our expectation should be:

when we have an instance of Dog, we will be able to send it the message name and get back a truthy value

And we’ll just remember to provide Strings. Maybe we’ll write a comment indicating the expected type of the parameter.

Well, what if get_dog looked like this:

def get_dog
  dog = Dog.new("Milo")
  def dog.name
    nil
  end
  dog
end

Maybe it just casually redefined the name method for that instance. Then your program crashes like this:

$ ruby dog.rb
dog.rb:19:in `<main>': undefined method `+' for nil:NilClass (NoMethodError)

Which… OK, who’s going to write code like that? Not me and no one I work with, for sure!

But where does that leave our statement of beliefs?

when we have an instance of Dog, we will be able to send it the message name

We can’t even say “and get back a value” because what if the override raises an error?

Perhaps you see where this is going…

Well, what if get_dog looked like this?

def get_dog
  dog = Dog.new("Milo")
  dog.instance_eval('undef :name')
  dog
end

$ ruby dog.rb
dog.rb:17:in `<main>': undefined method `name' for #<Dog:0x007fecc104a870 @name="Milo"> (NoMethodError)

Which, again, lol. You can just remove methods if you want to? Sure. No one is going to write this. I know.

(By the way, hat tip to Agis on Stack Overflow for sharing this trick. I figured it was possible but didn’t know how.)

OK so what can we say for sure?

How about this:

when we have an instance of Dog, it will have an instance variable @name defined

Wow that’s sad! How do we even check that? Maybe like this:

thing = get_dog
if Dog === thing
  puts thing.instance_variable_defined?("@name").inspect
  puts thing.instance_variable_get("@name").inspect
end

$ ruby dog.rb
true
"Milo"

OK great, have we reached the bottom?

No, because there are no rules in Ruby.

We can probably break this in many ways. Here’s one:

def get_dog
  dog = Dog.new("Milo")
  dog.remove_instance_variable("@name")
  dog
end

IMO this one is a bit pedestrian. Yeah, fine, you can just remove instance variables on random objects if you want to. Of course. My spirit is already broken, this isn’t meaningfully worse.

So let’s just try to say something that we don’t have to take back right away:

when we have an instance of Dog, the code in the initialize method must have run

Right? That has to be true. We’re living in a society, remember?

Nope:

def get_dog
  Dog.allocate
end

That results in this output:

$ ruby dog.rb
false
nil

What the hell is this?

This is the thing I mentioned at the beginning that I learned recently. When we create new objects in Ruby, we usually use the new class method. Notably, we don’t call the initialize instance method ourselves, although that’s what we are responsible for defining. Ruby handles calling that method for us. But before Ruby can call an instance method, it needs an instance, and that’s where allocate comes in. It just makes an instance of the class.

And you’re allowed to use it in your Ruby code, if you want to.

(Hat tip to John Crepezzi whose blog post explains this really well)

If you do, you get back a normal instance of your class in every way, except that the initialize method hasn’t run.

You can even call your own initialize method if you want to:

def get_dog
  dog = Dog.allocate
  dog.send(:initialize, "Milo")
  dog
end

We have to use send because initialize is private. Well, unless we change that:

class Dog
  attr_reader :name

  public def initialize(name)
    @name = name or raise ArgumentError
  end
end

def get_dog
  dog = Dog.allocate
  dog.initialize("Milo")
  dog
end

Sooooo where does that leave us?

when we have an instance of Dog, it’s a good dog

Basically: 🤷‍♂️.

That’s the bottom. That’s as far as I know how to go. Maybe there’s more. Please don’t tell me.

I want to emphasize: this is not a criticism of Ruby. I’m only faux-alarmed. Ruby is a springy ball of dough. It’s whatever you want it to be. All of these features are sharp knives you can use or abuse.

As I’ve been learning another language which feels much less pliant, I’ve started to notice things about Ruby that never occurred to me before. When I write Rust, I take some pleasure and comfort from the rigid rules. It’s more possible to use words like “guarantee” and “safety” in Rust-land.

But Ruby keeps you on your toes.

I learned a neat shell script refactoring strategy yesterday that I’d like to share. First some background:

I used to use a rubygem to help me write this blog. When I wanted to create a new post called “chainable shell functions” I would have run:

bin/poole draft "chainable shell functions"

And it would create a file called _drafts/chainable-shell-functions.md with some metadata in the first few lines.

Yesterday I got the urge to try replacing that rubygem with a custom shell script which does exactly the same thing.

I am an enthusiastic novice shell scripter.

I’m vaguely aware there are different dialects of shell scripting and that I’m probably using the wrong one.

Really I’m not expert in this stuff.

But while writing this one I learned something interesting that I’m going to share with you now.

Here is the first draft (annotated with comments for your convenience):

#!/usr/bin/env bash

# fail fast if any expression fails
set -e

# read all of the arguments into a string
title="$*"

# OK don't worry about this gnarly line, I'm going to break it down
slug=$(
  echo "$title" | sed "s/ /-/g" | tr -dc '[:alnum:]-' | tr '[:upper:]' '[:lower:]'
)

# the file we're going to create
filename="./_drafts/$slug.md"

# create the folder if it doesn't already exist
mkdir -p _drafts

# stop if the file already exists -- I don't want to overwrite an in-progress draft
if [[ -e "$filename" ]]; then
  echo "$filename already exists"
  exit 1
fi

# create the draft by piping a string into a file
echo "---
title: $title
date: $(date '+%Y-%m-%d')
---

Alright, this is where your post goes." > $filename

# Print a successful message
echo "Created $filename"

OK did you read that? Great.

So you saw that line I promised I would break down? The idea with that line is that I want to take the input, which is the title of the post, and figure out what is an appropriate filename for the post. I’m figuring that out by applying a series of transformations to the title:

• echo "$title"
  • just repeats the title, directing the output into a “pipe”, which the next command will read
• sed "s/ /-/g"
  • sed is a “stream editor”; it reads in a stream of data and prints out a stream of data
  • here we’re using regular expressions to “s” or substitute all occurences of a space with - (hyphen)
  • we want hyphens because they make for nicer looking URLs than spaces, which get escaped to %20.
  • the g at the end means “global”; without it, we would only subsitute the first space
• tr -dc '[:alnum:]-'
  • tr is short for “translate”
  • -d means “delete”
  • -c means “complementary”
  • this command means “delete all the characters that complement this set of characters”
  • in other words, “delete all the characters that aren’t alphanumeric or a hyphen”
• tr '[:upper:]' '[:lower:]'
  • “translate” again!
  • this time we’re translating all of the upper-case letters to lower-case letters
• Finally, we stop piping the output to the next command, and we’re done, so the result is saved in that local variable.

OK so that’s a lot going on in one line, and because of the compact nature of these commands, it’s not super readable.

In other languages, when I have a lot going on in one function, I want to split out smaller, well-named functions. Can I do the same thing here?

At first I wasn’t sure. I knew it was possible to write functions that received arguments by checking $1, $2, etc in the function, but I wasn’t sure how to make them “return” values…

After a little googling I learned: you can just write a shell function that calls commands that read from a pipe, and pipe things to that function.

Let me show you what I mean.

Here’s the second (and, frankly, final) draft:

#!/usr/bin/env bash

set -e

function dashify() {
  sed "s/ /-/g"
}

function removeSpecialChars() {
  tr -dc '[:alnum:]-'
}

function downcase() {
  tr '[:upper:]' '[:lower:]'
}

title="$*"
slug=$(
  echo "$title" | dashify | removeSpecialChars | downcase
)
filename="./_drafts/$slug.md"
mkdir -p _drafts

if [[ -e "$filename" ]]; then
  echo "$filename already exists"
  exit 1
fi

echo "---
title: $title
date: $(date '+%Y-%m-%d')
---

Alright, this is where your post goes." > $filename

echo "Created $filename"

Look at that!