Building Mup on Ubuntu Jaunty 9.04

I really like the Mup music typesetting program. It had been a while since I had needed to do some music, and I had never installed it on Linux before, so I thought I would give it a go.

It was harder than I thought, but I got it to work. Here is what it took:

• download and extract the source tarball
• install the following packages: gv, playmidi, libx11-dev, libfltk1.1-dev, libxpm-dev, libxext-dev
• change the makefile to link in some different libs, here is what I got to work:
  

# You can use fltk_jpeg or jpeg library, whichever you have
JPEGLIB = fltk_images

# You can use fltk_png or png library, whichever you have
PNGLIB = fltk_images

# You can use fltk_z or z library, whichever you have
ZLIB = z

• sudo make install

Now mup works, and the new mupmate and mupdisp, too.

The license code goes in a single-line text file: ~/.mup -- similar to the DOS mup.ok contents.

Starting a box with git

In The Creative Habit Twyla Tharp talks about "starting a box" to keep track of all the creative ideas that come on a project.

I've used git to just start tracking ideas in digital form. A brand new git repo is my digital box. Usually, the ideas start out as a whiteboard diagram or scratching on paper, which I then scan to PDF and put in the folder. The organization varies, but chronological file naming has worked for me, as has thematic subfolder organization.

Being able to just capture the work frees me up to try new things and not worry about whether that stuff I just did is safe or whether I can get back to it if I try something new out.

Git does such great cross-file compression that even after several revisions across binary files, the resulting repo sizes are surprisingly small.

An entire sprint without an SVN branch

A typical development flow has been:

• request an SVN task branch (wait for CM to help)
  
• do stuff (1-3 weeks)
  
• run all the regression tests (not on the latest stable)
  
• hope that nobody did anything that conflicted with us
  
• merge to the pending release (and pray we resolve any conflicts correctly)
  

Now we do the following:

• set up a team git repo (able to do this without CM's help)
  
• clone off a repo for each team member
• set up a daily cron job to get the latest stable from the pending release
• set up a daily hudson build to merge that in and push to team if it passes unit tests
• pull from team as we go (fast!)
  
• run all the regression tests (on the latest stable)
  
• use git to merge on top of the pending release and commit back to SVN (with minimal conflict windows)
  

Well, we finally got through a whole sprint without an SVN task branch. Maybe that seems like a small victory, but it saved us a bunch of late-breaking integration risk.

Exchanging gravitons with the monolith

When I was telling my colleague about my plans to aggressively modularize the monolith, he said:

You're exchanging gravitons with the monolith.

And he was right. The effect of the warped space-time in the close vicinity of the monolith was such that I lost sight of the new work we had recently embarked on. The trajectory I was on got skewed by the gravitational pull.

It is not sufficient to be doing work that is improving modularization. It is required to be doing work to deliver user value all the time -- and to take advantage of every opportunity to modularize in order to deliver user value.

Letting modularization become an end in itself is sometimes tempting, but in the end it was not the right path forward.

Blog by writing post titles

I got sick of trying to think of profound things to say here.

So I just started writing post titles until I found a topic I wanted to write about. Maybe that is what I can do the next time I'm feeling like a post is over-due.

Site Design Tips

In thinking about what next for fshelper.org, I've been on the lookout for good site design ideas. Here is the most recent article by Jakob Nielsen who has cared about this for much longer than I have.

Also, I found the Daleri Structure site design by Andreas Viklund to be very appealing for how I want the site to feel: informative, down-to-earth practical, and well-linked.

Refreshing Take on OS Upgrade

I'm typically a laggard when it comes to upgrading my OS. I like for things to be stable -- I don't like to waste time fiddling with things unrelated to what I've got to get done for whatever project I'm working on.

So now in July, I'm upgrading to Ubuntu 9.04 (released in April). To state how much of a laggard I usually am, I think this is the most up-to-date I've ever been on an OS upgrade.

I decided to use the standard "upgrade to 9.04" feature exposed in "Update Manager". So when I saw a screen like this:


then I felt happy. I felt like I knew what was going to happen, and that I was in control of the process to some degree. This freed my mind up and let me think about what I could do to minimize any upgrade risk.

In the past, because of the helpless feeling of being out of control of what's going to happen and what I can expect, I've avoided upgrading until the pain became great enough to justify a full backup/reorg of all my files that I for sure wanted to keep.