Sunday, October 30, 2005


What I've Learned about Inline Skating and Roller Hockey

  1. Don't buy the $35 inline skates from Wal-Mart. It's hard to skate on them, and they hurt my feet. The $150 skates I bought the next day were worth the money.
  2. Protective gear (helmet, knee pads, elbow pads, and wrist guards or hockey gloves) is another $100 or so, and is definitely worth the cost.
  3. Falling down on a roller rink without pads doesn't hurt much. Falling down in a parking lot without pads hurts a lot.
  4. Kris falling down is very funny (to everybody else).
  5. Carrying a hockey stick around for an hour leads to sore arms and shoulders.
  6. It's a lot easier to shoot the puck when not wearing skates, and a lot easier to skate when not carrying the stick.

Friday, October 28, 2005


Flying Lesson #61: Dual Night

I made a night flight tonight with my instructor. I made five full-stop landings, which in conjunction with my night cross country flight completes the FAA's night-related training requirements. We also did stalls, steep turns, and an engine-out simulation. We didn't get to everything in the lesson plan, so I'll have another short night flight next week to finish it off.

Logged tonight: 1.7 hours dual night in N4363D, with five takeoffs and five full-stop landings.

Two and a half lessons to go . . .

Wednesday, October 26, 2005


Flying Lesson #60

Made yet another practice-area flight. The weather was cool and clear, which was nice, but the air was pretty bumpy, so all these maneuvers I've been trying to perfect were not close to perfection. Still, it was good practice.

Logged today: 1.9 hours solo in N4363D, with 5 takeoffs and 5 landings. Cost: $207.

Three lessons to go . . .


Fast Mode

It seems that, in every software project I'm involved with, I eventually get asked this question in a meeting:

Kris, is there a "fast mode" we could use to improve performance?

Why yes, of course! Why didn't I think of that? I could just turn on fast-mode, and then performance will be twice as good. And then I guess I could disable slow-mode, which would double performance yet again.

Thank goodness I have managers who can correct these silly oversights on my part.

Tuesday, October 25, 2005


Roller Hockey

A couple of co-workers have talked me into buying some inline skates and playing hockey with them.

I expect to be severely injured. I may finally get some use out of those health benefits I've been paying for all these years.


What Does "++x++" Mean?

As one of my team's know-it-alls, I had a brief language-lawyer question presented to me today: What does the expression "++x++" mean in the C++ programming language? (All you non-programmers, and most programmers, will want to stop reading now.)

The C++ language, like its predecessor C, includes an operator "++" which increments the value contained in a variable. (The C++ language includes this operator in its name—meaning that it somehow "one better" than C.) The ++ operator can be prefix, as in "++x", or postfix, as in "x++". The difference is that the prefix operator first increments the variable and then returns its new value, whereas the postfix increments the variable, but returns its original value. So, for example, this code

  int x = 10;
  int result = ++x;  // prefix
  cout << "x = " << x << "; result = " << result << endl;

will generate the output "x = 11; result = 11", whereas this code:

  int x = 10;
  int result = x++;  // postfix
  cout << "x = " << x << "; result = " << result << endl;

will generate the output "x = 11; result = 10".

There is also a "--" operator, which works like "++" except that it decrements the variable rather than incrementing it. All this discussion of ++ also applies to --.

So, the question is, can you use the prefix and postfix operators at the same time on a variable, and what would the output be?

  int x = 10;
  unknown_type result = ++x++;    // prefix and postfix
  cout << "x = " << x << "; result = " << result << endl;

Some unthinking people guess that the variable x would be incremented twice, and then make even worse guesses about what result is going to be. Nope. The above won't even compile, as it is not valid C++. If you try to compile it, you will probably get an error message about an "invalid lvalue."

To understand why, first we need to define what an lvalue is. Simply stated, an lvalue (pronounced "ell-value") is an expression that can appear on the left side of an assignment statement. For example, in this code:

  int a, *p, **q;
  int& r = a;
  a = 10;
  p = &a;
  *p = 11;
  q = &p;
  **q = 12;
  r = 13;

the expressions a, p, *p, q, **q, and r are all lvalues. In contrast, 10, &a, and &p are not lvalues. You can't write an assignment statement that starts with "10 = ..." or "&a = ..."; it just wouldn't make sense.

