In response to the stall, first officer Robert took over control and pushed his control stick forward to lower the nose and recover from the stall; however, Bonin was still pulling his control stick back, lifting the nose further up. The inputs cancelled each other out.
Rookie mistake. (1) You always clearly announce who is in control of the aircraft. Generally this is announced by one pilot saying "my controls", and the other responding "your controls." Two pilots trying to do the opposite action is rookie mistake number 1.
(1) When the aircraft is in a stall, it's because insufficient air is flowing over the wing, and the wing cannot provide lift. This is solved by pushing the nose down, allowing the aircraft to regain airspeed. Bonin, the co-pilot, was pulling the stick back, which can only be read as that he panicked, and forgot training he should have learned while learning how to recover from stalls waaaaaay back when he first started learning to fly and got his basic pilots certificate. The pilot pulling when he should push is rookie mistake number 2.
On top of all of this, your assertion:
Your desire for pilots to fly the plane manually is laudable, but planes have become highly sophisticated beasties.
Are you asserting flying is too hard for humans? Because that would worry the fuck out of me. Or are you asserting flying commercial jets is hard? Because there I'd completely agree with you; the most complex thing I've flown is a single-prop high-performance retractible out of a Class C airport in IFR, and the idea of flying a jet is intimidating as hell. But then, that's why the guys who fly commercial jets get additional training: to learn how to keep ahead of these highly sophisticated beasties.
Because the correct way to design an airplane is to assume everything is going to go haywire: that the GPS satellites have all been taken over by Skynet, the computer has become depressed and suicidal, and the autopilot motors have all decided to play poker in the cargo hold.
Autopilot systems are generally designed to allow the pilot--with sufficient force--to override the autopilot motors in the event the autopilot acts up.
(I once flew a DA-40 whose autopilot decided a hard left turn was the right answer--it took a little upper-body strength, but not a lot, to force the plane from flipping over while I reached for the breaker to turn off the autopilot. Same principle applies in large aircraft like 737s, and that's by design.)
First, all pilots are trained to fly the airplane manually, with all air surfaces controlled by hydraulics on most aircraft. Electric motors are also connected to these hydraulics to allow the autopilot to fly the airplane, but as a convenience. Pilots are supposed to know how to fly the airplane without the use of the autopilot and by using radio signals received by VORs (radio-directional beacons) in order to navigate using a paper chart (or an iPad with a chart on it).
That Air France Flight 447 went down was not due to "poor training" or because of a lack of ability to detect a cyber-attack, but because the copilot in that airplane panicked and pulled when he should have pushed. (Frankly his mistake was a rookie mistake that student pilots are supposed to unlearn within the first 20 hours of training.)
Now are there attack vectors which can be used to sabotage an airplane? Absolutely--but they're not the "I plugged the laptop into the network and hacked the airplane's firewall" variety, since most aircraft (certainly the 737) run parallel networks--with the avionics physically disconnected from the entertainment and WiFi systems used by the passengers.
Attack vectors would be for a passenger or someone on the ground to jam and spoof GPS signals, and to jam and spoof directional VOR and ILS transmissions, to fool the navigation equipment on the aircraft to think it's somewhere it's not. Another attack vector is jamming and overriding the air traffic voice and text communications by someone spoofing air traffic control.
The problem is exacerbated by NextGen, where aircraft broadcast their GPS location (rather than their location being detected by ground-based radar), so it makes it harder for Air Traffic Control (who watches all commercial aircraft like a hawk, alerting pilots if they deviate from their flight plan) to determine if someone has gone off course. And of course the problem is made worse by inattentive pilots who often sit around the cockpit bored when they are supposed to be monitoring the navigational equipment to make sure it looks correct. (Remember when two pilots flew off course because both of them fell asleep at the wheel?)
But onboard cyber-attacks? Puh-lease...
The solution to all of this is the solution first taught to student pilots flying their first Cessna 172: fly the damned plane. Left hand on the yoke, right hand on the throttles, both feet on the rudders, and do that stick-and-yoke thing so many of them have forgotten because they think the computer is the best pilot in the cockpit.
If I had my way, the first thing I'd mandate is that all commercial pilots--including those flying the largest A-380 airplanes--spend at least a few hours a month flying the same Cessna 172 they learned in. That way they remain viscerally connected to flying by stick and yoke--and when the computer acts up, as it always seems to do at the worst moment in the cockpit, you can still look out the window, see that piece of cement in the distance, and put the airplane down where it's supposed to go.
The real question is "why is the cockpit navigational equipment connected to the Internet," and the answer is "it isn't." Nor is the autopilot on most designs.
Notice when the current giants in the market became giants: after the passage of Sarbanes-Oxley, which made it far more difficult for mid-sized startups to go to the public markets for funding. When the only practical exit strategy left to you is to be bought out by a Facebook, a Google, an Apple or a Microsoft, then the only strategy you have left as an entrepreneur is to figure out what will get you bought out, rather than going head to head with the large companies as Google once did against a Lycos or an Altavista.
Without the additional requirements in Sarbanes-Oxley which made accessing the public markets much harder, would we be talking about Github being bought out by Microsoft? Or would be be talking about Github's IPO?
Given that it has taken some GA aircraft manufacturers a decade to go from "idea" to type certified aircraft, I don't see how Uber--who has absolutely zero track record in the airplane business--will manage to get something that is legal to fly in such a short period of time. Worse for them, the FAA is a fairly conservative bunch who are very safety focused, which means Uber may find themselves (as the new kid on the block) facing a whole bunch of questions about the new aircraft's safety, including safety in the event of a partial engine failure. And since they plan to use this vehicle almost exclusively for commercial transport, they may find themselves facing even more stringent requirements than you normally see with stuff flown by part 91 pilots.
And unmanned aircraft? You know, the first phone selfie video of someone in one of Uber's aircraft as it plummets to the ground (taking several minutes if Uber's self-flying aircraft is in the 8,000-9,000 altitude range) will pretty much destroy Uber in lawsuits.
The problem, both with your examples and with your argument, is that they mix morality and money.
Now I'm all for morality. God knows I've been a strong supporter of LGBT causes and my (Scots-Irish) father in another era spent some of his misspent youth in Memphis protesting for black equality. I'm also all for money--and using money to build an organization, to hire people, to create wealth and to build something that adds to the economic gestalt. I'm even for consumers being picky with their money, deciding to spend their money on things they support, such as organic farming or refusing to cater to businesses who don't treat customers with equality and respect.
But it has been my experience that when we start mixing morality and money on the grand stage, both money and morality lose. And that's precisely what you're advocating here: that we as a society (rather than as individuals) choose how we spend our money based on a moral framework that, more often than not, is incomplete once we move onto the grand stage. (It's easy as a consumer to avoid a bakery who refuses to sell a cake to a gay couple. But as a society do we punish the Kosh Brothers for their stance in criminal justice reform, a position taken for a decade before President Obama praised their position? Or is it more complicated than that?)
So sure, take your moral stance on Peter Thiel. If y'all don't want him in California, we'll certainly take him in Raleigh. There are plenty of people who aren't as repulsed by his politics, and certainly we'd be happy to spend his money in areas like the American Tobacco campus in Durham, which has a bustling startup culture and which has the potential to create significant employment opportunities for minorities.
Because let's "spread that money around a little" (as a famous person once quipped) and help build some wealth before we start spitting on someone's assistance.
Our old A/C unit finally gave up the ghost and so we had to replace it with a new compressor and air exchange unit. We bought a top of the line unit, which the installers were able to put into place in just a couple of hours. And of course the unit didn't work: when plugged in, the thermostat gave a '443' error, which the installers simply could not figure out.
The next day a technician came out to diagnose the problem. It turns out the software on the outside compressor unit was incorrectly configured, and the '443' error indicated a mismatch between the air exchange unit inside the house, and the compressor on the outside. A few minutes with a laptop and the software in the compressor was correctly configured, allowing the system to work.
In the old days, the compressor was simply a fan, pump and baffles which allowed the coolant to be heated or cooled, running to an inside comp, fan and baffles which then blew the heat or cold air off the coils and through the house.
Today's A/C unit has a microcontroller in the compressor to measure a bunch of diagnostic information, a microcontroller on the heat exchange unit, and the thermostat contains a microprocessor which monitors all this diagnostic equipment. It's great in that I was able to get into the diagnostic settings and change a few properties to allow our A/C unit not to blow so hard at night (when we're sleeping), and to favor using the heat pump at colder temperatures in order to save power--even though in the winter it may take longer to heat the house up. The thermostat shows us the outside temperature at the compressor on the main screen, and will give a five day weather forecast when hooked up to the WiFi network in the house. It can cooperate with other thermostats in a zoned house to optimize energy usage. It will even notify the installers (if we wish) with diagnostic problems if there is a problem with our unit, so they can more quickly diagnose and fix problems as they arise.
But there are a hell of a lot more moving parts than the older A/C units--and a hell of a lot more things that can go wrong.
It is incredible for 60% of the Americans, the home they live forms more than 50% of their networth!. Homes are very very illiquid.
Which is why so many home owners who bought a home have done relatively well: because a home represents illiquid forced savings. The problem is most folks, if they had a pile of cash rather than an investment instrument (which earns crap returns but is still saved), will blow it on toys, trips and stuff rather than put it into a good investment portfolio. So while in theory investing in a home isn't as good as potentially other investment instruments (though please subtract the cost to rent, because you have to spend something on a home, because it's awkward for millionaires to live in cardboard boxes under an overpass), in practice investing in a home works out better for most folks than the alternative.
The big thing to remember is if you plan to stay in an area less than 5 years (in general), you are much better off renting than buying. Most of the stories I've read about people doing well buying instead of renting (and that includes us; we bought a house in Glendale in 1996 after the Northridge earthquake, and moved out 18 years later to Raleigh, using equity to pay cash for our home here in North Carolina) involve people staying in the same home for many years.
But if you buy in an area and plan to leave in less than 5 years, at the very least the cost to get the home ready after purchase and the 6% you lose when selling your home will probably eat up any (minimal) equity and appreciation you got in your home.
Remember: for most of the country, housing prices only go up at roughly the rate of inflation. Only in a few areas (like California, New York, or parts of Las Vegas) do housing prices appreciate substantially faster.
No, but the CEO, along with the CTO, are responsible for creating the policies which drive the procedures for the company. So while he may not be expected to know the specific implementation, he should know the policies and goals for corporate security. Bouncing those policies to some "VP of Security" only means those policies will not be taken seriously.
Of course developers should test their own code by running it in the debugger and making sure they're not checking in obvious garbage.
And of course developers should do unit testing modules to verify the correctness of certain libraries and submodules of their code. This correctness helps to make sure submodules behave correctly.
But you need a separate QA team. And you need two types of testing: directed testing (with specific testing instructions to test components of the software) that are put together by a QA manager. And you need undirected testing--basically QA folks just screwing around with the software.
There are several advantages of having a separate QA team. First, QA testers do not have to have the same level of experience as software developers, and so you can hire testers with less experience and for a lower salary. (If you have a QA manager who writes good test instructions, you can pretty much hire damned near anyone to test the software. I mean, presumably if your software is used by any random person off the street, you should be able to hire any random person off the street to test, right?)
Second, developers often wind up concentrating on a few modules when adding features or fixing problems, and so often fail to do adequate integration testing across the product, looking for unexpected side effects. (In essence, the biggest problem are those "unknown unknowns" which cannot be found unless someone just farts around with the software.)
(And don't tell me all this should be automated. That sort of automation is basically front-loading all the possible testing you may want to do--and completely ignores the institutional knowledge of your product gained by QA testers playing with the product. In the past when I've gone to work for companies with a well staffed QA team, I first go to the QA team, not to the development team, to understand how to use a product.)
In general I'm a big believer in the model of software developer as a Knight surrounded by support staff. Your developer is probably the most expensive person on your payroll--so why waste an expensive resource on stuff that can be offloaded to people who can probably do various support jobs more efficiently for a lower salary? I know that sounds a bit brutal, but there is definitely an efficiency argument for software developers not writing business requirements, manning customer support lines, or doing customer sales--so why the hell do we expect developers to take over testing?
Which wouldn't bother me if we had private-funded healthcare as a viable option. But since we don't, I guess it's up to Big Brother, since the moment a third party pays, it's no longer just about me and my doctor, right?
Ah, hell; just put the center of mass below the plane of the cuisinart blades so the weight hangs from the blades rather than is balanced on top, and it would help some with stability. I mean, even small low wing aircraft shape the wings as a 'V' with the center of mass below the bulk of the lifting surface, so as to have positive static stability...
Came here to say that. I mean, who puts the whirling blades of death at kneecap level without any sorts of guards? All you need is a poorly timed kick (in reaction to losing your balance, say), to have the bottom half of your leg chopped off by one of those four spinning Cuisinart blades...
Well, remember: in today's world, "design" is "what looks pretty and promotes the brand"--and today that's pastels and abstract shapes and cute little black and white animations which show off the horsepower of the GPU in the device.
And it has absolutely fuck-all to do with computer-human interfaces or usability--as if we just dumped every SigCHI paper from the ACM from the 1970's to the 1990's on a great big bonfire.
As an aside, on iOS we already force applications to switch to the Settings app to turn on or off notifications and location settings; there is no API within iOS which can programmatically change these settings.
Doing the same for iTunes passwords doesn't seem unreasonable to me.
Honestly I think this does count as a fundamental flaw--but a flaw in the design of the user interface flow used to obtain credentials for iTunes (or for other applications).
It's a flaw for two reasons. First, any process which interrupts your current actions with a modal dialog is a flaw in that if you are not paying attention, you may accidentally tap the accept or cancel button without realizing what you are doing. (This is worse on a desktop environment, where a pop-up may appear while you are typing. If you are a fast touch-typest like I am, you may accidentally press 'enter' or 'space' before realizing what you're typing has gone into the dialog box that just randomly appeared.)
Second, the design is a flaw because it does not give a mechanism by which the context of the dialog box cannot be brought forward and examined for validity. That is, with the iTunes login prompt, all you are permitted to do is to enter the password or not--but you have no way to know that it indeed is coming from iTunes.
I personally would consider fixing this user interface flaw by doing three things.
First, provide a notification mechanism which is clearly visible to the user (such as a flashing bar at the top of the screen), but which does not directly interrupt the user's interaction with the device. If, for some reason a password is necessary before the user can continue his interaction with the device, I would propose a dialog box come up with stops the user interaction with an accept/cancel button but which does not ask for information.
Second, in response to the notification mechanism, I would switch to the application that is asking for the information. (This is easier now that iOS supports multiple concurrent applications and a method for going 'back' in the upper-left corner of the screen.) This gives the user the opportunity to examine the application which is asking for the information. (If this is in response for an iTunes password prompt, I would switch to the Settings app and to the iTunes password screen within settings.)
Third, I would explicitly prohibit (either by changing the OS or through the review process) modal dialogs not belonging to an application from appearing over another application. This includes built-in OS modal dialogs.
All of this is designed to force the user to examine the context in which their sensitive information is being requested, rather than blindly handing it over. Because this sort of interaction is relatively rare, forcing the user to switch to the settings page (rather than just grabbing the password on the go) is not an unreasonable price to pay here.
Personally I have never had any problems with someone who is there and wants to learn and improve. Personally I like people who want to grow and develop as a programmer; hell, I was once a programmer who needed to grow and develop myself, a quarter century ago.
The ones who piss me off, however, are the ones who completely fuck up the code base--and do so while arrogantly proclaiming their way is the right way, and who refuse to learn because they have nothing to learn from someone older (and thus, somehow dumber) than they are.
Slashdot Mirror
I did not say the pilots were rookies. I said the copilot made a rookie mistake:
I notice you didn't quote the relevant part of the Wikipedia article:
Rookie mistake. (1) You always clearly announce who is in control of the aircraft. Generally this is announced by one pilot saying "my controls", and the other responding "your controls." Two pilots trying to do the opposite action is rookie mistake number 1.
(1) When the aircraft is in a stall, it's because insufficient air is flowing over the wing, and the wing cannot provide lift. This is solved by pushing the nose down, allowing the aircraft to regain airspeed. Bonin, the co-pilot, was pulling the stick back, which can only be read as that he panicked, and forgot training he should have learned while learning how to recover from stalls waaaaaay back when he first started learning to fly and got his basic pilots certificate. The pilot pulling when he should push is rookie mistake number 2.
On top of all of this, your assertion:
Are you asserting flying is too hard for humans? Because that would worry the fuck out of me. Or are you asserting flying commercial jets is hard? Because there I'd completely agree with you; the most complex thing I've flown is a single-prop high-performance retractible out of a Class C airport in IFR, and the idea of flying a jet is intimidating as hell. But then, that's why the guys who fly commercial jets get additional training: to learn how to keep ahead of these highly sophisticated beasties.
That's just bad design.
Because the correct way to design an airplane is to assume everything is going to go haywire: that the GPS satellites have all been taken over by Skynet, the computer has become depressed and suicidal, and the autopilot motors have all decided to play poker in the cargo hold.
Autopilot systems are generally designed to allow the pilot--with sufficient force--to override the autopilot motors in the event the autopilot acts up.
(I once flew a DA-40 whose autopilot decided a hard left turn was the right answer--it took a little upper-body strength, but not a lot, to force the plane from flipping over while I reached for the breaker to turn off the autopilot. Same principle applies in large aircraft like 737s, and that's by design.)
First, all pilots are trained to fly the airplane manually, with all air surfaces controlled by hydraulics on most aircraft. Electric motors are also connected to these hydraulics to allow the autopilot to fly the airplane, but as a convenience. Pilots are supposed to know how to fly the airplane without the use of the autopilot and by using radio signals received by VORs (radio-directional beacons) in order to navigate using a paper chart (or an iPad with a chart on it).
That Air France Flight 447 went down was not due to "poor training" or because of a lack of ability to detect a cyber-attack, but because the copilot in that airplane panicked and pulled when he should have pushed. (Frankly his mistake was a rookie mistake that student pilots are supposed to unlearn within the first 20 hours of training.)
Now are there attack vectors which can be used to sabotage an airplane? Absolutely--but they're not the "I plugged the laptop into the network and hacked the airplane's firewall" variety, since most aircraft (certainly the 737) run parallel networks--with the avionics physically disconnected from the entertainment and WiFi systems used by the passengers.
Attack vectors would be for a passenger or someone on the ground to jam and spoof GPS signals, and to jam and spoof directional VOR and ILS transmissions, to fool the navigation equipment on the aircraft to think it's somewhere it's not. Another attack vector is jamming and overriding the air traffic voice and text communications by someone spoofing air traffic control.
The problem is exacerbated by NextGen, where aircraft broadcast their GPS location (rather than their location being detected by ground-based radar), so it makes it harder for Air Traffic Control (who watches all commercial aircraft like a hawk, alerting pilots if they deviate from their flight plan) to determine if someone has gone off course. And of course the problem is made worse by inattentive pilots who often sit around the cockpit bored when they are supposed to be monitoring the navigational equipment to make sure it looks correct. (Remember when two pilots flew off course because both of them fell asleep at the wheel?)
But onboard cyber-attacks? Puh-lease...
The solution to all of this is the solution first taught to student pilots flying their first Cessna 172: fly the damned plane. Left hand on the yoke, right hand on the throttles, both feet on the rudders, and do that stick-and-yoke thing so many of them have forgotten because they think the computer is the best pilot in the cockpit.
If I had my way, the first thing I'd mandate is that all commercial pilots--including those flying the largest A-380 airplanes--spend at least a few hours a month flying the same Cessna 172 they learned in. That way they remain viscerally connected to flying by stick and yoke--and when the computer acts up, as it always seems to do at the worst moment in the cockpit, you can still look out the window, see that piece of cement in the distance, and put the airplane down where it's supposed to go.
So passengers can use WiFi while on board. Duh.
The real question is "why is the cockpit navigational equipment connected to the Internet," and the answer is "it isn't." Nor is the autopilot on most designs.
Notice when the current giants in the market became giants: after the passage of Sarbanes-Oxley, which made it far more difficult for mid-sized startups to go to the public markets for funding. When the only practical exit strategy left to you is to be bought out by a Facebook, a Google, an Apple or a Microsoft, then the only strategy you have left as an entrepreneur is to figure out what will get you bought out, rather than going head to head with the large companies as Google once did against a Lycos or an Altavista.
Without the additional requirements in Sarbanes-Oxley which made accessing the public markets much harder, would we be talking about Github being bought out by Microsoft? Or would be be talking about Github's IPO?
Given that it has taken some GA aircraft manufacturers a decade to go from "idea" to type certified aircraft, I don't see how Uber--who has absolutely zero track record in the airplane business--will manage to get something that is legal to fly in such a short period of time. Worse for them, the FAA is a fairly conservative bunch who are very safety focused, which means Uber may find themselves (as the new kid on the block) facing a whole bunch of questions about the new aircraft's safety, including safety in the event of a partial engine failure. And since they plan to use this vehicle almost exclusively for commercial transport, they may find themselves facing even more stringent requirements than you normally see with stuff flown by part 91 pilots.
And unmanned aircraft? You know, the first phone selfie video of someone in one of Uber's aircraft as it plummets to the ground (taking several minutes if Uber's self-flying aircraft is in the 8,000-9,000 altitude range) will pretty much destroy Uber in lawsuits.
As an aside, in the State of California, political affiliation and belief are protected classes.
So, from a legal perspective, it is in fact illegal to discriminate against conservatives. Just as it is illegal to discriminate against liberals.
The problem, both with your examples and with your argument, is that they mix morality and money.
Now I'm all for morality. God knows I've been a strong supporter of LGBT causes and my (Scots-Irish) father in another era spent some of his misspent youth in Memphis protesting for black equality. I'm also all for money--and using money to build an organization, to hire people, to create wealth and to build something that adds to the economic gestalt. I'm even for consumers being picky with their money, deciding to spend their money on things they support, such as organic farming or refusing to cater to businesses who don't treat customers with equality and respect.
But it has been my experience that when we start mixing morality and money on the grand stage, both money and morality lose. And that's precisely what you're advocating here: that we as a society (rather than as individuals) choose how we spend our money based on a moral framework that, more often than not, is incomplete once we move onto the grand stage. (It's easy as a consumer to avoid a bakery who refuses to sell a cake to a gay couple. But as a society do we punish the Kosh Brothers for their stance in criminal justice reform, a position taken for a decade before President Obama praised their position? Or is it more complicated than that?)
So sure, take your moral stance on Peter Thiel. If y'all don't want him in California, we'll certainly take him in Raleigh. There are plenty of people who aren't as repulsed by his politics, and certainly we'd be happy to spend his money in areas like the American Tobacco campus in Durham, which has a bustling startup culture and which has the potential to create significant employment opportunities for minorities.
Because let's "spread that money around a little" (as a famous person once quipped) and help build some wealth before we start spitting on someone's assistance.
Our old A/C unit finally gave up the ghost and so we had to replace it with a new compressor and air exchange unit. We bought a top of the line unit, which the installers were able to put into place in just a couple of hours. And of course the unit didn't work: when plugged in, the thermostat gave a '443' error, which the installers simply could not figure out.
The next day a technician came out to diagnose the problem. It turns out the software on the outside compressor unit was incorrectly configured, and the '443' error indicated a mismatch between the air exchange unit inside the house, and the compressor on the outside. A few minutes with a laptop and the software in the compressor was correctly configured, allowing the system to work.
In the old days, the compressor was simply a fan, pump and baffles which allowed the coolant to be heated or cooled, running to an inside comp, fan and baffles which then blew the heat or cold air off the coils and through the house.
Today's A/C unit has a microcontroller in the compressor to measure a bunch of diagnostic information, a microcontroller on the heat exchange unit, and the thermostat contains a microprocessor which monitors all this diagnostic equipment. It's great in that I was able to get into the diagnostic settings and change a few properties to allow our A/C unit not to blow so hard at night (when we're sleeping), and to favor using the heat pump at colder temperatures in order to save power--even though in the winter it may take longer to heat the house up. The thermostat shows us the outside temperature at the compressor on the main screen, and will give a five day weather forecast when hooked up to the WiFi network in the house. It can cooperate with other thermostats in a zoned house to optimize energy usage. It will even notify the installers (if we wish) with diagnostic problems if there is a problem with our unit, so they can more quickly diagnose and fix problems as they arise.
But there are a hell of a lot more moving parts than the older A/C units--and a hell of a lot more things that can go wrong.
Which is why so many home owners who bought a home have done relatively well: because a home represents illiquid forced savings. The problem is most folks, if they had a pile of cash rather than an investment instrument (which earns crap returns but is still saved), will blow it on toys, trips and stuff rather than put it into a good investment portfolio. So while in theory investing in a home isn't as good as potentially other investment instruments (though please subtract the cost to rent, because you have to spend something on a home, because it's awkward for millionaires to live in cardboard boxes under an overpass), in practice investing in a home works out better for most folks than the alternative.
The big thing to remember is if you plan to stay in an area less than 5 years (in general), you are much better off renting than buying. Most of the stories I've read about people doing well buying instead of renting (and that includes us; we bought a house in Glendale in 1996 after the Northridge earthquake, and moved out 18 years later to Raleigh, using equity to pay cash for our home here in North Carolina) involve people staying in the same home for many years.
But if you buy in an area and plan to leave in less than 5 years, at the very least the cost to get the home ready after purchase and the 6% you lose when selling your home will probably eat up any (minimal) equity and appreciation you got in your home.
Remember: for most of the country, housing prices only go up at roughly the rate of inflation. Only in a few areas (like California, New York, or parts of Las Vegas) do housing prices appreciate substantially faster.
No, but the CEO, along with the CTO, are responsible for creating the policies which drive the procedures for the company. So while he may not be expected to know the specific implementation, he should know the policies and goals for corporate security. Bouncing those policies to some "VP of Security" only means those policies will not be taken seriously.
And it's poorly written, poorly managed, poorly understood and completely under-appreciated by the C-suite until something goes pear-shaped.
Apple is famously secretive, and famously punishes those who break their secrecy.
Of course developers should test their own code by running it in the debugger and making sure they're not checking in obvious garbage.
And of course developers should do unit testing modules to verify the correctness of certain libraries and submodules of their code. This correctness helps to make sure submodules behave correctly.
But you need a separate QA team. And you need two types of testing: directed testing (with specific testing instructions to test components of the software) that are put together by a QA manager. And you need undirected testing--basically QA folks just screwing around with the software.
There are several advantages of having a separate QA team. First, QA testers do not have to have the same level of experience as software developers, and so you can hire testers with less experience and for a lower salary. (If you have a QA manager who writes good test instructions, you can pretty much hire damned near anyone to test the software. I mean, presumably if your software is used by any random person off the street, you should be able to hire any random person off the street to test, right?)
Second, developers often wind up concentrating on a few modules when adding features or fixing problems, and so often fail to do adequate integration testing across the product, looking for unexpected side effects. (In essence, the biggest problem are those "unknown unknowns" which cannot be found unless someone just farts around with the software.)
(And don't tell me all this should be automated. That sort of automation is basically front-loading all the possible testing you may want to do--and completely ignores the institutional knowledge of your product gained by QA testers playing with the product. In the past when I've gone to work for companies with a well staffed QA team, I first go to the QA team, not to the development team, to understand how to use a product.)
In general I'm a big believer in the model of software developer as a Knight surrounded by support staff. Your developer is probably the most expensive person on your payroll--so why waste an expensive resource on stuff that can be offloaded to people who can probably do various support jobs more efficiently for a lower salary? I know that sounds a bit brutal, but there is definitely an efficiency argument for software developers not writing business requirements, manning customer support lines, or doing customer sales--so why the hell do we expect developers to take over testing?
The keyword in my comment was "viable."
Which wouldn't bother me if we had private-funded healthcare as a viable option. But since we don't, I guess it's up to Big Brother, since the moment a third party pays, it's no longer just about me and my doctor, right?
I guess that's why they put the blades of a helicopter on the bottom...
Ah, hell; just put the center of mass below the plane of the cuisinart blades so the weight hangs from the blades rather than is balanced on top, and it would help some with stability. I mean, even small low wing aircraft shape the wings as a 'V' with the center of mass below the bulk of the lifting surface, so as to have positive static stability...
Came here to say that. I mean, who puts the whirling blades of death at kneecap level without any sorts of guards? All you need is a poorly timed kick (in reaction to losing your balance, say), to have the bottom half of your leg chopped off by one of those four spinning Cuisinart blades...
Well, remember: in today's world, "design" is "what looks pretty and promotes the brand"--and today that's pastels and abstract shapes and cute little black and white animations which show off the horsepower of the GPU in the device.
And it has absolutely fuck-all to do with computer-human interfaces or usability--as if we just dumped every SigCHI paper from the ACM from the 1970's to the 1990's on a great big bonfire.
As an aside, on iOS we already force applications to switch to the Settings app to turn on or off notifications and location settings; there is no API within iOS which can programmatically change these settings.
Doing the same for iTunes passwords doesn't seem unreasonable to me.
Honestly I think this does count as a fundamental flaw--but a flaw in the design of the user interface flow used to obtain credentials for iTunes (or for other applications).
It's a flaw for two reasons. First, any process which interrupts your current actions with a modal dialog is a flaw in that if you are not paying attention, you may accidentally tap the accept or cancel button without realizing what you are doing. (This is worse on a desktop environment, where a pop-up may appear while you are typing. If you are a fast touch-typest like I am, you may accidentally press 'enter' or 'space' before realizing what you're typing has gone into the dialog box that just randomly appeared.)
Second, the design is a flaw because it does not give a mechanism by which the context of the dialog box cannot be brought forward and examined for validity. That is, with the iTunes login prompt, all you are permitted to do is to enter the password or not--but you have no way to know that it indeed is coming from iTunes.
I personally would consider fixing this user interface flaw by doing three things.
First, provide a notification mechanism which is clearly visible to the user (such as a flashing bar at the top of the screen), but which does not directly interrupt the user's interaction with the device. If, for some reason a password is necessary before the user can continue his interaction with the device, I would propose a dialog box come up with stops the user interaction with an accept/cancel button but which does not ask for information.
Second, in response to the notification mechanism, I would switch to the application that is asking for the information. (This is easier now that iOS supports multiple concurrent applications and a method for going 'back' in the upper-left corner of the screen.) This gives the user the opportunity to examine the application which is asking for the information. (If this is in response for an iTunes password prompt, I would switch to the Settings app and to the iTunes password screen within settings.)
Third, I would explicitly prohibit (either by changing the OS or through the review process) modal dialogs not belonging to an application from appearing over another application. This includes built-in OS modal dialogs.
All of this is designed to force the user to examine the context in which their sensitive information is being requested, rather than blindly handing it over. Because this sort of interaction is relatively rare, forcing the user to switch to the settings page (rather than just grabbing the password on the go) is not an unreasonable price to pay here.
Personally I have never had any problems with someone who is there and wants to learn and improve. Personally I like people who want to grow and develop as a programmer; hell, I was once a programmer who needed to grow and develop myself, a quarter century ago.
The ones who piss me off, however, are the ones who completely fuck up the code base--and do so while arrogantly proclaiming their way is the right way, and who refuse to learn because they have nothing to learn from someone older (and thus, somehow dumber) than they are.