This site is from a past semester! The current version will be here when the new semester starts.
TIC4001 2020
**Schedule**
  • 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
    • **Links**
  • 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
    •

    • Week 3 [Fri, Aug 21st] - Project

    iP:

    1. Do any leftover iP tasks from the previous week
    2. Create a PR to the upstream repo by the end of the lecture
    3. Add Increments: Level-4, A-TextUiTesting, A-CodingStandard

    tP:

    1. Set up a project meeting time by the end of the lecture

    iP

    1 Do any leftover iP tasks from the previous week

    • Remember to do any leftover increments from the past weeks before starting on the current week's increments. This guideline applies to future weeks too.

    2 Create a PR to the upstream repo by the end of the lecture

    • Create a pull request (PR) from your fork to the upstream repo. Note the following:
      • Create the PR from the master branch of your fork to the master branch of the upstream repo (https://github.com/nus-tic4001-AY2021S1/ip)
      • Set the PR name as [{Your name}] iP e.g., [John Doe] iP If you are reluctant to give full name, you may give the first half of your name only.
        You may leave the description as empty.
      • Steps for creating a PR is given in this textbook topic (steps 5 onwards):

    Suppose you want to propose some changes to a GitHub repo (e.g., samplerepo-pr-practice) as a pull request (PR). Here is a scenario you can try in order to learn how to create PRs:

    A pull request (PR for short) is a mechanism for contributing code to a remote repo, i.e., "I'm requesting you to pull my proposed changes to your repo". For this to work, the two repos must have a shared history. The most common case is sending PRs from a fork to its upstream repo is a repo you forked fromupstream repo.

    1. Fork the repo onto your GitHub account.

    2. Clone it onto your computer.

    3. Commit your changes e.g., add a new file with some contents and commit it.

    • Option A - Commit changes to the master branch
    • Option B - Commit to a new branch e.g., create a branch named add-intro (remember to switch to the master branch before creating a new branch) and add your commit to it.

    4. Push the branch you updated (i.e., master branch or the new branch) to your fork, as explained here.

    Pushing a branch to a remote repo

    Here's how to push a branch to a remote repo:

    Here's how to push a branch named add-intro to your own fork of a repo named samplerepo-pr-practice:

    Normally: git push {remote repository} {branch}. Examples:

    • git push origin master pushes the master branch to the repo named origin (i.e., the repo you cloned from)
    • git push upstream-repo add-intro pushes the add-intro branch to the repo named upstream-repo

    If pushing a branch you created locally to the remote for the first time, add the -u flag to get the local branch to track the new upstream branch:
    e.g., git push -u origin add-intro

    See git-scm.com/docs/git-push for details of the push command.

    5. Initiate the PR creation:

    1. Go to your fork.

    2. Click on the Pull requests tab followed by the New pull request button. This will bring you to the 'Comparing changes' page.

    3. Set the appropriate target repo and the branch that should receive your PR, using the base repository and base dropdowns. e.g.,
      base repository: se-edu/samplerepo-pr-practice base: master

      Normally, the default value shown in the dropdown is what you want but in case your fork has e.g., the repo you forked from is also a fork of a another repo, which means both of those are considered upstream repos of your forkmultiple upstream repos, the default may not be what you want.

    4. Indicate which repo:branch contains your proposed code, using the head repository and compare dropdowns. e.g.,
      head repository: myrepo/samplerepo-pr-practice compare: master

    6. Verify the proposed code: Verify that the diff view in the page shows the exact change you intend to propose. If it doesn't, commit the new code and push to the branchupdate the branch as necessary.

    7. Submit the PR:

    1. Click the Create pull request button.

    2. Fill in the PR name and description e.g.,
      Name: Add an introduction to the README.md
      Description:

      Add some paragraph to the README.md to explain ...
      Also add a heading ...

    3. If you want to indicate that the PR you are about to create is 'still work in progress, not yet ready', click on the dropdown arrow in the Create pull request button and choose Create draft pull request option.

    4. Click the Create pull request button to create the PR.

    5. Go to the receiving repo to verify that your PR appears there in the Pull requests tab.

    The next step of the PR life cycle is the PR review. The members of the repo that received your PR can now review your proposed changes.

    • If they like the changes, they can merge the changes to their repo, which also closes the PR automatically.
    • If they don't like it at all, they can simply close the PR too i.e., they reject your proposed change.
    • In most cases, they will add comments to the PR to suggest further changes. When that happens, GitHub will notify you.

    You can update the PR along the way too. Suppose PR reviewers suggested a certain improvement to your proposed code. To update your PR as per the suggestion, you can simply modify the code in your local repo, commit the updated code to the same master branch, and push to your fork as you did earlier. The PR will auto-update accordingly.

    Sending PRs using the master branch is less common than sending PRs using separate branches. For example, suppose you wanted to propose two bug fixes that are not related to each other. In that case, it is more appropriate to send two separate PRs so that each fix can be reviewed, refined, and merged independently. But if you send PRs using the master branch only, both fixes (and any other change you do in the master branch) will appear in the PRs you create from it.

    To create another PR while the current PR is still under review, create a new branch (remember to switch back to the master branch first), add your new proposed change in that branch, and create a new PR following the steps given above.

    It is possible to create PRs within the same repo e.g., you can create a PR from branch feature-x to the master branch, within the same repo. Doing so will allow the code to be reviewed by other developers (using PR review mechanism) before it is merged.

    The PR will update automatically to reflect your latest code every time you push code to your fork. As a result, it provides a convenient way for us to access the current state of all your iP code from one location.

    Pull Requests is a mechanism for offering code to a repository e.g., a bug fix or a new feature. PRs allow developers to review, discuss, and refine proposed code changes before incorporating (i.e., merging) the new code to the repository.

    Resources:

    3 Add Increments: Level-4, A-TextUiTesting, A-CodingStandard

    Duke Level-4: ToDo, Event, Deadline

    Level 4. ToDos, Events, Deadlines

    Add support for tracking three types of tasks:

    1. ToDos: tasks without any date/time attached to it e.g., visit new theme park
    2. Deadlines: tasks that need to be done before a specific date/time e.g., submit report by 11/10/2019 5pm
    3. Events: tasks that start at a specific time and ends at a specific time e.g., team project meeting on 2/10/2019 2-4pm

    Example:

    todo borrow book
        ____________________________________________________________
         Got it. I've added this task: 
           [T][✗] borrow book
         Now you have 5 tasks in the list.
        ____________________________________________________________

    list
        ____________________________________________________________
         Here are the tasks in your list:
         1.[T][✓] read book
         2.[D][✗] return book (by: June 6th)
         3.[E][✗] project meeting (at: Aug 6th 2-4pm)
         4.[T][✓] join sports club
         5.[T][✗] borrow book
        ____________________________________________________________

    deadline return book /by Sunday
        ____________________________________________________________
         Got it. I've added this task: 
           [D][✗] return book (by: Sunday)
         Now you have 6 tasks in the list.
        ____________________________________________________________

    event project meeting /at Mon 2-4pm
        ____________________________________________________________
         Got it. I've added this task: 
           [E][✗] project meeting (at: Mon 2-4pm)
         Now you have 7 tasks in the list.
        ____________________________________________________________

    At this point, dates/times can be treated as strings; there is no need to convert them to actual dates/times.

    Example:


    deadline do homework /by no idea :-p
        ____________________________________________________________
         Got it. I've added this task: 
           [D][✗] do homework (by: no idea :-p)
         Now you have 6 tasks in the list.
        ____________________________________________________________

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

    A-Inheritance

         ↳ Use Inheritance to support multiple task types

    As there are multiple types of tasks that have some similarity between them, you can implement classes Todo, Deadline and Event classes to inherit from a Task class.

    Furthermore, use polymorphism to store all tasks in a data structure containing Task objects e.g., Task[100].

    public class Deadline extends Task {

        protected String by;

        public Deadline(String description, String by) {
            super(description);
            this.by = by;
        }

        @Override
        public String toString() {
            return "[D]" + super.toString() + " (by: " + by + ")";
        }
    }
    Task[] tasks = new Task[100];
    task[0] = new Deadline("return book", "Monday");
    Duke A-TextUiTesting: Automated Text UI Testing optional

    A-TextUiTesting

         ↳ Test using the I/O redirection technique

    Use the input/output redirection technique to semi-automate the testing of Duke.

    Notes:

    • A tutorial of this technique is here.
    • The required scripts are provided in the Duke repo (see the text-ui-test folder).
    Duke A-CodingStandard: Follow the Coding Standard

    A-CodingStandard

         ↳ Tweak the code to comply with a coding standard

    Tweak the code to comply with a given coding standard. From this point onward, ensure any new code added are compliant with the given coding standard.

    tP: Kickoff

    1 Set up a project meeting time by the end of the lecture

    • After forming teams, set up a weekly project meeting time/venue (and communication channels) with your team members:

    Team Communications

    • Use English for all team communications, both spoken and written.

    • We recommend at least one 1-2 hour synchronous online project meeting per week, in addition to any asynchronous communicating. Reason: Having all members available at the same time will facilitate easier collaboration and more peer-learning.

      • Fix a weekly 1-2 hour time slot and a venue for project meetings after the team has been finalized (latest by the end of week 3 lecture). All members are expected to attend weekly project meetings (not doing so could lower the peer evaluation ratings you receive, which in turn will be factored into your grade).
      • The best time for the weekly project meeting is the period Saturday, Sunday, Monday, Tuesday i.e., soon after the lecture but well ahead of the deadline for weekly tasks. Reason: After the lecture → you'll have the knowledge required for upcoming project tasks; before the deadline → you can use the meeting to deal with weekly project tasks.