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.

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.

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.

Fewer people than normal (is there a “normal” after only three?) asked what to get Samuel for his birthday this year – perhaps they all asked Olyvia and she didn’t mention it, or perhaps people know him better, or perhaps it’s just easier to buy for a three-year-old.  My stock response (which I tried, fairly successfully, to get Olyvia to use as well) was as follows (this didn’t apply to parents or grandparents):

Sam has so many toys that he just doesn’t have time to play with everything.  He has toys in his toy box that he hasn’t even played with yet.  He really doesn’t need any more at the moment.  He also has heaps of books and clothes.  If you want to buy him a present, then you are, of course, welcome to do so.  In that case, our suggestions are:

* Make him something.  He’s a bit of a fussy eater these days, unfortunately, so food might not be a good choice.  If you can think of something else to make, then that would fine.
* Something to do.  e.g. an IOU for a trip with you to somewhere. This could be as simple as a picnic at a park somewhere – he loves being outside.
* A donation to a charity and a card (he likes opening mail) saying what you did.  He’s not going to understand it now, but when he’s older, he’ll hopefully think that was really cool, and right now he already has so much stuff.

My hope was really for the latter – we actually do quite a few things already, so there isn’t a pressing need for the middle choice.  Making him something is great, but it seemed unlikely to appeal to many givers.  We did actually try this once before – suggesting a donation to a charity (Starship, I think) as a Christening present.  If I recall correctly, we didn’t get a single bite that time.

Samuel’s party was yesterday, and he had something like 50 people attend (perhaps 25 groups, e.g. families).  I know there are a few more presents coming, but the bulk will have been dealt with so far.  It wasn’t a total win, but we did have two or three people that chose to do a donation, which really pleases me (and I hope will please Samuel when he’s old enough to understand).  We also have a lot of stuff that I’m (of course) really grateful that people bought for Sam, but will hardly (if at all) get played with and will end up just getting donated somewhere.  On the “something to do” side, he did get supplies for baking (which he loves) and gardening (which he might get interested in) – not exactly what I had in mind, but good gift choices in my mind.  There were home-made cards and wrapping paper, but I don’t recall any home-made gifts.  He also got three gifts of cash – Olyvia and I had planned to top up his savings to reach the next milestone, so we did that after adding the other gifts and made an equivalent donation for him.

I wish I knew why people are so reluctant to choose the charity option.  The comment I hear most often (via Olyvia) is something disparaging about me and how I’m a killjoy, or don’t want Samuel to have fun.  This is ludicrous – half of the problem is that Olyvia and I (along with others, like his grandparents) spoil him so much that he already has so many things.  I also know what he likes – at the moment he likes opening cards just as much as presents, and he doesn’t like getting overwhelmed (which opening the flood of presents at his party was, although he managed well).  It’s also my (and Olyvia’s) job to consider his future happiness – I’d love it if he grew up happy and having the things that he wanted, but also without a need to have more things all the time.  This is a step along that road.

The other frequent comment is something along the lines of how Samuel would want to open a present and see something.  That’s true – but he enjoys opening cards just as much as a gift – so a card that went along with a donation (or something to do, or something homemade) would be just as much fun for him as another toy.  Olyvia noted something that I think is probably quite true – it’s also often that the giver wants to see a reaction from Samuel when he opens the present, and they think that a toy will provoke a better reaction than a card.  Although I understand this, I think it’s more important to consider what’s best for the receiver than for the giver.

Unfortunately, this is probably the last time that we’ll be able to try this experiment for some time.  Christmas is a much smaller event, where this isn’t as big an issue.  For Sam’s 4th birthday, he probably will be old enough that he will care what’s in the box, and not react as positively if it’s homemade/an activity/a donation.  My aim is for the party next year to be vastly scaled down, too (probably cutting out many of the parents, and also people that are really friends of mine/Olyvia’s, rather than Samuel’s), and this isn’t much of an issue with half-a-dozen gifts.

On a tangentially-related note: we did manage to get through his party without gift-bags or organised party games, which I’m quite pleased about.  (I’m sure games will be featured next year, by which time Sam will probably really enjoy them).

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.

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

