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).

We’ve been using lftp for years here. It’s stable and has a volume of options. I just found out today that lftp has an option to set the order in which files are uploaded if you are using the mirror command. You can set it like so:

set mirror:order ‘*.jpg *.gif *.png *.js *.css * */’

This will send first jpg, then gif, then png files etc. This is very handy if you are mirroring an entire website and you want the images to go live before the html does.

Nathaniel Talbott (from Terralien) gave a great talk on a number of interesting hacks in ruby. There was one in particular that I want to focus on here: gitjour. Gitjour is a fun and novel app that will discover git repositories on a local network via Bonjour. It’s hardly going to change your life, but it is fantastic for ad-hoc sharing of code on a local network and quick collaboration without too much ceremony, e.g. at a conference, or ruby users group, etc.

It’s a fun tool and you should definitely try it out.

While I’m on the topic of git, I’d like to point out that the community at RailsConf was completely sold on using git and using GitHub in particular. Even though I am a git-switcher myself, it was really surprising to see that almost the whole community had either switched or was planning on switching.

GitHub did a great job marketing at the conference. They gave out free t-shirts that said “Fork You” on the front. On the back the shirt said “http://github.com/________” and you were expected to take a sharpee and write your GitHub user name so that others could see your projects (my projects are here). The successful result was that at nearly every session or meal someone would use the phrase “I think I’ll put this code up on GitHub”.

UPDATE: I’ve found a picture of the shirt here

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!