- Do any leftover iP tasks from the previous week
- Create a PR to the upstream repo
- Add Increments as parallel branches:
Level-7
,Level-8
- Add Increments:
A-MoreOOP
,A-Packages
,A-JUnit
,A-Jar
- Add Increments as parallel branches:
A-JavaDoc
,A-CodingStandard
,Level-9
Reminder about the deadline for the weekly project tasks:
Admin Weekly schedule → Deadline for weekly tasks
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).
1 Do any leftover iP tasks from the previous week
- Remember to do any leftover increments from the past weeks before starting on the current week's increments. This guideline applies to future weeks too.
2 Create a PR to the upstream repo
- Create a pull request (PR) from your fork to the upstream repo. Note the following:
- Create the PR from the
master
branch of your fork to themaster
branch of the upstream repo (https://github.com/nus-cs2103-AY2021S1/ip) - Set the PR name as
[{Your name}] iP
e.g.,[John Doe] iP
If you are reluctant to give full name, you may give the first half of your name only.
You may leave the description as empty. - Steps for creating a PR is given in this textbook topic (steps 5 onwards):
- Create the PR from the
Textbook Git & GitHub → Creating PRs
Suppose you want to propose some changes to a GitHub repo (e.g., samplerepo-pr-practice) as a pull request (PR). Here is a scenario you can try in order to learn how to create PRs:
A pull request (PR for short) is a mechanism for contributing code to a remote repo, i.e., "I'm requesting you to pull my proposed changes to your repo". For this to work, the two repos must have a shared history. The most common case is sending PRs from a fork to its upstream repo is a repo you forked fromupstream repo.
1. Fork the repo onto your GitHub account.
2. Clone it onto your computer.
3. Commit your changes e.g., add a new file with some contents and commit it.
- Option A - Commit changes to the
master
branch - Option B - Commit to a new branch e.g., create a branch named
add-intro
(remember to switch to themaster
branch before creating a new branch) and add your commit to it.
4. Push the branch you updated (i.e., master
branch or the new branch) to your fork, as explained here.
Pushing a branch to a remote repo
Here's how to push a branch to a remote repo:
Here's how to push a branch named add-intro
to your own fork of a repo named samplerepo-pr-practice
:
Normally: git push {remote repository} {branch}
. Examples:
git push origin master
pushes themaster
branch to the repo namedorigin
(i.e., the repo you cloned from)git push upstream-repo add-intro
pushes theadd-intro
branch to the repo namedupstream-repo
If pushing a branch you created locally to the remote for the first time, add the -u
flag to get the local branch to track the new upstream branch:
e.g., git push -u origin add-intro
See git-scm.com/docs/git-push for details of the push
command.
5. Initiate the PR creation:
-
Go to your fork.
-
Click on the Pull requests tab followed by the New pull request button. This will bring you to the 'Comparing changes' page.
-
Set the appropriate target repo and the branch that should receive your PR, using the
base repository
andbase
dropdowns. e.g.,
base repository: se-edu/samplerepo-pr-practice base: masterNormally, the default value shown in the dropdown is what you want but in case your fork has e.g., the repo you forked from is also a fork of a another repo, which means both of those are considered upstream repos of your forkmultiple upstream repos, the default may not be what you want.
-
Indicate which repo:branch contains your proposed code, using the
head repository
andcompare
dropdowns. e.g.,
head repository: myrepo/samplerepo-pr-practice compare: master
6. Verify the proposed code: Verify that the diff view in the page shows the exact change you intend to propose. If it doesn't, commit the new code and push to the branchupdate the branch as necessary.
7. Submit the PR:
-
Click the Create pull request button.
-
Fill in the PR name and description e.g.,
Name:Add an introduction to the README.md
Description:Add some paragraph to the README.md to explain ...
Also add a heading ... -
If you want to indicate that the PR you are about to create is 'still work in progress, not yet ready', click on the dropdown arrow in the Create pull request button and choose
Create draft pull request
option. -
Click the Create pull request button to create the PR.
-
Go to the receiving repo to verify that your PR appears there in the
Pull requests
tab.
The next step of the PR life cycle is the PR review. The members of the repo that received your PR can now review your proposed changes.
- If they like the changes, they can merge the changes to their repo, which also closes the PR automatically.
- If they don't like it at all, they can simply close the PR too i.e., they reject your proposed change.
- In most cases, they will add comments to the PR to suggest further changes. When that happens, GitHub will notify you.
You can update the PR along the way too. Suppose PR reviewers suggested a certain improvement to your proposed code. To update your PR as per the suggestion, you can simply modify the code in your local repo, commit the updated code to the same master
branch, and push to your fork as you did earlier. The PR will auto-update accordingly.
Sending PRs using the master
branch is less common than sending PRs using separate branches. For example, suppose you wanted to propose two bug fixes that are not related to each other. In that case, it is more appropriate to send two separate PRs so that each fix can be reviewed, refined, and merged independently. But if you send PRs using the master
branch only, both fixes (and any other change you do in the master
branch) will appear in the PRs you create from it.
To create another PR while the current PR is still under review, create a new branch (remember to switch back to the master
branch first), add your new proposed change in that branch, and create a new PR following the steps given above.
It is possible to create PRs within the same repo e.g., you can create a PR from branch feature-x
to the master
branch, within the same repo. Doing so will allow the code to be reviewed by other developers (using PR review mechanism) before it is merged.
Resources
The PR will update automatically to reflect your latest code every time you push code to your fork. As a result, it provides a convenient way for us to access the current state of all your iP code from one location.
Pull Requests is a mechanism for offering code to a repository e.g., a bug fix or a new feature. PRs allow developers to review, discuss, and refine proposed code changes before incorporating (i.e., merging) the new code to the repository.
Resources:
3 Add Increments as parallel branches: Level-7
, Level-8
- Do Level 7 in a branch named
branch-Level-7
. Without merging that branch, go back to themaster
branch and implement the other increment in a separate branch named similar to the first (i.e.,branch-{increment ID}
). Now, go back to themaster
branch and merge the two branches one after the other. As before, tag the commit (in themaster
branch, after merging) that achieves the respective deliverable, and push to your fork.
Remember to push the branches to your fork so that the bot can detect them.
Only merged branches are detected by the script. After merging a branchb1
to themaster
branch, you need to push both themaster
and theb1
branches to the fork. Pushing themaster
branch does not automatically take theb1
branch along with it just because it is already merged to themaster
branch.
Advanced git users: do not delete the branch after merging.
Merge without a fast-forward so that git creates a separate commit for the merge.
Level-7
: Save Level 7. Save
Save the tasks in the hard disk automatically whenever the task list changes. Load the data from the hard disk when Duke starts up. You may hard-code the file name and location e.g., [project_root]/data/duke.txt
The format of the file is up to you. Example:
T | 1 | read book
D | 0 | return book | June 6th
E | 0 | project meeting | Aug 6th 2-4pm
T | 1 | join sports club
If you use file paths in your code,
- remember to use relative paths rather than absolute paths such as
C:\data
. If not, your app can cause unpredictable results when used in another computer. - remember to specify file paths in an OS-independent way. If not, your app might not work when used on a different OS.
Your code must i.e., if the file is missing, your code must creat ithandle the case where the data file doesn't exist at the start. Reason: when someone else takes your Duke and runs it for the first time, the required file might not exist in their computer. Similarly, if you expect the data file to be in as specific folder (e.g., ./data/
), you must also handle the folder-does-not-exist-yet case.
Level-8
: Dates and Times Level 8. Dates and Times
Teach Duke how to understand dates and times. For example, if the command is deadline return book /by 2/12/2019 1800
, Duke should understand 2/12/2019 1800
as 2nd of December 2019, 6pm, instead of treating it as just a String.
- Minimal: Store deadline dates as a
java.time.LocalDate
in your task objects. Accept dates in a format such asyyyy-mm-dd
format (e.g.,2019-10-15
) and print in a different format such asMMM dd yyyy
e.g., (Oct 15 2019
). - Stretch goal: Use dates and times in more meaningful ways. e.g., add a command to print deadlines/events occurring on a specific date.
Using dates/times in Java
A code snippet using the LocalDate
class:
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.time.temporal.ChronoUnit;
public class Main {
public static void main(String[] args) {
//create dates from strings
LocalDate d1 = LocalDate.parse("2019-12-01");
LocalDate d2 = LocalDate.parse("2019-12-02");
LocalDate d3 = LocalDate.parse("2019-12-02");
//compare dates
System.out.println(d1.isBefore(d2)); // -> true
System.out.println(d1.isAfter(d2)); // -> false
System.out.println(d2.equals(d3)); // -> true
//work with dates
System.out.println(d1.getDayOfWeek()); // -> SUNDAY
System.out.println(d1.getMonth()); // -> DECEMBER
System.out.println(d1.plus(1, ChronoUnit.YEARS)); // -> 2020-12-01
// get today's date and print it in a specific format
LocalDate d4 = LocalDate.now();
System.out.println(d4); // -> 2019-10-15
System.out.println(d4.format(DateTimeFormatter.ofPattern("MMM d yyyy"))); // -> Oct 15 2019
}
}
4 Add Increments: A-MoreOOP
, A-Packages
, A-JUnit
, A-Jar
- As in the previous week, commit, tag, and push, as you do the following increments in the
master
branch (no need to use separate branches).
A-MoreOOP
: Use More OOP Refactor the code to extract out closely related code as classes.
- Minimal: Extract the following classes:
Ui
: deals with interactions with the userStorage
: deals with loading tasks from the file and saving tasks in the fileParser
: deals with making sense of the user commandTaskList
: contains the task list e.g., it has operations to add/delete tasks in the list
For example, the code of the main class could look like this:
public class Duke {
private Storage storage;
private TaskList tasks;
private Ui ui;
public Duke(String filePath) {
ui = new Ui();
storage = new Storage(filePath);
try {
tasks = new TaskList(storage.load());
} catch (DukeException e) {
ui.showLoadingError();
tasks = new TaskList();
}
}
public void run() {
//...
}
public static void main(String[] args) {
new Duke("data/tasks.txt").run();
}
}
- Stretch Goal: Consider extracting more classes. e.g.,
*Command
classes (i.e.,AddCommand
,DeleteCommand
,ExitCommand
etc.) that inherits from an abstractCommand
class, so that you can write the main logic of the App as follows:
You can get some inspiration from how the code of the addressbook-level2 is organized.public void run() {
ui.showWelcome();
boolean isExit = false;
while (!isExit) {
try {
String fullCommand = ui.readCommand();
ui.showLine(); // show the divider line ("_______")
Command c = Parser.parse(fullCommand);
c.execute(tasks, ui, storage);
isExit = c.isExit();
} catch (DukeException e) {
ui.showError(e.getMessage());
} finally {
ui.showLine();
}
}
}
A-JUnit
: Add JUnit Tests Add JUnit tests to test the behavior of the code.
Requirements:
- Minimum: More than two test methods, preferably targeting more than one class (if you have multiple classes)
- Stretch goal: test methods to target all public methods of all classes
Refer to the JUnit tutorial @se-edu/guides to find how to use JUnit.
A-Jar
: Create a JAR File Package the app as an executable JAR file so that it can be distributed easily.
You can assume the user will run the jar file in the following way only:
- Copy the jar file into an empty folder
- Open a command window in that folder
- Run the command
java -jar {filename}.jar
e.g.,java -jar Duke.jar
(i.e., run the command in the same folder as the jar file)
Refer to the tutorial Working with JAR files @SE-EDU/guides to find how to create JAR files.
Do not commit the JAR file created. Instead, you can make the JAR file available in the following manner.
- Go to your fork on GitHub and create a new release.
- In the page where you fill the details of the release,
- give an appropriate version number e.g.,
v0.1
- attach the JAR file where it says
Attach binaries by dropping them ...
.
- give an appropriate version number e.g.,
5 Add Increments as parallel branches: A-JavaDoc
, A-CodingStandard
, Level-9
- As in the step 1 above, implement these three increments as three parallel branches first (branch names:
branch-A-JavaDoc
,branch-A-CodingStandard
,branch-Level-9
), and then merge them one-by-one. Hopefully, you will encounter some merge conflicts so that you get to practice de-conflicting branches. - The Java and Git standards to follow (for
A-CodingStandard
) are given in this page.
Level-9
: Find Level 9. Find
Give users a way to find a task by searching for a keyword.
Example:
find book
____________________________________________________________
Here are the matching tasks in your list:
1.[T][✓] read book
2.[D][✓] return book (by: June 6th)
____________________________________________________________