A US court has ruled that intelligent design cannot be taught in a Grade 9 class, because it isn’t science. Score one for Team Enlightenment.
Once again, I have to quote William Gibson: the future is already here, it’s just unevenly distributed. Check out eyeOS, a desktop-in-a-browser that comes with editor, calculator, and a bunch of other tools. Sure, it’s kind of slow, but it’s very pretty… You can even take it for a test drive.
I watched part of the first Canadian federal election debate last night. Then I read Michelle Levesque’s latest post. Given the option, I’d vote for her.
Thanks to generous support from Prof. Steve Easterbrook, Sean Dawson will be working on DrProject alongside Chris Lenz and Jason Montojo in January. We’re looking forward to a productive month.
I’m re-thinking the lectures in the Software Carpentry course based on feedback from this term’s students. I’m going to merge the three lectures on different development processes into one, and use the space that frees up to talk in more detail about programming style and software design—assuming, of course, I can think of something to say that isn’t banal.
I also want to talk about the material in an article by Paul Dubois in the May/June 2005 issue of Computing in Science & Engineering called “Maintaining Correctness in Scientific Programs”. Here are a few key lines from the introduction:
The more frequently a program is changed, the more difficult it is to maintain its correctness… Most programmers can reasonably tell when their programs are incorrect, but for scientific programmers, this is not the case. A bug that doesn’t cause the program to fail in an obvious way could be indistinguishable from an error in modeling the real world with equations… Solving this problem must be the focus of our methodology, be it for a single person writing a 10,000-line program [or] a team of 20 or more writing half a million lines.
Paul then outlines a strategy based on defense in depth which has the following layers:
This immediately struck me as an excellent way to organize and motivate several important parts of the course. It also points out some holes that I’ll need to fill. Oh, to have more hours, and more hands…
Every time I complain about Python’s muddled response to Ruby on Rails, someone pushes back by saying, “What does it matter?” This screenshot, taken from the “what we provide” page of a web hosting company, might serve as an answer:
Yup: Ruby gets a whole column of its own, while Python is tucked into “Miscellaneous”, along with OCaml. How many new users is that going to attract?
The Jan/Feb 2006 issue of American Scientist, the magazine of Sigma Xi, contains an article on Software Carpentry.
So, how’s your web site doing? Are people reading what you blog? Downloading your software? Simple statistics are fairly easy to gather, but if the web is how you make your living, simple stats may not be enough: you might need to find out what percentage of your customers are being referred from where, or how often they wander down blind alleys in search of the Mac beta of your latest game.
If this is your current migraine, Web Site Measurement Hacks may be your new best friend. It mixes practical “do it this way” advice with cogent discussion of why you’d want to do some things some way, and other things not at all. It did jump around a little more than some of O’Reilly’s other “Hacks” books, but that’s partly the nature of the subject. Recommended.
Modeling the Internet and the Web sounds like it’s about the same topic, but it isn’t. Instead, it surveys various mathematical and statistical models of page connectivity and user behavior. There are chapters on text analysis and advanced web crawling, and lots of comparisons of theoretical predictions with actual data to inspire confidence in the modeling techniques used. If this is your thing, this is your book.
Brian Hook’s Write Portable Code is also recommended. Anyone who has ported a non-trivial C or C++ application from one OS to another will have experienced some of the pain he describes. What makes this book worth owning is the breadth of its coverage, and the way the author ties various solutions together. Everything from line endings and byte ordering to stack layouts and exception handling is present and properly indexed. What’s more, the writing and code samples are cleanly laid out and very readable.
Finally, there is Bruce Tate’s Beyond Java. It’s central messages are that (a) Java’s accelerating bloat is getting in the way of leading-edge developers, (b) dynamic languages like Ruby are a lot more fun, and (c) you can never have too many kayaking anecdotes. I agree in part with the first point, though of course one geek’s bloat is another’s gotta-have-it. I’d agree with the second point, too, although more data and less ramble would have made it more convincing. As for the third, well, I think the analogies are forced, and make the book feel more Tony Robbins than Brian Kernighan.
Brian Hook: Write Portable Code. No Starch Press, 2005, 1593270569, 248 pages.
Eric T. Peterson: Web Site Measurement Hacks. O’Reilly, 2005, 0596009887, 405 pages.
Bruce Tate: Beyond Java. O’Reilly, 2005, 0596100949, 185 pages.
Book reviews by our very own Jorge Aranda and Laura MacDougall are now on the DDJ web site. (Unfortunately, they’re behind a paywall, but trust me, they’re spiffalicious.)
The second round of Google Summer of Code mini-articles are now on the Doctor Dobb’s Journal web site.
Uncategorized
Recent Comments