JoC, Teacher Commentary 3: Objects and classes

    Treat people as if they were what they ought to be, and you help them to become
    what they are capable of becoming.
            — Goethe

So, here we go, the first instalment of a Teacher Commentary.

If, you may ask, this is the first one, why then is it called “Teacher Commentary 3”?

Fair question, but there is method in this madness. I have decided to number them not sequentially, but in sync with the main Joy of Code episodes. Each Teacher Commentary will get the number of the episode it refers to. Since this commentary talks about episode 3, it is Teacher Commentary 3 (or TC-3, as I will soon start to call them in the headings).

Sometimes the teacher commentaries may not be tightly associated with an episode, but they will still fit in somewhere in the sequence, so they will get whatever number we’re up to in the main episode sequence.

One more rhetorical question before we get to the video: What is a “teacher commentary”?

The TC videos are meant for people who are not only concerned with learning object-oriented programming, or Greenfoot, or Java, but with teaching it. It talks to you as a teacher.

If you are not a teacher, you’re of course welcome to look at it as well, but I’m not sure how interesting this will be for you. Maybe your time is better spent moving on to the next main episode. (You won’t miss anything important.) Your choice.

Download video

 

JoC #3: Classes and objects

    If a man writes a book, let him set down only what he knows.
    I have guesses enough of my own.

          — Goethe

Alright, now it finally starts getting interesting! After the previous talk about installation, now we’re getting started actually doing stuff.

Watch this episode to get the first feel for working with Greenfoot, and see what classes and objects are all about.

Download video

Concepts discussed: class, object, method, instance, return value, return type, void, int, boolean

And, as I said in the video: Follow @JoyOfCode on Twitter to get updates when new episodes are posted.

Scenario download for this episode: hedgehogs.zip      (save and unzip before opening)

The Joy of Code, #2: Installing Greenfoot

     A professor is someone who talks in other people’s sleep.
          — attributed to W.H.Auden

Straight on the heels of the first episode comes the second: Installing Greenfoot.

We’re still not quite ready to write code, but we’re getting there. Setting up the environment is important, so we’ll do that first.

Download video

I made one mistake in the video: For running on Mac OS, Mac OS X 10.5 (Leopard) is required as a minimum OS version (not Tiger, as I said in the video).

The links mentioned in the video are:

The Joy of Code, #1: Introduction

    Everything that is worth doing is worth doing well.  
        — proverb 

Here is the first instalment of the Joy of Code programming tutorial. No coding yet — this intro just shows you what you’re getting into if you choose to follow this tutorial.

Download video

If you are itching to get your hands dirty and start coding: great! That’s the kind of reader I like. Don’t worry, we’ll get there very soon.

Links mentioned in the video:

Greenfoot scenarios shown in video:

(Note: At this stage you are not expected to do anything with these scenarios yet. These are just here for those of you curious to play without waiting for me to introduce things.)

Download video

BlueJ downloads hit 10 million!

The total downloads of BlueJ hit 10 million today. We started recording download numbers in 2001. Early on, downloads ran in the low hundreds per month, and we were really excited when they reached first 10,000 in a year, and later topped 100,000.

Currently, BlueJ downloads run at 2.5 million per year, and are still rising. Hitting the total of 10 million was a nice milestone.

 

Java 7 for introductory programming — does it make a difference?

The recently released BlueJ 3.0.5 brought full support for Java 7. While it is always good to be up-to-date with the latest versions — what does that actually mean for introductory programming teaching?

Java 7 brought a considerable list of new features to the Java system. Most of them deal with fairly advanced or specialised topics, and will have no influence on introductory teaching with Java. Some, however, will become visible even close to the beginning of programming. Here, I give a short overview of what’s new, and what you — as a teacher of introductory programming — should be aware of.

Java 7 – What’s new

Most of the new features in Java 7 are under the hood or in specialised libraries. These are very unlikely to affect an introductory programming course.

Improvements to the internals of the JDK include changes to the VM to support dynamically typed languages and improvements to the class loader architecture. On the library side, there are new frameworks for concurrency, cryptography and new versions of JDBC and Unicode. All these will not be relevant for most introductory courses.

The two areas that are relevant are “Project Coin”, the code name given to a project defining several small language enhancements, and NIO.2, a new library for I/O. We’ll discuss these in more detail in a moment.

Equally important, what’s not included in this release includes support for closures (known as “Project Lambda”). This would have been the most significant change to Java since the introduction of generics in Java 5 or, arguably, since the original definition of the Java language in 1995. Project Lambda has, however, been deferred to JDK 8 in what’s known as Plan B. JDK 8 is currently scheduled for release in late 2012.

So, which of the new Java 7 features are actually relevant for our intro programming course?

NIO.2

The I/O classes in Java have been improved several times over the years. The release of JDK 1.4 in 2002 brought some significant improvements in the somewhat short-sightedly named NIO library. The naming is rather less than ideal, since it stands for “New I/O”, and the passing of time dictates that everything new will eventually get old.

Which brings us to Java 7 and the New New I/O. So what will this be called now — NNIO? Well, the designers settled on NIO.2.

NIO.2 brings a number of new classes and interface, some with very useful methods. If you are doing any programming that accesses the file system, it’s worth familiarising yourself with these. Particularly interesting are the Files and Paths classes, and the Path interface, which you can find in the java.nio.file package.

All other relevant new features are part of Project Coin. They are diamond notation, strings-in-switch and improved exception handling.

Project Coin

Diamond notation

Generic type details on the right hand side of an assignment can now be inferred. For example, where in Java 6 we had to write

   HashSet<String, Monster> monsters = new HashSet<String, Monster>();

to declare a HashSet variable and initialise it with a fresh HashSet object, in Java 7 we can write

   HashSet<String, Monster> monsters = new HashSet<>();

In other words: We do not have to repeat the generic types of the HashSet on the right hand side, and can instead just write <>. (This syntax is the reason that this construct is known as the “diamond notation”). The effect of this is exactly as the Java 6 version above. It is a purely syntactic shortcut. The compiler will fill in the generic types by copying them from the variable declaration on the left, and all behaves just as before. Of course, the old notation is still allowed.

Strings in switch statements

The variable used in switch statements can now be of type String. For example

   switch (command) {
       case "go":
          goForward();
          break;
       case "help":
          showHelp();
          break;
       default:
          unknownCommand();
          break;
   }

Before Java 7, strings could not be used in switch statements.

Improved exception handling 1: multi-catch

It is now possible to catch multiple exceptions in a single exception handler. For example:

   try {
      file = new File("readme.txt");
      process(file);
   }
   catch (FileNotFoundException | UnsupportedEncodingException ex) {
      ...
   }

As you can see in this example, the catch clause can list multiple types of exception in its header, separated with an OR symbol, to catch any of these types of exception.

Improved exception handling 2: try-with-resources

The second new feature relating to exceptions is called try-with-resources. It solves a hard problem: It was previously surprisingly hard to correctly guarantee that resources (such as files or network connections) were correctly closed in the case of an exception.

The new construct solves this. Look at this example:

   try (FileWriter writer = new FileWriter(filename)) {
      ...
   }
   catch (IOException e) {
      ...
   }

Before Java 7, the standard way to close a resource (a FileWriter in this example) would have been in a finally block, which followed the catch block. In Java 7, the FileWriter is opened in round brackets following the try keyword, marking it as a resource to be auto-closed. Once the try/catch block is completed, the resource will automatically be closed by the Java runtime system.

For classes to be used with the auto-close mechanism, they must implement the new AutoCloseable interface. All the relevant classes in the Java library have been retrofitted to implement this interface.

That already sums up the relevant Java 7 changes. As we can see — not much to worry about here. (This will be different next year, when JDK 8 will bring us closures. I expect we will have to have a lively discussion then about how to treat these in a first-year course. But we can leave that for a while.)

To find out more about the new constructs in Java 7, see this summary. The next version of the Object First book (5th edition, to be released in late October) includes discussion of these new features.


Note: This post was first published in the Blueroom.

Multiple levels in Greenfoot games

A demo scenario

