Do your co-workers snicker at your sentence-length shell aliases? I’m here to tell you it’s okay because my aliases border on the Dostoyevskian, too.
Some commands you do a thousand times a day. They deserve super-short aliases:
alias be="bundle exec"
alias s="bundle exec rspec"
alias cuc="bundle exec cucumber"
Like h() or t() in Rails, the more often you invoke a command, the more acceptable it becomes to have a short, cryptic alias.
However, there’s a class of commands I find myself running about 1-20 times a day: interacting with our staging and production environments on Heroku:
# Heroku staging
alias staging='heroku run console --remote staging'
alias staging-process='watch heroku ps --remote staging'
alias staging-releases='heroku releases --remote staging'
alias staging-tail='heroku logs --tail --remote staging'
# Heroku production
alias production='heroku run console --remote production'
alias production-process='watch bundle exec heroku ps --remote production'
alias production-releases='heroku releases --remote production'
alias production-tail='heroku logs --tail --remote production'
# Heroku databases
alias db-pull-staging='heroku db:pull --remote staging --confirm `basename $PWD`-staging'
alias db-pull-production='heroku db:pull --remote production --confirm `basename $PWD`-production'
alias db-copy-production-to-staging='heroku pgbackups:restore DATABASE `heroku pgbackups:url --remote production` --remote staging --confirm `basename $PWD`-staging'
alias db-backup-production='heroku pgbackups:capture --remote production'
alias db-backups='heroku pgbackups --remote production'
Here’s where Neckbeard next to you silently pities your Fisher-Price programming style. What self-respecting programmer would type all that?!
Well, through the magic of autocompletion, you never type more than a few characters for each command. They might look goofy, but they’re memorable.
If you’d like these aliases and other goodies, they’re packaged up in our dotfiles.
Then, the next time you feel your pair programming partner smirking over your shoulder, just tell ‘em: “I learned to alias shell commands with Hooked on Phonics!”
I’ve been speaking about and teaching people vim for several years now, and I’ve noticed a surprising pattern: people are literally afraid of learning the editor.
Over the years, the popular mythology around vim has become that it’s insanely difficult to learn; a task to be attempted by only those with the thickest of neck-beards. I’ve heard dozens of times from folks who are convinced it will take them months to reach proficiency.
These beliefs are false. Here’s what’s true:
Go to your shell and type vimtutor. The tutorial that’s presented is excellent and you’ll be through it in no time. Once you’re done, you’ll have the rudiments needed to get your work done. You won’t be fast yet, no; but you’ll be competent. And even after those 30 minutes, you’re going to start grasping the ideas that make vim so amazing: the brilliant design decision that is modal editing, the composability of commands, the clever mnemonic naming of commands. These will be enough to make you want to learn more.
No one ever says “I’d love to learn Street Fighter 2, but there are just so many combos!” People don’t say this because learning a game is enjoyable. You start off with just the basic kicks and punches, and those get you by. Later, you learn more advanced moves, maybe even by accident.
Learning vim is like this. At first, you do everything as simply as possible. Then you start to wonder if there are faster ways to get things done, and there are! If you chain those commands together they just work! You bump into things accidentally, or maybe you spend some time in the extensive help files. Over time, you burn a few advanced tricks into your muscle memory.
Soon, you realize there are many ways to accomplish your edits, and you strive to do them in as few keystrokes as possible. This can be incredibly satisfying, particularly to us technical-types that seem to have a higher-than-average appreciation for efficiency. It may be hard to believe that trimming one keystroke off a command will one day trigger a dopamine response, but I swear it’s true. Just ask these guys.
If you use vim all day and make an effort to use it well, you’ll be editing code faster than you did in your old editor within two weeks. A couple tips to help you on your way: keep a cheat sheet of commands you’re trying to commit to memory, find a friend that’s an experienced vim user for the many questions that you’ll have in the beginning (ask in #vim if you have no such friend), and pay attention to things you do that feel inefficient (there’s almost definitely a better way). If none of that works, reach out to me on twitter and I’ll try to help you out.
There’s a reason everyone at thoughtbot is using a 20-year-old text editor. There’s a reason I’ve flown to other countries to try to convert more vim users. There’s a reason people love this editor. Maybe you should find out why.
Good luck! And happy vimming.
It seems like everywhere I turn lately, I run into tmux.
Nick, Josh, Harold, and Goose are running their editor+shell combos inside of tmux on a daily basis. When I wanted to know more about remote pair programming with ssh, vim, and GNU screen, Stephen Caudill’s awesome article suggested tmux was superior to screen. Then, Bryan Liles recorded a tmux screencast.
I’m always down for a ride on a bandwagon, so I’m giving tmux a shot. I’ve rarely used GNU screen so this is not a comparison between two similar tools. I’m evaluating a tool many of my peers are using.
These are the questions I’ve had so far.
“[Terminal tabs]: that’s not awesome.” - Bryan Liles.
I like the idea of having one shell for my whole development environment that I fly around inside like a Tasmanian devil.
I want speed and focus.
I went with Bryan’s suggestion and downloaded iTerm 2. While I’m still on the fence about tmux, iTerm 2 is definitely an improvement and I recommend it without reservation.
Then I installed tmux, read the documentation, and fired it up.
brew install tmux
man tmux
tmux -u
In my opinion, no. Anti-aliasing and 256 colors is the state of the art here. If I wanted a beautiful-looking editor, I’d still be using Textmate. I’m willing to trade off looks for speed. I know people who are very fast in other editors. I feel my ceiling for speed is higher in vim.
Josh tells me you can make some good-looking vim schemes with Palette that will be automatically converted to 256 colors. We’ll see.
This was non-obvious to me. You enter “copy mode” using prefix+[, then use vim bindings to move up (Ctrl+b, j, k, etc.).
There’s a noticeable delay in the editor that doesn’t exist in MacVim. I haven’t figured out why yet. I suspect it might actually be iTerm 2.
Enter “copy mode” using prefix+[, use vim bindings to move, select with space, copy with enter. This will let you copy and paste within tmux.
The bigger issue is copying text from within tmux and pasting it elsewhere. The very latest Homebrew formula has a patch to fix a pboard problem with copying in Mac OS X. It mostly works.
Most common amongst thoughtbot folks and blog posts is to make tmux act more like vim and GNU screen.
# act like vim
setw -g mode-keys vi
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
bind-key -r C-h select-window -t :-
bind-key -r C-l select-window -t :+
# act like GNU screen
unbind C-b
set -g prefix C-a
# look good
set -g default-terminal "screen-256color"
One day I might work on Hoptoad. Another day, a client project. I’d like to name my tmux sessions so I can leave one, drop into another, and go back to the original with all my state maintained (files still open in my editor, console/logs I want open, etc.).
tmux new -s hoptoad
# hack, leave, do something else
tmux attach -t hoptoad
This is my favorite feature so far.
This is a big selling point of tmux but I’m not convinced. Contrast the following with Command+Tab or using your mouse to move and click. In terms of speed, it’s probably six or one half dozen.
Using vim and GNU screen bindings:
Ctrl+a c # create a new window
Ctrl+a , # name the window (test, vim, console, log, etc.)
Ctrl+a " # split pane horizontally
Ctrl+a % # split pane vertically
Ctrl+a j (or k) # move up or down a pane
Ctrl+a h (or l) # move left or right a pane
Ctrl+a x # kill a pane or window
I believe in the philosophy of setting my mouse free but the reality is takes time for muscle memory to make this fast and the savings might not really be significant.
I’ve had a love-hate relationship with tmux in my first week using it, but the brief moments of flow I’ve experienced so far are enough to keep trying it.
Give tmux a shot and if you have any other tips, I’d love to hear them.
