…what really matters in programming…is not…solving puzzles and being the brightest kid in the class. It is…realizing that the complexity of software dwarfs even the most brilliant human; that cleverness cannot win. The only weapons we have are simplicity and convention. What is truly decisive on the battlefield are attitudes: hard work, responsibility, and paying attention to reality instead of the voiceover in your head.
My Google Summer of Code student, Chas Leichner, started his project this week. His aim is to build a “record, annotate, and replay” extension for IDLE, so that instructors can create program walkthroughs for students. We think this will be better than simple screencasts because they’ll be interactive: if a student wants to explore an alternative execution path partway through a replay, or look at some values that the instructor hadn’t thought to show, she’ll already be in the IDE. (For a rough-and-ready look at what we have in mind, check out Geoff Salmon’s web-based prototype.)
We’d welcome comments, particularly on the third post: how instructors add comments or directions to recorded program execution traces is going to be the key determinant of this tool’s usability.
This post from Darryl Cunningham is a damning summary of the harm done by Andrew Wakefield, who was paid to “prove” that vaccines cause autism. Children have died, and will continue to die, because of what he did; if a big pharma company had acted exactly the same way, there would have been street protests outside its headquarters and a massive class action lawsuit… As Cunningham says, though, the real villain here is the popular press, which will run any scare story that comes their way on page 1, and the correction on page 100 (if at all). It makes me angry and weary at the same time…
he Prediction API enables access to Google’s machine learning algorithms to analyze your historic data and predict likely future outcomes. Upload your data…, then use the Prediction API to make real-time decisions in your applications.
Interesting, and possibly very useful, but is Google going to keep a copy of my data for its own use? Or will it record some characteristics of that data (e.g., to improve its algorithms)? The former seems unlikely, but then, so did the success of Javascript as a general-purpose programming language. The latter sounds very possible, which makes me worry about accidental information leakage, particularly through post-facto correlation.
Their privacy policy doesn’t explicitly mention uploaded data (though it’s very clear about what Google will and won’t do with personal data). As of right now, their product-specific elaboration doesn’t seem to have anything either. The Terms of Service for their APIs looks promising, but Section 4 (“Your Data”) just says:
You’re responsible for your data.
” Google claims no ownership or control over any of your Data. You retain copyright and any other rights you already hold in the Data, and you are responsible for protecting those rights, as appropriate.” OK, but that doesn’t say that they won’t keep a copy, or keep a copy of any metadata or aggregated statistics that they calculate from it.
“By submitting, posting, displaying, or transmitting Data on or through the Service, you give Google permission to process your Data for the sole purpose of enabling Google to provide you with the Service in accordance with its privacy policy.” OK, they’re not allowed to process my data to do other things than the service I signed up for, but again, what about any derived metadata?
I’m being deliberately paranoid here, but past experience with licensing and other legal matters has taught me to assume that contracts mean exactly, and only, what’s written. I’d be interested in hearing from anyone who actually is a lawyer about whether my “aggregate, record, and use” scenario could be defended.
I had a conversation yesterday with a couple of friends about different kinds of startups, the kinds of people who start companies, the “lifestyle company” meme, and a few other topics. One of the things that came up was how little discussion there is of software practices, i.e., software development shops that are run along the lines of a medical or legal practice, with steady work but no dreams of expansive growth.When I look at what my friends are doing, I see more than a few who would be happy to keep their operation the size it is indefinitely, just as many doctors would rather stay in an office with half a dozen colleagues and a stable patient base, rather than found and run a hospital. But there’s little or nothing in the academic or business literature about such places: everyone seems to assume that if you’re starting (or in) a software company, your goal must be growth, growth, and more growth. I wonder how many of us would be happier if starting or joining a practice, rather than being the next [name of four-year-old billion-dollar company goes here], was a recognized, encouraged, and well-described career path.
I’m very pleased to announce that I’ve just signed a contract with Pragmatic to edit a book on the architecture of open source applications. Our goal is to describe the architectures of some moderately complicated pieces of software, both because they’re interesting in their own right, and to show readers how experienced software designers see the world. Contributors will explain:
What are the major elements of the application?
How do they interact?
Why?
What alternatives did you consider and discard?
What tradeoffs did you make?
Why?
The current list of contributors and topics is included below; I’m very excited to be working on this, not least because all of the author royalties will be donated to Amnesty International.
Recent Comments