I also tried to put myself into the shoes of an Iranian fundamentalist,but I got frustrated and decided to throw those shoes at someone.

Uh no, it's to demonstrate that the code "works". The problem here is what it means "to work". Part of the usefulness of TDD is that you might not fully understand what it means "to work" yet, and the tests help you flesh that out.

Let me clarify, so you don't think I'm 100% ditching what you're saying versus stating it a different way. A test suite will tend to have BOTH tests for what the correct behavior *is* and also tests for what the correct behavior *is not*. In other words, what you're doing is defining the BOUNDARIES between correct and incorrect behavior. You're right in the sense that if your *strategy* is to write only *optimistic* tests (i.e. "proving that it works"), you'll miss subtle areas where the behavior isn't fully clarified (i.e. corner cases).

But here's the problem: for absolutely anything in the universe, there is an INFINITE number of things something *is not*, but only a finite amount of things something *is*. I've seen people go too crazy with using tests as a way of type-checking everything where smarter data types would have been a better choice, or performing a hundred "this isn't what I want" tests that could have been handled with a single "this IS what I want" test. My point is that you're supposed to program for the correct case, not design as if you always expect everything to go wrong. Write for the correct case, test for the correct cases FIRST, test for the EXCEPTIONAL cases, and write handling code for the things that are exceptional. Don't write an infinite test suite of what something is not.

CONCLUSION: Write the most EFFECTIVE tests you can that covers the most ground. Don't write *pointless* tests you have to maintain later if there was a better test. If a test covers a lot of logical ground by defining the boundaries of what something *is not*, then write the test for that. If it covers a lot of ground by defining what something *is*, write the test for that.

I'd suggest it's a cost-benefit analysis. Having to label the same switch 100 different ways for appropriate localization would add a few dollars to the cost of the car. It's not just the printing, but the planning and QA, too. Using an icon may put the burden on the buyer to figure out the meaning of that icon, but once the buyer has been in the car a few times, he or she will know where the switches are and will operate them by feel.

The labels could wear off at that point, and it won't matter what language they're in. So on a car, while the incremental cost may not seem to be much, the long-term benefit is tiny.

It may be a bigger help on other things...like an air conditioner unit or some such...but then the added cost of label localization becomes a much bigger percentage of the cost of the item, and as such, sales and profits would take a much bigger hit.

I'm sure that for every person who has complained about crappy labeling, there is a group who has done the testing, surveyed their client base, calculated the ROI and determined that improvements are not worthwhile from a bottom-line perspective.

I dont think you have really escaped the single point of failure.

Losing an all in one device means you have lost a lot of functionality, but replacing that device brings it all back in one shot.

Having one device for one task may sound good, but if you need a camera, and you lose it ( or it breaks ) your stand alone GPS device cant help you take a picture.

Your point is valid for why I dont use my phone as an mp3 player. Draining the battery on my music player has much less impact when I am hours from a charger than draining the battery on my phone.

You can post this as often as you want, the comparison is still full of errors as a result of an ffmpeg bug (it was previously believed to be intentional). It uses x264, which is an opensource h264 encoder. The x264 developers responded to this comparison on reddit, highlighting the many errors in it: http://www.reddit.com/r/programming/comments/8iphn/theora_encoder_improvments_comparable_to_h264/

My point is that in 90 years the entire cityscape will change. I'm not saying it isn't worth doing. I'm just saying that by just reading the headline you get the impression that radical things need to be done NOW and in a PANIC. The things proposed are not radical, and no need to panic. Compared to New Orleans. They did have issues with low lying areas and they ignored them for years. In that case it was time to act now and in a panic, but the panic only happened after hurricane Katrina. I'm not advocating ignoring the problem, but just saying "Don't Panic."

That's not a spectrum. That's a hyperintelligent shade of blue! Quickly, grab a prism!

Whomever labeled this "pork" should think of New Orleans and reconsider. Protecting vulnerable coastal areas with levees and such is a valuable investment in human life.

In other news, Himalayas have seen a surge of new visitors and people moving in.

I am suggesting that the CAPS LOCK words and all the exclamation points and using words like 'bullshit' 'lying assholes' and 'force the luddites into the modern era' that he in fact takes a subject very personally, that he, by his own admission, does not participate in. And to take something that personally you either have to hate someone who does it (which is an issue not dealing with ham radios) or you have to want something they have, I'm guessing their portion of the radio spectrum. Either way, I doubt his problem is with the several (few? one? hundreds?) ham radio operators in Haiti who can't broadcast now, and more with the idea of using old technology when he believes it shouldn't be allowed.

I understand your point, but it somewhat feeds the point I was aiming for as well: a number of IT people see the telcos as process-bound and slow-moving, and they feel that's not an environment that they want to work in. If that sort of environment is the end result of unionizing, then a lot of IT people (obviously not all, but many) won't want to unionize.

It's obviously a trade-off: if you want the protection a union offers, then some bureaucracy comes with it. But, so far most IT people haven't been willing to make that trade.

"While it's not likely that a smart phone user is going to draw a lot of lines, the test does give some indication of which phones are most likely to properly respond to clicking on a link in a Web browser." I don't suppose they considered instead testing which phones properly respond to clicking on links in Web browsers?

Mandatory xkcd

Oh, definitely preferred to let them proceed with the prescriptive court order, and do your own audit while they are out getting it. And, having done your own audit, you are better able to make a case against them if they attempt to "plant" anything while auditing your systems.

Audits are part of the cost of doing business, very common in lots of areas besides software licenses, but they are costly and if you have an audit-free alternative it certainly becomes that much more attractive.

In regards to IBM pulling the same against Oracle you forget one of the biggest reasons against it. Federal Action and Lawsuits. This would fall squarely under Anti-Competitive actions, thus the Feds (DOJ/Regulators) would all jump in and Oracle would have a Damn near ironclad suit against IBM for Lots more then 100M dollars. Even though the Nazgul would be out in droves, they still couldn't keep the ring bearer away from Mount Doom as the Armies of the 7 lands would be fighting them at the same time.