Akhil Vuputuri - Project Portfolio

What it does:
The idea was to allow both the Expense Splitter and Diet Tracker features of EYLAH to be built onto the existing AB3 framework rather than replace it entirely.

Justification:
The partitioning into the two feature sections during the refactoring meant that it would be easy to extend the app in the future when adding more new features. It would also allow the two teams for each of the features work independently without much conflict of code, especially during the initial building phase where there are bound to be many bugs. Building on the existing AB3 code base also meant that we were able to follow the good practices and structure used.

Highlights:
As we had already started development of the two features before the refactoring, the highlight was trying to understand the existing structure at that point to refactor and partition without introducing any bugs. This required working together with my teammates to understand the functionality they had started to implement.

Credits:
Address Book 3 Code Base

What it does:
Food is used to represent a food item to be added into the diet tracker and it stores a Calorie object that contains the number of calories in the food.

Justification:
These classes are what the Diet Tracker is built upon as almost every command uses the classes to track the food intake of users. Without these classes, users would be unable to track the food they eat and their calorie intake. Date was added subsequently to allow for functionality of tracking food by date.

Highlights:
The highlight was understanding the requirements of a user when using the Diet Tracker and translating them into the Food class. For example, for a diet tracker a user would want a food item that they store to have calories so as to track and a name to remember by. It was also interesting to understand how date was to be stored. Instead of serializing the LocalDateTime object, I decided to store as a string and call the parser that Java offers to convert it back.

Credits:
AB3 Code Base on how Person is being modelled and used. Duke for the idea of using LocalDateTime.

What it does:
Store food data of user so that when the app is restarted, the information still exists. (Storage - Pull request #152 & #210)

Justification:
Users will not constantly keep the app open and there are times when they would close it,thus, storage allows users to close the app and continue where they left off without doing all the work again.

Highlights: It was quite a challenge dealing with the storage due to the complex nature of translating Java objects into a form that can be stored in a Json. There were several issues, such as data being able to be stored but no read when the app was re-initialised.

Credits: Would like to credit all my team mates in discussing and deciding that in this case the best way to store would be as a JSON rather than a string and also helping me with troubleshooting storage issues.

What it does:
Allows for food to be added and removed. (Add, Delete - Pull request #128) (Tests - Pull request #242)

Justification:
The core functionality of a diet tracking app is to be able to control the food in the app, that the Add and Delete commands let you do.

Highlights: It was intriguing to understand the LogicManager as this was my first implementation of logic components.

Credits: Address Book 3

What it does:
This allows the list shown to change based on the flag provided by the user. They can view daily list, filter by tag, filter by time period or view all consumption ever. (List Fix - Pull request #210) (List By Tag - Pull request #221) (List By Past Num of Days - Pull request #225) (Refactor Flags For Each Type - #248)

Justification:
Instead of simply listing out all the food, there are different list commands for different user needs. If the user wants to track his daily consumption, they can view the daily list, if they wish to find a certain type of food, they can filter by tag and if they want to know what they ate over a past number of days they can use time period.

Highlights: The incorporation of the various list command types was not straightforward as it did not just require changes in the List Command but also required addition of date and tags into food to be filtered.

Credits: My team mate, Jarrod for the idea on having different types of lists to serve different user functions

What it does:
Tabulate the total calorie intake for the day and display to the user. Based on the mode, obtain the calorie limit and let the user know how many more calories he can take or whether he has hit the limit.

Justification:
Knowing how many calories have been taken in and how much more one can eat would let the user better track his diet to know whether to consume more or less.

What it does:
There were many test methods that were failing.

Justification:
The classes would not be able to be rigorously tested if the assertions do not work. This also meant that we potentially had problems in our code if the test classes were correct.

Highlights
It was extremely hard to understand why the tests were failing, thus, required extensive logging and tracing to find out problems in the code.

What it does:
There were many bugs with storage, first when implementing storage for food and subsequently when implementing storage for personal metrics. For the storing for food, it was being saved to a JSON but could not be loaded when app was re-initialised. For the storing of personal metrics, there was issue with generating of the JSON file.

Highlights
Similar to the bugs with tests, it was quite challenging to figure out my values were not able to be stored or read.

What it does:
There was an issue during internal testing where extremely large values would cause overflow even when the data type was a long.

Highlights
There was much discussion on where to handle this and impose a limit. Here, I imposed a limit in the parser based on the size of the input string and taking into consideration the average lifespan of a human.