This site is from a past semester! The current version will be here when the new semester starts.
CS2113/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
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Tutorial Schedule
  • repl.it link
  • repl.it link (duplicated)
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard

  •  Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Reference AB3
  • Team Project Info
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Week 4 [Fri, Aug 28th] - Summary

    We strongly recommend you to have a team project meeting before the tutorial. Do the following during the meeting:

    • Finish the tP tasks allocated for the week. For example, if you don't have a preliminary project idea by this week's tutorial (as per the tP schedule), the tutor will not be able to give feedback on it.
      • Note that the timeliness of tP tasks (i.e., the deadline is the midnight before the tutorial) is graded under the project management component of the tP.
      • Keep notes of the meeting, and update project documents -- the tutor will ask for those during the tutorial.
    • Help each other finish iP tasks. Tasks allocated to this week are especially troublesome and some peer help can be very useful.
    • Dealing with technical problems:

    Apdx C: FAQApdx E: Using GitHub


    Apdx D: Getting Help

    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


    Apdx C: FAQApdx E: Using GitHub

    Topics:

    • [W4.1] OOP + Java: Inheritance

    • [W4.2] OOP + Java: Polymorphism

    • [W4.3] Java: Constants

    • [W4.4] OOP + Java: Enumerations

    • [W4.5] Automated Testing of Text UIs

    • [W4.6] Code Quality: Readability

    • [W4.7] Code Quality: Refactoring

    • [W4.8] RCS: Creating Pull Requests

    • [W4.1] OOP + Java: Inheritance
    • [W4.1a] Paradigms → OOP → Inheritance → What

    • [W4.1b] Paradigms → OOP → Inheritance → Overloading

    • [W4.1c] Paradigms → OOP → Inheritance → Overriding

    • [W4.1d] C++ to Java → Inheritance → Inheritance (Basics)

    • [W4.1e] C++ to Java → Inheritance → The Object class

    • [W4.2] OOP + Java: Polymorphism
    • [W4.2a] Paradigms → OOP → Polymorphism → What

    • [W4.2b] Paradigms → OOP → Inheritance → Substitutability

    • [W4.2c] Paradigms → OOP → Inheritance → Dynamic and static binding

    • [W4.2d] Paradigms → OOP → Polymorphism → How

    • [W4.2e] C++ to Java → Inheritance → Polymorphism

    • [W4.3] Java: Constants
    • [W4.3a] C++ to Java → Miscellaneous Topics → Constants
    • [W4.4] OOP + Java: Enumerations
    • [W4.4a] Paradigms → OOP → Classes → Enumerations

    • [W4.4b] C++ to Java → Miscellaneous Topics → Enumerations

    • [W4.5] Automated Testing of Text UIs
    • [W4.5a] Quality Assurance → Testing → Introduction → What

    • [W4.5b] Quality Assurance → Testing → Regression Testing → What

    • [W4.5c] Quality Assurance → Testing → Test Automation → What

    • [W4.5d] Quality Assurance → Testing → Test Automation → Automated testing of CLI applications

    • [W4.6] Code Quality: Readability
    • [W4.6a] Implementation → Code Quality → Readability → Introduction

    • [W4.6b] Implementation → Code Quality → Readability → Basic → Avoid long methods

    • [W4.6c] Implementation → Code Quality → Readability → Basic → Avoid deep nesting

    • [W4.6d] Implementation → Code Quality → Readability → Basic → Avoid complicated expressions

    • [W4.6e] Implementation → Code Quality → Readability → Basic → Avoid magic numbers

    • [W4.6f] Implementation → Code Quality → Readability → Basic → Make the code obvious

    • [W4.6g] Implementation → Code Quality → Readability → Intermediate → Structure code logically

    • [W4.6h] Implementation → Code Quality → Readability → Intermediate → Do not 'Trip Up' reader

    • [W4.6i] Implementation → Code Quality → Readability → Intermediate → Practice KISSing

    • [W4.6j] Implementation → Code Quality → Readability → Intermediate → Avoid premature optimizations

    • [W4.6k] Implementation → Code Quality → Readability → Intermediate → SLAP hard

    • [W4.6l] Implementation → Code Quality → Readability → Advanced → Make the happy path prominent

    • [W4.7] Code Quality: Refactoring
    • [W4.7a] Implementation → Refactoring → What

    • [W4.7b] Tools → IntelliJ IDEA → Refactoring : OPTIONAL

    • [W4.7c] Implementation → Refactoring → How

    • [W4.7d] Implementation → Refactoring → When : OPTIONAL

    • [W4.8] RCS: Creating Pull Requests
    • [W4.8a] Tools → Git and GitHub → Creating PRs

    • [W4.8b] Tools → Git and GitHub → Reviewing PRs

    Admin:

    1. Accept GitHub invitation from the module organization counted for participation
    2. Submit coding exercises on repl.it counted for participation

    iP:

    1. Create a PR to the upstream repo Mon, Aug 31st 2359
    2. Add Increments: Level-4, A-TextUiTesting, A-CodeQuality
    3. Get ready to review PRs before the tutorial
    4. Review some peer PRs during the tutorial counted for participation

    tP:

    1. Start weekly project meetings
    2. Start a collaborative doc to take project notes before the tutorial
    3. Decide on an overall project direction (user profile, problem addressed) before the tutorial