Posted by Doug
Sat, 13 Sep 2008 14:11:00 GMT
I do pretty much all my work using GNU Screen inside a terminal. I use a different screen session for each project and have pretty much the same window configuration for each session. After finally getting tired of manually setting up my screen sessions, here’s how I managed to script new session setup.
Like many I have a development directory where all my projects live. Inside this devel dir I have the trunk of each project checked out from version control. Most of my projects haven’t been converted to git yet, so I’m not sure how different it’d be compared to svn. My screen session is made up of several windows. Inside the first, I run emacs. The second is autotest. The third I run ./script/server. I also have a window for ./script/console and a database prompt; but the order isn’t that important. After those I’ll have a window or two for misc. bash prompts.
One solution to automatically setting all this up is to put screen commands inside your .screenrc to create and name the windows. You can even specify what command to run in the windows. The problem is that when you exit that command for whatever reason, the screen window is killed with it. That’s not so handy when you need to restart autotest or your server. Also, the .screenrc file doesn’t allow for any type of scripting for dynamically generating any of your startup information.
After digging in the man page a little bit I found a few screen commands that allow it to be scripted fairly well from outside scripts. I’ll show the important commands here.
screen -d -m -S <screen session name>
This will create a new screen session detached but with an input/output stream. The -S names the screen session to make it easier to refer to it later.
screen -X -S <session name> screen -t test 1
This sends a screen command to the screen session with the given name. In this case, the screen command is to create a new screen window named “test” as window 1.
screen -X -S <session name> -p 1 stuff "cd $DEVEL/$PROJECT; autotest
"
This again sends a screen command to the named session. In this case we’re sending the stuff command directly to window 1. The stuff command sends the string into stdin of the running application in that window. In this case the running app is a bash prompt. Note the trailing newline inside the string will cause the command “typed” at the bash prompt to be run.
The only other problem I ran into is that when creating screen windows like this, they didn’t show up on my hard status line automatically. My solution was to setup a little for loop and select each window like this:
for i in 0 1 2 3 4
do
screen -X -S <session name> select $i
done
Finally, when all is setup the way you want the last thing to do is join the resulting screen session like this:
screen -x <session name> -p 0
The trailing -p 0 says to start in the first window.
You can download my resulting script here. One thing to note is that I have an entry in /etc/services for each of my projects. I use this so that when I run ./script/server I always start on the same port for each project. Also, I’m making use of bash’s select command for prompting with project (or which already started screen session) to join/start. It’s a little clumsy in that select wants to keep prompting you for input after you’re done with the screen session; but it’s a lot better than what I had.
Posted in Programming | Tags emacs, screen, script | 3 comments
Posted by Doug
Tue, 09 Oct 2007 13:47:00 GMT
I mentioned in my post the other day about remote pair programming and someone called me out on it via email. Since I spend probably between 40 – 60% of my work time remote pair programming I thought I’d give some of my experiences.
First, some background. I’ve been moonlighting as a freelance web developer for a lot of years. I work with David Minor at Sus 4. He and I have done remote pair programming on almost all of our projects for the last four years. I also telecommute for my day job into blah blah blah (lawyers made me change this). I travel to the headquarters in VA once a month or so, but work from home the other three or four weeks. Probably half to three-quarters of my programming tasks at blah blah blah (lawyers made me change this) I pair with another developer. There are several different people that I’ve paired with regularly over the almost two years I’ve been there. Finally, I’ve talked a lot about remote pair programming at the Cincinnati Agile Round Table. From their Jim Weirich has picked up on my techniques while doing remote pairing at Edge Case.
What I’m trying to say here is that I have done a lot of remote pair programming over the years and I’ve tried a lot of different techniques. What I’m about to describe here is tried, tested, and proved.
Being on a Mac, I have paid licenses of both TextMate and SubethaEdit. They are both fine editors. I think I prefer TextMat over Subetha simply because I think TM handles projects better. However, I do think Subetha’s networking and multi-user support is really cool. The problem is with Rails projects I always end up with lots and lots of files open. Subetha doesn’t make it easy enough to share the files by default or for the remote guy to join their shared files by default. Plus, with TDD you have to have some way for both partners to see the test output.
While talking about things that don’t work… there’s just not enough bandwidth for VNC. I’ve done all I know to do to optimize it: drop the number of colors, change backgrounds to solid colors, muck with compression algorithms. I just can’t quite squeeze enough bandwidth out so that it feels interactive for both people.
So what does work? Welcome to the past. What I’ve found is that gnu screen running inside a terminal is the most bandwidth efficient, highly interactive, flexible multi-user environment. One person hosts, the other connects via ssh and joins the hosts screen session. For those who’ve never used screen, both users connected see exactly the same thing. Both users keyboards have simultaneous control of the terminal. Combine this with a good voice/video channel with Skype or iChat and it’s nearly as good as actually sitting next to someone.
Inside of screen you can have multiple tabs/windows. What I typically do is designate my first window to run emacs. This is my “IDE”. We do all text editing from inside there. I have another window designated for running tests (although sometimes I run tests from inside emacs). I have another window designated for the mysql prompt. Another is for tailing log files and another for running the server. Screen saves the history (I typically set it to something ridiculously large). Both people can see when you scroll through the buffer history. Both people can see all the data.
I’ve kinda glossed over the use of emacs here. I’ve also done remote pairing with vi (well, vim anyway). The point is that it helps a great deal if you’re using an editor that both people understand. I pair with a guy at work that only begrudgingly uses emacs. It’s not nearly as much fun for him. I’ve also paired with folks who aren’t comfortable with any terminal based editor. That’s no fun either.
Like pair programming when you’re actually together, there are a number of things to consider. Editor environments is one of them. Remote pair programming seems to heighten or exacerbate all the issues with local pair programming. Your communication issues are bigger. You really have to make a point to tell each other what you’re doing. Talk, talk, talk! A definite anti-pattern is one of the people in the pair going off to work on solutions locally on their own computer while the other person can’t see what’s going on. Do all work in the screen session. Make sure that both people can see everything that’s going on. Related to this, it’s hard for one person to “see” when the other is distracted. If one person is checking email while the other is trying to stay on task that’s no good.
The good news is that remote pair programming can work. I find actually pair programming in person to be very fulfilling, fun, and exciting. Remote pair programming isn’t as good as actually being together in the same room. However, it’s a very good substitute when the commute cost are high. If you’re the kind of person that doesn’t really dig pair programming in general, odds are you’ll find remote pair programming to be even less attractive than actual pairing.
I’ll also mention I know one guy (whom I respect a lot) who’s big on pair programming, but just can’t get in the groove of remote pair programming. I suspect his problem is lack of familiarity with the editor, but there may be other philosophical issues as well.
All that said, I don’t find running emacs inside a screen to be some “least common denominator”. In fact, I do all of my development this way—even when I’m not pairing. Lately I’ve been running multiple screen sessions on my box; one for each project I’ve got going. My “state” is always right where I left off. When I switch from independent work to pairing, it’s easy for someone to simply join my screen and we can get started. I’ll stop here and not get too carried away with singing emacs’ praises. That’ll be good info for another post…
Before I close out, it occurs to me that screen can be pretty ugly with zero config. I’ll go ahead an post my hard status config. This dresses things up quite a bit and makes it a lot easier to use. Put these lines in ~/.screenrc:
hardstatus on
hardstatus alwayslastline
hardstatus string "%{rk}%H %{gk}%c %{yk}%M%d %{wk}%?%-Lw%?%{bw}%n*%f%t%?(%u)%?%{wk}%?%+Lw%?"
Posted in Emacs, Programming, Commute, Test Driven Development, Internet, Community | Tags agile, emacs, pair, programming, screen, tdd, telecommute | 11 comments