Yesterday I announced that a new Greenfoot version is available (version 2.1). Over the next few days, I’ll go through some of the new features and introduce them briefly here. This is the first one: the setWorld(…) method.

The Greenfoot class now has a method with the following signature:

setWorld (World world)

This method takes a world object as a parameter, and it will show that world in the Greenfoot main window.

This allows you to have multiple World subclasses (in my example called Level1 and Level2). You can then dynamically (that is: while your program is running) create and install other world objects. These other worlds can show entirely different scenes, such as other levels.

Two world subclasses, representing different levels.

For example, to go to Level 2, you could use the following statement:

   Greenfoot.setWorld(new Level2());

Of course, the same initialisation applies as usual: If the Level2 world creates and inserts some actors in it’s constructor, this will all happen.

One thing to keep in mind, though, is that this will – if you don’t do anything clever – create new actors. So, if you have a game character in level 1, an then you add a game character to level 2, you will have a new character object. If you stored some state (e.g. a score) in the instance variables of that actor, it will be gone. If you want to preserve the state of your game character, make sure you carry the actor object across without creating a new one.

An example showing this new functionality in action is now on the Greenfoot Gallery, here.

Greenfoot 2.1 released

We have just released Greenfoot version 2.1.0.

This update of Greenfoot includes a good number of bug fixes, so if there is something that has bugged you for a while, give the new version a go and see whether it’s improved. (If not, tell us!)

But, more importantly, this version also includes some new functionality. The new features include:

  • A new sound API for volume control. This means Greenfoot scenarios can programmatically adjust the volume of sound clips. Several people have asked for this, especially aiming at fading sounds in and out nicely.
  • A new input function: getMicLevel. This function returns the noise level from the system microphone. This makes it very easy to write soem very simple early interactive examples.
  • Support for multiple worlds. Greenfoot now has a function to dynamically show different world objects. This makes it much easier to develop games with different levels.
  • Built-in move and turn methods. Actors in Greenfoot now have turn(int) and move(int) methods which turn and move relative to the current rotation.
  • UI changes. Finding out how to share your scenario on the Greenfoot Gallery has been made much easier. We suspect that many users previously never discovered this important function.

So, surf over to the Greenfoot download page and give it a go. Let us know what you think.

Over the next few days, I will add a few blog posts here that introduce and explain the new functionality in more detail. So check back soon!

Part 1: Using setWorld to create multiple game levels.

Use the Microsoft Kinect with Greenfoot

Those of you who know Greenfoot know that one of its aims is to make programming for beginners exciting and engaging. (Those of my readers who don’t know it should have a look here.)

The most recent addition to Greenfoot is a library that allows programmers to easily use the Microsoft Kinect module with their Greenfoot scenarios. This means that you can now write simple Greenfoot games that are controlled by players body movements.

Probably the easiest way to show what I mean, is to show you what I mean. Here’s a short video:

Programming the Kinect with Greenfoot is probably the easiest way to write programs with the Kinect module. Neil Brown, one of our developers on the Greenfoot team, has adapted open source server software that communicates with the Kinect and designed and implemented a Greenfoot library that makes access surprisingly simple.

If you are interested to try it yourself — here are the detailed instructions. But beware: you might stand in the middle of your room waving your arms around for the next few days! Some people might look at you strangely, but it’s great fun.

Sharing of teaching resources – it’s about people, not about stuff

iconAt the beginning of April this year, we opened a new web site: the Greenroom.

The Greenroom is a web site where teachers who teach with Greenfoot can share resources and have discussions. It was clear for a while that sharing of resources was a powerful thing that was urgently needed for the Greenfoot community. Greenfoot is different from many other environments, teaching with it requires different projects and different ideas, and thus getting started with it, as a new teacher, is challenging. Having a community to talk to, to ask questions, to get ideas, to get tried and tested material, makes a huge difference.

Yet, this is a space where many have failed.

It is often said, with only slight exaggeration, that there are more teaching resource repositories than there are teaching resources. The fact is, countless resource repositories have been created, and most of them have tumbleweed blowing down the main street.

The typical pattern is this: A repository is opened, a flurry of activity follows, resources are submitted (often by the creators and other people personally involved or contacted), and then it dies down. A few months later, little is happening, resources are not maintained, few new resources are added, you can hear the cold wind blowing through empty spaces.

A high profile example is the repository of resources on the ACM SIGCSE website (one of the largest organisations in computer science education). It was – as far as I know – opened in early 2004, and initially attracted a good number of submissions. However, this quickly died down. Looking at the recent submissions, it seems that only four resources were submitted in all of 2008. This went down to three in 2009, with one single submission (so far) in 2010.

Now, I don’t want to pick on that one particular repository specifically. This pattern is not unsusual. I am pointing to it here as a typical example. Making repositories thrive is hard. (We have recently published a paper about this.) So, when we designed the Greenroom, we were very worried about meeting the same fate: spending a whole lot of effort in creating a repository site, only to have it die a slow, quiet death after a few short months.

I am happy to say that we seem to have avoided that fate. The Greenroom is alive and well.

From September 2009 to March 2010, the Greenroom existed as a Google Group. This gave us an excellent discussion forum, and quite poor storage of resources. Over these first six months, about 170 people signed up. Then, at the end of March 2010, we finished our custom implementation of the new Greenroom, and we were amazed at the result: even though only half of the Google Groups subscribers moved over, we surpassed the old subscriber numbers within two weeks, and then they continued to climb. Now, after eight months, we have about 900 people signed up. Lots of resources have been posted, and many interesting discussions are going on.

subscriber graph

Subscriber numbers of the Greenroom; old (red) and new (orange)

So, what makes this site work, when so many others have failed?

I think, in building such a site, you need to address a number of questions:

  • Who is allowed to upload resources? Everyone, or only trusted people?
  • How do you ensure quality? By prior review (work-intensive, hard), or do you let everything in (and risk flooding by poor quality, untried material)?
  • Do you restrict access? (If only teachers can access, you can also post exercises with solutions, exams, etc. But then you need verification.)
  • How do you maintain the resources? Who looks after them?
  • Do you store local copies of resources (which may go out of date) or links to outside resources (which may break)?
  • How do you organise searching and browsing? This requires relating resources to each other – who does that work?

And most importantly:

  • How do you make people come and submit interesting material, and participate in interesting discussions?

I think there are some design choices you can make to address many of these things. As a result, we have built a repository site that is quite different from others. We decided to not use a standard platform (because they only gave us the same old stuff that we didn’t want) and build our own from scratch. The main design choice, which makes most of the difference is this:

The site must be about people, not about stuff.

So we designed a site that is primarily about community, and then about material. There are many design details that embody this idea:

  • The main page of the site shows activities of people, not lists of things.
  • People sign up to the site, and have an ongoing relationship with it. It’s not something where you go once every two years when you redesign your course, it’s a place where interesting things are happening every week or maybe even every day.
  • People sign up with their real names, and are encouraged to post profile pictures. In the Greenroom, you move in a community of peers, not in a big, anonymous black hole.
  • The mental model is that of a staff room in a school, not of a library. It’s about meeting people, not about searching through piles of stuff.
  • Submitting unfinished resources is welcomed. We all know that most things never get finished – submitting something is better than submitting nothing.
  • The resources are owned by the community, not by single people. The edit rights follow a wiki model: everyone can edit everything. (I remember the moment in our design discussions when Neil Brown, one of our team members, suggested this. This changed almost everything. Many of the questions posted above are affected by this. Like many good ideas, it seems obvious in retrospect, but wasn’t at the time.)
  • Small contributions are welcome. Linking some related resources, for example, is a good thing. It’s quick, anyone can do it, and the wiki model allows everyone to do it.

In short: I think people should re-think teaching repository design. It has worked for us. (More details about this are in our paper.) There is daily activity in the Greenroom, many people visit regularly, we have frequent interesting discussion in our forum, and a large number of excellent resources. It has been going much better than we dared to hope.

So, if you think about designing a resource repository, think about the people, not about things. And if you are a teacher interested in Greenfoot, join the Greenroom. There are many friendly people there happy to help.