The new curriculum and web science

There have been many arguments over the new computing curriculum. The more I look at it, the more concerned I am that it appears narrowly focused on programming, whereas computing can involve so much more.

One case in point is the course I’m currently studying at FutureLearn, the Open University’s contribution to the MOOCs (massively open online courses) currently sweeping the web. This particular course, sponsored by Southampton University, is called Web Science: how the web is changing the world. It looks at the effects the world wide web is having on society, and how we have influenced the web.

The topics it covers are ones that are important to understand, and that I spent time in the classroom trying to get across – that technology is new, but pervasive, and affects our lives in more ways than we can imagine. In fact, the same topic is covered in a book I’m currently reading in order to review: Digitized: The Science of Computers and how it shapes our World.

If children are truly to understand the importance of coding, and to be able to express themselves effectively using digital media, then they also need to understand the deeper concepts of computing, for example how it can help us to build a better world, and to better understand our own minds.

I’ve been quiet lately on here lately, as I left my teaching post in July. After a break away from classroom technology and learning for a bit, I’m getting restless and I’m starting to look for ways that I can help schools make the move forward from office-based computer skills to real computer skills. If anyone has any suggestions – or anyone in the Canterbury, UK area (or online) would like practical help – then please do get in touch. I will be resuming my quest to produce teaching materials in January, but not being in a classroom regularly makes it harder to keep up with the practical side of things.

Incidentally, there’s another MOOC coming up that ICT teachers really should be seeking out: Teaching Computing part 1 (part 2 to follow) from the University of East Anglia, which aims to prepare teachers to teach the new computing curriculum in both primary and secondary sectors. The course lasts for 4 weeks and is expected to take up around 4 hours per week, but of course anyone seeking to teach computing should be prepared to devote time to it – my biggest fear is that computing will go the way of ICT, with too many non-specialists stumbling through and not giving the subject the rigour that it deserves.


Python at key stage 3

a simple programI recently had the pleasure of introducing some year 8 and year 9 pupils to Python. They had previously dabbled in Scratch, but the idea of writing formal text-based programs was new to them, so we took it slow and steady.

The first lesson was mostly taken up with getting to know Python – we started by typing commands directly into the shell, and then they learned how to open up a new window, type a simple program into it and run the program. By the end of the first lesson they could type up print statements and simple maths statements into a program listing, save it correctly and run it.

Lesson 2 introduced the idea of variables and input. I reminded students at the beginning of the session how to start up a new window and create a program rather than type into the shell, and how to save their program with .py on the end to conserve the colour coding. They were also starting to discover the pleasures of debugging, and learning to look carefully at their code to spot errors. They helped each other out with this, and I showed them how to check not only the area of code that Python highlighted as a concern, but to check just before it as well, as often the error was missing speech marks or closing brackets.

Lesson 3 was where the real fun began, as we looked at if statements. Combining these with input meant that we could create a question and answer program, and combining that with a variable called score gave them the option of creating their very own quiz. Reactions varied, as some struggled to get their program running and grew frustrated while others started to really fly, creating inventive listings that checked for a user name and password before allowing access to the quiz. Generally, they seemed to enjoy the sessions, and my favourite reaction was that of frustration expressed as the code refused to work, followed by that surge of satisfaction and achievement as the error was spotted and fixed.

Our work developed by way of writing programs to solve problems, and for this I used my flash resources. This had the advantage of offering different levels of challenge and support, so that those who were able could work at a higher level while I could help those who were really struggling. By the end of the sessions all students understood a little more about how programs are made and they had learned that little details like capitals and spelling really matter. Most were starting to see how their program worked and how to fix errors and develop the functionality, while a small number really enjoyed the unit and were starting to come up with their own ideas and solutions.

This was only a very brief introductory look at programming, but it was enjoyable and worthwhile as a taster of computing rather than ICT, especially for those going into options, and encouraged students to think carefully and increase the accuracy of their written work. I saw expressions of satisfaction from both ends of the ability level, as those who struggled finally got something working while those who experimented showed off what they had managed to work out for themselves. Students whose first reaction as “This is stupid” moved over to “Oh, I see what the problem is”, as they learnt that the computer would do exactly what was it was told to do, and discovered for themselves the harsh realities of Garbage In Garbage Out. Even if they never see another Python statement, I believe they’ve taken away the understanding of how carefully you need to express yourself in order to be properly understood and how accuracy leads to better results.

As a result of my experiences I’ve developed a workbook and some flash resources, which you can find on my website here.


on computers and female geekism

computer kit with lots of components

build your own computer kit

