Single Session Development
Posted March 06, 2013 02:31 By Veezus Kreist (http://blog.veez.us/)
I've always been a pretty austere guy. I'd rather have less things than more: every time I move I throw out half of what I have. I'm not big into customization, either; if there's a non-ridiculous default, that's what I'm using.
That ethos extends into my work. I use the default Terminal.app on my MacBook, with the built-in Pro theme. I use exactly 12 vim plugins, including my favorite color scheme. My dot files amount to only 300-some lines, including vim options, bash options, git options, and comments.
That's the background for this post on single-session development, the way I've been developing lately. When I say session, I mean shell session. I mean, log into one shell on my laptop, maximize it, and run everything in that one session: no tabs, no
screen, and certainly no
tmux. Bernerd Schaefer started me down this path in his Laptop-Driven Development; that post has been hanging out in the back of my head for a couple of years.
The goal of this post is to make you unafraid to chuck your tabs, toss your
screen, and murder your
tmux while it sleeps. To do so, there are only four commands you'll have to remember:
fg Take a backgrounded or suspended process and bring it to the foreground
jobs List all backgrounded or suspended processes attached to this session
Ctrl+z (suspend) Suspend the currently running process and take me back to the shell
bg Take a suspended process and resume it in the background
And that's it; those are the only commands you'll need to remember. Now, what's it like to develop your current application in just one session? Let's find out!
Let's jump into our terminal and navigate to our current project directory. Once there, let's open up our editor, since that's arguably the most important of all the things we'll run in our session.
Say we've made some changes to this file, and we want to run a test. We could run it from right inside vim, but it's better from the command line, right? Hit
Ctrl+z to suspend vim and run our test.
Now it's time to get back into that editor. Type in
fg and hit enter, and you'll be right back in your vim session!
Mixing in Our Rails Server
It's time to see how our changes look on the server, so let's start one up. Go ahead and suspend vim again, and then we'll start up our rails server with
rails s >/dev/null 2>&1 &.
Let's parse this command. First,
rail s is the process we want to start in the background.
Next, we're asking the system to redirect
> the output of
rails s into the void:
But that's not all we've got to worry about. Most programs also output to
STDERR, and the
> redirection mechanism only catches
STDOUT. That's why we add
2>&1, which redirects
STDERR (also known as
1, which, in turn, gets redirected to
/dev/null). The ampersand in there is both magic and necessary: it says to redirect
STDOUT, not a literal file named
Lastly, we ask that our program be put directly into a background process, by ending the command with an
Still running with rails 2 (like so many scissors)? You can
script/server -d > /dev/null 2>&1, but be aware that the daemonized process won't be attached to your session, and won't appear in
So now we've got a rails server running somewhere in the background, right?
But how do we find out where that process is in our session? We can find it by typing in
There it is, right there! You can see that it's job number two for our session, and like a champ, it's Running right along.
Other Persistent Background Processes
You can background nearly any process with the same command modifiers as the rails server. Resque workers are probably the next most common process for me to background:
QUEUE=* rake environment resque:work >/dev/null 2>&1 &
Trading Suspensions With Your Other Favorite Interactive Process
Ready to get a little more advanced? In addition to running servers and tests and vim in the same session, why not keep your console hanging around, too? It's just as easy as keeping your vim around.
Let's suspend our vim session and start up a rails console.
We can suspend the console with
Ctrl+z, and we're back to the terminal. You can see we've got our server chugging along, but now we've got two suspended processes:
If we try to
fg again, all we get is the console.
Not to worry! There are two solutions to this problem. We could specify the stopped job number (
fg 1), or we could
fg - to go to the last-used suspended process after this one. The dash here indicates that we want to foreground the previous process, and can be used to alternate between two processes.
Foregrounding a Backgrounded Process
You'll do it sooner or later; we all do. You'll be happily chugging along and you'll accidentally foreground your rails server. Well, now what do we do?
No worry, just suspend it and then
bg takes a suspended process and resumes it in the background, much like
fg takes a suspended process and resumes it in the foreground.
Use Your UNIX Like a Big Boy or Girl
That's the gist of the process I've been using for development lately. I hope you've taken something away from this post and that you'll use it in your own process; either way, it's fun to explore the power of the tools that lay under the surface above which we normally work.