Archive

Archive for July, 2006

Screenshots of DrProject 1.0

July 15th, 2006
Comments Off

Guillaume Theoret took some screenshots of DrProject on Friday; it’s looking pretty spiffy, if I do say so myself. David Scannell found one late-breaking bug on Thursday, and was too busy helping Tom Dean with the install at Queen’s University to finish testing it on Friday, so the 1.0 Final release has been delayed until Monday. We’re so close… ;-)

(Follow the “rest of this entry” link for the screenshots.)

Read more…

DrProject

Another Database Design Question

July 15th, 2006

Apple Viriyakattiyaporn is adding tagging and tag clouds to DrProject this summer, and an interesting database design problem has come up. She wants to be able to tag tickets, wiki pages, milestones, and email messages. (For the moment, tags will be added to email messages after the fact, rather than when they’re sent.) She also wants to be able to search for items with particular tags as easily as possible, and allow people who are writing new components for DrProject to add tagging to those components with minimal grief.

The problem is that different things inside DrProject are keyed in different ways. The key for a ticket is [project, ticket_number], which is [string, integer]. (It’s actually [project, ticket_number, revision_number], since we keep old versions of tickets, but the third field doesn’t matter for now.) The keys for wiki pages, on the other hand, are [project, page_name], which is [string, string].

So how should tags be stored? Option #1 is to have a separate tag table for each component table, i.e., a TICKET_TAGS table containing [project, ticket_number, tag], a WIKIPAGE_TAGS table containing [project, page_name, tag], and so on. That’s simple to write, but not extensible: every time a new tagged component is added, DrProject needs to be told to search its tag table.

Option #2: put all the tags in a single table [component_name, project, component_key, tag]. Search is now easy—but what’s the type of component_key, integer or string? We can stringify integer keys, but that makes it clumsier to look up tags for integer-keyed components, and if we ever have a component with a multi-part primary key, we’ll be in a real mess.

Option #3: all tags for integer-keyed items in one table, while those for string-keyed items go in another. Again, it’ll work, but the SQL to find all items with a particular tag isn’t pretty.

Option #4: add a unique integer ID to every item that is currently string-keyed, and use [project, component_name, integer_id, tag] for the tags table. It’s doable, but saying that the keys for string-keyed tables now have two parts (the string and the integer) messes up the integrity constraints a bit.

For the moment, Apple is going with option #2, i.e., stringifying integer keys and hoping for the best. I’d be interested to hear what other people think — is there a more elegant way out of this?

DrProject

Software Carpentry 2.0

July 14th, 2006
Comments Off

I am pleased to announce the release of Software Carpentry 2.0 (Final). The web site is up, the mailing lists have been populated, all the tickets have been moved into the project’s Trac, and I’ve submitted a proposal for a wrap-up talk to SciPy’06. It’s taken 18 months to complete instead of the 10 I originally planned, but I have a green light to teach the course again this winter at the University of Toronto, and hope that others will pick the course up elsewhere.

Software Carpentry

Dharmesh Shah on “Why Students Make Great Entrepreneurs”

July 9th, 2006

This article from Dharmesh Shah makes for very interesting reading; so does the rest of his OnStartups blog.

Uncategorized

Reorganizing Our Software Engineering Courses

July 9th, 2006

Today, the University of Toronto‘s Computer Science department has a three-course sequence in software engineering: CSC340 (Requirements Engineering), CSC407 (Software Architecture), and CSC408 (Software Engineering, which is a team project course). Nobody is happy with them: students in CSC340 haven’t seen projects big enough to need formal requirements management, so they don’t understand what all the modeling and paperwork they’re being taught is for; there’s a lot of overlap between that course and CSC407; and CSC408 comes too late in their degrees (typically, the last term of fourth year) to help them find summer internships.

We’re therefore thinking about replacing those three courses with three new ones. It’s all very tentative at the moment, but the idea is basically this:

  • CSC301 (Agile Development) would teach techniques appropriate to rapid development of Version 1 of a new piece of software, starting from scratch. The course would be built around a series of two-week iterations using Extreme Programming or one of its cousins; topics would include requirements elicitation via user stories, group dynamics, estimation and prioritization, design patterns and refactoring, continuous integration, and professional ethics.
  • CSC302 (Large Systems Development) would turn attention to the things you need to do when faced with larger, legacy systems. Instead of starting from scratch, students would have to modify and extend something large that they’ve inherited; there’d probably be two iterations in teams of 6-8, with teams swapping code at the midpoint. Topics would include reverse engineering, modeling with UML, project, change, and risk management, traceability, and the CMM.
  • Finally, CSC403 (Advanced Topics in Software Engineering) would be cross-listed as a graduate course, and would cover component-based systems, fault tolerance, performance modeling, deployment, and other advanced issues.

We think the division between CSC301 and CSC302 would be a natural one, and that if students specializing in other areas (HCI, AI, etc.) only take one course, CSC301 would give them an adequate grounding for grad school or their first job. CSC403 is still up in the air a bit, though; it feels like an “everything we didn’t put elsewhere” course. Crucially, students would be able to do both CSC301 and CSC302 before their PEY internship.
So what do you think? What have we missed? What’s in there that doesn’t need to be? What did you get (or are you getting) in your degree that you think we should imitate?

Teaching

Someday

July 9th, 2006

For more than a year now, we’ve had a milestone called ‘someday’ in DrProject, so that we could group all our “wouldn’t it be nice if…” ideas together. What about adding an IRC channel for each project? Someday. How about authenticating against LDAP? Someday.

Prior to 1.0, “someday” was represented by putting “null“ in the ticket’s “milestone“ column.  The two problems with that were (a) we needed special code to translate “null“ to “”someday”“ for display, and (b) it messed up sorting. To fix both, we modified the setup script to create a milestone called “”someday”“ for each project upon creation.

Which of course brought up a new problem of its own: what date should be associated with “someday”? SQL doesn’t have a standard way to represent “a date that is greater than all actual dates” (i.e., a ceiling for the type “DATE“).  We’ve settled on January 19, AD 2038, which is the largest legal date in Unix, but we’re not happy with it — when we put this in classrooms this fall, we ”know” that some students are going to look at it and (quite reasonably) think it’s a bug.

So, what should we do?  Eliminate “someday” entirely?  Go back to using “null“ (and just eat the maintenance cost of more convoluted sorting and translation code)?  Do something else (suggestions welcome)?

Uncategorized

Routing Around Damage

July 7th, 2006

This article from InformationWeek is interesting, in a Friday afternoon sort of way:

John Gilmore once declared, “The Net treats censorship as a defect and routes around it.” Today, that’s how many employees view their IT departments…

Uncategorized

Bitten by WGA

July 7th, 2006

Earlier today, I discovered that Microsoft was making a threat analysis tool available for free download. Great, says I: it might make a good teaching aid in my Software Architecture class, or in the security classes that others at U of T are putting together.

Except that it requires .NET 2.0 to run…

…the installer for which needs Microsoft Windows Installer 3.0…

…which wants to put Windows Genuine Advantage on my machine. WGA is a “phone home” program that checks whether your version of Windows is legit.  I have no problem with that, but I do have problems with not knowing what other information it’s collecting (there’s no pop-up displaying what it’s about to send, with a “cancel” button), and with the possibility (which Microsoft has refused to deny) that WGA might disable my Windows installation (which, I hasten to add, was paid for when I bought this laptop from Gateway).

Kind of negates the warm fuzzy I got from their sponsorship of Developers Without Borders earlier… :-(

Uncategorized

Link Soup

July 7th, 2006

There are days when I believe my blog should consist of a simple redirect to Mike Gunderloy’s Larkware:

  • Buildix is a development platform on a disk: version control, bug tracking, continuous integration, and more, all on top of a single-disk Knoppix. This is the second thing I’ve seen built on top of Knoppix; the first was Quantian, which is a scientific development platform on a single disk.
  • This proposal for using multi-part filenames like TimeSheet.txt.sgml.xml.snapper to identify content. Amazing the lengths people will jump through to avoid metadata… And it makes me wonder whether Monad—sorry, PowerShell—is going to be the open window through which metadata sneaks into the house…
  • Bill Gates is making it harder and harder for open source fanatics to sneer at him. Microsoft’s latest is Develop Without Borders: write an Office 2007 application, and win money for the charity of your choice.

Uncategorized

What I Know About Playing the Bass

July 6th, 2006

Damian Conway spoke here at U of T last night. He’s very engaging, though I think I would have enjoyed the talk more if the examples had been shorter (and if there had been less Lara Croft at the beginning — still not sure what that was all about). The best part came right at the end, when he said (roughly), “One of the reasons I’m a good hacker is that I write code every single day.” My first thought was the number of times I’ve told students to try to find balance in their life: play Ultimate, knit, anything to avoid a one-note existence. But then I thought about what a jazz musician named Al Gorman once told me: you can learn how to play bass like John Paul Jones or Ron Carter in six hours — every day, for ten years. Nobody tells them to get a life; instead, society recognizes that if you want to be the best there is, you have to focus single-mindedly. When programmers do it, they’re called geeks, but maybe that level of geekery is essential. (And maybe that’s why I’ll never be Damian Conway;-)

Teaching