Leaving Cert Computer Science - One Step Closer

It's been a long time coming, but with the publication by the NCCA earlier this month of a draft curriculum (PDF) it seems as if Leaving Certificate Computer Science might finally be close to becoming a reality. The current "fast track" timetable puts the first exam appearance by the subject in June 2020, meaning it will be available for those entering 4th year this coming September (or those sitting the Junior Cert this coming June and skipping Transition Year). 

From our perspective, there's a lot to like about the proposal. The focus on practical applications is promising, and the 30% of marks allocated to coursework seems appropriate. There appears to be plenty of technical depth in the proposed curriculum, including study of CPU hardware, character sets, algorithmic complexity and sorting and searching algorithms. The course also includes a broader study of computers' impact on society, including sustainable development (this last part seems a little incongruous at first, but as part of a broader approach to including sustainability in all curricular strands it makes perfect sense).



There are also some areas we believe can be improved or need further work. Two in particular jump out at us from this draft of the curriculum proposal. The first is the heavy reliance on group work, which forms the backbone of the practical portion of the curriculum. It is envisaged that in this portion of the course “[s]tudents assume different responsibilities in each project, rotating between the roles of team leader, project manager, communications manager, and programmer”.

There are of course real benefits to group work, but it is our opinion that in the context of introducing computer programming to students for the first time it is counterproductive to give some students an “opt-out” from the coding portion of the assignment. Indeed it appears from the description that only a quarter of students will actually be coding during each 6 week project block. Even with rotation between the roles for each project, it is not at all clear to us that this approach will yield better educational outcomes than individual projects, and certainly not when that is measured in terms of computer science learning outcomes.

The second area in need of attention is not one which is within the scope of this recently published document, but it is an area which will ultimately the determine the success or otherwise of this initiative, and that is the actual delivery of this curriculum. It has long been our concern, backed by frequent communication with a wide range of schools, that most principals intend to either a) not offer the course at all, or b) press their physics/maths/technology teacher into service as a computer science educator. It is our strong view that neither solution is satisfactory.

The latter in particular could do serious damage to the reputation of the course, resulting in teachers delivering the course who, through no fault of their own, are neither skilled nor qualified to do so, and learning outcomes suffering accordingly.

We look forward to hearing what proposals will be brought forward to address this, and engaging with the NCCA and the Department of Education in developing solutions to address this problem.

Overall, with those small caveats out of the way, we are beyond excited that this step has finally been taken. It represents the culmination of literally decades of lobbying effort (for which the lobbyists in question are owed a debt of gratitude from us all), and a major leap forward for our education system. Getting student studying computer science at Leaving Cert level will inevitably broaden the range of individuals applying to proceed to third level education, as well as those who carry the skills of computer science into a wide range of other career tracks.

We look forward to being part of this bold new frontier in Irish education.



New Grading System at the Academy of Code

Grading students at the Academy of Code has always been something we've tried hard to get right, and generally it's been something we've struggled with. The nature of coding is that the material will immediately click with some students, while others will need more time to engage with it before they are ready to move on to the next concept. Over the course a single term this can mean vast gulfs emerging even within a class of the same age group, never mind one with a 3 or 4 year age spread (as many of our classes have).

In an effort to alleviate the issues this causes (boredom on one side, and frustration on the other) we generally allow a certain amount of leeway for students to progress at their own pace. This works well, and allows many students to thrive, but something we've heard from many parents is that they would like some sort progression for students, so that they always have something to work towards. 

That's why we've introduced our new grading system, as of the start of our summer camps this year. Pictured above are two returning students, who received beginners (white), junior grade I (red) and junior grade II (yellow) bands at the end of their week with us this summer.

This also coincides with our adoption of class booklets (previously we distributed lessons one at a time, as the previous lesson was completed - this was both inconvenient for students, who were limited in the work they could do at home, and also a nuisance for us, as it meant keeping a huge stack of paper on hand, and transporting it to each class!). Class booklets have a progression chart on the back, to be dated and signed by teachers as each lesson is completed and checked. 


For later grades there will also be more onerous grading requirements - the unassisted completion of some significant piece of coding, demonstrating understanding/mastery of specific areas of coding.

We're excited about this, as it will give students a clear, multi-year path to developing their coding expertise with the Academy of Code. Students seem excited too (although perhaps as much for the new fashion accessories and bragging rights as anything else!)

We will have more information about these grades in the coming weeks and months, especially the later grades which will require much more commitment to reach than the first few, and which may also include developing websites, working on hardware (arduino/picaxe/raspberry pi/lego mindstorms), and much more besides. Watch this space!

Gender Balance and Diversity at the Academy of Code

Diversity in IT is tricky. Google make a big deal of their commitment to equality of all types. So do Microsoft (in spite of the odd enormous misstep). Tech companies like Pinterest have been very public about their attempts to improve diversity. Closer to home, there are several women only scholarships available to women entering STEM (Science, Technology, Engineering and Mathematics) career paths.

In spite of all this, a survey of top tech companies show that tech roles in Apple, Google, Microsoft, Facebook and Twitter are filled by only 10-20% female employees.

And we shouldn't be too smug at the Academy of Code either. We have 7 employees, and only 1 female (numbers fans will note that that places us right in the middle of that 10-20% range).

While it's hard to say what exactly we can do to help this situation, we have started by making some efforts over the best six months to ensure that our advertising is more gender neutral. (Mostly this has meant ensuring that pictures used totally misrepresent the actual gender ratios at our courses - we reckon Machiavelli did make some good points...).

But hey, it's worked! At least it's moved things in the right direction (probably - causation is hard to firmly establish). Summer camp aside (and we expect the balance on summer camps is inherently more balanced - we'll know more once numbers for this summer's camps are available), we improved from a steady 16% girls up to 21% in like-for-like classes this term. Adding some girls-only classes (after-school in the Teresian School) has pushed that number up to 29% female. Hopefully our summer camp this year will show another solid step closer to gender parity.

Which of course raises the question - is gender parity the goal? Well, no actually. Not for us. Our goal is to get to a point where gender balance becomes a non-issue. Roughly speaking, this is regarded as being somewhere around a third. In a class of 20, on average you need around 7 girls for them to not be at risk of feeling like interlopers in a class for boys, and that's where we want to be. Whatever the numbers that eventually go on to careers in IT, we think it is a crying shame that anyone would be turned off a potentially amazing career purely because of their gender.

So: here are our numbers. We're working on them. Long term we want to be part of a broader solution, but short term we just want to be part of the conservation. If we can keep our own numbers going the right direction, and get at least some of our female students excited about a career in IT that's a good start. We also hope this might be something of a wake up call for parents. Around three quarters of our students are in primary school. Whatever about industry trends at large, at that age parents are still essentially calling the shots on extra curriculars. So parents - why is it sons and not daughters you're sending us?? If you have any thoughts on what more we can do, we're always delighted to hear from you. In the meantime, we're going to keep working on it. Hopefully we will contribute to a very different kind of IT environment over the coming years.

(Gender diversity is not, of course, the only kind of diversity - we will return to this subject again!)

A Long 16 Months

The class diary was an experiment which, in spite of its success, we put to one side after week 12 of our Autumn 2014 term. It's been gathering dust there ever since. The diary itself was quite well received, with plenty of parents happy to get an insight into what was happening in class, but putting it together became more of a distraction than it was deemed to be worth. New curriculum development took over, as did recruitment, logistics, and all of the other things that go into bringing each Academy of Code term together.

16 months has left a lot of updates unpublished, and a lot has happened at the Academy of Code in meantime. Time for an update, it seems!

Three founders have become two, as Simon has moved on to other projects (and is greatly missed, by staff and students alike). In his place we have added David, Robert, Sarah and Sid, not to mention Daire, who has been in and around the Academy since that first set of summer camps - not directly filling Simon's shoes, perhaps, but doing a fantastic job in their own rights.

We've also added some new students. Quite a few new students, in fact. In Autumn 2014 we had only a little over 20 young coders in our charge. As of April 2016, that number is well over 200.

