Deployment comes with far too many tools. For instance, this whole set is often used together:

And that’s not counting the smaller things like Vagrant plugins, Capistrano plugins, the many Chef cookbooks and so on, which would also be used with these. And it’s definitely not counting the many, many competitors. That whole list is just one stack of tools.

For some of them, it’s clear why you use them. VirtualBox? Yeah, okay, something has to make a VM if you test locally.

But why do you need both an “app deploy” tool (Capistrano) and a “server configuration” tool (Chef)? Can’t your server configuration just include your app? For that matter, if your “app deploy” tool runs scripts as root, can’t it configure your server?

There Can Be Only One?

Some people do use just one. It’s possible to deploy apps through Chef, but please don’t! It’s possible to do all your server configuration through Capistrano — really, really don’t.

For best results, think of Chef and Capistrano as two separate tools for two different jobs.

So what are those jobs?

Some famous people told me how to get superpowers. I did. They all happen to agree on this topic. Now I’m going to tell you the same secret. I’ll even help you out a bit more.

The most powerful, important thing you can do is to get your code in front of the people who will use it. Do it as fast as possible. Do it when it’s not ready yet. Do it when it makes you uncomfortable.

What does that have to do with superpowers, though? We’ll get there. But first, more about shipping code.

But It’s Not Ready!

Jeff Atwood, the guy who started Stack Overflow, knows all the excuses. That’s why he wrote Version 1 Sucks, But Ship It Anyway. It’s worth a read.

In the end, it boils down to this. You’re somebody who is reading about software when you don’t have to. Right here in this post, even! You care about your craft.

First off, let’s just say: Heroku is awesome. There are all kinds of great reasons to use it, and I would never, never claim that Heroku is wrong for all deployments.

But it’s also not right for all deployments. Let’s talk about when it’s wrong and when it’s right.

"Easy mode!"

Heroku’s big advantages are:

  • really easy to deploy
  • really easy to scale
  • mostly everything just works

Those are big advantages. Sometimes they’re the most important thing for your project. When they are, you should absolutely use Heroku.

But why might you not?

It’s Expensive

First, the elephant in the room: the cost. Heroku gives you limited free hours per month, and after that it’s expensive. Background threads or processes also cost extra.

A single minimum-power dyno runs you $36 per month, assuming you need barely any space in Postgres. Heroku is basically going to cost you at least twice what a VPS would cost (e.g. Linode or Digital Ocean) and give you much less power. If you process many simultaneous requests or run many background threads, it will be at least three or four times as expensive for the same power.

Here’s a video about threads in Ruby – how do you code them? What are the problems with them? I’m planning a few more short videos about Ruby concurrency. I don’t think enough people have a good grasp of the tradeoffs and problems of running more than one chunk of code at once, in Ruby or in general.

I’m also still learning Camtasia and the rest of the video toolchain. So I hope I’ll look back in a few months and think, “wow, this looks really bad now!”

In the mean time, enjoy! Here’s a transcript:

Ruby supports threads, of course. Modern Ruby, anything 1.9 and higher, uses
the normal kind of threads for your operating system, or JVM threads if you’re
using JRuby.

[next slide]

Here’s the code to make that happen.

The code inside the Thread.new block runs in the thread, while your main
program skips the block and runs the join.  “Join” means to wait for the
thread to finish - in this case, it waits up to 30 seconds since that’s what
we told it. With no argument, join will wait forever.

You’ll probably want a begin/rescue/end inside your thread to print a message
if an uncaught exception happens. By default, Ruby just lets the thread die
silently. Or you can set an option to have Ruby kill your whole program, but I
prefer to print a message.

In “normal” Ruby, Matz’s Ruby, there’s a Global Interpreter Lock. Two threads
can’t run Ruby code at the same time in the same process. So most Ruby threads
are waiting for something to complete, like an HTTP request or a database
query.

[next slide]

