Moby Dick has long been one of my favorite books. It’s part adventure story, part whaling encyclopedia, and it’s just good prose, dramatic, poetic stuff. It’s something of a precursor to things we see today like the fascinating and entertaining show The Deadliest Catch, which details the mechanics and the drama of fishing for crab on the Bering sea. If you like the latter, it may be a misstep to dismiss the former.

When Lennie was still in utero and we were trying to think of ways to let her hear my voice, I thought of reading Moby Dick to her. It doesn’t matter what words you’re saying, but matters only that the child can hear you. Also, though it’s one of my favorite books, it’s one that Mleeka never read and has never had any interest in reading. Our effort fizzled thanks to a lack of enthusiasm on her part (as I recall it; it’s possible the book just put her to sleep).

This past Christmas, I got a radically condensed, cartoon version of the book (not to be confused with the comic book version I got for my birthday), the idea being that it was something I might share with Lennie. To be honest, the book isn’t that great. The drawings are pretty crude, and though the book hits the high points of the plot, it’s just not the best sort of thing to read with a kid because of the way it’s laid out. But a few weeks ago, Lennie developed on her own a very keen interest in having it read to her. Probably a dozen times or so now, we’ve glossed it at bedtime. I don’t bother reading the words so much as pointing to pictures and telling Lennie the names of the people and explaining that the whale and Ahab are grumpy. Now she tells me these things. She can identify on her own the characters Ishmael, Captain Ahab, and Queequeg (volunteering the names of the former two). And of course, she knows the white whale’s name and that the sailors wield harpoons on their hunt for him. She can also tell the difference between the pictured right (or baleen) whale, and she’s close to being able to volunteer that the right whale has no teeth but has baleen instead. She’s very interested in the ouchies that appear on Moby Dick’s flank (bright red ribbons of blood trailing behind), and she understands that Ahab (who she knows has a peg-leg) is grumpy because Moby Dick bit his leg off.

And finally, as of this weekend, when we get to the page on which Moby Dick is first sighted from the crow’s nest, she’ll say in a theatrical voice that I may be responsible for having helped her develop for the purpose, “Thar she blows! A hump like a snow-hill!”

Mleeka refuses still to read even the abridged book with Lennie, and I consider it my duty to raise a little fanatic to exact revenge, which is, after all, one of the book’s core themes.

I’ve got a training session coming up in a couple of weeks for which I’m required to have a Windows laptop. Of the three laptops I owned at the time of my learning this, one is broken, one is 4 years old and just doesn’t have the power to run the software I’ll need to run, and my main one runs Linux. Sounded to me like it was time to get a new laptop. Doing so would afford me the opportunity to take both a Windows laptop and my Linux box to the training (where I’ll be doing a full day’s training and then, if possible, also a full day’s regular work each day, which necessitates that I have handy the box I can actually be productive on). It would also afford Mleeka an upgraded system after I got back from training. So I went to amazon and dropped a grand on another SONY Vaio and an extra GB of RAM. This is a significant upgrade for me, as I’m currently running half a GB and will be running 2GB when the new RAM arrives.

The new computer got here yesterday, and of course I love it. My inclination was to wipe Vista from it first thing, but then I googled around about dual-booting with Vista, and it turns out to be really easy. Vista lets you partition the disk without even so much as a reboot, which for Windows is shocking. So I shrunk the Windows partition and booted from the disk for Ubuntu Feisty. I had to mess around with gparted for a while to get the partitioning just right, but then I installed Ubuntu, and now I have a dual-boot system. So Mleeka gets her upgrade a little early. I started moving files from the old laptop to the new yesterday afternoon, and by now, I’m completely migrated.

I can’t say enough about how smoothly the Ubuntu install went. I’ve posted a number of times in the past about all the hoops I’ve had to jump through to get various Linuxes (Linuces?) installed on various laptops, but this time, it just plain worked. No wrangling with xorg.conf to get the widescreen or touchpad to work. No more special network card drivers.