We've added locations - first the Teresian School in Donnybrook, for after-school classes, now St. Paul's Raheny, for summer camps. Several more schools are also in the mix for further expansion in 2016.

Most importantly, we have been able to maintain (and even increase) the standards which we set down on day one, way back in early Spring of 2014.

As we get busier we find there is more frequent and more interesting news to share, not to mention more exciting screenshots and videos we can pull from our classes to share. All that and more in the coming months - stay tuned!

(Oh, and the summer camp 2016 registration page is now live - we sold out a class earlier this year in less than 60 minutes, so if you have a date in mind, don't delay!)

Week 12: Parents' Night

12 weeks done - flashed by in the blink of an eye! - and not a whole lot more to say here about what was covered. We're looking forward now, to January and to next summer, and we have a whole heap of new things in store for both new and returning students.

Speaking of returning students, we hosted parents' night this past week, in the second half of the final classes of term. As you might expect there were a couple of students who ran into Muphry's law in relation to demoing software live (that's a lesson for next term - never demo your software live!), but overall most parents seemed to be somewhere on the "happy" to "blown away" end of the scale in terms of their reactions to the final projects.

And speaking of blown away, we've been blown away by the feedback from those parents, and by the number of students who have promised they'll be back to us next term. Not that we want to count our chickens prematurely, but even the fact that so many are interested in coming back is a wonderful affirmation of what we're doing. We were also pleasantly surprised that all of those parents were pretty much across the board delighted with the classes, and with the progress their kids have made over the past 3 months.

As communicated to many of those parents, the biggest challenge we've run into this year has been simply churning out lesson plans and project ideas fast enough to keep ahead of the class. It's a wonderful problem to have, but at the same time it's also nice to now have a month to put a bit of breathing room between us and them! We'll be tweaking our "new students" course content over Christmas, but what's really exciting us is the possibilities for the returning students. While we're relatively constrained in what we can do early on, with three months under their belts there is suddenly a whole world of options for us to explore next year.

No firm decisions have been made just yet, but we have a couple of demo apps coded up already (some students will have seen those last week) which are really whetting our appetites. If next term even comes half way to living up to its potential it's going to be an absolute blast!

Some screengrabs from the 2015 course. And this is just for starters!

Some screengrabs from the 2015 course. And this is just for starters!

After that there'll be summer camps (dates to be announced, and sign ups opening, early in the new year), but that's probably enough to be going on with for now.

Classes next year are taking signups already, and we do only have a finite number of places so don't hang around if you're hoping to nab a place!

Week 11: More Projects, and Looking Ahead

Time really does fly. It feels like only a few short weeks ago that Simon, Eamonn and myself (Diarmuid) sat down to discuss the idea of forming a company that would run computer coding courses. That would have been back in March, or thereabouts. Since then we ran an experimental Easter courses (to prove that our ideas more or less worked in reality) and then two weeks of summer camps. Finally, buoyed by the positive feedback from those first two forays, we decided to press ahead and advertise our first term-time courses this past August/September.

We've certainly run into our fair share of difficulties along the way. Our decision to hand deliver 10,000 leaflets ourselves back in September was, in hindsight, something of a false economy. My decision to cut up stickers by hand for our branded USB sticks was (again in hindsight) rather more labour intensive than I perhaps expected. And as for the "wait, I thought you had the keys..." incident - probably the less said the better!

What really matters, however, is the teaching, and on that side of things we could scarcely be happier. As detailed in the past few weeks' blog posts, our students are far surpassing anything we could have imagined at the start of term.

I'm reminded of a lecture by an academic named Randy Pausch* (available on YouTube, and more than worth the ~75 minutes of your time). He was teaching a new course in Carnegie Mellon called "Building Virtual Worlds", and his students had just achieved more in their first two week assignment than he thought they would in an entire semester. He called his mentor, and after hearing the story his mentor said "[...] you obviously don't know where the bar should be, and you're only going to do them a disservice by putting it anywhere".

We're not teaching undergraduates at a top university (although I have no doubt that, in just a few short years, many of our students will be undergraduates at top universities!). All the same, I can't think of a better philosophy the guide us over the coming terms. 

We won't be abandoning our curation of course content, but we will be pulling out all the stops to provide more and better options to students, and even more opportunities to put their own stamp on what they're doing. We don't ever want them to feel that they're doing "enough" without having to push themselves. Within a few more terms some of our students will hardly need that kind of curation at all, as they'll reach a point where there's little they can't do. In the meantime we will keep racing to keep our assignments and projects ahead of them.

We're extremely excited about next term, and about the number of students who have already signed up to come back to us. If you're even almost as excited as we are, we hope you'll come along for the ride!

Week 9 & 10: More Project Work

The project phase of term is in full flow at this stage. While this is an exciting time for everyone, it does make it a little difficult to summarise what they're all up to. This is a lovely problem to have though, caused as it is by everyone doing something interesting, and all moving forward at their own pace.

This is what we really hoped to achieve when we founded the Academy of Code, and to see such exciting results in our first full term is incredibly heartening. Not that every student is equally as brilliant as each other - that simply wouldn't be a sensible yardstick - but that every one of them moves at the top end of whatever their own pace is, and that they are constantly being challenged, overcoming that challenge, and then being challenged again.

Over the past two weeks one of the major features being added by many students was collision detection, in most cases between circles. (Detecting collisions between rectangles involves a lot more steps, so most students were encouraged to stick to the circles. A few brave souls did implement the rectangle collision detecting though - and mostly with reasonably solid results!) 

The images above show how we go about detecting a collision. The distance from a circle to its edge is half its width (this is also called the "radius", for those of you who slept through maths class!). By getting the distance between the centre of the circles (basic geometry, which Processing takes care of for us with the "dist()" function) we can tell quite easily if the circles are touching. 

If the sum of the radiuses* is equal to the distance between the centres then the circles are just touching. If the distance between the centres is larger than the sum of radiuses then they aren't touching, while if that distance is smaller than the radiuses then there must be an overlap. Not trivial, but also far from rocket science. Lack of exposure to geometry is the real barrier we run into here, particularly with younger students, but with a bit of gentle coaxing most students managed it at some stage in the past two weeks. We also have the demo below to allow us to step through frame by frame and see what's happening. 

This is a very slightly altered version of the basic portion of the game students produce in their first term. We've added the line between circles, along with the text readouts, to allow us to watch the values of the important datapoints and analyse what's happening in the program. The line will turn red when the circles collide. The orange ball can be moved left and right using the 'a' and 's' keys, while the program can be paused by pressing '0', resumed at normal speed by pressing '9', or incremented a frame at a time by pressing 'c' while paused. (NOTE: You will probably have to click on the frame for any of those key presses to work!)

What you're seeing above, by the way, is one of the very neat features of processing - it can be embedded straight into a web page, almost without having to make any changes at all!

(Technical note: it's actually not quite that straightforward in reality, for a couple of reasons. Mostly it's that switching from Java (on the desktop) to javascript (in the browser) isn't ever going to be absolutely perfect. We've found that the background() function gives up on us in the javascript version (although this isn't a universal problem, and so merits a little more digging), as does some image resizing. In addition there are likely to be some issues with any complex object inheritance structures, as well as issues with overriding (since java is strongly typed and javascript is weakly typed). When the time comes (maybe 5 or 6 terms in!) this will provide us with a fascinating way of talking to students about the differences between strongly and weakly typed languages, and about how languages implement inheritance, and all sorts of other similar topics.
Another issue we've run into seems to be a Squarespace specific one, namely that embedding our canvas directly in the html on Squarespace just won't work. We have a couple of theories why, but for the moment we work around it by hosting them elsewhere and embedding them here using iframes.)

We have a number of mini-applications like this which we've either used this term, or will introduce next term, and many more ideas floating around. Look out for them here in the not too distant future!

In the meantime we're now facing into our final two weeks of term, and looking ahead already to next year. If you haven't already spotted the signs, we're taking signups for January already. If you're interested, don't wait until it's too late!




*Or radii, if you like to more classical in your plurals.

Week 8: It's Project Time!

Some of our more advanced students (mostly those who attended our Summer Camp) have been working on their end of term project for a while now. For the rest, today was a big occasion: they finally got their hands on the first project handout.

Not that there's anything all that special about the handout*, but what it represents is a major vote of confidence in all they've learned so far this term. We've been building up to it since September, and now we finally think they have all the skills (or enough, at any rate) to build the block dodging game we've been teasing them with the past few weeks.

What are those skills?

Well, they need to be able draw objects on the screen (using functions). They need to be able to move those objects around (using setup() and draw() blocks, variables, and basic arithmetic). They need to understand program flow (that's setup() and draw() again, and how the computer moves through the code in those blocks). They need to detect key presses (using if statements, comparison operators and system variables), and they need to detect collisions (using more comparison operators along with some slightly more complicated arithmetic).

There's other stuff too - despite the mainstream narrative that all kids these days are "digital natives", the reality is that there's all sorts of other, more fundamental IT skills they've learned in the past 8 weeks as well. Things like using ctrl-c to copy and ctrl-v to paste have come in handy. Using ctrl-z to undo has, unsurprisingly, come in even handier. They've become a bit more familiar with the windows file system (finding where on the computer they actually saved things), and they've become more used to highlighting specific bits of text they need to cut or copy (not much call for that while using a smartphone or tablet, it seems).

The block dodging game is simple relative to a modern 'AAA'** game of course, but is not dissimilar in appearance to something like Tetris. The basic idea is that you start by having a block or ball drop from the top of the screen, and the player controls a block moving left-to-right on the bottom of the screen trying to dodge that block. If the player is hit he loses, if not the game continues. We add layers of complexity when we randomise the position and size of the block, when we start keeping score, when we make the game harder as time goes on, and in many other ways as well***.

Progress was overwhelmingly positive across the board. Everyone managed to get either the player block moving left and right on key presses, or the "attacking" block dropping from the sky and then moving back to the top once it had passed the bottom of the screen. If anything, four more weeks seems like way too much time - but over achieving students are hardly a teacher's worst nightmare.

The advanced cohort also made great progress (but then, they always do, consistently outstripping even our most optimistic projections for them). We'll be featuring some of their work on the site over the next few weeks, as well as the finished projects from all of the kids in both the Tuesday and Wednesday classes.

Until then! 


*Actually it's one of our less interesting handouts - no colourful code blocks, no pictures, just a single A4 page of text with the scant consolation of a colourful "The Academy of Code" footer. Pretty disappointing relative to the high bar we like to try and set.

**'AAA' being the tag used to describe the kind of super high budget games which, with a few notable exceptions, you probably love if you're a kid and hate if you're a conscientious parent. 

***Simon (one of the teachers here at the Academy) decided it would be fun to add his own face to the "player" block, and make the falling blocks look like ninjas. Based on our experience demoing at the Wednesday class it seems there's no better way of endearing yourself to a 9- or 10-year-old than write a computer game where you escape from ninjas. Take note, parents! 

Week 6: Becoming a Nodding Bear (or a Rubber Duck)

The essence of good programming is being able to approach a problem you've never seen before and plot your way through it using the various tools at your disposal. This is true of every programmer, from beginners right up to technical architects on huge projects. In fact, it's not just confined to programming. All engineering (and programming is certainly at least sort of engineering), involves this ability to approach a problem and find a solution in as novel or humdrum a manner as the situation dictates.

One of the first things we talk to our new students about is the idea of this "toolbox". We start with some simple commands: this is how you set the size of the window; this is how you draw a circle; this is how you draw a rectangle. We add to this as time goes on, but we never get to the point where we say "this is how you create a computer game". That, as you would expect, is instead a combination of all the little things into one big thing. 

Starting out, their most powerful tool is not really any of these things but rather the instructors. The instructors know all the answers (or at least in the narrow confines of the assigned problems we do...), and we will always be available to give an extra nugget of information when a student is truly stuck. 

After a number of weeks, however, something strange starts to happen. Bit by bit, they slowly stop needing us. 

They still have questions, of course. Even advanced programmers occasionally need a sensible eye cast over a particularly intractable problem. More and more, however, their questions are answered before they finish asking them. As an instructor, all we need to do is nod along until they work it out for themselves. We're reduced to the roll of "nodding bear".

(A software team I worked on referred to it as the Stanford Bear, but I can find no sources which credit Stanford with the original innovation).

The idea of the nodding bear is that a programmer, as part of her/his debugging efforts, explains their problem to someone or something else. This can be an instructor, a colleague, or literally a rubber duck or stuffed bear. The typical question might begin with "so I'm trying to make this box disappear here and reappear here", before trailing off with "but when I check if the position is greater than the size - wait, shouldn't that be less than..? Never mind...". As the nodding bear, all the instructor has to do is nod along until the student arrives at the solution all of their own accord. Neat, right?

We're only six weeks in, so of course there are still lots of questions coming at us, and of course there is a wide range of abilities in each of our classes. All the same, it's great to slowly start becoming closer and closer to the proverbial Nodding Bear.

This week we revisited our basic drawing tools with most of the students, before moving on to making a box fly around the screen and respond to commands. More than ever before these students are starting to see how the tools they already understand can be combined in new and interesting ways.

Meanwhile the more advanced group were pressing ahead with their block dodging game. They progressed notably on their collision detection code, and generally made good progress towards the finished game. With a bit of luck we might need to find an entirely new project for them before the end of the year!

Week 5: Movement, and the Start of a New Project

This week was exciting for both our beginner/intermediate group and our more advanced cohort. For many of the beginner group this was their first time doing anything that might be called "animation", and they were predictably excited about the prospect! For the advanced students, meanwhile, this week marked the start of their first major, multi-week assignment - more on that further down.

After a recap exercise, which involved using detecting keyboard input and changing the size of a circle in response (which is not nearly as easy as it sounds!) the first group started into their animation with an apparently simple "move the ball across the screen" task. With a bit of help most of them had managed to plough through this by the end of the class, but that's not to say there wasn't a lot going on. Quite the opposite! This task requires students to understand program flow (which means understanding which instructions will execute in what order, and why) as well as making use of variables to store numbers, and accessing those variables to modify them. On top of all that this also requires that they be very careful about their use of brackets. Every '{' must be matched by a '}', and every '(' matched by a ')'. 

All this combined means that this bunch of students, many of whom have been with us only five weeks, are now equipped with many of the skills required to produce some really amazing programs. We're all looking forward to seeing how far we can bring them in the next seven weeks!

On to the advanced crew, and their assignment was only just getting into gear this week. They've been tasked with building a "block dodging" game. The player will control a character who moves over and back across the bottom of the screen (think Space Invaders), and dodge blocks which are falling from the top of the screen (think a cross between Tetris and, well, Space Invaders). Early progress has been encouraging, with students successfully crossing some of the first hurdles, and displaying admirable breadth and depth of knowledge. Perhaps next week we will have some early demos to share.

Week 4: Keyboard Input

Like week 3, week 4 was always going to be a good one in terms of student reaction. This, of course, is one of the main reasons we use Processing. Unlike other languages (eg Java, or even Python/Ruby/etc), it's possible to very quickly progress to user input in Processing.

As a teacher it's gratifying to be able to reliably show a demo at the start of class and have students (literally!) gasping with astonishment and excitement. (At least, one hopes that gasping with boredom hasn't quietly become a thing without any of us noticing?).

That said, this week was also a tough one for many students, as they had to deal with the idea of "nesting" much more than before. Opening and closing brackets/braces isn't really a skill normally all that necessary, and when necessary it doesn't tend to be terribly difficult. In the code example below, which is perhaps on the high end in terms of number of nestings*, there are 6 separate pairs of curly brackets, all of which must be matched correctly in order for the code to function. Not all students managed to get to this level of complexity this week, but they all will!

void setup() {

void draw() {
  if (mousePressed) {
    if (mouseButton == LEFT) {
      if (keyPressed) {
        if (key == 'c') {
          ellipse(mouseX, mouseY, 50, 50);

You can see in the code above much of what we covered this week, most notably if (keyPressed) and if (key == 'c'). For those students who are interested in making games (which I think probably covers most if not all of them!) this was obviously exciting, as they got to see how easy it potentially is to take a user's input and do something with it in code.

In addition to key presses we also introduced students to variables this week. Variables allow a programmer to store something (a number, letter, word, etc) and refer back to it later. For example, we might set a circleSize variable at the start of our program, and make all subsequent circles with circleSize as a diameter. If we want to change the size of all our circles we then only have to change the number in one place. This also allows us to do interesting things like incrementing or decrementing the circle size based on mouse clicks or button presses. 

As you can see, and as the students are seeing, even in the relatively small number of classes we've had so far they have built up a formidable array of tools with which to tackle programming challenges. Next week will see revision of bracket discipline, as well as a some quickfire revision of the various functions we've used to date, and more opportunities to play with the user input features introduced these past two weeks.

More advanced students (mostly those who have previously attended a course with us) will also be moving on to bigger and more complex problems, requiring higher level thinking and more complex structures. Something for us all to get our teeth into then, and plenty to look forward to for all our students!


*For those programmers in the audience: don't worry, user-defined functions are coming up soon. We won't be encouraging quadruple nested if statements as a standard programming practice!

Week 3: Mouse Input

Having introduced the students to user input in week 2, this week we started to make things a bit more interesting with the addition of left and right clicks. As usual Simon kicked things off with a quick demo of what we're building towards. As well as demoing our very simple car game again, we also took a look at a simple but extremely cool shape-shifting demo (which we will be embedding below shortly). This simply draws a box at the location of the mouse, leaving a trail behind when the mouse pointer is moved. Left-clicking switches from square to circle, while right-clicking clears the screen. All quite simple, but very visually engaging!

It's always fantastic to see the reactions of students the first time they write a program that tracks the mouse pointer. The mix this term is about 70:30 new students to returning students, so there were plenty of big grins around the room when they got a circle drawing on the location of the mouse.

In Processing we can very easily set a refresh rate of 30Hz (simply by placing code inside the draw() block), so combining what they already know about the ellipse() command (used to draw circles/ovals) with this and the newly introduced mouseX and mouseY variables (which always give us the up-to-date location of the mouse) it's actually quite a simple exercise to make a shape follow the mouse. Simple as it might be, it's still a great confidence booster. It also really shows the power of combining a few separate pieces of knowledge to make something that's much more than the sum of its parts, and is a very solid introduction to the idea of program flow.

Working hard!

Working hard!

Even better is when they realise what the next steps are, and there was more than one student this week who was desperately trying to make those next steps come together before the final "save everything and shut down" call came! Most managed to make some use of stroke() and noStroke() functions to remove or change the outlines of their shapes this week, but the real power of all those tools (and more, like the briefly introduced void() function) are yet to be fully revealed. 

Left and right clicks will continue to be in focus next week, as we keep up our relentless work towards mastery (or at least a decent grasp!) of coding computer graphics with Processing. Until next week, then!  


Week 2: User input and conditions

This week we introduced students to the concept of "user input". This allows us to write programs with which they and other people can actually interact, and is a vital early stepping stone in our curriculum.

After a quick refresh of our existing programming tools (ellipse, rect, fill), we started into the three main topics of week two.

  1. User input: This is a big subject so we started off with mouse button clicks. Once students had this part figured out we moved on to distinguishing between left and right button clicks, and using each one to do different things.
  2. If conditions: 'if' statements core to all programming logic. They allow the programmer to test if a 'condition' is true or false, and act in different ways depending on which it is. 
  3. We also introduced the "pointer base", a simple programming tool (programmed in-house by the Academy of Code team) that helps show the position of the mouse on the app window, allowing easier identification and placement of shapes on-screen. Most students find this useful, but especially those who might be struggling slightly with the co-ordinate system, or those younger students who simply hadn't come across it before attending the Academy of Code.
Eammon and the Tuesday class coding up Pumpkins

Eammon and the Tuesday class coding up Pumpkins

Other things we learnt:

Another basic function, background - similar to the fill command (and similarly allows students apply their knowledge of RGB colours from week 1!), this function lets us set the colour of the background of the window.

We also took the opportunity to get seasonal (if perhaps several weeks early), and students practiced their use of functions and co-ordinates by drawing pumpkins and ghosts!

Week 1: Shapes and Colours

One of the great things about Processing is how you can write just two lines of code and immediately have a shape appear on your screen. If you've never studied programming this might not seem like a big deal, but trust us when we tell you that this is a radical departure from how coding is taught to computer science students in Universities and Colleges. 

When I was in University (which is not really all that long ago, and I'm told not much has changed) we had to slog through literally dozens of lectures, tutorials and labs where all we did was input and output text. Only then did anyone even acknowledge the fact that actually, yes, it is possible to write programs which do more than this.

The merits of this approach are a whole post unto themselves, but suffice to say text adventures stopped being exciting in the early 90s, and we like to use a slightly bigger and more colourful hook with which to grab their attention. To start with they are given code to type in that looks something like this:

Week One, Step One: The journey begins!

Week One, Step One: The journey begins!

Then they hit the play button (that's the little triangle near the top left - no prizes for guessing what the square does). All going well, another window pops up that looks like this:

A circle! How exciting!

A circle! How exciting!

And that's a computer program!

There is quite a bit to talk about, even in those two lines, but when the students have gotten their heads around that much we add another element: colour. 

Colour is interesting because most students won't ever have needed to describe a colour in numbers (why would they, after all?). Moreover, what colour mixing they have done will have mostly been in art class in school, where they will have mixed paint. Computer colours obviously aren't composed of paint though, and in fact they mix in almost the opposite way.

Paint mixes subtractively, which means that if you keep adding different colours you'll end up with black. (My memory of art lessons is that inevitably any colours mixed indiscriminately ended up more of a gloopy brown, but probably I just gave up too easily).

Computers use light to make up colour, which mixes additively. Keep adding more colour and you get to (or near) white. The image below neatly sums up the difference:

How light mixes (on the left) versus how paint or ink mixes (on the right). © Athabasca University / Wikimedia Commons / CC-BY-SA-3.0

How light mixes (on the left) versus how paint or ink mixes (on the right). © Athabasca University / Wikimedia Commons / CC-BY-SA-3.0

We describe each of the component parts - Red, Green and Blue - with a number between 0 and 255. (The images above only show the 0 and 255 values, of course, but all shades in between are possible too. A total of around 16.7 million, if you were wondering, albeit a lot of them quite hard to tell apart). By using the fill command we can make subsequent shapes change colour. A very simple example, typical of what the students wrote in class this week, might look like this:

Note the lovingly precise comments - students are encouraged to comment their code from day one!

Note the lovingly precise comments - students are encouraged to comment their code from day one!

And it would output the beautifully simple:

This face doesn't look all that happy - possibly because describing curves is one of those things that's inexplicably hard. We don't start drawing curves for quite some time!

This face doesn't look all that happy - possibly because describing curves is one of those things that's inexplicably hard. We don't start drawing curves for quite some time!

All this means that by the of the lesson students are making coloured shapes and positioning them on screen using co-ordinates (younger students might be using co-ordinates for the first time). They've grasped the idea of parameters, and of functions. They understand the basic idea that computers execute instructions in the order given. They've also, almost certainly, had the experience of drawing a second circle in the exact same position as the first, wondering why they're only seeing one, and then laughing when they realise what's happened. Little do they realise that they've just successfully completed their first exercise in debugging!*

On top of this they've learned about how computers actually understand colours, and (somewhat unbeknownst to themselves) they've started internalising 255 as an important number (it's the biggest number you can store in a single byte, since you asked, and one which crops up almost constantly in computer programming).

All that, and 11 of our 12 classes still to go. Welcome to The Academy of Code!


*A lecturer of mine once made the observation that if "debugging" is the process of removing bugs from code then the process of writing the code should surely be known as "bugging". Not that it's ever likely to catch on, but I guess you could make the argument that the students were introduced to both debugging and bugging this week, which is really quite a lot to take in all at once. Thus far they seem better at the latter than the former, although the same could no doubt be said of plenty of professional developers.