This site is from a past semester! The current version will be here when the new semester starts.

Week 8 [Fri, Mar 3rd] - Project

iP:

  1. Evaluate two peer iPs before next week lecture

tP:

  1. Ensure you know tP expectations
  2. Start implementing v1.0
  3. Use GitHub to manage milestones
  4. Add some JUnit Tests

iP

1 Evaluate two peer iPs before next week lecture

This activity is worth 2x2=4 participation points.

  1. The allocation will be sent via email, by Monday 2359.

  2. Download the latest JAR file of the first iP by following the link provided.

    FAQ: What if the student has not uploaded a JAR file, or the JAR file doesn't work at all?
    A: When you submit the evaluation (step 7 below), there will be a way to indicate that the JAR was not available, or any other serious issues you faced.

  3. Locate the User Guide of the app by following the link provided.

  4. Open the Canvas survey (the one named iP Peer Evaluation 1) that you will be using to submit your evaluation and take note of the things you need to evaluate.

  5. Do a light testing of the app (not more than 10 minutes) to ensure the claimed features actually exist.
    Make sure you are using Java 11 to run the jar file (use java -version command to confirm).
    If double-clicking the jar file doesn't work, use the java -jar {file_name} command to open it.

  6. Do a quick examination of the code (~ 5 minutes) by following the provided link.

  7. Submit your evaluation using the survey.

  8. Repeat the above steps for the 2nd iP allocated to you (use the survey iP Peer Evaluation 2).

  9. Take note of the effort required for a typical iP: Now that you have seen two more iPs, you should now be in a better position to estimate how much you need to do for the tP (reason: the expected workload for the tP is that each team member puts in about one typical iP worth of effort).

tP: mid-v1.0

Lookout for these mistakes which were the most common in previous runs of the module:

  1. Not following the required phrasing style for the first sentence of Java method header comments.
  2. Not following the convention for Git commit message subject.
    Caution: This is near-impossible to rectify later, after PR containing the commits have been merged.
    Reason: While Git allows editing past commits, it changes their timestamp, which affects your weekly code contribution stats (which are factored into evaluating the consistency of your coding work over the project duration)

1 Ensure you know tP expectations

  • If you haven't done so already, make sure you know individual and team expectations of the tP

2 Start implementing v1.0

You may code from any of the below to be used in your tP, provided you give credit to the source (and do not claim such code as yours).

  • The iP code of any of your team members, or of any other person in the module.
  • Code from AddressBook-Level2 or any code used in module activities e.g., personbook

  • Start implementing v1.0, by adding code in small steps, while working in parallel, aiming to produce a VERY simple working version after one week, and a bit more functional version at the end of iteration (i.e., after two weeks).

  • See the panel below for our recommendations on the project workflow.

3 Use GitHub to manage milestones

  • We recommend using the GitHub issue tracker and its milestones feature to manage your project milestones, as explained in the following panels.

4 Add some JUnit Tests