Jeremy Zawodny's blog

TV Watching and Happiness

In one of those "well, duh!" moments the other day, I came across a headline on Slashdot that said Unhappy People Watch More TV. Given that I mostly stopped watching TV quite some time ago and consider it to be one of the more rude devices in our culture, I clicked thru to read about how others have discovered what I'd already guessed was true...

A new study by sociologists at the University of Maryland concludes that unhappy people watch more TV, while people who describe themselves as 'very happy' spend more time reading and socializing. 'TV doesn't really seem to satisfy people over the long haul the way that social involvement or reading a newspaper does,' says researcher John P. Robinson. 'It's more passive and may provide escape--especially when the news is as depressing as the economy itself.

Imagine that... Stagnation and exposure to negative information leads to sadness. It goes on...

The data suggest to us that the TV habit may offer short-run pleasure at the expense of long-term malaise.' Unhappy people also liked their TV more: 'What viewers seem to be saying is that while TV in general is a waste of time and not particularly enjoyable, "the shows I saw tonight were pretty good.

Another shock. TV provides only a short-term reward (kind of like a drug hit).

If this resonates with you a bit, or you suspect deep down that there's more going on with the influence of TV in our culture, I highly recommend reading Amusing Ourselves To Death by Neil Postman if you have not already.

It's too bad this stuff doesn't get taught in school--where, I'm told, teachers are using PowerPoint more and more.

*sigh*

Asynchronous MySQL Client in Perl

I recently found myself wishing for an async library for MySQL. My goal is to be able to fire off queries to a group of federated servers in parallel and aggregate the results in my code.

With the standard client (DBD::mysql), I'd have to query the servers one at a time. If there are 10 servers and each query takes 0.5 seconds, my code would stall for 5 seconds. But by using an async library, I could fire off all the queries and fetch the results as they become available. The overall wait time should not be much more than 0.5 seconds.

While I found little evidence of anyone doing this in practice, my search led me to the perl-mysql-async project on Google Code. It's a pure-Perl implementation of the MySQL 4.1 protocol and an asyncronous client that uses Event::Lib (and libevent) under the hood.

The code contains little in the way of documentation or examples, aside from the simple bundled test script. After a bit of mucking around with it, I managed to cobble together a working example. It looks like this:

Sure enough, that code runs in just a bit more time than the longest query it executes, rather than the sum of all the query times.

What still surprises me is that this code doesn't appear to get a lot of use (or at least discussion) in the real world. In the PHP world, the mysqlnd driver offers async queries.

So count this as my contribution to demonstrating that Perl can do async MySQL queries too.

Post-Election Thoughts: Equal but Not

I'm happy that Barack Obama won the election. I think it's time to stir things up a bit.

What really bothers me is that fact that we still don't have equal voting in this country. We certainly have the technology to share vote counts quickly and efficiently, so who not just do that? Why screw around with an electoral college anymore?

It seems disingenuous at best and an outright lie at worst to call Obama's victory a "landslide" when the actual percentages of the popular vote (the only vote that should count) were so close. Yet the large difference in electoral vote counts is supposed to make us believe that something very different happened. And the media was more than happy to play along with that deception (what a surprise, huh?).

It should not be possible to lose by having more votes than your opponent, but it is. Why does nobody seem to care? (See: electoral college, specifically this.)

Of all the countries that have tried to copy our model of democracy in the last 200 years or so, can you name a single one that adopted the electoral college as a piece of their political infrastructure?

I'd love to have my vote count as much as everyone in all the other states.

Why is that so hard?

Kick Ass Fonts in Ubuntu: 3 Easy Steps

A few days ago I made yet another tweak to my Ubuntu laptop to make the fonts look a little better. The result is that I'm now quite happy--impressed even. Here are the three things I've done to make my day-to-day work easy on the eye.

First, enable subpixel smoothing in the System > Appearance control panel.

For a long time that's all I had done was was reasonably happy. Things looked okay but not great. But I used GNU Emacs for most of my coding and wanted fonts there that looked at good as those in gnome terminal.

That led me to the second tip: install emacs-snapshot and use the GTK version. Then you can add this to your ~/.Xresources file:

Emacs.font: Monospace-10

And bingo! The same font that's in your terminal is in Emacs.

