Top Five Regrets Of The Dying

  1. I wish I’d had the courage to live a life true to myself, not the life others expected of me.
  2. I wish I didn’t work so hard.
  3. I wish I’d had the courage to express my feelings.
  4. I wish I had stayed in touch with my friends.
  5. I wish that I had let myself be happier.

— Bronnie Ware

Disclaimer: Ms Ware does not present her findings as the results of academic research.

One of my heuristics is: if an idea is obviously bad, find a cheap way to try it because if it turns out it’s not bad, then it’s really interesting. If you have a good idea that’s obviously good, somebody else has probably tried it before.

— Kent Beck in Is TDD dead?


Why rvm (or rbenv or whatever)?

Update: @dysinger has subsequently pointed out that he only uses Ruby for infrastructure. His advice (don’t use RVM or similar on servers) is great advice for infrastructure Ruby. Chalk this one up to context-specific advice put forward too generally.

In a conversation where I tried to shoot down some bad advice against the use of rvm (or similar) on servers, @LordCope asked me why I’d want rvm (or similar) on servers, instead of a 12 line shell script or operating system packages.

Why would I want to upgrade Ruby and gemsets on servers?

It’s hard to answer that question without assuming it’s being asked by someone who doesn’t write Ruby applications. If you don’t write Ruby applications, just use your operating system’s Ruby packages. Otherwise…

You develop and test one application against a specific version of Ruby and specific versions of a set of gems.

The next application you develop is tested against a different version of Ruby and different versions of a different set of gems.

Rinse, repeat. Soon, you have many applications on many servers, with different, tested Ruby and gem dependencies.

And now a Ruby security vulnerability is published. It affects some versions of Ruby but not others. The Ruby upgrade demands a rebuild of one of your gems.

Fortunately, that’s an rvm one-liner on each of my workstations, CI, staging and production, for each affected application. One commit to the .ruby-version file in the repo, and the rest is taken care of, globally.

No having to build and distribute a Debian package. No having to tell your CM system to use that Debian package on those servers. You’re done.

And this doesn’t perturb any of your other applications, whether you’ve chosen to co-host them or not, and regardless of when in their lifecycle CM is applied.

Isolation of dependencies is worth much. Just ask any Docker user. But once you have her answer, take a step back and consider that it’s valuable at many levels, and it’s an early exercise of options to lock yourself into a deployment strategy as the only way to get it.

Trying to do this with operating system packages of Ruby demands one or more of

  • loads of time,
  • an inviolable “one application per instance” rule, or
  • shit packaging.

People will argue with the last point. Ask them if they’re packaging all their gems too. If they aren’t, then give them enough time to experience the thrill of a native library update that demands a gemset rebuild and see how strongly opinionated they are then.

Hating on the way rvm and similar tools are implemented is fine. They’re almost always gross band-aids. But to suggest that you should just throw the value they offer away, in the name of myopic simplicity, is foolhardy. And it turns out the simplicity you get isn’t so simple or even easy (multiversion Debian packages for gems, anyone?)


Coping with deleted releases under unicorn

Does this unicorn.stderr.log excerpt look familiar?

