Reality Quotient

There is a fairly subjective measure I've only recently been able to give a name to:

Reality Quotient = ability to keep context while working toward a specific goal

This has to do with how deep you allow your stack to be, which if you allow it to get too deep, this affects your net throughput on Cockburn's "unvalidated decisions" or Demarco's "Total Useful Mental Discriminations (TUMD)". If the stack is too deep, you end up wasting a lot of time making useless decisions about things that have ceased having anything to do with the REAL task at hand.

The tendency to accept decisions that pin you into a corner is closely related to lowering the Reality Quotient. There is a whole book about the attitude of Getting Real, and I equate that attitude with a high Reality Quotient.

I did a search to see whether anyone else had published a writeup under the "Reality Quotient" heading. Although I found a lot of stuff on the web, none of it really matched what I wanted to say. The topic of this post is NOT:

• whether you are an honest person in general, or in a specific social situation
• a manager trying to find out what's REALLY going on in his/her org
• whether the actions of time travelers will have any effect
• some kind of measure of whether a politician is telling the truth or producing spin
• some measure of how "real" a reality show really is

The measurement I wanted to talk about is how capable you are of focusing on the problem you set out to solve until 1) it is truly solved and published to the world, or until 2) you have redefined the problem into another solvable one and published that transformation to the world.

In short, a high Reality Quotient requires a short stack, with tight feedback loops, focused on publishing real stuff to real people.

Expert genealogy answers

The focus on "expert answers" really helped me to better understand the shift in focus that was recently announced for StackExchange.

The obvious application is to the genealogy domain. There is a huge "long tail" to genealogy. FamilySearch's wiki is opening that space up -- but there may be some room for a Q&A kind of experience.

IntelliJ patches don't seem to install

When I started IntelliJ (9.0.1, community edition) today, it popped a dialog up with an option to download a "patch" to install 9.0.2 release.

I've clicked "Download Patch" before, but nothing ever happened, and I ended up resorting to a full install.

But today, I came across a comment that described how to apply the patch:

http://blogs.jetbrains.com/idea/2010/01/intellij-idea-901-released/#comment-128607

And it worked great for me.

Others on my team said their patches installed just fine. To be clear, I'm using the Community Edition, and it may only be an issue with that edition.

BYU Conference on Computerized Family History & Genealogy

I attended BYU's Conference on Computerized Family History & Genealogy Monday and Tuesday this week.

It was really informative and disorienting in a good way. I've been working on New FamilySearch for a long while and not realized fully what kind of a target audience I've been developing for. When I was one of the only 30-somethings in the room, and we were talking about a more-than-a-decade technology generation gap, it finally sunk in that the world was different than I had thought.

The main topics I came away with were:

• The technology generation gap is NOT ok, and needs to be bridged (by both the younger and the older generations).
• Among serious genealogists, there is a very real drive to publish, similar to the scientific community's reputation-based drive, but motivated also by a desire to preserve research that would otherwise be obliterated by death or lack of interest on the part of direct descendants.
• There is also a gaping technological hole in the genealogical community: Lack of Internet-style content-driven collaboration on genealogical research. Even serious genealogists seem to be content with this state of things.
• The Next Generation (TNG) looks really nice. I want to use it for the Sumsion family tree on sumsion.org/genealogy.
  

The idea that I can make a difference here is VERY motivating.

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.