This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2021 Jan-May
**Schedule**
  • Full Timeline
  • Week 1 [Mon, Jan 11th]
  • Week 2 [Mon, Jun 21st]
  • Week 3 [Mon, Jun 28th]
  • Week 4 [Mon, Jul 5th]
  • Week 5 [Mon, Jul 12th]
  • Week 6 [Mon, Jul 19th]
  • Week 7 [Mon, Jul 26th]
  • Week 8 [Mon, Aug 9th]
  • Week 9 [Mon, Aug 16th]
  • Week 10 [Mon, Aug 23rd]
  • Week 11 [Mon, Aug 30th]
  • Week 12 [Mon, Sep 6th]
  • Week 13 [Mon, Sep 13th]
  • Textbook
  • Admin Info
  • Dashboards
    • **Project Links**
     Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard
    •  Team Project (tP):
  • Team Project Info
  • Reference AB3
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
    •
    **Other Links**
  • Java exercises
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files (handouts, submissions etc.)
  • Tutorial Schedule
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard
    •

    • Week 3 [Mon, Jun 28th] - Admin Info

    1. Submit coding exercises via Github Classroom midnight before tutorial counted for participation
    2. [CS2113 students only] Form teams during the tutorial

    1 Submit coding exercises via Github Classroom midnight before tutorial counted for participation

    • As before, submit the coding exercises allocated for the current week, and any pending exercises from previous weeks.

    2 [CS2113 students only] Form teams during the tutorial

    + Other info relevant to this week:

    Admin Tutorials

    Tutorial Timetable

    Our tutorial IDs are different from LumiNUS. Format: CS2113T-W09 means a tutorial of CS2113T 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
    (contact details)
    CS2113T COM1-B103 Zoom Wed 09:00 LC02 CS2113T-W09 TBD
     CS2113  COM1-B103 Zoom Wed 10:00 T1 CS2113-W10 TBD
    CS2113T COM1-B103 Zoom Thu 09:00 LC01 CS2113T-T09 TBD
     CS2113  COM1-B103 Zoom Thu 10:00 T2 CS2113-T10 TBD
    CS2113T COM1-B103 Zoom Fri 08:00 LC03 CS2113T-F08 TBD
     CS2113  COM1-B103 Zoom Fri 10:00 T3 CS2113-F10 TBD

    The mode

    • Tutorials will be conducted using Zoom.
    • MS Teams will be used for file sharing.
    • A tutorial group is handled by two tutors. Each tutor will work with two teams.
    • The tutor will facilitate tutorial activities, observe your progress, and give feedback.

    Slides and tutorial recordings:

    • The Zoom recording of a tutorial will be made available to you after the tutorial.
    • Slides used in tutorials will not be distributed to students. You are expected to take notes (or screenshots) during the tutorial as necessary.

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

    • Not a source of admin information: Given the humongous amount of admin info contained in this module and the fact that it is constantly evolving, tutors may not be aware of the recent subtle changes to the admin information. To safeguard you from receiving incorrect admin info, tutors are prohibited from answering admin queries. If you have an admin query, please post in the forum (or email the prof at cs2113@comp.nus.edu.sg but only if the question is not appropriate for the forum).

    • No inputs for yet-to-be-graded components: Tutors are prohibited from giving inputs for components not graded yet. Reason: work submitted for grading should be your own.

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

    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?


    Keep in mind that instructors don't have ready solutions to all technical problems. Unlike tutorial questions for which instructors have model solutions, given the complexity of industry tools we use (Gradle, GitHub, 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.

    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.
    • Request to meet the instructor to solve the problem: That can only work if the person is supposed to know how to solve all technical problems, which is almost never the case.

    What to do:

    • Double-check the given instructions: 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 module 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.

    • 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 in the module forum:

      • Give full details of the problem 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.

        • Give a meaningful title to the post. Be as specific as you can.
          Bad testing problem
          Good runtest.bat fails with ClassNotFound error
        • Include full error message, screenshots, code snippets, stack traces, etc.
          Note that it is better to give code in text form rather than as screenshots, to allow others to easily copy-paste the code in their reply.
          You can use GFM syntax when posting in the forum.
        • If the problem is code-related, share the full code if possible (e.g., push the current state of the code to a branch in your fork and give the link to the branch). That gives a chance for someone to reproduce the state of your project in their computer. Sharing just a snippet of your choosing might not be enough as the problem may not be where you think it is.

      • Avoid addressing the question to one person (e.g., the prof), unless really necessary. Doing so will discourage others from answering that question.

      • Isolate the problem. "My code doesn't work" isn't going to help even if you post the whole code. 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 (have you heard about Rubber Duck Debugging?).

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

      • Remember to thank those you try to help, and close the issue after the issue has been resolved.

      • Share the solution. If you eventually managed to solve the problem on your own, share the solution in the thread for the benefit of others, and give closure to those who tried to help you. Don't leave the thread hanging or close it with something like Never mind. I figured it out.

      • Don't hijack other threads: It is OK to chime in if you have the same problem as the Original PosterOP but don't ask a different (even if somewhat related) question in someone else's thread. That prevents the OP from closing the thread after the original question has been resolved. Instead, post your question as a separate thread.


    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.

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

        Know what these stand for: RTFM, STFW, GIYF, LMGTFY

    • 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.
    • Ask the lecturer: Failing all above, you can talk to the lecturer before/after the lecture, or email the lecturer.

    Some technical problems can take a long 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.

    Resources


    • No ‘mini-lectures’: Tutors are prohibited from 'teaching' concepts that are covered in lectures or other learning resources given to you (reason: 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.
    • 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.

    Timing/venue:

    • Please refer to the Schedule page for further details on each tutorial.
    • You are expected to be present on time. Punctuality is considered for participation marks.
    • 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. Note that the better prepared you are, the higher the chance of completing e all activities allocated to a tutorial within time.

    Grading:

    • Your conduct in tutorials will be evaluated by team members and the tutor which can affect your participation marks.

    Admin Peer Evaluations

    This module leverages peer feedback/evaluations in many ways. In particular, we do several rounds of peer evaluations using TEAMMATES.

    Tool: TEAMMATES (for Peer Evaluations)

    We use the TEAMMATES online peer evaluation system. TEAMMATES is a project run by NUS SoC students and used by over 0.5 million users from over 1000 universities.

    Preparation: When the first feedback session is open on TEAMMATES, you will receive an eamil from TEAMMATES. There is nothing for you to do until then.

    When you do receive that email, it will contain a unique link that you can use to access TEAMMATES without logging in first. Logging in to TEAMMATES using a Google account is optional (but doing so will allow you to see all your TEAMMATES sessions in one page).

    Submitting peer evaluations is compulsory. If you routinely miss submitting peer evaluations, you can lose participation marks.

    Session: Practice Peer Evaluation

    • Objective: to give you a chance to familiarize with the TEAMMATES tool
    • Held early in the semester
    • Submission is compulsory. However, your responses will not be considered for grading as this session is for practice only.

    Session: Midterm Peer Evaluation

    • Held about two weeks into the tP coding phase
    Important questions included in the evaluation:

    Some of these questions (e.g., contribution to DG) are omitted from the midterm peer evaluation but are in the final peer evaluation (they are given here for your reference)

    Q The team members' contribution to the User Guide is,

    Q The team members' contribution to the Developer Guide is,

    Q The team members' contribution to the team-based tasks is,

    Q The team members' contribution to the product implementation (excluding UG, DG, and team-based tasks) is,

    Q The team members' conduct in the project and during tutorials,

    • Evaluated based on the following criteria, on a scale Poor/Below Average/Average/Good/Excellent:

    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.

    Q The competency of the team member demonstrated in the project and during the tutorials,

    • Considered only for bonus marks, A+ grades, and tutor recruitment
    • Evaluated based on the following criteria, on a scale Poor/Below Average/Average/Good/Excellent:

    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.

    Q [Optional] Any ANONYMOUS feedback you want to give the classmates you reviewed above?

    Q [Optional] Any CONFIDENTIAL comments about any team members?

    Session: Final Peer Evaluation

    • Held at the end of the tP.
    • This peer evaluation is compulsory. Not only it will count for weekly participation, those who don't submit will not get a chance to rebut peer evaluations received.
    • This session includes all questions from the Midterm Peer Evaluation:

    Q The team members' contribution to the User Guide is,

    Q The team members' contribution to the Developer Guide is,

    Q The team members' contribution to the team-based tasks is,

    Q The team members' contribution to the product implementation (excluding UG, DG, and team-based tasks) is,

    Q The team members' conduct in the project and during tutorials,

    • Evaluated based on the following criteria, on a scale Poor/Below Average/Average/Good/Excellent:

    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.

    Q The competency of the team member demonstrated in the project and during the tutorials,

    • Considered only for bonus marks, A+ grades, and tutor recruitment
    • Evaluated based on the following criteria, on a scale Poor/Below Average/Average/Good/Excellent:

    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.

    Q [Optional] Any ANONYMOUS feedback you want to give the classmates you reviewed above?

    Q [Optional] Any CONFIDENTIAL comments about any team members?

    • In addition, it contains these additional questions:

    Q Do you agree with the contributions claimed by team members, as stated in their PPP?

    Session: Responses to Peer Evaluations

    • This is a chance for you to submit your objections to the ratings you received in the Final Peer Evaluation.

    How peer evaluations are used

    • Peer evaluations are rarely used directly to calculate marks. They are fare mostly used to flag cases that need further investigation.
    • Before using peer evaluations in grading, we consider factors such as the following:
      • Is there a consensus among team members? We do not want an extreme input from one team member to unduly affect the outcome. In many cases, we discard the highest and lowest ratings received before calculating the average.
      • Do the other data points (e.g., LoC written, tutor feedback, commit history) corroborates the peer evaluations?

    Guidelines for giving peer feedback

    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.

    Guidelines for interpreting contribution ratings

    When you receive results of a peer evaluation question about contribution, use it mainly to compare the team view to your own view.

    • Example 1:
      Your view (of your own contribution) : E+10% i.e., 10% more than an equal share
      Team view (of your own contribution): E+8%
      Conclusion: The team's view is quite similar to yours.
    • Example 2:
      Your view (of your own contribution) : E+15% i.e., 10% more than an equal share
      Team view (of your own contribution): E+3%
      Conclusion: The team's thinks you did significantly less than you claimed you did.

    Admin Standards/Conventions

    Given below are the standards and conventions to follow in this module.

    Java
    Git
    • REQUIRED Follow the Git commit message subject conventions in the SE-EDU Git conventions.
    • OPTIONAL Follow conventions for the commit message body.
    Markdown
    Documentation

    Admin tP: Supervision

    Your tutor will serve as your project supervisor too.

    The supervisor's main job (in the context of this module) 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 at other times, as many times you need, subject to availability in his/her schedule.

    Tutors are not allowed to contribute to graded components of your project work. For example, if you are faced with a design decision in your project, a tutor will not make that decision for you.
    Reason: to ensure fairness across teams, and to ensure the work you submit for grading is entirely your own

    Following from the above, don't expect instructors to answer questions that are specific to graded deliverables (e.g., ask which design alternative is better -- that's a decision you need to make yourself). At best, the instructor can channel the question to the professor. However, you can still raise such questions in the module forum where the professor can answer the question in a general way that's not unfair to other teams (and other teams can benefit from the answer as well).

    How to make project decisions (given instructors are not going to make them for you)? Here are some tips:

    • Quickly try out the alternatives. Rather than get into a analysis-paralysis state, quickly prototype the alternatives to figure out which works better.
    • Go with the team consensus/majority. As most project components are graded by peers, the majority view within the team is a good approximation of how the result will be judged.
    • Go with the simpler alternative that's good enough for the current iteration. That way, if the decision was the wrong one, you'll find out sooner and the cost will be less. A common rookie pitfall is the temptation to look for an ideal future-proof solution -- usually, there is no such thing. Most alternatives can get the job done, it's just that costs and benefits vary.
    • Look at what other teams are doing. That will help you detect if you are going in the wrong direction entirely, and also might lead you to more alternatives to consider.
    • Keep an eye on the results: e.g., Did the design alternative you chose make the code more complex, harder to test, easier to break, harder to modify etc. This will help you decide if you made the right choice.
    • If you realized you picked the wrong alternative, change if you can. Often, the choice you picked may still be good enough to survive the project. In that case, leave it be, but make a mental note about it (you can even document it in the Developer Guide) for future reference -- that's how you build up experience.

    Admin Apdx B (Policies) → Policy on grading smaller/larger teams : OPTIONAL

    Policy on grading smaller/larger teams : OPTIONAL

    As most of the work is graded individually, team sizes of 4 or 6 are not expected to affect your grade. While managing larger teams is harder, larger teams have more collective know-how, which can cancel each other. We'll give some consideration when grading 3-person teams.