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 7 [Fri, Sep 18th] - Project

    iP:

    1. Set up a product website
    2. Submit the final version Mon, Sep 28th 2359

    tP:

    1. Set up the project repo during the lecture
    2. Practice the workflow with a sample repo
    3. Plan the next iteration

    iP

    1 Set up a product website

    • Add a brief User Guide (UG)
    Duke A-UserGuide: User Guide

    A-UserGuide

         ↳ Add a User Guide

    Add a User Guide to the project. Here is one simple way to do it.

    • Update the given docs\README.md. See this guide to GitHub flavored Markdown (GFMD).
    • Go to the settings page of your Duke fork and enable GitHub pages to publish from the docs folder (you can select a theme too).
    • Go to http://{your username}.github.io/{repo name}/ to view the user guide of your product. Note: it could take 5-10 minutes for GitHub to update the page.

    2 Submit the final version Mon, Sep 28th 2359

    • Create a new jar file
      • Create the JAR file in one of these ways:
        • If you have added a GUI or using third-party libraries: use Gradle.
        • Else: you can use Intellij.
      • The JAR file should be cross-platform and should work in a computer that has Java 11.
    • Do the following smoke tests to ensure the jar file works (reason: a similar flow will be used when grading your iP).
      1. Copy the jar file to an empty folder and test it from there. This should surface issues with hard-coded file paths.
      2. Pass the jar file to team members and ask them to do a test drive. Assuming some of your team members' OS differ from yours, this should verify if the app is cross-platform.
    • Create a new release on GitHub (e.g., v0.2) and upload the JAR file.
      • Recommended to refrain from uploading multiple JAR files as this can cause extra work for the evaluators.
    Duke A-Release: Release

    A-Release

         ↳ Release the product

    Release the product to be used by potential users. e.g., you can make it available on GitHub

    tP: Get ready for iterations

    1 Set up the project repo during the lecture

    • Set up the team org, the team repo, and individual forks as explained below:

    tP Team Organization Setup

    Please follow the organization/repo name format precisely or else our grading scripts will not be able to detect your work.

    (/) Only one team member:

    After receiving your team ID, one team member should do the following steps:

    • Create a GitHub organization with the following details:
      • Organization name (all UPPER CASE) : AY2021S1-TEAM_ID. e.g.  AY2021S1-TIC4001-2
      • Plan:  Open Source ($0/month)
      • This organization belongs to: My personal account
    • Add members to the organization:
      • Create a team called developers to your organization.
      • Add your team members to the developers team.

    tP Team Repo Setup

    (/) Only one team member:

    The tP project template given to you is a variation of the iP repo you used for the iP, but with some important differences. Please follow instructions carefully, rather than follow what you remember from the iP.

    1. Fork the https://github.com/nus-tic4001-AY2021S1/tp repo to your team org.

      • This repo (let's call it the team repo) is to be used as the repo for your project.
      • Please do not rename the fork Reason: our grading scripts rely on the repo name.

    2. Enable the issue tracker.

    3. Enable GitHub Actions: Go to the Actions tab and enable workflows by clicking the button. That will enable the GitHub Actions that are already included in the repo you forked.

    4. Enable GitHub Pages: Go to the Settings tab and enable GitHub Pages for the master branch /docs folder (similar to how you did it in the iP).
      Remember to choose a theme too by clicking the button (that will create a commit in your repo that is needed in a later step.
      After a few minutes, confirm your tP website is available in the corresponding github.io URL.

    5. Add members. Ensure your team members have the desired level of access to your team repo.
      Recommended: Give admin access to 1-2 members and write access to others.

    6. Create a team PR for us to track your project progress: i.e., create a PR from your team repo master branch to [nus-tic4001-AY2021S1/tp] master branch. PR name: [Team ID] Product Name e.g., [TIC4001-2] Contact List Pro. As you merge code to your team repo's master branch, this PR will auto-update to reflect how much your team's product has progressed.
      Please fill in these details as specified because they are used by our grading scripts.

      • PR subject: the name of your product e.g., InsureList
      • Description: a 1-2 sentence overview (plain text only, no formatting or links) of your project indicating the target user and the value proposition e.g., InsureList helps insurance agents manage detail of their clients. It is optimized for CLI users so that frequent tasks can be done faster by typing in commands.

    tP Individual Fork Setup

    (, , , ...) Every team member:

    1. Watch the tP repo (created above) i.e., go to the repo and click on the button to subscribe to activities of the repo.
    2. Fork the tP repo to your personal GitHub account.
      Please do not rename the fork Reason: our grading scripts rely on the repo name.
    3. Clone the fork to your computer.
    4. Set up the developer environment in your computer by following the the README carefully as the steps are different from the iP.

    Do not alter these paths in your project as our grading scripts depend on them.

    • src/main/java
    • src/test/java
    • docs

    2 Practice the workflow with a sample repo

    • We recommend that you practice the forking workflow with your team members as described in the textbook section given in the panel below.
      You can use your tP GitHub org for this exercise too.

    You can follow the steps in the simulation of a forking workflow given below to learn how to follow such a workflow.

    This activity is best done as a team.

    Step 1. One member: set up the team org and the team repo.

    1. Create a GitHub organization for your team. The org name is up to you. We'll refer to this organization as team org from now on.

    2. Add a team called developers to your team org.

    3. Add team members to the developers team.

    4. Fork se-edu/samplerepo-workflow-practice to your team org. We'll refer to this as the team repo.

    5. Add the forked repo to the developers team. Give write access.

    Step 2. Each team member: create PRs via own fork.

    1. Fork that repo from your team org to your own GitHub account.

    2. Create a branch named add-{your name}-info (e.g. add-johnTan-info) in the local repo.

    3. Add a file yourName.md into the members directory (e.g., members/jonhTan.md) containing some info about you into that branch.

    4. Push that branch to your fork.

    5. Create a PR from that branch to the master branch of the team repo.

    Step 3. For each PR: review, update, and merge.

    1. [A team member (not the PR author)] Review the PR by adding comments (can be just dummy comments).

    2. [PR author] Update the PR by pushing more commits to it, to simulate updating the PR based on review comments.

    3. [Another team member] Approve and merge the PR using the GitHub interface.

    4. [All members] Sync your local repo (and your fork) with upstream repo. In this case, your upstream repo is the repo in your team org.

    Step 4. Create conflicting PRs.

    1. [One member]: Update README: In the master branch, remove John Doe and Jane Doe from the README.md, commit, and push to the main repo.

    2. [Each team member] Create a PR to add yourself under the Team Members section in the README.md. Use a new branch for the PR e.g., add-johnTan-name.

    Step 5. Merge conflicting PRs one at a time. Before merging a PR, you’ll have to resolve conflicts.

    1. [Optional] A member can inform the PR author (by posting a comment) that there is a conflict in the PR.

    2. [PR author] Resolve the conflict locally:

      1. Pull the master branch from the repo in your team org.
      2. Merge the pulled master branch to your PR branch.
      3. Resolve the merge conflict that crops up during the merge.
      4. Push the updated PR branch to your fork.

    3. [Another member or the PR author]: Merge the de-conflicted PR: When GitHub does not indicate a conflict anymore, you can go ahead and merge the PR.

    3 Plan the next iteration

    • Plan the next iteration. As you know, you should follow the breadth-first iterative process. Therefore, first you must decide what functionalities should be in the product if you had only two weeks to implement it. You have done that already when you chose user stories for v1.0, translated that to features, and even drafted the UG based on those features. You can tweak that plan further at this point if you wish, given that you now have some idea of how fast the team can work when using the prescribed workflow.
      • Aim to produce a working MVP at the end of this iteration even if the functionalities are not polished (polishing can be done in a later iteration).
      • If possible, break the iteration into two increments i.e., aim to produce an even simpler but working version after one week.
      • Avoid depth-first implementations: "I'll do the back-end part of feature X in this iteration" is not acceptable as that is not in the spirit of iterative development. Remember, we are pretending this to be the last iteration; why would you implement the back-end part of a feature in the last iteration?
        It is OK to add simpler versions of bigger features, but not OK to add partial features that can't be used yet.
    • Divide the work among the team members i.e., the work required for the current iteration.
    • Reflect the above plan in the issue tracker by assigning the corresponding issues (create new issues if necessary) to yourself and to the corresponding milestone. For example, the user story pertaining to the increment show a place holder for photo, showing a generic default image should be assigned to Jake and to milestone v1.0
      Optionally, you can define a mid-v1.0 milestone to keep track of things to be done within the first half of the milestone.