- Submit coding exercises on repl.it midnight before tutorial counted for participation
- [CS2113 students only] Form teams during the tutorial
repl.it
linkrepl.it
link (duplicated) 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 | in LumiNUS (don't use this!) |
Our Tutorial ID (use this!) |
Tutors (contact details) |
---|---|---|---|---|---|
CS2113T | Wed 11:00 | CS2113T-W11 |
|||
CS2113T | Wed 12:00 | CS2113T-W12 |
|||
CS2113T | Wed 13:00 | CS2113T-W13 |
|||
CS2113T | Wed 15:00 | CS2113T-W15 |
|||
CS2113T | Wed 16:00 | CS2113T-W16 |
|||
CS2113T | Thu 09:00 | CS2113T-T09 |
|||
CS2113T | Thu 10:00 | CS2113T-T10 |
|||
CS2113T | Thu 12:00 | CS2113T-T12 |
|||
CS2113 | Thu 13:00 | CS2113-T13 |
|||
CS2113 | Thu 14:00 | CS2113-T14 |
|||
CS2113 | Thu 16:00 | CS2113-T16 |
|||
CS2113T | Fri 11:00 | CS2113T-F11 |
|||
CS2113T | Fri 12:00 | CS2113T-F12 |
|||
CS2113T | Fri 14:00 | CS2113T-F14 |
The mode
Tutorials will be conducted using Zoom. More info coming soon.
What happens during 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 cs2113@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.
Admin Appendix D: How to get Help in CS2113/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?
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:
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.
testing problem
runtest.bat fails with ClassNotFound error
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]
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
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
Admin Appendix D (extract): Questions suitable for tutor
Timing/venue:
Grading:
This module leverages peer feedback/evaluations in many ways. In particular, we do several rounds of peer evaluations using TEAMMATES.
Admin Tools → TEAMMATES
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.
Midterm Peer 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)
Uses the Equal Share +/- N%
scale for the answer
Uses the Equal Share +/- N%
scale for the answer
Uses the Equal Share +/- N%
scale for the answer
Poor
/Below Average
/Average
/Good
/Excellent
:Poor
/Below Average
/Average
/Good
/Excellent
:Final Peer Evaluation
Admin Peer Evaluations → Session: Midterm Peer Evaluation Questions
Uses the Equal Share +/- N%
scale for the answer
Uses the Equal Share +/- N%
scale for the answer
Uses the Equal Share +/- N%
scale for the answer
Poor
/Below Average
/Average
/Good
/Excellent
:Poor
/Below Average
/Average
/Good
/Excellent
:Responses to Peer Evaluations
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:
Thanks for all the hard work!
and negative ratings (e.g. Equal share - 40%
) to the same team member is not being honest.Given below are the standards and conventions to follow in this module.
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.
Note that 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, the tutor is not allowed to 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 the tutor 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 tutor can channel the question to the professor. However, you can 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 your tutor is not going to make them for you)? Here are some tips:
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.