I and most of my family headed to Margate today for GEEK 2013 (Games Expo East Kent). I and one son went last year and enjoyed the talks and discussions that took place. I was disappointed that there didn’t seem to be scheduled talks this year, and I felt the whole event was much more about looking back and being a games consumer than looking forward and being a games creator, whereas last year the balance was better. Still, there was the main hall full of games consoles for people to play (didn’t spot any ZX81s this year, but spotted a couple of BBCs and Commodores with things like 10 John was here 20 goto 10!) and the upper hall with stalls and exhibitions.

Youngest son enjoyed the halo and minecraft most, of course. Hubby and I found more of interest in the upper hall, where alongside the cosplay there were also electronics demonstrations. The Pi and Arduino workshops turned out to be a couple of people showing what they were and promoting them, and I had an interesting chat with one man about computers and schools and programming and electronics.  There was also a gentleman selling kits to build your own computer. The kits cost £20, and the end result was a tiny circuit board, smaller than a pi or arduino, that included a fully working keyboard (8 keys), plugs into a TV and can be programmed to produce simple games – think of a ZX81 DIY kit, but much smaller.

We decided to buy two, one each, and left the man with our padded envelopes full of components. The instructions are available via the website, and there is also a support group who we are told are active in producing listings and ideas.

Expect to read more about this project over the coming weeks as and when I get a chance to build it and play with it, but the other thing that struck me during the day was how male-oriented the event was. Everywhere you looked, there were boys crowded around screens, playing, watching, discussing, and females were definitely in the minority. There were a couple of talks in the end, unadvertised but announced on the day, one about the history of games and promoting the speaker’s book, and another from a couple who were promoting their film on the games industry in the UK, and through those there was also definitely the message that the games industry is dominated by men. (There was another unadvertised talk, too, a Q and A with indie games developers, but that was scheduled at the same time as the movie talk, which was rather irritating as I would have liked to attend both.)

So why is the computer industry so male orientated? This was something I pondered as I returned to the house and sorted out making tea and organising the washing machine and dryer, pottering around doing various household tasks before finally managing to sit down and get the laptop out.

Is that part of the reason? That the boys who dabbled in computers grew up into men who dabbled with computers, while the girls who dabbled grew up to take care of the house and children and had no time left for playing? That the boys are eager to try things, and the girls much more likely to step back and watch them? The same thing that makes men more likely to figure things out for themselves and women more likely to ask for help? The same thing that makes men more likely to be competitive and women more likely to be co-operative?

Is this innate or is it culture-related? While men are those making games, they will make games that appeal to men, which means men are more likely to want to enter the industry and make more games. While women are content to step back and let the men get their way, how can they change things?

When I studied a foundation course with the open university, as part of the science module we learnt about how it was not until women joined the scientists that a whole new side of the way gorillas behaved was recognised. In the same way, it’s not until women really push themselves into the computer industry that the industry will grow properly and become more balanced.

The idea of introducing computing right from the start of the educational progress is a big step towards that, if done in the right way: if we can introduce it in a way that doesn’t alienate half the population. In the same way that we need to get over this “cool to be useless at maths” attitude, we need to get over the “I can do email and facebook, what more do I need” attitude about computers.

Getting back to the kit, I feel like I’m on a quest to find out how computers really do work. The programming side is straightforward, and I understand the theory/software side of things. What I don’t understand is how the hardware makes these things happen. That’s part of what my electronics experimentation is about, and I welcome this chance to take my knowledge back a stage further, but at some stage I still want to know how the software is acted on, how the processors themselves work.

In the meantime, it’s back to school next week…


codeword success

codeword gui version 1

first idea for a GUI

It only took a screenshot of my project in action to put myself back on the right path, and a very pleasant afternoon was spent adding the last piece of functionality to it – as a reminder, it’s a program that allows me to enter the settings for a codeword grid, which is a puzzle that looks like a crossword but with number standing for letters. The user tries out a letter in place of a number and eventually solves the whole puzzle, with each number representing a different letter. My program does not create or provide puzzles, but instead you can use it as a tool to help solve commercially available puzzles, to save scrubbing out incorrect guesses.

I had got it to the point where it would display the grid in the console and accept changes via direct entry in the console, so what was left to do was to provide a list of what letters had been used already and to not allow the same letter to be used for two different numbers.

Writing code for the list proved to be straightforward – rather than delving into different data types and debating which was best, I opted for a simple list, with the first entry at index 0 set to “*” and the rest of the entries set to ” ” (space). Adding a letter for a specific number then involved setting the list at that index to the letter, and resetting involved setting the entry back to a space.

