Want to build a realtime web game? Or a web site that updates instantly when users add stuff?

You’re going to need to take control of your own deployment. Heroku, for instance, isn’t going to handle that well.

But first, here’s a little parable about Bob (who is, um, totally not an alias for my early mistakes… Probably.)

The Parable About Bob

Bob was an old-time C programmer. When he built C programs in his spare time, nobody ever saw them. You can give people source code, but usually they can’t use it in that world. And building an installer is horrible, especially if you have any friends with a different OS than you use. That used to happen, back in the day.

Ruby on Rails was awesome and Bob loved it. You could put something on a server and then your friends could use it. How cool is that?

And it had some fun new features like server-sent events. If you can make a good chat server, chances are good you can make a game, too. Bob was trying that out.

And actually, he came up with a kind of cool game. There were some hexes and some things in them. Stuff moved around a little and there was a chat window next to it.

Bob was running everything on his development machine, which was a little complicated, but he could manage.

Bob had a server that he used for a few things, and mostly he just installed stuff by hand.

So he went ahead and ran everything he needed (back then: Redis, an even older version of Juggernaut and his Rails app.) And everything was fine.

Of course, he had to set everything up again when he rebooted. But that wasn’t a big deal.

Also, his app would crash sometimes. That wasn’t a huge thing.

Juggernaut would also crash sometimes, and that meant restarting it and his Rails app.

And every time somebody logged in, something wasn’t working. Sometimes they emailed Bob. Mostly, they just didn’t look at the game, even though it was kinda cool.

Before long, Bob didn’t feel like showing off his game to his friends any more.

In fact, he was kinda done building games. Suddenly, Ruby on Rails kind of sucked.

Maybe Don’t Be Bob?

Bob didn’t know it, but a lot of his problem was that deploying Rails apps suddenly gets hard when you care about the details. Anything you’d build an interactive game or a chat server on turns out to require some work. You need to care about what app server you use (Unicorn? Thin?) You need to care about running custom servers (Redis? Something with EventMachine?)

Unfortunately, that’s harder than it should be. Right now, off-the-rack solutions don’t usually work.

Right now, you need to use a big custom stack of tools, and they’re hard to use.

You could go read up on all the tools and debug them together.

Or you could let me do it.

Sadly, I know all about Bob. And it sucks to be him.

Instead, let me show you how to set up your deploy the right way — that means easy to modify, easy to re-roll-out, easy to run custom stuff.

My pilot program is open right now.

Want to stop being Bob?

Free Email Rails Class? Free Chapters? News?

* indicates required
You'll hear about Ruby on Rails internals, database migrations and whatever Rails programmers can benefit from.

Comments