Earlier, I wrote that the ++ operator increments a variable. Technically, it can increment any lvalue, which it does by retrieving the value from its location, adding one to it, and storing the new value back to the location. (Optimizations can shorten that series of steps; I'm describing the logical operation.) So, "++x" is roughly equivalent to "x = x + 1" (or "x += 1"). If p is a pointer variable, then "*p" is an lvalue, and we can use the expression "++(*p)" to mean "*p = *p + 1". Another way of thinking of an lvalue is that it is some identified location in memory where we can store a value.

So now, let's look at "++x++". Our first question is about operator precedence: does the prefix operator take effect first, or does the postfix operator take effect first? The answer is that the postfix operator has higher precedence, so "++x++" is evaluated as "++(x++)".

Now let's pretend to be a computer and try to interpret and evaluate this. To make it concrete we'll assume that the initial value of x is 15. We evaluate the subexpression "(x++)", which sets x to 16, and returns the original value 15. Now, all we have to do is plug that result into the overall expression, and we have our answer.

But wait, how do we evaluate "++15"? We can't. Remember, ++ only works on lvalues, and 15 is not an lvalue. It's as if we are trying to evaluate "15 = 15 + 1", which is nonsense in C++. If you thought our new super-expression would be "++(x)", with x equal to 16, note that the result of "x++" is 15, not an lvalue.

So, "++x++" is not a legal expression, if x is an int, or long, or another such built-in integer type. Is there any way to define an x such that it would be a legal expression? One way is to create a user-defined type that provides definitions for the prefix and postfix ++, like this:

  class DoublePlus
    // prefix operator
    DoublePlus operator++()    { return *this; }
    // postfix operator
    DoublePlus operator++(int) { return *this; }

  DoublePlus x;

Then the expression "++x++" will compile. It won't do anything, as written here, but one could define whatever effects are desired for the two operators. Heck, one could even make them increment a value, but that's beside the point.

By the way, note the bizarre unused int argument in the second operator++ declaration. That's how the compiler tells the difference between the definitions of the prefix operator and the postfix operator. This is one of those elegant features that really endears C++ to its users.

So anyway, by creating a user-defined type, I can make "++x++" a valid expression, and make it do whatever I want. I can't figure out any way to do it without a user-defined type. I've tried various combinations of pointers and references, but the best I can come up with is something like "++*x++".

If anyone knows how to do it, or can prove it impossible, please let me know.


Watching TiVo'ed Programming on a Mac, Part 2

Thanks to a comment from megazone on my last post, I tried watching a converted MPEG-2 file using VLC media player, and it works. Sweet!

Even better: I can view the file over my home network; there is no need to copy the file over to the Mac to watch it. That saves me an hour.

I still might give EtiVo a try, because its compression feature will allow me to store more movies on my hard drive.

Maybe Apple or TiVo should license the MPEG-2 codec from the VLC people. Then maybe we Mac users could have our own TiVo Desktop application.

Sunday, October 23, 2005


Watching TiVo'ed Programming on a Mac, Part 1

I like my TiVo, and I like my 54-inch TV, but I've wanted to be able to watch things while working at my Mac. I knew TiVo had added some network features to their software, allowing users to move files from the TiVo to a computer, but I'd been too lazy to figure it out. This weekend, I finally gave it a go.

The first task was to figure out how to hook the TiVo up to my home network. The TiVo does not have a built-in Ethernet port, but does have a couple of USB ports, so a USB network adapter is needed. I wanted a wireless solution, but a glance at TiVo's supported wireless adapters for my older-model TiVo showed only a bunch of old adapters that are no longer available at the retailers I checked. So I had to get a wired adapter.

My DSL modem and router were in a back room, next to my Windows PC. I didn't want to run an Ethernet cable all the way from the TiVo to that back room. So, I spent an hour unplugging things, moving them around, and plugging them back in. Now my DSL modem and my router are right on top of the TV. In addition to letting me plug in my TiVo, I can now plug my Mac into the router, rather than relying on wireless. I bought a Belkin USB wireless adapter for the Windows PC that is in the now-routerless back room, but it didn't work reliably. So I bought a D-Link USB wireless adapter, which works like a charm. Lesson learned: Belkin sucks.

Next, I needed to figure out what software would be needed to get the video out of the TiVo and onto my Mac. It turns out that there isn't any. There is a TiVo Desktop application for Windows that can transfer videos, but they don't have a Mac version yet. (There is a Mac version of TiVo Desktop, but it only transfers pictures and music, not video.) There is an HTTP server built in to the TiVo that can be used to extract the files, but they are in a format that is not usable on the Mac.

After some research on the Tivo to Go Unleashed! page, I decided to try the following:

  1. Use TiVo Desktop on a Windows box to copy a video over to the Windows machine
  2. Use the DirectShow Dump utility to convert the .tivo-format file to an MPEG-2 file.
  3. Copy the MPEG-2 file to my Mac, and watch it using QuickTime Player or Windows Media Player (whichever one worked).

So, I tried these steps, which took about two and a half hours: one hour to transfer the video from the TiVo to the Windows machine, half an hour to do the conversion, and then another hour to transfer the converted video to the Mac. I tried opening the file with QuickTime Player, with Windows Media Player, and even with RealPlayer. Each application reported it was unable to deal with the file format.

It turns out that Apple doesn't provide an MPEG-2 codec with QuickTime. They will sell you one for $20. So I dinged the credit card and downloaded and installed the codec. (By the way, this requires a reboot. It felt like Windowsland.) I tried playing the video again. This time, I was able to hear the audio from the movie, but the video didn't work—it just stayed stuck on the first frame of the movie.

The MPEG-2 file plays fine on the Windows machine. It just looks like Apple's MPEG-2 codec is somehow incompatible. TiVo has a support article that states "Not all MPEG-2 codecs will play TiVo recordings properly." I don't know whether to blame TiVo or Apple for this incompatibility.

So that looks like a dead-end, but I have a some other routes to try:

I'll describe the results of those experiments in Part 2. I'd welcome any other suggestions.

Why does this have to be so difficult? One answer is that TiVo is screwing its customers with digital-rights-management "features." Thanks, TiVo. Another answer is that Apple doesn't provide good support for video formats other than QuickTime's native format. Thanks, Apple.

Saturday, October 22, 2005


Good-Bye, Three-Two-Lima

My flight school recently sold one of its aircraft, N4332L. I'm sure it's found a good home, but I'm a little sad to see it go. It's the plane that in which I first experienced actual IMC, and was the plane I used for my second solo flight. During March 2005, it was the plane I used most often. But they decided to sell it a few months ago, and since then, I had not flown it much. Now it is no longer on the ramp.

I wonder if she will remember me.

Every airplane has its own personality. N9103M is the plane I've flown most often recently, but N4363D is the one I've flown most during my training. I know which airplane is easiest to get trimmed for level flight, which one has the smoothest-running engine, which one has the best radios, and so forth. I know which one I'd refer to use for the checkride, but I know the others well enough that I'll be satisfied with any of them.

Yeah, I know, they're just machines. But I have a personal relationship with each one, and I'll be willing to fight you if you have anything bad to say about any of them. If I'm not willing to take my checkride in any one of them, I'm not ready to be a pilot.

Friday, October 21, 2005


Flying Lesson #59

I made another solo practice-area flight today, followed by a few touch-and-goes. I was able to finish off the items on the last lesson, and most but not all of the items for the current lesson.

In theory, I only have three and a half lessons to go. I had another lesson scheduled for this evening, but thunderstorms made me cancel that one. There's no reason to try to get these last few lessons out of the way—the chief flight instructor is leaving on a two-week vacation, and I can't do the final "lesson" (a stage check) until he gets back. So I'll have a few extra practice lessons in the meantime.

Logged today: 2.0 hours solo in N4363D, with 6 takeoffs and 6 landings.

Wednesday, October 19, 2005


Flying Lesson #58

Today I flew solo in the practice area and practiced slow flight and stalls. Then I returned to the airport and did some crosswind landings and short-field takeoffs and landings.

I couldn't complete the lesson because it called for normal landings and soft-field landings, and I couldn't do those with a crosswind. So I'll have to do those some other time to mark the lesson as complete.

Logged today: 1.9 hours solo in N4363D, with 5 takeoffs and 5 landings. Cost: $207.37.

Four and a half lessons to go . . .

Tuesday, October 18, 2005


Talent is Scarce Everywhere

Kevin Barnes has an interesting post about finding coders on the subcontinent, referring to Indian outsourcing. His experience is that finding good programmers in India is very difficult, notwithstanding the conventional wisdom that India is filled with talented software engineers who will work cheap.

The whole overseas outsourcing phenomenon has never worried me. I think that if there is somebody somewhere who will do my job as well as me for less money, then that person should get my job. If I haven't done anything lately to convince my employer that I'm worth my pay, then it would be my own damned fault if I were let go. If I am doing a spectacular job, but my employer doesn't recognize it, then I really need to find another job anyway, whether my job gets outsourced or not.

I'm sure that there are millions of people among the billions on the planet who would be better at my job than I am. But I also know that identifying those people is incredibly difficult. Talent is rare, and recruiting and retaining talented people is always going to be expensive, no matter where one looks.

Sunday, October 16, 2005


Flying Lesson #57: Long Solo Cross-Country

Today I flew to a magical far-away land: Alabama. OK, so it's really not that far away, but my route from Atlanta to Montgomery, then to Huntsville, and then back to Atlanta was over 500 miles. I wasn't looking forward to this—I was expecting it to be an ordeal—but it was super awesome. (I really tried to come up with a more sophisticated description than "super awesome," but that's the best I could do.)

The weather was perfect. I do mean perfect: not a cloud anywhere in Georgia or Alabama, cool temperatures, and crazy visibility. I was seeing things clearly from 40 and 50 miles away. When visibility is that good, everything looks closer than it is. I'd see a checkpoint up ahead, and think "Wow, I'm almost there. I'm making really good time," but then it would take another 20 minutes to get there.

As I entered the traffic pattern at Montgomery (MGM), I heard the controller clear somebody for a low approach. Looking far off the approach path, I saw an F-16. I thought seeing an F-16 close up in the pattern would pretty cool, but then the controller told me to extend my downwind leg, as I'd be following the third F-16. So I got to watch three F-16's make low fast approaches and then snap up into very steeply banked turns (85 degrees?). It was like I had my own personal airshow.

When I turned final, the controller had to ask a couple of the pilots to go around, so I saw F-16's speeding over my head as I led my little flying brick down to the runway. After landing and turning off the runway, instead of immediately running through my post-landing checklist like I should have, I watched one of the fighters zip down the runway, and I heard and felt the thunderous WHOOSH as it passed just a few yards behind me. Then a few seconds later, another one did the same thing. Very cool. (And I'm sure the F-16 pilots were equally thrilled to get to see a Piper Warrior up close.)

This flight went a lot better than my shorter Friday cross-country. The weather played a large part in that, but I also felt a lot more in the groove.

If every flight was like today's, the flight school would be getting every cent I earn. As things are, they are only getting most of my money.

Logged today: 5.7 hours solo cross-country, with 3 takeoffs and 3 landings. Cost: $622.

Five lessons to go . . .

Friday, October 14, 2005


Flying Lesson #56: Second Solo Cross-Country

Today I flew solo to Middle Georgia Regional Airport (MCN), then to Baldwin County Airport (MLJ) and back to PDK. The straight-line distance between those three points is about 180 nautical miles, but the flight route is farther than that due to the need to fly around the Atlanta Class B airspace.

I arrived at the airport at about 9:30 AM, but didn't get to take off until after 2:00 PM due to weather.

It should have taken less than 2.5 hours of flight time, but it took me 3 hours because, well, I got a little lost.

Here's what happened: I climbed to my planned cruising altitude of 5,500 feet, and saw thick clouds in front of me with haze beneath them. I decided I'd climb over them to avoid the poor visibility below. After climbing for a minute or so, I remembered that because of the overlying Class B airspace, I'm not allowed to climb!!! So, I stopped climbing, started turning to avoid the clouds in front of me, and then descended to get beneath the clouds. After spiraling down to 3,500 feet, with my attention devoted to watching for traffic, I wasn't where I expected to be, and couldn't identify any landmarks.

I considered that to be "lost," but with the radio navigation aids, I really had a pretty good idea of where I was. I decided to skip my second checkpoint, and go straight to the third checkpoint, which is where I was going to cross Interstate 20. I-20 runs east-west, and I was flying south, so I was pretty confident I'd eventually find it. I found the interstate, then followed it to the point where I was supposed to cross. So I found my checkpoint, but was about 20 minutes late getting there.

Going the rest of the way to Macon wasn't a problem. However, Macon has three airports, and of course, when I finally saw an airport I just naturally flew toward it. I was looking at the VOR and DME, starting to suspect I was in the wrong place, when the approach controller asked "zero-three-mike, are you landing at mike-charlie-november?" After I answered affirmatively, he said "You're heading for the wrong airport. Turn to heading 280 and we'll get you to the right place." He was very nice about it. I just kept saying "stupid, stupid, stupid" to myself.

After landing, getting a Coke, and filing a return flight plan, I took off from MCN for MLJ. MLJ is on a peninsula that juts out into a lake, so it was very pretty and I got that thrill of flying low over water. I did a touch-and-go, then turned north toward home.

Again, there were clouds at my planned altitude, and remembering my earlier mistake, I chose to go under them instead of over them. I had trouble finding one of my checkpoints, but was able to find it by getting on the appropriate VOR radial and tracking it to the right place. Those VOR thingees sure are helpful.

I was a little disappointed with the stupid things I did. However, it has been over a month since my last cross-country flight, which also happened to be my last solo, so it was almost like having another first solo. And frankly, it was good experience to get myself a little lost, because I got to practice getting myself un-lost. On Sunday I'll be making a 400-mile flight, and I hope today's learning experiences will help make that go smoothly.

Logged today: 3.0 hours solo cross-country in N9103M, with 3 takeoffs and 3 landings.

Six lessons to go . . .

Wednesday, October 12, 2005


Flight Plans and Control Towers

When stories such as the Stolen Jet incident make the rounds, people (including the reporters telling the stories) are often surprised to find out that airplanes can take off with a flight plan being filed, or without people in a control tower noticing what's going on. Here's a little explanation of how these things work.

A "flight plan" is information filed with the FAA (in the US) regarding an intended route of flight along with takeoff and landing times and a few other interesting bits of info. A pilot is only required to file a flight plan in a couple of cases:

  1. The flight will be conducted under Instrument Flight Rules (IFR), meaning that the pilot will be in continuous contact with air traffic controllers who will monitor and direct the progress of the flight from takeoff to landing. IFR is required above 18,000 feet, and any time the weather doesn't provide sufficient visibility.
  2. The flight will be passing through airspace that requires identification of airplanes for national security reasons. For example, if you are flying through the Washington, DC area or approaching one of the coasts from overseas, you need to file a flight plan.

Commercial airline flights and many charter operations always operate IFR, but many pilots will conduct flights using Visual Flight Rules (VFR) when the weather permits, even if they are instrument-rated. Pilots who are not instrument-rated have no choice but to fly VFR. A flight plan is not required for a VFR flight.

VFR pilots may file flight plans, but the only real effect of a VFR flight plan is that if the pilot does not call the FAA at the expected arrival time to close the flight plan, then the FAA will start search-and-rescue procedures. Nobody has to give the pilot permission to take off, fly the route, or land. Nobody will be monitoring the plane's position. Nobody will notice if the plane strays from its planned route. Nobody will care if the pilot lies about arriving at the destination. Nobody will care if no flight plan is filed at all.

Now, about control towers: People who fly commercial airlines at big airports tend to expect that all airports have control towers operating 24 hours a day. In fact, most airports do not have control towers. Yes, the airports that host commercial air carriers usually do have control towers, but most small airports are uncontrolled. At many small airports that do have towers, the towers only operate during the day, and close down at night.

At an uncontrolled field, pilots usually use their radios to state what they are doing, so that anyone else listening on the same frequency can react accordingly. However, radio use is not required, and there are plenty of "NORDO" (no-radio) flights. It is each pilot's responsibility to avoid crashing into other airplanes. This might sound like a chaotic situation, but in fact, many pilots prefer this to the chaos of constant radio chatter.

At those small airports that do have towers, the responsibilities of the tower controllers are limited to giving instructions to IFR pilots and ensuring that two airplanes don't try to use a runway at the same time. The tower personnel aren't looking for terrorists or thieves, and are not monitoring flights to determine whether anything "suspicious" is going on. They just want to prevent planes from hitting one another (and the primary responsibility for collision avoidance is still with the pilots, not with the controllers).

Except for IFR flights, and flights into the busiest of the nation's airports (O'Hare, Atlanta, LAX, etc.), it is not necessary for a pilot to follow a schedule or make any arrangements ahead of time to use an airport. When the plane gets 10-20 miles away, the pilot can just call the tower on the radio and state the intention to land. The controllers need no prior knowledge of that airplane; they just fit it into whatever traffic is already landing or departing. Similarly, when a pilot on the ground calls the tower asking to take off, the controllers just give the pilot instructions for getting safely to the runway and off the ground. They don't care where the planes came from, where they are going, or who is flying them; they just want the planes to move safely through their airspace.

