5 useful tips for a better commit message

You’re already writing decent commit messages. Let’s see if we can level you up to awesome. Other developers, especially you-in-two-weeks and you-from-next-year, will thank you for your forethought and verbosity when they run git blame to see why that conditional is there.

1. The first line should always be 50 characters or less and that it should be followed by a blank line. Vim ships with syntax, indent, and filetype plugins for Git commits which can help here.

2. Add this line to your .vimrc to add spell checking and automatic wrapping at the recommended 72 columns to you commit messages.

   autocmd Filetype gitcommit setlocal spell textwidth=72

3. Never use the -m <msg> / --message=<msg> flag to git commit.

   It gives you a poor mindset right off the bat as you will feel that you have to fit your commit message into the terminal command, and makes the commit feel more like a one-off argument than a page in history:

   git commit -m "Fix login bug"

   A more useful commit message might be:

   Redirect user to the requested page after login
   
   https://trello.com/path/to/relevant/card
   
   Users were being redirected to the home page after login, which is less
   useful than redirecting to the page they had originally requested before
   being redirected to the login form.
   
   * Store requested path in a session variable
   * Redirect to the stored location after successfully logging in the user
   

4. Answer the following questions:

   1. Why is this change necessary?

      This question tells reviewers of your pull request what to expect in the commit, allowing them to more easily identify and point out unrelated changes.

   2. How does it address the issue?

      Describe, at a high level, what was done to affect change. “Introduce a red/black tree to increase search speed” or
      “Remove <troublesome gem X>, which was causing <specific description of issue introduced by gem>” are good examples.

      If your change is obvious, you may be able to omit addressing this question.

   3. What side effects does this change have?

      This is the most important question to answer, as it can point out problems where you are making too many changes in one commit or branch. One or two bullet points for related changes may be okay, but five or six are likely indicators of a commit that is doing too many things.

      Your team should have guidelines and rules-of-thumb for how much can be done in a single commit/branch.

5. Consider making including a link to the issue/story/card in the commit message a standard for your project. Full urls are more useful than issue numbers, as they are more permanent and avoid confusion over which issue tracker it references.

   This is generally done as the first paragraph after the summary, on line 3.

Having a story in your git log will make a huge difference in how you and others perceive your project. By taking great care in commit messages, as you do in your code, you will help to increase overall quality.

Special thanks to Tim Pope, whose Note About Git Commit Messages literally sets the standard for a good commit message.

Additional thanks to the creator of Git and a real stickler for a good commit message, Linus Torvalds.

Better commit messages

Caleb Thompson:

Answer the following questions:

• Why is this change necessary?
• How does it address the issue?
• What side effects does this change have?

Redis partial word match -- you (auto)complete me

We can use partial word matching to rapidly search strings of text such as Names, Cities, States, etc.

We can do this by indexing strings into Redis sets based on partial matches of the string. The indexing process takes a string and breaks it into left-bound substrings which are placed into the appropriate Redis sets.

Partial word matching movie titles

In this example we’ll enable partial word matching queries of movie titles.

The movie titles will be stored in plain text. The keys are simple key-value pairs that are stored with the key structure movies:id, where id is incremented:

$ redis-cli get movies:1
"Bad Santa"
$ redis-cli get movies:2
"Batman"
$ redis-cli get movies:3
"Bad Company"

The movie Batman would be decomposed into the following sets (assuming that the indexing started at two characters):

ba
bat
batm
batma
batman

We’ll index the movie titles into sets based on partial match of their titles. To prevent any key collisions in Redis we’ll create keys with the following structue index:abc:movies.

View the indexed ids using Redis smembers command:

$ redis-cli smembers index:ba:movies
1) "1"
2) "2"
3) "3"

$ redis-cli smembers index:bat:movies
1) "2"

Note: The keys for the movie titles have been parameterized (lowercase and spaces replaced with dashes).

We’ll use a Ruby class Autocomplete to wrap the Redis calls:

# autocomplete.rb
require 'redis'

