Utah Open Source Planet

Ever since my third bout in the hospital about a month ago for stomach problems, I’ve been even more strictly watching what I’ve been eating.  In that time, I’ve been noticing an interesting trend.   The cost to buy better food is marginally small compared to the healthy benefits that come with it.

I’m no economics master (nor do I have any interest in becoming one), but one thing seems pretty obvious to me.  If you’re going to pay $3 for a piece of crap lunch, chances are if you spend a little bit more, you can get something on a magnitude of 2 or 3 times better for you.

Here’s one specific example I’ll use.  At work, there’s a grocery store in the same area.  There’s a Subway a little bit down towards the end of the strip mall.  If I went there, I could get a crappy sandwich with nasty cheese and disgusting bread for about $5 after tax.  It’s not glamorous or great, but it’s cheap, right?  Well, if I go to the grocery store and order a custom made deli sandwich with really fresh meat and really good cheese, it cost’s me an extra $1.50.  Sure, it’s more money, but I’m not going to have to worry about having stomach problems.  And $1.50 extra is nothing in comparison to a $500 trip to the emergency room.

My take on the whole economics of it is, you’re already going to spend X amount of dollars for food.  Why not increase your budget by about 25% and get something *really* good for you.  Ever since I’ve started doing that, I have been feeling so much better.  Lots more energy, less tired, and just healthier in general.

A few other quick examples.  My sister who is a food guru, convinced me to switch from margarine and instead just buy real butter.  I was always, of course, put off by the higher food prices.  But then one day I looked at the ingredients of the margarine I was buying, which was basically nothing more than whipped plastic.  Looking at the one for the butter, it had one ingredient: whipped milk / cream.  That was pretty surprising, so I checked it out, and I loved it, and of course it’s nice to know that I’m eating less garbage.

Another thing little sis has warned me against is checking the ingredients for food where the first item listed is high fructose corn syrup.  Well, I’m a big fan of juice and everytime I go to the store I buy some weird combination of juice to try out, like Apple Cranberry (which is always my favorite).  I just barely looked at the ingredient list the other day and sure enough, the syrup of death was the first item on the list.  Ick.  So, I switched to buying 100% pure grape juice and apple cider instead of my regular stuff.  Again, it costs about 30% more than the old stuff, but I feel a lot better overall.  It’s been great.

Anyway, nothing major so far, but I’m making progress.  It’s pretty interesting how just quickly checking the ingredient list will turn you off of buying something.  I’m getting in the habit of spending slightly more for food, but I’m feeling better all the time.  And I’ve had a lot less stomach problems, too.  I tell you what.

I went to the doctor again a few days ago, this time just to a clinic, because I’d been having problems with my stomach since the past week. The whole scenario strikes me as really odd, since none of the symptoms that would cause problems have been present, which are usually stress and me eating crappy food. Ever since I was in the hospital three weeks ago for throwing up for four hours straight, I’ve been keeping a closer eye than ever on my intake. This just kind of came out of the blue, though, with some acid reflux showing up all of a sudden for a few days.

The only thing that I have any idea that might be causing it is that since it’s finally started to get warm over here, I’ve started up my nightly regimen of going skating every night that I can, usually for somewhere between 30 minutes to 3 hours. I imagine that the stress on my stomach muscles was probably unexpected and just kind of threw it for a loop.

It didn’t help much that the doctor at the clinic was pretty impatient, and I didn’t feel like he was really giving me proper attention. He gave me a prescription for Prilosec, which also kind of annoyed me since I could have gotten that myself. I tried it out and it made me really dizzy, so I’m not going with that one again.

I’m trying to setup an appointment with a specialist to figure out what the story is once and for all. I know that a few years ago I was diagnosed with *starting* to get a peptic ulcer, and in times of extreme stress and anxiety the same area in my stomach will start to flare up again and cause some general discomfort … or I’ll start throwing up. I haven’t had any major stress though, not since the hospital incident, but there is just some minor nagging down there. For now, I’ve just come to the conclusion that I have a sensitive stomach.

I’ve started looking at diets for people with acid reflux, and so far the lists seem kind of arbitrary of what you can and can’t eat, in the sense that none of them seem related. The idea of a restrictive diet always seemed normal to me, but I always assumed it would just be to stay away from anything strong or spicy. Not something random like mashed potatoes, butter cookies and ice cream. But, whatever. Hopefully I’ll get this thing figured out soon.

My son is participating in the Lego Mindstorm robot contest. It’s been a pretty steep learning curve trying to not only understand how the Mindstorm works, but then trying to teach him how to program the darn thing. First he tried a GUI based procedural system and then gave up and so I’m trying to teach him C. The good news is that there are a number of ways to try to solve the problem of following a line, and he’s trying them all.  I’m a little worried about what happens when the line breaks, but I’m sure he’ll figure it out.  I’ll be sure to let you know how it goes.

-Peter

I’ve been pretty busy - I decided to raise the price on the house to $400K so that it shows up on the first page of the Utah MLS search.  It seems to be working because we’re getting more showings.  I think that we’re going to end up at the same price, but trying to second guess the buyer and lower it to closer to the expected sale price really didn’t work.  In this market, buyers are expecting to talk the seller down, and if it’s already at a lower price, there must be something wrong with it.  Who can figure?

We are doing some upgrades though… Granite on Friday, Floor Refinishing next wee, and new appliances in two weeks.  After all of that, maybe I should stay… nah… I gave my word and they’re depending on me.

www.pghouse.info
-Peter

I keep meaning to post more on the things I read, listen to and watch.

I watched the dramatization of the play My Boy Jack by David Haig.  It is the beautifully told story of Rudyard Kipling and his son Jack.  Jack was extremely myopic, but wanted, like every other young man his age, to join the war effort.  Kipling did all he could to help Jack become an officer after Jack had failed to get in twice.  Jack was declared missing in the Battle of Loos. It was nearly two years before Jack was declared KIA.  It was after this that Kipling wrote the poem My Boy Jack.

My experience with Kipling and author authors of WW I literature goes back to working at the BYU Library.  I was asked by Librarian Robert Means to help create a web site to go along with an exhibit he was putting together as an Anthology of World War I Literature.  While the web site is nothing to yell home about (I was just learning),  the content is great.  I’d recommend anything found on the site.

I had to go to the hospital again this week for problems with my stomach, I was throwing up on and off for about 4 hours on Monday night before finally going in to get an IV to get some fluids back in my system. I’m feeling a little better now, I’m able to get up and move around, but still can’t eat anything more exciting than toast. Oh, and it really hurts to laugh.

I’m convinced that a large reason for my stomach problems has been stress and anxiety.  Most of the problems have been financial in nature, since I haven’t gotten paid for a lot of contract work I’ve done, and I wasn’t really expecting that to happen.  Aside from that, though, I’m stretching myself too thin with lots of commitments, and I need to start cutting back.

Gentoo is the major committment I’m spending way too much time on right now, I think.  I enjoy working on it a lot, but I’ve got my finger in too many pies right now to keep it balanced and productive.  I’m gonna start cutting off stuff that I’m taking care of, and retreat back to a few areas of maintainership, of stuff that I’m really interested in.  There’s some things I’m taking care of just because no one else will, and while I’ll do my best to clean them up on the way out, I can’t take care of everything I want to forever.  I’ve been thinking about phasing back my workload for a long time now, and the change will be gradual, over a couple of months.

What I’d really like to work on more is get my own religious projects working, like going back to working on nephi.org.  Some of the projects on there I’ve been putting off for literally years.

All in all, what I need the most though is to find some balance and learn to relax.  It is extremely hard for me to to stop and sit still for more than a few minutes, as I’m constantly hyperactive and won’t be satisfied unless I’m engaged in doing something appealing.For the most part, it’s fulfilling because you can accomplish a lot, but it can create a lot of anxiety and pressure when you commit to a lot of things and then can’t keep up, which has been what’s happened with me.

Anyway, while poking around the apartment this week I’ve been playing with my whole TV setup, and especially with Myth.  I came up with this cool method and script last night to create snapshots for my shows in MythVideo.  I’ll have to post details once I get some time.

Errands run, kids in bed, and Krull On Demand. Finally, sometime to put some thoughts down about building the Alfresco Appliance.

Some of what I write here refers back to when I original put together, the first version of the appliance. Some is from revisiting it for this release.

Choosing a distribution

I started playing with building an appliance right about the time that Ubuntu announced their Jeos distribution. I have a strong preference for openSUSE and would have liked to have built the appliance on it. (LimeJEOS answers my concerns, and I am excited to give it a spin. Just a few more things to move off my plate before I can devote time to it.) I tried several different distributions: Fedora, openSUSE, Ubuntu, Puppy Linux, Zen Walk. I liked some, was optimistic about others, and disappointed and frustrated with a couple.

What I wanted was a distribution that provided me a small lightweight base, and gives me the ability to add just the packages I needed to run my application. Most of these came in close to what I wanted, but due to dependencies, grew to be much larger than I wanted. Some didn’t even provide me with a nice clean way to get the applications I was dependent on. Those I dropped immediately. Those with decent package mangers got pluses. I wanted to be to keep base packages up to date.

This brings us to Ubuntu Jeos (Just Enough OS). It gave me the size, the packages, and the manager that met my base criteria for a distribution.

Getting Started

While the base install is already fairly small, there still are many packages that I was going to need and not need. This takes some time, but go through the installed packages and identify what you aren’t and are going to need. Make a list and develop a script to remove the ones you don’t need. Another to add the ones you need. You may like to have some of the packages around while developing your appliance, but when you go to deliver it they may add more weight than what you would like, or give tools that just aren’t need by your appliance, or your end users. Keep them installed until you are sure they aren’t needed any more. My list includes: man pages, wireless-tools, sound packages, laptop packages, different editors, hardware utilities, etc. Your list will vary. Sometimes you may want to force remove dependent packages if you know their functionality is not needed. Don’t be afraid to take them out.

I know my list is not perfect, but over time it will improve. Some of this will come with trial and error. Don’t expect to get it right the first time.

Once I narrowed the package list, I started to add my dependent packages. Some of these could require you to re-add removed packages. That is why I suggest leaving packages installed until you have all your dependencies installed.

One of the cornerstones of an appliance is zero configuration. You want people to be able to just deploy the appliance, start it and use the appliance. In the case of Alfresco, it needs Tomcat to be started at boot time. For this I needed an init script. (Mine can be found here.) I use the init script to start Tomcat, start needed services, and perform runtime configurations.

Alfresco is a web-based application, so I need a way to provide the URL needed by users to access the application. For an appliance this can be changed from install to install. There are several ways to handle this, eventual, you will want to have a static address or use Dynamic DNS to update IP to name mappings. My appliances is primarily for evaluation. It is not really ideal to play with DNS or static IPs. I have kept the implementation simple, I’ve created a script that updates the /etc/issue file with runtime URL. (The script I use is here.) The major issue I faced was when the script was to be run. I placed the script in /etc/network/if-up.d. I fully expected it to be run when the interface came up. The script did run when I manually ran ifup. But it didn’t run in every case, especially the most import, at boot time. I tried several different things to work through this. I added a reference to the script into /etc/network/interfaces using the post-up directive. (in openSUSE, you would add a POST_UP_SCRIPT=”<name of your script>” to the interface file in /etc/sysconfig/network and put the script in /etc/sysconfig/network/scripts). This added a bit more power, but did quite fix my problem. I finally narrowed it down to udev. The interface was being brought up by udev, but when /etc/init.d/networking is run, it runs ifup with a -a option (all interfaces marked auto). The problem with this is if the interface is already up, the associated scripts won’t be run. I haven’t found an appropriate fix for this yet. (Any ideas?) So I just disabled the udev rule for the network interfaces . rPath has a good solution for this, they change /etc/issue file in an init script. I like this idea, but didn’t want to write another init script or pollute my existing alfresco init script with this.

Plans for the Future

One of the things that I want to do is provide some Alfresco branding to the appliance. I also want to create some more production ready appliances that use MySQL and point at an external virtual drive to store content and the indexes.

What is Missing

One of the big things that is missing in a management interface for the appliance. rPath provides a very nice extensible web-based administrative interface. It is extensible both for function and branding. But it is rPath specific. I’d like to see an open source cross distro solution. One that was not only extensible but adds CIM based management features. This would make it easy to administer the CIM instrumented applications on the appliance, but also could allow it to be managed externally, but CIM enabled management tools. This would allow the appliance to play nicely in the data center. This is something that Xen is working toward.

I haven’t participated in these memes before, but I thought I’d give this one a try.


$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
126 ls
117 bzr
104 clear
96 eg
79 cd
56 hg
37 less
22 svn
22 git
16 grep


Kind of embarassing. I don’t know why I type ‘clear<enter>ls<enter>’ so much, I just do. I know about ctrl-L too, but for some reason I just type ‘clear<enter>ls<enter>’ a lot during the day. *shrug*

Speaking of Vim.

IPython is invaluable for learning Django if you don't know much about Python or anything about object-oriented prgramming.

Today is World Autism Awareness Day, and as the father of an aspie, I’d like to encourage everyone to take a moment to learn a little more about Autism. 1 in 150 children are diagnosed with Autism.

There are some great resources out there to learn more about Austism:

• www.autismspeaks.org
• http://en.wikipedia.org/wiki/Autism
• http://en.wikipedia.org/wiki/Asperger_syndrome

Wired had a great article in February. CNN is doing a full day of coverage. And the Sundance Channel will be showing Autism Everyday.

Version control systems each use their own method to refer to different versions (also known as ‘revisions’) of the repository. The choice of revision specification often reflects underlying data structures, and the choice of data structures often inhibits or enables various features for the system. Additionally, the methods of displaying and using revision specifiers can also affect the ease with which users can learn and use the new system.

Unfortunately, a full comparison is beyond the scope of this post. I will concentrate on simply introducing the basics and giving a flavor for how things are layed out, which itself is a long enough topic. While conclusions could be drawn with just the data and explanations presented here, I am intentionally avoiding doing so and leaving such to possible later posts. (Besides, bloody taxes and the brain-damaged US tax code have stripped me of any time that I would need to write such additional comparisons.)

Warning: My pictoral representations for each system will be crazier and more complex than usual (and even more lopsidedly complex for some systems than others) in order to keep things short while still showing what is possible.

cvs

Method

See cvs revision numbers and cvs branching basics, particularly figure 2.4 near the end of the branching basics section.

CVS has revision identifiers that are per-file, meaning that repositories at any given time are a combination of many different revisions (one for each file). Ignoring an ugly technical detail about the special revisions 1.1.1.1 and 1.1.1, the first version of a file is numbered 1.1. The next change to the file is recorded as 1.2, the next is 1.3, and so forth. If the user wants to create a branch, based on the 1.3 version of a file, then the branched version is 1.3.2.1. Changing and committing the file on the branch results in 1.3.2.2, then 1.3.2.3, etc. A second branch also created off of 1.3 would be numbered 1.3.4 instead of 1.3.2 (with actual commits numbered 1.3.4.x).

Note that branches are named by a revision with one less number (e.g. 1.4.2 is the name of the branch with commits numbered 1.4.2.x). As such, branch names refer to the beginning of the branch. Each file is branched separately, with per-file revision numbers (it is even possible to branch some files without branching others).

Tags are aliases for a specific version number. Since revisions are per-file, a given tag may refer to different revision numbers for different files (e.g. the ‘v1.0′ tag might refer to version 1.27 of foo.c, 1.36 of bar.h, and 1.218 of foobar.py)

Uniqueness of cvs revisions is not an issue since there is only one repository.

Picture

                       (etc)
                         |
             (etc)   1.4.4.3.2.2
               |         |
            1.4.4.5  1.4.4.3.2.1
               |         |
            1.4.4.4  (1.4.4.3.2)
               |     /
               |   /
            1.4.4.3
               |
  1.4.2.2   1.4.4.2
     |         |
  1.4.2.1   1.4.4.1
     |         |
  (1.4.2)   (1.4.4)
      \       /
       \     /
        \   /
         \ /
         1.4
          |
         1.3
          |
         1.2
          |
         1.1

svn

Method

See svn revisions and working with your branch, particularly figure 4.4 (the branching of one file’s history).

svn uses global revision identifiers, with the first revision being marked as 1, the second as 2, the third as 3, etc.

Branches have an unusual implementation in subversion; they are handled by a namespacing convention: a branch is the combination of revisions within the global repository that exist within a certain namespace. Creating a new branch is done by copying an existing set of files from one namespace to another, recorded as a revision itself.

Tags (an alias for a specific version in history) don’t exist in subversion. Instead, subversion again uses a namespacing convention identical to that done for branches (thus making tags and branches indistinguishable in subversion other than the chosen names), and users are merely discouraged from committing additional changes to files within a tag namespace.

Uniqueness of svn revisions is not an issue since there is only one repository.

Technically, a revision could simultaneously modify any combination of branches and tags by simply committing to all namespaces; however, this is typically discouraged and users only have a certain namespace checked out at a time.

Picture

  trunk   branches/proj-2-22  branches/proj-2-20  tags/RELEASE_2_22_2
   24
                                                        23
                 22
   21
   20
                 19
                                     18
                                     17
   16
   15
                 14
                 13
                 12
   11
                                     10
    9
    8
    7
                                      6
    5
                                      4
    3
    2
    1

bzr

Method

See understanding bzr revision numbers and specifying bzr revisions.

bzr, like svn, uses 1, 2, 3, etc. for revision numbers. However, the revision numbers are always consecutive in a branch. Merged in changes from other branches are given 3 numbers per revision. For example, if changes were merged from a repository that has changes relative to revision 2, the changes would come into the current branch numbered 2.1.1, 2.1.2, 2.1.3, etc. If changes from more than one branch are relative to the same commit, then the middle number is used to distinguish commits from the different branches. Thus one would see another set of changes relative to commit 2 numbered as 2.2.1, 2.2.2, 2.2.3, 2.2.4, etc. (Versions of bzr older than 1.2 used more than 3 numbers in certain cases, but that is no longer true of current versions.) See the picture below to make this clearer.

Branches in bzr are done by creating separate directories (typically with their own repository), though one can set up shared repositories. Each branch will have its own numbering scheme for the revisions it stores, recording the order that the revisions entered that repository. (See below about uniqueness issues.)

Tags in bzr are an alias for a commit, and are stored as part of a branch.

Note that bzr revision numbers are not unique. If you have the same revision in two different repositories, they will not necessarily have the same revision number in both. bzr does store unique identifiers for revisions, known as revid’s (an example of which looks like Matthieu.Moy@imag.fr-20051026185030-93c7cad63ee570df), though they are not shown by default. Users can obtain these unique identifiers by passing the –show-ids flag to bzr log, and these revids can be used in place of the simpler default revision specifiers when prefixed with “revid:”.

Picture

              12
              |
              11
            / | \
          /   |  \
        /     |   \
      10    4.1.5  4.2.2
       \   /  |      |
        \ /   |      |
         9    |    4.2.1
        / \   |   /
       /   \  |  /
       8    4.1.4
       |      |
       7    4.1.3
       | \    |
       |   \  |
       6    4.1.2
       |      |
       5    4.1.1
        \   /
          4
          |
          3

          |

          2
          |
          1

Note: The revision identifiers shown in this picture are dependent on merge order; the revisions 4.1.5, 4.2.1, and 4.2.2 could instead be numbered 4.2.1, 4.1.5 and 4.1.6 respectively if the merges done to obtain revision 11 were done in a different order.

git

Method

See Understanding git history: Commits, and naming git commits.

git uses cryptographic checksums (in particular, sha1sums) of repository contents as revision identifiers. These checksums are 40-character hexadecimal strings (e.g. 621ff6759414e2a723f61b6d8fc04b9805eb0c20). Each revision also knows which revision(s) it was derived from (known as the revision’s parent(s)).

Git can be used with one branch per directory like bzr or hg, but it is more common to have branches stored within the same directory/repository (thus the reason some refer to git as a ‘branch container’). In git, branches record the revision of the most recent commit for the branch; since each commit records its parent(s), a branch consists of its most recent commit plus all ancestors of that commit. When a new commit is made on a branch, the branch just records the new revision. Tags simply record a single revision, much like branches, but tags are not advanced when additional commits are made. tags are not stored as part of a branch or in a revision controlled file, though by default tags that point to commits that are downloaded are themselves downloaded as well.

git revisions are unique by design; if you have the same revision in two different repositories, the revision name for both will be the same.

git does provide more human-meaningful ways of referring to commits, in the form of simple suffixes used to count backwards in history from the tip of a branch (or backwards from a tag or commit). This includes methods for counting relative to different parents, making the suffixes have structural meaning. However, such methods are somewhat hidden; for example, they are not shown in the output of git log. This leaves many users unaware of how to take advantage of them, if they are aware of them at all. (A simple wrapper can get them to be shown, at the cost of a little time; they could be shown at negligible time cost with an integrated solution, but none exists to my knowledge.)

