Month: May 2024

Monday, May 27, 2024 – Last week, after pushing all my changes to cloud, Mr. Peter provided feedback on the latest feature he tested. Unfortunately, there were many issues that needed to be addressed. The major problem was how the data was being loaded in the UI when retrieved from the API. Since the real data was significantly larger than my dummy data, I hadn’t anticipated the issues that would arise. This became the most critical problem to fix.

To replicate the slow performance issue, I needed to generate a large amount of data to mimic the real scenario. This led to my next task for the week: creating functions to generate a specific amount of data as specified by the user. A few months ago, I developed a similar feature, so I reused the same module but expanded it with more functions to meet the current requirements.

By the end of the week, I had created all the necessary functions. However, only half of them ran successfully, while the rest required further debugging. I plan to continue this debugging in the upcoming week. Once resolved, I will generate an additional 100,000 to 200,000 data points to better simulate the heavy use case scenario and help me debug the problem more efficiently.

Monday, May 19, 2024 –Continuing from my previous progress on publishing the project, I encountered an issue where the launch crashed. It turned out this was because I hadn’t republished the other API project with the latest changes. After publishing everything and rebuilding the Docker containers, the app launched successfully and worked just as it did during debugging.

Immediately, I focused on cleaning up one particular code, which I had been postponing to prioritize another task, which was to merge an old integration test with a new one. Once the merging completed, I jumped into testing out the application to make sure everything in the UI run as expected, then I noticed there was an error coming from logs. This error only appeared when executing a specific command. Interestingly, during debugging, no error was shown; instead, it just reported a transaction error in the log, even though the function executed perfectly.

I informed Mr. Peter about this issue, and he advised that it was an opportune moment to implement error-catching in my code. This led me to a debugging session to trace the error’s source. Finally, I discovered the issue: it stemmed from my attempt to delete a table with a one-to-one relationship with another table. Deleting Table A would already delete Table B, but I mistakenly deleted Table B first, which caused the transaction error in the logs. After correcting this mistake, no errors appeared in the logs.

The next bug I tackled involved deleting an entity in the report. After deletion, the table’s counter ID didn’t reset to 1, so I modified my query to address this.

After ensuring everything worked as expected, I pushed all my changes for Mr. Peter to review and supervise my latest update.

Last week, I began by integrating a previously completed test with an existing one. After that, I focused on cleaning up the code, particularly the sections related to a recently developed report feature. I then tested the app to identify any overlooked bugs. During this process, I discovered that the date filter was not functioning as expected. The issue was that I had made the date a query parameter for the API while other filters were applied to the background data grid collection. To address this, I removed the date query from the API and handled all filtering and search logic within the view model, aiming to reduce the number of API calls and improve loading times.

Next, I tackled a bug where the app sometimes became unresponsive when a progress bar was used. The logs did not show any errors, and there was no consistent event to pinpoint the cause. After discussing this with Mr. Peter, he suggested publishing the app to see if the issue persisted, as it might be related to Visual Studio. This was my first time publishing independently, so I asked Mr. Peter numerous questions to ensure I did it correctly. My initial attempt at publishing failed, and I was unsure where to look for the issue. After doing a quick research on Stack Overflow, I learned that I should check the output rather than the error list when publishing. Following this advice, I successfully published the app, but clicking on the System.exe file yielded no response.

I consulted Mr. Peter again, and he guided me on what to check next. It turned out the newest API was not built correctly. Upon reviewing the schema in the docker-compose.yml file, I discovered I had inserted an incorrect port name. After fixing this and rebuilding the API, I reopened the application. This time, the app launched, but it crashed when attempting to read or retrieve data from the API. As the week ended, I planned to continue addressing these issues in the following week.

Last week, I developed a UI table to facilitate the ongoing use of the latest entity for storing calculated margins. During this process, I recognized the necessity for an additional column—a boolean or flag from the tracker—to indicate the calculated margin as true. Consequently, I proceeded to implement the functionality for undoing margins, enabling the deletion of all data in the table. This deletion serves the purpose of resetting the table to regenerate and track based on the latest updates.

However, since the table that displays margins are interconnected, I ensured to address the logic for deleting all entities in the table and resetting several conditions in their respective tables. Subsequently, I created controller tests to verify the functionality. Although the tests were successful, I sought confirmation from Mr. Peter to validate my approach. Additionally, I added a button to the UI for easier access.

This week, I made adjustments to the UI displaying the data log. Upon completion, I noticed discrepancies in the creation of the tracker, as it did not produce the expected results as previously simulated. After debugging, it was revealed that there were errors in the logic governing the creation of the tracker data table.

After ensuring that all data was stored and displayed correctly, after I’ve showed to Mr. Peter, he pointed out a flaw in the design Where the system could only track the output of log data without being able to track the input. Consequently, I reverted to the original approach as initially discussed. Furthermore, I fixed several filters on the page that were not functioning properly. As the week draws to a close, there are still some adjustments needed, but I will continue addressing them in the upcoming week.

Monday, April 29, 2024 – Last week, I began by creating controller tests for the API responsible for recording inventory data. These tests were invaluable in helping me fully grasp the necessary logic to achieve the desired results. As I delved deeper into refining this logic, I found the need to add boolean-type columns to the entity to indicate processed and calculated inventory, preventing duplicate data retrieval.

Although it took some trial and error, as well as simulated data testing, once the tests were successful, I swiftly proceeded to develop the UI for displaying the recorded inventory.

Moving forward, I shifted my focus to another entity’s section that will store margin calculation . As I worked on creating the entity, I sought advice and opinions from Mr. Peter to ensure the best outcome. During the process of developing the entity’s service, which execute the logic for entity’s creation, I realized a previous error in the relationship of the current entity model with the preceding entity. Upon recognizing this, I promptly corrected the related services and logic, and tested them thoroughly post-changes.

Throughout the creation of this latest entity, whenever I encountered challenges with the logic, I endeavored not to dwell too long and alternately worked on creating or improving the UI. This approach allowed me time to contemplate better solutions.

As the week drew to a close, there were a few things needed to complete the task and some clean-up tasks to complete but I shall continue next week.

Monday, April 22, 2024 – Last week, following the end of the Hari Raya holiday, I resumed my work on developing the report section. Before the holiday began, I was assigned a new task to work on once the break was over – the margin section. Margins typically refer to profit margins, indicating the percentage of revenue that remains as profit after accounting for all associated costs. The margin section will allow users to view the overall margin calculated based on the latest input and output, previously developed and equipped with the latest data for comprehensive consideration.

To show the margin accurately, I needed to track the the goods in and out of the inventory. Therefore, Mr. Peter introduced me to a new entity designed to record and track the necessary data. Creating this entity would enable me to achieve the required next part of margin calculation. Initially, understanding how data would be recorded in the entity’s table was a bit confusing, but Mr. Peter simplified it visually, making it easier to grasp the basic flow.

I promptly worked on creating the model for the new entity and tested its type in the integration tests. Then, I proceeded to develop its services and outlined the necessary logic to achieve the desired results. Though some aspects were confusing, Mr. Peter patiently explained them to me and was open to any necessary changes or improvements.

Towards the end of the week, I developed an API responsible for calling the entity’s service to record inventory data. Additionally, I performed migration of the newly created entity model, updated the database, and generated its SQL file before adding them to the cloud. However, there is still more needed to be done to complete this task and shall continue working on it next week.