If you’re new to Ruby on Rails, you may be new to the old debates (pro and con) about how “Rails doesn’t scale.” You might wonder why people say that, or where it came from.

Let’s talk about that.

As far as “Rails Doesn’t Scale”, the main arguments go something like:

1) Ruby is slow, often up to 50x slower than C, so the server will eventually collapse.

This isn’t actually a scaling argument. But it’s true that Ruby is slow. Not 50x any more, closer to 5x (up to maybe 20x), but still, that’s not terribly speedy.

Rails doesn’t help Ruby here. A lot of the metaprogramming techniques it uses are among the slowest things Ruby does. I wrote a book about how Rails uses those techniques called Rebuilding Rails. They’re awesome, but they’re not speedy.

In practice, Ruby and Rails apps often “farm out” the slow stuff. The database is the traditional place to put the heavy lifting, but you’ll see Redis and Cassandra used in similar ways. Want Ruby to be fast? Call to something that isn’t Ruby, and is designed for speed :–)

Pure Ruby is quite slow, but just as scalable as any other language or library. It doesn’t get somehow slower as you add more.

2) Ruby/Rails leaks resources, so large or long-running projects don’t work

There was once more truth to this. Ruby had a few leaks and Rails exercised Ruby like nothing else. Also, ActiveRecord encourages large amounts of garbage per request, which was easy to mistake for leaks.

I had the good luck to be an early reviewer of John Sonmez’s excellent book “Soft Skills: The Software Developer’s Life Manual”. So you get a review!

I’m a huge fan of teaching developers more communication skills and especially more about their careers. I love Edomond Lau’s ‘The Effective Engineer’, for instance.

Soft Skills is a book like that — more career than communication skills, and especially a lot of very frank talk about how to promote yourself in your career. It also includes several other chapters of how to take care of yourself as you develop for a living; that means fitness, investing, and even morale.

Oh! And don’t miss the story of how he got the review, at the last minute, from Uncle Bob Martin. Even if you’re not a big fan of Uncle Bob.

Open Secrets

This is powerful stuff, and stuff I’ve never seen another book teach. In fact, go read the chapter names in the table of contents before you come back. I promise, it’s worth your time. And the table of contents will tell you far better than I did just what the book is about.

As Patrick McKenzie celebrates his 9th year in review and many other folks write theirs up, I believe I’ll write my first. It’s been a big year, and I have a lot to be thankful for.

Don’t know me? Makes sense. I wrote Rebuilding Rails, an ebook about understanding Rails by building a Ruby web framework from the ground up, as a result of Amy Hoy’s excellent 30x500 class. I’m writing a Ruby web app deployment class called Rails Deploy In An Hour. I’m employed full-time as the Analytics lead at OnLive, a cloud-gaming company. I have a wife and two kids, so selling products on the side is an adventure I don’t really have the time for — but I don’t let it stop me :–)

Let’s start with dollar amounts before explanations. That’s why I’d be reading if I were you.

Revenue in 2014

Amounts are net of processing fees and refunds. Also, it’s Dec. 23rd, so not quite done. But pretty darn close. Tell you what: if anybody buys a professional package of Rails Deploy In An Hour, I’ll update this to reflect it :–)

• Rebuilding Rails: $7,679.35 – 208 non-refunded sales, 6 refunds
• Rails Deploy In An Hour: $1,277.70. That’s three pilot students and one professional package buyer. Plus 1 sale-and-refund of developer package from a guy who thought I was farther along than I was.
• Misc – affiliate sale, guest episode: $600.00

Rails Deploy In An Hour is doing… okay. I reopened the class a few weeks ago and I haven’t done much for it since then. I’m waiting until more of the class is finished to seriously advertise for it, which means no sooner than January and more likely February.

Rebuilding Rails is basically flat year-over-year. That’s not amazing, but honestly better than I expected. My flurry of activity for the new class is breathing more life into it. I’m not doing much marketing for Rebuilding Rails itself right now. It has some nice posts that still bring in visitors, and an autoresponder email class. I’m playing with the idea of doing more of a second edition of Rebuilding Rails, but I just can’t justify it right now. Maybe in 2016?

(Do you just want more dollar amounts? My First $1000 in Product Revenue may be the right place for you.)

Products

Last Year’s Goals: I knew I wanted a new product. I didn’t think about much more.

This year I launched Rails Deploy In An Hour to its pilot class of three people, and I’ve made one continuing sale. It’s a deeper, more involved and more expensive product than Rebuilding Rails and it’s going to take awhile to really finish — not that such a product is ever 100% finished. I have three chapters done of seven, and two videos of at least ten, plus several miscellaneous guides well under way. Overall the class is probably 35%-40% done, though the software works fine now. This class? It’s too many pieces. I’m managing, but it’s a lot.

(Also known as “why doesn’t Capistrano pick up my changes???”)

One of the cool things about Capistrano is that you don’t even have to put your Capistrano files into your app repo. You can put the Capfile and config/deploy.rb and so on in a different repo, or its own repo, or no repo or whatever.

One of the really infuriating things about Capistrano is that it’s designed to allow you to do that. See the bottom of this post for a quick workaround, or just keep reading.

A few weeks ago, I was hacking away on prototype software for my new class. I was doing that horrible thing where you make a few changes, hit “rebuild” and wait for five minutes to find out if you fixed the problem. And I realized something surprisingly awesome about configuring servers.

Deployment turned into high-end development while we weren’t looking.

The best tools for configuring your server, Chef and Puppet, now describe themselves in terms of idempotence and declarative programming — they’re using the same concepts as Big Data tools, functional languages and other theory-heavy development.

And those “best tools” aren’t in a lab or a research paper somewhere. Silicon Valley already uses them and the rest of the world will soon. Puppet and Chef are extremely common – my last four years of workplaces all used them. These tools just work better than the provisioning tools before them.

Like most “best tools” you don’t know much about, they’re a bit young and raw. “Cutting edge”, you might say. “Bleeding edge” wouldn’t be far off either. They’re clearly still growing new features — and even whole new areas of functionality.

Welcome to the new world where “deployment” is a new, interesting, involved, painful kind of development. Just like web development was fifteen years ago, and Big Data was five years ago (or now, depending who you ask.)

These days deployment and server configuration tools get bundlers, deploy-specific test suites, and even linters, not unlike how JavaScript grew JSLint to get you to use just the good parts.

It’s easy to find posts about how to set up a Rails server manually. There are a ton of them out there.

It’s also easy to put off setting up Chef until later on. After all, how often are you going to set up a server? Do it manually, then automate when you need to, right? That’s the tradeoff.

Why would you use Chef before you had to?

That’s a good question. Let’s talk about that.

Chef and Vagrant for Test Servers

If you use Vagrant you can easily put together a test server. Unfortunately, if you just type a bunch of commands into your Vagrant server, you’re always at the mercy of the VM going away.

Or you can use Chef. And then you can always get a clean new VM matching your server pretty well.

With a test server, you can answer questions like, “will this work if I type it on the production server?” And you can do it without crashing production. So that’s kind of cool.