This site is from a past semester! The current version will be here when the new semester starts.
TIC4001 2020
  • Full Timeline
  • Week 1 [Mon, Aug 10th]
  • Week 2 [Fri, Aug 14th]
  • Week 3 [Fri, Aug 21st]
  • Week 4 [Fri, Aug 28th]
  • Week 5 [Fri, Sep 4th]
  • Week 6 [Fri, Sep 11th]
  • Week 7 [Fri, Sep 18th]
  • Week 8 [Fri, Oct 2nd]
  • Week 9 [Fri, Oct 9th]
  • Week 10 [Fri, Oct 16th]
  • Week 11 [Fri, Oct 23rd]
  • Week 12 [Fri, Oct 30th]
  • Week 13 [Fri, Nov 6th]
  • Textbook
  • Admin Info
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Java Coding Standard
  • Git Conventions
  • Participation Dashboard

  •  Individual Project (iP):
  • Individual Project Info
  • iP List
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • iP: Week 3iP: Week 5


    iP: Week 4

    1. Add Increments as branches: Level-5, A-CodeQuality, A-AbstractClasses, A-Packages
    2. Review some peer PRs counted for participation

    1 Add Increments as branches: Level-5, A-CodeQuality, A-AbstractClasses, A-Packages

    • Do each increment as a Git branch. Here is an example:
      • Start a branch named branch-{increment ID} (e.g. branch-Level-5). You are recommended to have multiple commits in that branch. Follow the branch naming convention exactly or else our gradings scripts might miss your branch.
      • After the increment is ready, merge the branch-Level-5 back on to master, without a fast-forward so that git creates a separate commit for the merge. git tag that merge commit as Level-5.
      • Push the branch to your fork so that the bot can detect it. As before, push the tag as well.
      • Advanced git users: do not delete the branch after merging.
    Duke Level-5: Handle Errors

    Level 5. Handle Errors

    Teach Duke to deal with errors such as incorrect inputs entered by the user.

    Example:

    todo
    ____________________________________________________________
    ☹ OOPS!!! The description of a todo cannot be empty.
    ____________________________________________________________

    blah
    ____________________________________________________________
    ☹ OOPS!!! I'm sorry, but I don't know what that means :-(
    ____________________________________________________________

    When implementing this feature, you are also recommended to implement the following extension:

    A-Exceptions

         Use Exceptions to handle errors

    Use exceptions to handle errors. For example, define a class DukeException to represent exceptions specific to Duke.

    • Minimal: handle at least the two types of errors shown in the example above.
    • Stretch goal: handle all possible errors in the current version. As you evolve Duke, continue to handle errors related to the new features added.
    Duke A-CodeQuality: Improve Code Quality

    A-CodeQuality

         Improve code quality

    Critically examines the code and refactor to improve the code quality where necessary.

    When adding this increment, follow closely the 'Code Quality' topics you have learned so far, rather than merely follow your own intuition about code quality.

    Duke A-AbstractClasses: Use Abstract Classes

    A-AbstractClasses

         Use abstract classes

    Make the Task class an abstract class. If applicable, use abstract methods as well.

    Duke A-Packages: Organize into Packages

    A-Packages

         Divide classes into packages

    Organize the classes into suitable java packages.

    • Minimal: put all classes in one package e.g., duke
    • Stretch goal: divide into multiple packages as the number of classes increase e.g., duke.task, duke.command

    2 Review some peer PRs counted for participation

    Please wait till Mon, Aug 31st to start this task, to give others a few extra days to create the PR if they haven't done so yet.

    This task is worth 2x2=4 participtaion points.

    • Learn how you should review PRs in this task:
    Video

    The PR review stage is a dialog between the PR author and members of the repo that received the PR, in order to refine and eventually merge the PR.

    Given below are some steps you can follow when reviewing a PR.

    1. Locate the PR:

    1. Go to the GitHub page of the repo.
    2. Click on the Pull requests tab.
    3. Click on the PR you want to review.

    2. Read the PR description. It might contain information relevant to reviewing the PR.

    3. Click on the Files changed tab to see the diff view.

    4. Add review comments:

    1. Hover over the line you want to comment on and click on the icon that appears on the left margin. That should create a text box for you to enter your comment.
      To mark multiple lines, click-and-drag the icon.
    2. Enter your comment.
      This page @SE-EDU/guides has some best practices PR reviewers can follow.
    3. After typing in the comment, click on the Start a review button (not the Add single comment button. This way, your comment is saved but not visible to others yet. It will be visible to others only when you have finished the entire review.

    4. Repeat the above steps to add more comments.

    5. Submit the review:

    1. When there are no more comments to add, click on the Review changes button (on the top right of the diff page).
    2. Type in an overall comment about the PR, if any. e.g.,
      Overall, I found your code easy to read for the most part except a few places
      where the nesting was too deep. I noted a few minor coding standard violations
      too. Some of the classes are getting quite long. Consider splitting into smaller
      classes if that makes sense.
      LGTM is often used in such overall comments, to indicate Looks good to merge.
      nit is another such term, used to indicate minor flaws e.g., LGTM, almost. Just a few nits to fix..
    3. Choose Approve, Comment, or Request changes option as appropriate and click on the Submit review button.

    • Step 1 Note these additional guidelines:

      • Read the Best practices for reviewing PRs @SE-EDU/guides. You are expected to follow all of them.
      • If the PR has received some review comments already, feel free to confirm/complement/question those comments in your review. Also, look for things the previous reviewers may have missed.
      • At the end of the review, choose Comment (i.e., not Approve or Request changes)
    • Step 2 Do the first PR review as follows.

      • Comment on coding standard violations only.
      • The review allocation is given in the panel below.
    Tutorial Reviewer First PR to review Backup PR to review
    TIC4001-F18 JanuariusJang ZhengShijieNUS Chilaiping
    TIC4001-F18 Yiheng0410 pigoliver Impala36
    TIC4001-F18 Chilaiping dgc5213 binbinhui
    TIC4001-F18 e0260222 daiweinus adi-kd0021
    TIC4001-F18 Chenduo1412 e0260222 daiweinus
    TIC4001-F18 skyventus tototto JanuariusJang
    TIC4001-F18 Impala36 e02161618 Chenduo1412
    TIC4001-F18 daiweinus adi-kd0021 linqing42
    TIC4001-F18 dgc5213 binbinhui Yiheng0410
    TIC4001-F18 tototto JanuariusJang ZhengShijieNUS
    TIC4001-F18 e02161618 Chenduo1412 e0260222
    TIC4001-F18 timmyly7 skyventus tototto
    TIC4001-F18 adi-kd0021 linqing42 timmyly7
    TIC4001-F18 binbinhui Yiheng0410 pigoliver
    TIC4001-F18 linqing42 timmyly7 skyventus
    TIC4001-F18 ZhengShijieNUS Chilaiping dgc5213
    TIC4001-F18 pigoliver Impala36 e02161618

    If the student you have been allocated to review has not created a PR (or the PR has a trivial amount of code), you can review the Backup PR to review provided in the allocation table. Failing both, pick a PR at random to review.

    • Step 3 Do the second PR review as follows.
      • Comment on other code quality guidelines (see the sections on Naming and Readability in this textbook chapter) you have learned so far. It's optional to comment on coding standard violations in this PR review.
      • The review allocation is given in the panel below.
    Tutorial Reviewer Second PR to review Backup PR to review
    TIC4001-F18 JanuariusJang dgc5213 binbinhui
    TIC4001-F18 Yiheng0410 e02161618 Chenduo1412
    TIC4001-F18 Chilaiping Yiheng0410 pigoliver
    TIC4001-F18 e0260222 linqing42 timmyly7
    TIC4001-F18 Chenduo1412 adi-kd0021 linqing42
    TIC4001-F18 skyventus ZhengShijieNUS Chilaiping
    TIC4001-F18 Impala36 e0260222 daiweinus
    TIC4001-F18 daiweinus timmyly7 skyventus
    TIC4001-F18 dgc5213 pigoliver Impala36
    TIC4001-F18 tototto Chilaiping dgc5213
    TIC4001-F18 e02161618 daiweinus adi-kd0021
    TIC4001-F18 timmyly7 JanuariusJang ZhengShijieNUS
    TIC4001-F18 adi-kd0021 skyventus tototto
    TIC4001-F18 binbinhui Impala36 e02161618
    TIC4001-F18 linqing42 tototto JanuariusJang
    TIC4001-F18 ZhengShijieNUS binbinhui Yiheng0410
    TIC4001-F18 pigoliver Chenduo1412 e0260222

    If the allocated PR is not suitable, use the same strategy as before to find an alternative PR to review.

    • Step 4 [When you receive reviews for your own PR] Respond to comments received. You are recommended to (but not obliged to) respond to comments received from peers, especially if the PR reviewer asked you for more info. As mentioned in these guidelines, do not get into arguments with PR reviewers/authors.


    iP: Week 3iP: Week 5