Well, I’m not going to get current like that…

I need to get IFR current again. I let 6 months go by without doing 6 approaches (actually, only did one). I wanted to fly to KAGC to pick up Laura on Friday, but I couldn’t because of a very thin looking broken layer at about 1500 feet – if I’d been IFR current I could have punched through that and been in VFR on top the whole way. This weekend was pretty clear, so I wanted to go up with a safety pilot and get current again. Saturday, I had to work. So it was Sunday or nothing. I had a brunch to go to earlier, so the plan was to get to the airport at around 1pm, and do some approaches with a safety pilot. My original plan was to do it with Jim, who wanted me to be his safety pilot as well, but he had to cancel. So I called another guy, Lance, who wanted to see what it was like to be a safety pilot. He was available.

When I got to the airport, I found the next problem: the plane I had booked, the Lance (yes, really) had a nose gear strut was almost completely flat. And even worse, the very slow leak of hydraulic fluid in the prop has turned into a veritable shower. There are red spatters all over the cowl, and a red streak covering most of the spinner. (Actually, I just this second got an email from a more experienced person who told me that the red oil is probably from the gear strut as well.) There is no way I wanted to be doing approaches in that. So Lance and I waited until one of the other pilots came back from their flight, which fortunately didn’t take too long.

Once we got into the air, I found the next problem: the breezy conditions made it quite turbulent, especially down low. I should have realized that this would be the case, but I’d put it out of my head. I went out to Geneseo VOR and did one turn around the hold – it was quite bumpy and hard to hold altitude and heading. There were two other planes doing holds there, one at 3,000 and one at 3,500, so I went to 4,000. It wasn’t any smoother up there. One turn was enough, and because of the bumps I decided to skip my usual non-precision approach to Le Roy or Canadiagua and go straight into the ILSes.

The first ILS went ok, except at about 300 feet above decision height there was a tremendous bump and suddenly the localizer needle went several dots off. I wasn’t at full deflection before DH, but it was bloody close. Getting vectored around for the second one, I was starting to feel airsick, so I told approach that I was going to make this one a full stop. Once again, I was right in the donuts until about 300 feet above DH, and it suddenly started going all wrong. At about 100 feet above DH I took off the foggles and landed uneventfully.

Now to figure out what to do with the Lance and its mystery oil leak.

It’s like the worst of the worst

When you’ve worked all weekend, Mondays are the double suck. First of all, you’ve got all the Monday dragginess, like filling out timesheets and morning meetings. And then on top of it you’ve got the accumulated tiredness that you normally feel on Friday, but worse. Plus, on Friday you’ve got that boost from the thought that it’s soon going to be the weekend. For me, it isn’t soon going to be the weekend, and I’ll probably end up having to work some next weekend as well, so a real weekend is at least 5 and possibly 12 days away. At least I’ve got Great Big Sea to look forward to.

Look at that counter click up!

Since I switched from MovableType to WordPress, my blog has gotten almost no spam, and almost all of it was caught by SpamKarma. In the past, I’ve gone months without any WordPress spam, and then suddenly a bunch of it for a day or two, and then none again. Since I upgraded to SpamKarma 2, it’s put a nifty little count of how many spams it had caught down there on the bottom of the blog page. It was up to about 7 this morning. As of right now, it’s up to 43. I suspect it will be higher by the time you read this. I’m hoping this is just another day or two spurt.

Spammers must die, Wiki Spammers doubly so.

A little while ago I set up a Wiki to discuss the imminent loss of the Digitial Aeronautical Flight Information File (DAFIF). Yesterday, the spammers found it. For two days now, some asshole has registered a new account and make his “user page” a spammer link farm. Now I could continue going in and ripping these pages out, but that could get really boring.

I think what I need is to replace the simple Wiki software I’m using (TWiki) with something with a bit more features. Specifically, I’d like to make it so that you can’t start editing until you give the software your real email address, like the way my mailman mailing lists require you to get and respond to a confirmation mail.

Any suggestions? (And yes, I know I asked for suggestions before and then ignored them all in favour of one that was easier to install. I’ll go back and read your suggestions from that time as well.)

SQLite again

I wrote a few days ago about a problem I was having with SQLite, or rather with DBD::SQLite. Turns out that one should never assume that the version you installed on one machine is the same as the version you installed on the other. After making sure the machine I was testing on was up to DBD::SQLite version 1.11, that part of it worked fine.

I’ve been doing some timing tests on the a generator task that generates 26915 waypoints, and doing one at a time it takes about 45-50 seconds and doing two at a time takes twice as long (about 1:30-1:40), as opposed to MySQL which takes 3:40 for one at a time, and 4:45 for two at a time. The fact that the SQLite one takes twice as long when there are two running makes me think it’s probably CPU-bound. The fact that it’s way, way faster than the MySQL alternative makes me think this is definitely worth pursuing.

But there’s a wrinkle. According to a post on the SQLite mailing list, one program can’t commit a write while another one is doing a query, even if the writes don’t involve the same tables. I guess SQLite’s database level locking is pretty stupid. But that’s the problem – there are three different types of things going on:

  • Database reloads – these only happen about once a month, only one at a time, and involve reloading FAA and DAFIF data into the waypoint, comm_freqs, runways and other similar tables. The reload scripts can take a hour or more to run.
  • Database generations – these run in the background, and just query those same tables that the reloads are loading. Lots of these run can run at once, and lots are run every day. As mentioned above, they only take a few minutes to run.
  • Choosing generating options in the web site. These tasks run after clicking one form page on the navaid.com generator and generating the response page. These mostly do some queries, but as well they track what options you’ve chosen so that they will be the defaults next time you come back. It does that by updating some tables which are not involved in the database generations.

Obviously a user doesn’t want to be sitting there waiting for their page to load for as long as it takes somebody else’s generation script to run. I’m going to have to try putting the tables that are used for storing these options in a different database to see if that will enable the pages to update in a reasonable time.