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!

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!) 

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

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!