You are entering the second half of the time period allotted to work on task #5 (API implementation). It is time to take a step back and reflect on what you have managed to implement so far. In some cases, this may serve to provide a gentle nudge to those who have been postponing their work on the implementation.

Your task (in pair) is to prepare a short presentation on the progress of your implementation and give a short talk about it during the labs.

Please note that you have approximately 1 week to prepare the (brief) presentation.

Guidelines

  • Try to fit into 5-7 minutes
    • Be specific, there is no need for general introductions
  • Briefly review the API and goals/non-goals
    • Quick reminder of key concepts
    • Changes since the initial version
  • Present interesting low-level design decisions
    • Is there something you are especially proud of?
  • What is the status of your tests?
    • Did you manage to integrate tests from the other teams?
    • How do these tests compare to your own tests?

Submission

Submit the presentation through your code repository (in the task-1 group) as a single PDF file named implementation.pdf placed in the .nprg043/presentations directory (i.e., the path from the repository root is .nprg043/presentations/implementation.pdf). You may want to keep a copy of the presentation elsewhere in the project if you want it to be part of the project structure (including source files used to produce the PDF), but the implementation.pdf file must be present in the .nprg043/presentations directory at deadline.

Full points will be awarded only if you submit presentation on time AND give a talk during the labs.

Please do tag your submission using the task-6-submission tag.

Split teams

If your team is split between two lab classes, you will be scheduled into the same lab class as during the API presentation.

If that is a problem, send an e-mail to the course instructor indicating during which lab class would you prefer to give your talk. Please note that your preference may be overriden for “load-balancing” purposes (if too many split teams indicate the same class).