That made me happy in Emacs, but my Firefox fonts were still a bit sucky. So when I read Tweak Your Font Rendering for Better Appearance in Tombuntu, I had to give it a try.

I created a ~/.fonts.conf file and added this to it:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="font">
    <edit name="autohint" mode="assign">
      <bool>true</bool>
    </edit>
  </match>
</fontconfig>

I logged out and back in and suddnely found myself staring at fonts in Firefox that looked as good as I've seen in Safari on a Mac.

That's all there was to it for me: subpixel rendering, emacs-snapshot, and enabling hinting via a .fonts.conf file.

It's worth noting that you can go even farther with the advanced font settings, but I really haven't needed to go that far yet.

Random Updates

I've got several random things to say to the interwebs but none of them merit a blog post individually...

First off, I love data. But I hate the fact that the spreadsheet in OpenOffice 2.x and Gnumeric both have row limits of 65,536. I don't know who missed the boat on 32 and 64 bit CPUs, but it's rather annoying! And, yes, twitter people, I know that 65,536 is a 16 bit limit--not 8. I was trying to make a point.

Secondly, Yahoo can haz layoffs (again). Having lived through 3 rounds of layoffs in my 8.5 years at Yahoo, I know what that feels like. :-( If you're a kick-ass Perl hacker or an excellent systems and network administrator who'd like to work at a great company in San Francisco, let me know.

Thirdly, the dumbest bugs are often the ones that have been in your code a long time and are incredibly easy to keep glossing over as you read and re-read it.

Fourthly, Tie::Syslog is pretty handy but seems to not like being used multiple times in the same app. Each instance seems to think that it has the same "identity." Anyone seen that before? I haven't dug into that yet but probably will soon.

Finally, we're out of town for a few days while the house is being fumigated for termites. And we brought all four cats with us. That what I call an adventure.

Now back to your regularly scheduled... uh, stuff.

Yahoo! Search Taste Test

In today's coverage of the new Yahoo! Search radio advertisements, Erick Schonfeld at TechCruch says:

So can an advertising campaign change any of that? Search is not like a soft drink. People use the search engine that they think can do the best job in helping them find things. Now, maybe Google has brainwashed all of us to believe that it does indeed produce more relevant results. And in a blind taste-test more people might choose Yahoo's results. But if that is the case, I'd rather take an interactive quiz that puts each search engine to the test and make my own decision. That would go much farther to convince me to switch than Yahoo's current creative.

Funny he suggests that. I remember suggesting exactly that a few years back when I worked in the marketing group for Yahoo! Search. I suggested we do something inspired by Twingine but which hid the engine identity and let users judge for themselves.

Why didn't it happen? Because some of the same people who were convinced that Yahoo! Search was "just as good as" Google (and better in some cases, they said) were afraid that people would realize that this was not the case.

The cognitive dissonance was amusing, but it was also frustrating and stupid. "Either we believe we're better or we don't... Which is it?" is the sort of argument I tried to make.

I guess that question eventually answered itself.

Oh, well...

Great HTPC Wireless Keyboard: Adesso WKB-4000US

A few weeks ago I asked for HTPC Wireless Keyboard and Mouse Recommendations and got some excellent suggestions. After reading reviews on-line and checking out the various specs, I settled on the Adesso WKB-4000US.

I decided on this keyboard partly because I've liked previous Adesso keyboards and partly because it seemed to be the right combination of price, size, and range for our use. I was not disappointed.

The keyboard feels very solid--not cheap at all. Range is excellent and the feel, while not excellent, is better than I expected. The trackpad works well and no special drivers were required for Windows XP. It Just Works. They keyboard even came with a set of batteries!

If there's any negative to mention, it's that the USB dongle is about twice as long as I'd have liked. But that's a pretty small price to pay for being able to sit on the couch and control the home theater PC without reception concerns.

If you're looking for a good wireless HTPC keyboard, I highly recommend the Adesso WKB-4000US. It's available on NewEgg.com as well as on Amazon.com.

Back Seat Flying in the Citabria: Tailwheel Fun

About a week ago I finally got the chance to work on the back seat flying with my instructor in our Citabria. I'm not new to flying from the back. I've done so in gliders for a few years now, but I knew this was going to be a bit different.

I wasn't concerned about the actual flying. Flying is pretty much the same no matter where you are. The only question is how many of the instruments you can see from the rear seat. Luckily, I found that I was usually able to see the two or three that mattered: airpseed, altimeter, and engine RPM.

What I knew would be the most interested was the takeoff and landing--especially the landings. Being a tailwheel airplane, the nose is naturally much higher when on the ground or in a landing attitude. That means dramatically restricted visibility from the back. On takeoff it's not too bad, since you can pretty quickly get the tail flying and level out the airplane.

On landing, however, you end up using a lot of peripheral vision and a bit of faith. (This is assuming a normal three-point instead of a wheel landing. See also: Conventional Landing Gear).

But a funny thing happens after you practice it a few times: you start to get the hang of it and realize that it's not all that different than landing from the front seat. You're still trying to stay lined up on the runway and fly the airplane until it lands. In fact, you're trying to keep it from landing as long as you can so that when it finally touches down there's not enough energy for it to start flying again.

Aside from the satisfaction of learning something new and building confidence in flying your airplane, being able to fly from the back seat has another benefit.

You can now have your wife fly from the font seat and get used to the airplane that she'll be using to finish up her training too. And I may be biased, but I think she did a pretty darn good job on her first flight from the front seat. :-)

I'm not sure I'd want to put a non-pilot up front--or at least not someone who hasn't been around airplanes a lot. There are a some controls that I cannot reach from the rear. But I'd feel pretty comfortable giving rides from the back now.

Steve Fossett Wreckage in Mammoth Lakes Area

Various news sources are reporting that Steve Fossett's wreckage has been found in the vicinity of Mammoth Lakes, California. There are a few interesting bits about what I've heard and read so far, but first have a look at the terrain that area.

There are ski runs nearby and the crest of the Sierra Nevada mountains isn't far either. The Mammoth Yosemite Airport sits at an elevation of 7,128 feet and the nearby ridges and peaks easily top 10,000.

In fact, the impact appears to have happen around 10,000 feet and was consistent with flying directly into terrain. The fuselage apparently disintegrated and the engine was found several hundred feet from the impact location.

My suspicion is that Steve had some sort of in-flight medical problem. He was a very experienced pilot and likely wouldn't have been doing any acro at that altitude (though is plane probably could have). And even if there was engine trouble, he'd have had the sense to try to get it down safely or at least slowly.

The NTSB should be able to figure out if the engine was running at the time of impact. But first they have to get all the wreckage transported to somewhere it can be studied.

The other puzzling thing is that he was supposed to be out look at dry lakes. There aren't really any dry lakes up there. Maybe 15-30 minutes away, down in the Owens Valley and beyond, but not up near the Sierra Crest.

I'm curious to hear what the NTSB and FAA are able to figure from all of this.

Programming Annoyance: Libraries that Exit on Me

This is something that's been bugging me for a long time now. Over the years, I've come to realize that programming time is 10% about writing the code to do the work, 70% about figuring out where failures might occur and dealing with them, 10% about documentation, and 10% about documentation. (That last 10% may be substituted with Desktop Tower Defense or something equally time wasting.)

Or something like that. The point is that writing the code to do what I want isn't hard. It's dealing with all the other things that do--especially error conditions. There are so many weird corner cases to consider. And when you're working on code for a high volume web site that has its servers under load 24 hours a day, it doesn't take long to encounter those odd situations.

Murphy is always watching.

Years ago, after battling similar problems at Yahoo, I began to develop certain ideas about how errors should be detected, handled, and reported. An important idea here is that the developer should always be in control of when the script/program/process dies. Aside from something truly fatal (like a segfault) library routines should detect errors and report them back to their caller in the form of a known-to-be-bad return value.

The problem is that I keep running into code I want to use that breaks that rule in multiple places. In Perl terms, that means that I'll be happily testing my code and suddenly something goes wrong and my script dies in a place I didn't expect. Upon digging into it, I find that the CPAN library I'm using has something like this lurking in it:

if (not $good) {
    Carp::croak("bad stuff happened!");
}

Or...

if (not $good) {
    die "badness here!";
}

Sigh!

This means I have to read the code a bit more and see if I can discern why the developer wants my script to die in some cases, but in others he's content to just do this:

if (not $good) {
    $@ = "bad things happened";
    return undef;
}

What is it about some errors that makes them fatal while others aren't so bad that I'm deemed able to deal with them? Why has this developer taken that decision away from me? It makes no sense at all.

What this means is that I then need to litter my code with ugly crap like this:

eval {
    $object->methodThatMayDie;
};
if ($@) {
    # handle error here
}

The problem with that, aside from the fact that I'm dealing with another developer's inconsistent coding, is that it pollutes my code and forces me to make yet another frustrating decision.

Do I use a small number of big eval blocks and give up knowing exactly where the code died? Or do I pollute my code with a larger number of smaller eval blocks so that I can react to specific problems with a more specific solution? That means the module developer would have had to document which methods or functions may die on me. Otherwise I have to go trudging through their code and waste my time figuring that out. Guess which is more frequent.

Or do I override the module's use of die or Carp or whatever. I can do it, but that has other side effects I probably don't want to deal with either.

Why do I even need to deal with this in the first place? Can't people provide consistent interfaces? Is there something so bad about returning an error code and leaving it up to the user of your code to decide how to handle error conditions?

Maybe they do want to exit() or die(). Maybe they want to retry the logic after waiting a bit. Maybe they want to page someone and log the failure. Maybe...

You get the idea.

This whole concept of "fatal" exceptions seems wrong to me. Unless things are so bad that the kernel is going to kill my process, I should be the one in charge of deciding when my code will blow up. And I shouldn't have to do extra work to asset that authority. Should I?

I know that in the Java world, it's common to do a bunch of stuff in a big try block and then try to figure out what, if anything, blew up later. But I'm a firm believer in dealing with specific problems at the exact place they occur.

I really wish more people thought that way. It'd make my life easier.

Ubuntu Kung Fu: Best Book Cover Ever!

I just ran across news that Ubuntu Kung Fu is Shipping and happened to look at the cover. As a cat lover and technical book author myself, I felt a little slighted.

That's right. Keir Thomas got a kitten on his book.

That kicks ass.

But even better, Ubuntu Kung Fu (PDF and printed) sounds like a real winner for day-to-day Ubutnu users. As the marketing blurb says:

Award-winning Linux author Keir Thomas gets down and dirty with Ubuntu to provide over 300 concise tips that enhance productivity, avoid annoyances, and simply get the most from Ubuntu. You'll find many unique tips here that can't be found anywhere else. You'll also get a crash course in Ubuntu's flavor of system administration. Whether you're new to Linux or an old hand, you'll find tips to make your day easier.

In other words, it's a book that nearly everyone using Ubuntu could benefit from. I'm hoping to grab a copy shortly. Have a listen to Keir Thomas on Ubuntu Kung Fu in this week's Pragmatic Podcast.

Also available on Amazon.com.

Mustard Lime Beef Steaks Recipe

A few days ago I made a new grill recipe that turned out even better than we expected, so I've reproduced it here for your grilling and eating enjoyment.

Ingredients

4 sirloin beef steaks (roughly 1" thick)
1/4 cup of dry mustard (Colman's works well)
1/4 cup Worcestershire Sauce (Lea and Perrins works well)
Lime Juice or 1 large lime
Coarse salt (sea salt is what I use)
Freshly ground white pepper

Preparation

Cover the steaks on one side with 2 tablespoons of dry mustard. Pat it down and spread evenly with the back side of a fork. Sprinkle two tablespoons of worcestershire sauce over the steaks, allowing it to soak into the mustard--patting the steaks with the fork if necessary. Dribble a bit of lime juice over the steaks.

Season the steaks with a good amount of salt and pepper. Then flip the steaks and repeat on the other side. Let them marinate for 20-30 minutes while pre-heating the grill.

Cooking

Clean and oil the grill. Cook the steaks on high heat for roughly 4 to 6 minutes per side, aiming to keep them pink on the inside. Do not rotate the steaks to make those nice cross-hatched grill marks. Doing so may knock off some of the mustard and seasonings.

Let the steaks sit for a few minutes. Slice and enjoy. :-)

Unfortunately, I have no pictures to show. But they're most excellent to eat. Trust me.