sudo port install enchant # you'll need MacPorts 1.8.* for this


Then download the dictionaries from the OpenOffice wiki.

Next, place the files in ~/.enchant like so:

$ tree .enchant/
.enchant/
`-- myspell
    |-- en_US.aff
    `-- en_US.dic

UPDATE
You can also set the path to where you want to keep the dictionaries when you compile enchant by passing the --with-myspell-dir option to configure (or aspell, hspell etc).

Share:

Since I use the command-line twitter gem (by John Nunemaker) I miss out on this feature and find myself using echo and wc to make sure I’m not over the limit.

To fix this problem, I’ve written a small, immediate-feedback utility called tweet. It shows you the number of characters typed so far and colorizes them accordingly.

Screenshots:

warning:

over:

Just download this script and save it as tweet somewhere in your $PATH

Share:

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

Share:

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

Share:

Open up ~/.screenrc add the following lines:

  multiuser on
  acladd nathan # change to your username here

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!

Share: