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).
DukeA-MoreOOP: Use More OOP
A-MoreOOP
↳ Make the code more OOP
Refactor the code to extract out closely related code as classes.
Minimal: Extract the following classes:
Ui: deals with interactions with the user
Storage: deals with loading tasks from the file and saving tasks in the file
Parser: deals with making sense of the user command
TaskList: 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:
publicclassDuke{ private Storage storage; private TaskList tasks; private Ui ui; publicDuke(String filePath){ ui = new Ui(); storage = new Storage(filePath); try { tasks = new TaskList(storage.load()); } catch (DukeException e) { ui.showLoadingError(); tasks = new TaskList(); } } publicvoidrun(){ //... } publicstaticvoidmain(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 abstract Command class, so that you can write the main logic of the App as follows:
publicvoidrun(){ 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(); } } }
You can get some inspiration from how the code of the addressbook-level2 is organized.
2 Add Increments as PRs: Level-8, Level-9, A-JUnit
Note how to merge PRs:
Textbook Git & GitHub → Merging PRs
Let's look at the steps involved in merging a PR, assuming the PR has been reviewed, refined, and approved for merging already.
Preparation: If you would like to try merging a PR yourself, you can create a dummy PR in the following manner.
Create a new branch e.g., (feature1) and add some commits to it.
Push the new branch to the fork.
Create a PR from that branch to the master branch in your fork. Yes, it is possible to create a PR within the same repo.
1. Locate the PR to be merged in your repo's GitHub page.
2. Click on the Conversation tab and scroll to the bottom. You'll see a panel containing the PR status summary.
3. If the PR is not merge-able in the current state, the Merge pull request will not be green. Here are the possible reasons and remedies:
Problem: The PR code is out-of-date, indicated by the message This branch is out-of-date with the base branch. That means the repo's master branch has been updated since the PR code was last updated.
If the PR author has allowed you to update the PR and you have sufficient permissions, GitHub will allow you to update the PR simply by clicking the Update branch on the right side of the 'out-of-date' error message.
If that option is not available, post a message in the PR requesting the PR author to update the PR.
Problem: There are merge conflicts, indicated by the message This branch has conflicts that must be resolved. That means the repo's master branch has been updated since the PR code was last updated, in a way that the PR code conflicts with the current master branch. Those conflicts must be resolved before the PR can be merged.
If the conflicts are simple, GitHub might allow you to resolve them using the Web interface.
If that option is not available, post a message in the PR requesting the PR author to update the PR.
Tools → Git & GitHub → Merge Conflicts
Tools → Git and GitHub →
Dealing with merge conflicts
Merge conflicts happen when you try to combine two incompatible versions (e.g., merging a branch to another but each branch changed the same part of the code in a different way).
Here are the steps to simulate a merge conflict and use it to learn how to resolve merge conflicts.
0. Create an empty repo or clone an existing repo, to be used for this activity.
1. Start a branch named fix1 in the repo. Create a commit that adds a line with some text to one of the files.
2. Switch back to master branch. Create a commit with a conflicting change i.e. it adds a line with some different text in the exact location the previous line was added.
3. Try to merge the fix1 branch onto the master branch. Git will pause mid-way during the merge and report a merge conflict. If you open the conflicted file, you will see something like this:
COLORS ------ blue <<<<<< HEAD black ======= green >>>>>> fix1 red white
4. Observe how the conflicted part is marked between a line starting with <<<<<< and a line starting with >>>>>>, separated by another line starting with =======.
Highlighted below is the conflicting part that is coming from the master branch:
blue <<<<<< HEAD black ======= green >>>>>> fix1 red
This is the conflicting part that is coming from the fix1 branch:
blue <<<<<< HEAD black ======= green >>>>>> fix1 red
5. Resolve the conflict by editing the file. Let us assume you want to keep both lines in the merged version. You can modify the file to be like this:
COLORS ------ blue black green red white
6. Stage the changes, and commit.
3. Merge the PR by clicking on the Merge pull request button, followed by the Confirm merge button. You should see a Pull request successfully merged and closed message after the PR is merged.
You can choose between three merging options by clicking on the down-arrow in the Merge pull request button. If you are new to Git and GitHub, the Create merge commit options are recommended.
Next, sync your local repos (and forks). Merging a PR simply merges the code in the upstream remote repository in which it was merged. The PR author (and other members of the repo) needs to pull the merged code from the upstream repo to their local repos and push the new code to their respective forks to sync the fork with the upstream repo.
Practice using parallel git branches and PRs, as explained below:
First, do each increment as a parallel branch (follow the branch naming convention you followed earlier branch-Level-8 etc.), but do not merge any.
Then, push each branch to your fork, and create a PR within your fork (i.e., from the increment branch to the master branch). Be careful not to create a PR to the upstream repo. If you did create such a PR by mistake, no worries, just close it yourself.
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:
Project Management → Revision Control → Remote Repositories →
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 the master 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.
Git & GitHub → Branch →
Pushing a branch to a remote repo
Here's how to push a branch to a remote repo:
SourceTree
Here's how to push a branch named add-intro to your own fork of a repo named samplerepo-pr-practice:
git push origin master pushes the master branch to the repo named origin (i.e., the repo you cloned from)
git push upstream-repo add-intro pushes the add-intro branch to the repo named upstream-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
Click on the Pull requests tab followed by the New pull requestbutton. 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 and base dropdowns. e.g., base repository: se-edu/samplerepo-pr-practicebase: master
Normally, 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 and compare dropdowns. e.g., head repository: myrepo/samplerepo-pr-practicecompare: 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.
Now, merge one of the PRs and update the remaining PRs accordingly, as given below:
Merge one of the PRs on GitHub e.g., Level-8. Remember to choose the Create merge commit option when merging.
Pull the updated master branch from your fork to your Computer.
Note how the remaining un-merged branches are no longer in sync with the latest master. To rectify, merge the master branch to each of them. Resolve merge conflicts, if any.
Push the updated branches to your fork. The PRs will update automatically to reflect the updated branch.
As before, tag the merge commit in the master branch and push the tag to your fork.
Merge the remaining PRs using a procedure similar to the above.
DukeLevel-8: Dates and Timesoptional
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 as yyyy-mm-dd format (e.g., 2019-10-15) and print in a different format such as MMM 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; publicclassMain{ publicstaticvoidmain(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 } }
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) ____________________________________________________________
DukeA-JUnit: Add JUnit Tests
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
Intuitively, you might think the right thing to do is to decide what features will be in v3.0 and then plan the intermediate versions based on that. But that's not what we are going to do.
Why? Given the difficulty of reliably estimating the effort each feature will need, any such long-range plan is likely to be inaccurate.
Instead, what we will do is to assume the current iteration is the last iteration, plan that iteration to deliver the product (based on available time), and try to follow that plan as best as we can. After the iteration is over, we plan the next iteration as if it's the last iteration. But that time, you can factor in the experience from the previous iteration to do a better job of planning.
How is that better?
Shorter-term plans have a better chance of being accurate and doable.
You get multiple clean shots at project planning. Each try can learn from the previous tries. Hence, more learning.
As each iteration produces a working product, you always have a working product, which practically eliminates the risk failing to deliver a working product by the final deadline.
The goal of this activity is to come up with the smallest possible product that is still usable so that it can be implemented as v1.0, to be delivered at the end of the first project iteration. We try to make it small because you will have only two weeks to implement v1.0 and coding as a team is a lot harder than writing code alone.
Do not discuss features, UI, command format, or implementation details yet. That would be like putting the cart before the horse. At this stage we are simply trying to choose which user needs to fulfill first.
If the product can be of some use without a given user story, that user story should be left out of v1.0, even if the omission makes the product hard to use, as long as the product is not impossible to use e.g., in most cases a product can be used without an 'edit item' feature because the user can always delete an item and add a new item instead of editing an existing an item.
Don't worry about v2.0. You can design v2.0 after v1.0 done.
Don't worry about v1.0 being 'too small'. You can always add more features to v1.0 if you finish it ahead of schedule. You can also select an additional set of user stories that are nice-to-have in v1.2, to be done but only if there's time left.
If possible, narrow the scope of v1.0 further e.g., narrower target user, a smaller value proposition.
Suggested workflow:
First stage:
Divide the user stories among team members.
Each member will go through their user stories to discard (e.g., cross out, or move to a different location, but not delete) which are definitely not needed for v1.0.
Second stage:
All members discuss the remaining user stories (i.e., the ones not discarded in the first stage), and try to trim the list further.
2 Conceptualize v1.0
Based on your user stories selected previously, conceptualize the product in terms of how it will look like at v1.0 in the form of a feature list.
Note down the feature list in your online project notes document.
Feature list: A list of features of a product grouped according to some criteria such as aspect, priority, order of delivery, etc.
A sample feature list from a simple Minesweeper game (only a brief description has been provided to save space):
Basic play – Single player play.
Difficulty levels
Medium levels
Advanced levels
Versus play – Two players can play against each other.
Timer – Additional fixed time restriction on the player.
...
3 Draft the UG before next lecture
Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v1.0.
We recommend that you follow the AB3 User Guide in terms of structure and format.
As this is a very rough draft and the final version will be in a different format altogether (i.e., in Markdown format), don't waste time in formatting, copy editing etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
Do try to come up with concrete command syntax for the CLI commands that you will deliver at v1.0.
Include only features that will be delivered in v1.0.
Consider including examples of expected outputs too.
Submission [one person per team]: Save the draft UG as a PDF file, name it {team-id}.pdf e.g., TIC4001-2.pdf, and upload to LumiNUS.
Recommended: Divide i.e., work related to the User Guide and the Developer Guidedocumentation work among team members equally; preferably based on enhancements/features each person would be addinge.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide.
Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.
Admin tP: Grading → Documentation
4. Project Grading: Documentation [/ 15 marks]
Evaluated by tutors
Based on the quality of your UG and DG, adjusted based on your individual contribution to the UG/DG.
4 Refine the product design
Review the UG to ensure the features written by each member fit together to form a cohesive product. Note that cohesiveness of the product can affect the grading of the product design aspect.
Admin tP: Grading → Product Design
1. Project Grading: Product Design [ 5 marks]
Evaluates: how well your features fit together to form a cohesive product (not how many features or how big the features are) and how well does it match the target user
