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 3 [Aug 26] - Admin Info

    1. Submit post-lecture quiz
    2. CS2103 students: Form teams during the tutorial

    1 Submit post-lecture quiz

    • Post-lecture quiz: As usual, read weekly topics allocated for this week. Submit the post-lecture quiz to test your knowledge of those topics. The quiz link will be emailed to you on the previous week's Friday.

    1 CS2103 students: Form teams during the tutorial

    + Other admin info you may want to read this week:

    Admin Tutorials

    Tutorial Timetable

    Our tutorial IDs are different from LumiNUS. Format: CS2103T-W09 means a tutorial of CS2103T module, held on Wednesday at 0900, and so on.

    Module Venue Time Tutorial ID
    in LumiNUS

    (don't use this!)
    Our Tutorial ID
    (use this!)
    Tutors
    CS2103T COM1-0210 (SR 10) Wed 11:00 G01 CS2103T-W11 Damith, Yuan Chuan
    CS2103T COM1-0210 (SR 10) Wed 12:00 G02 CS2103T-W12 Joanne, Andrew
    CS2103T COM1-0210 (SR 10) Wed 13:00 G03 CS2103T-W13 Jacob, Benjamin
    CS2103T COM1-0210 (SR 10) Thu 09:00 G11 CS2103T-T09 Jeffry, Yuan Chuan
    CS2103T COM1-0210 (SR 10) Thu 10:00 G05 CS2103T-T10 Jeffry, Tejas
     CS2103  COM1-B103 Thu 11:00 08 CS2103-T11 Damith, Brian
    CS2103T COM1-0210 (SR 10) Thu 11:00 G06 CS2103T-T11 James, Jeff
    CS2103T COM1-0210 (SR 10) Thu 12:00 G04 CS2103T-T12 Jun Rong, Brian
    CS2103T COM1-0210 (SR 10) Thu 13:00 G10 CS2103T-T13 Xiaowen, Yuan Chuan
     CS2103  COM1-0210 (SR 10) Thu 14:00 02 CS2103-T14 Gilbert, Yuan Chuan
     CS2103  COM1-0210 (SR 10) Thu 16:00 04 CS2103-T16 Kyler, ZhiHui
    CS2103T COM1-B103 COM1-0210 (SR 10) Thu 17:00 G13 CS2103T-T17 Jun Rong
     CS2103  COM1-0210 (SR 10) Fri 09:00 06 CS2103-F09 Jonathan, Keith
     CS2103  COM1-0210 (SR 10) Fri 10:00 07 CS2103-F10 Jonathan, Keith
    CS2103T COM1-0210 (SR 10) Fri 11:00 G12 CS2103T-F11 Jia Hao, Yuan Chuan
    CS2103T COM1-0210 (SR 10) Fri 12:00 G08 CS2103T-F12 Ayush, Yash
    CS2103T COM1-0210 (SR 10) Fri 13:00 G07 CS2103T-F13 LongBin, Yash
    CS2103T COM1-0210 (SR 10) Fri 14:00 G09 CS2103T-F14 Alfred, Yash

    What happens during the tutorial:

    • A tutorial group is handled by two tutors. Each tutor will work with two teams.
    • The tutor will direct students to share/discuss evidence of learning the weekly topics.
    • If some students have met with difficulties while learning a topic, the tutor can direct those students to get help from those who have learned the topic. The number of topics that can be covered in the tutorial session depends on how well-prepared you are.
    • The tutor will observe, and give feedback on how well you are learning required topics.
    • Please bring your laptop to tutorials. Often, you will need it for tutorial tasks.

    Relevant: [Admin Appendix C(FAQ): What if I don't carry around a laptop? ]

    What if I don’t carry around a laptop?

    If you do not have a laptop or prefer not to bring the laptop, it is up to you to show your work to the tutor in some way (e.g. by connecting to your home PC remotely), without requiring extra time/effort from the tutor or team members.

    Reason: As you enjoy the benefits of not bring the laptop; you (not others) should bear the cost too.


    The role of our tutors is different from tutors in other modules.

    • No direct tech help: Tutors are prohibited from giving direct technical help, other than to give you some general direction to finding a solution. Rationale: We want you to learn the vital survival skill of troubleshooting technical problems.

    Relevant: [Admin Appendix D: How to get Help in CS2103/T ]

    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.

    Resources


    • No ‘teaching’: Tutors are prohibited from “teaching” concepts that are covered in lectures or other learning resources given to you as self-learning is a vital part of the module. For example, the tutor will not do a mini-lecture at the start of the tutorial. Of course tutors can help you clarify doubts under the right circumstances.

    Relevant: [Admin Appendix D (extract): Questions suitable for tutor ]

    • 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.


    • No leading from the front: Tutors are not expected to lead your project effort. They will not tell you how to do project tasks or when to do project tasks. You have to figure those out yourselves. But tutors will give you feedback on how you are doing (or have done) project tasks so that you can improve further.

    Timing/venue:

    • Please refer to the Schedule page for further details on each tutorial.
    • You are expected to arrive on time. Punctuality is considered for participation marks.
    • You may leave the class 15 minutes before the hour if you have another class right after. There is no need to wait till the tutor dismisses you. However, inform the tutor (as a courtesy) before leaving if you leave before the class is dismissed.
    • Please make sure you vacate the table 5 minutes before the hour so that the next group can start on time.
    • In the past, many students have requested to increase the tutorial duration because a mere hour is barely enough to get through all the tutorial tasks. Increasing the tutorial time is not possible due to lack of venues and tutors. Instead, let's try to make the best of the one hour available by coming well prepared and starting on time.

    Grading:

    Tutorials are not graded. However, your conduct will be reviewed by team members and the tutor which will determine your participation marks.

    [Exchange students only] Registering for tutorials:

    • Exchange students need to use the ORATUT system to register for the tutorials. You must have received the instructions from UG office on how/when to go about the registration process. If not, please talk to UG office. When we can see your appeal on ORATUT, we can allocate you to the tutorial slot.

    Admin Peer Evaluations

    We use the TEAMMATES online peer evaluation system to conduct several rounds of peer-evaluations. All peer evaluations will be taken into account when determining your participation marks. The system also allows you to give anonymous feedback to your teammates.

    Extra Requirements: [considered for participation marks]

    • Submitting peer evaluations is compulsory. If you routinely miss submitting peer evaluations, you can lose participation marks.
    • Optional: TEAMMATES normally allows students to access it without using Google login. We encourage (but not require) you to login to TEAMMATES using your Google account and complete your profile with a suitable profile photo. Reason: CS2103/T is a big class. This profile helps us to remember you better, even after the module is over.

    The purpose of the profile photo is for the teaching team to identify you. Therefore, choose a recent individual photo showing your face clearly (i.e., not too small) -- somewhat similar to a passport photo. Some examples can be seen in the 'Teaching team' page. Given below are some examples of good and bad profile photos.

    If you are uncomfortable posting your photo due to security reasons, you can post a lower resolution image so that it is hard for someone to misuse that image for fraudulent purposes. If you are concerned about privacy, you may use a placeholder image in place of the photo in module-related documents that are publicly visible.

    Peer evaluation criteria: professional conduct

    • Professional Communication :
      • Communicates sufficiently and professionally. e.g. Does not use offensive language or excessive slang in project communications.
      • Responds to communication from team members in a timely manner (e.g. within 24 hours).
    • Punctuality: Does not cause others to waste time or slow down project progress by frequent tardiness.
    • Dependability: Promises what can be done, and delivers what was promised.
    • Effort: Puts in sufficient effort to, and tries their best to keep up with the module/project pace. Seeks help from others when necessary.
    • Quality: Does not deliver work products that seem to be below the student's competence level i.e. tries their best to make the work product as high quality as possible within her competency level.
    • Meticulousness:
      • Rarely overlooks submission requirements.
      • Rarely misses compulsory module activities such as pre-module survey.
    • Teamwork: How willing are you to act as part of a team, contribute to team-level tasks, adhere to team decisions, etc. Honors all collectively agreed-upon commitments e.g., weekly project meetings.

    Peer evaluation criteria: competency

    • Technical Competency: Able to gain competency in all the required tools and techniques.
    • Mentoring skills: Helps others when possible. Able to mentor others well.
    • Communication skills: Able to communicate (written and spoken) well. Takes initiative in discussions.

    Giving constructive feedback to others is a valuable skill for software engineers. It is also an intended learning outcome of this module. Half-hearted/trivial feedback will not earn participation marks.

    Here are some things to keep in mind:

    • Assume you are giving feedback to a colleague, not a friend. Keep the tone of your feedback reasonably professional. Do not use offensive language or slang.
    • The feedback should be honest and consistent. Giving positive qualitative feedback (e.g. Thanks for all the hard work! and negative ratings (e.g. Equal share - 40%) to the same team member is not being honest.
    • State your expectations early. All too often students give positive/neutral feedback early (hoping that the team member will improve later) and trash the team member in the final evaluation (because the he/she did not improve as expected). However, this could be confusing to the recipient. It is better to give negative feedback early so that the team member gets a clear signal that he/she needs to improve.

    Admin tP: Supervision

    Your tutor will serve as your project supervisor too.

    The supervisor's main job is to observe, facilitate self/peer learning, evaluate, and give feedback.

    Tutorial time is the main avenue for meeting your supervisor. In addition, you can meet the supervisor before/after the tutorial, or any other time, as many times you need, subject to availability in his/her schedule.

    Note that it is not the supervisor’s job to chase you down and give help. It is up to you to get as much feedback from the as you need. You are free to request more feedback from the supervisor as necessary. Similarly, it is not the job of the supervisor to lead your project to success.

    Admin Appendix B (Policies) → Policy on grading smaller/larger teams

    Policy on grading smaller/larger teams

    As most of the work is graded individually, team sizes of 3, 4, or 5 is not expected to affect your grade. While managing larger teams is harder, larger teams have more collective know-how, which can cancel each other.