At night, the tower may close, but the airport is still open. Many airports have pilot-controlled runway lighting that can be activated by an airplane's radio. An airport with a closed control tower is just like an uncontrolled airport: a pilot can take off or land without talking to anybody or filing any paperwork.

So, here's how to steal a jet airplane for a joyride and get away unnoticed: Take off when the tower is closed, don't use the radio, turn the transponder off, avoid busy airspace, maintain a low altitude and low speed to avoid notice on radar, land at an uncontrolled field (or a field with a closed control tower), high-tail it outta there, and eliminate any talkative witnesses.

When you read a story about a small-plane crash, and the reporter makes a big deal about the fact that there was no flight plan filed, or that the airplane's departure or arrival were "unscheduled," or that the airport staff had no information about the airplane or its pilot, note that these are not atypical events. The government doesn't track small-plane flights any more closely than it tracks automobile trips, and most small-plane pilots consider that to be a good thing.


Stolen Jet

A small jet was found at Gwinnett County airport this weekend. For a couple of days, how it got there was a mystery, but now an arrest has been made. Apparently it was just a joyride by a 22-year-old pilot, who does have a commercial pilot certificate, but no rating for this type of plane. He took five people along with him, and they turned him in. See and for current details.

(More details are available at, but that site requires registration.)

It looks like the moral of the story is that if you decide to steal a plane, you shouldn't take your friends along.

I understand why someone might want to steal a plane, but I wonder about the five people who thought it would be fun to take a ride in a jet with an unqualified pilot. They claim they were unaware that the jet was stolen, but I wonder how they accepted the fact that a 22-year-old was able to give them a joyride in a seven-million-dollar plane.


Think Positive

Code such as the following leaves readers scratching their heads:

  if IsNotUninhibited() != true then

Under what circumstances does DoSomething() get called? Well, it obviously has something to do with whether something is "inhibited" or not, but with all those negations mixed in, it's hard to tell if DoSomething() gets executed when inhibited or when not inhibited.

When I find something like this, I try to refactor it into something easier to understand by eliminating the excess negations. Here are some of the principles I follow:

So if we follow these principles, the above code could be rewritten as

  if IsEnabled() then

Would you fail to deny the rewrite isn't not a lot less unclear?


Flying Lesson #55

The ceiling was too low to go on a cross-country or out to the practice area, so my instructor and I did pattern work, practicing short- and soft-field takeoffs and landings. My landings during my last flight were pretty bad, but today's were OK. Maybe I was just having a bad day last time, or maybe I was having trouble due to optical illusions at that other airport—Cherokee County airport is on top of a hill, so it is hard to judge altitude above the runway.

Logged today: 1.0 hours dual in N9103M, with 7 takeoffs and 6 landings (the instructor demonstrated one landing). Cost: $205.

Seven lessons to go . . .

Tuesday, October 11, 2005


My Arachnid Neighbor

For the past week, a big, scary, beautiful spider has been building its web in the second-story breezeway in my apartment building. It's brown, with wide white bands on its legs. Its body is about an inch long, and legtip to legtip it is about two inches long. I've looked at several hundred spider pictures on the Internet, but haven't been able to identify it.

It's nocturnal, spending its days curled up in a corner, and then starting to build its circular two-foot-wide web an hour or so before sunset. It sits motionless in the center of its web all night. I've never seen it move at night, but I do see insects wrapped up in the web, so it must be doing its thing once in a while.

This evening, however, it is still curled up in its corner. I suspect it has passed away, because I don't think spiders ever sleep in or take a day off. That's too bad—it really was beautiful.

If it stays motionless for a couple more days, I may take it down to get a good look at it and try to identify it. The web sites that help identify spiders note the arrangement of eyes, shape of copulation organs, and other things that I can't see from a few feet away.

I haven't been able to get a good picture, because my camera won't focus on it at night, and its daytime curled-up posture isn't very interesting.

[UPDATE: As of 1:30 AM, the spider was alive and well in its web, in the process of wrapping up a juicy morsel. I guess spiders sometimes do sleep in.]


Another Student Pilot Blog

I ran across another student pilot's blog today: Only three flights so far—good luck with the rest.

Sunday, October 09, 2005


Will It Ever End?

In theory, I should be finished with my flying lessons in a month or two. I have eight lessons to complete: two solo cross-country flights, a dual night lesson, two solo practice-area flights, two daytime dual lessons, and a final stage check. Then I just have to prepare for the checkride. So I should be excitedly awaiting the freedom to fly wherever and whenever I want.

However, my experience with many software development projects leads me to expect the last 10% of any project to take as much time as the first 90%. "Almost finished" often becomes a steady state, as the rate of appearance of last-minute things-to-do outpaces the abilities of the developers to do them. This is when people often burn out and quit, as there is no end in sight, and no matter how hard one works, there is no apparent progress.

I hope flight training doesn't follow the same rules as software projects, but I'm noticing similarities. Due to a combination of work-related conflicts and weather, I really haven't flown much in the past month. My landings and maneuvers are getting shaky, and I'm forgetting little things here and there. The regression leaves me wondering if it's really worth sticking with it. I don't want to get stuck in one of those perpetual "almost finished" states.

Don't worry, I'm not going to quit. I'm just ranting after spending a few hours at the airport today hoping for the skies to miraculously become clear. They didn't. I was supposed to make this flight two weeks ago, but couldn't due to a business trip. Then it was scheduled for last Friday, but was scrubbed due to weather, so it was rescheduled for today, and again we had bad weather. So it is rescheduled yet again, for next Friday. The forecast calls for rain on Friday, so I'm not optimistic, but forecasts often change drastically over a week.