The only rough patches I’ve hit so far are that networking does seem a touch flakey. I can get to other boxes on my network without issue, but I’ve had to restart my wireless interface a number of times this morning because I couldn’t hit things outside the network. So I’ll need to work that out. And when I opened up my laptop this morning, I was surprised to see that it had shut down. Turns out that the power management settings default to hibernating when the laptop is closed, and hibernate, intentionally or not, equals hard shutdown on this hardware. That’s easily enough resolved with a change to power management settings.

So in two weeks, I’ll be off to my training with just one laptop that happens to be blazing fast. My next step is to make a virtual machine of another Windows install so that I can run it in vmware during the training and never have to leave the comfort of a bootup into Linux.

Anybody who’s done any open source development knows about this nifty tool called phpMyAdmin that lets you manipulate mysql databases through a web interface. For Luddites like me, using the command line interface is usually preferable to using any sort of GUI tool that requires pesky mouse moves and clicks, so I’ve generally deployed phpMyAdmin to be used by others who needed to screw with databases but haven’t been comfortable with (or had access to) the command line.

One of my tasks for today is drawing up some diagrams to show relationships between tables in a big fancy dimensionally modeled database I’m trying to blunder my way through designing. The problem is that I utterly hate all the tools I’ve tried for this on Linux. What I wanted was something that would read in a mysql schema file and populate the basic diagram for me so that all I had left to do was to map out the relationships. There’s a UML-diagram application called Umbrello that does entity-relationship diagrams of the type I need to deliver, and a user has contributed a script that will read in a schema file (though it’s finicky). I don’t like the application itself very much, but it fit my basic requirements. This morning, it started crashing, though, and was unusable. Luckily, I hadn’t done much manipulation of the model in it yet. So the quest for a better tool was back on.

I tried various versions of DBDesigner4 and MySQL Workbench, even going so far as to try running the Windows versions in wine when I experienced problems with the Linux versions, but nothing worked out.

Finally, I decided to take another look at phpMyAdmin to see if it had been enhanced with any sort of modeling capabilities. And it has! In recent versions, you can enable a “Designer” view by uncommenting a couple of lines in the config file and slurping in the tables for the phpmyadmin database in the scripts directory. It’s not a perfect tool by any means, but when I click the “Designer” tab in the app, it shows me a nice DHTML view of the tables that lets me drag them around, specify relationships, toggle to show or hide tables that have no relationships defined, etc. It comes with a nifty little palette and a toggleable sidebar to handle these operations, and it’s really a pretty elegant little piece of work. What’s more, and what makes this really useful for my purposes, is that I can save the frame (phpMyAdmin keeps a navigation frame open on the left) to my local disk, zip it up, and send it to somebody, who can then perform the same DHTML manipulations I was able to perform, making it ideal for sending along a complex schema that can have portions of it disabled for ease of viewing. (To clarify, they can save none of the information back to the database, but there’s some degree of flexibility with respect to how they can control the static view.) And to top if all off, if I want to make changes to tables, I can do it at the command line or right there in phpMyAdmin, and there’s no re-importing of a schema — the Designer view will be up to date the next time I reload it. In Umbrello, it’s my impression that any changes I made after import (e.g. drawing relationships) could not be exported back out in a useful way for porting back to the database, so I would constantly have been updating the schema, importing, and redrawing relationships.

This is a great tool for my purposes, and of course phpMyAdmin’s core features are also very useful in many environments.

I don’t know that I’ve ever participated in a blog meme, but here goes. Occasional web correspondent Ross White tagged me with the five songs meme. I listen to music mostly as background music and don’t consider myself much of an aficionado, so this list probably sucks. First, let’s go by my iTunes play count, which covers basically the last two years (I’m not sure whether my iPod adds its play counts back to iTunes when I dock it, though I suspect it does, given the first item on the list, which is a kid’s song we mostly listen to in the car).

• I Know a Chicken (Laurie Berkner)
• Gold Digger (Kanye West)
• The Reason (Hoobastank — a great tune to belt out when you’re falling asleep at the wheel)
• Elvira (Oak Ridge Boys — another nostalgic one I got for my daughter)
• I Am the True Vine (Paul Hillier, an Arvo Part arrangement)

Now for a truer list of my recent frequently-played tunes:

• Hate Me (Blue October)
• Cancer (My Chemical Romance — this is a coincidence, by the way)
• I Write Sins Not Tragedies (Panic! At the Disco)
• Wish You Were Here (Pink Floyd)
• Da Pacem Domine (Arvo Part — I tend t listen to all of his music at once, so this is a representative tune; more on Part here)

So there you have it. Two lists for the price of one, both no doubt showcasing my embarrassingly bad, poppy taste in music.

Well, I didn’t manage it. For the first fourteen days of April (and a day or two before that, even), I wrote at least a poem a day, and not all of them made me want to vomit. Then real life intervened, and I spent a lot of time in the car and hanging out with my extended family during the days surrounding Mom’s death, and I missed a couple of days. And then my work schedule ramped up so that I was (and am) spending the couple of hours of more or less free time I had been using to write in the evenings to work instead. Excuses, excuses. Rather than feeling too bad about it, I’m cutting my losses, acknowledging that I think I may have a few solid first drafts out of the experiment, and suggesting that I participated not in NaPoWriMo, but NaPoWriFo (fortnight). Wheeeee!

A few weeks ago, my company needed to publish a survey with a pretty flexible layout. Had we been constrained to the one-field-per-row constraint that Drupal’s survey module allows for, we would have had a very long an ugly form when in fact what we wanted was a nice tidy grid of small form controls that was much less imposing for users to consider filling out. So I hacked our old version of the survey module (for Drupal 4.6) to add a “layout” field to the fields tab for a survey. In the layout field, those who can administer surveys can specify markup and drop form fields into the markup using numeric placeholders wrapped in curly braces. Surveys for which no layout is defined use the default layout with numeric field weighting. I’ve submitted a patch to incorporate this functionality, and you can find the bug report with attached patch here if you’re in need of such functionality before the patch gets review or if the survey module developer declines to integrate it. The patch is for Drupal 5.x.

On a related note, I created a patch for the forms module that lets you add HTML between form elements. This hack/patch arose out of a need to stick a quick text snippet between two fields, where the snippet couldn’t be contained gracefully in the “description” line of the topmost of the fields. I add a form field type “html” that spits out whatever HTML you specify. I wrote this code (or the old version of it; this patch too is for Drupal 5.x) when my company needed explanatory HTML between two fields but the need to manipulate the form fields themselves hadn’t arisen yet. This functionality is good for insertion of quick snippets of HTML, where the first patch I mention above is best for layout overhauls.

Both patches probably represent security risks on sites that allow non-administrators to create forms or surveys, as I’m not (as yet) filtering content, so anybody who can create a survey can add arbitrary HTML. So apply the patch with that in mind.

I’m working on a project that requires me to apply a fancy pants style to a Drupal search form. I thought this would be simple enough, as it’s pretty easy to override default themes for pretty much everything else in Drupal, but it turns out either that I’m a dolt or that there’s not much clarity out there on this topic. After screwing around with a lot of things (e.g. poring over debug_backtrace() output, writing die() statements all over the place, temporarily hacking the search and node modules, etc.), I searched Drupal’s site and found a promising link that turned out not to be the solution I needed (it simply didn’t work).

At long last, I tried creating a theme function named mytheme_search_form(). The search module has a function named search_form(), but in all my hair-pulling, I never saw anything that indicated that you could override this function by prepending your theme name to it (I would have expected to find calls to “theme(’search_form’, $args)” somewhere). At any rate, I ultimately created the above-named function and gave it the following definition:

function mytheme_search_form($form){
        return _phptemplate_callback('search_theme_form', array('form' => $form));
}

