burgeralarm

I can 100% recommend this. Using O'Reilly like a library instead of a bookstore makes me a better developer no question.

According to the engineer who tested the cable:

"Most devices with a well-specified connector will not have any reverse bias protection in them because both it shouldn't be needed and for the technical reasons of power loss and space used.

Reverse protection is usually done with diodes, the canonical "one-way valve" of electronics. Diodes have a voltage drop across them, usually 0.6V for standard and 0.4V for Schottky types. Using one of these to protect one rail means you'll have about 1W lost to heat when charging at 3A. They are also not small for the currents involved with high-speed charging, being about 7x6x2.5mm for the smallest ones I can find that can handle 3A.

Devices don't usually have too much in the lines of over current protection outside of something like a polyfuse because the device will dictate the current used; if everything is okay in the device it'll set the charging rate and it only needs the most basic of protections in the case that something goes grossly wrong with the device. Sources are what really need overcurrent protection as they don't "have a say" in how much current is drawn."

Fortunately, probabilities for birth control methods aren't presented in this way. Generally, when an organization like Planned Parenthood says that the symptothermal method is 99.6% effective, what they really mean is:

"Of 100 couples who use the symptothermal method correctly for one year, 0.4 (fewer than one) will have a pregnancy." (Source: http://www.plannedparenthood.org/health-topics/birth-control...)

So after about 100 years of using this method, you've got a .4% chance of becoming pregnant. Seems like decent odds to me.

Hooray for trivializing _actual_ issues in tech. Oh, and a rape joke thrown in for good measure.

Jesus.

I don't think that's what happened. The article talks about a security audit using a fake FedEx box after the fact, but it sounds like this guy just got a hold of some keys or passcodes.

They're preying on our desire for instant gratification, no doubt.

This reminds me of a small project I tossed together:

http://git-fortune.bclune.org

It grabs a random commit message from a github repo and displays it. By default, it pulls from a repo containing the original debian fortunes as commit messages. But you can point it to other repos like this:

http://git-fortune.bclune.org/twbs/bootstrap

Inspired by What the Commit? and /usr/bin/fortune.

I agree, the presentation is fantastic! Well done.

The testing methodology is quite flawed (at least for the reading speed test on the site). It asks you to read a passage with BeeReader to start out. When you're done, you're presented with questions about the passage before reading a non-BeeReader passage.

The catch is, you will almost certainly read the second passage slower than the first, since you're now looking to retain information for the questions!

The colored passages _feel_ faster, but I'm not sure that counts for much.

Odd, must have been some caching thing. Changing the language caused it to show up.

The acknowledgement appears to be gone now, unless I'm missing something.

Similar to the mysql-semicolon cluster:

http://jvns.ca/projects/unix-command-survey/graph.html?cente...;

When using ln to link files, I tend to recite:

ln -s "what you want," "where you want it"

This is pretty cool. Simple but extremely useful.

I've written a quick and dirty port to Python, for anyone who'd like to take a look:

https://github.com/bclune/rubber_bullets

For a 12-character password, a computer with 2 decent GPUs (16000M hash/sec for MD5) can crack the numeric password in just over a minute. Once that's known, the real password can be recovered in around 25ms.

This is way cool, though I can't help but think that the results might differ from actual A/B testing because the testing context is explicit. Have you done comparisons to backend A/B testing to see how well the two align?

It would seem that traditional A/B testing allows you to see what actually converts, while this framework would be biased towards user preference--which doesn't necessarily imply conversion. For example, I think Amazon's site is ugly and busy, and given the choice between that layout and a cleaner one, I'd probably choose the cleaner. That said, there's no way they haven't tested the hell out of the home page and discovered that a busy page, though uglier, converts better.