Last updated on Friday, December 13, 2024

Unguided lab

This page describes the rules, submission, and grading for the unguided lab. See the write-up for a description of what the assignment is about and topic suggestions.

This callback counts towards your grade as explained in the course policies. Check the syllabus for deadlines.

Process

0. Read the rules below.

1. Form a team of 3 or 4 people and register it on Moodle by the team registration deadline.

   • We will create a team repository for you based on this information.
   • If you want, it can be the same team as for the unguided callback, unless you had a team of only 2.

2. Write a design proposal for your app and submit it by the proposal deadline by updating the README on the main branch of your team repository. The proposal should consist of the following:

   • User stories – 2 or 3 sentences – Describe user stories of your app using a who-when-what template, one story per sentence. Highlight interactions between users.
   • Requirements – 2 or 3 paragraphs – Describe what your app will do in concrete, detailed terms.
   • Mock-up – 1 or more pictures – Draw a rough hand-drawn sketch of what your app will look like, with labels to explain UI elements. If your app has multiple very different screens, draw a mock-up for each.
   • Roles – 1 sentence – Explain how tasks will be distributed among team members. (All team members are expected to contribute equal effort to the final result.) (See the SE lecture about specifications for examples.)

3. Implement and document your webapp, working only in the repository we created for you.

4. Submit your code on Moodle as a Git bundle (see § Submitting your code below).

5. Complete a brief individual self-assessment on Moodle.

6. Register on Moodle for a checkoff slot.

