Jay McGavren's Journal

QuickSilver Google search with 100 results per page...

Man, was this a pain to find. I’m assuming some proficiency with XML and Quicksilver here; leave a comment if you need more specific directions.

Install the Web Search module from the Quicksilver plugins pane if you haven’t already. Quit Quicksilver. Then edit this file:

~/Library/Caches/Quicksilver/Indexes/QSPresetDocWebSearches.qsindex

Search for:

<string>qss-http://www.google.com/search?hl=en&q=***</string>

And change it to:

<string>qss-http://www.google.com/search?hl=en&q=***&num=100</string>

Be sure you’ve got the “Google Search” entry; there are many similar ones. I originally edited the file while Quicksilver was running and had to quit and reload the catalog several times before I got it to stick. Your mileage may vary.

To test, bring up QS, type “Google Search”, tab twice, type your query, and press Return. Your default browser should load a Google Search with 100 results per page. You can of course make any other tweaks to this or any other search URL that your heart desires.

SVG...

I’m having way too much fun with the out-of-the-box SVG support in Firefox 3…

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