All BlueprintsEducation

Assignment submission and grading

Coursework handed in against a deadline: learners upload their work, anything that lands after the date is marked late rather than turned away, a tutor can give one person longer without moving it for the class, and the mark comes back with written feedback attached to the attempt it was about.

L2–L4Level range
8Sprints
45Tasks
Backend and frontendBuilt as

What you’ll build.

By the last sprint

A place to hand work in and get it marked. Students join a class, see what is due and exactly when where they are sitting, hand work in, and hand it in late and be told so rather than turned away. Marks and feedback attach to the attempt they were written about. A tutor gives one student longer without moving the date for anybody else.

What you’ll learn.

Each sprint is built around one skill. You show you have it in a pull request your team reviews, then explain it in a walkthrough.

Authentication

You can register and sign in a user, keep a request authenticated without asking for the password again, and explain where the credential lives in the browser and why there rather than somewhere else.

Assessments that grade themselves

You can deliver an assessment, grade a submission, and show that answers cannot be read or resubmitted by the person taking it.

File uploads

You can upload a file from the browser, store it somewhere the application does not own, and show it again on a later request — and say where the bytes travelled and what the database actually holds.

Roles and permissions

You can give users different roles and have the server refuse what a role may not do — not merely hide the button — and show the refusal working against a request the interface never offered.

Notifications people do not mute

You can notify a user when an event concerns them, show an unread count that survives a refresh, and honour a preference that says stop.

Going live

Somebody who has never met you can open a URL and use the product — and you can say what is different about the copy running there, where its secrets come from, and what you do when a release turns out to be wrong.

The roadmap. 8 sprints, 45 tasks.

Every sprint has a goal and a set of tasks. Open a sprint to see the tasks you will pick up.

Sprint 01

An account that holds

Somebody can make an account, come back to it, and not be thrown out in the middle of something.

5 tasks
  1. A learner can register and land signed in
  2. Signing back in survives a reload and a week away
  3. A sign-in that runs out does not cost somebody their place
  4. A learner can sign out on a machine they share
  5. Tutor accounts exist, and cannot be self-issued
Sprint 02

A class, and what is due in it

A tutor sets work with a date on it, and every learner in the class reads that date on their own clock.

6 tasks
  1. A tutor can set up a class and hand out a way in
  2. A learner can join a class with the code they were given
  3. A tutor can set a piece of work with a date it is due
  4. A learner sees what they have been set, and when it is due where they are
  5. The time left is the product's answer, not the browser's
  6. A tutor can correct work they have already set
Sprint 03

Handing it in

A learner uploads their work, and nothing says handed in unless the bytes actually arrived.

5 tasks
  1. A learner can hand a file in and see that it arrived
  2. A hand-in that did not finish uploading is not a hand-in
  3. Both sides can open exactly what was sent
  4. Files the product will not take are refused with time to do something about it
  5. Work that is removed takes its file with it
Sprint 04

Late, not refused

Work that arrives after the date is taken and labelled late, and handing in again says what it will cost first.

6 tasks
  1. Work handed in after the date is accepted and labelled late
  2. Work that lands on the second counts as on time
  3. Handing in again replaces what will be marked
  4. Handing in again after the date says what it will cost
  5. A tutor can allow further hand-ins, or close the work entirely
  6. An abandoned hand-in is not an attempt
Sprint 05

Whose work is whose

A tutor sees the whole class on one screen, a learner sees only themselves, and one person can be given longer without moving the date for anybody else.

6 tasks
  1. A tutor opens one screen and sees who has handed in and who has not
  2. A learner can reach their own work and nobody else's
  3. A tutor can only see and act on their own classes
  4. A tutor can give one learner longer without moving the date for anybody else
  5. An extension decides lateness everywhere lateness is decided
  6. A learner can leave a class, and a tutor can remove somebody from one
Sprint 06

Marked by a person

A tutor reads a hand-in and sends back a mark and written feedback, attached to the attempt they were written about.

6 tasks
  1. A tutor can mark a hand-in and write feedback on it
  2. Nothing a tutor writes reaches the learner until it is released
  3. A learner reads their mark against the attempt it was about
  4. Work waiting to be marked says so, on both sides
  5. Feedback does not follow a resubmission
  6. A tutor can release a whole class's marks at once
Sprint 07

When a mark changes

A learner is told their work has been marked, and told again if the mark moves after they have seen it.

5 tasks
  1. A learner is told when their work has been marked
  2. The product knows what a learner has actually read
  3. A mark that changes after the learner has seen it says so
  4. Read on the phone is read on the laptop
  5. A learner can see everything they have been told, and clear it
Sprint 08

Somewhere a class can reach

The product is on the internet at its own address, with files and a clock that belong to nobody's laptop.

6 tasks
  1. The product runs somewhere that is not a laptop
  2. Settings and secrets come from the environment, not the repository
  3. Work handed in survives a restart and a second copy of the app
  4. The live copy decides deadlines on a clock nobody has to argue with
  5. A stranger can do the whole thing on the live copy
  6. A failure is visible, and a bad release can be put back

Read before you build. The best engineers do.

Senior engineers read the docs before they touch the code. Every Blueprint comes with short documents on the product and its world, the kind a team hands a new hire. Read them well and you ask sharper questions and walk into every review prepared.

What you are building

The product, the two people who use it, and what finished means.

Whose clock the deadline is on

Domain you will not have: what a due date actually is, why late work is accepted rather than refused, what an extension is in a real institution, and what a mark is allowed to do after somebody has seen it.

Build assignment submission and grading.

Start your free week. Adaeze runs your kickoff, and Lars reviews every pull request.