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 4 [Mon, Jul 5th] - Admin Info

    1. Accept GitHub invitation from the module organization counted for participation
    2. Submit coding exercises via Github Classroom counted for participation

    1 Accept GitHub invitation from the module organization counted for participation

    • We will be adding you all to cs2113-AY2021S2 github org. Please accept the invitation sent by GitHub as you need to be a member of the org for some of the future module activities. If you did not receive the invitation link, you can use the link https://github.com/orgs/nus-cs2113-AY2021S2/invitation.
    • Worth 2 participation points

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

    + Other info relevant to this week:

    Admin Apdx C (FAQs) → Why very narrow project scope? : OPTIONAL

    Why very narrow project scope? : OPTIONAL

    Defining your own unique project is more fun.

    But, wider scope → more diverse projects → harder for us to go deep into your project. The collective know-how we (i.e., students and the teaching team) have built up about SE issues related to the project become shallow and stretched too thinly. It also affects fairness of grading.

    That is why a strictly-defined project is more suitable for a first course in SE that focuses on nuts-and-bolts of SE. After learning those fundamentals, in higher level project modules you can focus more on the creative side of software projects without being dragged down by nuts-and-bolts SE issues (because you already know how to deal with them). However, we would like to allow some room for creativity too. That is why we let you build products that are slight variations of a given theme.

    Also note: The freedom to do 'anything' is not a necessary condition for creativity. Do not mistake being different for being creative. In fact, the more constrained you are, the more you need creativity to stand out.

    Admin Apdx C (FAQs) → Why can't I use my favorite tool/framework/language etc.? : OPTIONAL

    Why can't I use my favorite tool/framework/language etc.? : OPTIONAL

    We have chosen a basic set of tools after considering ease of learning, availability, typical-ness, popularity, migration path to other tools, etc. There are many reasons for limiting your choices:

    Pedagogical reasons:

    • Sometimes 'good enough', not necessarily the best, tools are a better fit for beginners: Most bleeding edge, most specialized, or most sophisticated tools are not suitable for a beginner course. After mastering our toolset, you will find it easy to upgrade to such high-end tools by yourself. We do expect you to eventually (after this module) migrate to better tools and, having learned more than one tool, to attain a more general understanding about a family of tools.
    • We want you to learn to thrive under given conditions: As a professional Software Engineer, you must learn to be productive in any given tool environment, rather than insist on using your preferred tools. It is usually in small companies doing less important work that you get to chose your own toolset. Bigger companies working on mature products often impose some choices on developers, such as the project management tool, code repository, IDE, language etc. For example, Google used SVN as their revision control software until very recently, long after SVN fell out of popularity among developers. Sometimes this is due to cost reasons (tool licensing cost), and sometimes due to legacy reasons (because the tool is already entrenched in their code base).
      While programming in school is often a solo sport, programming in the industry is a team sport. As we are training you to become professional software engineers, it is important to get over the psychological hurdle of needing to satisfy individual preferences and get used to making the best of a given environment.

    Practical reasons:

    • Some of the topics are tightly coupled to tools. Allowing more tools means tutors need to learn more tools, which increases their workload.
    • We provide learning resources for tools. e.g. 'Git guides'. Allowing more tools means we need to produce more resources.
    • When all students use the same tool, the collective expertise of the tool is more, increasing the opportunities for you to learn from each others.

    Meanwhile, feel free to share with peers your experience of using other tools.

    Admin Apdx B (Policies) → Policy on publishing submissions : OPTIONAL

    Policy on publishing submissions : OPTIONAL

    The source code are publicly available and are available for reuse by others without any restrictions. 
    Is publishing submissions unfair to the author? We don't think so. If you were the first to think of something your peers are willing to adopt later, that means you are already ahead of them and they are unlikely to earn more marks by adopting your ideas.