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

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: