- Dan Servos has the first visuals from his grade stats plugin for Moodle.
- After a week of hard work, Qi Yang has plugged into Eclipse.
- Eva Wong has discovered that structuring projects from scratch is hard, but now has a handle on the data she’s going to visualize.
- Joseph Yeung is making steady progress on the OpenAFS administration tool.
- Matthew Basset thinks that writing 69 tests in a day is “slow”. He’ll learn…
- Nick Jamil is wrestling with ticket queries. Two weeks and change to go…
We’ve hit another “what should it do?” question in DrProject, and I’d welcome opinions from readers. As I’ve mentioned previously, the new ticketing system for DrProject is going to be extensible. Each project’s tickets will initially contain just four fields: sequence number, date created, creator ID, and one line of text. The first three will be filled in automatically; the user will only have to type the fourth. From experience, a simple “to do list” like this is all student teams really want or need.
However, almost everyone wants to add “just one more field” to this design. Sometimes it’s a person responsible; other times it’s priority, due date, a larger text area for a detailed description of the problem, or attachments. The new ticketing system will therefore allow the developers in a project to change the ticket schema for that project using a drag-and-drop form editor.
(Not that it matters right now, but we’re not just building this to support teams’ chosen workflows. It will also give us a way to find out what those workflows actually are—if we deploy DrProject, wait a few months, then look at what people have chosen to record, it should give us some insight into how they’re thinking about their work.)
Now here’s the problem. DrProject currently offers two “personal” views called “All Projects” and “All Tickets”. The first shows a merge of the event logs from all the projects the user belongs to; the second shows all the tickets assigned to the user from across all the same projects. The question is, what should we show for “All Tickets” if every project’s ticketing schema can be different? To make this more concrete, imagine that project Telepathy’s schema has grown to:
(id INTEGER, created DATE, creator USER_ID, title TEXT, duedate DATE, priority ENUM(“hi”, “med”, “low”))
while project Antigravity’s schema has grown to:
(id INTEGER, created DATE, creator USER_ID, title TEXT, priority(“urgent”, “optional”), owner USER_ID)
Options we can see are:
- Only show the common fields. (Unlike user-added fields, the four basic fields can never be deleted from a project’s ticket schema, so we know they’ll always be there.)
- Show the union of all the columns. This is awkward for all the obvious reasons: it’ll be very wide, many tickets will have blanks in many columns, enumerations with the same name but different values will be a pain, etc.
- Have one table for each project, but put all the tables on the same HTML page. A basic version is easy to implement, but sorting and filtering would be difficult.
Anyone have strong preferences? Can anyone see anything better? The ticket for this problem is #1506, and as I said, input would be welcome.
…but this talk on Eucalyptus by Rich Wolski is pretty damn good…
The one-year anniversary edition of the Toronto Girl Geeks Dinner is tomorrow night (Wednesday, June 25) — see their site for details. It’s a great event for networking (or so I’m told); I’ll try to do a better job next time about getting the word out…
…can be solved by adding another level of indirection, or so the saying goes. We’re already seeing browsers serving that purpose by running applications like spreadsheets and word processors that used to sit directly on top of the operating system; the announcement about Project Coverage is yet another example of virtualization being used to simplify solutions by adding a level of indirection to the OS itself.
My most recent grant proposal was shot down in its first review. Yes, I know, the competition for NSERC funding is increasingly fierce, but dammit, this would have helped a lot of scientists do a lot of good research, and I’m willing to bet that the ones that are finally accepted are less innovative. *grump*
- Kosta Zabashta has posted a screenshot of a new interface for navigating IRC logs in DrProject. It displays a sidebar of the project’s event log; clicking on an event takes you to the portion of the IRC log closest in time to the chosen event. Feedback is, as always, welcome.
- Meanwhile, Qiyu Zhu is working through the design of a new role editor, and believes that dumb redirects interact poorly with forms. Suggestions, anyone?
- Joseph Yeung’s MMC plugin for OpenAFS is loading! (Damn those memory boundaries anyway…)
- Daniel Servos is loading data. It’s not as easy as you might think…
- Victoria Mui has fewer squares than she used to have.
- Eran Henig discovers that deviant builds of Python for odd debugging tasks are still easier than getting Web-CAT to compile.
AudiOdyssey (via DDJ) is “…an experimental computer game designed to be accessible to both the visually impaired community and mainstream gamers. The user stars as Vinyl Scorcher, an up-and-coming DJ, on his quest to get club patrons dancing. Swinging the Nintendo Wii controller to the beat, Vinyl lays down the various component tracks of a song, and keeps the party jumping. If he [sic] does an especially good job, he [sic] can even freestyle! But beware—if dancers get too rowdy, they’re likely to bump into the turntables, messing up Vinyl’s tracks.”
It is (just barely) worth wading through Zed Shaw’s self-important vulgarity to see how he finds out what has been done to Ruby to fix some vulnerabilities.