Code Worrier

Teaching myself to RTFM

Git Bisect: Your Friend in Times of Need

| Comments

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.

How to Checkout the Last Git Branch You Were On

| Comments

Checking out the last branch you were on is as simple as git checkout -.

1
2
3
4
5
6
11:13:14-hoffm~/src/food52 (develop)$ git checkout master
Switched to branch 'master'
11:13:21-hoffm~/src/food52 (master)$ git checkout -
Switched to branch 'develop'
11:13:23-hoffm~/src/food52 (develop)$ git checkout -
Switched to branch 'master'

Boom!

3 Surprises From My First Open Source Contribution

| Comments

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.

404 and 500 Error Pages in Rails

| Comments

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 500.html and 404.html, respectively.

Try Out Routes in the Rails Console

| Comments

How do you quickly check what path a certain route helper maps to?

One method I use a lot is to grep rake routes. 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:

1
approve_comment POST  /comments/:id/approve(.:format)  {:action=>"approve", :controller=>"comments"}

There’s one problem with this, though: It’s slooooow.

Custom Slugs in Rails Without Gems

| Comments

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.

The Problem

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:

"784-michael-hoffman"

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

Put Your Git Branch in Your Bash Prompt

| Comments

Lots of folks were interested in getting git autocomplete going in bash, so I thought I’d offer another useful git/bash tip. This one was suggested by Stephan in the comments of that earlier post.

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.

How Do You Prevent ActionMailer From Spamming People in Development?

| Comments

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:

hotline_mailer.rb
1
2
3
4
5
6
7
8
9
10
11
12
13
class HotlineMailer < ActionMailer::Base

  default :from => "notifications@mywebapp.com"

  def notify_urgent_question(question)
    @question = question
    send( :to => "urgent@mywebapp.com",
          :subject => "Urgent: #{question.title}")
  end

  # Other mailer methods...

end

The email address “urgent@mywebapp.com” 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!