This site is from a past semester! The current version will be here when the new semester starts.
CS2103/T 2020 Aug-Dec
  • 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
  • Dashboards
  •  Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Showcase
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Addressbook-level3
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Tutorial Schedule
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard
  • Module ExpectationsLectures


    Weekly Schedule

    CS2103/T week vs normal academic week

    Each CS2103/T week starts with the lecture and ends just before the following week's lecture. The only exception is week 1, which starts on the Monday of the first week of the semester.

    As our lecture is on Friday, CS2103/T week starts a few days earlier than the normal NUS academic week. For example, CS2103/T week 2 starts on the Friday of NUS week 1. See the full timeline for exact dates.

    Deadline for weekly tasks

    The deadline to complete tasks allocated to the week is the e.g., if your tutorial is on Thursday, the deadline is Wednesday 23.59midnight before your tutorial day, unless stated otherwise. Our grading scripts that detect your work run at midnight and only the work that's done by midnight will be eligible for marks (for cases where the task is graded).

    The typical weekly cycle

    [Lecture day (Friday)]

    • Attend the lecture to,
      • see a recap of the preceding week's topics
      • get an introduction to the current week's topics
      • submit the in-lecture quiz/activities (if any)

    Timing/venue:

    Module Venue Time
    CS2103 LT19 Friday 1200-1400
    CS2103T LT19 Friday 1600-1800
    • As the lectures are repeats of each other, you may attend any of the two, except in weeks the lecture is used for the practical exam (PE) or the PE dry run.
    • As Zoom has a limitation of 300 participants (and CS2103T has more than 300 students while CS2103 has ~90 students), CS2103T students are encouraged to attend the earlier lecture (except in weeks mentioned above) if you are free during that time. If you can't join the Zoom lecture because it already has 300 participants, we'll make the lecture recording available to you the same day.

    Lectures start on time sharp and end around 15 minutes before official end time.

    Mode:

    • Will be done using Zoom. More information coming soon.
    • Some topics come with pre-recorded lecture videos.
    Tips for watching lecture videos
    • You can watch video lectures at faster speeds (x1.25 or even x1.5) to save time.
    • Lecture videos require NUSNET login.

    Attendance: Attendance for the first lecture is compulsory.

    Handouts: There are no handouts. All learning materials are organized around topics, are given in Web format, can be found in the Textbook section (organized by topics), and are also embedded in the Schedule page (organized by order of coverage).

    Slides: Our lecture slides are not suited for printing or to be used as a reference during the lecture/exams. They are only an aid for lecture delivery. Slides will be uploaded to LumiNUS after the lecture.

    [End of lecture - Start of tutorial]

    • Use the relevant learning resources to learn the topics.
    • Self-test your knowledge using exercises given in the learning resources.
    • Submit the post-lecture quiz/exercises (if any)
    • Do project tasks (e.g., attend weekly project meeting, finish weekly deliverables)
    • If you don't have time to learn all topics assigned to the week, use the star rating system to decide which ones to do first.

    Before attempting weekly project tasks, go through the weekly topics (and do the weekly programming exercises/activities, if any) as the knowledge from those topics may be needed to complete the project tasks.

    [During tutorial]

    • Attend the tutorial to,
      • demonstrate evidence of your learning weekly topics to the tutor
      • learn from peer demos of showing evidence of their own learning

    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
    (contact details)
    CS2103T Wed 10:00 LG02 CS2103T-W10
    CS2103T Wed 11:00 LG03 CS2103T-W11
    CS2103T Wed 12:00 LG04 CS2103T-W12
    CS2103T Wed 13:00 LG05 CS2103T-W13
     CS2103  Wed 14:00 T01 CS2103-W14
    CS2103T Wed 15:00 LG06 CS2103T-W15
    CS2103T Wed 16:00 LG07 CS2103T-W16
    CS2103T Wed 17:00 LG08 CS2103T-W17
    CS2103T Thu 09:00 LG09 CS2103T-T09
    CS2103T Thu 10:00 LG10 CS2103T-T10
    CS2103T Thu 11:00 LG11 CS2103T-T11
    CS2103T Thu 12:00 LG12 CS2103T-T12
    CS2103T Thu 13:00 LG13 CS2103T-T13
     CS2103  Thu 14:00 T02 CS2103-T14
    CS2103T Thu 15:00 LG15 CS2103T-T15
     CS2103  Thu 16:00 T04 CS2103-T16
    CS2103T Thu 17:00 LG14 CS2103T-T17
     CS2103  Fri 09:00 T06 CS2103-F09
     CS2103  Fri 10:00 T07 CS2103-F10
    CS2103T Fri 11:00 LG16 CS2103T-F11
    CS2103T Fri 12:00 LG17 CS2103T-F12
    CS2103T Fri 13:00 LG18 CS2103T-F13

    The mode

    Tutorials will be conducted using Zoom. More info coming soon.

    What happens during the tutorial:

    • 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. If you are facing difficulties with a weekly activity, the tutor can direct you to get help from another student in the tutorial.

    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 cs2103@comp.nus.edu.sg but only if the question is not appropriate for the forum).

    • 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.
        • If the problem is code-related, share the 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.
      • 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' on 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.
    • 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 or when to do project tasks. You have to figure those out yourselves. But tutors will give you feedback on how you are doing 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 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.

    [End of tutorial - Start of lecture]

    • Downtime (or catch-up with missed tasks)

    Module ExpectationsLectures