This site is not ready yet! The updated version will be available soon.
CS2103/T 2020 Jan-Apr
  • Full Timeline
  • Week 1 [Aug 12]
  • Week 2 [Aug 19]
  • Week 3 [Aug 26]
  • Week 4 [Sep 2]
  • Week 5 [Sep 9]
  • Week 6 [Sep 16]
  • Week 7 [Sep 30]
  • Week 8 [Oct 7]
  • Week 9 [Oct 14]
  • Week 10 [Oct 21]
  • Week 11 [Oct 28]
  • Week 12 [Nov 4]
  • Week 13 [Nov 11]
  • Textbook
  • Admin Info
  • Report Bugs
  • Forum
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • Java Coding Standard
  • Participation Marks List

  •  Individual Project (iP):
  • Individual Project Info
  • Duke Upstream Repo
  • iP Code Dashboard
  • iP Showcase

  •  Team Project (tP):
  • Team Project Info
  • Team IDs
  • Addressbook-level3
  • Addressbook-level 1,2,4
  • tP Code Dashboard
  • tP Showcase
  • Week 4 [Sep 2] - Summary

    We strongly recommend you to have a team project meeting before the tutorial. Do the following during the meeting:

    • Finish the tP tasks allocated for the week. For example, if you don't have a preliminary project idea by this week's tutorial (as per the tP schedule), the tutor will not be able to give feedback on it.
      • Note that the timeliness of tP tasks (i.e., the deadline is the midnight before the tutorial) is graded under the project management component of the tP.
      • Keep notes of the meeting, and update project documents -- the tutor will ask for those during the tutorial.
    • Help each other finish iP tasks. Tasks allocated to this week are especially troublesome and some peer help can be very useful.
    • If you can, do the post-lecture quiz together; while the deadline for the quiz is Thursday midnight, doing it before the tutorial will help you identify unclear areas, which you can then clarify during the tutorial.

    Dealing with technical problems: Unlike tutorial questions for which instructors have model solutions, given the complexity of industry tools we use (Gradle, Travis, Git, ...) and the rapid pace they are updated, instructors don't have ready solutions to most technical problems you face in this module. The only realistic way to solve those problems at a large scale is crowd-sourcing i.e., someone else who faced a similar problem might know how to fix it. Here are some tips:

    • Don't request to meet the prof/tutor to solve the problem. That can only work if the person is supposed to know how to solve all technical problems, which is not the case.
    • Often, technical problems arise due to deviations in how you perform a step or a difference in your environment. Get your team to meet for a weekly work-together session. When you do the iP tasks together, it is easy to compare with each other and figure out what deviation is causing the problem. That is, crowd-source your team first.
    • Failing the above, post in the forum.
      • Give full details of the problem e.g., screenshots, code snippets, stack traces, etc.
      • If the problem is code-related, push the current state of the code to a branch and give the link to the branch. That gives a chance for someone to reproduce the state of your project in their computer.
      • Avoid addressing the question to one person (e.g., the prof), unless really necessary. Doing so will discourage others from answering that question.
      • Remember to thank those you try to help, and close the issue after the issue has been resolved.
    • Failing the above, raise the issue during the tutorial. Perhaps someone in the other team knows how to fix it.
    • Some technical problems can take a longer time to resolve. Therefore, plan ahead and schedule your work much earlier than the deadline.
    • Some problems might not get resolved at all; while waiting for a solution, explore alternatives and workarounds.

    Further reading:

    Relevant: [Admin Appendix D: How to Get Help ]

    C: Frequently Asked Questions E: Using GitHub

    D: Getting help in this module

    This guide is mostly about getting tech help, but it also applies to getting clarifications on module topics too. e.g. what is the difference between refactoring and rewriting?

    We want to move you away from 'hand holding' and make you learn how to solve problems on your own. This is a vital survival skill in the industry and it needs practice.

    Whether it is a technical problem (e.g. error when using the IDE) or a doubt about a concept (e.g. what is the difference between scripted testing and exploratory testing?)  the teaching team is happy to work with you when you look for a solution/answer, but we do not do it for you. We discourage unconditional direct help from tutors because we want you to learn to help yourself. Yes, we believe in ‘tough love’😝.

    The question you should always ask yourself is, 'how do I solve this problem if the lecturer/tutors are not around to help me?'

    What not to do:

    • Send a help request to an instructor: When faced with a technical problem or a doubt about a concept, don't fire off an email lecturer/tutor immediately, unless it is something only the lecturer/tutor is supposed to know.

    What to do:

    • Check what is given: Check if the problem/concept has been discussed in the lectures, textbook, or the list of resources given to you. Yes, it is easier for you to write an email to the tutor/lecturer instead, but that shouldn't be your default behavior. We know that sometimes it is difficult to find stuff in the resources we have provided. But you should try first.

    • Search: It is very likely the answer already exists somewhere in the cyberspace. Almost every programming-related question has been answered in places like stackoverflow. Don't give an opportunity for someone to ask you to STFW.
      Pay attention to the error message you encounter. Sometimes it also contains hints as to how to fix the problem. Even if not, a web search on the error message is a good starting point.  

    • Ask peers:

      Ask your team members.

      Ask classmates using the module forum. Even if you figured out one way to solve a problem, discussing it on a public forum might lead you to better ways of solving it, and will help other classmates who are facing similar problems too. If you are really shy to ask questions in the forum, you may use this form to submit your question anonymously which we will then post in the forum.

      Rubber duck debugging is an informal term used in software engineering to refer to a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug his code by forcing himself to explain it, line-by-line, to the duck.

      [for more, see wikipedia entry]

    • Ask the world using programming forums such as stackoverflow.

      Here are some tips for posting help request:

      • PLEASE search for existing answers before you post your question in those public forums; You don't want to appear as a 'clueless' or 'too lazy to do your research' person in a public forum.

      • Learn to isolate the problem. "My code doesn't work" isn't going to help even if you post the whole code online. Others don't have time to go through all of your code. Isolate the part that doesn't work and strip it down to the bare minimum that is enough reproduce the error. Sometimes, this process actually helps you to figure out the problem yourself. If not, at least it increases the chance of someone else being able to help you.

        How to isolate problematic code? Delete code (one bit at a time) that is confirmed as not related to the problem. Do that until you can still reproduce the problem with the least amount of code remaining.

      • Generalize the problem. "How to write tasks to a text file using Java" is too specific to what you are working on. You are more likely to find help if you post a thread called (or search for) "How to write to a file using Java".

      • Explain well. Conversations via online forums take time. If you post everything that is relevant to your problem, your chances of getting an answer in the first try is higher. If others have to ask you more questions before they can help you, it will take longer. But this doesn't mean you dump too much information into the thread either.

        Know what these stand for: RTFM, STFW, GIYF

    • Raise your question during a tutorial. Some questions can be discussed with the tutor and tutorial-mates. What kind of questions are suitable to discuss with the tutor? Consider these two questions you might want to ask a tutor:
      • Good This is how I understood/applied coupling. Is that correct? - Such questions are welcome. Reason:This question shows you have put in some effort to learn the topic and seeking further clarification from the tutor.
      • Bad What is coupling? - Such questions are discouraged. Reason: This question implies you haven’t done what you could to learn the topic in concern.
    • Talk to the lecturer before or after the lecture. The lecturer will be at the lecture venue from 30 minutes before the start of the lecture.

    • Request our help: Failing all above, you can always request for help by emailing the lecturer.


    C: Frequently Asked Questions E: Using GitHub

    • [W4.1] Design: Models

    • [W4.2] Class/Object Diagrams: Basics

    • [W4.3] Class Diagrams: Intermediate-Level

    • [W4.4] Java: JavaFX

    • [W4.5] Java: varargs

    • [W4.6] RCS: Managing Pull Requests

    • [W4.7] Code reviews

    • [W4.8] Static Analysis

    • [W4.1] Design: Models
    • [W4.1a] Design → Modelling → Introduction → What

    • [W4.1b] Design → Modelling → Introduction → How

    • [W4.1c] Design → Modelling → Introduction → UML Models

    • [W4.2] Class/Object Diagrams: Basics
    • [W4.2a] Design → Modelling → Modelling Structure → OO Structures

    • [W4.2b] Design → Modelling → Modelling Structure → Class Diagrams (Basics)

    • [W4.2c] Design → Modelling → Modelling Structure → Object Diagrams

    • [W4.2d] Tools → UML → Object vs Class Diagrams

    • [W4.3] Class Diagrams: Intermediate-Level
    • [W4.3a] Tools → UML → Notes

    • [W4.3b] Tools → UML → Constraints

    • [W4.3c] Tools → UML → Class Diagrams → Associations as Attributes

    • [W4.3d] Design → Modelling → Modelling Structure → Class Diagrams - Intermediate

    • [W4.3e] Paradigms → OOP → Associations → Association Classes

    • [W4.4] Java: JavaFX
    • [W4.4a] Tools → Java → JavaFX
    • [W4.5] Java: varargs
    • [W4.5a] Tools → Java → Varargs :

    • [W4.6] RCS: Managing Pull Requests
    • [W4.6a] Tools → Git and GitHub → Manage PRs

    • [W4.7] Code reviews
    • [W4.7a] Quality Assurance → Quality Assurance → Code Reviews → What
    • [W4.8] Static Analysis
    • [W4.8a] Quality Assurance → Quality Assurance → Static Analysis → What


    1. Accept GitHub invitation from the module organization
    2. Submit post-lecture quiz


    1. Review some peer PRs
    2. Add increments: A-Gradle,A-CheckStyle, Level-10, A-Varargs


    1. Start weekly project meetings
    2. Decide on a overall project direction (user profile, problem addressed) before the tutorial
    3. Start a collaborative doc to take project notes before the tutorial