May 252009

For the Mozilla Labs Design Challenge Summer 2009, I’ve updated the mockup of my design for tabbing in the browser (works only in Firefox). I call the new version “AwesomeTabs” because it integrates tabs into the AwesomeBar. I discuss the virtues and issues of this new design in a video.

Some points I made about my thinking for the original design are still relevant.

BTW, please don’t infer anything about my coding skills from the mockup source. It’s a hack built on top of a hack built on top of a hack.

Mozilla Labs Design Challenge

Posted by Brian Will
May 192009

In chronological order:

  • ATI WinMach64
  • ATI Rage II
  • Voodoo 1
  • Voodoo 3 3000
  • Voodoo 5 (yeah, that was a mistake)
  • Savage 3D (another mistake; think I returned this one)
  • Riva TNT 1
  • Matrox G400
  • Geforce 2
  • Geforce 3
  • Geforce 4
  • Radeon 9800 Pro
  • Radeon X800 XT
  • GeForce 6700
  • GeForce 6800 (a warranty replacement for the cooked-itself-to-death 6700)
  • GeForce 7800
  • GeForce 8800
  • Radeon 4850

That’s 18 cards in about 15 years. I justified this shameful consumption by usually pawning my current card off on a family member as an excuse to get an upgrade.

The cards that made me the most happy were the Voodoo 1, the TNT, the GeForce 2, the 9800 Pro, and my current 4850. The 4850 actually seems to have cooked away its thermal paste or something and now runs really hot under load—often over 100 degrees Celsius! Shockingly, I haven’t seen any stability or artifact issues despite this, so I’m going to hold off on replacing it until I really have to.

Posted by Brian Will
Apr 192009

I’ve created an hour long introduction video to Clojure, a new dialect of Lisp.

I’ve also decided to leave unfinished my implementation of Pigeon, my pedagogic programming language, even though it would take a trivial amount of work to complete. I now think that it’s not really important for students to actually run Pigeon code; in fact, I think it best to discourage students from writing anything beyond a trivial amount of code in Pigeon lest they waste time rather than just moving on to later material.

Instead, my focus now is on creating a course of videos for total newbs to programming, totaling about 10 hours and running in this sequence:

  • A first language (a run through of Pigeon)
  • Numbers (how numbers are represented as bits)
  • Text and images (how they are represented as bits)
  • The system (hardware and OS basics)
  • Language and tools survey
  • Javascript (sans browser)
  • The internet and the web
  • HTML / CSS / Javascript (in browser)
  • The command line and Unix environment
  • C
  • Data structures and algorithms
  • OOP
  • Java
  • Encryption, security, and compression
  • GUI Toolkits (Swing?)
  • Version control
  • Databases

I’m processing the audio and video for the first two, but that leaves a lot of work as I only have sketches of the remaining parts.

Posted by Brian Will
Mar 262009

Of all the introductions to git I’ve seen, this one is by far the clearest. It focuses on the the essential concepts while working in just the right amount of practical how-to.

Posted by Brian Will
Mar 262009

Keep your filthy mitts off Michele Bachmann’s urine jars.

Posted by Brian Will
Feb 232009

That’s how a veiled threat is usually phrased, isn’t it?

Posted by Brian Will
Feb 202009

A lot of screencasts suck, and it’s quite apparent why: the typical sucky screencast is thoughtlessly produced in about the same amount of time as it takes to watch it. If you want to produce a decent screencast, you should expect the production-time-to-viewing-time ratio to be more like 20 to 1 rather than 1 to 1. (I arrive at the figure 20 based on the fact that screencasts I’ve produced in the past with a ~10 to 1 ratio still sucked quite badly. I suspect, however, that the correct figure is closer to 30.)

Anyway, to produce decent screencasts, I’ve settled upon a quite involved process:

The content

  1. First, create slides. If your screencast really requires full-motion video, we’ll insert that later. For now, just use the slides as a kind of outline or guide, even if they aren’t going to appear on screen in the end. For presentations, I’ve gotten accustomed to PowerPoint 2007, as OpenOffice Impress is just too clumsy, and the presentations that Impress produces are much harder to make look decent.
  2. Second, record your narration. If you’ve written out everything, try improvising with the words a bit to help give the illusion that what you’re saying is extemporaneous. If you’re just making it up as you go along, that’s fine and in fact the way I do it, but understand that you should record in short intervals (~15-30 seconds) with as many retakes as it requires to get it right. Do not expect to deliver even just a few minutes of talk off the top of your head in one take. If you’re doing it right, working without a script goes quite slow. Each minute of narration I’ve produced this way has taken about 5 to 10 minutes of recording.
  3. Third, edit your narration. If you worked without a script, you’ll likely have many flubs and odd pauses to remove, even if you properly did retakes. You’ll also likely need to add appropriate breathing space between topics. Even if your performance is perfect, you still probably need to normalize and compress to help even out variances in volume, and you may want to try noise reduction (just don’t use too much because you’ll then end up sounding robotic).
  4. Fourth, use desktop recording software to record the slides. I’ve found the automatic slide timing in PowerPoint too clumsy to match the slides to the narration, so I just click through the slides myself while listening to the narration. To do this well, I find I need to first listen to the narration and create a list of the times at which I need to click. If you need full-motion clips of your desktop, simply produce them individually to be edited in later.
  5. Fifth, use video editing software to put the video and sound together and to compress it all into a deliverable format. If the sound doesn’t match perfectly to the video, try duplicating and remove frames as necessary.

