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.

We started out by quickly going over the model answers I prepared for the simple Python revision.  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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: