+++OUT OF CHEESE ERROR+++

Frogs, mud, slingshots, wrong words and awkward times, etc.

All part of being a kid.

Now I'm older I realize more fully the grief I gave my parents.

Not the whole audience. Some of us actually do care that they're not spouting the technobabble you hear in the typical Sci Fi shows, or that when the characters do make mention of it, it's to mock it, just as we do.

Normal cell conversation encryption isn't end-to-end. GSM encryption only protects the conversation from your phone to the tower you're talking to. You're right in that both parties each need one of the high security phones to support true end to end encryption. I've heard it said that at Facetime and iMessage used to be secure, but the tinfoil hat crowd has claimed Apple has since had to provide "lawful intercept capability".

Because the baseband systems are generally invisible to the phone OS, and because the phone OS is usually the place people are interested in hacking, they have not received much attention. Still, there are quite a few researchers who have begun hacking the baseband stack, and in general they've found them to be very poorly coded, and riddled with security vulnerabilities. They have discovered serious flaws that allow malformed packets from the wireless network to hack the phones. While it may be "unlikely", it could certainly be possible.

Also, take a look at CANDYGRAM.

The US is finally going to Chip and PIN next year. It just takes a long time to get a million businesses to spend the money needed to convert their readers.

Sure, chip and PIN messages can be intercepted, but the data that can be intercepted cannot be reused dor a second fraudulent transaction, and cannot be tampered with.

Chip and PIN moves the trust out of the merchants' terminals and out of the network. Only the chip and the bank's systems have the secret knowledge needed to participate in the conversation. You no longer have to wonder if Home Depot's readers are safe, because it won't matter.

With a billion credentials, they certainly haven't had the chance to exploit them all yet. It's too late for 0.01% of the victims, but not too late for the rest of us.

In cryptography, it means a number that is only used once -- n-once. However, it is actually the wrong word to use here, as a cryptographic seed's most important attribute is unpredictability.

Don't underestimate the importance of the right education. Our company almost collapsed under the stupid organizational structure put in place by our last CIO, who was not an engineer, and had no idea how engineers work. I never before realized how much damage an org chart could do.

... and it will only require 50,000 words in which to send it.

I generally avoid the self checkout, but I might use it if there are no other customers in front of me and there's a line at the cashier. Have you ever waited for a self checkout behind a typical person? I want to claw my brain out as I watch them stupidly wave a package over the scanner again and again, all the while covering the barcode with their hand. Or they bounce everything off the glass, as if they're buying basketballs. Or they have to sift through their entire basket, to find that one bottle of Axlotl juice that they want to put in the bag next.

All you have to do is sign up and they'll migrate your email account to their IMAP servers. https://xcsignup.comcast.net/o...

IIRC they hurriedly provided this back about the time Windows 8 came out, because Windows 8 has no POP3 client.

Maybe the requirement to upload bulk updates was a lower priority for that development team than getting other features implemented, and it's still on their stack. Or maybe they ran out of budget before getting to implement that feature. Maybe the stakeholder who was assigned to work with that development team failed to understand his or her own user base - the stakeholder's job is to provide the business perspective, and maybe he thought a pretty color scheme was more important than bulk uploads.

People can still make poor decisions in any framework, which does not necessarily invalidate that framework. The good thing about an Agile approach is that as long as the team is there, the software can still be easily changed.

And if she hasn't already, your wife has the responsibility to file a bug report or at least report her concerns to the stakeholder - the team may not even know of this need for bulk updating, or the financial impact of the one-at-a-time process. It sounds like it's fairly easy to quantify the cost of the inefficiency, which should help prioritize it accordingly.

Software is malleable in that whatever is on the inside can be safely changed through refactoring to meet your new design goals. And yes, you have to adhere to strong design principles: the open/close principle helps ensure that you can safely migrate to a new API while still supporting your old clients; the interface segregation principle helps ensure that your clients are always getting the right service without confusion; and you have to commit to serious code coverage metrics for your automated tests. That means you don't even write an exception handler unless you have a unit test that proves it properly catches the exception.

And developers absolutely cannot work in a vacuum, or be incompetent - there's no room for them. So when they're writing the negative tests, they are expected to be smart enough understand the permutations and the boundaries in the requirements they're implementing. But high complexity means lots of paths through the code, which means lots of tests, and this need for testability that is practically and realistically achievable provides incentive for the developer to keep code complexity down. That is a feat he or she continually accomplishes through the refactoring step of TDD. That way, instead of writing fifty tests, perhaps they can split it into five modules and write ten tests. Not coincidentally, this activity continues to improve modularity, reusability, and maintainability of the module. So it improves the code's design after it's written (an activity that still was not needed up front.) As a bonus, you get to execute the automated tests again and again, so future maintainers benefit by knowing they haven't broken your module. TDD is actually a design methodology, not a test strategy.

And I know that you're using CAPTCHAs as a clever example (how can you prove that you wrote a transformation so complex that you can't Turing test it?), but the real answer there is it depends on what code you're testing. Are you testing the code that processes the outcome for a true or false response? Are you testing the user interface, that allows them to type letters into a text box? Those tests aren't especially hard to automate. But when you're talking about the specifics of "is this CAPTCHA producing a human-interpretable output?" then you're talking about usability testing, which is expensive, manual, and slow. It's a task you'd perform after changing the CAPTCHA generation routines, but you wouldn't be able to automate. So I'd have to manually test it only after changing the generation routines, and I wouldn't alter the generation routines without scheduling more user testing.

(If I ever had to write a CAPTCHA for real, I'd probably try to parameterize it and allow the admins to tweak the image generation without my having to further change and test the code. So if the admin figures out how to tweak it to a black-on-black test, and preventing low-contrast color schemes wasn't identified in the original effort, the admin could still untweak it. And yes, that should generate a bug report, even though it would be recoverable.)

But in terms of difficult to test code, teams that do this kind of development work well will often have different suites of tests for different situations. Etsy does this really well, by splitting tests into various categories: slow, flaky, network, trunk, sleep, database, etc. They always run all trunk tests on every build, but only if the developer is working on something that tests the actual network communication would he execute the network tests. See http://codeascraft.com/2011/04... for their really inspiring blog.