Building an assessment app in two days without rushing (hopefully)

At the University of Queensland, I'm helping to teach a software engineering studio course ("Design Computing Studio 2") where students are all collaborating, in groups, on 170-person project. It's a somewhat unique course, as it has a very large amount of collaboration between groups, and we've presented papers on it at two well-regarded international conferences: ICSE and ITiCSE.

This year, my colleague Jim has introduced peer critiques into the course — something that was missing in previous iterations. Groups will be asked to present their plans, and students will be asked to critique them. The groups in turn get to rate whether or not the critique feedback was useful.

I've also been writing the interactive teaching software "Impressory" for use on the course, and have a number of other software projects on the go. So, I wrote handy to make it easy and concise to write interactive, functional, webapps (generally, with Angular.js and Play).

It's time to find out how easy it really is.

The challenge

This week, I'm going to write the critique tool, as the first piece of functionality for an open source assesement app. And I'm going to blog it as I go — each post describing what code I've written, and how and why it does what it does.

This isn't going to be a hackathon — I'm not planning on staying up nights. In fact the next thing I have to do after posting this is head out the door to a meet-up about something completely different. And then I've got another meeting tomorrow morning. (So you might not see the next post until tomorrow afternoon.)

But the next lecture for the course is at 8am on Thursday, and I'd like to have it done by then so I can show it in class. Right now, it's 6pm on Monday. So that leaves Tuesday and Wednesday to get it done (in between other things like writing lecture content).

Let's see how we go.

For the students on the course

On the course, we teach highly collaborative ways of building software — part of our ethos is that even when we think we're working individually, we are still collaborating because we work with each others' code. There are tests, continuous integration, ticket management, collaboration tools, and all the fun of the fair.

If I'm writing this app in public and blogging it, then the chances are at least one or two students will glance at my code and the blog posts. And, if they're anything like I was as a student, they will be particularly delighted to see what I get wrong! (I'm sure there will be some things.)

So, I'd better to make the disclaimer up front that there will be some short-cuts.

Things that will be the same:

• Version control, using git on github
• There will be some tests (though using Specs2 rather than JUnit)
• Automated builds (though using sbt rather than gradle). At each stage, you should be able to run it at home if you want.

Things that will be different:

• Scala, not Java.

  Later in the course, we introduce students (a little) to Scala. But for the moment, it might look a little alien.

  Using Scala means a lot of the code I write can be much more concise.

  It can also be written in a functional style that makes it easy to use some powerful abstractions, and to avoid some mistakes (by making it less likely that a mistake will compile without errors).

• Some unfamiliar libraries.

  In handy, I hopefully have a bit of a head start.

  handy-appbase-core contains a few classes that have been hived off from Impressory to mean I don't need to repeat myself about functionality I've already written.

  And that includes dealing with security, asynchronous databases, returning model objects as JSON, log in with GitHub, dealing with whether it's a JSON request for data or a browser hitting a data URL, etc.

• Probably fewer tests

  On the course, having fewer tests would be a very bad habit — there's 169 other programmers who could break your code at any moment, and we'd like a test to show they haven't please.

  But over the next few days I'm not going to have 169 collaborators to keep me honest.

  The style I'm writing this in, however, tries to make sure that the type checker is less likely to let a mistake through than for a typical Java program.

• No CI server.

  I haven't yet set up a continuous integration server for the project. As I'm a lone developer, so there's nobody to continuously integrate with, I might not.