diff --git a/AboutUs.html b/AboutUs.html index 65aba03bd83..9c5464adabf 100644 --- a/AboutUs.html +++ b/AboutUs.html @@ -3,7 +3,7 @@ - + About Us - AddressBook Level-3 @@ -24,7 +24,7 @@ [portfolio]

Jane Doe

[github] [portfolio]

Johnny Doe

[github] [portfolio]

Jean Doe

[github] [portfolio]

James Doe

[github] -[portfolio]

+[portfolio]

@@ -19,7 +19,7 @@ Search

Configuration guide

Certain properties of the application can be controlled (e.g user preferences file location, logging level) through the configuration file (default: config.json).

+
  • About Us

    • Configuration guide

    Certain properties of the application can be controlled (e.g user preferences file location, logging level) through the configuration file (default: config.json).

    @@ -21,7 +21,7 @@
  • About Us

    • DevOps guide

    Build automation

    This project uses Gradle for build automation and dependency management. You are recommended to read this Gradle Tutorial from the se-edu/guides.

    Given below are how to use Gradle for some important project tasks.

    Continuous integration (CI)

    This project uses GitHub Actions for CI. The project comes with the necessary GitHub Actions configurations files (in the .github/workflows folder). No further setting up required.

    Code coverage

    As part of CI, this project uses Codecov to generate coverage reports. When CI runs, it will generate code coverage data (based on the tests run by CI) and upload that data to the CodeCov website, which in turn can provide you more info about the coverage of your tests.

    However, because Codecov is known to run into intermittent problems (e.g., report upload fails) due to issues on the Codecov service side, the CI is configured to pass even if the Codecov task failed. Therefore, developers are advised to check the code coverage levels periodically and take corrective actions if the coverage level falls below desired levels.

    To enable Codecov for forks of this project, follow the steps given in this se-edu guide.

    Repository-wide checks

    In addition to running Gradle checks, CI includes some repository-wide checks. Unlike the Gradle checks which only cover files used in the build process, these repository-wide checks cover all files in the repository. They check for repository rules which are hard to enforce on development machines such as line ending requirements.

    These checks are implemented as POSIX shell scripts, and thus can only be run on POSIX-compliant operating systems such as macOS and Linux. To run all checks locally on these operating systems, execute the following in the repository root directory:

    ./config/travis/run-checks.sh

    Any warnings or errors will be printed out to the console.

    If adding new checks:

    Making a release

    Here are the steps to create a new release.

    1. Update the version number in MainApp.java.
    2. Generate a fat JAR file using Gradle (i.e., gradlew shadowJar).
    3. Tag the repo with the version number. e.g. v0.1
    4. Create a new release using GitHub. Upload the JAR file you created.
    +e.g. ./gradlew shadowJar.

  • run: Builds and runs the application.
    runShadow: Builds the application as a fat JAR, and then runs it.

  • checkstyleMain: Runs the code style check for the main code base.
    checkstyleTest: Runs the code style check for the test code base.

  • test: Runs all tests.

    • Continuous integration (CI)

    This project uses GitHub Actions for CI. The project comes with the necessary GitHub Actions configurations files (in the .github/workflows folder). No further setting up required.

    Code coverage

    As part of CI, this project uses Codecov to generate coverage reports. When CI runs, it will generate code coverage data (based on the tests run by CI) and upload that data to the CodeCov website, which in turn can provide you more info about the coverage of your tests.

    However, because Codecov is known to run into intermittent problems (e.g., report upload fails) due to issues on the Codecov service side, the CI is configured to pass even if the Codecov task failed. Therefore, developers are advised to check the code coverage levels periodically and take corrective actions if the coverage level falls below desired levels.

    To enable Codecov for forks of this project, follow the steps given in this se-edu guide.

    Repository-wide checks

    In addition to running Gradle checks, CI includes some repository-wide checks. Unlike the Gradle checks which only cover files used in the build process, these repository-wide checks cover all files in the repository. They check for repository rules which are hard to enforce on development machines such as line ending requirements.

    These checks are implemented as POSIX shell scripts, and thus can only be run on POSIX-compliant operating systems such as macOS and Linux. To run all checks locally on these operating systems, execute the following in the repository root directory:

    ./config/travis/run-checks.sh

    Any warnings or errors will be printed out to the console.

    If adding new checks:

    Making a release

    Here are the steps to create a new release.

    1. Update the version number in MainApp.java.
    2. Generate a fat JAR file using Gradle (i.e., gradlew shadowJar).
    3. Tag the repo with the version number. e.g. v0.1
    4. Create a new release using GitHub. Upload the JAR file you created.
    @@ -27,7 +27,7 @@ Expected: The most recent window size and location is retained.

  • { more test cases …​ }

    • Deleting a person

    1. Deleting a person while all persons are being shown

      1. Prerequisites: List all persons using the list command. Multiple persons in the list.

      2. Test case: delete 1
        Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.

      3. Test case: delete 0
        Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.

      4. Other incorrect delete commands to try: delete, delete x, ... (where x is larger than the list size)
        -Expected: Similar to previous.

    2. { more test cases …​ }

    Saving data

    1. Dealing with missing/corrupted data files

      1. {explain how to simulate a missing/corrupted file, and the expected behavior}

    2. { more test cases …​ }

    +Expected: Similar to previous.

  • { more test cases …​ }

    • Saving data

    1. Dealing with missing/corrupted data files

      1. {explain how to simulate a missing/corrupted file, and the expected behavior}

    2. { more test cases …​ }

    @@ -19,7 +19,7 @@ Search

    Documentation Guide

    Style guidance:

    Converting to PDF

    +
  • About Us

    • Documentation Guide

    Style guidance:

    Converting to PDF

    @@ -19,7 +19,7 @@ Search

    Logging guide

    +
  • About Us

    • Logging guide

    @@ -25,7 +25,7 @@
  • Verify the setup:
    1. Run the seedu.address.Main and try a few commands.
    2. Run the tests to ensure they all pass.

    • Before writing code

    1. Configure the coding style

      If using IDEA, follow the guide [se-edu/guides] IDEA: Configuring the code style to set up IDEA's coding style to match ours.

      Tip: Optionally, you can follow the guide [se-edu/guides] Using Checkstyle to find how to use the CheckStyle within IDEA e.g., to report problems as you write code.

    2. Set up CI

      This project comes with a GitHub Actions config files (in .github/workflows folder). When GitHub detects those files, it will run the CI for your project automatically at each push to the master branch or to any PR. No set up required.

    3. Learn the design

      When you are ready to start coding, we recommend that you get some sense of the overall design by reading about AddressBook’s architecture.

    4. Do the tutorials -These tutorials will help you get acquainted with the codebase.

    +These tutorials will help you get acquainted with the codebase.

    @@ -23,7 +23,7 @@ test class, or a test and choose Run 'ABC'
  • Method 2: Using Gradle

    • Link: Read this Gradle Tutorial from the se-edu/guides to learn more about using Gradle.

    Types of tests

    This project has three types of tests:

    1. Unit tests targeting the lowest level methods/classes.
      e.g. seedu.address.commons.StringUtilTest
    2. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
      e.g. seedu.address.storage.StorageManagerTest
    3. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
      -e.g. seedu.address.logic.LogicManagerTest
    +e.g. seedu.address.logic.LogicManagerTest @@ -30,7 +30,7 @@ specifying any tags after it.

    Examples:

    Locating persons by name: find

    Finds persons whose names contain any of the given keywords.

    Format: find KEYWORD [MORE_KEYWORDS]

    Examples:

    Deleting a person : delete

    Deletes the specified person from the address book.

    Format: delete INDEX

    Examples:

    Clearing all entries : clear

    Clears all entries from the address book.

    Format: clear

    Exiting the program : exit

    Exits the program.

    Format: exit

    Saving the data

    AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.

    Editing the data file

    AddressBook data are saved automatically as a JSON file [JAR file location]/data/addressbook.json. Advanced users are welcome to update data directly by editing that data file.

    Caution: If your changes to the data file makes its format invalid, AddressBook will discard all data and start with an empty data file at the next run. Hence, it is recommended to take a backup of the file before editing it.
    -Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.

    Archiving data files [coming in v2.0]

    Details coming soon ...

    FAQ

    Q: How do I transfer my data to another Computer?
    A: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder.

    Known issues

    1. When using multiple screens, if you move the application to a secondary screen, and later switch to using only the primary screen, the GUI will open off-screen. The remedy is to delete the preferences.json file created by the application before running the application again.

    Command summary

    Action Format, Examples
    Add add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…​
    e.g., add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague
    Clear clear
    Delete delete INDEX
    e.g., delete 3
    Edit edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…​
    e.g.,edit 2 n/James Lee e/jameslee@example.com
    Find find KEYWORD [MORE_KEYWORDS]
    e.g., find James Jake
    List list
    Help help
    +Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.

    Archiving data files [coming in v2.0]

    Details coming soon ...

    FAQ

    Q: How do I transfer my data to another Computer?
    A: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder.

    Known issues

    1. When using multiple screens, if you move the application to a secondary screen, and later switch to using only the primary screen, the GUI will open off-screen. The remedy is to delete the preferences.json file created by the application before running the application again.

    Command summary

    Action Format, Examples
    Add add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…​
    e.g., add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague
    Clear clear
    Delete delete INDEX
    e.g., delete 3
    Edit edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…​
    e.g.,edit 2 n/James Lee e/jameslee@example.com
    Find find KEYWORD [MORE_KEYWORDS]
    e.g., find James Jake
    List list
    Help help
    @@ -19,7 +19,7 @@ Search

    AddressBook Level-3

    CI Status codecov

    Ui

    AddressBook is a desktop application for managing your contact details. While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).

    Acknowledgements

    +
  • About Us

    • AddressBook Level-3

    CI Status codecov

    Ui

    AddressBook is a desktop application for managing your contact details. While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).

    Acknowledgements

    @@ -21,7 +21,7 @@
  • About Us

    • Project: AddressBook Level 3

    AddressBook - Level 3 is a desktop address book application used for teaching Software Engineering principles. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC.

    Given below are my contributions to the project.

    +

  • Community:

  • Tools:

  • {you can add/remove categories in the list above}

    • @@ -174,7 +174,7 @@ return String.format(message, personToEdit); }

    Congratulations!

    Writing tests

    Tests are crucial to ensuring that bugs don’t slip into the codebase unnoticed. This is especially true for large code bases where a change might lead to unintended behavior.

    Let’s verify the correctness of our code by writing some tests!

    Of course you can simply add the test cases manually, like you've been doing all along this tutorial. The result would be like the test cases in here. Alternatively, you can get the help of IntelliJ to generate the skeletons of the test cases, as explained in the next section.

    Automatically generating tests

    The goal is to write effective and efficient tests to ensure that RemarkCommand#execute() behaves as expected.

    The convention for test names is methodName_testScenario_expectedResult. An example would be -execute_filteredList_success.

    Let’s create a test for RemarkCommand#execute() to test that adding a remark works. On IntelliJ IDEA you can bring up the context menu and choose to Go To > Test or use the appropriate keyboard shortcut.

    Using the context menu to jump to tests

    Then, create a test for the execute method.

    Creating a test for `execute`.

    Following convention, let’s change the name of the generated method to execute_addRemarkUnfilteredList_success.

    Let’s use the utility functions provided in CommandTestUtil. The functions ensure that commands produce the expected CommandResult and output the correct message. In this case, CommandTestUtil#assertCommandSuccess is the best fit as we are testing that a RemarkCommand will successfully add a Remark.

    You should end up with a test that looks something like this.

    Conclusion

    This concludes the tutorial for adding a new Command to AddressBook.

    +execute_filteredList_success.

    Let’s create a test for RemarkCommand#execute() to test that adding a remark works. On IntelliJ IDEA you can bring up the context menu and choose to Go To > Test or use the appropriate keyboard shortcut.

    Using the context menu to jump to tests

    Then, create a test for the execute method.

    Creating a test for `execute`.

    Following convention, let’s change the name of the generated method to execute_addRemarkUnfilteredList_success.

    Let’s use the utility functions provided in CommandTestUtil. The functions ensure that commands produce the expected CommandResult and output the correct message. In this case, CommandTestUtil#assertCommandSuccess is the best fit as we are testing that a RemarkCommand will successfully add a Remark.

    You should end up with a test that looks something like this.

    Conclusion

    This concludes the tutorial for adding a new Command to AddressBook.

    @@ -39,7 +39,7 @@ "address": "4th street" } ] } -

    You can go through each individual json file and manually remove the address field.

    +

    You can go through each individual json file and manually remove the address field.

    @@ -104,7 +104,7 @@ do you think will happen if we traced the following commands instead? What exceptions do you think will be thrown (if any), where will the exceptions be thrown and where will they be handled?

    1. redit 1 n/Alice Yu

    2. edit 0 n/Alice Yu

    3. edit 1 n/Alex Yeoh

    4. edit 1

    5. edit 1 n/アリス ユー

    6. edit 1 t/one t/two t/three t/one

  • What components will you have to modify to perform the following -enhancements to the application?

    1. Make command words case-insensitive

    2. Allow delete to remove more than one index at a time

    3. Save the address book in the CSV format instead

    4. Add a new command

    5. Add a new field to Person

    6. Add a new entity to the address book

    • +enhancements to the application?

    1. Make command words case-insensitive

    2. Allow delete to remove more than one index at a time

    3. Save the address book in the CSV format instead

    4. Add a new command

    5. Add a new field to Person

    6. Add a new entity to the address book