The Third Bit

This one resonates. (via Titus Brown)

Uncategorized

Good article by Jon Udell on “Overcoming data friction“.  One of the projects in my course this term is trying to do something like this by gluing together data from various social services’ web sites — screen-scraping and after-the-fact duct tape turns out to be easier than getting various branches of the same government to agree to exchange data, or make it available to the public that’s paying for it.  Students interested in startups, take note: any information that’s hard for you to get or correlate is a market opportunity.

Teaching

One day in September 1197 the effective ruler of Outremer, Henry of Champagne, was reviewing his troops from a window of his palace at Acre when a delegation from the local Pisan colony entered the room behind him.  He turned to greet them, and a few moments later thoughtlessly stepped backward. His little dwarf, Scarlet, seized his clothes in an attempt to stop him, but it was too late. Together, the two crashed to the ground below. Scarlet escaped with a broken leg; Henry was killed.

— John Julius Norwich, A History of Venice

Uncategorized

The US National Academy of Engineering‘s site is running a feature on “grand challenges in engineering”. You get to vote for which you think is most important: better medicines, securing cyberspace, preventing nuclear terror, and eleven others.  Carbon sequestration is there; so is economical solar power and producing energy from fusion.  “Reducing emissions” is not listed—apparently, the idea of cutting back is still too politically sensitive. *sigh*

Uncategorized

For a long time, I have believed that Jon Udell has the best job in the world. He gets to build interesting systems and talk to interesting people about interesting futuristic things, and best of all, he gets paid for it.

A couple of years ago, though, I discovered Brian Hayes‘ column in American Scientist magazine. His job looks like a lot of fun too: every couple of months, he has to explore some interesting and revealing idea that is somehow related to mathematics and computing. Some of his past columns have now been collected in Group Theory in the Bedroom, and they are as entertaining as they were the first time around. The opening article talks about the most elaborate mechanical clock ever made; others look at the problem of determining where the continental divide actually is, different ways DNA could have coded for proteins (but didn’t), the statistical distribution of violent events, and what, if anything, “equality” actually means. Fans of Martin Gardner’s long-running Scientific American column are particularly likely to enjoy Hayes’ tone, insight, and playful curiosity.

Demaine and O’Rourke’s Geometric Folding Algorithms is the raw material that popularizers like Hayes mine to create their essays. During the past decade there has been an explosion of interest in several closely-related problems: how to fold shapes up in two or more dimensions, and how to cut folded material so that it has a certain shape when unfolded. Applications range from drug design and robotics to forming metal sheets; the algorithms range from straightforward (though never trivial) to mind-bending.

This book does an excellent job of surveying the state of the art. There are copious examples and illustrations, and the authors manage throughout to convey the excitement of working in an area where many basic questions are still unanswered. Pick a page at random, and there’s a fair chance you’ll find a conjecture that is still awaiting proof. It is not for the mathematically challenged, but I expect graduate and undergraduate students will be finding research projects in it for years to come.

Cawood and Fiala’s Augmented Reality: A Practical Guide is aimed at less advanced readers, but offers just as many avenues for the curious to explore. (Disclaimer: Pragmatic Bookshelf published my last programming book, and will be publishing my next one as well.) “Augmented reality” is the practice of overlaying a virtual world on top of the real one, i.e., of synthesizing video data in real time to make imaginary objects appear to exist in the real world. Today’s systems rely on contraptions that combine video goggles with a camera; the goggles put a small screen in front of each eye, while data is injected into the signal from the camera to create tanks, flying fish, or whatever else the programmer wants.

Most of the book is taken up with very detailed descriptions of the code required to glue the real and virtual worlds together. At the end, the authors pull everything together by creating a virtual tabletop tank game. Basic computer graphics concepts are introduced as needed, as is a little bit of AI (for navigating mazes). I don’t think all the code examples were necessary—anyone capable of understanding the book could browse the source for themselves in most places—but this would still be a good starting point for an exciting undergraduate course.

Fourth on my winter reading list was Armstrong’s Programming Erlang, also from Pragmatic. The subtitle, Software for a Concurrent World, explains why so many people are suddenly interested in functional languages like Erlang: there’s a feeling that traditional imperative languages simply can’t cope with a world of multicore processors and web services. I’m still waiting for evidence that it’s easier to build such systems with functional languages, but even if it’s not, programming in Erlang and its siblings is like stepping into a parallel universe.

Armstrong’s book is a workmanlike introduction to Erlang in particular and parallel functional programming in general. Its author one of the language’s creators, and that occasionally shows through in discussion that is more nit-picky than newcomers probably need. The wealth of examples more than makes up for that, though, and everything is solidly grounded in real-world needs. Many of the underlying ideas can be used in other languages, even if not as gracefully, and should be in every programmer’s mental toolbox.

Last but not least are Thatcher et al’s Web Accessibility and Sydik’s Design Accessible Web Sites. Their common theme is making the web usable by people with disabilities, particularly visual handicaps. A quick audit of the web sites I’ve built in the past three years was pretty humbling; as the number of elderly web users grows, and as regulatory agencies start to enforce equal access rules, closing the gap between what is and what should be is going to become more and more important.

