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!
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: /dev/null.
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 2) into STDOUT (or 1, which, in turn, gets redirected to /dev/null). The ampersand in there is both magic and necessary: it says to redirect STDERR into STDOUT, not a literal file named 1.
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 jobs.
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 jobs:
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.
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 &
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.
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 it.
bg takes a suspended process and resumes it in the background, much like fg takes a suspended process and resumes it in the foreground.
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.
https://web.archive.org/web/20131029105409/http://blog.veez.us/