Leeds University at PyConUK 2008

Tony Jenkins and Nick Efford from Leeds University gave an excellent talk at PyConUK on their experiences of teaching Python as an introductory programming language which seems to be very similar to our efforts at Coventry. Tony and Nick managed to raise pass rates, inspire some fantastic coursework, have fun and generally kick ass. Great news for Python and even better news for a future generation of students. You can see some more of their work in ITALICS.

Answering student questions in the classroom

In University teaching, particularly where large classes are involved, and especially in the sciences, asking and answering questions in class raises a number of interesting challenges. Firstly, how to encourage students to begin asking questions in front of their peers (and thereby risk embarrassment and humiliation). This will be the subject of a later blog post, but you can probably imagine a good solution by considering the rather eccentric way the challenge is phrased. The second challenge is how to answer questions from students in such a way that they are encouraged to be curious about their subject. Now because you are an attentive and intelligent reader ... you will notice that we have already rejected a number of positive messages we could aim to send to students. When a student asks a question, we could aim to answer it "well" in the sense of giving the student a clear answer which enhances their understanding of the topic being taught and leads them towards the learning outcomes for the session. This is clearly a Good Thing. Alternatively we could aim to minimise the anxiety of students when they ask questions -- a change in the way the student feels about asking questions. Or, we could aim to encourage the student to continue answering questions -- a change in current and future behaviour. Instead, we wish the student to think of themselves as a person who is curious about their subject. This has a number of advantages which should be familiar to good teachers. A student who thinks of themselves as curious, interested, engaged, hard-working, intelligent, etc is likely to behave congruently to their self-belief by engaging in their studies. This is often something that is evident in mature students who complain about being taught with youger peers, as in "I have come here to work hard on my degree, they haven't!". Such students may not win the Nobel Prize but they invariably pass because they are the sort of person who passes. At least, that's what their self-fulfilling prophecy tells them. Interestingly, many such students were not the sort of people who passed exams in school, which casts a slightly different light on the quote above. Also, beliefs generalise. A person who thinks of themselves as a "good student" is likely to behave like a "good student" in many or all contexts that they find themselves in. A student who acts like a good student is only acting and may stop at any moment. This is what the pedagogical people call "deep learning". Sort of.

In the context of questions the advice often given to new teachers is that "there are no stupid questions". This is the sort of abject nonsense which seems to proliferate courses on how to teach, and we all know that there are many stupid questions, aren't there? That was probably one of them right there. And besides, if there were no stupid questions, what would there be -- stupid questioners, presumably. A good teacher will respond well to student questions whether they are "stupid" or "clever". Anyone with any real classroom experience knows that answering a "stupid" question with a sense of genuine, congruent, sincere respect for the questioner will already get you half-way towards reducing student anxiety and peer-pressure and eliciting questions in the future. Of course, this partly presumes that the student understands your answer, which they may not and it's important to have strategies for dealing with the situation where no matter what you say, the student still doesn't quite "get it". My two favourite responses are to ask the class -- as in "I bet one of you can explain this even better than I can!" -- or to tell the student you will talk to them some one-on-one after the session. The latter needs some careful handling to ensure that this is a clear invitation to have a positive discussion, not a comment on how well the student has understood the teacher. These are both reasonable strategies but you should have at least five good strategies for dealing with this situation.

So, how to answer questions? Naturally you should have several well rehearsed strategies that you can use in different contexts, but let's look at a particular example of good practice. My colleague Bob Newman answers almost every student question with "That's a really interesting question" or "That's interesting" or "How interesting" or some variant. This has a number of useful, interesting and resourceful qualities:

Lack of referential index

"That's interesting" -- what's interesting? The student will fill in the gaps. Usually either the question is interesting or, better still, the questioner is interesting. This communicates a sense of respect towards the student -- an "interesting" question or student is certainly not a "stupid" one.

No reference to modalities

In one-to-one teaching it is useful to pace your answers with the student. A student who sees a problem needs a different answer to the student who can't get a handle on an answer. However, in a classroom context, giving a visual response to a question will only help students with a visual representation of the material. The best possible answers will either lack a clear modality (leaving each student to fill in the gaps) or cover the major three -- visual, kinestetic and auditory.

Vagueness

An interesting question invites exploration and suggests that the teacher (and better still the class) will talk around the topic rather than giving a quick, definite answer.

Another great reason to study Computer Science

Of course, Computer Science is an intrinsically interesting subject, but research has recently shown that switching from Maths to CompSci means you're twice as likely to be getting some.

Programming skillz and games degrees

Bob found a really interesting article on What Game Companies Want From Graduates. Interesting, for a number of reasons, but the one sentence that stands out for anyone teaching programming is this:

Currently for EA, the majority of "open positions for new graduates are software engineering and technical artist roles," though "both require substantial programming abilities."


Programming is, EA say, important both for programmers and non-programmers alike, no doubt for a bunch of reasons ranging from needing to communicate effectively with the whole team to needing to script and extend modelling and animation tools.

It's an important point because applications to core CS and Soft Eng degrees are falling world-wide, with interest in degrees such as Creative Computing and Games Technology rising. With fewer students opting to take A Levels in Maths and the physical sciences the need to develop core technical skills needs to be clearly seen as fun, important and leading to jobs in a way that was never needed by those of us who grew up hacking the Amstrad6128.

How to learn a new (programming) language

Pretty much every programmer that I've ever met learns new languages by writing a number of small programs in the new language, that should show up the major features of the language and enable the transference of skills from known languages to new ones. Here's a list of my favourite small problems:

The basics: choice, iteration, recursion

Factorial function

Factorials are easy, but the trick here is to deal with all the various boundary conditions, preferably using exceptions.

Fibonacci sequence

Generating the next Fibonnaci number has a simple recursive solution and a slightly more complex iterative solution which can show up features such as simultaneous assignment.

The first n primes

Print the first n primes using the
Sieve of Eratosthenes. This is an interesting one -- it has nice solutions both iteratively and recursively. Also, you can do neet things with exceptions to give a solution.

Files and other I/O

Caesar cipher

Read in an ASCII sentence and encipher it with the Caesar cipher (add a key to each letter) and print out the enciphered text. Write the converse function to decipher.

Count the occurances of letter 'a' in a file

Read a file name in on the console, open the file for reading and count the occurances of 'a' in the file. Print the result (and close the file!).

Linear data structures: arrays and so on

Binary search

Look for a value in a sorted structure -- iterative or recursive solutions are both interesting to try out.

Bubble sort

The simplist sorting algorithm, but it should give a reasonable idea of how to manipulate mutable structures, or deal with immutable ones if that's all the language has available.

Modularity: modules, classes, objects, etc.

Sets data structure

Sets are a simple data structure to implement, they're easy to test and a good instroduction to polymorphism. Union, difference, intersection, etc. all make useful methods and you can play about with mutable or immutable sets and see the difference.

Why Linux is such a great choice for multimedia computing

All about Linux has a great post on the use of Linux in the film industry. Check it out!

GUI programming basics 1/3

This is the first of three posts on the basics of GUI programming. This post covers the most fundamental of GUI concepts with some example code to illustrate them. The next post will cover some more complex issues (in particular, layout managers) and the final post in this series will contain an extended example -- a simple text editor.

GUI programming is a bit of a black art. It sits on the interface of prgramming and HCI and usually requires careful planning (for usability) and relatively, but not very, sophisiticated programming techniques (meaning we don't teach it in the first year). Generally, GUI toolkits make good use of objects and to learn a new toolkit you need to understand a whole bunch of GUI jargon. Conceptually, there's not a lot new to learn when it comes to writing GUIs. If you already know about objects, OOP and event loops then you've learned most of what you need, the rest is just jargon and libraries. So, first to the jargon, then we'll look at some code. The following is a brief glossary of GUI concepts, in alphabetical order:

Binding:

Binding is the process of associating an event (such as a key press or mouse movement) with a callback or event handler. For example, we might bind the key accelerator Ctrl-S with the callback onSave.

Callbacks (or Event Handlers):

A callback or event handler is a piece of code (usually a function or method) which is executed when an event occurs. For example, an callback called 'onQuit' may be run when the key accelerator Alt-F4 is pressed by the user. Note that callbacks are written by the GUI programmer but scheduled to run by the toolkit -- i.e. you don't usually have to write your own event loop!

Containers:

A container widget may have other widgets embedded within it. For example, a top-level container for an application may contain a menu, statusbar, toolbar and so on.

Events:

An event is usually some form of input or interaction that occurs externally to a GUI but can be detected by the GUI toolkit. Examples include keyboard key presses, mouse movements and button presses, drag'n'drop, and so on. Most events will be uninteresting (e.g. mouse movements) but some require a response from the GUI (such as button presses and key accelerators).

Event Loop:

A loop which is used to dispatch callbacks in response to events. Usually the event loop for a GUI is provided by the toolkit and doesn't need to be written from scratch.

Widgets:

A widget is a single element in a GUI and in OOP languages is usually an object. Example widget types are: label, button, text entry field, canvas (to display graphics), list box, scroll bar, radio button, etc.

Simple GUIs with Tkinter and Python

Tkinter is the cross-platform GUI toolkit which ships with Python. It's based on the Tcl/Tk system and it's popular because of it's simplicity. Other toolkits are a bit more sophisitcated (like, wxPython, based on the C++ toolkit wxWidgets) but are also more complex. So, Tkinter is a good place to start if you haven't writen GUIs before, but you might want to look around at other libraries when you're a bit more confident of the basics.

What follows is a very simple series of 'Hello World!' scripts which introduce the very basic concepts of GUI programming by producing minimal GUIs. The next post on GUI programming will introduce some more complex practical concerns -- various widget types, layout (geometry managers), and so on.

Hello World! (1)

This script is absolutely minimal. It simply creates an empty application window (called root) and instructs Tkinter to start it's event loop.

#!/bin/env python2.4

"""
Hello World! with Python's Tkinter GUI toolkit.
"""

from Tkinter import *

__author__ = 'Sarah Mount'
__date__   = 'October 2006'

root = Tk()
root.mainloop()

Hello World! (2)

An empty application window isn't much use! The next script creates a single widget, a label. Labels are holders for text. They generally don't do anything (unlike, say, buttons) so they are really the simplest widget around. In our case, we just want to create a label, pack it (meaning, arrange it on the main application window) and start the Tkinter event loop.

#!/bin/env python2.4

"""
Hello World! with Python's Tkinter GUI toolkit.
"""

from Tkinter import Label

__author__ = 'Sarah Mount'
__date__   = 'October 2006'

# Create a widget
widget = Label(None, text='Hello World!')
# Arrange widget in application window
widget.pack()
# Start GUI event loop
widget.mainloop()

Hello World! (3)

Our third version of Hello World! introduces callbacks. Here, we use a button widget rather than a label. When we create the button, we need to give Tkinter a reference to a function which can be called to handle mouse click events.

#!/bin/env python2.4

"""
Hello World! with Python's Tkinter GUI toolkit.
"""

from Tkinter import *
import sys

__author__ = 'Sarah Mount'
__date__   = 'October 2006'
 
def quit():
 print 'Quitting...'
 sys.exit()

widget = Button(None, text='Quit Hello World!', command=quit)
widget.pack()
widget.mainloop()

Hello World! (4)

This last script is essentially the same as the last, but makes use of a lambda expression in the callback. This is a common technique and although it's rather pointless in such a simple script, lambdas are a great way to cut down the size of your code whenever you need a simple function call in an event handler.

#!/bin/env python2.4

"""
Hello World! with Python's Tkinter GUI toolkit.
"""

from Tkinter import *
import sys

__author__ = 'Sarah Mount'
__date__   = 'October 2006'

def quit(msg):
 print msg
 sys.exit()

widget = Button(None, text='Quit Hello World!', command=lambda: quit('Quitting...'))
widget.pack()
widget.mainloop()

Further reading

• Python's Tkinter toolkit: http://wiki.python.org/moin/Tkinter


• GUI programming in Python: http://wiki.python.org/moin/GuiProgramming
  

Cheat4Success! How to cheat a Computer Science degree

Every time lecturers mark work, there is inevitably an amount of time spent dealing with plagiarism -- detecting it, checking sources, dealing with the resulting paperwork, and so on. With cut'n'paste making cheating ever easier, it seems that plagiarism will never completely disappear.

Cheating, in this sense, means taking credit for someone else's work. It does not mean discussing ideas with friends, making use of someone else's (abstract) ideas or choosing to do the same homework as someone else. It does mean downloading someone else's work and passing it off as your own. In work, this is professional (or gross) misconduct and would get someone sacked. At University (and Schools, presumably) it's treated seriously, but expulsion is not usually the first line of punishment.

Of course, this is totally unfair, right? Most students don't cheat, most students want to get a degree and take some pride in their work. However, more and more time is spent with the few percent who cause trouble, which wastes time, (public) money, energy, devalues good degree courses, causes apathy in both students and staff and is generally a complete pain. That time and money could be much more usefully spent helping students who are engaged in their work to do a bit better, rather than in policing a small number of students who cheat. So, in light of that, this is my guide to cheating and cheating well (4success!) on a Computer Science degree. If only students cheated better, no one would catch them out and any effort put towards dealing with plagiarism could be so much better spent.

1. No one else can use Google except for you.
You've probably figured out that many programs exist on the Internet and can be downloaded. Also, many people put their homework online and you can get hold of that too. There are only so many ways to teach any particular topic, so probably the questions you're set have been set elsewhere already, so the answers are out there for you to see, copy, paste, and claim as your own. Fortunately, students are the ONLY people able to use Google for this purpose. Your instructor cannot possibly google for the work s/he has set, certainly won't find the same links as you and (thanks to the genius of those guys at Google) is physically prevented from finding out how you cheated.

2. Mix your sources.
Some things in life are better mixed. Drinks, for example. And the same is true for sources. If you have an instructor who is particularly persistent in tracking down cheats, it's better to cut'n'paste code (or text) from as many different sources as possible. This way, even if you're caught, you've wasted as much time and public money as humanly possible. Also, as your number of sources tends to infinity, your false claims of ownership cease to be cheating and become research and everyone knows that lecturers love research. For top marks, you should find at least 20 different sources to copy from.

3. Change variable names
One of the nice things about programming (rather than wussy subjects like history) is that two programs are distinct and different if they differ by only the names of their variables. It doesn't matter if every single part of the two programs is identical, including the comments and whitespace. If you really want to cheat4success, you need to take someone else's code, change the variable names and Ta-Da! it's a whole different program. Then when your instructor challenges you, you can just say "Ha! Those programs are different, they have different variable names!". And your instructor will be dumb-founded. The posh word for this is "alpha-conversion". Which is to do with lambda calculus. Which is clever. So, now you can not only cheat well, but justify what you've done with Big Words. Even better!

4. Hand in code which doesn't work.
One good trick is to download someone else's code and break it. Now you can play a particularly clever ruse. Your code is broken, it can't possibly be someone else's code -- after all, why would anyone put broken code up on the web? So, it's just a coincidence that (apart from the small changes you've made) your program is identical to a published one. For best results, change filenames and libraries.

5. Copy from your lecture notes.
That's not plagiarism, it's flattery. Your lecturer won't be able to resist.

6. Deny the laws of probability.
If the worst happens, and despite following this guide your lecturer still suspects you've cheated, then the worst mistake you can possibly make is to appear rational. So, refuse to see reason, don't engage in meaningful dialog and certainly don't be honest (after all, that rather defeats the object). Your lecturer might want to engage you in strange thought experiments like "What's the likelihood of your submission being identical to that one. Oh, it's 1/10^googol. And 10^googol is more than the number of atoms in the Universe". Everyone knows that statistics lie. Don't be drawn into the discussion.

7. It weren't me 'guv.
no one can resist your charming smile. Just grin widely, tell your lecturer that you wouldn't dream of doing such a terrible thing and you'll be fine. If that doesn't work threaten formal complaints, litigation or the breaking of limbs. Works every time!