Picture

           650a6f...
              |
           caf806...
          /   |   \         719b9d...
        /     |     \       /
      /       |       \   /
 75cc2c...  147c0a... acac44...
      \       |         |
        \     |         |
         8f50e6...    8147be...
         /    |     /
       /      |   /
  9b39b2... 6e2cde...
    |         |
  01fa22... 1a9d90...
    |    \    |
    |      \  |
 46508c...  b6765c...
    |         |
 1c4e8d...  328638...
       \     /
       6627f7b...
          |
       754b42...
          |    \
          |      \
       d1879f...  fba5d0...
          |
       c962db...

hg

Method

See a hg tour through history, and section 2.4.1, “Changesets, revisions, and talking to other people”.

hg uses a method that may look like a mix of the methods used by git and bzr; it has two distinct methods of referring to each revision. Like git, hg uses sha1sums to refer to revisions (though it abbreviates them to fewer characters by default). Like bzr, hg uses the numbers 1, 2, 3, etc. to refer to revisions. Thus hg has one unique method to refer to revisions and another that is simple and easily manipulatable by users. Each revision (or “changeset” in mercurial’s vocabulary) is of the form revision-number:changeset-identifier (e.g. 3:ff5d7b70a2a9).

Like bzr, branches in hg are typically done by creating separate directories (typically with their own repository). However, it also has named branches for naming branches within a repository, which are somewhat similar to git. (I have been told there are important distinctions between hg named branches and git branches, but I do not fully understand all the details; maybe someone will explain in the comments.)

mercurial has both tags and local tags, with (normal) tags being stored in an .hgtags file that is version controlled, and local tags being stored in a file that is not version controlled nor shared (cloned/pulled/pushed/etc.). Like most other systems, tags in hg are an alias for a specific commit.

The (abbreviated) sha1sum portion of hg revisions (the “changeset identifier”) is unique by design; if you have the same revision in two different repositories, the changeset identifier for both will be the same. The simple number portion of hg revisions (the “revision number”) is not unique. If you have the same revision in two different repositories, they will not necessarily have the same revision number in both.

Picture

             19:c87f92...
                |
             18:650a6f...
               |      \
        15:caf806...   \
         /     |        \
       /       |         \
      /        |          \
13:75cc2c... 14:147c0a... 17:acac44...
      \        /           |
        \     /            |
       12:8f50e6...      16:8147be...
         /    |        /
       /      |      /
9:9b39b2... 11:6e2cde...
    |         |
8:01fa22... 10:1a9d90...
    |    \    |
    |      \  |
5:46508c... 7:b6765c...
    |         |
4:1c4e8d... 6:328638...
       \     /
      3:6627f7b...
          |
      2:754b42...
          |
          |
      1:d1879f...
          |
      0:c962db...

Final notes

Each system uses a different scheme, which have different advantages and disadvantages. Odds are that I am not aware of all the relative merits of these systems yet, though I do know some. Personally, I don’t think any of them are optimal (though I admit that optimality is a somewhat relative term given the inherent trade-offs involved). Unfortunately I’m going off-topic, as I said I wouldn’t be discussing advantages and disadvantages in this post, so I’ll shut my trap here…

This cartoon from left handed toons pretty much sums me up pretty nicely.

A couple weeks ago, I got an e-mail message from an old friend that I went to school with from first grade until high school. She was inviting me to join a social network she had set up using the Ning platform. I signed up and have been spending a little time there catching up with the couple dozen people who have signed up as well.

This is the first time I've ever heard of Ning. I'd be interesting in hearing what some people in-the-know, as far as social networking is concerned, think of them.

In related news, if you're an alumnus of the Granger High School class of 1990 and you have not received an invitation to the class Ning site, drop me a line with your e-mail address and I'll get you invited.

I’ve accepted a position closer to my parents in Southern California which means that unless I want to earn some serious frequent flier miles at my expense (which i don’t), I’m going to be moving.  Unfortunately for me that means that the nerd house is going on the market.  (The whole house is a technology cocoon)  It’s also a Maker house with a sweet workshop - great for tinkering, metal work, wood work, scrap booking, or whatever your “thing” is.  If you or anyone you know is looking for a home in northern Utah county (Pleasant Grove), let me know and I’ll try to hook you up with what I honestly believe is the best house for the money in the area.  I’m also quite motivated.  Seriously, It’s the variable for which I have no solution, so you could probably rob me blind and we would both be happy.

-Peter

Warning: This is essentially a long rant about the built-in help of git, but with specific problems pointed out and some constructive suggestions buried at the very end.

When I was starting on my PhD in mathematics, there was a time I remember where the professor in one of my classes referred to a problem on our homework assignment as “a calculus problem.” Later during the week, the six or so students in the small class were talking about the homework and one of the brighter students (i.e. not me) trepidly asked, “Did he really call that a calculus problem?” It turns out we were all stumped by the problem, and we were surprised–and scared–that the professor utterly trivialized it. We did all eventually solve the problem, and did ultimately agree that it was a generalization of ideas from calculus, but not until after getting a bit of a scare that we were in over our heads in graduate school.

In a similar way, Carl and others have argued that they just don’t see the big user-visible differences in the models offered by git and other VCSes. Many a git user seems to have had trouble understanding why other systems would be marketed as being easier than git. I am a lot slower than most of them, but I eventually figured it out and I do think that git could be just as easy if tweaked appropriately; however, it sure does seem to place every obstacle possible in the way of users discovering that.

This blog post is dedicated to what I believe is the single biggest obstacle in the way of users learning git: its built-in documentation (which doubles as its manpages, or vice-versa). Let me first point out that the git manpages are stellar from the point of view of comprehensiveness, or from the point of view of those writing their own UI for git. However, in this post I will judge these documents based on their friendliness to users who are new to git (which may not have been one of their design goals for those pages, so such judgement may come across as unfair).

Do not layer concepts — make it all or nothing

Imagine taking a computer user who is bright but unfamiliar with unix or common editors associated with unix, and giving them vi (or vim) to run. Also, imagine making them unable to use vi until they understand every feature and capability of it. Without a way to incrementally improve their productivity (better manuals, or a friend to explain things, etc.), most users will either give up or take an extremely long time to become productive. While this analogy is a bit of a stretch, for the most part this is precisely the way the git manpages are structured[1].

I’ll take push and pull as an example. If you take a look at git’s help for push or pull (or fetch), you’ll note that “refspecs” are featured prominently. Embedded in the explanation of refspecs, you’ll find concepts, terms, and other details such as rebasing, octopus, configuration file syntax and effects of such configuration options, fast-forwarding, nonlinear history, repository storage format, implementation details about git’s repository directory layout, local and remote repositories, remote tracking branches, and merge strategies–all inextricably intertwined (or so you’d think on your first 12 readings). refspecs pack a lot of information into a short amount of space, making them very convenient to the expert; but for new users this just places a mountain in front of them getting started. Since push and pull are the methods of collaborating with other users and refspecs are necessary to their functioning, new users often feel stuck.

In a similar way, when I was starting I thought that I would have to understand the index, reflogs, tree-ish’es, internal repository storage format, and a few other arcane things before I’d ever be able to do anything productive with git diff.

Assume that all details are equally useful

This section could likely be combined with the previous one, but I thought it was worth a special mention. It typically comes across as “this document is overloaded with detail”, though the existence of details is not necessarily the problem (you can have a comprehensive document and have it be understandable; take a look at the cvs, svn, or hg books at red-bean.com). The problem with documentation that assumes all details are equally useful (typically a subconscious assumption) is that it makes it extremely hard for the user to get started. git’s commands have boatloads of flags, and with few exceptions there is not much guidance at all about which are more important for just getting started. Users have to sift through it all and try to figure it out themselves.

The manpages also often specify details before concepts, erring as far as possible on the side of precision. For example, take the opening sentence of the description of the git diff command: “Show changes between two trees, a tree and the working tree, a tree and the index file, or the index file and the working tree.” After reading this, the user can only respond with comments like: “What’s the index file?” (or maybe even “is the ‘index file’ something slightly different than the ‘index’ I read about elsewhere, perhaps just a subset of it or how it behaves?”), “The working tree isn’t a tree?!?”, or, perhaps most likely, “Huh, what?” The git diff help tries, starting from the beginning, to introduce as many concepts as possible (without explanations) and just befuddles the user. For another example, take a look at the description of git checkout. For someone familiar with git, they won’t see anything wrong. In fact, I don’t see anything hard there anymore. However, do you know how many dozen times I tried to parse those two short paragraphs in attempting to learn git? I don’t — I long since lost count.

Require understanding of deeply nested commands

The documentation in git often defers explanation by referring to other (low-level) commands, in a way that makes users feel they have to understand all the low-level commands too.

Here’s an example. From the git push documentation:

The <src> side can be an arbitrary “SHA1 expression” that can be used as an argument to git-cat-file -t.

From the git-cat-file documentation, explaining the -t option:

Instead of the content, show the object type identified by <object>.

Finding the definition of <object> on the git-cat-file page:

The name of the object to show. For a more complete list of ways to spell object names, see “SPECIFYING REVISIONS” section in git-rev-parse

(More complete?!? There was no explanation here at all!) And for kicks, the very beginning of the SPECIFYING REVISIONS section of git-rev-parse:

A revision parameter typically, but not necessarily, names a commit object. They use what is called an extended SHA1 syntax. Here are various ways to spell object names. The ones listed near the end of this list are to name trees and blobs contained in a commit.

If the user gets to this point they are like to ask whether the object from the git-cat-file page refers to a commit object, a different kind of object, or a more general case that includes both. Also, they may ask, if it’s just a commit object, then part of the ensuing explanation is going to be for something else other than what we are interested in…but are we going to be able to differentiate which parts of the explanation that is?

Here are some other examples, all of them taken from the the first paragraph or two of the descriptions of each command. From git-checkout: “It updates the named paths in the working tree from the index file (i.e. it runs git-checkout-index -f -u)” (one has to love following up an unintelligible (to new users) explanation by referring to a lower-level command that assumes the user knows even more). From git-bisect: “This command uses git-rev-list –bisect option to drive the binary search…“. From git-log: “The command takes options applicable to the git-rev-list command to control what is shown and how, and options applicable to the git-diff-tree commands to control how the changes each commit introduce[d] are shown.”

Prefer implementational details to user-level concepts

Just one example I know of immediately…open up the git-checkout manpage and you’ll see a section titled “Detached Head”; it’s completely meaningless to new users. Trying to describe the concepts (”working with no active branch”, “working on an unnamed branch”?) would be much better. I think they’ve tried to stomp out issues in this category, so there are not as many as there used to be.

Make your terminology inconsistent

I’ll jump straight to a quick example from git: You put things in the “index” with “add” which is known as “staging”, you remove them with “reset” (or “rm –cached” if it’s the initial commit), you use flags like “–cached” to refer to index stuff in some places, use “HEAD” to avoid it (specifically in diff), and sometimes the flags related to it are “soft” vs “mixed” (which also need to be juggled with “hard” in git-reset). While users eventually learn all the synonyms and related terminology, it really slows learning down.

Use inconsistent conventions

The git manpages do not use consistent conventions. For example, taking a look at the synopsis lines you’ll see “<filepattern>” on git-add, “file” on git-annotate, and “-pNUM” on git-apply; why are non-literal items denoted with angle brackets in one case, uppercase in another, and no special markings in a third case? On the git-push manpage alone, you’ll see “–receive-pack=<git-receive-pack>” and also “–repo=all”; angle brackets in one case, and plain text in another? On the git-diff manpage you’ll see “<commit>{0,2}” and also “<path>…”, while on git-bundle you’ll see “refname…”, and on git-checkout-index you’ll see “[<file>]*”; so denoting more than one item is done with a variety of regexes, an ellipsis combined with angle brackets, or just a plain ellipsis.

The more ways you have of referring to things, the more likely users are to confuse them. One that bit me particularly hard was the “<commit>{0,2}” in the git-diff synopsis. Now, I use regular expressions daily and my usage of them spans emacs, grep, sed, perl, python, and probably other places I’m forgetting…but it still did not occur to me that this syntax in this context happened to be a regex. It looked somewhat similar to reflog notation in git, and I launched into all sorts of reading up on reflogs (and the documentation it depended on) trying to understand this detail. I also read the online tutorial, parts of the git user manual, blog sites, and even mailing list archives. I gave up and moved on, but never felt comfortable that I understood things…until months later when it dawned on me that this was a simple regex.

(And no, I don’t care that my post whining about inconsitent conventions is itself riddled with inconsistent conventions.)

What can be done to fix this?

Well…some people have fled to hg and bzr to avoid these problems in git. As far as built-in documentation, both of them have done well and have very nice documentation for new users; bzr’s is particularly well polished. Adopting one of those systems is a reasonable choice which I can’t fault people for making.

Now, I dislike reaming a project without mentioning something good or at least providing constructive feedback. In addition to spelling out some specific problems throughout this post, I came up with some constructive ideas for improvement: Easy GIT, a brainstorming session about making git more user-friendly, in the form of a usable demonstration. It also doubles as a transition tool, helping users switch from other systems (particularly svn). I don’t know if anyone wants to adopt any of my ideas or documentation, but it’s out there for people to evaluate (even if not yet complete).

I will also note that Govind Salinas had a similar idea and created pyrite (and did so before I started eg, though I didn’t learn of it until after I was using eg daily). So it seems that I am not the only one thinking along these lines…

Talk about a frustrating experience!

A couple weeks ago, I had to go to a customer's office to do some network troubleshooting work. On my way, I received two text messages, in quick succession, on my phone (Palm Treo 700p w/ Sprint). I began to go to the text messages to see what they were and the phone "rebooted."

Now, this isn't a regular thing, but it's not unheard of for a Treo to reset. But this was no regular reset. My phone went into a nasty reboot loop-- never quite coming back up to normal operation. It would get to a certain point in the boot-up process and then reset again.

I tried just about everything I could think of (short of doing a hard reset that wipes all your data from memory) and nothing helped. I ended up taking my phone to the Sprint repair facility later that day. I went back in an hour or so and got the phone back to find they had done what I didn't do: a hard reset. All my data was gone. I had it backed up, but it's still a pain to restore everything.

It wasn't long before I realized the Sprint repair center didn't just do a hard reset on my phone. They also upgraded the firmware and the new firmware is abundant with annoying bugs that drive me nuts!

Several basic functions that had no issues before now have glaring issues. Here are some of the things I am having to deal with:

• Favorites button Quick Key in Phone application does not work. This is, essentially, a speed-dial function that lets you assign a keyboard key to a favorite contact from your address book. By holding down the assigned key, that person's number is dialed. Worked fine before. Doesn't do anything now. This sucks.
• Call list population is very undependable. I might get an alert that I missed 2 calls, but when I go to my call list to see who those two calls were front, they aren't on the list. If I make a call using a favorites button, the outgoing call isn't recorded in the call list.
• Ring tone and alert sounds "fade in." This seems like a "volume escalation" feature, but I've double and triple checked (and then some) that the escalate volume checkbox in the Sound preferences is not checked.
• The On Demand application freezes the Treo. I used to use the On Demand application frequently to check weather reports and read News Of The Weird news articles. Now the only thing On Demand is good for is freezing up the device. The only way to remedy the problem is to do a soft reset or remove the battery.
• Deactivating the keyguard to delete or view messages is difficult. The Treo will act like the keyguard is active, but the normal "Keyguard: Press Center button to unlock" message does not display on the screen. Very frustrating.

Has anyone else seen these problems with their Treo device?

Should I take my phone back to the repair center or will they just do another hard reset and tell me that's all they can do?

Late one night this week…

Googleearth gallery
   > 2007 Tour de France route
      > Noticed amazing Carcassonne which the route passed by
         > Jump to Wikipedia to learn about Carcassonne
            > A thought leads to Labyrinth the book
               > Which makes me think of the (unrelated) Labyrinth movie
                  > Learn that the fancy manipulation of the ball is called Contact Juggling
                     > Search Youtube for Contact Juggling
                        > Amazing:

Late one night this week…

Googleearth gallery
   > 2007 Tour de France route
      > Noticed amazing Carcassonne which the route passed by
         > Jump to Wikipedia to learn about Carcassonne
            > A thought leads to Labyrinth the book
               > Which makes me think of the (unrelated)Labyrinth movie
                  > Learn that the fancy manipulation of the ball is called Contact Juggling
                     > Search Youtube for Contact Juggling
                        > Amazing:

Enlarge image

So, I was really upset a month ago when one of my headlights in my Jeep Cherokee went out. It’s not the first time and that’s actually the reason why I was upset. I just replaced both of them one year ago and again, a year before that! For some reason I’ve felt that headlights should last longer than one year (apparently, misguided in these perceptions). They seem that they are not made of tissue and therefore one should expect them to not function like a short term, disposable item.

I know, I should actually be putting less faith in the auto industry in America. If they make things that actually last, they would not be selling any new vehicles. But a year? C’mon!

Last night, after spending an evening watching videos with Debbie I said goodbye, left the doorstep, walked to the car which was parked out on the street. It was very dark, no moon was out. Immediately after starting the car and pulling the round knob to turn on the headlight, *plink*, my other last-of-a-redundant-system headlight burnt out.

I spent the next hour traveling at about 15mph on back roads with my hazard lights blinking. They provided me with barely enough light to see the lines painted on the edge of the road and enough warning for other cars to stay away from me.

My theory is that because I bought the super bright Sylvania SilverStar headlights the last two times, which boast “increased downroad viewing up to 25%, increased sideroad viewing and up to 20% brighter, whiter light”, they actually burn hotter and have a shorter life span. In order to test this theory, today I purchased Sylvania XtraVision High Performance Halogen lights which do not burn as bright. I am hoping that their lower brightness is due to lower temp of the element and will result in increased lifetime.

My 1996 Jeep Cherokee up American Fork Canyon, UT

It has been a long time since my last blog post on VCSes. I am getting back into the swing of things and will be making a few more posts. Besides, Olav doesn’t have enough to do and he wants more of my long rambling posts to digest.

The VCS world is becoming more and more interesting, even if it is also more and more frustrating. I’ll briefly point out a few things I have seen happen in the last few months that look cool, making this VCS post a little bit different than my others.

cvs

Stinking stingy CVS refuses to die…it seems to prefer slowly petrifying over the years or something. It was great a number of years ago, but there’s just so many better tools these days. However, there does appear to be a light at the end of the tunnel. The last place I am forced to use CVS (work) will finally be switching (to subversion) in a couple months. Woohoo!

svn

I haven’t seen any big changes in subversion itself (only one bug fix release has occurred). However, it looks like they are making progress on finally implementing useful merge functionality. This is interesting on a number of levels: (1) this lack of functionality was one of the big reasons subversion sometimes looks like a (very well polished) antique rather than a modern system; will the incorporation of this feature be enough to stave off some of the ongoing defections to other systems?, (2) this may be interesting for those using bzr-svn, hgsvn, or git-svn — are users of such systems going to find it even easier to use their preferred tool?, (3) the main reason svn’s dozen or so ugly renaming bugs (some of which essentially result in corrupted data) have gone almost completely unnoticed is that most are only triggered in merge operations and subversion’s current merge functionality is so primitive and problematic that hardly anyone uses it. Further, svn’s roadmap clearly lists fixing the rename problems in a different release, after the merge fixes are included. Will the extra visibility that one problem will receive due to a different problem being fixed make subversion look more problematic or less? This will be fun to watch.

On a separate note, it is interesting to see that subversion developers are considering adopting some features of distributed VCSes — sometime in the distant future. An easy to miss but interesting nugget from that email is the following:

Fortunately, we’ve pretty much agreed, IIRC, that we’re willing to punt on subdirectory detachability in working copies in order to get performance improvements.

I have often seen svn and cvs proponents argue that as one of the big advantages to those systems, yet it looks like the svn developers are willing to drop it. Very interesting indeed.

hg

Mercurial version 0.9.5 was released since I did my last round of VCS blog posts and it is on my system. hg-0.9.5 has quite a number of improvements; the one that particularly caught my eye was support for subversion as a source SCM in its convert functionality. When I first looked at mercurial, they suggested people use git-svn and then convert from git to hg. To me, that seemed to push people to just use git. It looks like this has changed.

I have often found it somewhat strange that mercurial doesn’t have more active vocal proponents. Usually one hears from the git or bzr proponents, but not so much from mercurial. Yet it has always had many of the advantages of both (and, in some ways seems to have the most svn-like UI, and would seem a more natural transition for svn converts). I guess it’s a case where having most of the advantages or capabilities of other systems (even multiple other systems) yet not clearly standing out in one particular area will rob you of the active advocates that you could otherwise have. Of course, maybe it’s like the linuxjournal reader’s choice awards phenomenon too; the noise or results that others hear may only be indicative of a certain small subset of the community.

bzr

A lot has happened in the Bazaar world. They had their big 1.0 release in mid-December and are now up to bzr-1.2. They have made impressive gains in performance, particularly with their adoption of the pack idea from git, and it appears they have at long last caught up to the leaders in the field in this area.

Near the end of last year, I corresponded about early versions of the “Main Competitors” writeups of the Why Choose Bazaar page, with Ian Clatworthy. I pointed out some advantages of bzr he hadn’t included, mentioned how some bold claims had no accompanying proof, and pointed out some places where he seemed to be unaware of capabilities of other systems or where I disagreed with some of his claims. The final versions seem to have mixed results; part of my feedback was addressed (and more was addressed in follow-ups), but other parts were not. I’m particularly puzzled by the reticence to investigate the existing capabilities of other systems and the willingness to claim features of bzr as advantages without determining whether they are actually unique. Regardless, though, while one does need to individually verify or discard each claim, the writeups are fairly impressive. I probably need to get back in touch with Ian again.

git

I’m so annoyed with Carl right now. He was the one who introduced me to git a number of years ago, and showed me some really cool things about it. I dropped it almost immediately at the time because it was way too hard to use. But, I’ve always been interested in it and made occasional attempts to tame the dragon ever since.

As many are aware, git has made huge strides towards usability in the 1.5 series, and has recently introduced automatic repacking in git-1.5.4. Because of all this work, I made diligent attempts to understand it over the last couple months. In doing so, I finally had the necessary epiphanies to feel I understand it. It turns out I was able to use it productively long before the uncomfortable feeling of I-don’t-really-understand-this-thing was finally expelled. The result? I found that there are several features of git not present in other systems that I am absolutely addicted to, but looking back on the journey I can’t say that it would be worth the effort for others to follow the same path, despite these awesome features. The thing is still too bloody hard to figure out.

One of my desires for my blog posts series was to point out how horrible the git manpages (i.e. the built in help system for git) are for new users, but I felt uncomfortable doing so until I actually understood them. I was not able to understand even the synopsis of the git-diff manpage until a couple weeks ago. And I tried. Hard. Over days, weeks, and months. I read up on reflogs, the index, git’s storage format, the git tutorial and all kinds of other documentation. I feel stupid now, because I was just missing something simple and now seemingly obvious. But from what I can tell, little should-be-obvious-but-aren’t things like this are blocking lots of people from being able to use git.

Long story short: git has become far more usable…mere mortals can actually figure the system out (a big change from earlier versions) if they have an unusually large level of patience and motivation. git has some really awesome features, but I just can’t recommend it to others in its current state.

My sons have fallen in love with PC Gaming.   (They play Wii and XBox, but not with the same obsession as PC based games.) They used to just play the flash based online games from websites they would visit (cartoonnetwork.com, nickjr.com, etc.)  Then their uncles introduced them to StarCraft and WarCraft.  And they are hooked.  One of the nice things is that I have been able to recycle some of my old games (RollerCoaster Tycoon, Sim City 3000, Nox).  It has been fun seeing them explore these new virtual worlds.  Taylor is super excited about the upcoming release of StarCraft 2 and dreams of one day working at Blizzard.  Andrew wants to be a game designer.  Everyother day they ask me how to write programs.  These conversations lead to discussions on basic algebra, physics and even Object Oriented Programing.  (Anyone interested in providing pre-release games for them to test or review?)

Today I thought that it would be fun to install one or two games on my machine for those times that I need at little escape.  Big mistake.  I installed a First Person Shooter (Return to Castle Wolfenstein) and within 5 minutes knew why I stopped playing.  I loved first person shooters.  I used to play network games with the guys I worked with at the Courts.  It was a great break from work and a fun team building exercise.  From time to time I would get a little motion sick.  But today I got very motion sick.  I am still suffering from a huge headache playing the game brought on.  The quick jolting motion just seemed to much for me.  Man I am getting old.  Maybe if I take some motion sickness pills next time…..

Today, I went grocery shopping at Albertson’s. I know that they use cards in order for you to save money. Actually, all those cards are good for is tracking your spending habits, and targeting advertisements to your home, and solicitation calls to your phone number. So, for the past few years, I’ve been using 867-5309 for the phone number when I reach the checkout (I forgot my card). However, as of the past couple months, that phone number no longer works, and I can’t save money. So, when I reached the checkout, the lady asked me for my phone number or my savings card. I told her I didn’t have one. So, she preceded to hand me a form to fill out while she scanned my groceries.

Now, at this point, I’m laughing inside. The first thing I think of is “Do they honestly expect people to not beat the system here? Seriously.” So, with that in mind, I filled out the form:

First Name: John
Last Name: Dough
Address: 108 Church St.
City: Beverly Hills    State: CA    Zip: 90210
Email: <none>
Phone (911) 867-5309

I handed her the form, she looked it over, and asked “John Doe?!”.
“It’s pronouced ‘dow’. I get that all the time. Also, I’m just visiting. Is that okay, being from California, or do I have to fill it out there?”
“Yes”, she said. “That’s fine.” And she gave me my savings cards, handed me my receipt, and we were out the door.

John Doe would just be too obvious. I have to shake it up a little bit. Funny she didn’t catch the area code, or the phone number. 108 Church St. is an apartment I used to occupy when living in Toronto, Canada. I’m sure every city has a Church St. so it’s easily convincing.

And there it is. I got my savings without handing out a bit of my identity. If they cancel the card, no biggie. I figure every time I walk into that grocery store, I’ll just fill out a new one with unique bogus info. I’m out to show Albertson’s the silliness of making shoppers fill out those forms to get a “savings card”. Maybe I should start with U.S. Presidents, work my way through each of them, then move through Biblical Prophets. I could have some real fun here. And, if they ever catch me on falsifying the information, I’ll just show them my collection of savings cards, and ask them to pick which one would work.

Beating the system, and it’s all too easy.

When my family plays games, there is always someone that is ahead.  Often it is in everyone’s best interest to try to keep that person from winning.  That way the game goes on longer, and the others improve their chances of winning.  For the second place person, that can be a great advantage because they can gain critical ground while everyone is pulling down on the player in first place.

In West Virginia, that happened today.  West Virginia uses a caucus system where supporters of each candidate get together and figure out who is going to be the candidate recommended at the convention.  Many other states use a primary election and then dole out the delegates either by district or in a winner take all electoral contest.  In this case, McCain knew that he wasn’t going to win West Virginia, and can see what we all do, that Mike Huckabee is not a viable candidate.  To hold Mitt back, he instructed his delegates at the caucus to vote for Mike Huckabee.  Remember these are people who chose him – not Mike Huckabee to begin with.

Why does that matter?  It matters because McCain was only up by about 20 delegates, and the 18 from West Virginia would have helped to close the gap.  The interesting part is that 47% of the delegates were for Mitt.  I suspect that had Mike Huckabee dropped out (like he should have weeks ago) , Mitt would have easily picked up 3% of the delegates.  I think that he would have handily trounced John McCain. Through manipulation of the system, John McCain denied the people of West Virginia their voice, and effectively negated their vote.

