The Third Bit

A random conversation about John Cleese and training videos at Agile’08 on Tuesday reminded me that I wanted to post about something neat I saw at CAST’08. Everyone attending the talks had a red, a yellow, and a green card with a number on them (the same number for all three cards). If you wanted to start a new discussion thread during question time, you raised your green card; if you wanted to add something to the current thread, you raised your yellow card; and if you wanted to interrupt right now, you raised your red card. In the first two cases, the moderator wrote down your number so s/he could call on you when it was your turn; in the third case, you got to speak right away, but then your red card was taken away, so that you could only interrupt once per session.  It seemed to work pretty well, and I’ll use it in meetings of my own in future.

Now, how do we redesign chat clients to achieve the same effect?

Uncategorized

I had the pleasure yesterday of finally meeting Michael Feathers, author of one of my favorite programming books, and a contributor to Beautiful Code. Along with a couple of other people, we talked for a bit about unwritten books, software design, and the fact that discussion about the latter seems to have stagnated. A lot is still being written about how to put code together, but I can’t remember the last time I heard someone say something on the subject that was genuinely new.

One thing that was new (at least to me) was Michael’s observation that refactoring pure functional code is a lot easier than refactoring imperative code. Like a lot of people, he has been messing around with current-generation functional (or nearly-functional) languages, and he has discovered that when you take side effects away, reorganizing code becomes much, much simpler. I’m still not convinced that Erlang, Haskell, or F# is actually going to be the next big thing, but hey, I’ve been wrong before…

Another thing that came up was a way of teaching students how to navigate large code bases. The idea was to give a good developer some code she had never seen before—some big code, not just a screenful or two—and make a screencast of her thinking aloud as she figured out just enough about how it worked to make a simple change. I would use videos like that in my software engineering courses (and not just because it would save me having to make up a lecture or two); I’d also watch them myself, and I expect that most students who were about to start interviewing for their first jobs would want to sit through them as well. Anyone know of anything like this out there already? Or if not, would anyone like to volunteer to make one?

Learning

Here’s a story for you:

http://compsci.ca/blog/lanschool-threatens-compscica-with-legal-actions/

Tony and Dan created compsci.ca as a web-based community for high school and university kids interested in computer science. [Full disclosure: Dan is doing a Google Summer of Code project under my supervision.] A couple of years ago, Dan found a flaw in LanSchool‘s classroom management software. They informed the company, then published a description of the exploit. Now, two years later, they are being threatened with legal action (in a rather confused way).

If idealistic young coders who do the right thing get whacked for being good citizens, it’s hardly any wonder that so many turn to the dark side. If you’d like to let LanSchool know what you think, you can reach them here.

Later: see also comments from David Crow and Jon Erickson. Jon got in touch with LanSchool, who said they had tried to reach Dan Servos before engaging a lawyer. Dan never got their email (or anything else), but they are now in touch, and hopefully will be able to work something out.

Learning

I’d like to draw a picture—I really would. It wouldn’t exactly be an entity-relationship diagram, or a database schema, but it would combine elements of both, and it would help me explain the model underlying the app I’m currently working on to the whole team (myself included).  But I’m not going to bother, because experience has taught me that it will cost too much to maintain:

1. There isn’t a decent lightweight open source cross-platform drawing tool for this kind of thing: Inkscape and Dia just don’t measure up to Visio and Omnigraffle.
2. There aren’t tools to check those diagrams against actual schemas, or vice versa. Well, OK, there are, but all the ones I have found can only check drawings they’ve created (i.e., they conflate drawing with checking), and none of them talk directly to ORM code like SQLAlchemy or Hibernate.
3. Most importantly, version control systems don’t know how to handle diagrams, even ones stored in SVG or other pseudo-text-based formats. I want “svn diff” to be able to tell me what’s change between the last version of the diagram and this one; I hate launching two versions of a drawing application side by side and playing “spot the change”.  I want merge, too — if Jeff and I are both working on a complex design, I don’t want our tools to make the job even more complex.

So here I am, doodling in my notebook instead of creating something I can actually share with my fellow developers. Pfah.

Uncategorized

Agile’08 starts Monday, which makes me feel that I ought to justify the Big Design Up Front I’m currently doing.  Here’s as far as I’ve gotten:

1. I’m thinking again about access control in DrProject. A user’s membership in a project is represented by a triple (project, user, role), where a role is a set of permissions defining what can be done.
2. The simplest model for permissions would be to define READ and WRITE for each component, e.g., WIKI_READ (“can see the wiki, but not modify it”) and WIKI_WRITE (“can create new pages, or update/delete existing pages”).
3. But tickets mess this up.  Open source projects often allow non-developers to file tickets (in fact, they encourage it). The only way to support this if the only permissions available are TICKET_READ and TICKET_WRITE is to give anonymous users (i.e., people who haven’t logged in) a role that contains TICKET_WRITE. However, that would also allow them to modify or delete other people’s tickets, which is clearly a Bad Thing.
4. OK, so what about TICKET_READ, TICKET_WRITE_ALL, and TICKET_WRITE_OWN? Easy enough to create three permissions—but it would complicate the logic inside DrProject. It also complicates the conceptual model (which I think is actually the bigger burden).
5. Here’s another wrinkle. In every ticketing system I’ve ever worked with, tickets have a one-line “title” or “summary” field, then a longer “description” field. For small projects (our target market), most tickets only need the former, so I’ve been thinking about taking the latter out of the tickets themselves, and providing an easy way to link to specially-named wiki pages (e.g., ticket #123 automatically links to a page called Ticket123, but only if someone has bothered to create it). This neatly supports the common situation in which a “ticket” turns into something more akin to a BBS discussion, where lots of people post back and forth about the best way to solve a problem. But how would the permission system handle this? Would the special logic to handle TICKET_WRITE_OWN propagate to the wiki, so that if a page was associated with a ticket, and that ticket belong to Fred, and Fred’s role in the project included either TICKET_WRITE_ALL or TICKET_WRITE_OWN, then Fred would be allowed to modify the wiki page?  Just writing it out makes my head hurt…

The moral of the story isn’t that there’s a place for BDUF (which all but the most zealous agilistas would acknowledge).  The moral (at least for me) is where that place is.  If you’re doing exploratory programming in a new domain, there isn’t much point trying to do a lot of up-front design: you just don’t know enough about what’s possible or what’s interesting.  Similarly, if this is the ninety-ninth system of type X you’ve built, up-front design probably isn’t economical either: you know the tradeoffs and possibilities well enough to avoid potholes.  In between, though, where you know enough to know that there are thorny issues and delicate tradeoffs, time invested in up-front thinking is time invested well.

Uncategorized

Cameron Neylon complains about the proliferation of networking sites, aggregators, and what-not for scientists. I think he’s right: none of them will succeed until there’s massive consolidation.  Maybe LinkedIn or someone like that could offer a cheap-but-not-free service customized to scientists’ need on top of its existing infrastructure?

Software Carpentry

After years of declining or flat enrolments in Computer Science, we have some good news this year: our first-year numbers this fall are going to be up over last year’s by about 20%.

Learning