Sunday, 12 July 2009
Shift LIfe
Sam Moore, Eugene Ch'ng, Dew Harrison, Mat Murray and I have been working on a pervasive interface for an artificial life simulation. At the recent Shift-Time festival in Shrewsbury we exhibited an artificial life simulation of an fictional ecosystem, projected onto a sand pit. People could change the behaviour of the creatures in the ecosystem by changing the environmental conditions of the system. They could make the sun shine more or less by playing with a lamp, increase the
humidity or change the pH by pouring in water, vinegar or soda mix from watering cans or cause an earthquake by hitting the side of the sand pit with a toy hammer.
We had really good feedback from the people who came to see us. One family came back on the second day because their three children were talking about it "all night". Typical comments from kids were "I think it's cool" and one kid left saying "well, you've got to be impressed with that", which made us laugh.
More info and an interview with Dew can be found here:
[Event listing] http://www.shift-time.org.uk/events/shift-life.shtml
[Interview] http://www.shift-time.org.uk/video/video-shift-life.shtml
Saturday, 13 September 2008
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.
Saturday, 17 March 2007
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.
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.
Thursday, 28 December 2006
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.
Wednesday, 11 October 2006
Sunday, 1 October 2006
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):
- 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.
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!
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
- GUI programming in Python: http://wiki.python.org/moin/GuiProgramming
Python's Tkinter toolkit: http://wiki.python.org/moin/Tkinter
Sunday, 10 September 2006
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!
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!
Subscribe to:
Posts (Atom)
