Multitasking

Right now I have four IDE windows open: NetBeans, two instances of Eclipse running on my main development machine, and another Eclipse running on a laptop to which I'm connected via Remote Desktop. All are running some mixture of the same projects. My development box runs Ubuntu, and I'm a multiple desktop addict.

I've noted before how I like NetBeans' integrated Tomcat server, but don't particularly like its Java editor or debugger. So when working on a web app, I set up projects in both NetBeans and Eclipse that refer to the same source tree. When switching between them after edits, I do need to kick off a rebuild, but this takes a fraction of a second to complete. It works well enough, in fact, that I don't feel the need for any of the web development plugins that I can get for Eclipse.

The two Eclipse instances are a little trickier to explain. My default Eclipse workspace has pretty much all of the projects that I'm currently working on, some open, most closed. And for the most part, that's a Good Thing: when I edit, say, a utility class, all dependencies in the workspace will pick up the update.

However, I've found that there are times when I want to switch back and forth between projects. For example, I'm working on a mainline project, and think of a series of changes that I want to make to a utility library. I find it's easier to use separate Eclipse workspaces for this, since each workspace can have its own set of open windows. When I switch from one workspace to the other, I maintain the context of where I stopped working.

Unfortunately, switching workspaces within a single Eclipse instance is not a matter of a few seconds, and the new workspace opens with the folder view collapsed. Separate instances can coexist peacefully, however, as long as they're using different workspaces. The JVM has become good enough about sharing portions of virtual memory that there's no noticeable swapping when I switch between instances. The only real drawback to this technique is that changes — particularly refactorings — don't automatically update across workspaces; I have to manually refresh.

That brings me to the Eclipse instance running on my laptop. I've found that, even within a single project, I'll be working on one part of the code and think of a refactoring somewhere else. Or realize that a widely accessed method should change its signature. I tend to be anal about my checkins: the commit message should accurately describe what was changed, and I don't want to check in a lot of files that have changes incidental to the commit.

One solution is to keep a list of such changes, and postpone them until after my current checkin. But that doesn't always work: sometimes it will be hours between checkins. Sometimes an entire day. And while some refactorings don't look so good in the cold light of morning, usually the delay just makes my current coding more difficult.

The laptop solves this problem, by holding a copy of the code as-of the previous checkin. Refactorings or signature changes can happen there, get checked in, then applied to my main directory via svn update. And while this seems like a recipe for disaster, or at least eternal conflicts, I've been surprised at just how easy it is to integrate such changes — they are, after all, incidental to my “current” work.