1. Fix the Carpet

The shag carpet everywhere in this apartment is evil. It needs to be ripped up and replaced; or alternately, covered with some very solid, rigid plastic or wood flooring. Shag carpet is not suitable for an office.

I can get a decent 4′ x 8′ board or two at Lowes that should suffice, if I can just figure out how to fit that in my Prius. (I just knew I was going to regret not buying the pickup truck. )

2. Turn on the A.C.

The problem with a loft office is that heat rises. The central air conditioning in this place is not very effective. I need to improve it, or keep it running more of the time.

3. Buy a New Chair

My Aeron is just too old and decrepit. It lasted a while, but I need a new one, or something better. This won’t matter though unless I fix the floor first. (See #1.)

I’m willing to consider non-traditional chairs (kneeling chairs, recliners, etc.) but it might need to be in conjunction with a new desk. I’ll only try this if I can really try it out at a store first though.

Desk wise, what I want doesn’t seem to exist (and I’ve looked). I want a fully adjustable desk. I want to be able to independently and easily move the monitors, keyboard, and mouse to exactly where I want them, within a millimeter or two; up and down, backwards and forwards, and possibly tilting them as well. Anything that’s a fixed height is almost certainly not the right height for me, on at least one axis.

On the other hand, the one piece of my current setup that really works adequately is the table I use as a desk. It’s a big board from IKEA on top of some adjustable height legs normally used by musicians. If I can’t find anything better, this will continue to serve.

I should probably also get an extra table for random paperwork, books, disks, and other office flotsam. However, this will be less helpful if I can’t roll my chair over to it.

4. Buy a New Mouse

Done, but the Logitech I bought just isn’t cutting the mustard. The response is too linear. I need to go back to a Microsoft Intellimouse. Nothing else feels right.

5. Buy a KVM

I need to be able to access several systems easily without switching all my cables around. I need at least 2 setups and maybe 4: Mac, Linux, and PC.

The problem is most KVMs are stuck in 1998: VGA displays and PS/2 mice. Does anyone even use those any more? All my systems are DVI and USB. The Belkin Flip might be a start, but is there a 4-port version?

6. Buy an External Hard Drive

Well, really, buy some more. One thing I didn’t expect from the move was that I have now shifted over to my X86 MacBook as my primary system. Aside from some minor Warcraft glitches, it performs as well as my old dual G5 desktop, which I now rarely turn on. However it is lacking the hard drive capacity of the G5. I need to figure out which of my files really don’t need to be with me all the time, and move them onto an external drive.

The tricky part is that a lot of what really needs to move is my media. That is, my iTunes and iPhoto libraries. However I don’t want to move all of it. Some of it needs to stay with me. Is there a way to split these libraries across multiple physical disks? Another large folder that really needs to be split into occasional and essential contents is my Applications folder.

7. Get Virtualization Running

Figure out why Parallels is non-functional.

Or install VMWare.

Or get Bootcamp going.

If I can get all that done, then maybe I’ll finally be able to start doing some real work at home. I would even be willing to pay an ergonomics consultant or interior designer if they could find me a setup I’m comfortable with. But it has to start with replacing this damn shag carpet!

Furthermore, projects may have dependencies on other projects. For instance XOM 1.1, JDOM, and dom4j all depend on Jaxen. For the latest and greatest JAR, Jaxen should be rebuilt using its own build.xml file, rather than bundling a stale JAR archive that’s months or even years beyond its expiration date.

You could
cd

into each separate diretory and type
ant compile

in each one, but that’s time conmsuming and error prone. Plus interproject dependencies may require this to be done in a precise order that makes this even more error-prone. It’s preferable to create a master build file at the top level that compiles everything by invoking targets in the other build files. The ant task lets you do this. For example, this task executes the build.xml file in the directory website (relative to the directory where the current build.xml file is) :

  <target name="website" depends="init" description="Build the website">
    <ant dir="website">
  </target>

If the build file is named anything other than build.xml, add an antfile attribute giving the file name:

  <target name="website" depends="init" description="Build the website">
    <ant antfile="docbuild.xml" dir="website">
  </target>

Both of these execute the default target. You can select a different target using the target attribute like this:

  <target name="website" depends="init"
       description="Build the website">
    <ant antfile="build.xml" dir="website" target="tutorial">
  </target>

By default, all Ant properties in effect for the current target are passed to the subbuild. You can prevent this by setting inheritAll to false:

  <target name="website" depends="init" 
      description="Build the website">
    <ant antfile="build.xml" dir="website" inheritAll="false" >
  </target>

If you set inheritAll to false, you can still pass individual properties to the subbuild using using nested property elements. These can use either the same or different property values. You can also set new properties for the subbuild that are not available in the master build. For example, this task inherits the version property, changes the license property to the fixed value Commons Attribution-NonCommercial-NoDerivs, and removes all other properties:

  <target name="website" depends="init" 
        description="Build the website">
    <ant antfile="build.xml" dir="website" inheritAll="false" />
    <property name="version" value="${version}"/>
    <property name="license" 
                     value="Commons Attribution-NonCommercial-NoDerivs "/>
  </target>

That’s pretty much it. You can now have separate build files for different reasons and still combine them all. Cool!

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jedit login

 
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jedit co -P modulename

Of course many projects are divided into multiple modules, all of which are required. You can check out the entire project, including all of its modules like this:

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/project login

 
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/project co .

That is, replace “-P modulename” with a period. This does check everything out into the current working directory, so you’ll probably want to match CVS’s project directory first. For example, when checking out jEdit,

~/projects$ mkdir jedit 
~/projects$ cd jedit
~/projects/jedit$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jedit login 
Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/jedit
CVS password: 
~/projects/jedit$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jedit co .
cvs checkout: Updating .
U build.xml
cvs checkout: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvsignore
...

This checks out the entire project. The downside to this is that it may check out some vestigial empty directories as well that are no longer used. (CVS is very bad at pruning old directories from the tree when a project is reorganized.) You may want to identify and delete these directories on your local system. They can be identified because they only contain other empty directroies and a CVS directory. When checking out jEdit there is one of these,
com

.