Pick Up the Crew is Go

I published the First Year programming coursework today. If students fancy writing a game they can create a version of "Pick Up the Crew", an action packed game where the captain has to search the cruel sea for overboard crew members, all the while avoiding hungry sharks.

Above is my highly abstract test version written in XNA. I'm a great believer in "placeholder graphics", as you can see. 

I'm expecting great things from the students this year. I've even bought "pickupthecrew.com" and I'll sign it over to the student who produces the best looking game at the end of the semester. As long as they publish the game of course. 

Free C# Course and a Shiny New Kindle C# Yellow Book

I've spent the last couple of weeks swearing at HTML files. Who would have thought that converting a Word document into nicely formatted markup could be so difficult. Anyhoo, I've finally managed to get the text into some sensible shape and it now has a proper Kindle table of contents.  If you have already bought my C# Yellow Book on Kindle,  then you might like to update your copy.  If you haven't you can get one here.  And why not?

Of course the original version is available at the usual place. And I've also added the entire content of our First Year programming course from last year. This includes over 100 slide decks, practical sessions and the assessed coursework. The content is free for anyone who wants to teach C# or learn it. Enjoy.

Robs Magic Marker

In December last year we spent a happy four days marking first year coursework. I'd printed out a marking sheet for each student and we sat down with each one and went through their programs filling in the marks. At the end I had around 200 forms that had been filled in during the marking, the next step is to enter these into the assessment system.

This seems like the hard way to do it, and it is. But it is the only way that I can check to make sure that all the grades from the different makers line up and that every student gets appropriate feedback.

Imagine my joy when I discovered that when I created the assignment on the university assessment system I'd accidentally selected the "anonymous marking" option. This means that the submissions on the system are, ahem, anonymous, not in an alphabetic list like the one that I'd carefully created. And there's no way that I can "de-anonymise" them. So now I have to sort all my paper sheets into numeric order and then run the risk that I'd get things mixed up.

Fortunately I'm a programmer and so I reckoned I could fix this. Turns out that "anonymous" means "indexed by student number", which is something I can easily obtain for each student. And the submission system has a "bulk download" option so I can bring down all the submissions and then fiddle with them on my computer.

I've ended up with a little program that does all the heavy lifting for me. It gets all the entries, matches names with numbers, lets me enter comments and generates the marking spreadsheet ready for upload into the system.

It took me a morning to create (which is around the time that it would have taken me to sort the paper copies) and I can use it with the assignments from now on.  Sometimes you do get progress from your mistakes.....

Update: A sharp eyed reader has spotted that my cunning technique makes a bit of a mockery of "anonymous marking" as it turns out I was able to map the submissions onto the students with just a bit of C#. That's true, and any member of staff who wanted to could find out the author of a so-called "anonymous" work. However, we don't use this technique to prevent this kind of bad thing. Instead we use it to prevent "unconscious bias".

I was not a fan of anonymity when it was introduced, I saw it as a criticism that implied I might be inclined to victimize particular students if I knew who they were. However, it is not like that at all. If I know Fred, and I'm marking Fred's work, then I'm going to bring to the process all my knowledge of what Fred is like. If the mark I come up with is a bit low, but I happen to think that Fred is quite good, I might inflate it to compensate for this. This is unfair. Fred should get the mark the work is worth.

If all I see is the student number when I'm marking it is much less likely that I'll know  that it is Fred who did the work, and the mark I come up with will be impartial. 

In this case we mark the work in front of the student and so the question of anonymity does not arise. The student is in a position to discuss the mark that they have been awarded to make sure that justice is done, and so I don't see a fairness problem in this situation. But I'd never use it to break "proper" anonymity as this actually makes my job more difficult. When I'm marking exam scripts I much prefer not to know who wrote them, this makes it easier to just focus on what is in front of me. 

Social Media and Professional Work

Peter and I have spent quite a bit of time this week watching our second year students present their solutions to a commercial development problem that we set this semester. We created groups of students, gave them an incomplete specification, some legacy database code and turned them loose. It's been great fun. 

One thing that is very important is that team members are in contact with each other during any development like this. Lots of teams told us that they had created private Facebook groups and used these to set up meeting and manage interactions. This worked well because, as they pointed out, they are all on Facebook and this makes it easy for them to keep in touch with each other. So it works, but is it professional?

After a few presentations I'd think I'd figured the right way to make the point that this  probably isn't the best way to do it. I asked each group if they thought it would be OK for Peter and I to use a private Facebook group to store and manage their assessment results. Nobody thought this was a good idea. Even though the situation is exactly the same as someone writing software for money. 

So, the lesson here is that if you're working on a proper project you should probably use proper tools to manage your group interactions. Take a look at Yammer, Basecamp, or Trello. These are perfect for short term student projects as they seem to have trial (or free) versions that would sit will with student assessments. And they are another skill you can put on your CV. Employers are just as interested in your experience with project management tools as they are with anything else.

You could even do something cunning like pick a system you've not to used for your next Three Thing Game team entry. Then write a blog post on how you got on with it later. 

Finished Marking

We finished marking the First Year ACW today. It's been four long days of sitting down and asking the question "So, does it work?". Many thanks to Mike, Kevin, David, Simon and Septavera for rising to the challenge and getting everyone marked in good time. Now I've got to go through 190 or so of the mark sheets, normalise them and put them on eBridge with the comments transcribed.

It is always interesting looking at programs from people who are learning to code. What struck me this time was that as they were writing the software students were improving their style. So parts of the program would be rather messy constructions and the later bits would be tidier. 

This year we had some stunning submissions. XNA is great platform for making sprite based games but it is really hard to implement a turn based board game using it. But quite a few students had risen to the challenge and we had marks in the high nineties and one or two 100%s being awarded.

I'm rather looking forward to marking the work in the second semester.

Python Wrap

Python wrap sounds like the kind of dish you don't pick off the menu, or perhaps a piece of music that you really don't want to hear. But in this context I'm talking about the last of our "Wrestling with Python" sessions for a while. They have been great fun to deliver, and it has been lovely to watch people come to terms with the artful business that is programming. 

This week we were making good on our promise of a "Soup to Nuts" implementation, going from problem description to working code.  And we added some File Handling, just to make it even more useful. You can find the slides and completed code here.

We'll be running more of these next year. 

Writing a Program is not a Fight

Our First Year students are busy at the moment working on their Assessed Coursework. They are implementing computerised versions of Tactical Space Cheese Racer, a board game that we've invented just for this year. 

One student came to see me today and told me that he was having problems getting the code to work. Each line of his breathless report was prefaced with "And then it does this...." as if the code was some kind of malign being that he was fighting against. 

After listening for a while I had to remind him that he is not in a battle here. The program is something that that he created, and therefore he really should focus on the steps that it follows and why it does what it does. Just poking the beast by moving code around and adding and deleting statements will not actually tame it. What you have to do is focus on the sequence of operations it goes through when it does these bad things. 

We started going through the code and finding stuff here and there that could be fixed, and by the end he was referring to the thing as "my program", which I think is progress. 

Tactical Space Cheese Racer is Coming

Every year we set the First Year Programming course a piece of Assessed Coursework. Each year it is a board game of some kind. This year we will be playing "Tactical Space Cheese Racer". This is a game that involves space, cheese, racing and tactics.  As you might expect.

The game is a bit like "Snakes and Ladders" but without the ladders and snakes. Each player is flying a cheese powered rocket over the board with the aim of reaching the finish as soon as possible. Each turn the player can throw the "tactics dice" and try to cause as much mayhem as possible (they can get extra turns, their engines might explode etc etc).  On the cheese squares they must use tactics because the power of the cheese compels them to. 

I've built a simulation and played a few games (well, 10,000 actually) :

Arnold is an AI player who always throws the tactics dice. Norman never uses tactics unless he has to. Simon throws tactics if he is last in the game and Sandra uses tactics every now and then. I think the balance is reasonable, at least for now. We'll be rolling out the coursework in the next week or so. And tonight I spent a happy half hour finding out how to make chrome effect text using image based lighting in Photoshop.

When to Explode

I think I've blogged on this one before, but think it is worth mentioning, since we touched on it during the First Year programming lecture today. 

Consider the ReadNumber method above. It is designed to make our lives easier, so that if I want to get the number of players for my game I can just call the method:

int noOfPlayers = ReadNumber ("How many players? : ", 2,4);

The idea is that the method prints the prompt and gets a number from the user in the range 2-4. If the user gives a value outside the range the method politely asks for another value.

This is a neat method. But what happens if I make a mistake when I call it:

int noOfPlayers = ReadNumber ("How many players? : ", 4,2);

This means that the minimum is now higher than the maximum. Which is wrong. During the lecture I mentioned this possibility and suggested this rather firm approach inside the method when it runs:

if (min >= max)
                throw new Exception("Invalid min and max range");

The code above makes the method fail if the minimum and maximum are incorrect. And by fail I mean stop the program from working. I suggested that in this situation the method can't do anything but fail, since it is operating under a failed premise. 

After the lecture one of the First Year (splendid bunch by the way) came up to me and suggested that one solution would be for the method to just swap the minimum and maximum values round if the method discovers that they are the wrong way round. The test is easy to make and swapping the values takes no time at all. And the method is then going to continue. So why not?

Because this is the kind of idea I call "Half way good and all the way bad". We are making a very, very, dangerous assumption, which is that the mistake was that the person using the method has got the min and max the wrong way round. Consider this code:

int coreTemp= ReadNumber ("Reactor core temperature? : ", 20,40);

This code is asking the user for the reactor core temperature (whatever that is). But what happens if when the method is written the programmer misses out a zero when typing it in:

int coreTemp= ReadNumber ("Reactor core temperature? : ", 20,4);

Now the minimum is much higher than the maximum. If my program swaps these values over it will be asking for a value between 4 and 20, which is much too low and might cause really bad things to happen. The clever swapping trick has now changed a typing error to produce a fault that is potentially very dangerous.

If the method stops the program when it is not used correctly the programmer is guaranteed to spot it. But if we do the swapping thing we could end up with strangely broken programs out there. So I'm very keen to cause the maximum damage when my methods are told wrong things. 

Actually, the best way to solve this problem is to use a lovely feature of C# which lets you name each argument to a method call:

NoOfPlayers = ReadNumber(prompt:"Age : ", min:10, max:100);

In this call of ReadNumber we actually identify each parameter by name, rather than using their position in the list to indicate what they mean. I'm a big fan of naming arguments like this, since it also makes it much clearer to someone reading the code what is actually going on.

First Year Welcome Party - With added Carbonite

We had our First Year welcome party today. In the olden days we used to have cheese and wine. We don't do that any more. Nowadays we have Occulus Rift powered racing, 10 player Xbox mayhem, Wii U, Digital Scalectrix, Xbox One and Rocksmith Guitars. Plus we will also embed you in carbonite, just like Han Solo at the end of Star Wars, courtesy of our Kinect 2 sensor and Ultimaker printers. 

We had quite a few customers for the 3D scanning. In fact we have a whole bunch of models to print off later in the week.

We had two seats set up for racing, with force feedback steering wheel, and Occulus Rift for the view. Great fun.

Thanks to Platform Expos for the use of their console setup.

Rachael came along with her big camera and took some video. The party did get very busy, we had to get some extra tables out when the time came for the quiz. To my eternal shame I didn't get pictures of the winning teams posing with their Nerf gun prizes. Oh well, maybe next year.

I was testing a new version of the TagOMatic to handle the drinks and it seemed to work OK, apart from a few "rogue" tags that seem to have found their way into the system. I'll be using the TagOMatic as the basis of an Arduino talk in the first of the new season of Rather Useful Seminars next week. 

I've put some more pictures up on Flickr, you can find them here. 

Three Thing Game@School Video

Rob Miles, lecturer at the University of Hull, describes the University's 'Three Thing Game @ School' competition which was held on 15 July 2014. The event involved around sixty school pupils wrestling with Python programming and writing games.

On Tuesday Rachel came round with her posh video camera (and tripod) and took a lovely video of the Three Thine Game@School event, which you can watch if you like. Note how I'm heavily channeling my nerd-power, with a pen in my top pocket...

3D Printerns

Mr Burns seems to like 3D printing....

The department is running a new initiative this year. We have a bunch of undergraduate students working as interns for a couple of months over summer. They are being paid to work on interesting projects "just to see where they go". The idea is that this will lead to research efforts and other interesting stuff.  The prospective interns were interviewed a few weeks back and they'll be starting in July. It's going to be fun. 

