D520 – Week Four

This week continued from the previous one, covering Chapter 4 of IronPython in Action.  That meant no new notes, and no new lab exercise.  We basically did two things: worked through the MultiDoc example in Chapter 4, and worked on implementing the Airline lab designed in the previous week.

The first recommended reading for the week was Part 1 of Joel Spolsky’s “Talk at Yale”, wherein he tries to relate his study to his career – the part I hoped they would find interesting was the discussion of “geeks” versus “suits”.  The second recommended article was Steve Yegge’s “Code’s Worst Enemy”, which is mostly about code bloat.  In retrospect, these might not be the best pairing, since Yegge is always long, and this particular Spolsky article is very long (if you read all three parts).  However, I was again pleasantly surprised to hear that students were actually reading these.

I was right to set aside a whole ‘lecture’ section of a week for introducing MultiDoc – I used all two hours (with breaks and a late start, actually about 90 minutes) going over the code, and didn’t quite manage to finish – I got up to the very last section, but didn’t have time to go through adding the menubar/menu items (so I did that in the break and showed the working example afterwards).

• I typed out all the code in class from the (paper) textbook.  I could have copied-and-pasted the code from the (ebook) textbook, or used the source available from the textbook’s site.  I did tell the students that they could do this, but I noticed that many of them typed along with me (I didn’t wait for them to keep up, but I did position windows so that they could type while I demo’d).  I think this generally worked well and helps the students understand more than just reading the code.
• I found the concept of separating pages of text into tabs somewhat strange, but one of the students compared it to separating out worksheets in a spreadsheet, which makes it more palatable in a way.  Perhaps – considering the authors’ day jobs – this was even the inspiration!
• I ran the code to show them the results at roughly the same places the book shows screenshots.
• I did the SaveFileDialog example in the interactive interpreter as the textbook does, but skipped the file IO example and the MessageBox example (I briefly talked about the former and we had looked at the latter for Lab 2).
• I talked about MVC as we created each of the parts, although I had mostly covered this the previous week.
• I only lightly touched on using command patterns.  We’ll be adding new commands for a few weeks, so I felt there would be time for that later, and the advantages would be more obvious once there were more than two commands (which is really just one command, since ‘Save As’ is just a special case of ‘Save’).
• The students had used standard dialogs in D500 using Tk, so weren’t as impressed by what SaveFileDialog provided as I thought they might be (perhaps I should task them with creating one!).  In fact, some felt that it took a lot more lines of code to use the dialog – but when I pointed out that most of the code was setting the dialog up nicely (filters, initial location), they saw that it was comparable.
• In the context of reading/writing files, I again mentioned the issue of having two ‘standard’ libraries (the part of IronPython I dislike the most), as the textbook does.  I’ll stick with doing things the .NET way in general (because the students are meant to be getting familiar with .NET), although since I’m personally more familiar with Python, that might not always be the case.  I added comments to the code showing the Python library equivalents.
• I brushed over exceptions.  I’m not sure how familiar they are with the concept from their introductory course, and I didn’t have time to do the topic justice.  We’ll go back to them in a later week – for now I just added the code.
• I brushed over lambdas as well, which I’m certain that they wouldn’t have seen before.  I included them in the code, but I wonder if I should have written named functions instead.  I’m not sure that they need to know about anonymous functions for the course, but I would like to keep the example as close to the textbook as possible.  I think I’ll insert a mini topic on lambda into a later week, and just put the equivalent function in comments for now.
• I added a reasonable amount of comments to my code (partly as I was going, and partly while the students took their breaks).  My version (of how MultiDoc.py appears at the end of Chapter 4) is available if you’re interested in the commented version.  (The original version is available under the BSD license, with the copyright owned by Michael Foord.  I believe I’m allowed to make this available under the same terms, but I couldn’t find a copy of the license.  If Michael objects, I’ll pull this down).

This part of the lesson went very well.  The MultiDoc example is straightforward, and the students have the opportunity to examine both my code and the code as it appears in the textbook (without even having to type it in).  They can also read through the outline in the textbook (ideally they did that before class, but that’s not likely to have been the case for most), so they have both my explanation and the author’s to help them understand what is happening.  We actually covered quite a lot (MVC, command patterns, tabs, common dialogs, toolbars, and menus) even though it was just a single example.

I’m looking forward to continuing with MultiDoc over the next few weeks.  I won’t always been able to dedicate this much of the lesson to it, so I will have to copy-and-paste code at some points.  Where possible, though, I’d like to continue working through building up the application part-by-part, just as they would.

The second part of the lesson was slightly reduced in time (because I ran over a little with MultiDoc).  The task, which I didn’t create an outline for, was simply to implement the Airline application described in the previous week’s exercise.  The students had the option of using their own design, or the example one that I provided [PDF]. My example is ugly (we cover UI design later!) but I tried to keep it as simple as possible (e.g. everything is in a single form), and I based it on the model answer from the Visual Basic exercise that this exercise was based on.  I provided a UI [.py] as well as a design outline – I built the UI in Visual Studio because I was in a rush and didn’t expect that the students would look at the GUI code, so it’s not elegant (e.g. I would replace a great deal of the code with a few loops).  I also provided a shell [.py] that showed them how to subclass from the GUI.

I was surprised that several students opted to use their own design (I got the impression that they had started working on it before class, which was when they got access to the example design).  Most students seemed able to jump in and start implementing things, although there were a few stuck in the “where do I start” mode that I’ve seen before.  I’m curious to see what gets submitted so I can get an idea of how well they can do this sort of coding.