The technical bits

Rather than use a deskstand mic, I use a headset-style mic. Because I find the headphones uncomfortable, I wear them around my neck with the mic bent in place in front of my mouth. Understand that small changes in the mic position relative to your mouth will produce very noticeable changes in the acoustics of your voice, so try to find a single position and head angle to use every time.

To record and edit the audio, I use Audacity. Hit R to record, space to stop. (Be careful because if you hit R and space too quickly after each other, Audacity–on Windows at least–tends to crash. I suggest saving to WAV for every minute you produce.) Unfortunately, Audacity starts a new track every time you hit R, so you’ll have to manually consolidate the tracks, but it’s thankfully not too bothersome to do this: just cut and paste by highlighting with the mouse and using ctrl-x, ctrl-v. (Tip: after consolidating, delete the empty tracks by clicking the small x in the top left of each track.)

While recording, I prefer to start a new WAV file for every 4 or 5 minutes of audio so as to diminish the chance of losing work. I number the tracks like so: blabla-000.wav, blabla-001.wav, blabla-002.wav, blabla-003.wav, etc. (where blabla is the name of the screencast).

When done editing the audio, I use the compressor effect in Audacity to get consistent volume. I set the threshold to -30db, and if the end result doesn’t look even, I’ll run the compressor again one or two times until it does. Then I find a bit of audio where I’m not talking but which has some noise, select it, click ‘noise removal’, click ‘get noise profile’, then select the whole audio, click ‘noise removal’ again, slide the slider all the way left, then click ‘remove noise’.

Through this whole process, save everything as at least 44.1khz 16-bit stereo in WAV format. If we’re going to degrade, we can do that later.

To capture video of the desktop on Windows, I use CamStudio, an open source tool. Some Vista users will find that the 2.5 beta has fixed sound recording for them, but because we’re not using it to record sound, I recomend just using 2.0. Also be sure to download and install the CamStudio lossless codec (latest is 1.4, at the moment), which I find is the best for pristine full-motion desktop capture. I do my presentations in 16×9, so I set the desktop to 1280×720, run the presentation in full screen, and use CamStudio to record the full screen without any audio. Handily, CamStudio has an option to disable recording of the cursor.

To edit and compress the video, I use VirtualDub. Using the CamStudio codec with VirtualDub requires installing the DirectShow plug-in (which does not work with 64-bit VirtualDub, so be sure to use 32-bit).

Open the video file, then under “Audio”, specify “audio from other file…” to get audio from the appropriate .wav file. You may have to adjust the sync under “interleaving”. Because we’re compressing to mp3, first select “full processing mode”. While your original mic recording in Audacity will be in mono, you at least want it to be mono coming out of all of the listener’s speakers. Otherwise, even a decent narrative will come off as sounding tinny, dull, and lifeless. So under Audio->Conversion, be sure to select stereo. Then under “compression”, I suggest 44100 Hz 128kbps stereo mp3. (Also, stick to CBR as it will further reduce the possibility of sync issues. If you need an mp3 encoding codec, LAME mp3 is the obvious choice.)

Under “Video” select “fast recompress”, then select a compression codec. I recommend x264vfw, an h.264 codec. (VitualDub requires Video For Windows encoding codecs, so if you already have an h.264 codec, you may still need x264vfw.) Experiment with the compression levels until you find something acceptable.

Assuming your video is mostly still images, the video data should run at well under a megabyte per minute such that the audio data will most likely outweigh the video data in the final file. A 10 minute video produced this way takes about 15 megabytes. I’m sure with greater compression expertise, this could be cut substantially, but if your end target is Youtube and other video services, I strongly recommend aiming for quality first and letting them handle any further compression.

Posted by Brian Will
Jan 052009

The comments to this y.combinator item add to what I said here. In particular, commenter apinstein writes:

I used to do a lot of AppleScript programming. When I initially learned about the “natural” syntax I though “this is gonna be so easy!” But ultimately it works against you.

Computers are very precise beasts, and they need to know exactly what you want them to do. The looser the “syntax” gets, the more guesses the compiler has to make to come up with a set of precise instructions.

What I initially thought would be easy and liberating turned out to be a total PITA. AppleScript programming is horrible. Ultimately there is an underlying syntax, but it’s harder to remember because it’s less consistent (ie “natural”). I had to spend way too much time trying to understand what goofy “natural” grammar I had to use to get it to do what I wanted.

Even if you assume an “ideal AI,” I still don’t think that a natural language syntax is a good idea, since language itself has a lack of specificity that requires even an “ideal AI” to make guesses that could be logically wrong.

Posted by Brian Will
Jun 162008

Having spent a lot of time in the last 3 years writing programming education material, I recognize just about everything said here. (The section “Writing clearly” is the interesting one.)

Posted by Brian Will
Jun 112008

If obnoxiously long ring tones were socially acceptable, the opening of this episode of You Look Nice Today would be mine.

Posted by Brian Will