Ironpython in Action on Tony Andrew Meyer

D520 Week Three - 2010

Mon, 09 Aug 2010 18:26:49 +1200

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 [PDF], and a [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.

D520 - Week Six

Mon, 07 Sep 2009 21:31:20 +1200

Chapter 6 of IronPython in Action covers “properties, dialogs, and Visual Studio”. This seemed an obvious place to insert the material on user-interface design that is normally covered in the course, and to look a bit more deeply than the textbook does at Visual Studio itself (and the Windows Forms controls and their properties). I only scheduled a single week to cover this, but I suspected that it might take more than one (I left an empty slot in the schedule to cover one such over-run), and that was, indeed, the case. The students received notes [PDF], slightly longer this week (covering the UI design material not in the textbook, as well as the usual chapter summary, key points, and examples, and the steps required to install IronPython support in the ‘Experimental Hive’ Visual Studio SDK), and a fairly simple lab exercise [PDF]. The recommended reading for this week (which I didn’t get a chance to mention, but is listed in the course material) is a very light-hearted comparison of different programming languages (somewhat old, so the students probably don’t actually know many of these, but I like the underlying truths - I guess I should have tried to add languages like Ruby, PHP and Javascript myself) and a Wil Shipley article about the fast/good/cheap trade-off. I really enjoy Shipley’s style of writing, but even if I didn’t, I’d include this article: the point about there being many dimensions (brevity, features, speed, time, robustness, flexibility, …) and that you can’t have them all is really important for starting developers to understand. However, even more than that, I really agree with Shipley’s contention that you should always start with brevity. The first half of the class is straight from previous offerings of the course (although a little condensed), and is basically just a 90 minute talk about user-interface design, aimed at non-designers. As previously, I use the points from Tog’s First Principles of Design as the outline, although I talk about more than just what’s in the article (and only skim over some parts of it). The course isn’t really about UI/UX design, but it is an important element, and I try to emphasise it in some way each week (and many of the recommended reading articles are about some sort of UI/UX design). For the two projects, the students will have to complete not just a development design document, but also a UI design, including an explanation of why they made the decisions they did. Historically, this is notoriously badly done for the first project, with most students (despite my emphasis when outlining the project, and giving them a marking schedule) submitting nothing more than a screenshot of a Visual Studio mock-up. For the first project, all I really need to see is that they’ve considered something, rather than just thrown things together - by the end of the course, I expect that they should be able to put something together that is a reasonable UI. There has historically been an examination question on this topic as well - something along the lines of “outline three important considerations in user-interface design”. The biggest issue was in installation - again! I carefully tested running through the installation on a clean copy of the Windows image they have. It was slow (so I recommended doing it before coming to class, and planned to kick it off at the start and only start using it a couple of hours later, after the UI talk), but worked fine. I forgot, however, about the Northtec proxy server that blocks so much Internet functionality. There were basically three steps required to get the “Experimental Hive” version of Visual Studio running with IronPython (1, unfortunately) support: install Visual Studio 2008 SP1, install Visual Studio 2008 SDK, compile the IronPython sample. The Visual Studio SP1 installer is one of the “stub” installers that are popular in some circles - i.e. it’s a very small installer that then downloads whatever is necessary to complete the installation. While there are some merits in this approach, it doesn’t work well in all situations: this was one of those. It seems that the service pack installer only support proxies that provide auto-discovery, which the Northtec proxy does not. That left two alternatives: force the students to download and install the service pack (many hundreds of MB) outside of the lab, or use the .iso version of the SP. I downloaded the .iso (830 MB!), and that installed without problem in the lab. However, I don’t really have a convenient way to distribute files of that size among the class (generally the files I provide are quite small) - if I had realised this in advance I could have had it added to the file server, but that wasn’t really feasible in the time available. I had to fall back to copying the files on to a USB drive (1GB, so max’ing it out) and distributing them via sneakernet. Figuring out all of this (around the actual teaching) took most of the class, so when I left I had only got this far (i.e. halfway through step 1 of 3). The SP installation should be trouble-free (but will probably take 30-60 minutes), so the students should have that done by next class. We’ll continue with the SDK installation (~120 MB standard installer) and IronPython compilation at that point. Next year, I’ll make sure that SP1 is installed on the image, side-stepping this whole problem (I hadn’t got to testing software installation when the images were created this year, because I knew that I wanted the students to do installation themselves). Of course, I could be really lucky, and Visual Studio 2010 might include built-in IronPython support. We were able to use Visual Studio in the method described in IronPython in Action, however (creating class libraries in Visual Studio and subclassing in IronPython). I think the students found this less appealing that I do - moving the generated .dll around was problematic for some of the students, for example. I suspect that even though using IronPython directly in Visual Studio is problematic (e.g. stuck with IronPython 1) many students will elect to do that. To me, properties seem a bit like decorators and lambdas, in that they are slightly advanced Python, and perhaps a bit ahead of where the students generally are in D520. However, we certainly covered properties in Visual Basic, and the fundamentals are the same, really. The MultiDoc example was very useful here, in that it uses properties to implement observers, so there was a practical use for properties, rather than the toy examples that are often used in explaining why you’d want to hide your attributes behind getters and setters. I think that the students understood the general idea. As part of this, I briefly covered the observer pattern, as outlined in the textbook - perhaps it’s just the work that I’ve done, but I come across observers all the time, so I tried to get across the importance of this idea. My plan at this stage is to find somewhere in the schedule where I can insert an “Advanced Python Refresher”, where the students can take another look at decorators, properties, lambdas, and anything else that comes up along these lines. I doubt many (maybe any) students will use these techniques in their projects, but I do expect that they’ll feature in the final examination - and will probably be a good indicator of the good programmers (those that really understand programming and might end up doing it professionally) versus the good students (those that put in enough effort to get through, but are really suited for other IT jobs - sysadmin, testing, managing, etc). Chapter 6 has nicely thorough coverage of the very versatile MessageBox, but it’s not really overly complicated to use, if you have a list of the icon and button options available (as in the book, or on MSDN). Since we’ve seen MessageBox a few times already, I skipped over this material, focusing instead on the custom dialogs. The chapter also has a section on serialising in .NET - the students are already familiar with the pickle module, so this is really just a .NET version of something they already know. I originally intended to cover this next week, but if time is short again, I might just skip it completely (since they can easily use pickle instead). We ran out of time before I could really go over the MultiDoc code from Chapter 6, so I left that for the next week. The lab exercise was just redesigning the Airline application used in earlier labs. There were two aims here - firstly to get the students to try out the various controls that are available (it’s easier to explore in Visual Studio, even if you end up using the controls in hand-written code). Secondly, the students must design their projects, including the UI, and submit that design. This doesn’t just mean ‘sketch the UI’ - it means consider and explain the reasons behind the UI decisions - hopefully the lab started students on the road to doing this properly in the project.

D520 - Week Five

Mon, 24 Aug 2009 17:57:44 +1200

Chapter 5 of IronPython in Action deals with XML, although it starts out covering some of the more advanced things you can do with functions. I considered skipping this chapter (the function material is perhaps a bit advanced, and covering XML isn’t a necessity), but decided that it was worth learning about XML in .NET (since it’s so common) and that it would make using the MultiDoc example tricky (since the file format is XML) and I really wanted to use MultiDoc. I gave the students notes [PDF], again covering the textbook material that we could look at, the tools (unchanged), key points, and a link to the MultiDoc example code. We had a new lab exercise [PDF] this week (implementing Conway’s Game of Life), as well as two new recommended reading articles: a Lukas Mathis post about preferences and another Spolsky post, this one about “architecture astronauts”. Students again read the recommended reading (again, before class!). There was some debate about the Mathis article about preferences. The points I hoped they took away were the difference between configuration and preferences and that preferences don’t suit ‘casual’ users. I think some students were unconvinced, but I hope that I managed to get across the point that they are (by definition, as students in this course) more than casual users, and so not the sort of user that preferences don’t suit. (However, even though I’m far from a casual user, I too generally dislike preferences - one reason I use a lot of Apple products). I got the feeling that the material on functions was a little advanced, as I suspected. This was, however, the ideal place for me to cover lambdas, as I proposed doing last week, so I added that in. I talked about functions defined in other functions, passing functions as arguments, anonymous functions (lambdas), and decorators. These are important things to learn if you’re going to be a Python developer (or a developer in other languages that let you treat functions in this way), but perhaps belong in a more advanced class. Next year I might skip over this (i.e. assign it as recommended reading), and just rewrite any of the textbook examples to use regular functions. On the other hand, it’s great exam question material! Last week, I stepped through the MultiDoc code, typing it in as I went. I felt there wasn’t sufficient time for that this week, so instead opened up the source that Michael provides and talked through it. I don’t feel this was as successful as the previous week, so I’ll go back to typing as much as I can. I didn’t have time to comment the code as I went, but did so after class (for the version of MultiDoc as it stands at the end of the chapter). The commented version is available under the same license as the original. I completely skipped going over xmldocumentreader.py since it’s fairly generic and well covered in the textbook, and concentrated on documentreader.py and documentwriter.py instead. Implementing Conway’s Game of Life wasn’t an exercise that was in the course in previous years (although it would be essentially the same task to do it in Visual Basic), although I have used it some time ago in other courses (and I think I had to do it myself back in my undergraduate years). It seemed like an exercise that would concentrate on Python programming in general, and just happen to use some .NET classes. Two of the classes that they would need (Timer and PictureBox) I expect they’ll want to use in their projects later on. I particularly like to cover Timer (whether it’s Visual Basic or IronPython) because the students at this point are still working in a procedural fashion, rather than an event-driven one. That means that their natural instinct when needing to do something like update the grid every X seconds is to have a loop with a time.sleep() call in it. They then end up with an unresponsive GUI, because they are blocking the main thread. A timer isn’t the only way to deal with this, but it’s a good default choice, and covering it explicitly saves me explaining it to many students individually when they come across it (e.g. in project work). However, most of the class found that they didn’t know where to start (and were either so stuck that they really had no idea, or just didn’t feel like taking a crack on this particular day). So I ended up working through the exercise with them (rather like I ended up doing the Quiz the week after that exercise). I don’t mind doing this occasionally, but the students really need to start on their own eventually. I could perhaps provide a detailed design next year, that clearly showed what functions you would use and how they would be tied together. I wrote three versions of Life in the end (all extremely similar). I wrote my first one simply to check how difficult it would be for the students, intending it to be an example answer. The second was a small modification of the first, which added a bit more colour to make the display more interesting. The third was the one I wrote during class - it’s considerably simpler (i.e. not as nice code) than the other version.

D520 - Week Four

Sat, 15 Aug 2009 16:54:19 +1200

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).