I can be patient. I'm in no hurry to get the license. I hope to be finished before the holiday season, but if it takes another six months, I'll stick with it another six months. I'll just trust that when it's finally over, I'll think it was all worth it.

In the meantime, I'm not going to fret about any lack of progress. When people ask me if I'm finished yet, I'll just have to answer, "Almost."

Friday, October 07, 2005


Bits and Bytes

A bit is the fundamental unit of information in digital computers. It can be in one of two states, usually thought of as on/off, true/false, 1/0, or set/clear. By combining multiple bits, one can distinguish between a lot of states. For example, if you put eight bits together into a byte, the number of distinguishable states is 2 to the eighth power, or 256. If you put two bytes together into a word, then the number of distinguishable states provided by those 16 bits is 256 squared, or 65,536.

It is often useful to think of the states as integer numbers. The 256 states in a byte can be mapped to the numbers 0-255, or if you need signed arithmetic, they can be mapped to the range from -127 to +128. By combining bytes, one can get larger ranges of integers, and by combining one integer value with an integer divisor, exponent or other modifiers, one can represent fractions, decimal numbers, complex numbers, or any other kind of number.

This is the basic underpinning of all data representation in a computer. I wish I could say that the above paragraphs are a simplified layman's explanation, but surprisingly, lots of professional computer programmers don't understand it.

One of my boss's favorite interviewing exercises is to ask the candidate to write a function that swaps the two halves of a 16-bit value. For example, the function should change 1111111100000000 to 0000000011111111, or change 1010101000000000 to 0000000010101010. Trust me, this is an elementary problem, and the simplest most-straightforward implementation takes about three lines of code. Over 90% of candidates can't do it. I don't mean that 90% come close but fail some sort of tricky borderline case; I mean that 90% stare at the whiteboard for a few minutes, maybe doodle a little bit, and then just give up. Even after being reminded of the programming-language operators that manipulate bits, 90% are still totally lost.

Yesterday, one candidate answered the question by saying "I don't think I belong in your group. Thank you for your time," and then he left.

Because of the high failure rate on the above question and our desperate need to find anybody to work for us, the boss has started asking simpler questions, like "Please write the numbers from 0 to 15 in binary." Again, for someone applying for an embedded-systems programming job, this should be trivial. The candidates are generally more successful at this, but there is still a surprising amount of cluelessness. The boss wanted to ask one of the candidates to leave her Ph.D. on the desk on her way out.

It really does boggle my mind. I understand that a lot of programmers consider bits and bytes to be low-level implementation details that should be hidden beneath higher-level abstractions, and programmers who have exclusively worked with higher-level languages may not have much experience with the low level. But why are they applying for C++ embedded-systems jobs if they don't know this stuff? How can someone have 10 years of programming experience, and not know how to toggle a bit?

In my mind, it's akin to a mathematician not knowing how to do addition, or a chemist not knowing the properties of hydrogen. I suppose my background is a little atypical, in that I started with low-level assembly-language programming as a kid and moved up into higher-level languages later, whereas most programmers start with the high-level stuff and remember their one-semester assembly-language course with dread. If one's career consists exclusively of reading data from a database and displaying it on a web page, one may not have ever needed to worry about the individual bits. But still, a programmer who can't make sense out of a hex dump or who doesn't understand why a value of -1 might magically change to 65,535 really needs some remedial training.

If you are a programmer (or want to be one) and you react to this by saying "Geez, I have no idea how to do that stuff either", I'd recommend the following exercises:

Wednesday, October 05, 2005


Flying Lesson #54

After a week and a half since my last lesson, I had a dual lesson with my instructor. We briefly reviewed the results of my stage check, then flew. There was a strong breeze, so I did several crosswind landings. I didn't do them very well. I'd like to blame my problems on the 10-day hiatus, but I've never been very good with them.

We also did several stalls, and some hood work, including an emergency climb and emergency descent.

I have a 190-mile solo cross-country flight planned for Friday, but the passage of TS Tammy may require postponement.

Tuesday, October 04, 2005


Debugging Output

Most computer users have no idea how complicated software can be. It seems very simple, almost like a law of nature, that if one hits the 'A' key on the keyboard, an 'A' will just appear on the screen. Unbeknownst to software users, thousands or even millions of lines of program code may have been executed to make that happen, and it was all written by fallable people. When there is a bug somewhere in those thousands or millions of lines of code, finding it is a daunting task.

To help find exactly where a problem is occurring, software developers create debug output. This is information about program execution which is invisible to the typical user, but which the developer can view when needed. The output usually goes to a log file, or may be visible in a debugger window or other special viewer application while the program is running.

There are two times when developers add debug output to their programs:

  1. while adding new functionality, and
  2. while trying to figure out why some damn thing isn't working like it should.

It is easy to tell the difference between the two kinds of output. The first kind tends to be orderly and descriptive, providing clear feedback about the operation of the program, like this:

10:08:27  opened file "userdata.dat"
10:08:27  24 record(s) read from "userdata.dat"
10:08:28  closed file "userdata.dat"
10:08:29  24 record(s) inserted into data view

The second kind of debug output, typically written in the wee hours while bouncing between states of intense frustration and sleepy delirium, usually looks more like this:

04:23:17  Boo!
04:23:17  open file "userdata.dat"
04:23:18  its working (2)
04:23:18  24 record(s) read from "userdata.dat"
04:23:18  I'm here (2)
04:23:18  closed file "userdata.dat"
04:23:18  hwnd=0x001248de
04:23:19  its still working (2)
04:23:19  it's still still working (2)
04:23:20  hwnd=0x001248de
04:23:20  Hello, and welcome to the comm thread
04:23:23  it's still^3 working (2)
04:23:24  it's still^4 workign (2) and yeah, I know it's misspelled, so what???
04:23:24  xyzzy
04:23:24  hwnd=0x001248de
04:23:25  !!!hey, this shouldn't happen!!!
04:23:25  Sydney Bristow kicks ass
04:23:25  Entering update_data()
04:23:25  I love bourbon
04:23:25  Dave told me to type this
04:23:26  Take this, beeyotch (2)
04:23:26  24 record(s) inserted into data view
04:23:26  Exiting update_data()
04:23:26  hwnd=0x001248de

That second example may seem like complete gibberish, but its usefulness comes from the fact that the developers know exactly what line of code was being executed when each one of those lines of output was generated. What each line says doesn't really matter—all that matters is that each be uniquely identifiable, so that when something unexpected shows up in the output, the developers know where to look. There is no point in trying to make it clear or meaningful, because the developers didn't really know its significance while writing it. The whimsy and crassness in the messages is the developers' way of entertaining themselves during a time when they wish somebody would be kind enough to sneak up from behind with a baseball bat and end the misery.

Ideally, when a problem is found and corrected, the developers will remove the second kind of debug output, or change it to something that would be more useful. Often, they don't, because when the problem is found, they just want to go home rather than cleaning up the mess. This leads to all sorts of stories about embarrassing messages popping up while users are running the program, while giving a demo to an important customer, or while the boss is looking over one's shoulder. Developers should be more careful about what they write, but their senses of humor and judgment often deteriorate while debugging.

If you ever run across strange or insulting messages while running a program, don't take offense. Just think of the poor developers working a 16-hour workday who wrote the message. The developers didn't really want you to see the message, but it is a human plea for help and comfort. You're getting a glimpse behind the curtain.

I'm an obsessive believer in beautiful code, so I have an irresistable urge to delete or fix this stuff whenever I find it in code that I have to maintain. (If I don't remove it, at the least I need to fix the spelling and punctuation.) So my plea to other programmers is to please clean this stuff up when you don't need it any more.

This page is powered by Blogger. Isn't yours?