A Rant About Splash Screens

(This might look familiar to some people)

Can somebody please shoot all the asshole software designers who make a splash screen that remains on top even if you switch to another application while it’s loading? I don’t want to fucking see the fucking credits for your software every time it loads, fuckers. I especially don’t want to see it blocking my view of what I’m working on in the interminable time it takes you to load your software. Adobe, I’m looking right at you.

Oh Google, you are so devoid of any semblance of clue

As I wrote about in Rants and Revelations » Hey, Google, Google still hasn’t reimbursed me for my hotel, cab and food while I was in New York City. Today, I discovered why. Evidently when one of their recruiters leaves them, instead of arranging some sort of orderly transfer of her unfinished work to somebody else, they just throw all her email into the garbage and mark any mail that she hasn’t dealt with “Return to Sender” and send it back. I got my reciepts back, over a month and a half after I sent them, which means that undoubtedly they fished them out of her inbox rather than just refusing them at the front door. So I wrote to the only other recruiter there I have been in contact with, and he gave me the name of a third recruiter that I need to send all my stuff to, including the claim form that I’d emailed to the first recruiter on July 21st.

You know, if their tech departments were run as well as their recruiting organization, Microsoft could stop worrying about them.

Note to self: Xen config

Once again, my blog becomes my own personal scratch pad for things I want to remember. In this case, what to do with Xen domUs that install udev:

– login to the VM using “xm console ID”
– edit /etc/udev/persistent-net-generator.rules
– insert the following at the top, just below the first comment block:

# No persistent interface names for Xen VMs.
KERNEL==”eth*”, GOTO=”persistent_net_generator_end”

– remove the existing persistence “database”:

rm /etc/udev/rules.d/z25_persistent-net.rules

You’re not expected to understand or care.

What a difference an index makes!

I made some changes to my FAA data loader script and ran it. Four days later it had finished running, I discovered a few bugs, and was getting ready to run it again, but I decided to see if I could improve the speed any. I’d already run the perl profiler and discovered that 95% of the time was spent in mysql. So I tried doing an “EXPLAIN” on all the queries. That’s when I discovered that one very common query was doing the dreaded “ALL” query on a 12,000 row table as step 1. Hmmm. That table isn’t even an important one, it was just table joined to the main “waypoint” table to get one field that was semi-useful. The query has a “waypoint.datasource_key = ?” in it, why isn’t it doing that first? “DESCRIBE TABLE waypoint;” showed me the error of my ways – I’d forgotten to put an index on “datasource_key”.

So I created the index and started the script before going to bed. I was astonished to discover that the script was done this morning. According to my Munin graphs, it had only taken about 6 hours to run. 96 hours down to 6 hours. Yeah, that’s a worthwhile optimization.

Fun fact #143.4

Discovered while trying to debug my nav data loading scripts: The Hendersonville Airport (0A7) and the “W.N.C. Museum Airport” (8NC9) are only 0.03 nautical miles apart, but they’re separate airports. I’m not sure if they’re the closest two ever, but they’re certainly pretty damn close. As a matter of fact, I think this picture Hendersonville Airport from the AirNav.com web site listing for Hendersonville shows both runways, the paved one for Hendersonville and the turf one for the museum. I bet there is a story why they didn’t just build a taxiway between them and call it one airport.