I had a great time teaching some digital stuff today. I said at the time that I’d put the slides and stuff up on the internets, and here it is.
I also mentioned some links to useful Karnaugh Map videos, they are here:
Steven did a project which involved getting swarms of robots to push a box around. This is a picture of a swarm of robots pushing a box around. I think we can call that a win. Unfortunately I haven't got any pictures of the Jousting Robots that Jason made, but he does have a video where one of them crashed into the other one and broke it, which I think also counts as a win.
[Click through the picture for the full 360 degree lecture experience]
Sometimes I get asked about exam technique. What's the best way to deal with an exam? What should I do to prepare? My advice is quite simple; try to get yourself into a situation where you know the answers to the exam questions.
Today we had our revision lecture for our First Year Programming module. I went through all the questions from last year and didn't quite give the answers as such. I was more interested in charting a path that will get you to the answer from first principles. I'm quite calculating about this. I'll try really hard to give some solid hooks that you can remember, and will start you off to the answer.
Compostition? That's a car number plate. Throw away the numberplate and the numbers go away too.
Agregation? That's a football team. If we disband the football team we don't kill all the players.
I feel a bit guilty about saying "and the way to remember the triangle on a class diagram is to think of granddad dying", but I was trying to get people to think about inheritance....
The aim of all this is to make exams useful for teaching, as well as our assessment mechanism. In a week or two's time I'll find out if it worked.
We were back in the department, marking today. We are using the latest version of my Magic Marking program, which now has a search so that you can easily find the student you want to mark. It automatically opens the student submission, builds the marking spreadsheet and puts everything in the right place for returning to the students when the marking is complete. I saw some really nice great too, which was nice.
James came to see us today, which was rather nice. We got to talking and the subject turned to the gulf between studies and real life, and how to narrow it.
One of the things that we try to do in Hull is to tell people useful stuff that will they can use to get by in life as a developer. A problem that we have is that people think that the only use for the stuff that we are telling them is in exams and assignments to get a good mark. This is a good thing as far as it goes. And of course you should do this. We have to do the grading thing to ensure that the learning outcomes for our courses have been met.
But we really, really want people to carry those skills into the next (and indeed every) thing that they do going forwards. We're trying to start you building skills that will carry you through your professional career. I don't think you can ever say you've learnt something like programming because, if you do it properly, you are continuously learning. And you should never stop.
The good news for me is that we do get a few folks who go out into the big wide world, and come back and say "You know, that stuff you taught us turned out to be quite useful".
Who'd have thought?
Anyhoo, James is very keen to come back and do some Rather Useful Seminars on what you can do as a student to build on what you're taught, which is great. Stay tuned.
Kevin and I are just putting the finishing touches to the assignment for Programming 2 for this year. We always set two different scenarios, one a game and the other a line of business app. For the game we are doing "Cross Country Ski Race". For the line of business app we are doing "Cross Country Ski Race Manager". Almost like we have planned it.
For the game, players have to steer their player down an increasingly tortuous ski run, avoiding the deadly, and somewhat improbable, "horizontal avalanche" that seems to have erupted. Fortunately an explosion at a nearby cheese mine has left their path littered with life giving cheese which they can use to recover their strength.
For the manager application they have to track competitors, generate reports and produce a fully tested solution. Should be fun.
I put some of my lectures up on YouTube last week and it was great to get a comment on one of them. Kostas was wondering why I spend so much time explaining how static works, and even dragging the Planet Jupiter into the explanation, when a memory diagram would do the job much more efficiently.
Well, yes and no.
The problem with diagrams like these is that people think that they just have to learn the diagram to pass the exam and therefore pass the course. But I don't want them to do that. I want them to know what "static" means, and when to use it in a program.
I use Jupiter as a context because it might stick in the memory. It turns out that the planet puts out a lot of radio static and that static on the radio is kind of like an echo of the big bang. So it has always been here. Just like static members of a class. They don't need instances to exist. As long as the class exists, the static members exist. So you can use static methods to perform tasks without needing to make an instance (for example data validation) and you can use static properties to hold values that need to be stored once only for the class.
My idea is that folks can go from Jupiter, to static, to always here, to methods and properties and they'll have a handle on what it all means and how to use it. Which I think is better than a diagram.
I've started recording some of the first year lectures as screencasts, Just to see how it turns out. I joked with the class that I'd only tell the people that came to the lectures where the videos are, but this is probably not very helpful. Anyhoo, you can find the first one here and I've set up a channel here for the rest. They're a bit rough and ready, being recorded straight from the Surface using Camtasia and the built in microphone, but they might be of interest to C# students at Hull.
I'll keep posting them for the rest of this semester. The only slight snag for me is that it takes around four hours to render each captured session so I've got to create a workflow that I can use to do this.
The department is trying something new this year. Each of our Final Year project students is being asked to give an interim demonstration of their project to their second supervisor at around the project mid-point. The students see a lot of their first supervisor, but they don't usually see the second supervisor until later in the project, when they are involved in the final viva and the assessment.
This year I'm getting to see all the projects for which I'm second supervisor. I wasn't convinced at the start, what with the nightmare of fitting a whole new bunch of meetings into an already crowded diary, but I must admit it has been really useful. I've seen some really great work, and some that could be made great by a strong focus on the important elements.
When considering things like this I'm much more impressed by an "end to end" demonstration of a working system with "n" features than a half-way demonstration of a system with "n*2" features. If you are making a game, it should be playable all the way to the end, with a high score table and a chance to play again. If you are making a product you should be able to run through an entire scenario of whatever transactional behaviours the product provides. If you are performing research you should have the theory, the things you are going to do to prove/disprove the theory and some outcomes to look at which drive the conclusions. And it is worth trimming the scope so that you can achieve this.
Writers have this thing where they talk about "killing your favourite children" which means that they have to discard a great piece of text out because it doesn't actually add anything to the work. The text might be funny, or poignant or interesting - but if it doesn't fit the context it has to go.
During the meetings we were encouraging students to take a look at their projects and do something similar. This isn't to say that they should not get credit for work that doesn't end up in the finished deliverable. My advice is to write these up in the report and then document the process by which you decide to leave them out in order to focus on the core of the work. In fact, I reckon that getting a handle on your project and dropping features that will make you fail is actually strong evidence of real professional ability. And in real life you can always save these for version 2.0 anyway.
I've been giving awards for the best performance in First Year labs and exams. Last week I gave awards to the top five or so exam scores. When it came to the practical work I had a bit of a problem, what with ten students getting 100% in the work - which is awesome by the way folks.
Anyhoo, it means that Una the 3D printer has been busy for a large chunk of today dropping out perfectly formed pieces of green cheese for next Monday's lecture....
We had our big First Year exam this morning. Around 250 students took the exam at the same time. Thanks to Septa, Amadou, Kevin, Nicholas, Xinhui and David for helping to run the affair.
Before the exam I carefully wrote a briefing document and made sure that everyone knew the username and password to unlock the test. Bearing in mind the Yellow Book theme this year I thought a username of "bananas" and a password of "custard" would work well.
Thing is, that's not what I typed in the briefing document. I missed the s off bananas, and so people were tying to start the exam with a single banana. Which didn't work. Fortunately I'd also put my phone number in the briefing document, so as soon as the exam started my phone lit up with folks ringing through from the exam locations around camps. We sorted out the problem in double quick time and everyone was able to get on and answer the 50 questions.
... at a secret rocket and cheese production facility in the North of England....
... I'm making special "Space Cheese Mining" marker awards for all the folks who helped out with the First Year marking this year. I'm going to give them to Kevin, David, Phininder, John, Bailin and Brian to say thanks for their assistance in giving all of our students a great assessment experience and some splendid feedback. Guys, I'll have them for you for Monday.
For me, there's nothing quite like marking a nice looking, well structured piece of code, giving a good grade and then asking the student "So, when did you start programming?" and then having them tell you that they started in September this year.
At this time of year we do a lot of assessment of our students. This week I'm going to be spending the best part of four days in the lab with a bunch of my colleagues, pointing at bits of code written by students and asking "What does this do?". Great fun.
You might think that we do the assessment so that we can give the students grades. True enough, but to me the assessment is more important than that. We also want to have a framework in which we can talk to each student about the programs they have written, and how to make them better. The marking scheme provides lots of hooks we can use to hang discussions about good program design, documentation and testing.
By the end of each marking session the student will have a number and hopefully they'll have learnt a bit more about software development. Which is kind of the plan.
I've been teaching programming for a very long time. I'm still waiting to get properly good at it. In the meantime I'm given to thinking about what it means to learn how to program. I've narrowed it down to five "knows".
- Know what the computer does.
- Know how to create a program.
- Know how to automate a task that you yourself can perform.
- Know how to think like a computer.
- Know how to structure and manage your solutions.
I've been teaching the First Year course for the last few weeks and I reckon that we are at level 3 at the moment, moving on to level 4. This is a crucial time.
At "Know level three" you can take something you would be able to do yourself and write a program do perform that action. One example we do is deciding whether or not you can see a particular film. If your age is lower than the rating for that film, you can't go in. When you write the program you can imagine yourself selling tickets and deciding whether or not people can come in.
Level 4 is quite different. You have to let go of how you would do a task and try to think how you could make a computer do it. Sorting is a classic example of this. If you gave me 20 numbers to put in descending order I'd be able to do it, but I'd not really be able to tell you how I did it. To write a program to sort 20 numbers you would make it do the task in a way that a human never would (for example bubble sort). This is the hardest part of programming. Up until you hit level 4 you can think you are doing very well. Ifs and loops make sense, as do variables. And you've even written the odd program. And then wham, you suddenly find that you can't do it. And I mean really can't do it. This can be very painful and demoralising.
Today I did a tutorial with the students where we explored the transition from level 3 to 4. The best advice I have on this matter is not to stress if the penny doesn't drop first, second or third time. Don't think of it as a technical problem (I must re-read my notes so that I understand arrays better) but think of it as a "way of thinking problem".
Work with what you know a program can do (stash things in arrays, get them back, work through elements, compare values and do things with them etc) and then try to figure out how these abilities can be used to solve the problem.
Consider lots of related problems: find the biggest item in an array, find the smallest in an array, count how many times the value three appears in an array etc etc and notice how fundamental behaviours (working through the elements of the array in sequence) can be used to solve a whole class of problems. Don't worry if your answers seem complicated to you. You get better with practice, and some things are just tricky to do.
I learned to program a long time ago, but I still remember the worry of "What if I don't get this bit" every now and then. Your best bet is to start early, find friends to discus it with and keep the focus on what you are trying to do. And you'll be fine.
On the face of it the video games Animal Crossing Happy Home Designer and Sunset Overdrive don't appear to have a lot in common. But in one respect they are quite similar. Both make complex demands of their players. Games now have to deal with the fact that rich, complicated gameplay makes it necessary for the player to know stuff.
When I played Sunset Overdrive a while back I was impressed with the design of the tutorial levels and the lengths that the game went to as it made sure you new what all the weapons did and how and where to use them. There was also a well managed introduction to the overall plot and the characters. Playing Happy Home Designer (a fun little title as it turns out) I had a very similar experience. As a player you have to learn how to work in the various design scenarios and this is very well introduced into the narrative.The game even has a cash based system that you can use to learn more things in order to unlock new abilities.
People have been going on about game based learning for years. It's interesting to see that the game makers are getting good at putting the learning into their games too.
One of our ex-students, Josh Naylor, now works as a Developer Evangelist for Unity. He's written this rather nice blog post that sets out how to succeed as a student, which you can find here. Well worth a read. And there is no truth in the rumour that I only mentioned his post because it mentions me. None at all.
If you fancy getting to grips with Windows 10 Development (and you should) there's a new set of videos and samples that you will find very interesting. One of them shows how you can write programs that connect to the Marvel Comics database, which is awesome.
Find out more here.