One area of interest is 3D printing, which is rather nice. It means that the departmental 3D printer (which doesn't have a name - yet unlike Una) will be getting even more use over summer. At the moment he/she/it (really must find a name) is busy printing out parts for our robot army (not sure if I should be talking about that). Perhaps we need another printer. Of course, we'll need another name then....

I really hope that the Summer Interns scheme becomes an annual thing. It provides a great way for students to explore just working with things to see what happens. 

Making Screencasts the Hard Way

Having the house to myself this morning I thought I'd record a video of the 08120 Programming 2 Exam walkthrough. I try to remember to make these when I've finished marking the papers. I can cover lots of the questions that folks might have about the right answers and I like to do this when the marking issues are still fresh in my mind. 

Of course it wasn't as simple as I expected. I hadn't done a video for a while, so I had to find the headphones and the microphone, install Camtasia (my favourite program for recording stuff), find that the headphone and microphone weren't working and that sound playback was also broken. Fix all that, set the screen size to work properly, create a PDF that I can browse through and finally, after half an hour of faffing around, get to sitting down and recording something. 

And I thought that modern technology was here to make life easier....

Pass Student BBQ

I told these folks they'd be in the blog, and here they are.

For the last couple of years the department has been working with students from later years who provide support for the first years. The Peer Assisted Student Support sessions are run by PASS leaders who give up their time to help. Their sessions have proved very popular and a lot of students owe quite a few percent of their grades to the patient support of these folks.

Today, by way of a thank-you, the university organised a barbecue, knowing that one thing that students prize above all others is free food. There were also certificates to be had. From the left we have David Arrowsmith-Cooper, Gareth Andrews, Antony Nunn and Phininder Balaghan. 

In the middle, wearing the suit, we have Dr Richard Heseltine who is the Director of Library and Learning Innovation and University Librarian. Well done folks.

We are presently recruiting PASS leaders for next year. If you fancy having a go, feel free to get in touch.

Banjo Madness

I'm getting a lot of questions about banjos from students at the moment. This is because we are in the final stretch of the assessed coursework for our programming module which involves either creating a management system for a "Banjos for Hire" shop, or creating a game where you have to use your accordion to fight of hordes of invading interstellar banjos by shooting killer notes at them.

Today I got to see some work in progress from some of the students. I saw a Windows Phone game that was pretty much ready to go to market (just needs some sound and it should go straight in the store) and a close to complete WPF implementation of the store. Great stuff. 

Yellow Book now in Spanish

I love it when Amazon send me recommendations for things that I've written....

I saw on Twitter that folks are working on a version of the C# Yellow Book in Spanish, which is rather nice.  

Good luck folks. 

Of Garbage Man and Banjos

This year the first year students can create a game as part of their programming coursework. The game is "Alien Banjo Attack" and above you can see a screenshot of my demo version. At the top are various different types of evil banjo and your mission is to defend the earth using nothing more than your accordion which will shoot notes of music to destroy the incoming swarm.  If the banjos reach the bottom of the screen you lose the game. If you crash into a banjo you lose a life. Space Invaders with a banjo feel. What's not to love?

I want there to be loads of objects (notes, banjos etc) on the screen at the same time, which means a lot of instances of the various classes that represent the game objects. There has been some discussion about the best way to handle this, as banjos are destroyed and new ones appear.

I reckon the best way to do this is to make a banjo stateful. The banjo will contain a flag to represent whether or not it is involved in the game. If a banjo is destroyed this flag set to indicate that it is dead and the banjo plays no further part in the gameplay. When we need a new banjo we just have to find one which is marked as dead and "resurrect" it by moving the banjo to a new position and then changing the flag to bring it back to life. 

You might think that creating new instances of banjos to replace discarded ones would be another way to achieve this behaviour but I don't like that at all. If we start creating and destroying objects this will make work for the Garbage Collector who will have to come in and tidy up memory every now and then which might slow things down a bit. 

Another way to reuse objects would be to keep a list of "dead" banjos. Each time a banjo is killed we move it out of the "active" list into the list of dead ones. That way, if we need a new banjo we just have to look in the list. This is a bit more complicated than just searching for a banjo that can be resurrected, but it does have the advantage that the game never wastes time working through "dead" display objects, as these are no longer in the active list.  Many operating systems use this technique in what is called a "thread pool" where previously used threads are kept ready for use by processes that might need them.

Computer Science and the Hour of Code

Sunday's paper had a big section on how important it is to learn to program. I agree. There was a lot of kerfuffle a few weeks ago when Lottie Dexter, a Conservative activist hired to manage a "Year of Code" initiative, admitted that she didn't know how to write software. Lots of people got very cross about that and they got even crosser when she went on to say that you can learn how to teach programming in a day or so. 

Oh well.  I think/hope that what she meant to say was that you can learn to do something useful/fun with a program and tell someone about it in one day. And I suppose that you don't need to be an active practitioner of a field to promote it. Nobody seems to expect the head of British Airways to be a qualified pilot. 

You can watch the item on Newsnight here. For me the most unwholesome aspect of the whole interview is offhand manner of the interviewer, Jeremy Paxman, who gives the impression that learning how to instruct the machines that control our lives today is somehow beneath him and that's how it should be. Oh well again. 

Of course if Lottie Dexter had said "Learning to program is very hard, takes ages,  and you need an enormous brain to be able to be able to do it" she would have been in about the same amount of trouble. I reckon I've been learning to program for the last forty years or so, and I wouldn't put myself forward as that much of an expert. But I can get useful things done. And I know (mostly) which things are impossible to do with computers.  

For me the important thing about the whole learning to program business is that if you have a go you know what you can and can't do with computers. You get a feel for what is possible and you are motivated to have a go. And maybe you'll like doing so much that you will decide to learn a bit more....

And with that I present "Rob's Things to Do if you want to learn about computers (or indeed science and technology in general)"

• Have a go. Go to the hour of code site and have a play.
• Don't expect to learn everything at once. One of my favourite tweets was from someone who said "It seems to have taken me around 20 years longer than I expected to become a good programmer". It won't take you 20 years to learn how to do be useful with a computer, but just like a great concert pianist is always finding new things in pieces of music and new ways to express them, programming has a lot of art in it and you are always discovering new ways to do things. But you can't ever say you've learned all there is to know about the subject. The good news though is that you don't have to.
• Have an aim in mind. Programming is all about making things. You can't just learn it in isolation, you have to be building something. Set out to make a silly game, a clever web page, a moving robot, a musical instrument or anything that you find fun and engaging.  I'm presently trying to make some remote controlled table lights for a wedding. I've learned about a whole new branch of embedded technology and I'm still finding out new things. I'm having a great time. And I might even make some lights by the end of it. 
• Find friends. Working together is much more fun. You can solve problems by just explaining them to each other. Join a group. Start a group. Look for STEM ambassadors in your area and find out what is going on. 
• Keep it simple. Get something simple working and add things to it. Don't have a huge, complicated idea and then fail to make it work. 
• Remember it is supposed to be fun. If you start to fret about whether you can make your thing work then take a step back, change what you do, or go and listen to music or play computer games for a while and then come back and try again.

I've no idea how my life would have turned out if my school hadn't pointed me at a teletype connected to a computer all those years ago. But I'm jolly glad they did. Perhaps you should take a look too. 

Alien Banjos in Space

This year for the 08120 Programming 2 course I'm providing two coursework options. The first, as chosen by a SurveyMonkey poll, is to create a management system for the "Banjos4Hire", the only banjo hire shop in the country. The second option is a game with the title "Alien Banjo Attackers from Space". The gameplay will involve shooting musical notes at invading banjos whilst avoiding the "strum of death". I mentioned on Twitter that I could use some artwork for the game and I got this sent through from Orb 12. 

Amazing.

Open Day Crew

This is the audience from today. You can see that they are all budding students, as the lecture room has filled up from the back...

We had another great audience for the Open Day today. Lots of good questions, free food and drink, and of course we gave away a Raspberry Pi to one lucky winner.

One thing did come out of discussions though and I thought I'd clarify it here. I put a lot of emphasis on programming in the introductory talk that I do. I see this as reasonable, because a lot of Computer Science is the business of telling the computer what to do, and programming is all about that. 

But what I didn't make clear is that you don't need to be able to program before you start our course. We teach you everything from first principles (and in fact the Yellow Book is written that way) and so if you have never programmed before you don't need to worry. 

One of the best parts of my job is saying to students "You must have been coding for a while" and having them reply "No, I only started learning in September..."