Last year Chapter Four of IronPython in Action was covered over two weeks (the lab is also a two-part exercise), and I felt that worked fairly well, so kept the same plan for this year, although the exact parts that were covered each week changed. As usual, the students received notes [PDF], and a lab exercise [PDF], and two recommended reading items, both by Brent Simmons: one on how improving quality is non-linear, and one on how your own code is always improving. The notes again cover the textbook, key points, and example code (although most of the example code is MultiDoc, so just links to the online copy.
This year, I left duck typing for the second week, preferring to spend more time on the IronPython introduction (and sacrificing some time for going over Lab 1). We did cover design patterns, specifically MVC (command patterns we’ll also do in the second half), and we managed to get the MultiDoc example complete (as it is at the end of the chapter) except for the magic methods (which we’ll add once we have covered duck typing, so we know what they do; this does mean that the program doesn’t actually run at this point). As always, this lecture was also used to hammer home the importance of doing some sort of planning before starting any large project.
Like last year, the students struggled with the first Lab (the quiz exercise); I did expect this, and it was confirmed before the class started. I felt that going over the exercise in class worked reasonably well last year, so I did that again this year – this took longer than I hoped (over an hour), although this will be quick next week (because it’s only a design, no IronPython code), so the effect on the combined eight-hour session isn’t too bad. Although I made available the three versions (naive, console, GUI) from last year, I again started from scratch, to demonstrate how they can progress from not really having any idea about what to do to a more finished exercise. The versions from this year are slightly different as a result (particularly the console version, which I made a lot simpler this year), but they follow the same pattern. Although this was expensive in terms of time, it again felt very worthwhile, and I hope the students are more confident when they begin coding for Lab 3 (next week). Having a week’s break when they don’t need to write any new code is another benefit of splitting this material over two weeks (since they’ll be in week four by that time, and ought to be able to do something, even if it is simple).
This week’s lab exercise did change from last year, although not significantly. For a long time, the exercise was to design an airline booking application – originally based on an example program, and then to code it based on the design the second week. Writing the design based on an existing application never seemed right (defeating the point of the “design first” meme!), and the application was quite buggy (and I never got around to fixing everything, since it wasn’t my code); that part was removed from the lab in 2009. In 2010 I dropped the airline booking part altogether – it never worked particularly well, because actual booking is much more complex and the students tried to include things that weren’t necessary. The actual task (design this week, code next) remained the same, but they now have to design a Memory card game – this should be quite simple, and prepares them for the first project. (It’s also something that they can test by playing a game). Following the new system, they didn’t get any time to work on this in class.
TonyAndrewMeyer 