• I typed out all the code in class from the (paper) textbook.  I could have copied-and-pasted the code from the (ebook) textbook, or used the source available from the textbook’s site.  I did tell the students that they could do this, but I noticed that many of them typed along with me (I didn’t wait for them to keep up, but I did position windows so that they could type while I demo’d).  I think this generally worked well and helps the students understand more than just reading the code.
• I found the concept of separating pages of text into tabs somewhat strange, but one of the students compared it to separating out worksheets in a spreadsheet, which makes it more palatable in a way.  Perhaps – considering the authors’ day jobs – this was even the inspiration!
• I ran the code to show them the results at roughly the same places the book shows screenshots.
• I did the SaveFileDialog example in the interactive interpreter as the textbook does, but skipped the file IO example and the MessageBox example (I briefly talked about the former and we had looked at the latter for Lab 2).
• I talked about MVC as we created each of the parts, although I had mostly covered this the previous week.
• I only lightly touched on using command patterns.  We’ll be adding new commands for a few weeks, so I felt there would be time for that later, and the advantages would be more obvious once there were more than two commands (which is really just one command, since ‘Save As’ is just a special case of ‘Save’).
• The students had used standard dialogs in D500 using Tk, so weren’t as impressed by what SaveFileDialog provided as I thought they might be (perhaps I should task them with creating one!).  In fact, some felt that it took a lot more lines of code to use the dialog – but when I pointed out that most of the code was setting the dialog up nicely (filters, initial location), they saw that it was comparable.
• In the context of reading/writing files, I again mentioned the issue of having two ’standard’ libraries (the part of IronPython I dislike the most), as the textbook does.  I’ll stick with doing things the .NET way in general (because the students are meant to be getting familiar with .NET), although since I’m personally more familiar with Python, that might not always be the case.  I added comments to the code showing the Python library equivalents.
• I brushed over exceptions.  I’m not sure how familiar they are with the concept from their introductory course, and I didn’t have time to do the topic justice.  We’ll go back to them in a later week – for now I just added the code.
• I brushed over lambdas as well, which I’m certain that they wouldn’t have seen before.  I included them in the code, but I wonder if I should have written named functions instead.  I’m not sure that they need to know about anonymous functions for the course, but I would like to keep the example as close to the textbook as possible.  I think I’ll insert a mini topic on lambda into a later week, and just put the equivalent function in comments for now.
• I added a reasonable amount of comments to my code (partly as I was going, and partly while the students took their breaks).  My version (of how MultiDoc.py appears at the end of Chapter 4) is available if you’re interested in the commented version.  (The original version is available under the BSD license, with the copyright owned by Michael Foord.  I believe I’m allowed to make this available under the same terms, but I couldn’t find a copy of the license.  If Michael objects, I’ll pull this down).

This part of the lesson went very well.  The MultiDoc example is straightforward, and the students have the opportunity to examine both my code and the code as it appears in the textbook (without even having to type it in).  They can also read through the outline in the textbook (ideally they did that before class, but that’s not likely to have been the case for most), so they have both my explanation and the author’s to help them understand what is happening.  We actually covered quite a lot (MVC, command patterns, tabs, common dialogs, toolbars, and menus) even though it was just a single example.

I’m looking forward to continuing with MultiDoc over the next few weeks.  I won’t always been able to dedicate this much of the lesson to it, so I will have to copy-and-paste code at some points.  Where possible, though, I’d like to continue working through building up the application part-by-part, just as they would.

The second part of the lesson was slightly reduced in time (because I ran over a little with MultiDoc).  The task, which I didn’t create an outline for, was simply to implement the Airline application described in the previous week’s exercise.  The students had the option of using their own design, or the example one that I provided [PDF]. My example is ugly (we cover UI design later!) but I tried to keep it as simple as possible (e.g. everything is in a single form), and I based it on the model answer from the Visual Basic exercise that this exercise was based on.  I provided a UI [.py] as well as a design outline – I built the UI in Visual Studio because I was in a rush and didn’t expect that the students would look at the GUI code, so it’s not elegant (e.g. I would replace a great deal of the code with a few loops).  I also provided a shell [.py] that showed them how to subclass from the GUI.

I was surprised that several students opted to use their own design (I got the impression that they had started working on it before class, which was when they got access to the example design).  Most students seemed able to jump in and start implementing things, although there were a few stuck in the “where do I start” mode that I’ve seen before.  I’m curious to see what gets submitted so I can get an idea of how well they can do this sort of coding.

