Archive for the ‘Venues’ Category
I meant to write this post yesterday, but we’re watching Torchwood: Children of Earth, and, well, you know how it goes. We spent two sessions looking at the basics of SQL and relational databases, which almost every scientist is going to encounter at some point in their career. The morning exercises were obviously too easy—students completed them in a little over and hour—but the afternoon seemed to go at the right pace. This morning we’re going to look at XML, and this afternoon at text processing with regular expressions.
This morning’s lecture was a high-level look at software testing, with a long-ish detour into exceptions; this afternoon was an introduction to Python’s unittest framework, with some handwaving about testing that functions throw the right kinds of exceptions, replacing files and other slow objects with mock equivalents, and how you decide what tests to write first. It felt like it went better than yesterday’s lectures on object-oriented programming, which I think left some students a little bewildered. We’re spending tomorrow looking at databases, which means I have to brush up on my SQL tonight…
We took a detour from the notes yesterday morning and built some classes to represent matrices. One reason was to show students how to break a problem down into pieces and solve them one by one; another was to introduce the notions of encapsulation, polymorphism, and inheritance. Aran Donohue (one of the TAs here in Toronto) thinks that inheritance is over-taught, and taught too early—he may be right, but it’s also hard to avoid, since so many libraries and frameworks (and tutorials, but that’s a circular argument) expect familiarity with it.
We looked at operator overloading and (very briefly) at design patterns in the afternoon, then did a modeling exercise. What classes would you create if you were writing a program to simulate solar systems? What would those classes’ responsibilities be, and which classes would collaborate with which others? The most creative solution included Santa Claus; the most complete took collisions and explosions into account.
We started Week 2 with a morning of theory: Francois Pitt, a senior lecturer in U of T’s Computer Science department, gave students a crash course in algorithmic complexity. It’s not something they’ll use every day (or even every week), but if they ever have a conversation with a computer scientist about making something go faster, the odds are good it’ll come up.
The afternoon’s material—the basics of classes and objects and Python—was more immediately practical. As always, I struggled with the fact that you have to know several things before any of them are useful: constructors don’t make sense until you know what objects are, but you can’t build objects without constructors (at least, not cleanly). The students spent the afternoon building simple classes to represent molecules; we’ll spend tomorrow building more classes, then move on to testing and QA on Wednesday.
Day 5 of the course: Paul Lu gave a lecture on Make in the morning, and students had a chance to work on problems of their choice in the afternoon. Of all the tools we teach in this course, Make is the least satisfying (at least to me): the basic concept is simple, and I wouldn’t run a project without some automating repetitive tasks, but Make’s syntax and limitations are repellant.
The problem is, the alternatives available today are equally unsatisfying. Ant requires human beings to write XML (the assembly code of the internet), and extending it requires serious skillz. Its creator, James Duncan Davidson, said back in 2004 that if he had it to do all over again, he’d have used a general-purpose scripting language as a base instead. Lots of build systems do, including CONS, SCons, and Rake, but they’re all still niche products with small user bases, weak IDE integration, and even weaker documentation.
Most tellingly, none of these tools has a native debugger that’s as useful as breakpoint-based debuggers for conventional programming languages. Rocky Bernstein’s “remake” for GNU Make comes closest, but figuring out why something didn’t get updated, or why hundreds of commands are executing when they’re not supposed to, is still hard. This course is now 12 years old, and for 11 of those 12 years, I’ve been wishing for something better to offer students so that they could see just how much work task automation could save them. I’m still wishing…
Tomorrow (Monday) is Day 6 of the course; Francois Pitt will talk about computational complexity in the morning, and we’ll start object-oriented programming in the afternoon. I’m enjoying it so far — hope the students are too.
Today was all about the Unix shell: Karen Reid covered a wide range of topics, often using live examples. Some of the students had never used a command-line prompt before, so all of the material was new; others already knew their way around pretty well, but Karen’s explanations filled in some gaps and made sense out of what had, for some of them, seemed like arbitrary magic.
Tomorrow morning, Paul Lu is going to introduce them to Make. We’re going to spend the afternoon working on the students’ own problems, which range from automating workflows to visualization with VTK to manipulating geographical data with GRASS. There may also be some ice cream…
Day 3 of the course—we did sets and dictionaries in the morning (glossing over the handwaving in the notes about computational complexity, since Francois Pitt is going to cover that properly later), and then Paul Gries showed students some basic image processing. Students found the morning exercise challenging, but seemed to be getting lots out of it. The visit to the pub this evening was still quite welcome, though. Tomorrow, Karen Reid is introducing them to the Unix shell; we’ll let you know how it goes.