Sub Ubi

Minus a three week holiday, I’ve been teaching an adult course in Java programming for the last 10 weeks. This has been… educational for all involved.

Three students—two of whom are retirement age, I believe. Only one of the three has any previous programming experience, and that was 15 years ago. They’re all many years from their last experience as “students.” Despite the small size of the class, it isn’t “easier” to teach—it is different, but the amount of work an instructor has to do (if you’re going to do a good job) doesn’t drop magically with fewer students.

I’ve been working from the Barnes and Kolling Objects First textbook, which is one of the best out there for teaching Java. I also rolled in some of the “Design Recipe” approach from HtDP, as that was the text I’ve worked with most before this course. In the first eight weeks, I did my best to do a lot of repetition of core concepts (for reinforcement), and I assigned a lot of code annotation/reading assignments.

I could talk about some of the things I think were successful so far, but I think the most enlightening things have been what might typically be considered points of failure. These are the points where I have learned the most about what I’m attempting to do.

1. Not enough success early / success often

   I forgot the full implications of what it means to be an adult learner returning to coursework after a long absence. My students are not accustomed to the kind of frustration that can result from attempting to do something new and different; university-age students walk in the door expecting things will be new and different.

   I would give my students assignments, and encourage them to write me with questions when they were stuck. Most of them did not ask questions, and I wrongly assumed things were going well. After two weeks, I realized they weren’t; they were getting the concepts, but they weren’t connecting those concepts to the code they were writing (this is a persistent theme). In fact, they were having a very hard time actually writing code, which wasn’t obvious, as they were doing reasonably well reading code.

   My point is they needed more feedback, sooner, and it needed to be positive.

2. Asking questions is hard

   Sitting 10 weeks into the course, I realize fully that there is a certain amount of pride or stubbornness involved for adult learners: “I should be able to figure this out!” I also think they don’t appreciate fully how hard the material is, and just how many questions they should ask. Of course, this implies that they know what to ask, which often they clearly didn’t.

3. Failure to achieve automaticity

   In reading Schools of Thought by John Bruer I was struck by his review of research on reading and writing. In particular, the fact that as accomplished readers, no working memory is used in the process of reading—it is as automatic as learned kinetic skills (playing scales on the piano after years of lessons, etc.).

   My students can read code. They can’t read code automatically. They see

   Foo x = new Foo();
x.something();


   And they can tell me that Foo is a class, that x holds an instance of the class Foo (it’s an object), and that we then invoke the something() method on the object x. But that isn’t automatic. They have to think about it.

   When I look at that piece of code, I immediately understand as much as I have just said. In fact, this is almost irrelevant to me—I’m already more interested in what kind of class Foo is, and what the something() method does. In short, I’m using my working memory for building up a picture of what they program does, as opposed to making sense of the code itself.

4. Lack of context

   My course is the last of the IT certificate. It doesn’t connect particularly well to the rest of the course. So, on a larger scale, it isn’t clear why they’re taking this course.

   Within the course, I didn’t have a thematic arch for the 16 weeks. As a result, it wasn’t clear where we were going or what we were trying to achieve.

   Both of these issues can easily be dealt with the next time around.

I do have some solutions in mind for a second run; briefly:

1. Feedback early and often: Test harnesses

   I started giving the students assignments with test harnesses built in. This way, as they wrote their code, they could first compile and see if it runs, and then they could run the test cases to see if it does what it is supposed to. This way, they get instant feedback if they’re on track, or off track.

   This kind of quick feedback gives them confidence that they’re making progress. They really liked it in the most recent assignment, and felt much better about it as a result.

2. Requiring questions

   Perhaps I should not only have code reading and writing assignments early on, but also assignments where I force them to write possible exam questions, and they should provide (what they beleive) are plausible answers as well. If they can’t pose a question, then they should do their best to identify what it is they are confused about.

   At the end of the day, I guess I’m thinking that some more reflective practice would help.

