Last night was the second session in the introduction to Java that I’m teaching as part of Kent’s IT Cert course. Most of my students had not reviewed chapter one, or continued working through any of the exercises; in an 8-week course, this isn’t ideal, but we can manage at this early stage.

I spent a good chunk of Sunday prepping for class, as well as ironing some details out on Monday. The prep was primarily composed of building a tutorial that would run within BlueJ; we’re calling these tutorials trails. This is because the tool we’re currently using to build the trails (a modified version of JFLAP–a tool designed for teaching student about automata) lets us draw out the progression of the tutorial, as well as attach conditions on the transitions from one step to the next.

From the student’s perspective, they encounter the tutorial content as a textual pane embedded in BlueJ.

What’s interesting about the tutorial is that we can interact with the environment and the student’s code at a very high level through the BlueJ Extensions API. This means we can write a tutorial that responds to

• Classes of syntax error made by the student,
• (Some) semantic errors made by the student, as well as
• The state of their interactions in BlueJ with objects on the bench.

Practically, this means we can augment or override compiler errors with messages of our own, we can inspect their code to see if they’ve carried out the correct additions or modifications (example below), or see if they understand how to interact with the classes they’ve written as objects.

For example, I wanted my students to write a very simple class:

public class Animal {

}

This is because I wanted to build up to adding fields (one at a time), a constructor (that sets default values for those fields), accessors (again, one at a time), and mutators in a very stepwise, controlled manner. This way, syntax errors would generally be constrained to one or two lines of code at a time, and the students would repetitively encounter the fundamental elements of a class. Drill-and-practice at its simplest.

Using the trail builder, we can check for all kinds of things (more on this when the tools and software are released after testing). This particular tutorial didn’t capture any syntax errors, but it would check to see that they managed the semantics of each step. For example, we could check that they had a class called Animal with no fields or methods; if they didn’t, we give them some generic feedback saying as much:

After enough attempts, we encourage them to ask a question. There are better ways of handling this, but for the moment, the intention was to get the students asking myself or each-other questions in-class, not coding checks for every possible contingency. When they get things right, something very important happens: they get positive feedback.

Off the top of my head, I don’t know of any tutorial systems for programmers that offer this kind of interaction. We can augment syntactic error messages, semantic errors (by examining their code through the BlueJ API or unit tests), we can branch to sub-trails to drill on specific problems as necessary, and most importantly, we can praise students for work well done—something that simply doesn’t happen in VB.Net (or any other development environment I’m aware of).

I think the class went very well. I was surprised at how far through the tutorial my students made it in an hour-and-a-half, considering none of them have done any programming of significance before. They saw it as a lot like HTML, but “more picky.” At the end of the evening, we were able to recap and go through the concepts and vocabulary fairly easily. I’d say that there was a lot of value last night in drilling on basic concepts from the start.

We’ll see what happens next week; I’ll be writing a “drill-and-practice” tutorial generator (so I can give them an endless stream of these kinds of problems to work on), and we’ll start digging into the TicketMachine material I’m cleaning up.