Become a Better Speaker for $100

The title of this post is a lie. It costs $70 or less, but takes a lot of work. I’ve offered this advice person-to-person many times, and finally got around to posting it.

How well you speak can have a great impact on  your ability to get customers, to attract employees, to persuade others to adopt your ideas, and much more. But how do you know how well you speak? You can’t tell as you are speaking; and if you’ve never heard yourself speak but simply assume you do well, there is a great risk that you are very, very wrong.

To become a better speaker, you need to review your own “performances”. For the last few years I’ve been recording my talks (at user groups etc.) with a hand-held voice recorder. I use an Olympus WS-100 (probably obsolete by now) and you can readily find an adequate device for $70 or less.

Make the Recording

Don’t actually hold the recorder on your hand. Sit it on the podium if you use one (I don’t care for podiums, I use one only if I am presenting with my computer and the podium is the only place to put the computer); but not to close to your noisy computer. Put it on a table or unused chair in the first row, but not too close to any noisy people or equipment.

Start it at the very beginning, and stop it at the very end. It is easy to edit out extra recording later.

Put in a fresh battery, so it doesn’t run out partway through.

Listen to the Recording

Take the recorder/player in your car, copy it to  your iPod, burn to CD, whatever… but listen to it, end to end. Experience your talk as a member of the audience. Make notes about any bad habits you exhibit, such as “umm”, “ahh”, “like”, “ya-know”, long (unintentional) pauses, pointless extra words, etc. This is your first opportunity to become a better speaker by means of the recording. WARNING! The first few times this might be very, very painful.

Edit the Recording

If you plan to post this audio online (as I usually do),  clean up the recording to trim off any extra starting and ending time; the audio you post should start immediately with your talk content and end crisply. Download Audacity (or another audio editing) and use it for this initial trim.

If you can spare the time (approximately 2x the length of the talk), listen through the whole recording in Audacity, trimming out the “umms”, “ahs”, overly long pauses, etc. This is your second opportunity to become a better speaker… but only for the offline listeners, and in an artificial, one-off way. Still, for an occasional important talk it is worthwhile.

Get a Transcript

Finally, be aware that your (now-pristine) audio is completely unsearchable and invisible to Google. To make it findable, have a transcript made and post that also. You can pay CastingWords or other similar service to create a transcript for around a dollar per minute, or perhaps much more cheaply with some searching. The resulting text can be readily posted online, making your talk both more findable, and more accessible.

An example of a recorded, lightly edited, and posted talk (with transcript) is my Ruby GUI talk earlier this year.

DRBD on Ubuntu

This week I experimented with DRBD (Distributed Replicated Block Device) which is “a block device which is designed to build high availability clusters. This is done by mirroring a whole block device via (a dedicated) network. You could see it as a network raid-1.”

DRBD can be used for build a “poor man’s SAN”, a RAID running over Ethernet. In our case, we want a warm spare of an important database system, i.e. a second set of hardware which can take over for the primary within a few minutes of failure, and DRBD might be a great way accomplish that. DRBD runs on commodity hardware (ordinary servers, network adapters, etc.) so it is inexpensive. It is also, if benchmarks and comments are to be believed, surprisingly good. I suspect this is because CPUs and networks (Gigabit Ethernet, ideally) are so much faster than disks.

The systems at hand for testing here run the Ubuntu distribution, itself based on Debian. It took a lot of reading and learning, but very little actual typing, to get DRBD going on Ubuntu. My writeup here should help the next person along. As I write this, the released version of DRBD is 0.7, and the DRBD site encourages ignoring the newer unofficial release, advice that I followed.

First, read the HOWTO and the FAQ, but don’t follow the instruction in them yet; then you are ready to begin. The guessable part is to install the module with apt-get (you’ll need the “Community” APT sources in Ubuntu; I don’t know offhand what is equivalent in Debian):

apt-get install drbd0.7-module-source

