D520 – Week Four

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.

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 Two

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

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.

IronPython editor postscript

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.

Eclipse/PyDev

I was right to re-examine Eclipse.  The things that I remember bothering me so much five years ago (speed, the interface) seem to have been completely addressed, and it looks like a quite usable product.  When adding PyDev (which was quite simple), there’s support for IronPython that appears completely built-in (although it’s still obvious that Java is the #1 choice).  It seemed like a quite reasonable contender, unlike I tried to actually configure it to use the IronPython interpreter (which has to be done manually).  I was using a completely standard, fresh, installation of IronPython 2.0.1 (from the .msi) installed in the default location (here ‘C:\Programs\Iron Python 2.0.1’) with ‘Eclipse Classic 3.5’ and version 6u14 of the Java Runtime.

I believe that, in theory, you can click the automatic configuration button, or manually locate the IronPython interpreter, and it’ll just work.  Unfortunately, for me nothing seemed to work.  The error message indicated that having spaces on the Eclipse path could be a problem (which seems pretty shocking in 2009), so I tried moving Eclipse to C:\, which didn’t help.  I tried moving IronPython to C:\ (and renaming the folder to have no spaces), and that didn’t help.  I imagine that someone more familiar with Eclipse, or with PyDev with CPython/Jython, might have been able to solve this easily.  However, if I can’t figure it out in 10 minutes, then I am not at all comfortable with telling my first-year students to use it (even though we walk through the installation together, some of them will need to do that by themselves as well).

NetBeans

It wasn’t entirely clear which version of NetBeans to use, but I presumed that the most appropriate was NetBeans 6.7 “Python EA2”.  Although the post I saw indicated that you needed to rename ipy.exe and ipyw.exe, I found that just selecting ipy.exe worked fine.  I quite liked this IDE, and it appeared (although I didn’t use it for long) that using IronPython worked fine.   There’s no graphical form designer, so NetBeans is in the same category as Komodo Edit (which I discussed previously).  In many ways, it’s probably a better choice than Komodo Edit (in that the IronPython integration is simpler to do, although it does require that Java is installed), although I don’t know if there is any way to provide .NET auto-complete.  It’s a fairly full-featured IDE, like Komodo and unlike DIE, which would normally be a positive, but in this specific case (first-year programming students) is actually a negative, since they need to ignore all the ‘team’ functionality, and you have to work within projects (which is true of Visual Studio as well).  This is an “early access” version – since I’m not familiar with NetBeans I don’t know how unreliable that makes it – it makes me a little nervous about suggesting it to students, but I certainly didn’t have any trouble with it myself.

Conclusion

If you’re able to get Eclipse/PyDev installed, then I suspect it might slightly beat out my previous recommendations of Komodo Edit and DIE; since I didn’t get it working, I can’t recommend it to the students.  NetBeans, however, will get added to the list of suggested tools (alongside Komodo Edit and DIE).  If I wasn’t so familiar with Komodo Edit, I’d probably use NetBeans as the editor I use to demonstrate, but it didn’t wow me so much that it overcomes the familiarity.