Project Duke

The project consists of the following increments:

• Levels: A series of features, meant to be added to Duke in the given order, although some can be skipped. These have been named Level 1 to Level 10 to indicate how each makes the product progressively "level up".
• Extensions:
  • Category A These are internal/feature enhancements meant to help you practice a specific Java or an SE technique.
  • Category B These are enhancements related to task tracking.
  • Category C These are enhancements, not specifically related to task tracking.
  • Category D Each of these adds the ability to track another type of entities.

When implementing this feature, you are also recommended to implement the following extension:

When implementing this feature, you are also recommended to implement the following extension:

When implementing this feature, you are also recommended to implement the following extension:

When implementing this feature, you are also recommended to implement the following extension:

While it is possible to represent a task list as a multi-dimensional array containing , the more natural approach is to use a Task class to represent tasks.

As there are multiple types of tasks that have some similarity between them, you can implement classes Todo, Deadline and Event classes to inherit from a Task class.

Furthermore, use polymorphism to store all tasks in a data structure containing Task objects e.g., Task[100].

Make the Task class an abstract class. If applicable, use abstract methods as well.

Use exceptions to handle errors. For example, define a class DukeException to represent exceptions specific to Duke.

Use the input/output redirection technique to semi-automate the testing of Duke.

Notes:

• A tutorial of this technique is here.
• The required scripts are provided in the Duke repo (see the text-ui-test folder).

Use Java Collections classes for storing data. For example, you can use an ArrayList<Task> to store the tasks. They offer many advantages (e.g., dynamic sizing, easy to find/add/delete items), over using a primitive data structure such as a normal array.

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

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 inherit from an abstract Command class, so that you can write the main logic of the App as follows:

  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();
          }
      }
  }
  
      
  
      
  
  
      
      

Add JUnit tests to test the behavior of the code.

• Minimal: Use JUnit to at least two non-trivial methods, from two different classes (if you have multiple classes),
  and, ensure they are tested reasonably well (i.e., the test code should try to catch most potential bugs in the target methods).
• Stretch goal: Use JUnit to test all non-trivial public methods of all classes.

Refer to the JUnit tutorial @se-edu/guides to find how to use JUnit (in the context of this project).

Organize the classes into suitable java packages.

• Minimal: put all classes in one package e.g., duke
• Stretch goal: divide into multiple packages as the number of classes increase e.g., duke.task, duke.command

Add JavaDoc comments to the code.

• Minimal: Add header comments to at least half of the non-private classes/methods.
• Stretch goal: Add header comments to all non-private classes/methods, and non-trivial private methods.

Tweak the code to comply with a given coding standard. From this point onward, ensure any new code added are compliant with the given coding standard.

Use checkStyle to detect coding style violations.

Refer the tutorial Using Checkstyle @SE-EDU/guides to learn how to use Checkstyle.

Critically examines the code and refactor to improve the code quality where necessary.

When adding this increment, follow closely the 'Code Quality' topics you have learned so far, rather than merely follow your own intuition about code quality.

Use assert feature (not JUnit assertions) to document important assumptions that should hold at various points in the code.

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:

1. Copy the jar file into an empty folder.
2. Open a command window in that folder.
3. 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 (in the context of this project).

Use Gradle to automate some of the build tasks of the project.

Gradle support is provided as a separate branch (named add-gradle-support) in the Duke repo. Therefore, merge that branch to your master branch, and follow the scenario 2 in the guide below.

Refer to the Gradle tutorial @SE-EDU to learn how to use Gradle (in the context of this project).

• Minimal: Set up gradle so that you can build and run Duke using gradle.
• Recommended: Set up gradle to run unit tests.
• Stretch Goal: Use gradle to automate more things in your project.

Use GitHub Actions to set up Continuous Integration (CI).

The workflow specified by this .yml file is a good candidate for this project. The last three segments are related to I/O redirection tests; can be deleted if not applicable to your project.

Refer to the Using GitHub Actions @SE-EDU/guides to learn how to use that .yml file to set up GitHub actions.

Use Java enums, if applicable.

Use Java varargs feature, if applicable.

Use the Lambdas feature of Java in your code, if applicable.

Use the Streams feature of Java in your code, if applicable.

Use third-party libraries in your project. For example, you can use the Natty library to parse strings into meaningful dates.

Add a User Guide to the project in the following way:

• Update the given docs\README.md. See this guide to GitHub flavored Markdown (GFMD).
• Enable the GitHub Pages feature for your fork:
  1. Go to your repo's settings tab.
  2. Click Pages on the menu on the left edge of page.
  3. Set the Source as: [ Branch: master ] branch and [ /docs ] folder and click Save.
     You can select a theme too.
• Go to http://{your username}.github.io/{repo name}/ to view the user guide of your product. Note: it could take 5-10 minutes for GitHub to update the page.
  It is important that you carefully check the content of the UG available at the above URL to ensure the HTML version of the page (auto-converted from MarkDown by GitHub Pages) has the right content. In some rare cases, the page might look alright on GitHub file preview but will not render correctly on GitHub pages.

Minimal:

• Ensure the chatbot name is stated clearly at the top of the User Guide.
• Provide the reader with enough guidance to be able to use all important features of your chatbot.

How detailed should the user guide be? It should be fit-for-purpose. i.e., think from the user's point of view and include as much information as necessary for the user (while trying to keep it as short as possible -- users don't have the patience to read lengthy user guides either), in a format as friendly to the user as possible.
You can use the 'Features' section of this user guide as a benchmark.

Add a Developer Guide to the project, explaining the design and implementation to future developers.

Release the product to be used by potential users. e.g., you can make it available on GitHub

Improve the GUI to make it more polished. Some examples:

• Tweak the GUI to match the asymmetric nature of the conversation: As the conversation is between the user and the app (not between two humans), it is asymmetric in nature. Accordingly, it makes sense not to display both sides of the conversion in the same visual format.
• Highlight errors e.g., when the user types a wrong command, the error should be shown in a different format to catch ther user's attention.
• Tweak padding, fonts, colors, alignments to make the GUI more pleasing to look at.
  Given the app is likely to take only a small portion of the screen, and the bot replies can contain lot of text, try to optimize for space (e.g., avoid wasting display space that simply shows the background graphics).
• Allow resizing of the Window, and ensure the content resize appropriately as the Window changes size.
• Profile pictures: If your GUI shows profile pictures, you can tweak the way the picture is shown (e.g., crop as a circle or a square with rounded corners). In fact, an easy tweak is to use a picture with a transparent background so that it blends nicely with the background.
  Given that the participants of the conversion are fixed (i.e., you and the chatbot), do you even need big profile pictures?
• Focus more on tweaks that actually improves the user experience (UX). Some changes (e.g., profile pictures, background graphics) can be eye catching but can even degrade the UX if not done right (e.g., it can make the text harder to read)

You can take inspiration from these past projects. If you adopt any ideas from them, don't forget to give credit to the original author.

Choose a unique personality for Duke, and tweak the following aspects to go with that personality:

• Name
• Phrases used by Duke (e.g., when responding to a command)
• GUI (colors, icons, font, etc.)

Write more JUnit tests, to test nearly all code that can be tested automatically.

You may omit code that are hard to test automatically e.g., GUI functionality (test those manually instead).

This can include more manual testing as well e.g., testing on different OSes, different screen resolution, different OS language settings (English vs Chinese)

Improve the code to handle all errors you anticipate the product will encounter during usage.

Some examples of errors:

• command format errors: multiple spaces where only one is expected, trailing/leading spaces in the command, an essential parameter missing, a parameter is specified multiple times, special characters used where they are not expected, ...
• environment issues: an expected file is missing, access to a file is denied, a file content is not as expected, ...
• data is not as expected: start date/time is later (or same as) than end/time, a value that should be unique is duplicated (e.g., two tasks with the same exact details), non-existent dates (e.g., Feb 30)

Provide a way for an event to be tentatively scheduled in multiple slots, and later to be confirmed to one the slots.

Provide a way to easily snooze/postpone/reschedule tasks.

Provide support for managing recurring tasks e.g., a weekly project meeting.

Support the managing of tasks that need to be done after a specific time/task e.g., return book after the exam is over.

Provide support for managing tasks that need to be done within a certain period e.g., collect certificate between Jan 15 and 25th.

Provide support for managing tasks that takes a fixed amount of time but does not have a fixed start/end time e.g., reading the sales report (needs 2 hours).

Provide a way to get reminders about tasks e.g., remind the user about upcoming deadlines.

Provide a way for the user to find free times e.g., when is the nearest day in which I have a 4 hour free slot?.

Provide a way to view tasks in the form of a schedule e.g., view the schedule for a specific date.

Deal with schedule anomalies e.g., detect if a task being added clashes with another task in the list.

Add the ability to recognize and deal with duplicate items. e.g., the same task added multiple times.

Provide more flexibility with the data source e.g., the ability for the user to specify which file to use as the data source.

The ability to sort items e.g., sort deadlines chronologically.

Support more natural date formats e.g., Mon in a user command can be interpreted as the date of the next Monday in the calendar.

All more flexibility in search e.g., find items even if the keyword matches the item only partially.

Support a way to easily edit details of items e.g., change the end time of an event without changing anything else.

Minimal: the ability to update an existing item without having to delete it first

Other ideas:

• the ability to clone items (to easily create new items based on existing items)

Provide a way to tag items e.g., tag a task as #fun.

Provide a way to attach priorities to items e.g., mark an item as a high priority (or priority level 1).

Provide a way to archive items so that the user can remove items from the app but still keep a record of them somewhere e.g., archive all tasks in the list into a file so that the user can start over with a clean slate.

Provide a way to perform tasks on multiple items e.g., delete some specific items in one go.

Provide a way to leverage statistics about the items managed by the App e.g., show the number of tasks that have been completed in the past week.

Provide a way to undo a command.

Minimal: the ability to undo the most recent command.

Provide in-App guidance to users.

Minimal: add a command to access a help page.

Other ideas:

• Load the App with some sample data at the first run.

Make the command syntax more flexible.

Minimal: provide shorter aliases for keywords e.g., t can be shorter alias for todo.

Other ideas:

• Allow users to define their own aliases
• Remove the need for the parts of a command to be in a specific order

Support managing info about contacts e.g., details of friends

Support managing info about small snippets of textual information the user wants to record e.g., one's own waist size, a name of a movie that the user wants to remember

Support managing info about expenses e.g., the amounts spent on food, books, transport, etc.

Support keeping records of loans given/taken e.g., money lent/owed to colleagues/friends

Support recording info about places e.g., info about restaurants visited, for future reference

Provide the ability to learn/memorize thingse.g., learn vocabulary, answers to questions

Support managing info about clients e.g., for an insurance agent to keep track of clients

Support managing info about merchandise e.g., a property agent to keep track of properties, a collector of stamps keep track of items in the collection