As promised, here’s my material from the first week of “D520: Programming” (in IronPython). I gave the students a set of revision exercises [PDF] (and example answers [zip]), a course outline [PDF], and some brief notes [PDF]. The notes have four sections (this pattern will continue): which chapters of the textbook are covered this week (and a couple of sentences that summarise them or point out which parts are important to us), the tools that are required this week (since this is the first week, this section is large, covering installation of Adobe Reader, IronPython itself (including putting it on the PATH), and several IDEs (as previously covered), including configuration), key points, and example code (the examples that I plan to use in class). For anyone interested (chiefly: me in about nine months time, when I’m planning the 2010 course), here’s a summary of the first week. It’s rather long (2100+ words) – the summaries of future weeks should be shorter.The students seemed fine with the choice of textbook, and that there was one. I expected more grumbling about the price, but perhaps they just kept that to themselves. There did seem to be a moderate amount of interest in the ebook version over the print copy. The real test of the textbook starts next week, since none of the students were organised enough to buy the text before the first class, and so hadn’t seen it or read the first two chapters, which we covered. They are expected to have at least skimmed through Chapter 3 before next week’s class.
The first part of the lesson was the mandatory-but-dull course introduction (who I am, what the assessment is, what they’ll be learning, and so forth), which went as normal. The second part was a small lecture about IronPython and .NET (roughly covering the material from Chapter 1 of the textbook, but improvised at the time). I doubt much of this will be accessed (I haven’t finalised the examination paper yet) – if anything perhaps just low-mark questions like ”what is .NET”, “what is the Framework Class Library”, “explain what managed code is”, or “what is one advantage and one disadvantage of IronPython over CPython”. The first lesson of most modules is generally fairly light-weight – it helps those that miss the first class (more than you might think), and leaves room for addressing any problems that arise. I tried to emphasise the strengths of both .NET and IronPython, as well as reassure them that they would be using their existing skills, rather than starting from scratch (it’s possible I made too much of this: since they don’t know how difficult students in the previous two years found the Python->Visual Basic change, they may not have been expecting anything difficult). I imagine few students were interested in the history, but IMO it’s still worth including in the lecture. We then proceeded to tool installation and I did a few examples in the interactive console.
There were a few IronPython-specific hiccups:
- IronPython 2.0.2 was released the day before class. My master copies of the notes are Pages documents, and I didn’t have access to an OS X machine in order to replace “2.0.1″ with “2.0.2″. So the notes were already slightly out-of-date. This is an extremely minor issue, especially since I’m planning on mostly using 2.6.
- IronPython 2.6b2 was released the day after class. Although new releases are, of course, excellent, and it’s great to have a new version that fixes a lot of issues (including one that I reported that’s relevant if any of the students choose to use NetBeans), it’s annoying that it happened to be that day and not 24 hours (or more) earlier – this is one aspect of the open-source IronPython project that’s different than a more community-driven open-source project (e.g. I would have known if there was going to be a CPython release, simply by following the appropriate PEP and/or Python-Dev discussion). It’s not a large problem, and it just means that I’ll encourage the students to install 2.6b2 next week.
- I typo’ed the Windows Forms demo (we don’t actually start looking at Windows Forms until next week – it was just a demonstration). I’m more used to wxPython than Windows Forms, and so forgot that Application.Run() needs the main form passed to it. Unfortunately, “Application.Run()” doesn’t generate any sort of error, it just sits there, doing nothing until forceably killed. It took me a little while to realise my mistake (at first I thought that there was a problem with the installation).
- I had tried things out with both 2.0.1 and 2.6b1 when developing the course notes: I felt that using a beta release might not be a good idea, but really wanted to use 2.6 (since there are many significant improvements) rather than 2.0. This meant that there are a few things that I only tried in 2.0.1, and (since I picked 2.6 in the end) don’t work – at least not the same way – in 2.6. In particular, the built-in interpreter help() function (which basically just displays the docstring for an object) does not work in 2.6 (but does work in 2.0.2). This has something to do with the sys._getframes issue, but I’m still reasonably new to IronPython, and so I’m not really completely caught up on the history of this issue. The help() function does work in 2.6b2 if you start the interpreter with the -XFrames switch, but my very quick attempts at using the -X options in class failed, and I didn’t really have time to diagnose this properly until after class. I hope that somehow (perhaps -XFrames defaulting to True) this is resolved for 2.6 final, because I think it’s important to have help() just work. I’m not sure how to resolve this – I can get the students to alter the Start menu shortcut, but often they are starting IronPython from a command prompt. Perhaps creating a batch file and running ipy.bat rather than ip.exe would be the best solution.
The biggest problem wasn’t IronPython-specific: installing IronPython. In fact, it was so time-consuming and problematic that I skipped over installing additional/alternative IDEs and left them working in Notepad++ (I’ll try and fit in IDE installation next week, alongside IronPython 2.6b2).
History: last year, Northtec used a shared Ubuntu installation on each of the lab computers. Students would generally start one of various Windows virtual machines in VMWare (each machine would have software appropriate to particular courses), and then log in to a domain setup for the lab. Each student had a roaming profile that would be copied to/from that virtual machine as necessary. Although this was a good scheme in some ways (superior to the systems used in previous years), it still had faults. The two most noticeable were that (a) the Windows installation in the image was very locked down – this was to stop students breaking it or doing things that they shouldn’t, and (b) the students had a miserly profile quota (small enough that it would be completely filled by fewer than a dozen Visual Studio projects).
Today: the labs still have a shared Ubuntu installation. The students now each have their own separate Windows virtual machines (again VMWare), installed on portable hard drives. In theory, these VMs are open for the students to do whatever they like, and they obviously have as much space available as their drive provides. If anything went wrong with their image, they could just start from a fresh one. Two variations of image were provided, which had various software installed (one with a lot – including Visual Studio, one fairly minimal). The theory was (at least as I understood it) that the students would learn to install the tools that they required, as part of their training.
The problem: the images are actually really locked down in some ways (for the students’ protection, I suppose). It’s incredibly difficult to actually download anything in IE or Firefox (personally, I struggled through getting the Chome installer, and have since been fine). The campus proxy server doesn’t make this any easier, with its three-wrong-password-attempts-equals-lockout policy, especially since the Firefox installation in the image is inexplicably missing the “save password” option for the proxy settings. From what I understand, students generally download files in the Ubuntu host environment, and move them into the image – except that if they are running the image from a Windows host (e.g. at home), for some reason there’s no transferring files from host to client (perhaps a deliberate limitation of the free VMWare player?). In the end, about half the students managed to get the installer, and for the rest I copied it onto a USB drive and distributed it that way. There was one students for which even this didn’t work: for some reason he has a different image where he has no administrator rights, and so can’t install anything. I had to download and copy the zipped binaries version of IronPython (and the standard library Lib folder from the .msi install) for him.
This last point is perhaps the biggest: I had thought that the students would be using exactly the same image as I had. Prior to class, I’d carefully gone through (with a fresh image) installing everything necessary, documenting the steps required in their course notes. If they had the same image, then it should have worked exactly the same for them. However, they clearly didn’t have the same image – they had problems I didn’t, and didn’t have problems that I did (e.g. I have to ‘unblock’ any executable downloaded, but they do not; I had to install a PDF viewer, they didn’t). In addition to this, I discovered that in the first semester, only one of their (four) modules required an image, and that it already had all the software they required pre-installed. So rather than being used to downloading and installing software, this was new to them (at least in this context).
The second half of the class (the ‘lab’ portion) was all about Python revision – working in IronPython, but just writing standard Python. The aim was to refresh their memory from the previous course, and to surreptitiously get an idea of how good the students were at programming. I was quite pleasantly surprised (partly because I’d heard bad things about this batch of students – but perhaps the really bad ones didn’t make it this far). Most of the students seemed to manage the exercises without too much difficulty, and also (and this is by far the most important thing) seemed willing to try and figure out issues on their own (by looking at their CPython textbook/notes), although I did help out, of course. There were eight simple exercises, and most students completed the first seven (the eighth was a bit longer and trickier). One of the key intended benefits of changing from Visual Basic (.NET) to IronPython is that the students don’t have to start fresh, and can more directly build on the skills and knowledge from the previous course. It seems (although it’s certainly not clear yet, and won’t be until the course has done a few years) that this is working.
Even more astonishingly, I had (at least) one student that read the recommended reading! Each week, I provide links to two articles as “recommended reading” – this is not accessed in any way, and is completely optional. I don’t even bring them up in class (other than pointing out what they are), unless a student brings them up first. These are made up of articles that I’ve found over the last few years – from my RSS reader, del.icio.us bookmarks, and so forth. I try to include articles that are reasonably relevant to what the students are learning in this module (design, testing, development) or the degree as a whole (applied IT in business, entrepreneurship), are ideally fairly short, well written, are ideally somewhat humorous, informative, and are often by well-known authors. I have little expectation that any of the students will read these, but it doesn’t take too much effort to include them (since I’m reading these myself, so just need to tag them, then later select, and organise them), and hope that they would be of interest to particularly good students (and that they’d hopefully learn something from them). I’ve only done this for this first-year course for a couple of years, and I’m not sure whether I’ve had any students actually read them before now, so this is very pleasing. (For reference, this week’s reading was “That Design is Money” about designing a better UI for ATMs, and “Five whys” (by Joel Spolsky) an amusing tale of a sysadmin disaster, how it was handled, and what lessons were learned).
The class seemed to go quickly, but I expected that, since it’s changed from a 6-hour week (08:00-12:00, 13:00-15:00) to a 4-hour week (08:00-12:00), with the students expected to do more on their own (I remain sceptical about how much will be done). The time was all filled up – if the IronPython installation had proceeded more smoothly, I think it still would have been, because I would have been able to include IDE installation and demonstration as well.