I spent a long week grappling with text encoding. Please enjoy the fruit of my labors:
Git bisect is like CPR or a fire extinguisher: You shouldn’t need it very often, but when you, it might just save a life.
In case you are not familiar with its splendor, git bisect is a tool for pinpointing the commit that caused a change. Usually, the change you’re interested in is the introduction of a bug. Bisect is handy when, for instance, you discover a regression and you don’t know what caused it or exactly how long it’s been around. Bisect isolates the offending commit with logarithmic efficiency. It accomplishes this by performing a binary search of the commits on your branch, dividing and conquering until only one commit remains.
Checking out the last branch you were on is as simple as
git checkout -.
1 2 3 4 5 6
I recently submitted my first (tiny!) patch to an open source project. It’s something I’d wanted to do for a long time, but couldn’t figure out how to initiate. Here are some things that surprised me about the process.
1. Most of the work is not coding.
This, as I understand it, is the lifecycle of a garden-variety open source contribution:
- Find a problem.
- Muster your courage.
- Describe the problem to the project owners in excruciating detail.
- Convince them it’s a problem worth solving.
- Fork the app and get it up and running locally.
- Solve the problem (write production code and tests).
- Document the solution (docs, commit messages, changelogs).
- Propose, explain, and defend your solution (pull request).
- Iterate on your solution and its documentation.
There are many approaches to responding to failed requests in Rails. Here I offer the way I currently favor setting things up. I’m hoping that this might start a conversation about best practices; I’m sure I could do better!
The default way Rails handles requests to which your application does not have a contentful response is to serve up static HTML documents stored in the public directory.
In particular, 500 (server error) and 404 (not found) responses result in the application’s rendering
How do you quickly check what path a certain route helper maps to?
One method I use a lot is to grep
So, let’s say I’m looking for a route that has to do with comment approval.
In that case, I might run
rake routes | grep approve.
And there’s my answer:
There’s one problem with this, though: It’s slooooow.
There are some nice gems out there to help you create and manage human-readable slugs in Rails. However, our requirements at Food52 were simple enough—and different enough from the standard case—that I thought I’d have a go at building a slugging system from scratch.
As an example of the desired behavior, given that we want to use the attribute
name to generate slugs for users, and given that my user id is 784 and my name is “Michael Hoffman”, the slug for my user page should be:
(We leave the id in because we like it there!
It makes debugging easier and it allows us to use Active Record
find to look up objects from params.)
Furthermore, we want our slugs to adapt gracefully to changing circumstances. So, if my name changes, the slug should do…something smart.
Getting a little more abstract, our requirements are as follows:
If you’re using git properly and collaborating on a project, chances are you find yourself changing branches often. This can be quite disorienting. You deploy from the master branch, then get back to that bug fix you were about to work except for—whoops!—now you commited that fix to master and have to back away slowly. Confusions like this one can easily be avoided by putting you branch name front-and-center: at the end of your bash prompt. Here’s how.
I’ve been working on a Rails app that contains lots of mailers with hard-coded recipients. For instance, here’s a mailer that we use to notify folks when someone asks an urgent question on our hotline:
1 2 3 4 5 6 7 8 9 10 11 12 13
The email address “firstname.lastname@example.org” generates emails to many people. We handle membership in Google apps.
Left to its own devices, this mailer will trigger an email to that list of people every time you hit the controller action that calls for it to be delivered.
That’s bad news if you’re just testing out the action in your development environment. You have a group of people who are getting annoying emails for no reason, and you may not even be getting the emails yourself!
While working on a longer (forthcoming) post, I wrote a little benchmarking utility that I want to share. Here it is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15