First Shell Lecture for Software Carpentry is Up
The first lecture on using the shell is up on the new and improved Software Carpentry web site. Comments and feedback would be greatly appreciated.
The first lecture on using the shell is up on the new and improved Software Carpentry web site. Comments and feedback would be greatly appreciated.
That’s just one of the answers to the 2006 World Question, “What’s your dangerous idea?”
We had our first on-line meeting about DrProject today. (I’ve decided that the one we had in December was the zero’th
. The meeting itself went pretty well, though I’m very conscious of how little time we actually have to get things done: one month is going to fly by. I’m also a little embarrassed that I didn’t make time over the holiday to clean up the DrProject Subversion repository: what Chris, Sean, and Jason are inheriting looks a bit like the remains of a moving-out party. The current task list is in the meeting minutes; the biggest items are:
One thing that struck me during the meeting was how much time we spent synchronizing. Are we done with this point? Does anyone have anything else to say? (Long pause.) OK, let’s move on to—oops, no, it looks like someone does have another question (which is now unfortunately interleaved with discussion of the next point). One way to fix this would be to support threading in IM clients. Another, which I think would work better socially, would be to build in support for voting. Participants ought to be able to click “Call a vote”, type in their question, and have it pop up in everyone’s client with yes/no (or +1/0/-1) buttons. As you vote, you should be able to see who else has voted, so that laggers could be prompted, and disagreements aired. Drawing a line under part of the discussion would then be as simple as asking, “Are we done?” and watching the clicks come in.
Charles Petzold wrote the Bible (or Necronomicon, take your pick) on Windows programming. He’s blogging about the creation of his next book, and has posted these five simple rules for aspiring technical authors:
#4 is the only one I’d quibble with—I think how the code was written is as important as its final state—but it’s all still excellent advice.
I have revised the Introduction to the Software Carpentry course. This was the easy one: no diagrams, no code fragments, no glossary entries; the rest will be harder. I’d be very grateful for feedback, comments, and corrections. (And yes, audio will follow, but not today—my nephews are playing Zombies downstairs, and juvenile shouts of, “Eat lead you undead scum!” aren’t quite the background I have in mind.
Recent Comments