PROJECT: Internship Diary

This portfolio provides an overview of my contributions to the Internship Diary project.

Overview

Internship Diary is a command line interface (CLI) and desktop-based internship tracking application.

Arguably the most important phase in the journey of a computer science undergraduate is in their internship. Internships are widely viewed as an entry point into the professional scene of computer science. Coupled with the intense competition amongst highly desired internship companies, applying for internships become a tedious and stressful process. Numerous hours would be spent planning, researching and organising internship applications.

As a group of computer science undergraduates, our team understands the anxiety and stress that internship planning can cause. Therefore, we resolved ourselves to create a software that can ease the worries of fellow computer science undergraduates when organising or tracking their internship applications.

Internship Diary is the culmination of this resolution, a simple yet elegant one-stop application for computer science undergraduates' internship organising needs.

Summary of contributions

  • Major enhancement: implemented interview classes and commands

    • What it does: This feature enables the user to add and modify interviews in an internship application, through the interview commands.

    • Justification: Interviews are important to an internship application. As interviews are almost always the next step towards a successful application, it is important for the user to be able to organise and view his interviews. Therefore, this features improves the product by allowing the user to add and modify interviews in an internship application.

    • Highlights: This enhancement requires extensive testing as it makes massive increments to the current Model and Logic packages. The implementation had to be constantly tweaked to ensure good integration with all other enhancements. Meticulousness and the ability to write good test cases was integral to implementing this enhancement.

  • Major enhancement: implemented display of internship application details in the Graphical User Interface (GUI)

    • What it does: This feature enables the user to display the details of a selected internship application (all the fields and list of interviews) on the right panel of the internship application.

    • Justification: This feature improves the product as it allows the users to view all the details of the internship application. This is important because the user will need to refer to the details in order to plan or organise his internships.

    • Highlights: This enhancement uses property change listeners to react to any changes by the user to the displayed filtered list on the left panel and the internship application selected. This implementation will allow for better flexibility in future modifications to internship application, while being less prone to bugs and errors. Additionally, this enhancement requires strong knowledge of javafx and the Ui structure of Internship Diary in order to produce a robust and well-integrated GUI enhancement.

    • Credits: Chan Ger Hean for improving the implementation by using java property change.

  • Minor enhancement: added select command to show Internship Application detail based on index.

  • Minor enhancement: added parsers for new Internship Diary fields (status, priority, role).

  • Code contributed: You can find all my code contributed here: RepoSense Report

Other contributions:

  • Project management:

    • Set up Tags on Github Issues

    • Created and managed Milestones on Github

    • Managed meeting agendas and delegation of features, and translated them into issues on Github

    • Assigned issues and PRs to relevant Milestones (from v1.1 to v2.0)

    • Assigned relevant tags to issues

  • Enhancement to existing features:

    • Added additional test cases to improve coverage from 74% to 77% (Pull Request #83)

    • Added builders to assist in tests (Pull Request #64, Pull Request #83)

  • Documentation:

    • Preliminary refactor of DG from AB3 to Internship Diary (Pull Request #19)

    • Refactor UG to reflect v1.2 Internship Diary features (Pull Request #83)

  • Community:

    • Pull Requests reviewed (with non-trivial comments): #31, #77, #134 , #198

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Structure of interview

  • Interview represents an interview that you have been given by the company you are applying to. It exists within an InternshipApplication

  • Currently there are two types of Interview provided by the Internship Diary:

    • Online Interview — No address is needed.

    • Offline Interview — Address must be provided when interview is added or modified from online to offline.

  • You can specify what type of interview you want to add by using the o/IS_ONLINE prefix.

  • In order to facilitate your tracking of interviews, there are no restriction to what InternshipApplication you can add your interview to.
    Therefore, it is possible for you to add an interview to an InternshipApplication with any status.

    • This is so that just in case you forgot to record an interview after you already got offered or rejected, you could still add it into the Internship Diary for your personal tracking.

    • In v2.0, we will create a prompt on whether you want to automatically change your InternshipApplication status to 'interview'.

Field Prefix Can Be Empty? Max Number of Values Remarks

isOnline

o/

No

1

Can only be true or false

Interview Date

d/

No

1

Must be a valid date of the form day-month-year. Whitespace and / are also supported separators. If year is not given, will default to the current year.

Interview Address

a/

online: yes offline: no

1

No restrictions on input.

Selecting an internship application to display: select

Selects an internship application to display on the right panel of the internship diary.

Only one internship application may be selected at any point in time.

Alternatively, you may use your mouse to click on a specific internship application on the left panel of the internship diary.

Format: select INDEX

Example(s):

  • select 1

Modifying an interview in an internship application: interview

Add, list, edit or delete interviews within an internship application

An interview must contain a date and a boolean (true or false) that represents whether an interview is conducted online or not.
If the interview is not conducted online, an additional address field must be provided. See Structure of interview for more information.

Format:

  • Overview
    interview INTERNSHIP_INDEX COMMAND_WORD [INTERVIEW_INDEX] [a/ADDRESS] [d/DATE] [o/IS_ONLINE]

  • A COMMAND_WORD can be: add list edit delete
    The command will behave identically to their internship application counterparts

    • list is currently functionally similar to select, additional features will be added in v2.0.

  • The INTERNSHIP_INDEX corresponds to the index of the internship in the displayed internship list. Whereas the INTERVIEW_INDEX corresponds to the index of the interview in the interview list.

  • Specific format of each COMMAND_WORD:

    • Add interview
      interview INTERNSHIP_INDEX add d/DATE o/IS_ONLINE [a/ADDRESS]

      • Address field a/ADDRESS is listed as optional here as online interview do not require an address but offline interview does.

    • List interview
      interview INTERNSHIP_INDEX list

    • Edit interview
      interview INTERNSHIP_INDEX edit INTERVIEW_INDEX [a/ADDRESS] [d/DATE] [o/IS_ONLINE]

      • If you are editing an online interview into an offline interview, Address field a/ADDRESS is a requirement.

    • Delete interview
      interview INTERNSHIP_INDEX delete INTERVIEW_INDEX

Examples:

  • list
    interview 2 list
    Lists all interviews in the 2nd internship application in the list

InterviewListExample
Figure 1. Display of interview list in internship application details panel

  • interview 2 add o/false d/05 02 2020 a/Raffles City #02-22
    Adds an interview to the 2nd internship application in the list.

InterviewAddExample
Figure 2. Display of change in interview list after a new interview is added

  • interview 2 list
    interview 2 edit 1 d/05 05 2020
    Edits the date of the 1st interview in the 2nd internship application in the list to 05 05 2020.

InterviewEditExample
Figure 3. Display of change of interview field after an interview is edited

  • interview 2 list
    interview 2 delete 3
    Deletes the 3rd interview in the 2nd internship application in the list.

InterviewDeleteExample
Figure 4. Display of change in interview list after an interview is deleted

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

Interview and Interview Commands

Implementation

The implementation of interviews will be facilitated by two overarching components, the Model Abstract Class Interview which is associated to an InternshipApplication (see Model Diagram [Design-Model] ) and the Logic Classes InterviewCommandParser and InterviewCommand.

The Logic Classes will interact with the Interview Classes to modify the interviews list in InternshipApplication. More detailed explanations will be provided in the subsequent sections.

Interview

There are two types of interviews currently available in Internship Diary:

  • Online Interview — this type of interview will not carry an address. A placeholder Address "NA" will be set.

  • Offline Interview — this type of interview must have an address.

Interview will consist of the following variables and method:

  • getIsOnline() — abstract method that returns whether the interview is to be conducted online.

  • ApplicationDate interviewDate — indicates the date of the interview.

  • Address interviewAddress — indicates the address of the interview.

In particular, Interview will rely on the ApplicationDate and Address classes in the internship package to implement interviewDate and interviewAddress
The class diagram below shows the classes associated to Interview.

InterviewClassDiagram
Figure 5. Structure of Interview and its associated classes

Interview Commands

Interviews can only be modified through the interview command which relies upon InterviewCommandParser and InterviewCommand classes.
The interview command will encompass four types of sub-command:

  • add — add an Interview to the specified InternshipApplication.

  • edit — edits a specified Interview that exists in the interview list in the specified InternshipApplication.

  • delete — deletes a specified Interview that exists in the interview list in the specified InternshipApplication.

  • list — lists all Interview in the specified InternshipApplication.
    Currently list functions similarly to select, additional functions for list will be proposed in [Proposed Improvements] InterviewListCommand.

Correspondingly, the InterviewCommand class will be made abstract with specific implementation of each sub-command in an inheriting class, this can be seen in the diagram below.

InterviewCommandClassDiagram
Figure 6. Structure of InterviewCommand class with its respective sub-commands

Additionally, InterviewCommand will implement the following static operations to facilitate sub-commands:

  • InterviewCommand#getInternshipApplication(Model, Index) will assist all sub-commands in acquiring the InternshipApplication to modify.

  • InterviewCommand#isInterviewBeforeApplication(InternshipApplication, Interview) will assist edit and add commands in checking whether the interview occurs before the internship application.

Lastly, as the commands inherit from Command interface, the commands will implement execute(Model). All the sub-commands follow roughly the same execution sequence as seen in the diagram below.

InterviewAddCommandExecuteSequenceDiagram
Figure 7. Sequence Diagram to show execution of InterviewAddCommand

The execution sequence will first modify the InternshipApplication based on the specific sub-command. Then followed by creating a CommandResult, and returning it.

Interview Commands Parser

InterviewCommandParser is the entry point to all interview sub-commands. It will be called from `InternshipDiaryParser`which is the primary logic parser for user input.

InterviewCommandParser will support the parsing of all four types of InterviewCommand sub-commands. The following activity diagram will show how InterviewCommandParser reads and interpret user input to return the expected sub-command.

InterviewCommandParserActivityDiagram
Figure 8. Process of InterviewCommandParser when reading user input

Additionally, InterviewCommandParser will only be invoked within the Logic component, with the only exception being InterviewAddCommand. Figure 18 will show the general invocation format within the Logic component using InterviewDeleteCommand as an example. While Figure 19 will show the invocation of InterviewAddCommand which is the only sub-command that will utilise the Model component.

InterviewDeleteCommandSequenceDiagram
Figure 9. Interactions inside the Logic Component for InterviewDeleteCommand
InterviewAddCommandSequenceDiagram
Figure 10. Interactions inside the Logic and Model Component for InterviewAddCommand

[Proposed Improvements] InterviewListCommand

Currently, the InterviewListCommand is functionally similar to SelectCommand. In v2.0, there will be the following improvements to the InterviewListCommand:

  • Additional parameters to filter interviews

    • New command format will be interview INDEX list [o/IsOnline] [a/Address] [d/Date].

    • The command will return the list of interviews consisting of only the interviews that contain the optional fields provided in the command.

    • FilteredList from javafx will be used to implement this feature.

Design Considerations

Aspect: How to implement interview

  • Alternative 1 (current choice in v1.4): Use an abstract class as the primary reference to Interviews. Implement types of Interview as extending classes.

    • Pros: More scalable, able to easily add new Interview types.
      Easier to debug and handle exceptions.

    • Cons: More classes to create and handle.

  • Alternative 2 (previous choice in v1.3): Use a concrete Interview class with additional variables to differentiate Interview types.

    • Pros: Easy to implement.

    • Cons: Increasing number of variables if more interview types will be added.

Aspect: How to implement different Interview Commands

  • Alternative 1 (current choice): Use a standardized command with sub-command type parsed as user input.

    • Pros: More streamlined, only one command.
      Able to use polymorphism to share operations between commands.

    • Cons: Harder to implement and document.

  • Alternative 2: Use separate commands for each different method of modifying interview.

    • Pros: Easy to implement.

    • Cons: Makes the user remember more commands.
      Create a lot of repetition in code.