INFO -- : executing ["/srv/rack/releases/20131217-083442/vendor/bundle/ruby/bin/unicorn", "-D", "-c", "/srv /rack/shared/config/unicorn.rb", {10=>#<:unixserver:fd>}] (in /srv/rack/releases/20131218-093642)
INFO -- : forked child re-executing...
/srv/rack/releases/20131217-083442/vendor/bundle/ruby/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:452:in `exec': No such file or directory - /sr v/rack/releases/20131217-083442/vendor/bundle/ruby/bin/unicorn (Errno::ENOENT)

When unicorn starts, it resolves symlinks in the path to the executable. When it re-execs as part of zero-downtime deploys, it uses this resolved path.

If your deployment strategy deletes old releases, enough deploys will eventually cause the release that contains the resolved path to unicorn, making subsequent zero-downtime deploys a NOOP.

The solution is to hard wire the unresolved path to unicorn into unicorn.rb. This is documented here.


And what if we couldn’t do that?

In a recent talk that was awesome for all sorts of other reasons, Dan North observed that, from the inside, it’s impossible to distinguish institutional thinking. He presented a very simple coping mechanism.

When a course of action seems obvious, ask

"Okay, now what if we couldn’t do it that way?"

I’ve been surprised by the power of this simple technique.

Yesterday, I was in a meeting with stakeholders where we were exploring how to deprecate support for logging into webmail through our web hosting control panel login form.

At the start of the meeting, I made a point of saying “As developers, we want to fade into the background of this conversation, so that we can hear what’s important to you.” Stakeholder thinking seemed unshackled. The room was brimming with possibility.

Ten minutes in, and we’d zeroed in on the use of a banner on the control panel login page, to announce deprecation. We’ve used announcement banners effectively before, and the call centre folks were convinced that the impact on call volumes would be minimal.The realm of possibility had collapsed to a pin prick, and the conversation was already down to the level of placement, colour and repetition of the banner.

So I got my Dan on and said, “Okay, great. So we have an idea that’s looking good, but we’ve stopped exploring. Before we carry on, let’s have a quick stab into the unknown. What if we couldn’t put a deprecation banner on the control panel login page?”

After a moment of confusion, the UI guy said we’d have to put a deprecation banner on the webmail system itself. And that opened up a can of worms, in the form of password managers and saved passwords. Suddenly, the impact on call volumes didn’t look so small, because we know that most of our customers don’t know their passwords.

Twenty minutes later, we had a solution to explore, that looks like it’s going to rock. It’s going to be great for customers, it’s going to have minimal impact on call volumes and all the unnecessary complexity it introduces can be jettisoned at the end of the deprecation phase.

For me, this was a triumph over institutional thinking. Announcement banners work. We’ve seen it before. Obviously, this is the right way to do this. No need to discuss anything else, right? Well maybe. After all, the new solution does involve an announcement banner.

But by forcing ourselves to look at the problem from an awkward angle, we surfaced some ugly uncertainty very early on, saving ourselves a little money and a lot of face. Sure, we’d have tripped over password managers eventually. But why wait?

How exciting, that such a simple question can produce so much unexpected value!

The talk in which I discovered this gem, was Dan North’s Accelerating Agile talk at NDC 2013. If you haven’t seen it yet, you’re in for a treat. Get inspired!


Communicating a change of heart

A significant source of drag in my workplace, is the team’s tendency to remain aligned with management perspectives that were abandoned by management years ago. Seriously. Years ago.

I do it myself. I’m really bad at it, actually. “If only management wouldn’t get in the way of X, I could do Y.” And then I chat to my boss about some tangentially related thing, and realize - nay, remember - that he isn’t hostile toward X at all. He changed his mind about it more than two years ago, and I remember him saying so.

And then I sit there wondering what the hell is wrong with me and my team. And then…

At RailsBridge Cape Town 2013, Karen Greaves said something to me that hit me like a ton of bricks:

Management must repeatedly communicate and demonstrate a change of heart, or the team won’t believe it.

Now I’m not absolving myself of responsibility for my own thoughts. But I felt that this was a really valuable insight. Not just for management. For anyone whose word carries weight.

If I use the power of my word to align people with my perspective, and then I change my mind, it might take equivalent (or more) power over time (work) to realign people around my new perspective.

P.S. When I told Karen that I planned to share the idea, she humbly observed that the words are her own, but that the idea is prior art. Nevertheless, they’re her words, and she introduced me to the idea, so she gets the brownie point.

  • @sheldonh: These are not the Borg you are looking for.
  • @JohanVanDyk: You just scissor fucked Star Wars and Star Strek.
What Google thinks you should be getting this week-end. Do you feel lucky, punk?

What Google thinks you should be getting this week-end. Do you feel lucky, punk?


Dig this

We have this custom in our office. Every now and then, someone will exclaim “It’s the X song!” for some value of X, while a song with appropriate lyrics is playing.

For example, Daniel Bedingfield’s I Gotta Get Thru This would almost certainly elicit an “It’s the Documentation At The End song!”. Almost certainly. If that song somehow managed to stay on long enough to reach the chorus.

Today, Bliss’s Monitor Access came on. Arguably, it’s the Refactoring song, because of the “Light that motherfucker up”. But when it occurred to me to name the song, it was in the “I know you gonna dig this” loop.

More specifically, it was in the “Dig dig dig dig” build up. So I called out “It’s the Node.js song!”. See, I’ve been punting node.js hard, and have been saying peeps will dig it. Sadly no dice, because as I said it, the track transitioned into the “this this this” bridge. So my timing was poor.

Rory’s was not. Without a moment’s hesitation, he asked “Because of this?”

JavaScript jokes. I kill me.