I could then call these list functions as part of the setting and resetting a letter, and check whether a letter had been used already before allowing it to be entered into the grid.

My code at the moment has very little help for the user (hence part of my problems yesterday!) and it has very little error checking for input, but neither of these is a real issue as the intention is to put a GUI on the front of the code, to handle display and entries.

And here I hit the next issues: issue one is how to create a GUI in python and issue two is which editor to use to create it.

The book I’ve been working from suggests pythoncard, but I have not been able to install this successfully. I’ve managed to establish that Tkinter is already available as part of the python standard library, but it carries a warning that it will not run with the basic python IDLE, as that does not handle events properly, so that then leaves me looking around for an editor that will do the job.

I enjoy working with the IDLE, as it’s incredibly straightforward, and I object to using more time figuring out how to use an editor than I spend actually coding. I’ve got Eclipse that I’ve used for Java, and I’m currently looking into using that with a pydev plugin, but I’m starting to get frustrated by all these different options, which all seem designed to provide high levels of support with very complex projects and make life very complicated for the casual user who just wants to create a simple project.

The other IDE that I’m trying out is Geany, which I recognise as the software that originally came on my raspberry pi, and so I have used already for python. I’ve got it running with my codeword software, but when it gets to the end of the program, which goes as far as creating the grid, the program then seems to terminate without allowing me to enter further commands via the console. If I can put a GUI onto the program, then the console won’t be needed anyway, but it’s just another frustrating step.

I think with fondness of the days when I learnt programming, when we used C++ with an IDE that allowed us to design a GUI and attach code to it really easily. Even the Java editor we used back in those days seemed far more straightforward, even though I never did really get the hang of the different containers that you could use for java layouts.

Surely these things should be getting easier, not more complex?

Incidentally I’m now running a log of my project, with notes for each version change on what I’m attempting to do. Each feature is being developed piece by piece, with constant resaves as different versions – all versions ending in 4X are the basic version, while 5X added in the list and 6X used the list to check whether the letter was available before using it. I’ve also included screenshots of the project in action and a first sketch of what the interface might look like.

Hopefully if I end up leaving the project again for an extended period (for example while I build up my GUI skills) this log will make it much easier next time to pick it up and catch up with progress. I can’t say I understand every line of the code I’ve written or could duplicate it easily, but at least I know enough to know what it does and how to use it, and which functions are available.


Picking up the pieces

codeword throwing an errorIt’s been a while – a hectic six weeks of term, until finally we’ve reached half term and I have time to try to pick up the pieces of my technical developments and see if I can make progress with them.

I left a few projects hovering: there’s the virtual pet that I started in Scratch and app inventor, the Simple Simon game that I made in Scratch and started to convert to app inventor, the general learning I was doing with Python and the codeword project that I started in Python.

It was the codeword project that’s been my ambition for longest, and the project that I remember as the furthest developed, so that’s the one I’ve opted for first. And there I hit my first problem.

Just in trying to pick up the pieces of this project, I’ve learned several things: that it’s really hard to pick up a complex project after so long, that without any real structure it’s difficult to pick it apart and get an overview, and that with no log of changes it’s hard to even find which version to use! I’ve got versions of the file from codeword to codeword6, plus codeword4a and codeword4b. I’ve gone back to codeword4b, as that contained a note saying it was the latest – but of course there’s nothing to say I didn’t progress further and just not remove the note. I remember the project being workable via command line codes, but now it doesn’t seem to respond to even the simplest of commands.

This blog is probably the place I’ve documented my project the most, so I guess I’ll have to read back and see if it’s any help. In the meantime, I really need to pick the code apart and understand it thoroughly, and produce some sort of map or algorithm so that I know how it all ties together – although algorithms/flowcharts become rather complicated when they’re event driven rather than procedural!

In the meantime I’ve learnt that even the most straightforward of projects needs to be thoroughly documented and planned before coding, and that actively writing and testing code is just a small part of any software project. Managing your code so that it can be easily understood and followed, and leaving some sort of explanation to progress, and building in error checking are also incredibly important.

I’ve also proved the point that software needs concentrated effort to get to grips with, and picking it up only for a short while can be counterproductive, as it can take so long to catch up with where you were that you never actually have time to make proper progress. On the other hand, maybe  little and often isn’t too much of a problem – but little and seldom definitely is a no-no!

A change of strategy

We’ve been plodding along for a few weeks now with Python, and a few boys in particular have amused me with the way they’ve played with the code we’ve used, particularly input and loops:

Enter password:

Wrong password, this computer will self destruct in 10..9..8..

Downloading virus…

downloading virus…

downloading virus…

We also had some fun with making the computers beep (thanks codeboom!).

But overall it felt slow, and some of the lower ability kids were finding it hard going.  Bear in mind that this cohort has done very little coding previously, if any at all, and they’ve been finding it very difficult to think in the logical way needed to build up algorithms.

So this afternoon we tried out Greenfoot.  I had originally considered it as a learning tool, but rejected it because coursework for GCSE seems console-biased, and it seemed any editor that would edit Java to run in the console seemed unnecessarily complex for our use.  However, I became interested to see what the kids would make of it.

We started with Mik’s videos, and soon we had turtles crawling and spinning merrily on screen.  The students who had previously seemed to lack motivation started experimenting and playing, and by the end of the lesson, curses over brackets and semi-colons aside, all agreed that they would like to see more Greenfoot.  Most importantly, they had experienced the wow factor that I had felt was lacking previously.

Scratch is misleading, in my opinion: it looks as though it’s designed for younger kids, and it’s very easy to click blocks together and do something, but in fact it can get very complex very quickly when they want to do something specific, and it can be frustrating when they see all the blocks there but don’t understand how to use them, especially when their perception is that it should be easy because of the child-like design.

Greenfoot can be just as complex, but it’s revealed part by part as they learn, rather than thrown at them all at once.  It feels grown-up, and produces effective, visible, entertaining results very quickly.

Python is described as easy, and on some levels it is, but Greenfoot’s way of laying out code and colouring the blocks makes it straightforward to understand and read, and the braces indicate clearly where code blocks begin and end, and the Greenfoot environment makes it much easier than standard Java to work in.

So we’ll continue with Greenfoot for a little longer, looking at the same constructs – if statements, loops etc – as we have in Python, and I’ll investigate the possibility of a simple editor that will help us create programs easily without panicking over how complex it is.

Oh, and I might investigate Processing further as well – as I understand it, that also uses Java, and is also very visual, enabling students to see and visualise the results of their code much more easily.  That, as I see it, is the most useful and efficient way for them to learn, rather than plugging in lots of text-based code.  They’re only 14/15 year olds, after all.


BBC Basic

In my look at different languages for use in GCSE computing, I never even considered BBC Basic*, so it was a surprise to discover that it’s the language used in examples given out by OCR and the language used in a new coursebook.

BBC Basic was one of the original languages used in schools, on the BBC Micro.  Back in those days, as I recall, all users learned a form of BASIC – I myself learned Sinclair Basic, on the ZX81.  At that point, each line of code needed a line number, and it was possible to jump from one line of code to another using a command called GOTO, which could result in code that could be hard to read.

password checker in BBC Basic (from OCR)

password checker in BBC Basic

Now it seems that BBC Basic has been updated into a version for Windows.  There is a free version available for evaluation purposes, which limits the size of programs and prevents you producing a stand-alone version of the code.  A paid-for licence is available to lift these restrictions.

My concern is that I cannot understand why this language would be a language of choice for teaching computing.  It’s described as easy for beginners to learn, and it’s based on a language that may be familiar to those who learned their programming a couple of decades ago, but I can see no inherent benefit in using a language that’s purely for teaching and not used in any professional developments, as far as I’ve been able to find out.

I’ve tried hard to show an interest in this language, really I have.  I don’t know whether I have some deep-seated aversion to Basic, but to me this looks clumsy and hard to read, and there seem to be other languages that are free, used professionally and are far easier to read and understand at a glance than this one.  There seems to be no hook to say that BBC Basic is better because…, just the feeling that BBC Basic was the original teaching language so it should still be used.

password checker in Python

password checker in Python

Am I missing something?  Is there some aspect of BBC Basic that makes it better than Python or Java to use?  Because I’m disappointed that OCR have chosen to release their sample code in this one language rather than provide a selection of examples.  The justification given in the book for using the language is that BBC Basic is very close to pseudocode, but I don’t see that it’s any closer than other languages, and I’m left with a feeling similar to one I felt when I originally learnt Basic – that it’s all very well, but it’s not a proper language that is actually used to create real projects.

Feel free to correct me, but this feels to me like something that is being pushed for nostalgic purposes rather than because it’s a good tool for the job. Or am I just carrying over my old teenage prejudices, with all the frustration of trying to write fast, playable games with a tool that was just too slow to work that way?

PS: Originally BASIC was always given in capitals, as an acronym for Beginners’ All Symbolic Instruction Code, but these days it seems to be adopted as just Basic.