A good working environment

By Greg Turnquist

Greg is a member of the Spring team, an author of several books on Spring Boot, conference speaker, and the lead for Spring Data JPA.

August 30, 2011

I like a good working environment. Don’t you?

I’m not talking about the furniture in my office. Instead, I’m referring to how things are organized on my work machine. Do you ever have the feeling that your work is strewn all across the place, and you can’t find anything to save your life?

I found that if I put all my source projects underneath a single “src” folder in my home directory, it was easy to type the same keystrokes every day, and find the project I needed to work on. If I needed to retrieve something from another project, I also knew it wasn’t far away.

Long ago, I realized the value of decoupling source repositories from workspaces. Tools like Eclipse let you nicely create a workspace and then start creating projects inside them. The problem is, it defaults to putting the project inside the workspace. When I wanted to delete a workspace and create another with different settings, it took extra effort to safely move my source code out of it. I hated having to remember to do that. There is also the fact that sometimes I have different workspaces referencing the same source repository. Suffice it to say, I quickly stopped doing that. Instead it’s much easier to start up a project, put it under source control, and then import it into a new workspace. Now I create workspaces on the fly, and don’t invest too heavily in keeping them around, because I can always create another. The real gold is in my source repositories which are nicely tucked away under neath src.

Today I just discovered a nice payoff for keeping all my source repositories underneath src. Hopping between my laptop and my tower computer, I needed to smoothly transfer this folder of work between the two machines. I couldn’t use something like version control, because most of the projects inside src were also under control and nesting isn’t an offered feature. Besides, committing some work simply to move it to another machine that isn’t commit-worthy doesn’t sound like a good idea.

So what could I do? I have used rsync many times in the past for various purposes, and the thought of using rsync to push deltas, along with deleting discrepancies on the remote end sounded like the perfect solution. I rehearsed the exact arguments I wanted to use, and capture them in a toolbox script called rpush. I pushed my current batch of work from my laptop to my tower and it was perfect! I even had Eclipse open on my remote workstation, and it nicely popped up “Source file has changed. Reload?” I clicked yes and saw the changes. Perfect!

As I started to work, I realized that my tower was missing some key apps, especially DbVisualizer. Since I had fashioned rsync to push a single folder, a light bulb went off in my head. I simply pushed /Applications/DbVisualizer.app to my remote machine and then mv’d it remotely into the /Applications folder. Excellent. Anything else needed from my laptop was simply an rpush away.

Given all this, I also pushed rpush itself to my remote server. In fact, it was already there, because rpush is stored as part of a project inside src. Now when I need to shift back to working from the laptop, I can execute the same script from the tower machine. Given that rpush works on linux as well, it is just as easy to move back and forth between these machines and a virtual linux machine as well.

I don’t know about you, but that is what I call a perfect working environment.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *