Damian Conway, Perl hacker extraordinaire, will be speaking at the University of Toronto on Wednesday, July 16. The title of his talk is “Temporally Quaquaversal Virtual Nanomachine Programming in Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces… Made Easy”; the venue is Room 1160 of the Bahen Centre for Information Technology (40 St. George St.). Doors open at 5:00 pm, Damian should be there to start talking at 6:00, and yes, there will be a pub afterward.
Dmitri is still struggling with Google’s web toolkit—in particular, with trying to debug code that’s throwing an exception for unknown reasons. Maybe we could pass a new law—nobody’s allowed to release a library, framework, language, or other [name goes here] without including debugger support… *sigh*
Kosta has posted some more thoughts about integrating IRC into DrProject. He’s still working on mechanisms, but I’m looking ahead to the user interface. In particular, how should IRC logs be displayed? His first pass will be a “magic” wiki page that conversation entries are appended to (or possibly one separate “magic” page for each IRC conversation topic). That will work for short projects, but:
- What happens with something like DrProject itself, which could have tens of thousands of lines of conversation after a year has gone by? Even in undergrad course projects, there are likely to be thousands of lines in a term. Email is naturally segmented into chunks; what is the chunking (if any) for chat?
- What happens to the event log? We clearly don’t want one entry in the log for each IRC chat message—what should we show instead?
Nick Jamil and Jeff Balogh have posted a fairly detailed design for DrProject‘s new ticketing system. As far as I know, there isn’t another one like it: when a project is first created, its ticketing is just a to-do list, but users can add extra fields (like “owner”, “due date”, or what have you) to meet their needs. I think the initial low cost will make ticketing more attractive to undergrad students; I’ll be very interested to see what information teams (undergrad, professional, open source, or whoever) choose to add when they’re given complete freedom.
So when a team member says that a story is Done and moves the story card into the Done column, a customer could run into the room at that moment and say “Great Lets go live now”, and nobody in the team will say “no, but wait”.
Ironically, Kniberg’s post is called “Version Control for Multiple Agile Teams”. Why ironic? Because I was talking yesterday to a professor in my department — young guy, smart, already has a better research and publication record than I’ll ever have. I brought up version control (as in, “Why do less than 10% of faculty and grad students use it?”); his reply was, “Well, we’re just going to back everything up once a day.”
Dmitri has been wrestling with some plugin and servlet issues — suggestions would be very welcome.
Jon Udell has posted an interview he did with me last week at IT Conversations. The title is “High Performance Computing Considered Harmful”, and slides from a talk of the same name that I gave in Austin are available.
Later: here’s Jon’s summary of the interview. Curmudgeonly? Moi?
My greatest weakness as a programmer (other than impatience) is how little I know about relational databases. I know how it happened—I spent my twenties working in high-performance scientific computing, before very large scientific databases became common, and there was always somebody else to worry about that side of things for the projects I was on in my thirties—but it trips me up with ever-increasing frequency.
So, having told my students many times not to be ashamed of not knowing things, I figure I should set a good example and parade my own ignorance in public. The entries in this blog are stored in a PostgreSQL database as chunks of text. I’ve discovered that different entries represent characters in different ways: the long dash, for example, is usually a triple dash “—”, but is also sometimes represented as either a two-byte or three-byte sequence (depending, I presume, on what machine I was on the day I wrote the entry—I sometimes compose in a regular editor, then paste the entry into the blog). I’d like to clean up these inconsistencies, which means doing search/replace on approximately 1450 database entries. As I see it, my options are:
- Write a shell script that uses the command-line PostgreSQL client to pull entries in turn, run them through sed(1), and push the results back into the database.
- Write a Python script that connects to the database, pulls the entries, does string substitution, and pushes the results.
- Learn a little more SQL and do this with a query of some kind.
#3 is where I’m stuck. I know how to find the offending entries: “select entry from table where entry like chars”. I even think I know how to do string substitution. My question is, how do I push the results back into the table? I clearly want to replace each entry with the update of itself; is there a way to do this, or do I insert a new bunch of rows into the table, then delete the old rows? How? And why?