Want to write a successful Ruby gem? Here’s how in THREE EASY STEPS!

Step 1: Invent a catchy moniker

Choose something either intrinsically cool (e.g. skycrane) or ironically cool (e.g. unibrow). If you get the name right, every Ruby developer will want to use your gem and be disappointed if it isn’t relevant to their current projects.

Step 2: Decide what it should do

It doesn’t matter. Sure, ideally your gem’s name will give some clue as to its function. But if the name is awesome enough, no one will mind if it’s obtuse or even misleading. And don’t worry if it’s already a solved problem. In fact, don’t even bother checking. Your awesome name will make it superior.

If you’ve wracked your brain and come up empty, an HTTP client is always a good choice.

Step 3: Design your API

Ruby devs have a fever, and the only prescription is more DSL! Also, puns. And I don’t mean that pun; I mean code puns. Here are two examples of a library that sends files over any network protocol. You tell me which will be preferred.

FileSender::send_file file, :protocol => :sftp, :host => 'example.com', :username => 'jimmy_jimmy', :password => 'my_cats_name', :path => '/some/dir'

# vs

SkyCrane.lift! file do
  sftp do
    host 'example.com'
    username 'jimmy_jimmy'
    password 'my_cats_name'
    path '/some/dir'
  end
end

I can’t think of an example use case for Unibrow, but I know you’ll want to use it anyway.

Unibrow.join left, right

See? How much more awesomer would your code be if that was sprinkled throughout?

Why all the hate, bro?

It isn’t. It’s merely a few observations I’ve made during my years as both a user and creator of Ruby Gems. I love using well-designed APIs as much as the next; some are even a joy. I’m only noting that occasionally we risk becoming a little silly. Obviously this isn’t unique to the Ruby community. If I was a Java developer, this post may have been about Factory Factories, and Factory Factory Factories.

The more I look at it, the more I like the SkyCrane idea…