Way to go John – That’s exactly the sort of disregard for the American people, to further your agenda, which I was expecting from you.

-Peter

Now that the primaries are underway, I’m going to need to vent.  It’s been four years since I’ve needed to vent politically, so this space has been relatively free of my rants.  Brace yourself, because the season has started and I can’t hold back.

-Peter

My flight out of Islip was delayed for weather.  Once we hit the gate in Atlanta, I had two minutes before my connecting flight to Salt Lake was to leave.  Needless to say, I didn’t quite make it.  I hate the Atlanta Airport.  I always have.  I have yet to have a connection in Atlanta where first and second legs were both in the same terminal. (Try running with two kids in a double strolle, with all their carry-on, plus your own across 2 concourses.  Not fun.)

So they put me up in a Comfort Suites.  Not the nicest place, but it is a bed.  Up at 5:30 to get my shuttle back to the airport.  Now waiting for seat confirmation.  I want to be on this flight.  I am ready to be home.  It is funny, I can complain about the noise the kids make…all the time….at home.  But these trips bring home to me that I wouldn’t want it any other way.  The quiet of the hotel gets to me.  I love being able to sit down and have one of the kids to talk to.  I love in the morning have Olivia come into my office, give me a hug, and ask for breakfast. I love talking computer games with with boys, or playing Go with Taylor. I love having Adrienne next to me.  I miss her the most.  It will be good to be back home.

I’ve seen this photo floating around, and it is of a Martin Luther King Jr. rally in Texas.  For whatever reason, a few of the signs were mis-spelled.  I’ve heard some suggestions as to how this happened, none of them very nice, but I think the point here is that a mistake can mask your message.  Snopes chased down the story, and the local television station confirmed that the photo was authentic, however the news director, Richard Longoria, pointed out:

It’s obvious two signs were misspelled, bunches of others weren’t. It’s such a shame that the person who put it on the web didn’t put the entire story, which showed members of the Black American community and others in Corpus Christi respectfully honoring the life and memory of an American hero, Martin Luther King.

In school, we spent a lot of time working on presentation skills and removing the distractions that can take away from the message.  The next time that you write a note, update your web site, talk on the phone, etc.  prepare yourself, prepare your message, and prepare your surroundings.  If it’s a big thing, run it by a couple of people.  Your friends will help you. (If you don’t have friends that will help, find new friends.)  As my mom used to say, it’s not what you say, it’s how you say it.

-Peter

An anonymous coward commented that he (or she) found a dvd writer for $400.  That’s  getting really close to where I want  to be… now if they would just allow it to play through something other than HDMI so that I could watch it on my (very old) component HDTV.

• http://www.meritline.com/lg-ggw-h20l-lightscribe-6x-blu-ray-3x-hd-sata-drive.html

On a plane, to New York, via Atlanta. On the way in, they were rebooting the in-flight media center. I was happy to see them running Linux. I tried to grab a picture, but it was at the end of the boot. This one of those rare conditions you want a reboot to grab a picture ;)

One of my primary goals in life is to teach my kids to be eventually good, productive, and self-reliant adults.  One area of life-skills that my wife and I are focused on in teaching our children, is teaching them the principle of work: how to work, the value of work, to take ownership over their responsibilities, and to be proud of their accomplishments, and to learn to work as a team and family.  One way we are reinforcing the principle of work is through the use of effective Visual Management.

Visual Management has the following purposes:

• Visual Management provides instruction
• Visual Management conveys information
• Visual Management provides immediate feedback
• Visual Management quickly exposes abnormalities in a process or work area
• Visual Management quickly conveys progress or lack thereof

My wife created a wonderful job chart, which you find below:

This Job Chart is in our kitchen, where there is frequent foot traffic and where our family spends most of our time.  There are a few items I’d like to note:

• My kid’s ages are (from top-to-bottom): 9,8,7,3,3
• The Kid’s Heads: Visually representing each child with their face is much more effective than using their names.  The Kid’s Heads are laminated and have Velcro on the back, to facilitate ease-of-job-rotation.  This approach is also very environmentally friendly, since the pictures and the board are laminated — there’s no waste.
• We have jobs over 6 days — Monday through Saturday and the jobs are fixed, but the heads are rotateable.  The younger boys (the twins) rotate with each other at the bottom 2 rows — those jobs are designed for their age and ability.  The top-3 rows contain jobs for the older kids and those jobs are designed for their age and ability. 
• Every Sunday, we rotate the heads for the upcoming week.

Deploying The Program

When my wife and I first met about this during our end-of-the-year meeting, we were quite excited and saw a lot of promise in helping our kids learn the value of work. 

Plan:

• My wife and I first met together to discuss our goals for the year 2008 and how we could accomplish those goals and the expected outcomes at the end of 2008.  We then brainstormed all the jobs that needed to get done in our household on a daily and weekly basis.  We, then, categorized the jobs based on age and abilities of our children.  For example, we had to be sensitive to the child’s height or the size of their hand and matched the work to their physical and mental abilities.

Do:

• We gathered the family together and explained our goals and vision for 2008 as it relates to the principle of work.  I explained to the kids how important work is and I also shared my personal stories about the principle of work.  I showed encouragement and excitement to the kids and that learning the principle of work will help them "feel big" and not little anymore. 
• My wife and I explained our expectations  and discussed rewards and consequences and also the start-date.
• We provided training on some jobs that the kids were not familiar with.  This is especially true for my twins, as this is their first foray into a more structured world of chores and work.

Check:

• Every night during our family prayer, we discuss how the day went and how their jobs are going. 
• The 3 older kids have other diversions also like homework, piano, playing the Wii, and hanging out with friends.  We want to make sure that they can still do other stuff and not be too burdened by any single item. 

Act:

• Depending on the findings during our daily discussions, then we adjust.  For some kids, they might have to double-up on work the next day so they can do homework.  We do not want to Batch work like that, but that is an option until further discussions can be had on whether there might be too much work.

Respect For The Kids

The Job Chart conveys information so that Mom and Dad don’t have to.  When Mom or Dad have to convey the information, it usually ends-up as nagging.  That approach is irritating, disrespectful, and polarizes people.  We want, instead, to teach self-reliance, demonstrate our trust in the kids, and help them grow in their own terms, but with our loving guidance.

How Can This Be Improved?

What we haven’t done yet is to provide Standard Work Cards for each job, showing in text how to do the job and also a picture of what a "good job" looks like.  One example might be to show a side-by-side comparison of a dirty toilet next to a clean toilet, with a marker on the clean toilet, indicating to the reader what the ideal finished good should look like. 

Can you think of other ways could we improve?

Just So You Know

Yes, I have jobs also.  My jobs are usually of the "Ask Mom" variety.  This means that I get all the hard work, inconvenient errands, and other random but necessary to-do items.  And, yes: my wife is pretty much the best.

+++++

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This