D520 on Tony Andrew Meyer

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.

More notes coming soon

Mon, 21 Sep 2009 12:40:52 +1200

I am still putting together the weekly D520 notes. However, the last couple of weeks have been a bit busy and so they’re waiting to be cleaned up and have links added. The intra-semester break starts next week so I’ll catch up then.

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 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 Two

Fri, 31 Jul 2009 11:01:39 +1200

Here’s my material from the second week of “D520: Programming” (in IronPython). The students got [PDF] and the first proper [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!:

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: