Archive for the ‘Work’ Category

More notes coming soon

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

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]. Continue reading

Mailbox flattening messages

The mailbox.py code does this to dump a message (e.g. when adding to a Maildir file):

def _dump_message(self, message, target, mangle_from_=False):
    # Most files are opened in binary mode to allow predictable seeking.
    # To get native line endings on disk, the user-friendly \n line endings
    # used in strings and by email.Message are translated here.
    """Dump message contents to target file."""
    if isinstance(message, email.Message.Message):
        buffer = StringIO.StringIO()
        gen = email.Generator.Generator(buffer, mangle_from_, 0)
        gen.flatten(message)
        buffer.seek(0)
        target.write(buffer.read().replace('\n', os.linesep))
    elif isinstance(message, str):
        if mangle_from_:
            message = message.replace('\nFrom ', '\n>From ')
        message = message.replace('\n', os.linesep)
        target.write(message)

(There’s a bit more that deals with other types of message).  Unfortunately, with some messages containing Unicode characters, this breaks with a UnicodeDecodeError:

Traceback (most recent call last):
  File "", line 1, in
  File "/usr/lib/python2.5/mailbox.py", line 245, in add
    self._dump_message(message, tmp_file)
  File "/usr/lib/python2.5/mailbox.py", line 203, in _dump_message
    buffer.seek(0)
  File "/usr/lib/python2.5/StringIO.py", line 106, in seek
    self.buf += ''.join(self.buflist)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd6 in position 106: ordinal not in range(128)

The message does flatten with message.as_string() – or str(message) – without any problems.  I’m not really sure why mailbox.py doesn’t just use as_string(), rather than create a generator itself.  I’m also not totally sure where the error is coming from, especially since it happens inside of seek().

For now, I can just call mailbox.add() with msg.as_string(), rather than with msg directly, and it’ll work fine.  At some point, if I have time, I’ll revisit this and try and figure out if it’s a Python bug that should be reported.

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

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. Continue reading

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. Continue reading

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. Continue reading

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. Continue reading

IronPython Course Notes – The Plan

Since I decided to use IronPython as the programming language for teaching D520 at Northtec, I’ve planned on putting my course material online so that anyone else planning on using IronPython in teaching can make whatever use of it they can.  There won’t be a huge amount of material, especially in this first year, and especially since I managed to find an excellent textbook to use, but there will be some exercises, assignments, an exam, and so forth.  Each year I teach a course I add new material, and while some material is replaced or removed, usually the old material stays, so the amount of material gradually increases.

What I haven’t been able to decide is how to put this material online (the students have access to it via a Moodle installation, but I don’t want to make that publicly available).  I toyed with the idea of putting it up in wiki format (but that seemed like a reasonable amount of work and I doubt there will be contributions from other people), with using iWeb to create a small dedicated site (mostly to play around with iWeb, which I have never really used, but that seemed like a lot of unnecessary work), or with putting it on Google Docs and sharing it that way (but I write the material in Pages and publish as PDF, so that doesn’t suit well, since I’d have to convert to Word then to Google Docs).

What I’ve finally decided is that I’ll just put it up here.  It’s already setup, I’m a bit busy to put much else up at the moment so it won’t be crowded, and it’s very simple for me to do.  I’ve further decided that it would be best to publish it bit-by-bit (since no-one else needs it at the moment anyway – if I’m wrong about that, please contact me).  Each week, after the class has finished, I’ll post all the material I used that week, and some commentary about how well it went.  I think this commentary will provide added value (including for me, when I’m revising the material next year), and it means that it’s easier for me to update the material as I go (although I’ve prepared the whole course, I expect that there will be changes since it’s so different than last year’s course).

I expect that as I continue to use IronPython in a teaching context, I might have additional comments that I feel like posting, so those will be nicely interspersed with the teaching material.

I’ll put everything in the “Teaching” and “Python” categories, so it’ll be easy to ignore everything else here if anyone is interested in using this material.  I’m making it available under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 New Zealand License (I include using it in a similar course as non-commercial).

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.