Of these two books, I preferred Sydik’s, primarily because it was shorter (less than half the size of Web Accessibility). On the other hand, the latter covers topics in more depth, and assumes its readers are somewhat more advanced. Both have plenty of pointers to tools and primary references; either would be a solid basis for several undergraduate lectures or an intensive two-day course in industry.

---

Joe Armstrong: Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf, 2007, 978-1934356005, 536 pages.

Stephen Cawood and Mark Fiala: Augmented Reality: A Practical Guide. Pragmatic Bookshelf, 2008, 978-1934356036, 328 pages.

Erik D. Demaine and Joseph O’Rourke: Geometric Folding Algorithms: Linkages, Origami, Polyhedra. Cambridge University Press, 2007, 978-0521857574, 496 pages.

Brian Hayes: Group Theory in the Bedroom, and Other Mathematical Diversions. Hill and Wang, 2008, 978-0809052196, 288 pages.

Jeremy Sydik: Design Accessible Web Sites. Pragmatic Bookshelf, 2007, 978-1934356029, 328 pages.

Jim Thatcher, Richard Rutter, Christian Heilmann, Andrew Kirkpatrick, and Cynthia Waddell: Web Accessibility: Web Standards and Regulatory Compliance. Friends of ED, 2006, 978-1590596388, 696 pages.

Books

An excellent discussion of the forces that shape real-world applications.  Why can’t I write this well?

Uncategorized

Yesterday was Family Day, a new Ontario holiday.  It was also the start of Reading Week (no classes at U of T), but David, Yi Qing, Luke, and Qiyu were in anyway, beavering away to get DrProject ready for PyCon while I wrote reports.  (I miss coding…)  16 new tickets created; 19 completed (but 3 reopened); 29 changesets checked in; five sub sandwiches eaten (along with three large chocolate milk, one regular milk, and an orange juice for the old guy).  We’re starting up again in an hour and a half; there’s a ton to be done, but it’s looking better all the time.

DrProject

David Ascher has announced the launch of Mozilla Messaging, a new Mozilla Foundation subsidiary that wants to reinvent email and internet communication.  It’s an increasingly crowded space, but if anyone can pull it together, the Moz folks can.

Uncategorized

The project course I’m teaching this term has forty-six students in it, who are working on twenty-five projects. Some are going very well, but some teams are still trying to get the code their clients have given them to compile or run. The main reason seems to be time management: this is just one course among five for most students, and unlike their others, it doesn’t have regular assignments or deadlines every few weeks.  That makes it very easy for students to push it aside because something else has to be done by [tomorrow, Friday, next week].

Now, I know from experience that if I set deadlines every couple of weeks, students will find a way to meet them, just as they do in their other courses.  However, I also know that doing that robs students of a chance to learn how to manage their time.  That, writing, and budgeting are the holy trinity of consulting: everything else can be fudged, but if you can’t keep yourself focused on the things that actually matter, explain what you’re doing, and manage your money, you’ll never make it on your own.

So, what could I do to help them?  I have given them the sermon about “don’t put this off until the end of term unless you really want a C-”, and they all understand it intellectually, but it’s clear that a substantial minority still don’t get it in their gut.  Regular progress reports don’t help, since students regard them (rightly, I think) as yet another distraction from the projects themselves.  If anyone has any silver bullets, please pass ‘em along…

Teaching

I realized this morning that I hadn’t told the blogosphere what my graduate students have decided to work on.  (I hope the fact that I realized this while cleaning crusty soap scum off a dishwasher says more about me than it does about my graduate students’ choices…)  In brief:

• Jeremy Handcock is studying ways to visualize the history and state of software projects.  His plan now is to use something like Prefuse Flare to give project members an easy way to configure a wide variety of visualizations (of a wide variety of data), then examine what they choose to view and why.  This is similar to what we’re hoping to do with the new ticketing system Jeff Balogh is building for DrProject, which will let each project configure whatever fields they want in tickets—once enough people have done so, we hope to reverse engineer their actual workflows from what they’ve decided is worth putting into tickets.
• Samira Abdi is going to use information retrieval and text clustering techniques to “thread” the events in projects’ histories.  Right now, for example, the history of a SourceForge or DrProject project is a flat stream of events: a change set, another change set, a ticket update, an email message, another ticket update, and so on.  When we view discussions in a bulletin board or mail reader, though, most of us groups the individual items into discrete conversations.  By looking at common keywords and cross-references, Samira hopes to be able to do the same to project histories.
• Carolyn MacLeod wants to figure out why the overwhelming majority of software developers don’t use formal modeling tools like Alloy, Statemate, Spin, and so on.  The obvious hypotheses are “they aren’t actually very useful” and “their learning curves are too steep” (i.e., someone who is just starting to use them sees all the cost, but none of the benefits), but there are others related to mismatches in problem framing.

None of these are actually on my research wishlist, which probably means I’m too much of a soft touch to be a good prof. But the students seem keen (as keen as anyone can be in Ontario in February), and I think they’ll all be able to invent or discover something interesting by the end of the year.  Stay tuned…

Research