3. Automaticity: Flashcards

   How do you establish automaticity in reading code? Certainly, there is no literature out there on this concept; this is probably the first time anyone has connected the ideas in writing. So, I can only use the mechanisms I already know work: flash cards, memory games, and other simple exercises that are designed to reinforce small pieces of information in long-term memory.

   When I started “programming” on the Commodore 128, I would copy long program listings from magazines so I could play some game, or use some utility. Eventually, I started writing my own little programs, and I would refer back to these listings to see if I could use things from them in my own code. Eventually, I managed to work out how to peek and poke things, which allowed me to do interesting things with long lists of data.

   Point being: it was by repetition and rote learning that I picked up a lot of things in the very early days. This must be a factor, and a significant one at that.

4. Providing context

   Anything. Something. Working towards an information system of some sort, be it a punch clock or an attendance register—anything that they can concretely understand and work towards. Something that ties together databases, HTML, scripting, and everything else that was in the course. Adding this kind of theme is relatively easy, however, so I’m least worried about this.

I’ll certainly revisit this. If nothing else, it has served its purpose as an external brain dump for me to share with my colleagues also working on the IT cert course.

From Guido van Rossum:

Like Python, Haskell uses indentation for blocks; after that, the similarities stop. It is a strongly typed pure functional language, where just about everything is written as recursive functions, because the language has no looping construct. Because of this it will probably always remain a language of mostly academic interest: loops may be theoretically inferior to recursion, but I have no doubt that the human brain has special reasoning abilities for loops, and many real-world problems are most naturally expressed using loops rather than recursion. I’d say that a loop is a higher-level concept than recursion; recursion is more powerful, but also more low-level, like assembly language.

I found myself sucked into a “recursion vs. state” debate last week. This particular debate was that it was easier to teach people about objects (as in object oriented programming) than to do anything that involves the word recursion. I maintain that the ordering in which material is introduced plays a significant role in a student’s ability to assimilate it into their existing knowledge of the world—and in this respect, students are no more prepared to think about a stateful, object-oriented universe than they are prepared to think about highly structured, and sometimes self-referential information (all of which is in the abstract).

Is it harder to learn structure than state? State than control flow? Control flow than structure? I don’t believe I can be as casual about which of these is easier or “more natural” the way Guido van Rossum is—that’s just sloppy. I think there is a critical interplay amongst all three of these concepts; remove one, and students can’t begin to understand the “notional machine” (a la Ben du Boulay), or the execution model (as I’ve commented on before).

I have a number of small sketches and diagrams building up; it may be time for another post in the “pedagogical ordering” thread.

Inspired partially by Matt Lavine’s quest to find haiku in the words of Bush, Rumsfeld, and other hawkish luminaries of our time, I decided the errors in a program I’m writing should be in the haiku form as well.

The program is intended to make it easy for students to send questions to the instructor while working in the BlueJ programming environment. BlueJ is an piece of software designed to support beginners who are learning to program in the Java programming language.

The interface isn’t all that fancy; it’s just a window that lets them to enter a subject and add some additional text:

Nothing special. When they forget to indicate what course the question is intended for, we get the first possible error they could commit:

Now, they may also leave the “Attach Code” box checked, but not actually have any files in their project. This is unlikely, but possible.

And, of course, they may leave one or both of the fields blank; this isn’t to be tolerated. Actually, it just seems like a bad idea, and makes things harder for the instructor later.

It’s a beautiful day here in Canterbury. Too bad I have work to do. At least an officemate got a giggle out of them.

Tuesday nights I’ve been teaching introductory programming to a group of mature students. They’re on the new IT certificate course, and for some of them this is the first time they’ve ever seriously engaged in a programming-like activity. It is definitely challenging for both them and me.

We’ve been using Objects First with Java: A Practical Introduction using BlueJ by David Barnes and Michael Kölling, and the pedagogical programming environment that drives the approach, BlueJ. In teaching this text to adults, I’ve learned a few things that I didn’t realize coming into the course:

• Repetition matters. There’s a lot of background that undergraduates today tend to bring to the learning process—even if it’s just that they’ve been in school continuously for the last 15 years, as opposed to having been away from school for the last 15 years. Repeating and drilling concepts is critical.
• Reading code matters. Moreso, drilling the reading of code is important. My students have a very good grasp of the concepts surrounding classes and objects, but that is not grounded (confidently) in how we express those ideas in the Java syntax.
• Projects motivate. In particular, we’re into chapter 5+ in the BlueJ text, and most of the material there is, in my opinion, difficult to motivate. Perhaps more specifically, my students are likely to never write programs of such substance that ploughing through the remainder of the text is going to matter; we need to ground things from the remainder of the book in practical exercises that have real meaning for them.

To this end, I’ve decided this eight weeks will be project-based. We’ll tackle a project that is a little beyond the abilities of the class, and learn these more advanced topics as we need them. At the least, I’d like them to see inheritance in action, but I think that can be arranged. Beyond that, anything we accomplish is good, as long as they’re motivated and keen to succeed.

I’ll try and be more on top of the next few weeks, and do some more writing here about the experience, as well as provide a bit of a background on PBL. As it stands, our first class of this eight-week “term” went well; we discussed the work they did over the Easter holiday, and brainstormed a number of possible project areas. From there, we started working through one of them, just to get a sense of what was involved. I think our first lesson learned could be summed up as

Seemingly easy things, aren’t.

This seems like a good starting point. We worked through some difficult logic involving time, and I sent them off to think through where other difficult parts of a client/server application might lie. Given what I was trying to have ready for them Tuesday night, and what I ended up with, I’m glad my prep completely failed. Class went well.

I wanted to put a little more info on-line for my parents-in-law, and also capture a bit from this afternoon when I (finally) manage to catch Pete.

Software like iChat should (and does) have the phone company worried. Phones make money; what I’m about to describe doesn’t. And anything that doesn’t make money for them is good for us.

I created an AOL Instant Messenger account for myself and my mother. Then, I started up iChat, and added my mother to my “Buddy List,” which is pictured below. I called home, and talked her through starting iChat, logging into AIM (we had some problem for a bit because she accidentally selected a “.Mac” account as opposed to an “AIM” account), and we were rolling at that point.

The iChat “Buddy List”

The thing about instant messaging clients is the … well, instantaneous bit. When I start iChat, it tells a server that I’m logged in; not only that, but iChat tells the server who my “buddies” are. When one of my buddies log in, the server then lets me know that they’re online. From there, we can do a number of neat things. (Footnote: I’m not positive this is how the software works, but it does give you the right idea.)

First off, I can push the little “A” button in iChat (at the bottom of my Buddy List) and start “chatting” via text. I type something in, and it immediately gets sent to the person I’m talking to. Pictured above, you see my mother and I typing back and forth. To test the system, I tried sharing a recent picture of Carrie and I; I was at a conference in Ireland, and Carrie came across the water to stay with me while I was there. iChat sent the picture in my little “talk bubble,” it popped up on my parent’s computer, and they were even able to drag it to their desktop to save it.

Neat.

But the thing we were most blown away by was the little phone button at the bottom of the buddy list. Pushing this button effectively “rings up” your buddy, they can “pick up the phone,” and the two of you can then have a voice chat, in real-time, over the Internet.

My parents are on dial-up, but we had no problems. In fact, audio quality was better than some of my transAtlantic phone calls I’ve made in the past. They used the built-in microphone in their iMac, which was OK; a pair of headphones with built-in mic would be better (right) for audio quality, but by using the built-in mic, both my mother and father could talk to me, and both could easily hear what I was saying through the speakers in the PC. A genuine speakerphone.

What would ideally come next is video. This afternoon I’ll chat with Pete (who has a nifty video-chat camera thinger), and before then I’ll try and find someone with a video camera that I can use. From searching the web, my guess is that it won’t be possible for me to find the right hardware that quickly.

However, it would be neat to be able to “call home” with full video. Or, it would be great (if we can afford to get Carrie onto broadband for next year) for us to be able to video chat… casually. Once you’re paying for the Internet connection, being able to do this involves little more than the cost of the camera. Well, and the computers doing the communicating… but we’ve already paid for those. So, now we might as well start using them.

I’ll follow up with what a (one-sided) video conference looks like when I chat with Pete later this afternoon.

Pete has been pressuring me to get iChat working. I finally gave in. I had this thing against instant messaging clients—in my (limited) experience with them, they’re nothing more than a distraction.⁰

Sunday night, I gave in. I decided to set up an account for me, and on a whim I also set up an account for my parents. I then called home and talked my mother through the setup of iChat. We hung up, she logged into the ‘net, and viola!, we were using VoIP technology to talk between our computers!¹ What blew my mind was that I was sitting in bed in Canterbury, going wireless to a DSL connection, which bounced then to London, NYC, around to Chicago, and then down to the Cleveland area to get to their ISP, at which point it squeezed through a 56k line.

We talked for 2 hours. Audio quality was great.² My father wandered in eventually, and we had a conference call in a way that wasn’t really possible before.³ In communicating this way, things that were just so difficult before were easy; for example, I had told them I’d point them at a place to get a card for their digital camera. Unfortunately, this wasn’t taken care of while I was in the States, and it hasn’t come up in email so far. My mother mentioned it; I looked it up on the web; I pasted it into iChat; she clicked the link, and had the same page in front of her that I had in front of me.

Wow. I mean, this is almost as cool as mobile phones. Actually, it might be cooler than mobile phones. Who knows. (One Of Duncan’s Handlers thinks I’m silly for believing this stuff is magic, but it is.) Fortunately, I just cancelled my mobile phone contract (pay as you go is more economical for me in the long run), and now I need to see if we can budget getting Carrie broadband access up in Wales.

PS. MBL, get an AIM account, and setup iChat.⁴

---

⁰ This is probably still true.
¹ Truth told, it took three tries, because we accidentally chose a “.Mac” account the first two times around when trying to set her up; once we worked that out, things were easy-peasy.
² Not as good as a phone on a good day, but better than my transAtlantic phone connections most days.
³ I mean, it was possible, but whenever you picked up two phones in our house… anyway, the line voltages were never quite right, and someone would have a horrible connection.
⁴ Gratuitous footnote.

I’ll update this post later; for the moment, I’d really love it if someone would drop a comment to this message that told me how to properly include a JAR file into an XCode Cocoa/Java application on OSX. Given the ability to bridge a native UI with Java is so easy, it seems like it shouldn’t be that hard to use code from a JAR file.

But… I’ll be damned if I can find it anywhere in the Developer docs or Google.

UPDATE 20040419
To be more specific:

1. I want to be able to construct an application GUI quickly via drag-and-drop.
   
   The cheapest and most direct way to to achieve this seems to be Interface Builder. Someone donating a copy of a full version of RealBasic would achieve the same thing.
2. I just want to interact with some remote services via XML-RPC.
   
   I can code the application logic in AppleScript, Objective-C, or Java as this is the majority of what I need to do.
3. This isn’t so important that I really want to learn another language.
   
   AppleScript is cute, but ugly. I don’t want to deal with pointers and learn all the syntactic sugar of Objective-C; this project is important, but small, and doesn’t justify that kind of time. I know Java.

I want to build a GUI, native, that has it’s program logic written in Java; most of it’s interaction will be with remote servers via XML-RPC. Therefore, I really need to import the Apache XML-RPC library into a Cocoa/Java application. I successfully tied together an interface and controller classes using the NeXT Step OSX development tools.

As far as I can tell, I need to add a new build phase that copies the JAR into the correct place in the application bundle that is produced. I do not know how to make Xcode copy the JAR where it belongs. This is very, very annoying. I have docs for Project Builder that are different enough that I can’t extrapolate to the new tool.

RealBasic would probably be an ideal solution, as I really would like the little application to eventually run on Windows and on the Mac. However, I don’t think I can even con my department into buying me a full-on Professional license. I’ll post documentation tomorrow regarding the actual software, which is currently implemented as an extension to BlueJ.

The PPIG community is small, diverse, and therefore makes for good conversation—both research related and in general. My presentation went well, and some good ideas came from talking with other attendees afterwards. I’ve posted the paper (titled A first look at novice compilation behavior using BlueJ), and imagine it will eventually turn up in the PPIG archives.

What is good compilation behavior? I suspect this question is going to become something I have to tackle through research. Having spent time digging through how first-year students at Kent actually interact with the compiler, I don’t know if we can easily declare any one behavior to be better than another. However, this is the next step in the analysis: to focus on individuals, and attempt to find aspects of their compilation behavior that set them apart from each-other.

Neat stuff.

Mon 29 Mar	Wed 31 Mar	Grand Challenges in CS Education
Sat 3 Apr	Wed 7 Apr	PPIG 2004
Wed 7 Apr	…	Wales