class Autocomplete
  def initialize(partial_word)
    @partial_word = partial_word
  end

  def movies
    redis.sort "index:#{partial_word}:movies", by: :nosort, get: 'movies:*'
  end

  private

  def redis
    Redis.current
  end

  attr_reader :partial_word
end

movies = Autocomplete.new('bat').movies

We’ll use the sort command with the by: :nosort parameter to query the partial word match index and return the matched movie names.

Written by Harlow Ward

Related Reading

Redis Set Intersection - Using sets to filter data

Redis Pub/Sub…how does it work?

Episode 45: Tiny Robots Cuddling with other Tiny Robots

Episode 45: Tiny Robots Cuddling with other Tiny Robots:

In this week’s podcast we try something a little different. Joe Ferris, Matt Jankowski, Ben Orenstein, and Chad Pytel get together and have a little fun, in what we’re calling “Tiny Robots cuddling with other Tiny Robots”.

We’d love to get your thoughts on this special format, tweet us @thoughtbot or email learn@thoughtbot.com.

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download

Tickets in your Support, Support in your Tickets

It’s probably not a huge surprise that we use Lighthouse integration with our own Tender support (and Lighthouse support too). Using both applications lets our support team escalate issues to our developers that might need a little more time and attention. It’s particularly awesome because support staff can set the discussion aside but as soon as the Lighthouse ticket is closed the Tender discussion will be bumped back to pending dashboard.

Integration can be an incredible enhancement to your support workflow and is so simple, you’ll be up and running in no time. Check out the knowledge base article to get started - https://help.tenderapp.com/kb/general-use/how-do-i-integrate-my-tender-with-lighthouse. We also offer integration with Github Issues.

*Tender customers who are subscribed to a paid Lighthouse plan receive 15% off of their Tender account.  So what are you waiting for!? Sign up today and make sure to contact us at billing@tenderapp.com so we know to apply that discount for you.

Let Nunes Do It

In a moment of either genius or delirium I decided to name my newest project after myself. Why? Well, here is the story whether you want to know or not.

Why Nunes?

Naming is always the hardest part of a project. Originally, it was named Railsd. The idea of the gem is automatically subscribe to all of the valuable Rails instrumentation events and send them to statsd in a sane way, thus Railsd was born.

After working on it a bit, I realized that the project was just an easy way to send Rails instrumentation events to any service that supports counters and timers. With a few tweaks, I made Railsd support InstrumentalApp, a favorite service of mine, in addition to Statsd.

Thus came the dilemma. No longer did the (already terrible) name Railsd make sense. As I sat and thought about what to name it, I remembered joking one time about naming a project after myself, so that every time anyone used it they had no choice but to think about me. Thus Nunes was born.

Lest you think that I just wanted to name it Nunes only so that you think of me, here is a bit more detail. Personally, I attempt to instrument everything I can. Be it code, the steps I take, or the calories I consume, I want to know what is going on. I have also noticed that which is automatically instrumented is the easiest to instrument.

I love tracking data so deeply that I want to instrument your code. Really, I do. I want to clone your repo, inject a whole bunch of instrumentation and deploy it to production, so you can know exactly what is going on. I want to sit over your shoulder and look at the graphs with you. Ooooooh, aren’t those some pretty graphs!

But I don’t work for you, or with you, so that would be weird.

Instead, I give you Nunes. I give you Nunes as a reminder that I want to instrument everything and you should too. I give you Nunes so that instrumenting is so easy that you will feel foolish not using it, at least a start. Go ahead, the first metric is free! Yep, I want you to have that first hit and get addicted, like me.

Using Nunes

I love instrumenting things. Nunes loves instrumenting things. To get started, just add Nunes to your gemfile:

# be sure to think of me when you do :)
gem "nunes"

Once you have nunes in your bundle (be sure to think of bundling me up with a big hug), you just need to tell nunes to subscribe to all the fancy events and provide him with somewhere to send all the glorious metrics:

# yep, think of me here too
require 'nunes'

# for statsd
statsd = Statsd.new(...)
Nunes.subscribe(statsd) # ooh, ooh, think of me!

# for instrumental
I = Instrument::Agent.new(...)
Nunes.subscribe(I) # one moooore tiiiime!

With just those couple of lines, you get a whole lot of goodness. Out of the box, Nunes will subscribe to the following Rails instrumentation events:

• process_action.action_controller
• render_template.action_view
• render_partial.action_view
• deliver.action_mailer
• receive.action_mailer
• sql.active_record
• cache_read.active_support
• cache_generate.active_support
• cache_fetch_hit.active_support
• cache_write.active_support
• cache_delete.active_support
• cache_exist?.active_support

Thanks to all the wonderful information those events provide, you will instantly get some of these counter metrics:

• action_controller.status.200
• action_controller.format.html
• action_controller.exception.RuntimeError – where RuntimeError is the class of any exceptions that occur while processing a controller’s action.
• active_support.cache_hit
• active_support.cache_miss

And these timer metrics:

• action_controller.runtime
• action_controller.view_runtime
• action_controller.db_runtime
• action_controller.posts.index.runtime – where posts is the controller and index is the action
• action_view.app.views.posts.index.html.erb – where app.views.posts.index.html.erb is the path of the view file
• action_view.app.views.posts._post.html.erb – I can even do partials! woot woot!
• action_mailer.deliver.post_mailer – where post_mailer is the name of the mailer
• action_mailer.receive.post_mailer – where post_mailer is the name of the mailer
• active_record.sql
• active_record.sql.select – also supported are insert, update, delete, transaction_begin and transaction_commit
• active_support.cache_read
• active_support.cache_generate
• active_support.cache_fetch
• active_support.cache_fetch_hit
• active_support.cache_write
• active_support.cache_delete
• active_support.cache_exist

But Wait, There is More!

In addition to doing all that work for you out of the box, Nunes will also help you wrap your own code with instrumentation. I know, I know, sounds too good to be true.

class User < ActiveRecord::Base
  extend Nunes::Instrumentable # OH HAI IT IS ME, NUNES

  # wrap save and instrument the timing of it
  instrument_method_time :save
end

This will instrument the timing of the User instance method save. What that means is when you do this:

# the nerve of me to name a user nunes
user = User.new(name: "NUNES!")
user.save

An event named instrument_method_time.nunes will be generated, which in turn is subscribed to and sent to whatever you used to send instrumentation to (statsd, instrumental, etc.). The metric name will default to “class.method”. For the example above, the metric name would be user.save. No fear, you can customize this.

class User < ActiveRecord::Base
  extend Nunes::Instrumentable # never

  # wrap save and instrument the timing of it
  instrument_method_time :save, 'crazy_town.save'
end

Passing a string as the second argument sets the name of the metric. You can also customize the name using a Hash as the second argument.

class User < ActiveRecord::Base
  extend Nunes::Instrumentable # gonna

  # wrap save and instrument the timing of it
  instrument_method_time :save, name: 'crazy_town.save'
end

In addition to name, you can also pass a payload that will get sent along with the generated event.

class User < ActiveRecord::Base
  extend Nunes::Instrumentable # give nunes up

  # wrap save and instrument the timing of it
  instrument_method_time :save, payload: {pay: "loading"}
end

If you subscribe to the event on your own, say to log some things, you’ll get a key named :pay with a value of "loading" in the event’s payload. Pretty neat, eh?

Conclusion

I hope you find Nunes useful and that each time you use it, you think of me and how much I want to instrument your code for you, but am not able to. Go forth and instrument!

P.S. If you have ideas for Nunes, create an issue and start some chatter. Let’s make Nunes even better!

Vim Splits - Move Faster and More Naturally

Most of us are Vim users and have tweaked our favorite editor for speed and convenience. See thoughtbot’s dotfiles.

One of my favorite tools is the window split. Here is a quick splits overview and configurations to use them more effectively.

The basics

Create a vertical split using :vsp and horizontal with :sp.

By default, they duplicate the current buffer. This command also takes a filename:

:vsp ~/.vimrc

You can specify the new split height by prefixing with a number:

:10sp ~/.zshrc

Close the split like you would close vim:

:q

Easier split navigations

We can use different key mappings for easy navigation between splits to save a keystroke. So instead of ctrl-w then j, it’s just ctrl-j:

nnoremap <C-J> <C-W><C-J>
nnoremap <C-K> <C-W><C-K>
nnoremap <C-L> <C-W><C-L>
nnoremap <C-H> <C-W><C-H>

More natural split opening

Open new split panes to right and bottom, which feels more natural than Vim’s default:

set splitbelow
set splitright

Resizing splits

Vim’s defaults are useful for changing split shapes:

"Max out the height of the current split
ctrl + w _

"Max out the width of the current split
ctrl + w |

"Normalize all split sizes, which is very handy when resizing terminal
ctrl + w =

More split manipulation

"Swap top/bottom or left/right split
Ctrl+W R

"Break out current window into a new tabview
Ctrl+W T

"Close every window in the current tabview but the current one
Ctrl+W o

:help!

As with everything in Vim, for more information, check the well-written helpfiles. In Vim, :help splits.

Vim Meetups

Come talk splits at a Vim Enthusiast Meetup near you:

• Stockholm Vim Meetup
• Boston Vim Meetup
• San Francisco’s VimSF Google Group

Photo credit: Andrew Ressa on Flickr

Written by Adarsh Pandit.

Online presentation with thoughtbot and Heroku

Adarsh, Alex, and I are giving a free online presentation with Abe from Heroku about how their platform fits into our process. Over 1,400 people have registered so far! The details:

• Tomorrow, April 17
• Once at 7:00am PST (2:00pm GMT / 7:30pm IST)
• A second time at 10:00am PST (5:00pm GMT / 10:30pm IST)

RSVP here.

We will be live coding(!), making a single change to a live web application hosted on Heroku within the context of a common process for us:

• Campfire for real-time communication and alerts.
• Trello for managing the task and tracking discussion.
• Our git protocol.
• GitHub pull request-based code review.
• Shortcuts from thoughtbot/dotfiles.
• Staging and production environments on Heroku.

We will also show a few other goodies:

• Heroku config variables.
• Heroku addons.
• Heroku 2x dynos.
• Using Apache Bench for simple load and memory tests.
• Dynos handling about ~1,000 requests per minute for a static site.
• Unicorn, Sinatra, and Ruby 2.0’s Copy-On-Write garbage collection.
• Using log2viz for performance and memory visibility.

We will share an open source web application and a read-only Trello board during the presentation. There will be a question-and-answer session at the end.

Hope to see you online! RSVP here.

A Manageable Multi-Database Redis Development Setup

Redis has quickly become the companion to Postgres in most of our Rails apps. This creates a problem for development, since a Redis server only uses numbered databases. Thats 1-16 by default. Hardly memorable, unless your app is called "5", in which case you're golden. On a single machine alone, it's easy enough to lose track of them once you have a few apps connecting to redis for both development and testing databases. Once you have multiple developers and designers working on an app, it's even worse. The solution I've found is to run a separate Redis server for each app, listening via a named socket.

This is easy to set up. First, take your standard Redis config file (mine is /usr/local/etc/redis.conf, thanks to Homebrew) and copy it to redis-common.conf. Edit this new file and change its port to port 0, ensuring it doesn't listen over TCP.

Then, create a separate config file for each app you want to use Redis. I call them /usr/local/etc/redis-server-<app_name>.conf. These files are nice and short:

include /usr/local/etc/redis-common.conf
pidfile /usr/local/var/run/redis-app_name.pid
unixsocket /tmp/redis-app_name.sock
dbfilename dump-app_name.rdb
vm-swap-file /tmp/redis-app_name.swap

These per-app config files are enough to run an entire Redis instance: they load the common config, followed by the app-specific paths that allow the server to run in isolation from other apps.

You can then start the Redis server like this:

redis-server /usr/local/etc/redis-server-app_name.conf

Currently, I have 5 different app-specific configs like this. This makes bringing Redis up and down a bit of a chore. I simplified the process with a couple of shell functions:

function redstart {
  redstop
  for file in `ls /usr/local/etc/redis-server-*.conf`; do
    redis-server $file
  done
}

function redstop {
  for file in `ls /usr/local/etc/redis-server-*.conf`; do
    pidfile=`grep pidfile $file | awk '{print $2}'`
    if [ -f $pidfile ]; then
      kill `cat $pidfile`
    fi
  done
}

Easy. Redis up and Redis down in one hit.

There's another benefit to running Redis like this: loading production data onto your development machine. Most cloud-hosted Redis providers give you backups in Redis' .rdb format, which is the data file for the whole server. You can't load this for a single numbered database. Splitting your local Redis servers by app means you can just replace the file specified in dbfilename with this backup file and now your app has the latest production data without interfering with any other app's Redis data.

Bonus: Redis config management functions

Want an easier way to build and manage those per-app config files? Here you go:

function redls {
  ls /usr/local/etc/redis-server-*.conf
}

function redgen {
  if [ -z "$1" ]; then
    echo "You need to specify an app name, eg. redgen decafsucks"
    return 1
  fi

  app=$1
  config="/usr/local/etc/redis-server-${app}.conf"

  redstop

  echo "include /usr/local/etc/redis-common.conf"     > $config
  echo "pidfile /usr/local/var/run/redis-${app}.pid"  >> $config
  echo "unixsocket /tmp/redis-${app}.sock"            >> $config
  echo "dbfilename dump-${app}.rdb"                   >> $config
  echo "vm-swap-file /tmp/redis-${app}.swap"          >> $config

  redstart
}

function redrm {
  if [ -z "$1" ]; then
    echo "You need to specify an app name, eg. redrm decafsucks"
    return 1
  fi

  redstop
  rm -f "/usr/local/etc/redis-server-${app}.conf"
  redstart
}

Bonus: Rails redis initializer

Here is the do-it-all Redis initializer I use in my Rails apps:

require "redis"

if (redis_url = ENV["REDIS_URL"] || ENV["REDISTOGO_URL"]).present?
  uri = URI.parse(redis_url)
  REDIS = Redis.new(
    host: uri.host,
    port: uri.port,
    password: uri.password)
else
  redis_socket = "/tmp/redis-myappname.sock"
  if File.exist?(redis_socket)
    REDIS = Redis.new(
      path: redis_socket,
      db: !Rails.env.test? ? 0 : 1)
  else
    REDIS = Redis.new(
      host: "localhost",
      port: 6379,
      db: !Rails.env.test? ? 0 : 1)
  end
end

This looks for Redis URL ENV vars first, which are used on Heroku to specify the Redis location. If they're not found, we must be in development, so it looks for the named Redis socket for the app (change redis_socket to make it your own). If that's there, it uses database 0 for Rails development and production modes, and database 1 for test. Finally, we don't want to fail completely if someone hasn't yet starting using the named redis sockets, so we fall back to the standard Redis TCP port.

Permalink

Episode 44: I feel the opposite of burnt out

Episode 44: I feel the opposite of burnt out:

In this week’s podcast, Ben Orenstein is joined by Chad Fowler, author, speaker, and CTO of 6wunderkinder. Ben and Chad discuss Chad’s recent move to Berlin and 6wunderkinder, what a CTO does, getting back to coding, the early Ruby community, who Chad wants to hire, predicting success of new hires, and what makes a truly good developer, favorite interview questions, how Chad’s interviewing process has changed over time, how age and experience can change your perspective, how Chad built a great team, and what he might write about in the future. They also discuss Chad’s new tattoo, his regrets, meditation, therapy, gaining control over your mind, and much, much more.

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download