“So what will it mean to bear witness in the future?”

They say that history is written by the victors. But now, before the victors win, there is a chance to scream out with a text message that will not vanish. What would we know about what passed between Turks and Armenians, between Germans and Jews, if every one of them had had the chance, before the darkness, to declare for all time: “I was here, and this is what happened to me”?

– Anand Giridharadas in the NYTimes in “Africa’s Gift to Silicon Valley: How to Track a Crisis”.

Ushahidi sounds inspiring.

The project is on Github.

Educational video on ‘Quants’ and their role in the financial crisis

YouTube: “Quants: The Alchemists of Wall Street (Marije Meerman, VPRO Backlight 2010)”

Related: “The Modelers’ Hippocratic Oath”: I will never sacrifice reality for elegance without explaining why I have done so….I understand that my work may have enormous effects on society and the economy, many of them beyond my comprehension.

Programing Links March 7th, 2009

Mike Taylor on Kernighan and Plauger’s “The Elements of Programming Style” (gotta buy and read this)

Eli Bendersky: “The server-side Javascript meme”

PragPub–March 2010: Jason Huggins: “JavaScript: It’s Not Just for Browsers Any More”

“Algorithms are Thoughts, Chainsaws are Tools”, reviewing a short film by Stephen Ramsey on “Live Coding”. Read it and watch it.

Alex Clemesha: “Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip”

Deseret Tech: “NoSQL v. SQL is the worst holy war ever.”

Dennis Forbes: “Getting Real about NoSQL and the SQL-Isn’t-Scalable Lie”

Jesse Legg: “Emacs for Python Programmers: Basics”

the official hudson weblog: “Hudson at PyCon”

The website of Lei Chen: “Setup Perfect Python Environment In Emacs”

Extra Cheese: “Python vs. Ruby: A Battle to The Death”

Martin Fowler: “ConversationalStories”

Code Monkeyism: “What Developers Need to Know About Agile”

Coding Horror: “Cultivate Teams, Not Ideas”

Geoff Sowrey: “What makes a Senior Developer?”

Related:

“The Modelers’ Hippocratic Oath”

Practical Common Lisp

impromptu

Douglas R. Hofstadter “analogy as the lifeblood, so to speak, of human thinking”

Douglas R. Hofstadter: Analogy as the Core of Cognition:

My point is simple: we are prepared to see, and we see easily, things for which our language and culture hand us ready-made labels. When those labels are lacking, even though the phenomena may be all around us, we may quite easily fail to see them at all. The perceptual attractors that we each possess (some coming from without, some coming from within, some on the scale of mere words, some on a much grander scale) are the filters through which we scan and sort reality, and thereby they determine what we perceive on high and low levels.

“A Conversation with Martin Fowler”

Bill Venners interviewed Martin Fowler back in 2002 that resulted in six part series filled with engineering wisdom to absorb.

Among the many exchanges was the following on flexibility that reinforces some principals I try (not always successfully) to put in practice:

Bill Venners: In Refactoring you write, “Before I used refactoring I always looked for flexible solutions. Because design changes were expensive, I would look to build a design that would stand up to changes I could forsee. The problem with building a flexible design is that flexibility costs.” What is the cost and what is the alternative?

Martin Fowler: The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You’ve gained. But if you get it wrong, you’ve only added complexity that makes it more difficult to change your software. You’re obviously not getting the payback.

It’s not hard to guess wrong about flexibility needs. You can guess wrong if requirements change. What you think is a requirement for flexibility now may go away or change in the future. You can also guess wrong if you put extra code into the program to improve flexibility but you don’t get it quite right. You get more complexity without getting the flexibility you were after.

The alternative is to use the XP approach and not put the flexibility in at all. XP says, since most of the time we get it wrong, just don’t put the flexibility in there. Now if you can’t evolve your design safely, then that is a foolish route to take. But if you can evolve your design safely, it becomes quite a nice approach. In fact it becomes a self-reinforcing approach. If you strive to keep your design as simple as possible by avoiding speculative flexibility, then it’s easier to change the code because you have less complication to deal with. The code is easier to understand and easier to change. As a result, you can make changes much more quickly.

Read the whole series:

Refactoring with Martin Fowler

Design Principles and Code Ownership

Evolutionary Design

Flexibility and Complexity

Test-Driven Development

Tuning Performance and Process

Shirky confirms Shenk

Clay Shirky, in a recent talk at Web 2.0 Expo New York, challenged us to stop talking about information overload as an excuse, recognize it as a fact (one that’s existed for a long time and will not diminish in the future), and to work on building better filters.

Watch Clay Shirky on information overload versus filter failure:

Titles like the Boing Boing one are kinda unfortunate because they frame Shirky’s view to be one that would be in opposition to lets say, David Shenk’s from his book “Data Smog”.

Far from it.

David Shenk attempted to identify the information landscape we are living in now way back in 1997. In a 2007 piece in Slate he took a critical look back.

As with any look forward, the book wildly missed the mark with some of its more grim predictions, but in many ways still has much to offer and think about.

In particular, towards the end of the book Shenk proposed a personal call to action for building better filters (learning to be our own for example) and to be better information producing citizens (being our own editors). Big foreshadowing of Shirky’s talk there.

Most reviews of the book focussed on Shenk’s definition of the problem and pooh-poohed his suggestions. So here we are, many years down the line, and most of the focus is *still* grousing about ‘information overload’.

Clay Shirky’s point is its high time to stop doing that and get busy building the tools, protocols, customs and businesses that will help us not only deal with it, but thrive from it.

A great description of the bug elimination process

John Graham: “A bad workman blames his tools”:

1. Find the smallest possible test case that tickles the bug. The aim is to find the smallest and fastest way to reproduce the bug reliably. With heisenbugs this can be hard, but even a fast way to reproduce it some percentage of the time is valuable.

2. Automate that test case. It’s best if the test case can be automated so that it can be run again and again. This also means that the test case can become part of your program’s test suite once the bug is eliminated. This’ll stop it coming back.

3. Debug until you find the root cause. The root cause is vital. Unless you fully understand why the bug occurred you can’t be sure that you’ve actually fixed it. It’s very easy to get fooled with heisenbugs into thinking that you’ve eliminated them, when all you’ve done is covered them up.

4. Fix it and verify using #2.

Read the entire piece.