This installs the module’s source code, not the module itself. After doing this, I spent a couple of hours trying to figure out how to compile it – untarring it and running “make” does not work. There is an abundance of confusing and misleading advice on the web about this, including advice to compile your own kernel. If you don’t need a custom-compiled kernel for other reasons, ignore all that and discover the joy of Debian’s “Module Assistant”, invoked by the command “m-a”.

m-a prepare

“prepare” will get your machine ready to compile modules that can link with the running kernel; it will prompt to download and install packages needed for this, including the correct kernel header packages. Now you are ready to build and install the module:

m-a a-i drbd0.7-module-source

Follow the prompts; if it asks to install more packages, agree to do so. On Ubuntu 6.10, it may fail with an error about “mv”. This is a known bug; the workaround is to expand the module source file (it lives in /usr/src/), add the line “SHELL=/bin/bash” at the top of each Makefile, then retar the module source.

By the way, this points out a stark and troubling aspect of Ubuntu “community” packages: not only are they not assured to work, they are not even casually tested to verify they compile on the Ubuntu version they are purportedly intended for use with… which I find very disappointing. I suppose the lesson is that Ubuntu is very slick for the set of officially supported packages, but if you’ll be using a lot of packages beyond that set, its appeal is much diminished.

Now you are ready to enable DRBD, following the HOWTO instructions, starting with setting up /etc/drbd.conf.

In my case I used LVM to make a 10 GB partition on each machine, put DRBD on top of that, put a filesystem (Reiserfs, for variety) on top of them, then moved/symlinked my PostgreSQL data there. It worked fine, including these tests: I started a long intensive DB operation (restoring a several-GB backup), then with that running, rebooted the secondary machine. This did not interrupt the DB operation, and when the secondary finished its reboot, the DRBD partition re-synced automatically. I then shut down the primary machine, and verified I could mount and read that same data on the secondary machine… all exactly as described.

One caveat though – in a few cases, machines with DRBD stopped during the boot sequence, waiting for user intervention (in this case, closing a shell) because they the DRBD device wouldn’t mount. I suspect this was because I don’t fully understand how to configure it.

Of course this was just a short initial look, but I am very impressed with DRBD so far.

Dual Monitors – Worth Every Penny

As I write this in 2006, it is a very late post. Back in January 2003, I got a major PC upgrade: two 19″ LCD monitors and a dual-DVI video card to drive them. This was somewhat less common (and much more expensive) in 2003 than today. The monitors are “Samsung SyncMaster 191T”. I took this photo at the time, meaning to post it:

Dual monitors are a remarkable productivity tool – I am confident that this upgrade paid for itself within the first few months of use. Another developer here at Oasis Digital uses three screens; I’m planning to go that direction, or two larger screens, next time I upgrade. I’ve since moved to a faster computer, but I’m still using these monitors.

For best results, don’t even think about plugging LCDs in to analog VGA – the difference between analog and DVI is immediately visible and stark. I’ve seen many sources online claim that DVI is only a minor improvement; I find this unfathomable.

I use and recommend Ultramon for making best use of multiple screen – it seems to work better than the similar software which ships with some video cards.

Basement Data Center

It occured to me today that a section of my basement is starting to resemble a data center:

Data Center

The four machines here:

  • Are all test machines, or being configured and burned in for future deployment – the production hardware for our projects invariably ends up in customers’ data centers or in robust colo facilities (redundant power, massive air conditioning, redundant “tier one” network connectivity, etc.)
  • All use AMD CPUs – two of them have dual-core Athlon64 X2’s.
  • Are all black – black is still the default color, it appears.

Other tidbits:

  • The leftmost machine is a “Shuttle XPC”.
  • The shelves are homemade and very strong.
  • Three of the machine run only Linux; the other dual-boots to Windows XP.
  • Very little work happens on these machine at the physical console – they are accessed via SSH, VNC, Terminal Services, etc.
  • There is a dedicated 15 amp circuit to run these machines.
  • The reason they are here, in my basement, is so that the hardware and OS can be configured. When one becomes wedged it can easily be rebooted or diagnosed at the terminal; that happens all to often when, for example, trying a variety of Linux kernels to get virtualuzation working .