Continuing the theme of turning healthy snacks into deadly artery bombs, an apple was sliced, battered, and fried. What emerged from the oil was something so delicious it made Mother Nature weep at her own incompetence in the face of what man hath wrought. — Skepchick: Critical Thinking at its Finest
“You know that sign in the lobby that says improve everything we touch? Please don’t.” — Francis S. Blake, CEO Home Depot
Context: speaking on how Home Depot has had so many initiatives that it wasn’t succeeding at any of them. Source: Home Depot’s total rehab, pg 2. Retrieved from CNNMoney.com on 25 Sep 2008.
The venrable NeuroLogica Blog writes, in Teaching Creationism:
Reverend Professor Michael Reis, Director of Education at the Royal Society has recently advocated the “teach the controversy” approach to creationism in schools.
The author goes on to point out the flaws with said “teach the controversy” approach. Unfortunately, while I entirely agree with the author’s argument against teaching the “controversy” of evolution vs. creation in a science classroom, I don’t think the Reverend Professor is actually suggesting that we do so.
SQL statements in code should always be written using binding. There are a very few edge cases where this is not possible: if you encounter one, you need to re-think your approach so that you don’t need to use that edge case (e.g. perhaps a stored proc or trigger is more appropriate).
Wrong way:
curs = connection.cursor()
curs.execute("SELECT col1, col2 FROM atable WHERE id = " + id_var)
curs.execute("""
UPDATE atable SET col1 = %s
WHERE id = %d" % (new_value, id_var))
""")
Both statements make SQL injection easy. What if idvar or newvalue were ; SELECT * FROM atable ; --?
The first .execute uses string concatenation, the second uses string formatting to accomplish the same goal.
Right way:
curs = connection.cursor()
curs.execute(
"SELECT col1, col2 FROM atable WHERE id = ?",
(id_var)
)
curs.execute(
"UPDATE atable SET col1 = ? WHERE id = ?",
(new_value, id_var)
)
This way, the database driver uses binding to pass the values where the ‘?’ characters are in the statement. The driver takes care of checking for safety and proper datatypes, quoting and escaping characters as needed. This entirely avoids SQL injection.
Wrong way: $sth = $dbh->prepare(”SELECT col1, col2 FROM atable where id = $id_var”); $sth->execute();
Avoid variable substitution, concatenation, and sprintf.
Right way:
$sth = $dbh->prepare('SELECT col1, col2 FROM atable where id = ?');
$sth->execute( $id_var );
Use the ‘?’ prototype in the prepare call, then execute with the variables, in order, to bind to the prototypes.
Productivity is widely pursued: managers want to measure it, workers want to maximize it, and just about everyone seems to want to talk about it. Productivity-enhancing systems abound, from Frankln-Covey to GTD. Most of the productivity systems I’ve seen focus on getting as many things accomplished as possible.
More accomplishment is good, right? Unfortunately, most productivity systems don’t adequately address the concept of opportunity cost: the notion that if you decide to do task A right now, you’re also deciding not to do task B, C, or D right now.
Productivity, to me, is not about how much you get done, but about how much of the right things you get done. Put another way, productivity should be about managing opportunity costs, not merely about managing time.