This site is from a past semester! The current version will be here when the new semester starts.

Week 4 [Fri, Aug 27th] - Project

iP:

  1. Add Increments as branches: Level-5, A-CodeQuality, A-AbstractClasses, A-Packages
  2. Use GFMD in the PR description
  3. Review some peer PRs counted for participation

tP:

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

iP

1 Add Increments as branches: Level-5, A-CodeQuality, A-AbstractClasses, A-Packages

  • Do each increment as a Git branch. Here is an example:
    • Start a branch named branch-{increment ID} (e.g. branch-Level-5). You are recommended to have multiple commits in that branch. Follow the branch naming convention exactly or else our gradings scripts might miss your branch.
    • After the increment is ready, merge the branch-Level-5 back on to master, without a fast-forward so that git creates a separate commit for the merge. git tag that merge commit as Level-5.
    • Push the branch to your fork so that the grading script can detect it. As before, push the tag as well.
    • Advanced git users: do not delete the branch after merging.
Duke Level-5: Handle Errors
Duke A-CodeQuality: Improve Code Quality
Duke A-AbstractClasses: Use Abstract Classes
Duke A-Packages: Organize into Packages

2 Use GFMD in the PR description

  • GitHub Flavored Markdown (and Markdown in general) is useful in many places when using GitHub e.g., issue tracker, PR reviews, writing documentation. The aim of this task is to ensure that you are sufficiently familiar with the GFMD syntax.
  • Requirements: Update click on the the ... icon on the top right corner of the previous description and choose Edit(how?) the description of the iP PR you created earlier so that it contains the following GFMD elements:
    1. a heading
    2. a bullet list
    3. a numbered list
    4. a fenced code block (with syntax highlighting)
    5. a task list
    6. an emoji
    7. a blockquote
    8. a hyper link
    9. inline code
    10. some text formatting: bold, italic, stikethrough etc.

Here is an example:

DukePro

“Your mind is for having ideas, not holding them.” – David Allen (source)

DukePro frees your mind of having to remember things you need to do. It's,

  • text-based
  • easy to learn
  • FAST SUPER FAST to use

All you need to do is,

  1. download it from here.
  2. double-click it.
  3. add your tasks.
  4. let it manage your tasks for you 😉

And it is FREE!

Features:

  • Managing tasks
  • Managing deadlines (coming soon)
  • Reminders (coming soon)

If you Java programmer, you can use it to practice Java too. Here's the main method:

public class Main {
    public static void main(String[] args) {
        Application.launch(MainApp.class, args);
    }
}

If you wish, you may write the PR description to be very similar to the example given above -- as the goal here is to demonstrate your mastery of the GFMD syntax (not ad writing skills).

3 Review some peer PRs counted for participation

Please wait till Mon, Aug 30th to start this task, to give others a few extra days to create the PR if they haven't done so yet.

This task is worth 2x2=4 participtaion points.

  • Learn how you should review PRs in this task:
Video

  • Step 1 Note these additional guidelines:

    • Read the Best practices for reviewing PRs @SE-EDU/guides. You are expected to follow all of them.
    • Make sure you add 'review comments' (not regular comments) as only those are counted for participation. See step 4 in the panel above to find how to add 'review comments'.
    • If the PR has received some review comments already, feel free to confirm/complement/question those comments in your review. Also, look for things the previous reviewers may have missed.
    • At the end of the review, choose Comment (i.e., not Approve or Request changes)

  • Step 2 Do the first PR review as follows.

    • Give comment on coding standard related issues only.
      Review comments don't always have to be about problems in the code. Other things you can do:
      • complement the author on not making a common mistake
      • ask questions
      • suggest alternatives
    • The review allocation is given in the panel below.

If the student you have been allocated to review has not created a PR (or the PR has a trivial amount of code), you can review the Backup PR to review provided in the allocation table. Failing both, pick a PR at random to review.

  • Step 3 Do the second PR review as follows.
    • Comment on other code quality guidelines (see the sections on Naming and Readability in this textbook chapter) you have learned so far. It's optional to comment on coding standard violations in this PR review.
    • The review allocation is given in the panel below.

If the allocated PR is not suitable, use the same strategy as before to find an alternative PR to review.

  • Step 4 [When you receive reviews for your own PR] Respond to comments received. You are recommended to (but not obliged to) respond to comments received from peers, especially if the PR reviewer asked you for more info. As mentioned in these guidelines, do not get into arguments with PR reviewers/authors.

tP: Set direction

1 Start weekly project meetings

  • We recommend you start weekly project meetings now. You can use the meeting to do tP tasks, but also help each other do iP tasks. On a related note, it is also acceptable to discuss weekly post-lecture quiz (if any) together with team members as you do the quiz i.e., discuss and decide the answer collectively, but you should not give away your answers to someone who was not part of that discussion.

2 Start a collaborative doc to take project notes before next lecture

  • Keep project notes in easy-to-use collaborative docs (Recommended: use a GoogleDoc). This document will be checked by the instructors at various points.
    Remember to choose a tool that allow public view access e.g., GoogleDoc can be shared via a public link so that the document can be viewed by others. You'll be asked to submit this link to us in the next week.
    Make sure all you current and future project notes (if split into in multiple documents) are reachable via links given in this document and are viewable by the public.

3 Decide on an overall project direction (user profile, problem addressed) before next lecture

  • Decide project direction, target user profile, and problem addressed: Use your first project meeting to discuss with your team members and decide your project direction, target user profile, and the value proposition of the product, as described in the panels below:

As we are still at the early stages of identifying a problem to solve, do not think of the product (i.e., the solution) yet. That is, do not discuss the product features, UI, command format, and implementation details, etc. unless they are pertinent to the decision of the project direction.

  • Submission: Submit your product name, target user profile, the value proposition, and the public link to your collaborative project notes via TEAMMATES. You'll receive an email from TEAMMATES with the submission link. Only one member needs to submit on behalf of the team. All members can view/update the submission.
    Submission link will be sent to you by Mon, Aug 30th (reason: we need a few days to set up the submission system after teams have been finalized).