7. Receive your checkoff as a team from a staff member. This should take approximately 10 minutes (4 minutes + 1–2 minutes per person in the team). Be prepared to:

   1. Give an overview of your app. (1 slide presented in < 1 minute by team member #1)
   2. Explain the distribution of tasks among team members. (1 slide presented in < 1 minute by team member #2)
   3. Demo your app, by guiding the staff member as they use your app. (3–4 minutes, led by remaining team members)
   4. Answer individual questions on implementation challenges and give a tour of your code, Git history, tests, etc. as requested. (1–2 minutes per team member at the staff member’s request)

   Don’t run over: if you take 5 minutes to go through your two slides, you may be asked to skip the demo completely.

Submitting your code

Submission is on Moodle, as usual (one submission per team). To preserve your Git history, you will submit your work as a Git bundle: a single-file copy of a repository. Use the following command to create submission.bundle:

$ git bundle create submission.bundle --all

Make sure that your repository contains the following:

• A README file, named README.md (explained in the grading rubric below)
• A screenshot of your app, named apps/jvm/src/main/resources/www/static/<appId>.png
• Your code, as an SBT project as usual (build description in a top-level build.sbt, etc.)

The auto-grader on Moodle will just check your bundle and run your tests; the score that it returns is not used directly. If the code you submitted to Moodle doesn’t compile, you will get a 0 in the “Correctness” section in the rubric below.

Submission deadline

The submission deadline is Fri, Dec 13, 23:00.

We will grant an automatic 48-hour extension until Sun, Dec 15, 23:00 (unlike the usual 1-hour extension for other labs). No further extensions will be granted and no exceptions can be made. If you haven’t submitted any code to Moodle by then, you will get a 0.

Rules

• Each team member should have a clearly distinct task and should fully be in charge of their part of the code. It’s OK to help each other, but if one person does all the work, then the others won’t get points. Eventually, though, the whole team is responsible for the final result.
• Don’t cheat—it’s okay to discuss ideas with classmates, but don’t share code or discuss implementation details except with your teammates.
• Do not create your own repository: once you register your team, we will create a repository for you.
• You may use AI coding assistants, but be sure that you can explain the code during the checkoff, and remember that you won’t have access to AI on the final exam.
• Similarly, you may consult resources such as textbooks or reference websites, but you must cite them and be able to explain any code or ideas you took from them.
• You may use external libraries/dependencies, but you must cite them.

Topic choice

You may build any app you want, but:

• You must build one coherent app per team (not one tiny app per person).
• You must use the CS-214 webapp framework (without this, we will not be able to grade you fairly).
• You may read the provided webapp examples for inspiration or reference, but you may not use them as a starting point.
• Your app must be designed for meaningful interactions between two or more users, not just independent simultaneous use by many users (but it’s OK to have caps, e.g. a 2-player game is OK).
• Your app’s server-side logic must not be trivial (a wrapper around an existing chatbot would not be acceptable, but a 2-player chess app would be; see the FAQ for more examples).

Grading

The unguided lab is graded out of 20 points, based on the checkoff. Your lab score is the sum of your external and internal scores, as detailed below.

External score

The external score measures your progress towards a reasonably complete and bug-free app, out of 10 points.

• Completeness (how close you are to having a complete app)

  • App has all or almost all required functionality: 4 points
  • Some minor, secondary functionality missing: 3 points
  • Some significant functionality missing, but app is usable: 2 points
  • Major functionality missing, but some nontrivial implementation: 1 point
  • App achieves nothing or nearly nothing: 0 points

• Correctness (how well the parts that you did implement work)

  • Working demo with no or very minor defects: 4 points
  • Mostly working demo with minor defects: 3 points
  • Glitchy demo, but defects can be worked around: 2 points
  • Broken app, but some of the core functionality works: 1 point
  • Code submitted to Moodle is rejected by the grader, no code submitted on Moodle, or demo shows severe bugs: 0 points

• User documentation

  • README explains how to start the app and use it: 1 point
  • No README, or README unusable or clearly incomplete: 0 points

Exceptional, flawless demos of apps with a broad feature set may receive 1 additional point, bringing the total to 10.

Internal score

The internal score measures the quality of your code and your implementation of software-engineering best practices, out of 10 points:

• User stories
  • Relevant and representative of user needs: 1 point
  • Missing, irrelevant, or focused on implementation rather than needs: 0 points
• Requirements
  • Adequate, clear, reasonably complete, and capturing the main functionality of the app: 2 points
  • Vague, somewhat incomplete, or conflating implementation choices with functionality: 1 point
  • Missing, far from complete, entirely focused on implementation choices: 0 points
• Proposal scope
  • Appropriately scoped: 1 point
  • Too ambitious or too simple: 0 points
• Code quality
  • Clean, simple, functional code: 1 point
  • Overly complex, poorly organized, or overly stateful code: 0 points
• Internal documentation
  • Documentation on shared interfaces, require-ensuring annotations on tricky code: 1 point
  • Missing documentation or pre-/postconditions: 0 points
• Git history
  • Clean commits with detailed descriptions of changes, in staff-provided repository: 2 points
  • Clean commits without descriptions, in staff-provided repository: 1 point
  • Sloppy history, no Git history, or other repository used: 0 points
• Tests
  • Mostly complete: 2 points
  • Incomplete: 1 point
  • Not present or not compiling: 0 points

Grading notes

Prior to receiving a checkoff, each team member must fill an individual self-assessment questionnaire on Moodle. This helps us detect grading discrepancies, and it helps you reflect on your performance. Submitting a self-assessment is mandatory, but your answers will not affect your grade.

Scores are individual, per EPFL policy. We may adjust scores based on a review of overall grading patterns. The staff member giving you your checkoff may ask for a score review in corner cases.

The unguided lab is worth 90% of the overall unguided assignment score. (The other 10% comes from the unguided callback. Together, the unguided lab and callback make up 20% of the overall lab score. This is also explained in the course policies.)

If you are not satisfied with your score, you may challenge it. To do so, make a private post on Ed, and explain where you disagree from the original score. Include your two presentation slides and instructions on how to run your demo. A TA (PhD student) or professor will compile your code on their own machine based on your Moodle submission and decide on a new score. This score may end up being lower than the original one.

FAQ

Help! I don’t feel ready to write my own app.

Don’t panic:

• You will already be familiar with webapps, as this will be the second time you are building an app: the first will have been when you completed the last guided lab of the semester, webapp-rps, which uses the same framework but holds your hand through building one very specific app.

• You will be working in a team. Working together is a great way to tackle tricky problems.

• We have designed this lab to have a reasonable workload. The lab runs over 3.5 weeks and should not take you more time than what you usually dedicate to labs every week.

• We expect most of you will do very well, in the same way that most of you have done very well on the other labs. The grading scheme is designed to be generous.

What counts as meaningful interaction? What is non-trivial server-side logic?

The example apps listed above would all be acceptable. The following apps would count as trivial or as lacking interaction:

• A global billboard where any anonymous user can post and read all other posts;
• A wrapper around an existing chatbot that just relays messages back and forth between the user and the chatbot;
• A to-do list where every user has their own completely independent list;
• A connect-4 tournament where every user plays against the computer.

What counts as “clean commits”? What is a “sloppy history”?

To get all “Git history” points, make sure that you:

• Commit independent changes separately.
• Commit only relevant files (source code, not binaries generated by SBT).
• Use descriptive commit messages, and include a detailed description for nontrivial changes.

I want to focus on the lab. Can I skip lectures and exercises?

You do you, but the topics covered in lecture and practiced in the exercises will be on the final exam. Don’t think of this unguided lab as a massive project—it really shouldn’t take you more time than if we were doing a succession of normal guided labs. Don’t skip exercises and lectures for it.

Can we implement our own UI without using one of the provided UI classes?

Yes, but make sure that your app works in a reasonably modern browser, because that’s what our staff will use when giving check-offs.

Can we ask the course staff for help with our app?

Of course! But please do follow the guides we gave on asking good questions, because we have no idea what you’re working on until you tell us.

• For design questions: make sure that you have a clear, self-contained question, and a minimal example that demonstrates the problem you’re trying to solve. In most cases, we shouldn’t have to read your code at all to answer your question.

• For bugs: Make sure that you’ve applied the debugging guide. If you don’t tell us what you’ve already attempted and where you got stuck in applying the debugging method, we’ll just point you back to it.

Am I allowed to publish my app?

Most CS-214 course materials and lab templates are provided to you under a license that does not allow redistribution: for example, you cannot post your completed labs online, even after the end of the semester.

However, for the unguided lab, we will allow some forms of redistribution after the end of the semester, such as publishing your webapp and its source code on your personal website—under the condition that you grant the instructors and EPFL permission to showcase your app in the course (e.g. on the course website), potentially publicly and indefinitely.

If you object, you can receive the webapp library under the usual course license: we won’t be able to showcase your work and neither will you. In that case, please write a private message to the course staff on Ed.

© 2023, 2024 EPFL. All rights reserved.