Northtec 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 Two – 2010

Mon, 09 Aug 2010 18:04:16 +1200

No radical changes from either last year’s week two or last week. In a way, this is the real first week - in the previous week we learn about the course and about what IronPython is (and remember how to program in Python), but we don’t do much more than that. In the second week, we really get into doing some actual IronPython programming. I gave the students [PDF], and the [PDF], and the recommended reading was two Joel Spolsky posts: one on (IT) customer service and one on how hardware improvements impact software design. The notes are again in three sections: textbook chapters (this week is Chapter Three, a fairly essential introduction to .NET and IronPython), key points, and example code (from Chapter Three). The lab is essentially the same as in previous years. We started out by quickly going over the . There isn’t really much time to spare for this (and it ended up being about 45 minutes anyway) - ideally the students already could manage these (except perhaps the last couple), but that isn’t really the case. It felt like they were getting more up to speed after going through these - I’ll need to be careful that this segment doesn’t end up being too long, otherwise we’re essentially dropping the lecture and putting the lab back in (just in the other order and a week late), and the students will end up waiting for me rather than attempting themselves. (Although this first non-assessed lab is a slightly different case). I simplified the textbook material again, ignoring .NET structures, enumerations, delegates, and so forth: the focus was really on events and Windows Forms. From there, I hope that we’ll build in to using other aspects of the .NET framework. (The GUI choice is again complicated this year - last year it was obviously Windows Forms, but unclear on the best way to design; this year Visual Studio is the best way to design, but the IronPython integration only offers a WPF graphical form designer, and I don’t really want to completely switch to WPF. For the non-graphical design that we do at first, we’re sticking with WinForms). I think this simplification helped fit the material into a single lecture (where it felt a bit rushed last year), although part of that is probably that I’m much more used to the 4-hour format now. I stuck to the new plan (other than going over lab 0 first) where we didn’t start work on lab 1 in class at all, and the second half of the class I worked through the Windows Forms examples. It felt like there was more time for this, too - I think I did more of the examples (i.e. did them more bit-by-bit) than last year. However, I don’t think anyone is confident enough with Windows Forms to actually create a GUI quiz application for the lab - although with a different group of students I suspect that might not be true. In general, the course seems to be progressing well (although it’s early stages yet) - like last year much smoother than when transitioning from Python to Visual Basic, and better than last year in that I’m more familiar with the 4-hour block, with IronPython, and with how parts of the course work.

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 Three

Sun, 09 Aug 2009 23:01:31 +1200

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 [PDF], the textbook chapter (4), and the [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 [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).

D520 Week One

Thu, 23 Jul 2009 18:00:55 +1200

As promised, here’s my material from the first week of “D520: Programming” (in IronPython). I gave the students [PDF] (and [zip]), [PDF], and [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:

Choosing an IronPython editor for teaching

Sun, 12 Jul 2009 11:25:28 +1200

The Northtec D520 “Programming” course is changing to IronPython (from Visual Basic) this year, so I have to figure out what editor/IDE the students should use. In some ways, Visual Studio would be ideal, since they need to get exposed to that during the course (and it’s an excellent IDE, with a really great form designer), but since there isn’t any real IronPython support in Visual Studio (hopefully coming in 2010), it’s not really a viable option. Instead, they’ll start with a simpler editor, and then briefly learn how to use Visual Studio’s form designer and subclass the forms in IronPython (as described in IronPython in Action). The requirements here are a bit different than when selecting an editor/IDE for actual development work. Firstly, it needs to be free (at least for educational use), and it needs to be reasonably simple to use the basic functionality (since these are first-year students). Code-completion isn’t necessary (on the one hand, it helps them out while they are learning - on the other, they rely a little too much on it), nor is a built-in debugger, or support for complex projects. I considered seven different editors/IDEs - there are a couple of others, but they either seemed too young (e.g. IronPython IDE, IronEditor), or inappropriate for other reasons (e.g. ZeusEdit is not free, I can’t stand Eclipse. UPDATE: I decided to try Eclipse and Netbeans after all).