This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2021 Jan-May
  • 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
  •  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
  • 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 6 [Mon, Jul 19th] - Admin Info

    1. Submit coding exercises via Github Classroom counted for participation
    2. Submit post-lecture quiz before the lecture counted for participation
    3. [optional] Submit mid-term feedback for the module Sat, Feb 20th 2359

    1 Submit coding exercises via Github Classroom counted for participation

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

    2 Submit post-lecture quiz before the lecture counted for participation

    • Post-lecture quiz: Read weekly topics allocated for this week and submit the post-lecture quiz before the following lecture.

    3 [optional] Submit mid-term feedback for the module Sat, Feb 20th 2359

    • An anonymous survey to submit feedback about the module and the teaching team will open on LumiNUS by Monday. Please take a few minutes to give feedback to your tutors.

    + Other info relevant to this week:

    Admin Exams

    There is no midterm exam. Information about the final exam is given below.

    • The final exam will be as per the normal exam schedule, and will count for 30% of the final grade.
    • We will use Examplify for the final exam this time.

    Exam structure

    The exam duration is 90 minutes.

    The final exam has two types of questions:

    1. MCQ questions - includes True/False like concept questions and some multiple choice/response questions
    2. Short-answer questions

    • All questions will be displayed at once as Examplify doesn't allow creating sections
    • Based on the question you are answering, you need to manage your time appropriately
    • Weightage of the questions will be displayed to help you with time management

    Exam briefing, mock exam, practice exam paper

    • There will be an exam briefing in the penultimate lecture that covers Examplify usage.
    • You will be given a practice exam paper (smaller than the full paper) to help you practice timing. That practice paper will be released at least one week before the exam.

    Admin Apdx F: Handling Team Issues : OPTIONAL

    If your team is facing difficulties due to differences in skill/motivation/availability among team members,

    • First, do not expect everyone to have the same skill/motivation level as you. It is fine if someone wants to do less and have low expectations from the module. That doesn't mean that person is a bad person. Everyone is entitled to have their own priorities.

    • Second, don't give up. It is unfortunate that your team ended up in this situation, but you can turn it into a good learning opportunity. You don't get an opportunity to save a sinking team every day 😃

    • Third, if you care about your grade and willing to work for it, you need to take initiative to turn the situation around or else the whole team is going to suffer. Don't hesitate to take charge if the situation calls for it. By doing so, you'll be doing a favor for your team. Be professional, kind, and courteous to the team members, but also be firm and assertive. It is your grade that is at stake. Don't worry about making a bad situation worse. You won't know until you try.

    • Finally, don't feel angry or 'wronged'. Teamwork problems are not uncommon in this module and we know how to grade so that you will not be penalized for others' low contribution. We can use Git to find exactly what others did. It's not your responsibility to get others to contribute.

    Given below are some suggestions you can adopt if the project work is not going smooth due to team issues. Note that the below measures can result in some team members doing more work than others and earning better project grades than others. It is still better than sinking the whole team together.

    • Redistribute the work: Stronger programmers in the team should take over the critical parts of the code.

    • Enforce stricter integration workflow: Appoint an integrator (typically, the strongest programmer). His/her job is to maintain the integrated version of the code. He/she should not accept any code that breaks the existing product or is not up to the acceptable quality standard. It is up to others to submit acceptable code to the integrator. Note that if the integrator rejected your code unreasonably, you can still earn marks for that code. You are allowed to submit such 'rejected' code for grading. They can earn marks based on the quality of the code.

    If you have very unreliable or totally disengaged team members :

    • Re-allocate to others any mission-critical work allocated to that person so that such team members cannot bring down the entire team.
    • However, do not leave out such team members from project communications. Always keep them in the loop so that they can contribute any time they wish to.
    • Furthermore, evaluate them sincerely and fairly during peer evaluations so that they do get the grade their work deserves, no more, no less.
    • Be courteous to such team members too. Some folks have genuine problems that prevent them from contributing more although they may not be able tell you the reasons. Just do your best for the project and assume everyone else is doing their best too, although their best may be lower than yours.

    Admin Apdx C (FAQs) → Why so many submissions? : OPTIONAL

    Why so many submissions? : OPTIONAL

    The high number of submissions is not meant to increase workload but to spread it across the semester. Learning theory and applying them should be done in parallel to maximize the learning effect. That can happen only if we spread theory and 'application of theory' (i.e., project work) evenly across the semester.

    In addition, spreading the work across the semester aligns with the revisiting concepts at spaced intervals'spaced repetition' technique that we apply in this module to increase your retention of concepts learned.

    Admin Apdx C (FAQs) → Why submission requirements differ between CS2113T and CS2101? : OPTIONAL

    Why submission requirements differ between CS2113T and CS2101? : OPTIONAL

    They do, and they should.

    CS2113T communication requirements are limited to a very narrow scope (i.e., communicate about the product to users and developers). CS2101 aims to teach you technical communication in a much wider context. While you may be able to reuse some of the stuff across the two modules, submissions are not intended to be exactly the same.