D520 Week Three – 2010

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

D520 Week Two – 2010

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 notes [PDF], and the first assessed lab exercise [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.

D520 – Week Five

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

D520 – Week Three

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.

D520 Week One

As promised, here’s my material from the first week of “D520: Programming” (in IronPython).  I gave the students a set of revision exercises [PDF] (and example answers [zip]), a course outline [PDF], and some brief notes [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.

Choosing an IronPython editor for teaching

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