Remember that problem I had writing migration code where the whole site went down? Turns out I could have fixed that in advance by just following best practices for migrations.
There are several libraries meant to help you follow migration best practices. Two of them are “Good Migrations” and “Strong...
I might be a touch late, writing my 2015 end-of-year post in February.
It’s been a pretty good year in some ways, not a great one in others. First off, let’s hit some numbers:
These are net of refunds, Stripe and Gumroad fees and so on.
That’s pretty decent Rebuilding Rails revenue, very much in line with the last two years. I also finally made the switch to Gumroad, so I’m not doing my own invoicing any more. The remaining chunk of time I spend on it week-to-week is debugging problems people hit with the software, and that shouldn’t go down much – the whole point is helping new people learn Rails. If they’re doing it right, they’re debugging. And talking programming with me isn’t something I can foist off on a remote assistant.
As I look into database migration dangers for (edited to add: now defunct) a book I’m working on, I find a lot of great existing stuff that I had no idea existed.
Thanks, guys!
Andrew Kane of Instacart has a bunch of wonderful guides, including one on “strong migrations” — migrations that run without downtime on MySQL and Postgres. It sums up some wonderful previous articles about downtime-free migrations on Postgres with high data volume, how to create indices without downtime on Postgres, and no-downtime migrations in general.
Some of you may remember Rails Deploy In An Hour, a Ruby deployment class I tried selling last year. More of you probably remember Ruby Mad Science, the open-source software that went with it.
I’m not selling the class any more, though I haven’t taken down Ruby Mad Science, and I don’t intend to. But it won’t be getting the maintenance it would want… now that I understand just how much that is.
I wondered, “why aren’t there more good Ruby deployment products out there?” And “why don’t people know more about the books there already are?” And as I learned more I started to wonder, “why aren’t there more Heroku competitors?” And “why did Ninefold stop supporting Rails?”
These are interesting questions. I know the answers better now, and I’m happy to share them. Perhaps they’ll help the next person fix the problem better than I did.
It turns out that programmers hate doing deployment. The programmers I’m targeting (hobbyists, early developers, small startup guys) extra-specially hate doing deployment. They just want it done and working with minimal work.
Back when I worked at On-Site, years ago, I screwed something up in my code. I discovered it when everything stopped working in production.
Oops.
By “everything” I mean “nearly every action a user could take would just hang.” So that’s not great.
But I learned something important about database migrations. And that’s nearly as good as not crashing production, right?
Right?
I’ll tell you what happened with me and crashing our servers, but first let’s talk about database migrations.
My favorite article on salary negotiation of all time talks about “fully-loaded costs” of an employee. The idea is that when figuring what it costs a company to employ an engineer (or whoever) it’s short-sighted to just take their salary and multiply by time. Patrick suggests that “a reasonable guesstimate is between 150% and 200% of their salary” and that the “extra” tends upward as salary does. Of course it depends on benefits and whatnot.
Many people think that’s complete baloney. Specifically, they tend to think that the “extra” is fixed (e.g. $30k extra,) rather than a large and increasing percent of salary.
But when you’re negotiating salary, or otherwise asking, “what does an employee’s time cost a company?” he’s right. Let me explain why.
Breaking down a giant monolithic Rails app (colloquially a “monorail”) is a very hot topic right now. I’ll give you the boring, accepted advice first: extract obvious bits by breaking apart obvious sub-apps, take nontrivial logic and extract it into /lib and/or external gems, take repetitive models...
Occasionally, you’ll see people put up a “why you should hire me” page, such as the one that got Jason Zimdars a gig at 37signals. These pages are effectively sales pages for people, though they read a little differently from a sales page for a book.
(If you don’t believe that a “hire me” page is a sales page, I recommend reading a bit more Patrick McKenzie.)
Most frequently you see pages for less-established entry-level people — people who try using a sales page because they have to, not because they want to.
And I thought, “hey, what if I tried that?” As a great fictitious man once said, “we try things. Occasionally they even work.”
So when my last company went out of business, I put a “hire me” page together. I had a little breathing room before missing a paycheck and reasonable savings. Why not try it?
When people talk about Google ruling the roost, it’s common to compare them to Microsoft. I’m an old guy, and I remember Microsoft as our overlord. So I find that comparison pretty darn funny.
But if you haven’t been doing this since, oh, call it 2005… That doesn’t necessarily mean much to you. Microsoft...
