Archive

Archive for January, 2005

Canadian Undergraduate Software Engineering Conference

January 16th, 2005
Comments Off

I spent Saturday at CUSEC 2005, where I met some interesting people, gave a couple of talks [1, 2], and marveled once again at how well Carleton University has managed to reproduce the neo-brutalist architecture I remember from my 1988 trip to Moscow.

It was an interesting conference: created and run by students, with an interesting mix of presentations from profs, grads, and undergrads. The only disappointment was discovering that there wasn’t a single student attending from U of T. UNB, several Montreal-area universities, both of Ottawa’s, Waterloo, and McMaster were well represented, but not Toronto. Maybe Ottawa is just too cold for decadent southern Ontarians… ;-)

So, a big thank-you to Chris Donaldson, Mike Smith, and the rest of the organizers for inviting me up, and for a job well done—I hope to see you next year.

Teaching

Two Kinds of People…

January 12th, 2005
Comments Off

There are two kinds of people in the open source world: those who are in it to help others, and those who are in for the shouting. Tong Shen and I ran into one of the former this week: his name is Brad Anderson, and he just put together a patch to make Trac work with PostgreSQL. Tong had been having problems getting Python, PostgreSQL, and PyPgSQL working on Cygwin. He sent a message to Brad, who responded almost immediately with some helpful advice, and later walked through the same setup procedure Tong was using to make sure it was OK.

So thanks, Brad—and thanks to everyone else who has answered questions and contributed time over the past three years to help us out when we got stuck. Hope we can pay it forward some time…

Uncategorized

Testing Web Interfaces

January 10th, 2005

In this morning’s meeting, I told the Hippo students that we’re going to do analysis & estimation on four things, then (probably) only build three (maybe even two):

  1. refactor Trac to separate the model from the controller (right now, the database interaction code is stirred into the who-what-where-when logic);
  2. add support for multiple projects (Victor Ng pointed out that this is a big task, as it involves major architectural work);
  3. add some kind of group communication mechanism (probably mailing list or bulletin board—instructors don’t like NNTP newsgroups much, and blogs aren’t the right way to arrange for someone to bring TimBits to a meeting); and
  4. build some infrastructure for testing Trac’s web interface.

Two students (Sean Dawson and Kristin Kerr) worked on testing infrastructure for the Java version of Hippo last term, and their final report includes a good summary of available tools. By coincidence, Titus Brown’s blog had an entry today on “Testing Web Sites”. It pointed at the Python Browser Poseur (PBP) web site, and at webunit, both of which I’m going to have students look at. If any readers know of other Python-friendly tools for testing web sites, I’d be grateful for mail.

Uncategorized

Managing Student Projects Using Blogging: First Impressions

January 8th, 2005

If you already know what blogs are, and how they work, you can skip down in this posting. If not, read on…

Students who are new to 49X will have heard me say that I’m tracking each project’s progress using blogs. A “blog” (short for “web log”) is essentially an on-line journal; typically, one person posts articles to it, which many people can then read. You can think of it as being like a mailing list or newsgroup, which only one person (or a small number of people) can send information to.

Here’s how blogs work: when the blog’s author wants to post a new article, she adds information to a file (typically called index.rss or index.rdf) on her web server. Each entry in the file looks something like this:

<item rdf:about="http://pyre.third-bit.com/blog/archives/000166.html"> <title>Why Testing Matters</title> <link>http://pyre.third-bit.com/blog/archives/000166.html</link> <description>This story from the CBC is frightening: apparently, due to a computer error, abnormal radiology results for nearly 40 cancer patients weren't sent to their doctors. If FedEx or Canada Post had lost the results, they'd probably be sued; since...</description> <dc:creator>Greg Wilson</dc:creator> <dc:date>2005-01-07T09:31:09-05:00</dc:date> </item>

The blog’s author almost certainly doesn’t type in this XML by hand. Instead, she typically uses a GUI, or a web interface, which has fill-in fields for the title and description, and which generates the rest of the information (such as the permanent link for the item) automatically. Pyre’s blog, for example, is created using a PHP-based system called Movable Type.

Now, suppose that I want to read some blogs, instead of writing a new entry for this one. On my machine, I keep a list of the URLs of all the blogs I’m interested in, along with the IDs of the entries from each that I’ve read. When I run my blog reader (such as FeedOnFeeds or FeedReader—there are literally hundreds out there), it polls each of those URLs to find out which ones have new entries, then downloads those entries and shows them to me. Once I’ve read them, my blog reader updates its little database (the one stored on my hard drive).

Blogging (which can mean both “writing a blog” and “reading blogs”) is exploding in popularity right now because it addresses one of the biggest problems on the internet: signal-to-noise ratio. Sooner or later (usually sooner), mailing lists and newsgroups are either swamped by people asking questions that have been answered a hundred times before, consumed by flame wars, inundated with spam, or all three. The only solutions (so far) are to have human moderators filter the messages, or to restrict who can post; the former is expensive, and the latter stifles the conversation.

Blogs, on the other hand, are subscription-based, and since each feed usually has just one author, you can quickly decide if you want to keep listening or not. If you don’t, you just remove that feed’s URL from the list your reader checks, and bingo, it’s gone.

