X-Combinator

I really dislike getting screen-shots in the format of power-point files. Thankfully, 10.5’s Quick Look can help me preview power-point files. What I needed was a way to have Firefox automatically Quick Look all power-point files that I downloaded. Here’s how to do it:

Open up Script Editor and paste this:

on open filelist
	repeat with i in filelist
		do shell script "qlmanage -p '" & POSIX path of i & "' >& /dev/null &"
	end repeat
end open

File > Save As…. Choose “Application” and save it somewhere it won’t move. I choose /Applications/ql.app.

Now simply choose ql.app next time you download a power-point file or set it up in Firefox’s Preferences > Applications.

qlmanage is the command-line tool to open files in Quick Look. By using AppleScript you are able to create this thin “application” that Firefox will trust and give a downloaded file (As opposed to a shell script, which Firefox will not let you choose as a file handler).

Since my upgrade to OS X 10.5 I have been having a terrible time getting colors to work with git.

Originally I was using OS X 10.5.4, git version 1.5.3.1, and iTerm or Terminal.app. $TERM=xterm or xterm-color. I have color with PS1, ls, vim and most git tasks. However, git diff (or git show) always screws up the diff by showing the ESC[ characters instead of colors. For instance:

  [nathan@nate ~/s3]$ git show 67d254ec17f
  ESC[33mcommit 67d254ec17fdc507765ddee1feb2a14e5896e79fESC[m

I searched and searched wasn’t able to figure out how to fix this. It was suggested on the github forum that I upgrade to git 1.5.6.4. Unfortunately not only did it not fix the color in git diff, it broke the color in git status which was working previously.

After about a week of poking around on and off I discovered that the problem was not git, but my GIT_PAGER which is more. If I tried GIT_PAGER=cat git-diff then the color output just fine. less and more use the same environment variable LESS (man less for details). And less was outputting the colors as raw escape codes.

man less shows that the option -R is defined as follows:

       -R or --RAW-CONTROL-CHARS
              Like  -r,  but  only  ANSI "color" escape
              sequences are output in "raw" form.

That would do it.

After perusing the man page for a while I settled on adding this to my
~/.profile:

  export LESS="-erX"

At the end of the day, this tip is really about less and how it interprets colors and probably has little to do with git. Even so, I only found this odd behavior while using git. Hopefully this post will help someone who is having similar issues.

As a side note, below is an example of how to configure your colors for git-diff and other commands.

[user]
    name = Your Name
    email = y...@yours.com
[color]
    branch = auto
    status = auto
    diff = auto
[color "diff"]
    meta = yellow
    frag = cyan
    old = red
    new = green
[color "branch"]
    current = yellow reverse
    local = yellow
    remote = green
[color "status"]
    added = yellow
    changed = green
    untracked = cyan
[alias]
    st = status
    ci = commit
    co = checkout
    br = branch

RailsConf was fantastic. A huge thank-you goes out to everyone who took the time to create presentations and sessions. Creating them is a lot of work and I commend you for preparing them. One common negative theme, however, was this: Live coding isn’t efficient and it is bug-prone. It doesn’t matter who you are or how good you are, you’re not going to be maximally efficient presenting if you are performing live coding. Even if you practice, when you get up on stage you will make typos and it will not run exactly as planned. If you’re not convinced, let me give you a list of people who did live coding this weekend and made typos or mistakes:

• Ola Bini - jruby core developer
• Jeremy Kemper - 37signals
• Ezra Zygmuntowicz - EngineYard

Each of these guys are Ruby-Rock-Stars and they are way smarter than I am. The content of what they presented was, in every case, phenomenal. They are some of the best programmers in our community and if they can’t give a presentation without typos and mistakes I can almost guarantee that I (you) won’t be able to either. When you get in front of 300 people, start typing, start talking, and realize you’re under the pressure of time (and the crowd) it changes your ability to focus on any one task and it is very hard to not make mistakes. My theory is that one can present a live-like demonstration with no loss of effectiveness.

The most obvious way to do a live-like demonstration is by recording a screencast. You could also use AppleScript or library like castanaut (if you are on a mac). The app I’d like to recommend today is ttyrec . It’s a great little command-line app (it compiles flawlessly on my OS X 10.4) and it records the output of a shell session and can play it back like you are typing in real time. I see two major benefits to this:

• You can’t make mistakes. It’s recorded and it’s storing the output all into a text file. This means that if the network fritzes out when you’re on stage it doesn’t matter. Network outages, ill-timed bugs, etc. become irrelevant because the commands are not actually run at playback time (the stderr/stdout stream is saved into a text file).
• You can talk while you’re playing the demo. They do this in TV all the time (think Friends). In a scene where actors play video games they don’t actually play the game and act at the same time. The video games are recorded so the actor can focus on acting. When your computer is playing-back the work you’ve prepared before hand you can focus on talking while the “typing” is happening on the screen. You don’t have to do the mental context-switching of talking and typing simultaneously which causes mistakes that cost you (and maybe more importantly, your audience) time.

You may say “Well, I don’t want to do a recording, I want my demo to be live”. Here’s my view on that: Most people don’t care if your demo is actually live. When you’re on stage and what you’re showing is prepared it’s assumed to be in the perfect environment because you’ve been testing and developing in that exact environment. Even if your demo is truly live it still seems “contrived” in that we, the viewer, can never actually see all the pre-work, installing, compiling, back end etc. that was prepared behind the scenes. As Josh Susser pointed out: “keep in mind Lansford’s Corollary to Clarke’s Third Law: ‘Any sufficiently advanced technology is indistinguishable from a rigged demo.’”

I believe that recording your shell with ttyrec or similar is exactly as effective as a live demo. If I, as a listener, am interested in your project I’ll be the same amount of convinced to download/try/buy even if your demo is recorded. In fact, I’ll be a lot more convinced to try it out if you play something recorded that runs perfectly as opposed to a system that is so complicated or buggy that even the author is having problems using it.

So please record your “live coding” before hand. Your audience will thank you, you’ll avoid embarrassment, and you’ll be more effective for it

UPDATE I removed Yehuda Katz from the list of non-recorded presenters. My apologies go out to Yehuda who pointed out that he did record his presentation before-hand.

I want to share a simple tip that I learned from Jim Weirich (author of rake, xml builder, and rubygems) this weekend at RailsConf: You can do pair programming with screen. When I learned about this I asked around and apparently everyone knew about this already, but I had never done it. Here’s how you can do it too:

Open up ~/.screenrc add the following lines:

In terminal one start a screen session. Then log in as the same user on terminal two and type screen -x. Now either user can control and see real time what is going on in the tty. It is possible to do this across users, I believe. See your local man page.

They use this in combination with audio/video chat (Skype or iChat). This way they can see facial expressions, ask for control of the keyboard etc. Jim and co. have keywords for passing control, I believe they are “drive?” and “release.” The person who wants to take over says “drive?” and they are allowed to use the keyboard iff the other person says “release.”Seems like a simple, but powerful idea.

UPDATE Jim pointed out that they use the terms “tag” and “yield”. Thanks Jim!