Then I created a file in my template directory named “search_theme_form.tpl.php” and built a custom form.

Next up was adding additional search fields to the form. To do this, I looked at node.module, where the function node_form_alter() adds fields to the default form. It didn’t seem necessary to jump through that hoop since my form was mostly hard-coded anyway, so I just added some radio buttons with the name “category” so that I could filter search results by taxonomy. Simple enough. But the search never actually filtered on my results. Here I did more hair-pulling and weird debugging. Finally, I went back to the hook_form_alter() functionality, having noticed a “processed_keys” key in the $form array. So to make my form honor my category search, I added the following things to my template.php file. It’s not clear to me how much of this is necessary, and I rather suspect I’m doing something stupid here, but it seems to work and I’m on deadline, so I’m rolling with it.

function mytheme_search_keys($type = null){
        $keys = search_get_keys();
        if($type){
                $keys = search_query_insert($keys, 'type', $type);
        }
        if($_POST['category']){
                $keys = search_query_insert($keys, 'category', $_POST['category']);
        }
        return $keys;
}

/**
 * Taking over this function so that I can call mytheme_search_validate to do the advanced search.
 */
function blog_form_alter($form_id, &$form){
        if($form_id == 'search_form'){
                $form['#validate']['mytheme_search_validate'] = array();
        }
}

/**
 * Need to call this to add category to the processed_keys array item so that
 * the category actually gets searched in the mini-advanced form we generate
 * in mytheme_search_form().
 */
function mytheme_search_validate($form_id, $form_values, &$form){
        $keys = $form_values['processed_keys'];
        $keys = mytheme_search_keys($form_values['module']);
        form_set_value($form['basic']['inline']['processed_keys'], $keys);
}

function faq_search($op = 'search', $keys){
        switch($op){
                case 'name':
                        return t('content');
                default:
                        $keys = mytheme_search_keys('faq');
                        return node_search('search', $keys);
        }
}

function forum_search($op = 'search', $keys){
        switch($op){
                case 'name':
                        return t('content');
                default:
                        $keys = mytheme_search_keys('forum');
                        return node_search('search', $keys);
        }
}

function blog_search($op = 'search', $keys){
        switch($op){
                case 'name':
                        return t('content');
                default:
                        $keys = mytheme_search_keys('blog');
                        return node_search('search', $keys);
        }
}

Now for an explanation. The “mytheme_search_keys()” function is a helper that lets me make sure I’m limiting the search to a given node type. It’s not clear to me that this is absolutely necessary, but things seem not to work if I don’t add the “type:” string to the search, so I’m leaving it in. Note that this function also looks for $_POST[’category’] and adds it to the keys. If I wanted to add other search fields, I’d add them here as well. I suppose that since mytheme_search_validate() calls this function to set keys, I could eliminate the extra function and just do the same work in mytheme_search_validate().

Next up, blog_form_alter(). The hook_form_alter() functions are associated with modules, so I chose one I knew my site would be using that didn’t have a form_alter hook defined already. It feels kind of hacky, but it seems to work. The idea here is that we need to make the form run a validation function in order to add the keys we’re pulling in from mytheme_search_keys(). It was when I added this code that the category filter actually started working, so it seems to be a crucial bit. The key seems to be adding the keys to the $form[’basic’][’inline’][’processed_keys’] array item, which seems to handle adding the search criteria to the URL and to the search itself.

Finally, I added the three _search() functions, which again feel a little extraneous, but the thing doesn’t work unless I add them, so they’re staying put for now. All we’re doing in these functions is adding the node type to the keys being searched (the search code extracts things like “type:blog” and “category:3″ from the query to do advanced searches) and then executing the node_search() function with the revised $keys value.

So, there you have it, the long way around to having a custom-themed Drupal search form with additional filters based on node type and category. Hope this saves somebody a few of the 10 or so hours I spent staring incredulously at my screen as solution after solution failed to work.