About the only time a "Manager" is acceptable is if the code for the thing it manages is outside your control. Otherwise, "Manager" is almost always an instant sign of a functional design that's pretending to be object-oriented and failing miserably.

Or, put another way: Classes called "Manager" almost always violate the single responsibility principle.

Testability is critical, but it's pointless without actual tests. By tests, I do not mean a single test case verifying only the "normal" path where everything goes exactly as expected. I mean testing every boundary case, varying degrees of complexity where applicable, and failure modes, ensuring that it fails in the way that it is intended to fail and in every case where it is intended to fail.

Just as a follow-up, minasoko has pointed out in reply to another of my comments that ADS-B data shows the copilot specifically set the autopilot to fly to an altitude of 100 feet. As much as I want to give this guy the benefit of the doubt, for me, that pretty much rules out any possibility that this was not an intentional action by the copilot.

Incidentally, the similarities to EgyptAir Flight 990 are stunning.

I wasn't aware of the ADS-B data. That definitely seems to be a pretty insurmountable piece of evidence against any kind of an "unintentional" theory.

I can believe this. But what if, instead of falling against the switch, the copilot, recognizing that he was about to pass out (e.g. recognizing symptoms of an impending stroke), intentionally attempted to move the switch to the "unlocked" postion (to make it easier for the captain to get into the cockpit quickly)? Due to a combination of confusion, physical incapacitation, and infamiliarity with a probably rarely-used control, he could conceivably have turned the switch to the wrong position even while he was attempting to do what he thought would be the best possible action.

As far as I can tell, this is nonsense. Under "normal law" in an Airbus autopilot system, sufficient pressure on the control stick will override the autopilot system. For downward pitch, the autopilot system will allow up to 15 degrees of downward pitch to be commanded without removing the autopilot system from "normal law"; other autopilot functions will continue to function normally. I'm not sure what the exact result of 15 degrees of downward pitch would be, but I'm pretty sure it would be a rapid but controlled descent—exactly what the telemetry shows.

The evidence does seem to be getting stronger, but I'm not quite ready to conclude that this was intentional. The fact that the co-pilot was breathing does not necessarily indicate that he was conscious. If he became unconscious, he could easily have fallen into a position where his body was pushing forward on the control stick. This would override the autopilot and cause the plane to descend under "manual" control. As far as I know, they still haven't found the FDR, so there's really no way to tell whether or not the "manual" control inputs were intentional (i.e. varying inputs with relatively light pressure would probably indicate intentional control; relatively continuous inputs at an extreme input position would probably indicate unintentional input). The locked cockpit door is harder, but not impossible, to explain: I'm not familiar with the design of the switch, but it's conceivable that he could have fallen against it and knocked into the locked position; perhaps more plausibly, he may have recognized that he was about to pass out (I have personally fainted due to low blood sugar a few times, and it generally doesn't happen without at least a few seconds of advanced warning) and, attempting to turn the switch to the "unlocked" position in order to simplify a hasty ingress of the captain, may have inadvertently turned the switch in the wrong direction. Before we vilify this guy posthumously, let's make sure we have precluded all other options.

Well, in a full motion simulator it's not impossible to surmount--anyone who has ridden on the Mission Space ride (especially the orange version) at Disney World will confirm that (it's an awesome ride, by the way). But unless you have a few million dollars to squander, yes, the feeling of acceleration would fall into that category of "non-visual sensory inputs" that you just can't get from a game. Great point.

LOL, I fail to see how the availability of expensive peripherals that provide improvements negate my comments, which were about "typical" setups. The average gamer has neither a high-tech, $300 wheel nor a $150 helmet (which still doesn't provide any form of peripheral vision).

Have Slashdot stories always been this ridiculous and I just haven't noticed before?

Even using the most realistic settings, most video racing games fail to physically equate to real-life driving—for instance:

• Typical racing wheels allow 1/2 to 3/4 turn of the wheel, lock-to-lock; a typical passenger car has well over 3 turns lock-to-lock, and even a high-performance sports car has over 2.
• Peripheral vision, which is very important in real-life driving, is completely lost in video games; many racing games do not even allow you to look in a different direction than you are going (e.g. turn your head to look left while continuing to drive straight), and those that do allow it require some button-press that is not the same as just turning your head.
• Most non-visual sensory inputs to driving (slight variations in vibrations, etc.) are lost in video games.

So there's no doubt that there's little, if any, physical correlation of video game driving skills to real-life driving skills, even in the most realistic games. However, more abstract skills learned in video gaming, such as situational awareness and reaction times, certainly do apply to real-life driving, especially in high-pressure accident-avoidance situations, where the split-second reaction times honed by racing games are clearly advantageous. Clearly, that was outside the scope of this "study", but the conclusion stated by the title of this post is entirely erroneous.

Did you even bother reading the whole comment? "Agencies often cite more than one exemption when withholding part or all of the material sought in an open-records request."

HA! This has to be the best comment I've seen on Slashdot, ever! You hit the nail on the head!

I took all of my notes throughout university (including engineering courses) using OpenOffice.org. The equation editor in OpenOffice is easy-to-learn, fast (as in, no mouse use required and the keystrokes are all sane), and the completed equations look great. (By default, there isn't a keyboard shortcut for inserting a new equation, so you'll need to manually assign one—I used Ctrl-Shift-F, if I remember correctly.

Your example would almost work as is; it would be entered as:

f_x (x) = int from -infinity to infinity f (x, y) dy

Or, if you prefer your parentheses to stretch (in case you have fractions inside, or what have you):

f_x left ( x right ) = int from -infinity to infinity f left ( x, y right ) dy

Either way, it comes out looking very nice. The one thing that takes some getting used to is that you need to make liberal use of whitespace (e.g. between f and the opening parenthesis of the function), otherwise things will occasionally come out looking a little strange. The best part is, when you don't know what you need to type for a particular symbol, you can select it from the menu and OO will insert the plaintext code, which makes it very easy to learn the code for new items.

From the linked article: "The books published by The Espresso Machine will have a recommended sales price of $8 per copy, although the final decision will be left to each retailer."