D520 Week Two

Here’s my material from the second week of “D520: Programming” (in IronPython).  The students got some brief notes [PDF] and the first proper lab exercise [PDF].  The recommended reading this week was a post by Lukas Mathis about poor hardware design (and lessons to be learnt), and a post by Wil Shipley about tracking down a Delicious Library bug.  The notes are again in four sections: textbook chapters (this week chapter 3, which is fairly essential reading), tools (same as last week, although I also recommended IronPython 2.6b2), key points, and example code (from chapter 3 of the textbook).  The lab exercise is a modification of one from last year (when it was in Visual Basic) – I’m trying to keep as many of the previous lab exercises as possible, so that there is still a tiny bit of continuity between 2008 and 2009.

Thoughts on how the class went (again, mostly for me when preparing the 2010 course) – as promised, much shorter than last week (less than half the words!:

• I simplified the textbook material somewhat when going over it.  The textbook talks about .NET structures, enumerations, delegates, and so forth.  It seemed like those would overwhelm the students in their second week, so I concentrated on outlining how things work, rather than the work that’s done underneath to support that.  We’ll probably come back to the proper definitions later, and the good students will come across them when they read the textbook (few – maybe none – of the students had read ahead, although part of that was difficulty getting hold of the text (the campus store sold out)).
• I wonder if the material from this week should be spread over two weeks – it seemed a little rushed (part of which is probably adjusting to having only 4 contact hours rather than 6).  The current schedule has chapter 4 spread over two weeks (next week and the week after) – perhaps chapters 3 and 4 could have 1.5 weeks each, or even both have 2 weeks each.
• Starting IronPython isn’t particularly quick.  On the tutor system (still using a VMWare Windows Server 2003 image running in VMWare Player on Ubuntu), it takes about 2 seconds to start up – slow, but not unbearably so.  However, on some of the students’ systems (same hardware for the server, same Ubuntu installation, same VMWare Player, different USB hard drive holding the same (in theory) Windows Server 2003 image) it would take much longer – often 30 seconds or more.  That makes debugging fairly unpleasant.  It seems that it must either be the Windows image (i.e. they’ve installed something else that is slowing everything down), or the USB drive that the image is on – mine has separate USB cables for power and data, so that probably helps.  I’m not sure how to work around this.
• I knew that the students had done some GUI work in the earlier D500 course, and that they used Tkinter (Tcl/Tk), since it’s installed by default with CPython, and that they wrote their code using Notepad++.  I assumed that meant that they were writing all the GUI code by hand – however, they actually did a couple of exercises by hand and then used Tk_happy to do all the GUI creation.  If they had been used to creating GUIs by hand with Tkinter, then creating a GUI by hand with Windows Forms should have been fairly straightforward.  However, since they were used to graphically creating the GUI, they struggled a bit more than I had hoped.  I might move the introduction to using Visual Studio to create forms (either subclassing VB/C# or using the ‘experimental hive’) up a little to compensate for this.
• The students had managed the simple Python exercises in the first week quite well.  Creating the quiz application didn’t go quite so smoothly (although they have until next week to submit, so I don’t know how well they have turned out).  They could all create a console quiz application, but they consisted of many print/raw_input/if statements, rather than using a data structure to hold the questions/answers and then looping through rather than repeating.  That meant that moving to a GUI was more complicated than it would have been if the console application was better designed.  I’ll probably go over how the console version could have been done better next week, depending on what the final versions handed in are like.
• Nearly all the students seemed willing to have a go, even those that clearly aren’t very good at programming (yet!).  This is a nice change from previous batches of students – although part of this will just be the particular students in this year, I hope that the change to continuing with a language that they are (essentially) familiar with has also played a part in this.
• Since we ran out of time covering tools in week 1 (because of the issues downloading and installing software), I talked about editors/IDEs this week.  Several students chose to try out Komodo Edit, so I hope that works out well.  I suspect in other years, some would choose to use Eclipse.
• Theoretically, the lab exercise should be submitted before next week’s class (at which time they get 1 mark for doing something, or 2 marks for making a reasonable attempt – the labs aren’t graded).  In practice, I don’t really care if they are a week or two late (especially as we move through the semester and assessment builds up), or even submitted right at the end of the semester.  Because of that, and also because there are so many ways to complete any of the labs (like any programming task), I don’t usually provide a “model answer” (I do discuss common problems in class, and help students individually).  However, I think that, at least for this first lab, I will need to do so.  I’ll build my own quiz application (or perhaps even a few versions, starting with the console one and building up) and make it available from next week.  If I do that, then I’ll post a link to the code here, too (probably in next week’s summary).