Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Single Session Development

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!

Getting Started

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: /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?

The jobs Command

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.

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 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.

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.

https://web.archive.org/web/20131029105409/http://blog.veez.us/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment