Last summer, we tried to create a concept map showing how the big ideas in Software Carpentry related to each other. We weren’t satisfied with it, so we set it aside. With our first anniversary coming up in three months, though, it’s time to revisit the idea of a high-level overview of the course. To that end, I have posted a first attempt at a competence matrix that organizes skills into levels. Please leave comments on that page telling me what’s wrong or missing.

As I’ve said several times now, we’re going to add a lecture on high-performance computing to the course. We have rough outlines of the content in the version control repository, and feedback would be very welcome.

1. Introduction
2. The Example Application
3. Improving Sequential Performance
4. Profiling
5. Parallelism Defined
6. Computer Architecture in Ten Minutes or Less
7. Task Farming
8. Basic MPI
9. Collective Operations in MPI

Have you ever wondered how scientists test their code? We have, and we’d like you to help us find out. If you use MATLAB, please have a look at our new research project—and please forward the link to other groups and lists where we might be able to recruit people. (Of course, we’d also welcome input from NumPy users…)

See also these posts from Steve Eddins, who built the MATLAB xUnit testing framework, and thanks in advance for your help.

A couple of weeks ago, I went to the University of Wisconsin – Madison to speak at a three-day software skills boot camp run by The Hacker Within, a grassroots student group that’s taking the same “teach what you know, learn what you don’t” approach as the Peer-to-Peer University and other efforts. I was very impressed then, and am even more so now that I’ve had time to reflect on what I saw (and recover from my close encounter with Delta Airlines, whose motto appears to be, “We don’t care because we don’t have to”).

And then, a couple of days ago, I got mail from a graduate student in Mississippi who’d like to organize an online run of Software Carpentry through P2PU. We’ll post details soon, but it’s got me thinking more about how we could experiment with different delivery models to get this stuff into as many hands as possible, as quickly as possible. I would therefore like to ask if you (yes, you) would like to organize a boot camp on site wherever you are. We can provide content, share our experiences, and (perhaps most importantly) send someone who has done one of these before to wherever you are to help out.  If you think you can get a couple of dozen grad students, faculty, lab mates, or fellow fans together for three days to learn and share, please add a comment to this post to let us know.

Work as though you lived in the early days of a better nation.
— Alasdair Gray

We recently experienced a spate of spam and fake user accounts on the course discussion forums.  In this post I’ll briefly explain what we’re doing to stop that from happening again, and how the technology works.

The course forums are powered by bbPress, the forum software written by the WordPress folks.  When I first installed it I left it with the default configuration settings and without doing anything in particular to lock it down from spammers.  Bad idea.  When I checked this morning we had over fifty fake user accounts, and two spam postings.

I had to manually remove the fake user accounts — luckily this is easy to do since either the names (e.g. “google directions plus”) or the user’s website is obviously spammy.  I then activated two plugins: Akismet to filter out any future spam posts and reCAPTCHA to stop automated computer programs (i.e. bots) from registering fake user accounts.

Akismet works by inspecting posts or comments for known spam-like features and flags them as spam if they match.  It is offered as a web service, so all we needed to install was a simple plugin for bbPress that sends each post and comment to the Akismet server and receives back an answer as to whether it is suspected to be spam or not.

The reCAPTCHA plugin adds a visual or audio test to the registration form on the course forums.  The test involves writing down scrambled words presented in an image or an audio clip and the test is designed to be possible for humans to answer correctly but not for computer programs.  The reCAPTCHA system is unique in that by correctly solving the tests you are also helping to digitize books, newspapers and radio audio.  That’s because words for the reCAPTCHA tests come from one of those sources when they have been flagged as unreadable during an automated digitization process. Thus the words are known to be currently unreadable by computer programs  and this guarantees that bots will be unable to pass the test.  When a human passes the test they will have had to correctly read the word and the correct spelling is sent back to the folks digitizing the material.  Nifty.  You can learn more about exactly how the reCAPTCHA system works here.

Cameron Neylon recently made the case against peer review once again; the dialog near his posting’s end is too accurate to be funny.  In this light, calls for peer review of scientific software are probably misplaced; we need a better mechanism than one that’s already mostly failing.

Jon Udell’s 1999 book Practical Internet Groupware was a revelation for me: it was the first coherent explanation I’d ever read of how the disparate collection of technologies and social conventions that we call “the web” fit together, and what the deeper patterns and concepts beneath them are. After a lot of further work and thought, Jon has condensed those ideas into seven principles—or as he puts it, “Seven Ways to Think Like the Web“. These concepts are the most meaningful definition yet of what the phrase “computational thinking” actually means, and of what people who aren’t programmers need to know in order to use the web effectively. As I said in the post on Tom Limoncelli’s plea to software vendors, we’ll know we’re teaching the right things, the right way, when people who have done this course understand these principles and how to apply them.

Well this was a nice birthday present: the Python Software Foundation announced today that they will provide some support for a Software Carpentry sprint in Toronto in July. Thanks, folks—we’ll post details about what, when, and where as soon as we have them.

Last night, Mike Bayer (@zzzeek) tweeted:

Why are “scientists”, who are so dramatically smarter than me, such dumdums when it comes to basic programming skills: http://bit.ly/fWPtjW

Taavi Burns (@jaaaarel) replied:

Ask @gvwilson of @swcarpentry?

So here I am, and what I want to say is:

Scientists aren’t stupid: software is.

Seriously. I spent an hour and a half last night trying and failing to get Thunderbird and Dreamhost’s email to play nicely together. Today, I’m wrestling with the fact that Python’s multiprocessing library gets lost in infinite recursion if you try to do something crazy like, oh, I don’t know, leave out the if __name__ == '__main__' check (but only on Windows). In both cases, the parties involved can explain why it does what it does, and in both cases, I just… don’t… care.

So here’s what I want to say to software developers who wonder why scientists are dumdums. When a scientist says “a>b doesn’t work for complex numbers”, it’s not their fault. When a programmer says “a>b doesn’t work for email messages”, odds are good that it’s because two standards committees didn’t talk to each other, or it’s a deliberate fail for backward compatibility with something written in 1997, or something like that.

The key concept here is one that Irving Reid introduced me to: learned helplessness. If something fails repeatedly, people learn that it’s not worth trying to make it work again. That lesson sticks, even when circumstances change in ways that make success possible. Once someone has wasted hours trying and failing to get A, B, and C to play together nicely on their laptop—once they have spent hours figuring out why that failed, only to find that what they learned is useless when the next problem crops up—it’s quite reasonable for them to stop trying, because the odds are against them succeeding without superhuman effort. As long as software conditions people to believe that, to first order, they’re doomed—as long as “doubling your chance of succeeding” means raising the probability from 1% to 2%—maybe they’re right to put that time into the science they wanted to be doing in the first place.

MIT’s OpenCourseWare initiative was (and probably still is) the highest-profile “open and online” initiative in higher education.  According to this article, they’re rethinking their approach to help the self-directed learners who have emerged as their biggest users. I’m really excited by this, and by P2PU‘s peer-to-peer model, and all the others that are emerging (including the hybrid models we’re trying out). I also think that asking “which model will win?” misses the point: each one is a best fit for a different combination of educator, content, and learner.

Now, if only someone would build a presentation tool that played nicely with these models…