Jeremy Zawodny's blog

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.

View Larger Map

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.