A while back, a few of my 49X students built a tool called Psiphon to measure Internet censorship around the world. Today, the Globe and Mail ran a story on it. Very cool—very cool.
Uncategorized
I’ve seen the phrase “post-modern programming” used a lot in the past few
months to describe the notion of improvising web interfaces to useful
applications (like Flickr or Google Maps), and then gluing them together
to create something new. This table shows a cross-product of ideas, so that you can see who’s gluing MSN
Messenger and eBay together, or NASA and Flickr. Very cool.
The Software Carpentry lecture on regular expressions is now on the web. It’s a bit of a jump from the previous lecture on design, but given how shaky the latter was, I needed the cuddly warm blanket of working on something I’m sure I understand. As always, comments and corrections to me, please.
Sean, Michelle, and I spent a couple of hours yesterday writing and updating documentation for DrProject. The first 1.0 release candidate is now up on the web; while there are lots of little things to fix, I’m 99% confident we’ll be able to announce it, and open up the Subversion repository, within the week.
Which makes this piece, by Marc Hedlund, very timely. I’m as amused by the invented-for-hype term “Web 2.0″ as the next person, but that doesn’t change the fact that software development has changed in the last ten years. Here’s my take on Hedlund’s list:
The shadow app (which is his name for the internal application a company develops in order to figure out how their publicly released application is doing): we don’t have anything like this yet for DrProject, but one of the principal reasons we built it was to collect data on how undergraduates program, so that we can improve our courses. Karen Reid and I are taking Steve Easterbrook‘s grad course on Empirical Research Methods in Software Engineering this term, in the hopes of learning how to design studies and experiments that are scientifically credible; our “shadow app” will be driven by what we are learning there.
Sampling and testing, i.e., randomly show a small fraction of your visitors the new interface, and see how they use it, before releasing it generally. I don’t think we’ll ever be able to do this in the classroom: the code of ethics prevents us from varying the conditions under which students work solely to collect data without first getting informed consent, and experience elsewhere is that less than 10% of students will bother to fill in the appropriate form. We might be able to do this with non-course projects, like DrProject itself.
Build your own API: of course. Chris Lenz remounted DrProject on WSGI in January, so building a SOAP API (or similar) should be straightforward. I’d love to see a DrProject-friendly Eclipse plugin…
Ship timestamps, not versions: no. Once we open up the Subversion repository, people can grab whatever they want, whenever they want. We’ll still do old-fashioned releases—it wouldn’t be fair to students who are using it in courses to push anything that hadn’t been thoroughly tested.
Developers—and users—do the quality assurance. We had to do this for budgetary reasons, but—no, who am I kidding? We chose to do this: I could have had one of the three people working on the project in January do QA full time. I know that dedicating some people to QA has been proven over and over again to be a more efficient way of producing usable software; I guess I’m just a sinner at heart.
Developers—and executives—do the support. Yes.
The eternal beta. No. Beta testing started as a way to give a few valued or experienced customers a sneak preview of what the next release was going to contain; it has degenerated into a two-syllable shorthand for “you can’t blame me”. I can’t ask students facing hard deadlines in several courses at once to rely on DrProject unless I’m sure it’s stable, and if I’m sure, why would I bother to call it a beta?
So, what’s next? More testing infrastructure is at the top of my list: I’m particularly excited by the newly-announced Selenium IDE, which is a Firefox extension that lets you record, edit, and debug tests. Figuring out a way to run under mod_python is up there too—we have to run as a pure CGI right now for security reasons, which won’t scale to the kinds of loads we expect fifteen minutes before a major hand-in date.
And then? We’d like to figure out what the simplest useful requirements management and traceability tool looks like; we’d like to add some sort of continuous integration (that can handle builds in several languages, without requiring students to do a lot of configuration), and progress charts that let students see how they’re doing compared to the rest of the class (a la JRefleX) would be cool as well.
But first we have to get the 1.0 release out the door…
I’ve just posted a completely new lecture on object-oriented design ideas. I’d be very grateful for high-level comments: is it useful material? Do you think that relatively inexperienced programmers will get it? Etc.
Yes, you read that right: a dating service for Perl modules, which launches on February 14. Oh, and Titus has posted an introduction to testing web applications using twill and wsgi_intercept, which we may plagiarize in order to test DrPython (which is now just days away from its 1.0 release).
UPS messed up a delivery from the States again today. (Apparently, they find it hard to remember that Canada is an independent country, with its own taxes and regulations and stuff.) Having wasted hours wandering around their responsibility-avoidance systems last year, trying to sort out similar problems, I’d like to make a request: if you’re a publisher sending me books to review, please, choose someone — anyone — else.
*sigh*
I’ve split the lecture on object-oriented programming in two; the first one is now on the web (without diagrams). This ties with the rewrite of the style lecture for “most changes since the fall”, so comments and corrections would be very welcome.
Eleven days ’til the AAAS workshop…
When I was a lad, back in the early 1980s, Prentice-Hall defined good programming books (at least for me). The C Programming Language, The Unix Programming Environment…they set the standard that most other books failed to meet.
Five years ago, O’Reilly had clearly captured the flag. From Programming Perl to Linux in a Nutshell, if a propellor-head needed to know it, it could probably be ordered from oreilly.com. They didn’t just reflect the explosion in pragmatic programming that accompanied the internet boom; they also helped to shape it and give it direction.
These days, though, I’m not sure that any book publisher can see more than thirty seconds ahead. Few of my students in Toronto buy books at all: they turn to instant messenger first (“Hey, does anyone know how…”), and then to Google. So how is O’Reilly coping? Judging from the four books reviewed here, pretty well.
First on the list is Laura Wingerd’s Practical Perforce. For those who haven’t seen it, Perforce is the sweetest version control system ever created. Wingerd has worked on it from the beginning, and the depth of experience that has given her shines through in this thoughtful, well-written book. From basic operations to the complexities of administering repositories used by hundreds of developers, Wingerd patiently shows readers what the real issues are, how best to think about them, and how Perforce can solve them, all without a whiff of marketology. I particularly appreciated her discussion of how to manage branching and merging: even if you’re using another system (such as Subversion), the best practices she describes can save you a world of pain.
If Practical Perforce was the voice of experience, Google Map Hacks is a little kid going, “Wow! Wow!” in a toy store. The seventy tips and tricks collected in this book range from how to query GM’s occasionally-unpredictable interface, to tracking your movements, to browsing Planet Earth for photo shoot locations.
I enjoyed this book, in large part because its contributors clearly feel that social engineering is as important as software engineering. Sharing your favorite walks around your community with other people isn’t really about coding; it’s about drawing attention to beauty, and inspiring change. OK, that sounds pretentious, but it’s true, and remember: this particular earthquake has only just begun.
Last up is a pair of database books: Beaulieu’s Learning SQL and Molinaro’s SQL Cookbook. The first one was solid, though not inspiring: it covered everything that a modern introduction to SQL ought to, using the same kind of banking and HR examples that instructors were using twenty years ago. If you’re new to relational databases, it’s a good a place to start, but don’t expect it to set your heart racing.
The SQL Cookbook, on the other hand, did provide a few “cool!” moments. Like everyone else, I’m constantly frustrated by the fact that SQL written for MySQL won’t run on PostgreSQL, PostgreSQL queries won’t run on DB2 or SQL Server, and so on. Well, not only does this book show how to solve commonly-occurring problems, it also explains how the solutions differ for different database packages. I have already replaced a couple of loops from my Python code with calls to RDBMS-specific functions, and the discussion of “Knight’s Values” helped me solve a problem that had been nagging me for weeks. As long as O’Reilly keeps publishing books like this, at least one programmer will turn to them before Google.
Rich Gibson and Schuyler Erle: Google Maps Hacks. 0596101619, 366 pages.
Anthony Molinaro: SQL Cookbook. O’Reilly, 0596009763, 628 pages.
Laura Wingerd: Practical Perforce. O’Reilly, 0596101856, 358 pages.
Now, through the miracle of AJAX, collaborative over-the-web fridge magnet poetry. Gibson said that the street finds its own uses for technology; he should have added that our inner children do, too.
Now, how the hell do I apply this to software engineering?
Recent Comments