What are Ruby threads good for if there’s a global lock? In Matz’s Ruby,
you’ll mostly want to use them for occasional events. RabbitMQ messages,
timeouts, and Cron-style timed jobs are all good.

Since you can only have one thread doing real work in Ruby at once, threads
are best when your process is mostly idle.

JRuby and Rubinius users can chuckle here. Their Ruby handles multiple Ruby
threads working at the same time without a hiccup.

So what problems do you sometimes see with Ruby threads?

[next slide]

With the Global Interpreter Lock, threads can switch back and forth between
CPUs, sometimes very often. If you see Ruby threads performing horribly in
production with Matz’s Ruby or using way too much CPU, try locking the thread
down to a single CPU. Your operating system has commands for that — Google
them.

Next, if the main thread dies or finishes, your program ends.  That’s a
feature, but sometimes it’s surprising. To have your main thread of execution
stick around, use join on the other threads to let them finish.

And of course an unhandled exception in a child thread kills only the child
thread, and it does it completely silently.  Use a begin/rescue/end to print
errors to console or set the Ruby option to kill the main program when a child
thread dies from an unhandled exception.

Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another’s code; too little and expressiveness is endangered.

Ruby, on the other hand, is an experiment in “give every toddler a chainsaw”-level freedom. And as Gary says in that talk, you get some things like RSpec, ActiveRecord and Cucumber that simply aren’t possible at the lower “reasonable” levels of freedom.

95% of what only Rubyists can do with that freedom is horrible, irredeemable crap. But the other 5% couldn’t have happened in any other way.

pictures of gemstones

If you’ve never built a Ruby gem, go do that first. It’s amazingly easy. And it lets other people use your stuff!

When you do you’ll have to figure out — how much goes into one gem? What should you cut up into new gems?

Here’s how you tell.

What’s the Big Idea?

You want your gem to have one basic idea. Then, cut out everything that isn’t part of that idea. If your gem solves differential equations… Great! Don’t expose methods for memory allocation just because you wrote them.

The people who download your gem are busy, and they have short attention spans.

So you get to tell them one thing. What’s that one thing?

Aren’t Gems Inefficient?

People from other languages make fun of five-line gems. Ruby people usually know better.

A Ruby gem can do amazing things in five lines — single ideas that don’t take more than that can be awesome.

If you’re using 20 kilobytes to package up five lines of text… Dude! It’s 20 kilobytes. You waste more than that in TCP headers checking gmail every five minutes.

Gems are cheap. I promise.

Helping people see your amazing idea is priceless. Don’t shovel in hundreds of lines of crap so it seems “more serious.” Just show off the important part.

electronic message headers

How Big is Too Big?

pictures of gemstones

There are many explanations of the problems with God Objects, a.k.a. Monster Objects — objects that do too much and know too much.

Libraries can have the same problem.

A library that knows too much is giving you orders. RSpec includes its own mocking library… And so it’s hostile to people who like RR (Ruby Double) or Mocha. It forces you to do things its way. Is that why you started programming Ruby?

As much as I love ActiveSupport, it does the same thing. It requires very specific versions. It monkeypatches the core libraries. It’s just not friendly to people who want to do their own thing.

In the end, this is like “one idea” up above… If you force your users to do it your way, they’ll hate your gem. Show them something awesome and they’ll love it.

But I Want Numbers!

I can’t give you a maximum number of lines for your gem. But here are some rough ideas:

ActiveRecord is about 30,000 lines… And it’s a huge gem. If you’re writing more Ruby than this in one go, you’d better have a really good reason. And its largest file (associations.rb) is still only around 1500 lines. That’s a lot of Ruby code.

Pony is a fabulously useful email gem, which mostly wraps another, worse email gem. It’s only 500 lines, and half of that is tests. I do not care that it’s “too small.” I care that it works well and the interface is awesome. If it were only 10 lines, I would still use it happily.

The important thing, for both of them is: the gem has one central idea, and it stays true to it.

You should do the same.