This is wrong, or misleading at best. Two of my credit cards are known by their issuer to have chips; both have been used hundreds of times on chip-capable terminals with only the magstripe (because the chip is missing from both cards) with zero complaints or problems; both have had their magstripes copied by restaurant employees and used to illegally purchase goods. If any retailers are treating magstrip info as second-class I've yet to run into one, QED. So the big problem with the chips is that you can reconstruct the magstripe info from quite a distance. And you only need the magstripe info to clone a card well enough to go buy something at your local Wal-Mart or any of the other thousands of shops that don't ask for the CVN2/CVV2 (which, around here, only Sears does ask).

So tell me again why I'd want to use this insecure contactless system when it saves me perhaps a second or two, tops?

Classic case which I run into somewhat regularly at work:

void some_hot_interrupt_handler(struct some_message * p) {
..// sanity stuff
..switch (p->message_type) {
..case WHATEVER1:
....// code
....if (message isn't for us)
......goto noack;
....// code
..case WHATEVER2:
....// code
....if (message handled by FPGA, so bail out ASAP for speed)
......goto ack;
....// code
....if (message has bad timestamp, etc.)
......goto noack;
....// code
..case WHATEVER3:
.... etc. for several more message types
..}
ack:
..ack_message(p);
noack:
..free_message(p);
..reenable_receiver();
..return result;
}

Yes, there are a lot of ways to solve the problem. The easiest is by breaking the mass up into inlined function calls that return to the common parts, but then you have to signal which common parts you want (ack/noack) and that sort of hamstrings the (or just this particular?) compiler's ability to generate code as efficient as the goto. And this thing is being called many, many thousands of times a second so even tiny bits of overhead really hurt. You could duplicate the ack/free/enable bit within the various message handler cases, etc., but the sprawl hurts you pretty badly, too, because that's code duplication (an error waiting to happen) and you shouldn't try to "fix" that macro-izing it because you have to keep the whole function in very limited fast RAM. You could use another signaling variable (do_ack, etc.) but then you have a huge nest of if/else within the handler and the compiler starts to have trouble with optimizing that, too.

Our house rule is: do not use gotos... except for the few cases where they're the right tool for the job.

They're still what they were designed to be. They're just investing in P.R. now. Next.

It depends on the field you end up in, really. Writing $randomSmallSocialWebApp requires only a moderate understanding of algebra, statistics, and numerical methods. (You can get by with less, but you won't be as good a programmer and won't float as high.) Writing $randomControlApp requires considerably more math, depending on the job.

In my job I write a lot of embedded software and use a lot of my math training. From control theory to simple things like calculating rise times and ring on a bus.

A sheet-feeder duplex scanner that'll scan and OCR to a PDF. Drop in your year of bank statements, press the button, come back in five minutes. Scan your receipts, product manuals, whatever you actually use. Throw out everything else.

At my last employer, where I was involved in the technical half of resume screening and candidate evaluations, online courses weren't worth very much in the early stages. The problem is that the quality of the programs varies so widely that it's best for the screener to just ignore them. Yes, there are diamonds in the rough, but you don't have enough time to go do the research, so you mentally block that part out and continue on. It's not particularly fair, but when you have 500 resumes to work through in a day, you have to come up with a fast system.

Now, if you make it into the later rounds and it comes down to you versus someone who hasn't demonstrated that drive to better themselves and their career? Yeah, I'd take the time to go look up the online program, any graduation statistics it published, etc.

1. Failure to comply with a court order puts you in civil contempt of court. You can be held indefinitely for that. There is no habeas corpus involved there because you hold the keys to your own cell. You can sit in jail until you comply with the order, the order is overturned, or the order no longer serves a purpose (e.g., grand jury convenes, the jury trial at which you were supposed to testify is done, etc.). Even better, civil contempt charges don't require iron-clad proof, merely that the preponderance of evidence shows that you are violating the court order.

2. Yes, you cannot be compelled to testify against yourself, but US courts have repeatedly ruled that you can be forced to turn over evidence which is potentially incriminatory. "I have hidden them because they incriminate me" isn't a valid reason to avoid turning over fingerprints, hair samples, security camera footage, files, day planners, etc. If you know where the thing is and the court holds a valid order to get the thing, failure to comply is civil contempt of court. Then see point #1.

You realize that you can be held indefinitely on contempt charges? As in, for the rest of your life or until you comply? There's no violation of your rights in that case because you are considered to hold the keys to your own cell, as it were.

This is a load of horse shit. Yes, atomic mercury is bad for you. However, there are several useful and demonstrably non-harmful mercury compounds. "There's no safe amount of arsenic exposure!" "Hey, your cellphone contains some gallium arsenide transistors. OMGYERPOISONED"

They're using a palladium element as their "fusion" site. Palladium can absorb an absolutely amazing amount of hydrogen (900 times its own weight at the proper temperature). That's a supidly large amount of hydrogen which you can use for self-powering a demonstration for quite a long time.

The built-in PDF reader on the Nook Color is decent. It drains the battery faster (maybe 2x or 3x?) than reading epub files but is still quite usable. I've only ever had trouble with one PDF: there was one page with a TON of overlaid vector images and it wouldn't render correctly; all pages after that page were missing images entirely. Otherwise it's been a fine machine.

While it'll be nice to get native lambdas, the above example is a bit contrived; it's a lot prettier than this in current C++. With boost's lambda:

vector<int> foo(5, 0);

// one example
int n = 42;
for_each(foo.begin(), foo.end(), _1 = var(n)++);

// and another
for_each(foo.begin(), foo.end(), cout << _1 << '\n');

The syntax isn't perfect, but can be very handy for throwing together prototypes, descriptive code, etc.

The summary incorrectly states "5 ft" but the other news releases state "5 m." The fuel rods are 4.5m long, so the implication is that 100% of the hanging fuel rods are exposed. Any that fell/slumped to the bottom of the pressure vessel are, of course, probably 100% covered since there is still some water in the vessel.

1. download dd-wrt and flash your router; a decent one with a full 8 MB of flash is probably ideal.
2. set it up to have two SSIDs; one will be encrypted, one will not. DO NOT BRIDGE THEM. (You don't want the open wifi AP traffic to be able to reach your other subnet.)
3. set up traffic rate limiting (QoS) on the router; put the public subnet traffic into the "bulk" (i.e., low) priority and your private subnet's traffic into something higher.
4. turn it on, test it well, and smile because you're doing well and doing good.

The linked article about the nuclear plant problems in Japan is chock full of technical errors and omissions. He skips the primary danger of exposed fuel rods, the danger Japan is facing: thermal damage to the fuel rods themselves, prior to the total meltdown stage, means your steam pressure releases now contain primary radionuclides! He states that the melted fuel rods aren't hot enough to melt steel and concrete, when they most certainly are! (They melted sizeable chunks of the containment vessels at TMI and Chernobyl.) He fails to correctly describe what emergency core cooling systems do and how. He miss-states the actual danger of graphite-moderated reactors: it isn't that graphite is flammable, it's that you're using it as a moderator (as thus, water as some of the neutron absorption) and that makes the system inherently unstable. Once you reach the point of worrying about the graphite burning, you're way past the tremendous explosion/meltdown phase.