As you can tell (unless you’re reading this via RSS), I’ve changed the theme for the site again.  I quite liked the layout of the old theme, but the text was just too hard to read, especially with large posts (which I am prone to).  Let me know if there are any issues – since this is hosted WordPress, it should be fine, of course.

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 notes [PDF], the textbook chapter (4), and the lab [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 each version of the program available to the students [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).

I really enjoy listening to Jason Calacanis when he’s on TWiT, and I think he generally makes a lot of sense (and considering his success, he clearly knows more than me).  However, his anti-Apple rant (like so many others) is really off-base (I’m not the only one that thinks so).

There is no technical reason why the iTunes ecosystem shouldn’t allow the ability to sync with any MP3 player

The iTunes ecosystem does allow the ability to sync with any MP3 player (even more so now that music is DRM-free).  You can build an application that uses the XML library description that iTunes creates to figure out where all the music/video is, and do what you like with it.  The way I see it, there’s no reason that iTunes/Apple should be forced to support any MP3 player with their software.  Apple clearly makes some money from the iTunes music/video sales, but it’s clearly not the main profit generator is the ecosystem – the high-margin iPods/iPhones are.  Apple has spent a great deal of time and money building a store and an application to make the players more appealing.  Why should any other player get to piggyback on the top of that?  If (e.g.) Palm wants to create an online music store and develop an application that works with it and the Pre, then they should be able to (and I see no reason they can’t).

I like iTunes more than other media applications I’ve used, but it’s certainly not perfect, and it shows that it started out as a music player and is now a great deal more.  I love the iTunes Store, but Amazon completes with it (I can’t tell how well, since they won’t see to me in NZ) as does the Zune Store – which even offers a subscription model (no idea if this is available in NZ – it’s too Windows-centric for me).  There’s absolutely room for someone (e.g. Palm) to build a better store (or interface with an existing one like Amazon) and built a better application.  Do that, and build a better device, and you’ll get customers.  Don’t expect that Apple should have to help you compete against them.

Think for a moment about what your reaction would be if Microsoft made the Zune the only MP3 player compatible with Windows.

The iPod/iPhone isn’t the only MP3 player compatible with OS X.  However, isn’t the Zune is the only MP3 player compatible with the Zune store?  The “PlaysForSure” idea got thrown out some time ago.

Simple solution and opportunity: Not only let the iPhone work on any carrier,

How many countries is the iPhone locked in?  It certainly isn’t locked here, or in many other countries (e.g. Australia).  This is only an issue in some countries, like the U.S. – it’s a U.S. Apple problem, not an Apple problem.  From what I understand, it makes business sense for Apple to have an exclusivity deal with AT&T, at least for now.  I don’t see anything wrong with that.  If AT&T was bad enough, then people wouldn’t use it, even if it was the only iPhone choice.  If other companies made phones good enough on other carriers, then it wouldn’t matter which network the iPhone was with.  I presume this is a temporary issue and the U.S. will join the other enlightened countries before long and have unlocked phones, anyway.

but put *two* SIM card slots on the iPhone

A nice idea in some ways, but about as un-Apple as you can get.

3. Draconian App Store policies that are, frankly, insulting

This is actually points 3, 4 and 5.

Yes, every application on the phone has to approved by Apple, and if you were interested in something adult in nature…well…you can’t do that.

From all accounts, the approval process needs a lot of work.  One suspects that now that Jobs is officially returned to work (and Schiller is speaking openly about at least some things) that changes will happen before too long.  I think Apple must surely realise that the situation is getting out of control, and will start implementing changes.  For now, there are still a lot of applications that I really love, there are none that I know of (which is an issue, of course) that I wish I had, and only one that has been pulled that I love (which is Amazon’s fault, not Apple’s).  I’m willing to give Apple a bit more time to fix this – I suspect that even they didn’t realise quite how successful this would be.

4. Being a horrible hypocrite by banning other browsers on the iPhone

Again, this is really just a specific case of #3.  Personally, I see almost no demand for Opera anywhere apart from by a few (very extreme) fans.  I don’t even see much desire for Firefox or Chrome on the iPhone.

5. Blocking the Google Voice Application on the iPhone

There’s a lot of talk about this.  It seems overblown to me, considering that Google Voice isn’t even publicly available (I believe it’s an invite-only beta) and is U.S.-only.  I think it’s just that a lot of the noisy tech pundits use Google Voice, and so this impacts them directly.  I think there are much worse cases of App Store approval problems.  In any case, this is again just another instance of #3.

Making great products does not absolve you from technology’s cardinal rule: Don’t be evil.

It seems to me that the cardinal rule is more “make great stuff”.  I’ll still buy from Amazon, even after they killed my favourite iPhone application.  I dislike some of how Apple handles App Store submission, but I’ll still buy various products from them.  I dislike DRM in general, but the iTunes Store is good enough that it’s still worth using.

1. Do you think Apple would be more, or less, successful if they adopted a more open strategy (i.e. allowing other MP3 players in iTunes)?

Less.  A huge part of the appeal of the Apple ‘ecosystem’ is that because they control all parts, everything “just works”.  If you use all-Apple products, everything works so much nicer than if you mix-and-match.

2. Do you think Apple should face serious antitrust action?

No.

3. Do you think Apple’s dexterity and competence forgive their bad behavior?

Yes.

A few days ago, Apple released version 3.0.1 of the iPhone OS, which addressed a pretty major SMS vulnerability.  When Olyvia tried updating her 3GS to 3.0.1, something went wrong.  The iPhone entered “Recovery Mode”, which means that it displays an image indicating that you need to connect it to iTunes, and you can’t do anything else (no phone calls, no iPod, no applications – absolutely nothing).  Connecting the phone to iTunes prompted a message indicating that the phone needed to be recovered – doing so downloaded the 3.0.1 update, and then got stuck on the “Verifying Restore with Apple” step for a long time, until it would finally fail with error “3104″.  This process could then be repeated, with the same results.

What this meant in practice was that the phone was bricked as of last Friday.  An update should never be able to brick a (legitimate, not jailbroken) phone! Even more, failing to verify a restore with Apple should never leave the phone in a broken state.

I tried many thing to resolve this:

• Restoring on three different computers (three OS X Leopard, one Windows XP).
• Using three USB cables.
• Using two Internet connections (different router, different physical location, different ISPs).
• Restoring with five different user accounts, including one that was created solely for this purpose.
• Removing iTunes and the Mobile Device helper completely and reinstalling.
• Restoring with an administrator account (both OS X and Windows XP) and a standard account.
• Redoing the restore at many different times of day, including times when most of the US would be asleep (so the server load should be fairly low), over Friday, Saturday, Sunday, and Monday.

None of this worked.  It did mean that I downloaded the 300MB+ update six times (one for each user account and once to refresh) over the four days.  That combined with the iTunes installation brings the total download cost to around 2GB.

I eventually gave up.  Google found many other people with this problem, but only a single solution, which involved opening a terminal connection to the phone and changing an environment variable.  I wasn’t particularly comfortable doing that, since if something goes wrong I want Vodafone/Apple to just replace the phone without any argument.  Since there isn’t any real support available over the weekend, I waited for Monday morning.

I wasn’t sure whether to contact Apple (expecting a “please call Vodafone” answer) or Vodafone (expecting a “what do you mean you updated your phone?  Can you do that?” answer).  Thankfully, Vodafone NZ has a very responsive and helpful Twitter presence (@vodafoneNZ).  I tweeted, asking who to call, and was asked for details.  I provided these (going into more detail in an email), and got back a (unfortunately not helpful at all) suggestion.  Since that didn’t work, Paul Brislen provided me with an 0800 number for the “iPhone Team” (I’d call them “iTeam”, subtitled “there’s an ‘i’ in iTeam”, but anyway…).  Unfortunately, since I had to do a lot of travelling and offline things on Monday, I wasn’t able to get to this until Tuesday.

I certainly appreciate a (free) phone number I can call.  However, I don’t have a great deal of time to spend talking on the phone, explaining a rather complex problem and the many steps that I’ve already done to try and resolve the problem.  I also have poor cellphone coverage (Vodafone’s fault) and a rather noisy landline (Telecom’s fault), so voice calls aren’t a great solution to a problem.  Faced with a (presumably) long and difficult phone call, the ‘hack’ solution of altering the environment variable looked a little more appealing.

I downloaded iRecovery and opened a terminal (shell) connection to the iPhone.  Typing “printenv” gave a list of the environment variables – the ones that had a “P” at the start were presumably non-default values (these included “auto-boot”, “bootdelay”, “backlight-level”, and “platform-uuid”).  The article indicated that the “false” value for “auto-boot” was the problem (and the solution to use setenv to change it, then reboot the phone).  This seemed a reasonably safe thing to do (and also easily reversed), although I imagine that it would be rather scary to a non-programmer (who has no idea what “printenv” or “setenv” might mean).

Thankfully, this worked.  The iPhone rebooted – although it went straight back to the recovery page in iTunes, which wasn’t hopeful.  However, this time the recovery process worked flawlessly (using the existing four-day-old copy of the download).  The phone was recovered from the automatic backup, and then sync’d.  Some of the settings are a bit out as you expect in a recovery, but the phone actually works, which is really all that matters.

I don’t know what would have happened if I called the “iPhone Team” (and don’t need to find out now).  I suspect that we wouldn’t have got far, or maybe would have ended up doing exactly this (or perhaps having to return the phone for service).  I could be wrong about that.  I do feel that Vodafone (specifically @vodafoneNZ) handled this pretty well (and Apple extremely badly).