Here’s the cool bit. Nothing says a blog’s content has to be written by a human being: it can equally well be created by programs like Trac. Each Trac project generates a blog automatically; every time someone checks something into the project’s Subversion repository, Trac makes a blog entry out of their check-in comments. It does the same thing when someone creates, modifies, or closes a bug report or milestone.

A week ago, I subscribed to the blogs being created by this term’s projects. This means that I can go to one web page, and click the “update” button, and get an up-to-the-minute summary of everything that has happened in each project since the last time I checked. (Assuming, of course, that people write meaningful comments when they make changes: if they write, “Did stuff,” I’m not much wiser than I was before.)

It’s only been a week, but I already know that this is a much, much better way to track multiple projects than having Subversion and the bug tracker send me email. Having everything consolidated on one page means that I can see at a glance that Sean updated Important.java three times in quick succession, or that Laurie just opened nine new bugs. It wouldn’t scale to a hundred projects, but then, no one can manage a hundred different projects anyway.

I already have lots of ideas about how to improve Trac’s project management blogging. I’m not posting them here yet because many of them are contradictory, and because I’m sure all of them have already been tried, critiqued, and improved—I need to spend a few hours googling for prior art. In the meantime, though, I’m hoping to get FeedOnFeeds installed on Pyre some time in the next few days, so that students can track projects’ progress.

Now, if only I could figure out how to integrate instant messaging into all of this…

Uncategorized

Why Testing Matters

January 7th, 2005
Comments Off

This story from the CBC is frightening: apparently, due to a computer error, abnormal radiology results for nearly 40 cancer patients weren’t sent to their doctors. If FedEx or Canada Post had lost the results, they’d probably be sued; since it’s “just” software, my bet is that no one will even lose their job.

Uncategorized

The Big Questions

January 6th, 2005
Comments Off

The Edge Foundation‘s Big Question for 2004 was, “What do you believe even though you can’t prove it?” Answers from 120 scientists and others are now on-line. (Personally, I’ve never given up on the Great Pumpkin…)

Uncategorized

SQL Injection Attacks

January 5th, 2005
Comments Off

Those of you interested in security, or writing web applications, may be interested in this article, which shows how SQL injection attacks work.

Uncategorized

Why Python?

January 5th, 2005
Comments Off

A couple of students have ask why we’re using Python instead of Perl in this term’s projects. After all, Perl is more popular—there are more books about it, and a lot more libraries for it as well.

The answer is that Brent Gorda and I used Perl to teach classes at Los Alamos National Laboratory for two years. When we switched to Python, we found that it only took two days to cover material that had previously taken three. What’s more, students retained more: they were more likely to remember what they’d learned after the class was over, and (crucially) more likely to keep using Python.

If you want to know why students got further with Python than with Perl, check out the Periodic Table of Perl Operators. Yes, that’s right: Perl has so many built-in operators that you need a wall chart to keep track of them. And that’s even before you start counting all the different ways there are to pass parameters, index structures, and so on.

So if Python is easier to learn, why is Perl more popular? I blame history: Perl was in place and “good enough” when web programming took off in the mid-90s, while Python was still in its infancy. As Stephen Jay Gould observed in his book Wonderful Life, random chance plays a larger part in evolution and history than we’re comfortable acknowledging. Sometimes, there is no good reason; sometimes, things just are.

Uncategorized

What the Rest of the World is Doing

January 4th, 2005
Comments Off

This blog posting, from ActiveState‘s David Ascher, describes an art exhibit in Vancouver called Massive Change. It looks fascinating; I hope to catch it when it comes to Toronto.

Uncategorized

Knowing Where You’re Going

January 2nd, 2005
Comments Off

One of the hardest things in any project is to figure out exactly
what you’re trying to accomplish. This template is intended to help
software development teams do that by forcing them to state what
problem they’re trying to solve, who it affects, and why their
solution is a good one. It is taken from:

Gary Pollice, Liz Augustine, Chris Lowe, and Jas Madhur: Software
Development for Small Teams: A RUP-Centric Approach
.
Addison-Wesley, 2003, 0321199502.

The bits on the left, on gray, are boilerplate; the bits on the
right, on white, are to be replaced with something
project-specific. I will post again in two weeks once students’
vision statements are on the web.

The Problem

The problem of developing software in a predictable and reliable manner
affects the management of software projects. Specifically, developers are
not able to predict reliably how long it takes them to perform
development tasks with acceptable quality, which makes it
impossible to effectively plan a project.
The impact is that users and managers are never sure whether the produced software
will meet its requirements, how reliable the software will be, or
whether the software will be delivered on time.
A successful solution would be for developers to become more self-aware of what they do (i.e. the
process they actually follow), how they spend their time, and the
kinds of defects they find in their work.

The Solution

For software development teams
who need to better understand how and when defects are introduced into
their products,
our product is a tool for gathering and reporting performance metrics
that helps developers track and analyze personal software development
metrics.
Unlike the alternative of failing to gather data, or trying to gather it
manually,
our approach helps users gather data unobtrusively, and provides objective
feedback that allows them to improve both individual and team
performance.

Books