The Third Bit

I’m still not convinced that distributed version control is the future, mostly because I don’t believe in the future: as always, there will be many mixed together, and since my focus is getting novice developers up the learning curve, I’m going to continue to rank initial ease of use over power in the hands of professionals.  That said, Bugs Everywhere looks pretty cool: it’s a distributed bug tracking system that works with Arch, Bazaar, GIT, Mercurial, and RCS. No master copy, just parallel universes that merge occasionally…  Neat.

But once again it prompts me to ask: where are the computer scientists while all this is going on?  None of the systems I’ve mentioned in this post was created by a grad student as a research project, and I’m willing to bet that most profs in CS departments don’t even know they exist. *sigh*

Uncategorized

I really did mean to blog several times a day about this term’s code sprint, but too much was happening during the day, and I was too tired at night. There were lots of high points:

• Andrew Trusty, Andrew Louis, Andrey Petrov, Severin Gehwolf, and Blake Winton came out for part or all of it to help, just because. Thanks, guys.
• The PyVCal team, who are building an abstraction library on top of Perforce, Subversion, and Git, got some scripts working with all three, and Derek Kwok started building a mock implementation of the API to use in testing.
• The OLM team made huge strides forward: marking, some major simplification of their data model, and lots more.
• Basie (the rebuild of DrProject on Django) also made huge strides: we have charts (using Flot), a partly-AJAXed ticketing system, user preference pages, lots of new UI design, more wikification, and lots of other things that I’m forgetting right now.
• Karen Reid and I started using Twitter. But we could quit any time, honest.

Many thanks once again to Alan Rosenthal, Vlad Sekulic, and especially David Wolever for tech support, and to Jason Whyne, Liz Blankenship, Heather Grant, and James Leung for coming all the way to Toronto to hack for three days.

Further commentary from Mike Conley, Phyliss Lee, Aran Donohue, and Andrew Louis.

DrProject, Teaching

Wow — Scott Meyers’ next book is going to be about making code go fast, and he has posted a spreadsheet listing his sources, which he promises to update regularly.  As if I didn’t already have enough to read…

Uncategorized

The good news is that after a long hiatus, DemoCamp is back: Toronto’s 19th high-tech show-and-tell/meet-and-mingle will be on March 3 at the Imperial Pub. The bad news is, tickets appear to have sold out within half an hour of the announcement, so the only way to get in now is to volunteer to give a demo—details are on the announcement page.  Stay tuned for more information…

DemoCamp

Still trying to wrap my head around REST, and have a question for the lazyweb.  Suppose my app contains users and groups, with a many-to-many relationship between them (i.e., a user can belong to any number of groups, and a group can contain any number of users.  I can identify users as /app/user/fred, /app/user/jane, etc., and use GET/POST/PUT/DELETE to fetch, create, update, and delete.  (Yeah, I know, GPPD != CRUD, but you get the idea.)  I can similarly use /app/project/red and /app/project/green to identify projects, but what should I use to identify memberships?  /app/project/green/user/fred?  Nope: it mixes category identifiers (‘project’, ‘user’) and item identifiers (‘green’, ‘fred’), and more importantly, implies that users are sub-categories of projects—it would be just as logical to use /app/user/fred/project/green, which means that both are probably wrong.

In the relational database world, of course, many-to-many relationships are almost always represented by introducing new entities, such as a tuple <<17238917, ‘fred’, ‘green’>> (where 17238917 is a magic number created by the system for its own use, and not exposed to the outside world).  Is that the right way to do many-to-many in REST?  I.e., should /app/membership/17238917 return the pair <<’fred’, ‘green’>>, while /app/project/green/members returns a list of magic membership tuple IDs, and /app/user/fred/groups returns ditto?  What’s the right (or at least most common) way to do this?

Uncategorized

A former student and co-author, now at Google, has posted slides from a talk explaining engineering to high school students. She’s done a pretty good job…

Uncategorized

0635: In a little less than three hours, the students working on several of our open source projects will put their heads down for a three-day code sprint. I’ve been looking forward to it for weeks: it’s my first chance to meet Jason, Liz, Heather, and James in person, and between the pizza, the whiteboard re-architecting, the usability testing, and just the plain old coding, it’s going to be a ton of fun.  My #1 goal is to have the Django-based rewrite of DrProject solid enough to host Blake Winton’s iPhone game development project by 3:30 pm on Saturday; my #2 is to create a screencast by 5:00 that same day showing off what we’ve built so far.  Lots of other good things in the works too; stay tuned for news.

1231: Pizza just arrived, so while everyone’s grabbing a few slices, here’s a roster of attendees:

Basie (our code name for the rebuild of DrProject on Django): Greg Wilson, James Leung, Heather Grant, David Wolever, Jason Whyne, Phyllis Lee, Liz Blankenship, Bill Konrad, Blake Winton, Christian Muise, Botond Ballo, Veronica Quinones, Aran Donohue.

OLM (the Ruby on Rails version of the online marking tool): Karen Reid, Veronica Wong, Amanda Manarin, Mike Conley, Severin Gehwolf, Andrew Louis.

Miscellaneous: Mohammed Jalali, Rory Tulk, Andrew Trusty, Cameron Gorrie, and Vlad Sekulic (university sys admin) holding the whole thing together.

My stomach’s rumbling: more in a bit.

Uncategorized

Jordi Cabot and I submitted the rewrite of our survey of software project portals last Friday; the SE-CSE’09 paper summarizing the results of our survey of how scientists use computers is almost done, and I’ve got a few minutes to kill before two students arrive from the University of Alberta for our reading week code sprint, so here’s a quick list of some papers I’ve read so far this year that I’ve liked:

• DeLine, Czerwinski, Meyers, Venolia, Drucker, and Robertson: “Code Thumbnails: Using Spatial Memory to Navigate Source Code”. Proc. VL-HCC’06. Put thumbnails of code files in the scroll bar so that people can navigate to them “by shape”, then measure whether it works (it does).
• Plimmer, Grundy, Hosking, and Priest: “Inking in the IDE: Experiences with Pen-Based Design and Annotation”. Proc. VL-HCC’06. Use tablets to integrate hand-drawn design and annotation with three IDEs and see what people do. (Answer: cool things.)
• Bogart, Burnett, Cypher, and Scaffidi: “End-User Programming in the Wild: A Field Study of CoScripter Scripts”. Proc. VL-HCC’08. CoScripter is a very cool tool for recording and playing back web macros. This study looked at how people actually use it, and how they re-used other people’s work.
• Hearty, Fenton, Marquez, and Neil: “Predicting Project Velocity i nXP Using a Learning Dynamic Bayesian Network Model”. IEEE Trans. Software Engineering, 35(1), Jan/Feb’09. My first reaction was “double bandwagon” (neural nets and XP), but like all of Norman Fenton’s work, it’s meticulous and solidly grounded.
• Abraham and Erwig: “Mutation Operators for Spreadsheets”. IEEE Trans. Software Engineering, 35(1), Jan/Feb’09. Describes a coherent set of operators for mutating spreadsheets to do test-case generation.  Nice to see software engineering researchers taking the world’s most widely used declarative programming system seriously .

Research

I’ve used the term “CSCS” a few times now; time to start groping toward a definition.  “Computer supported collaborative science” (CSCS) is a specialization of computer supported collaborative work, which is the study of “how collaborative activities and their coordination can be supported by means of computer systems”. Insert the word “scientific”, and you have CSCS.  More specifically, CSCS includes science 2.0, open notebook science, reproducible research, workflow & provenance, and other things modern computing technology can do to help scientists find and share information.

Another way to look at CSCS is “areas where typical researchers in software engineering and/or HCI can directly help scientists”.  The word “typical” rules out HPC, numerical methods, very large databases, and a whole bunch of other “computational science 1.0″ topics, since most SE/HCI people don’t have the background for those. The stuff that falls under “e-science” or “grid science” (depending on which side of the Atlantic you’re on, and which grant agency you’re trying to seduce) might or might not be included, depending on which part you’re looking at—there’s certainly overlap.  The same goes for the semantic web, data visualization, and a bunch of other things.

Ironically, it’s not clear whether traditional software engineering research falls under the CSCS heading either, at least not if you define SE as the study of software construction—it takes a lot of SE skill to build the kinds of things CSCS is about, but I don’t see where CSCS requires the invention or study of new ways of building things.  On the other hand, if your definition of SE includes end-user programming or the study of how to do empirical studies of tools and techniques in action, then there’s definitely overlap with CSCS.

So that’s my opening shot: anyone want to volley it back?

Software Carpentry

Via Jon Pipitone: there’s a panel discussion tomorrow at Columbia titled “Open Science: Good For Research, Good For Researchers?” Jean-Claude Bradley, Barry Canton, and Bora Zivkovic are all going to be there, and yes, video will be distributed.  I’m looking forward to it—it’ll be a lot of thinking on computer supported collaborative science in one place.

Software Carpentry