Comparative Judgement: Re-imagined with Meteor

As I faced thirty 12 year olds eagerly looking forward to the lesson I was about to lead I realised I was dreadfully unprepared. I was about to run a peer assessment session using the latest shiny app I had created with the latest technology, meteor, that hadn’t even reached its first official release. What on earth was I thinking?

Thirty kids not only firing their essays into the system, and boy could they write fast, but also thirty kids hammering my adaptive maximum likelihood algorithms running on the back end. And just for fun, throw in an integrated email system, a school firewall, a selection of Macs, PCs and tablets, and no school technician to be found. This was not going to end well.

I was tempted to run, but then I saw the steely glare of the teacher I was with. Time to face the withering scorn that only 12 year olds are capable of. It wasn’t like I hadn’t been here before. Twelve months early I had been in an almost identical situation and watched my cloud server grind to a halt. I had been using a traditional client / server web framework built on synchronous processing — you send a request — you, and everyone else (in this case thirty 15 year olds) wait for a response — and wait, and wait, and wait … It turns out that 15 year olds don’t much like waiting.

But this was meteor! They’d promised me something called reactive processing that would change the way the web worked for me! No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database, or wrangle an ORM layer, or swap back and forth between JavaScript and Ruby, or broadcast data invalidations to clients. Maybe I should have checked their credentials… but it was too late for that now!

The session began suspiciously well. Kids were typing in their essays into their word processors with gusto, while I nervously emailed out the first links. Surely the firewall was going to eat the emails… but no, the first one appeared in the student inbox, then the next, then all of them. Before I could say, please don’t all upload your answers at once they had opened the links, hit upload, and sat back and looked at me waiting for instructions. Quick! The judging links!

Again the email system worked! And away they went, happily judging each other’s essays, blissfully unaware that a server in California was grinding away with my maximum likelihood algorithm to make sure the paired comparisons they were being presented with were optimal, and the scores produced were accurate. It took me a while to realise that their judging was proceeding smoothly, with no delays caused by trans-atlantic mathematical gridlock. So this is what reactive means! I could breathe again. The leaderboard was working. The students’ essays were being ranked. We would have a winner.

As the winner approached the front of the class to receive his accolades, I froze. The judging had stopped, but the leaderboard, proudly displayed on the the interactive whiteboard, was still updating itself, as if a horde of ghosts were still judging the essays. Of course they were.The judging simply hadn’t waited for my lovingly crafted algorithms, sitting somewhere in the US, to finish every time a student made a judgement: the app knew it didn’t need to wait for a response! I crossed my fingers and hoped we wouldn’t end up with a new winner once all the votes were in…

So that’s meteor:

Data on the Wire. One Language. Database Everywhere. Latency Compensation. Full Stack Reactivity. Embrace the Ecosystem. Simplicity Equals Productivity.

And 30 happy 12 year olds.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s