D520 – Week Three

When planning the semester’s schedule for D520, I choose a few topics that seemed large and gave them a two-week time-slot.  One of these was chapter 4 of IronPython in Action, which covers duck typing, design patterns, and introduces the MultiDoc example that’s used throughout the middle section of the book.  One of the concepts that the course has always (at least, as long as I have known it) tried to push is the importance of design – not just user-interface design (although that’s both important and covered), but the importance of doing at least some planning before starting to write large amounts of code.  In the last couple of years, I’ve moved the course away from focusing on extensive formal design to also cover design patterns and testing (particularly automated testing, like unit tests).  Since this is such a major issue for the course, and since I planned on using MultiDoc as an example in class (I try to always have an example that continues on from week to week), this seemed like an obvious point for a two-week session.

As such, the notes [PDF], the textbook chapter (4), and the lab [PDF] (somewhat) are shared over week three and week four.  The notes follow the standard layout, although there’s an extra section that condenses some of the material from previous years about emphasising design; the tools remain the same as the previous week.  The lab is outlined in more detail below.  The recommended (but completely optional) reading was a 2005 Gamasutra post about rapid game design (many of the students are often into gaming, so I like to include this article) and one that attempts to explain why ease-of-use is often neglected by Scott Berkun (from 2002! Oldies but goodies this week).

I’d noticed in the previous week that the students weren’t doing a particularly elegant job of completing the “Quiz” lab exercise, which was causing difficulties in converting the console version to a GUI version (apart from the expected difficulties of building a GUI with Windows Forms for the first time).  While their programs did the task, there was a great deal of repetition – basically a print statement, a raw_input and an if, repeated for each question in the quiz (i.e. no loop, no data structure).  I decided that rather than just provide an example application, I’d walk through the lab myself, showing the students how I would progress from the console version through to a GUI.

I deliberately did this without any preparation (although I have done a Visual Basic version of this application in previous years, and I did do a partial GUI version in class in week two), so that the students would see how I had to go back and change things (emphasising the importance of design), and how mistakes were a natural part of developing (although thankfully I didn’t make too many – it’s always a little tricky writing code when you need to restrict yourself to writing something that a beginner can easily understand).  I started with a console version that was basically the same as the ones I saw being created, then altered it so that it stored the data in a dictionary and looped through it.  We then worked through changing that application into a Windows Forms application.  The resulting program isn’t great (and the UI is very ugly), but it demonstrated the progression that I wanted to show.  I made each version of the program available to the students [zip].

I talked for a while about duck typing – I did this ‘freehand’ rather than via the material in the textbook, so that the students would have multiple perspectives to use to absorb this.  I’m not sure how well they understood the importance – it’s a fundamental aspect of Python programming, but they haven’t yet come across anything significant enough that typing is important, so it’s a little abstract.  I think that since they started in Python, rather than a strictly typed language like C or Java, that they don’t understand quite how lucky they are (when they get to doing templates in C++, they’ll wish they had duck typing there!).  Hopefully it did sink in a little, especially for the better students, and they’ll see the importance as we work through more advanced programs.  It’s also an obvious exam question! (Any of the students smart enough to have found this via Google will have figured that out already, I expect).

For the section on design, I mostly talked ‘freehand’ as well, condensing material that I’ve covered in a few classes in the previous couple of years.  I talked a little about the MVC style that the textbook introduces, but also talked a lot more about the high-level, overall, importance of design, how students tend to work, how real-life projects often work, and tried to convey the important of some sort of planning.  I left introducing MultiDoc for the next week (that will be the main focus of the first half of the lesson).  That meant that we didn’t use the textbook extensively this week – not because it was lacking in any way, but rather because it’s a large topic and I wanted to use it more in the second part.  I hope that (at least some of) the students will read the chapter in the days between week three and week four (to follow through with what we covered in week three) and so will be more prepared for week four.  (I’m quite looking forward to starting the MultiDoc example next week).

The lab exercise is based on an exercise that has been in the course for a long time (I think it was perhaps from a textbook that was once used).  In the past, the students have been given a working (although very buggy) application used to do simple seat booking for an airline.  Their task has been to write a formal design document for the application, using the way that the application worked as the basis.  In the following week, the students would then implement the application themselves, based on their designs.  I’ve never loved this exercise – partly because the example application was so buggy (although I fixed it up somewhat), and partly because it’s doing things backwards (design after implementation), which is exactly what I’m telling them not to do.  I did like the concept itself (no coding – just design) and the example (airline booking) was good enough.

I threw away the ‘example application’ part of the exercise, and simply gave the students a description of what the application was meant to do.  It was then up to them to figure out how it should work (including an idea of what the interface would be, although I emphasised that wasn’t the focus of the task).  Next week I’ll give them an example design, and they can implement the application, either based on their own design, or on my example one.  I’ll probably build a GUI for them as well, so that they can concentrate more on improving their coding skills than figuring out how to make Windows Forms look nice.

The students accepted this much more readily than in the past (there’s usually grumbling about the lack of coding).  I’m not sure what that signifies, and I haven’t seen any submissions yet, so I’m not sure how well they did.  It did seem like the designs (as in the past) were very shallow, failing to consider many aspects (data structures, starting up, shutting down, and so forth).  In that, the results seem quite similar to previous years, which is pleasing (since I’m trying to keep as much continuity as possible, given the huge change from Visual Basic to IronPython).