Jay McGavren's Journal

“Filter Through Command” in your editor...

It’s SO nice to finally have an editor (TextMate) with a proper “filter selection through command…” command. I’ll never go back to an IDE without one.

For those not familiar, commands like this take the current selection and pipe it through a Unix command (shell scripts, Perl, Ruby, Python, etc. included), then replace the selection with the command’s output. So if you have this text in the open document:

foo
bar
baz

You can select it, choose Filter Through Command (Cmd-Option-R in Textmate), type “sort” (the Unix command) in the dialog that appears, and wind up with this:

bar
baz
foo

I shit you not...

Was sitting at a red light when I remembered that I needed to look into GitX (thanks for the tip, Byron and Andrew). So I commit a minor no-no and flip out my cell to send myself a voice-to-text note via jott.com. As I’m doing so, the cross-street’s light changes, and I step on the gas. That’s when I realize my light hasn’t changed.

Fortunately it was late at night, so there was no traffic to have an accident with. But I did find this message in my e-mail:

Jott Networks to Jay: Reminder. Computer research Getex(?). Wooh! Jesus!

Notes from Kernighan and Pike: The Practice of Programming...

Borrowed The Practice of Programming from the Gangplank library on Jade Meskill’s recommendation… It’s pretty C++ and Java-centric, but a lot of it is applicable to Ruby, and these notes were taken through Ruby-colored glasses.

Style:

Why 'waste time' on good coding style?  Once it becomes automatic, even code
you produce under pressure will be better.
Using long names regardless of context is a mistake: clarity is often achieved
through brevity.
"queue.queue_capacity" is redundant, "queue.capacity" is better.
The ?: operator is fine for short expressions where it can replace four lines
of if-else with one, but if full conditional statements make the code clearer,
use those.
If you work on a program you didn't write, preserve the style you find there.
The program's consistency is more important than your personal preference.
Learn your language's idioms.  Those with experience can read and write them
easily without mistakes.  And if there's a mistake in using the idiom, it's
usually easy to spot.
Sprawling code goes onto multiple pages/screens; scrolling reduces readability.
If there's no good logic to put as the default in case statements and if-elses,
throw an exception; it catches conditions that "can't happen".
On comments:
        Harmful comments:
                Don't restate what the code already clearly says.  (Carefully
                chosen names are better than comments.)
                Don't write comments unless you're sure they will be updated as
                the code changes.
        Good comments:
                Aid understanding of a program by briefly pointing out
                important details.
        A comment that introduces each function will speed comprehension when
        reading code.
        If the code uses an unfamiliar algorithm, consider referencing a
        document/URL/book the maintainer can read.
        Comment anything unusual or potentially confusing, but only after
        considering refactoring.


Design and Implementation:

"Show me your tables, and I won't usually need your flowcharts; they'll be
obvious." --Frederick P. Brooks, Jr., The Mythical Man-Month
Program design can be colored by the language used, but is usually not
dominated by it.
Issues to be worked out in a design:
        Interfaces: provide services that are uniform and convenient, without
        so much functionality as to be unwieldy.
        Information hiding: provide straightforward access to your components.
        Hide details of your implementation so they can be changed without
        affecting users.
        Resource management: is the user responsible for managing storage,
        memory, and other limited resources, or is the framework?
        Error handling: who detects errors, who reports them, and how?  What
        recovery is attempted?
Build a prototype for new systems.  It's not until you've built and used a
version of a program that you understand the issues well enough to get the
design right.

Diana got tickets for us and Mom to the Chihuly blown glass exhibition at the botanical garden… The artist is one of the few I know of that allows cameras into the exhibition, and shutterbugs came out of the woodwork for it. All 3 of us were armed with our own point-and-shoots (one on loan from Diana’s mom), and we fired off hundreds of shots between us until batteries started running out.

This one’s off my camera phone; the proper pictures will be posted later. Some will be going into a photo contest they’re running, and judging from the unimaginative entries in the gallery, we might actually have a chance.

MountainWest RubyConf - a travelogue...

Integrum at MountainWest RubyConf 2009 from Jay McGavren on Vimeo.