Codefol.io

(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.

deployment

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...

deployment

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.

An ambitious young programmer asked me recently, “how do I balance learning new specialties with producing good results?” It’s a great question, and a hard balancing act.

It took me too many years to learn this. I hope the rest of you learn it much faster than I did.

A Tale I Will Thee Tell

If you find a project that your management considers highly productive that uses a new-to-you technology, then you can learn and be productive. That’s a best-case scenario, but it happens semi-often.

Watch for it, just in case.

As you’d expect, those opportunities are often reserved for the programmers who play the politics game best — if you do well, many of those will mysteriously open up to you.

But let’s say you can’t get that, not yet.

Your Goal: Be Like Old Google

Next best is to have a perceived-as-high-value activity that doesn’t take all of your time. This is much, much easier than it sounds. If you can do that, you can declare your own old-Google-style 20% time, especially if you don’t declare it out loud. The keys to being perceived as highly productive are, roughly:

1) Be sure to ask your managers, and occasionally their managers, what the company values. Patrick McKenzie’s article talks about doing this during your interview — and yes, do that, but don’t stop doing it once you work there.

Also, ask business-critical groups (e.g. Sales, Marketing) and politically powerful groups (e.g. Product, Finance) what they get from Engineering. You ask because they remember the stuff they value and forget the stuff they don’t. So their answers will not be a good match for what Engineering thinks that Engineering gives them. Their answer tells you what you want to be working on. Those are projects they consider valuable and noteworthy. If you do a good job on projects like that, they will remember you personally. At least, they will if you do steps 3 and 4 correctly.

career business

When I create and promote fun content, I get more subscribers, more goodwill and more engagement.

When I ask my audience to buy things, or even sit through being asked to buy things, I lose those things, by and large.

So this product trek is kind of an alternation — “power up” my audience by giving...

entrepreneur

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

• Vagrant
• VirtualBox
• Chef
• Librarian-Chef
• Capistrano

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?

deployment

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.

business

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.

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 (note: pricing is out of date), 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.

For a powerful server you’re actually using, it’s easy to pay $250/mo for what Amazon might have delivered for $100/mo or Digital Ocean for $80/mo.

deployment

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...

ruby

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”...

ruby rubycommunity