Bruce Schneier has excerpts from the Canadian Privacy Commissioner‘s Annual Report. As another Canadian once said, “You don’t know what you’ve got ’til it’s gone.”
DemoCamp7 was held last night in a pub downtown. It started late (A/V issues), and while there was a good crowd, I was a little let down by the demos themselves: Cameron Browning’s home-made data glove and 3D web site visualizer felt kind of 1990s, and all we got to see of Paruba, FeelingBullish, and Domainer‘s page-building tool was the UI, not the technology behind it. Damien Conway’s lightning tour of Perl 6 was entertaining, but please, could they do some usability studies before letting people overload the letter ‘d’ as an operator?
That said, it was a good crowd, and I enjoyed seeing how people were using AJAX, Ruby On Rails, and other shiny new toys. DemoCamp8 and DemoCamp9 are already filling up; look forward to seeing you all there.
Note: Damien is talking tonight (Wednesday, July 5, 2006) at 6:30 pm in Room 1180 of the Bahen Building at the University of Toronto, 40 St. George St. Everyone is welcome.
Last week, I asked whether design by contract could please be the next thing in programming to go mainstream, so that we could manage version updates more sensibly. I don’t actually think there’s much chance of it happening, but one of the emails I received about it made me realize that two other things I care about have already passed the tipping point: static and dynamic code analysis.
As their names suggest, the first is concerned with looking at the code while it’s standing still, while the second examines how the code behaves when it’s running. Static analyzers like Lint have been around for years—so long, in fact, that “lint” has become a verb, just like “make”. Today’s static analyzers, like Checkstyle, can detect many more problems, and are extensible, so that users with a grudge can add new intelligence piece by piece. Dynamic analyzers have just as ancient a pedigree: prof, gprof, gcov, and their ilk have been helping people figure out which bits of their code are actually being used for thirty-odd years.
What’s new is how frequently these tools are now integrated into other systems. The JUnit extensions page lists several tools that create coverage reports in the wake of unit tests (courses here at the University of Toronto have used Clover to great effect), which are themselves showing up in CruiseControl and other continuous integration frameworks. A few weeks ago, my twenty-line change to someone else’s C++ was bounced by a Subversion pre-commit hook because Insure++ found a memory leak.
I think this is wonderful, but I’m a little concerned at how little attention it’s getting in classrooms. We’re still trying to get instructors to adopt version control for all programming courses, and I was told a month ago that students doing the major project course sequence at the University of Waterloo‘s Software Engineering program aren’t required to use any particular tooling at all. I’d love to add some of this stuff to DrProject, but I’m afraid it would make it less accessible, rather than more.
Added 2006-07-19: Panagiotis Louridas has an article in the July’06 issue of IEEE Software that talks about static checking tools for Java, particularly FindBugs. I’ve griped before about how hard object/relational mappers and other “hide the code” tools are to debug; if someone could build a lint-like tool for them, a lot of people would applaud.
This, from Mike Gunderloy, who got it from Ned Batchelder. Can you tell it’s a procrastinatory kind of day?
Recent Comments