Teaching on Tony Andrew Meyer

Displaying PDFs via the iPad

Tue, 24 Aug 2010 12:57:40 +1200

I used the iPad’s external screen output for the second time today (the first was trying out Chopper 2 with the TV as the screen and iPhone as controller) - this time not just as an experiment. I have a set of revision worksheets (all PDFs that I inherited many years ago - I might have Word documents somewhere, but I’m not sure where). Going over the questions in class, I can simply read the question out loud (but people don’t listen well enough and can’t ‘go back’ to it), or write it on the board (slow, handwriting code is problematic when you’ve got messy writing), but ideally it’s projected. The classroom does have a projector - in previous years I’ve hooked up my aging laptop and put the PDFs up to see. My hope was that I could use the iPad this year (since it’s meant to be replacing the laptop in most circumstances). The first problem is that I don’t have an application that shows PDFs that will use the external screen (e.g. iBooks ignores the external display). This is pretty annoying, and I hope it gets changed with an update in the near future. It’s not hard to imagine a business meeting where everyone has iPads and wanting to show a PDF that has been created (an advertisement, a manual, etc) to everyone at the meeting. Basically the only application I do have that will use the external display to show a document is Keynote. So the next step was creating a Keynote document with the same content as the PDFs. The next problem that arises is that I can’t copy the text from the PDFs on the iPad (not in iBooks, and not in Stanza, which is the only other PDF reader I have installed). I could see it perfectly well, but there was no way to extract the text. I hope this changes too. Just enabling select+copy in iBooks would be great. It’s not hard to imagine use cases here, either: select text, copy it, and tweet a quote from a document. (Ok, there are DRM issues with books, but just do something like leave out “select all” - even just enabling this for PDF would be ok). I resorted to using the laptop. I copied the PDF content to a PowerPoint (no Mac here to use OS X Keynote) document, and then (via Dropbox, since I don’t have a computer to sync with here) and opened it in (iOS) Keynote. The final steps, which did work, were very nice. I formatted the slides using Keynote (very simple, didn’t miss a mouse or keyboard at all), including inserting a few images via Safari. When the time came to use the slides, the projector accepted the iPad’s output without problems (although the position and location of the cable meant that the iPad was in an awkward location - buying the Keynote Remote application and using an iPhone/iPad Touch would have improved that). (For some reason, I couldn’t get the “laser pointer” functionality working at the time, although this has worked fine when I’ve tested before. I didn’t really need that). Overall, it’s a pretty good experience if you already have Keynote (or PowerPoint) material. It’s a pretty terrible experience if you have something else (e.g. code!) that you want to display. Thankfully, that can be addressed in software - even in third-party software.

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.

What happened to the 2009 IPy Notes?

Mon, 26 Jul 2010 16:51:13 +1200

Around this time last year, I started posting weekly reports on the IronPython classes I was teaching at Northtec, including copies of the material that I was giving the students. These stopped abruptly around the middle of the course. The course did complete (and was fairly successful - I think the change to IronPython was definitely for the better), and I did continue making notes as I taught. However, I didn’t manage to get them online. On the 10th of October 2009, my father passed away (very unexpectedly, of a heart attack the day before). As a result, I didn’t have as much extra time as I had anticipated, and I didn’t really have the energy/motivation to post the notes. (The classes continued, except the week of the funeral, where the hours were halved). The course began again last week (21st July 2010), and I’m going to try this again. As I go, I’ll complete the 2009 notes as well (some/all of the links in the 2009 ones are broken, which I’ll fix, and when I get to where the notes stopped, I’ll post the notes that I took last year, although these will be less exhaustive than if I had done them at the time). No promises, but I expect that I’ll be able to post throughout the entire course this year, and I’ll again make the material that I use available (you may use it under a Creative Commons license if you wish, although much of the material is references to IronPython in Action). I had planned to present a short summary of the experience of using IronPython in this way at PyCon NZ, but I’m again unable to make it this year (for happier reasons - a close friend is getting married that day); perhaps next year! I’m still interested in hearing from anyone else that’s using IronPython in the classroom.

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

IronPython editor postscript

Fri, 17 Jul 2009 16:43:26 +1200

I earlier tried various editors I was considering using to teach IronPython. One of the glaring omissions was Eclipse/PyDev, which has built-in support and is a very well-known IDE (particularly in the Java community). The main reason that I skipped Eclipse was that when I was searching for an IDE to use professionally about five years ago I tried Eclipse (for Python, C, and C++ development) and I really hated it - the IDE was very slow (especially to launch), it was very Java-centric, and just didn’t suit me at all. I’d briefly tried Eclipse before that as well, with similar results. Over the last few days, I decided that I was probably being unfair, and since this was a choice for my students rather than for me personally, I really ought to try Eclipse (with the PyDev extensions). I also noticed recently a post about using IronPython with NetBeans - I’d heard of NetBeans before, but only in a Java development context, and since I stay as far away from Java development as I can, I had no experience with NetBeans at all.

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

Useful / cute googling

Mon, 11 May 2009 17:44:53 +1200

Inspired by a Coding Horror post. Things that I would demo to an “Intro to IT” class if I teach one again.

I don’t think you can get directly to NZE listings (i.e. “NZE:AIR” doesn’t work like “GOOG”) - you have to go via google.com/finance. I don’t think UPC codes are used here, either. Looking up a VIN number would be great, but I’m guessing that doesn’t work, and can’t be bothered going and reading my VIN at the moment).