There are a lot of weird Unix command names. Where do they come from? One answer is: a lot of them are jokes. I don’t mean I disapprove - I mean they’re literally meant to be funny.
For instance: there’s a command called “cat”, short for “concatenate.” When you use it on a file (or several), it prints...
I’m going to tell two stories about the Ruby community. One happened this past May (2018), and another happened in 2007. Both are about the Ruby community. Both are about what we did and what we stand to lose. Both are about trolls and how we handle them.
One story is small, recent and has a happy...
Rands recently wrote a post called “Your Culture is Rotting”. The short version is that he thinks if people are nervous about HR, it’s a sign of a culture problem. I partially agree - but I think being nervous about HR is perfectly normal and should be expected. It’s the degree of nervousness. Here...
Have a horrible revelation, from an appreciator of less sugar with my caffeine.
You can buy a brick of caffeine in pure powdered form for about $30. That’s for 500g – about a pound. Several years’ supply, easily. Weightlifters use it, so it’s going to be readily available for a long time. I got mine...
Avdi recently asked in one of his wonderful SIGAVDI newsletters:
“I’m noticing that the topic of empathy is starting to be discussed more and more and developer circles. In retrospect, it’s strange that it has taken so long to come to the fore.”
Early tech companies were attempts to make something...
This isn’t really my blog post – it’s Brian Brushwood’s. But as his blog slowly, visibly decays, it makes me want to keep a copy somewhere I’m sure I can find it. So, here it is:
Hey gang,
Lately a lot of young magicians have been asking me for advice, which has caused me to remember one of the most valuable correspondences of my life: one of the most mind-blowing letters I ever received, chock-full of insights that to this very day guide my career and philosophy in both creating and performing magic.
This is a pretty long post, but with Teller’s permission, I’d like to share with you the secrets he gave me 14 years ago to starting a successful career in magic.
Lots of you loved my old post on this. Thanks! But thanks to many fine questions, especially by one guy on Twitter, it’s time for an update! And also, naturally, the same things you loved last time. I’m not heartless.
Sometimes you’re sure that’s not the right place for that piece of code, but where...
Interested in taking your Rails migration code to the next level? Welcome. You’re in the right place.
What’s that? Somebody in the back says they’re not already up on the basics? No problem. The Rails Guide on migrations is like most Rails guides – pretty darn awesome. It’ll have you adding tables, dropping columns and altering multi-column indices before you know it.
For the rest of you who know the basics, let’s learn what awesome Rails programmers already know about migrations.
Migrations can bring down a busy site in a hurry. Many things you do in a migration will lock the table you’re touching, which will block every SQL query and every Rails route that touches that table, sometimes for minutes or hours. You can’t “scale” your way out of it – you only get one database, and it’s locked for all app servers.
A question you’ll occasionally see: when do you run your migrations in production? There’s a standard answer, so let’s talk about it.
You’ll run your migrations before you deploy new code. In general, that means “every time you push code to production, you run all the migrations since the last time you pushed code to production. Do it before you replace the old code.”
Easy enough. Why?
First, because that’s the order you think about things. If you’re adding a new column to a table, you’ll want to make your code use it. If you run the migration first, that all works out nicely.
Migrations can be tricky, and it’s time-consuming to test them properly. One answer is to have other people look over your code.
In addition to the checks you can enforce with automated tools, there are a lot of things a human should look over. Let’s talk about some of the rules for code reviewing a migration that aren’t covered by the Good Migrations or Strong Migrations tools.
Small migrations are (usually) happy migrations. It can be hard to roll back migrations, especially when they modify large tables. If your database supports rolling back schema changes at all, it can still take minutes or hours to do. Even a large, hard-to-divide operation like adding a column to a two-terabyte table is happiest if it’s mostly done by itself.
