Category: Experiential

Monday, January 13 2025 – Last week, my primary focus was on resolving bugs in previously developed features, particularly within the report section of our project. Initially, I conducted several rounds of testing directly through the user interface but couldn’t replicate the specific bugs that had been reported. Later, Mr. Peter pinpointed the exact scenario where the bug could be reproduced. With this insight, I quickly identified the issue in the logic calculation and implemented a minor fix in the code.

While addressing this, I took the opportunity to perform thorough testing to ensure the fixes were robust and bug-free. Additionally, I made minor improvements to the UI for better functionality. Similarly, in another part of the codebase, I resolved a similar pattern of errors using a comparable approach.

Towards the end of the week, Mr. Peter assigned me a new task: continuing work on a project that was nearing completion for a specific feature. This project had been primarily handled by an intern who was in the final week of his internship. Recognizing the importance of a smooth transition, I quickly familiarized myself with the project structure and codebase. I took full advantage of the remaining time with the intern, asking as many questions as possible to gain insights and ensure I could handle the project tasks independently moving forward.

This week is my last week of internship at here. Begin with Monday, I tested it out the test container for MinIO. I use the test base that created by Mr. Peter and also created a context for the test. After the setup, all working and able to pass all the tests. My routine of testing basically is trying it out on swagger first with different scenario I can think of. After the logic works without error the I only proceed with doing test script.

On Wednesday, Mr. Peter ask me to try out the UI for retail app. I perform monkey testing on the page with spamming button and keep on sending request on the site. I record the error and bug I found.

Time move forward to Thursday, I clean my code and push it. Mr. Peter spotted unused package and other error. I quickly fix it and wait for the feedback for Friday. As usual, many error on the code and I fix it as it is the last day of my internship.

In summary, I have tested it out the file with MinIO and this is the last week of my internship. I am grateful to get to do my Internship at Tong Hin as I get to learn many kind of code and structure. I am happy that I get to experience a workplace that communicate and a happy vibe. Thank you Mr. Peter and Ms. Laili for the guidance. Good Bye!

Twelveth week as an intern in Tong Hin and happy new year. Mr. Peter check the on going work of the OwnCloud and found out that the OwnCloud goes by http instead of API. He decided to change the file service to MinIO as MinIO is compatible for Amazon S3 as we are using it. MinIO serve files as object and there is some difference between MinIO and OwnCloud.

Research start off by checking the old problems we faced on OwnCloud. I checked the features provided by MinIO and it was many. MinIO able user to set the policies on the UI side. Beside that, MinIO authorized user by access key and secret key.

Mr. Peter updated the item schema several times this week which focus on the media. The brand which also need media start with 2 list, 1 to store as the picture of the brand and the other is to display it out. On Thursday, the brand changed to only 1 field which contain the previous work which simplified the field.

The brand controller is completed but the media is still a problem as moving to MinIO. The MinIO have almost the same way of Amazon S3 on accessing the buckets. It is new for me as the MinIO a different approach on getting media compare to OwnCloud. Upload and delete works, and will work around with list and get. On Friday, Mr. Peter asked me to do the test for media. It have not try it out yet as I try on swagger, it was not complete.

In summary, the brand was done and trying to solve MinIO. This week progress has been a bit of slow due to MinIO and I hope get to solve it much quicker due to my internship period is ending.

Monday, January 6 2025 – Last week, I focused on developing the UI for the sign-in functionality. During this process, I discovered an intriguing security feature: the token received from the API is frequently used to retrieve data that requires authorization. This piqued my interest, as I had always wondered how authorization is managed on the front end.

The token is retrieved and then stored in a cookie. A cookie is a small piece of data stored on the user’s device by their web browser. It allows the website to remember information about the user, such as authentication details, across sessions or requests.

In addition to the sign-in page, I worked on creating related UI elements, such as the edit page. One aspect I found particularly interesting was the process of calling an API to retrieve an entity. To ensure that the user making the request has the necessary privileges, the token must be sent for validation. Unlike passing an ID directly in the URL, which could expose sensitive data, the token is sent securely in the request headers.

This was my first time encountering token-based authorization in this way, and it was a fascinating learning experience.

Next, I shifted to working on another entity. I started by designing the UI, incorporating a dropdown button that supports nested input fields. These fields are dynamically populated based on data retrieved from the API. Once the UI was complete, I moved to the backend to create the API query list that the UI would use.

Monday, December 30, 2024 – Last week, I continued developing the CRUD API for an entity designed to manage metadata on the backend. This entity follows a schema similar to others and is accessible to admins. Once the API development was complete, I ran tests, all of which passed successfully.

With the backend portion done, I transitioned to the UI development. Later, Mr. Peter informed me that the API for another entity was ready for use, which allowed me to begin integrating it into the UI.

I started by implementing the create API into the existing UI. After confirming that the entity could be created without issues, I shifted my focus to the sign-in functionality. Initially, I took a straightforward approach, simply executing the sign-in API command. However, I realized that my implementation might not be entirely correct, as it lacked a mechanism to track whether the entity was logged in.

To refine my approach, I referred to a developed project for guidance. In the reference project, the implementation involved storing the entity’s data and token within the application. This allowed other parts of the application to access the login status when required.

Towards the end of the week, I adopted the same approach in my project. However, the code is still unable to retrieve the login status. I concluded that I might not have stored the data and token correctly, which will require further debugging and adjustments in the coming week.

Last week, I focused on developing the UI for the sign-in functionality. During this process, I discovered an intriguing security feature: the token received from the API is frequently used to retrieve data that requires authorization. This piqued my interest, as I had always wondered how authorization is managed on the front end.

The token is retrieved and then stored in a cookie. A cookie is a small piece of data stored on the user’s device by their web browser. It allows the website to remember information about the user, such as authentication details, across sessions or requests.

In addition to the sign-in page, I worked on creating related UI elements, such as the edit page. One aspect I found particularly interesting was the process of calling an API to retrieve an entity. To ensure that the user making the request has the necessary privileges, the token must be sent for validation. Unlike passing an ID directly in the URL, which could expose sensitive data, the token is sent securely in the request headers.

This was my first time encountering token-based authorization in this way, and it was a fascinating learning experience.

Next, I shifted to working on another entity. I started by designing the UI, incorporating a dropdown button that supports nested input fields. These fields are dynamically populated based on data retrieved from the API. Once the UI was complete, I moved to the backend to create the API query list that the UI would use.

Starting the first day of this week, I begin updating the schema required from the last discussion. I reduce the number of objects while adding the respective details user IDs, and I remove unnecessary objects. I also modify the line items for the transfer order by changing the list of transfer DOs and receive items from objects to strings. Afterward, I proceed to update the repositories, services and tests based on the new schema while also adding more static methods for the store and user. Once the tests passed, I continue by creating the transfer receive components including the commands for create, cancel and query for lists, the API controllers for commands and queries, the repositories for CRUD operations and the logic services. After creating all the necessary parts, I focus on refining the transfer DO logic and tests. Meanwhile, Mr. Peter stated that the transfer DO may contain multiple transfer orders to be issued. Additionally, when the user wants to create a new transfer receive by receiving multiple transfer DOs.

On the last day of the year, I add some exceptions to ensure consistent store for both transfer DOs and transfer receives. I also refine the transfer DO services, particularly the create and cancel DO methods, to support scenarios where the transfer DO contains multiple transfer orders. This required updating the logic for issuing or canceling multiple transfer orders and revising the corresponding tests. After all the transfer DO tests passed, I update the transfer receive logic for creating multiple transfer DOs and updated both the transfer DOs and transfer orders after creation. Meanwhile, I rename certain elements to make them more meaningful and user-friendly. Mr. Peter also pointed out a scenario I had overlooked regarding the cancellation of transfer orders flag. Additionally, he suggested dividing the transfer order tests into smaller sections for easier navigation. To improve readability, I decide to exclude the tests from the file, planning to address this after the public holiday.

Happy New Year! I start by separating the transfer order tests and checking them, renaming components for better understanding while rename the error messages for both transfer orders and DOs. I then began implementing the new transfer order cancellation logic discussed earlier. Although the implementation involved some challenges initially, I successfully complete it and pass the tests. Next, I worked on the creation of transfer receive components and added additional tests. After successfully completing the transfer receive creation process, Mr. Peter requested new repositories for creation and deletion, excluding history. He also mentioned adding a LookUp for TypeConfig. After creating the repositories and lookup, I added methods for creating them based on the item barcode and store following the creation of a new transfer receive. Finally, Mr. Peter also reminded to add the exception for destination matching the for the user.

Conclusion

Since this week is the penultimate week of my internship, I focus on refining and extending key features such as transport DO and transport receive logic, while working on feedback to improve test structure and naming conventions to increase clarity. Despite the challenges, I am able to successfully implement and validate complex functionality such as multiple transfer order processing, storage establishment and enhance cancellation logic. With only one week left, my goal is to complete the remaining tasks, improve the system and ensure a seamless handover of my contribution to the team.

During this week, I was assigned the task of improving the POS system workflow. The main objective was to reduce the number of clicks users need to perform while using the system. To achieve this, I spent time brainstorming and analyzing different scenarios to determine the best solution. Finally, I devised an optimized approach for the entire system. I added three buttons that appear dynamically based on specific situations. When creating an order for the first time, the system displays two buttons: “Checkout” and “Payment.” The “Checkout” button allows users to create an order without generating an invoice or making a payment, catering to users who do not wish to complete these actions immediately. The “Payment” button, however, performs different functions depending on the situation. If the order has not been created yet, clicking the “Payment” button will automatically create the order, generate an invoice, and navigate the user directly to the payment page. If the order has already been created, the “Payment” button generates the invoice and navigates to the payment page, providing a quick and seamless checkout process.

After an order has been created, the system accommodates two possible scenarios. If the order has been created but the invoice has not yet been generated, the system displays the “Payment” button along with a “Create Invoice” button. When the user clicks the “Create Invoice” button, they are taken to the invoice preview page, where they can review the invoice, generate a PDF, and complete the invoice creation process. If the invoice has already been created, a “View Invoice” button is displayed instead. Clicking this button automatically generates a temporary PDF for the user to preview the invoice. The “Payment” button remains visible at all times, whether the order has been paid or not, to allow users to review payments at any time in the future. After a payment is completed, I configured the system to reset to the new order page and clear all parameter data. This ensures a smoother, more efficient workflow for the POS system.

Starting the first day of my last internship week, I pull the branch where Mr. Peter had pushed changes after reviewing and modifying the code. I then review the changes and notice many amendments had been made, such as moving the transfer repositories to a new “Transfer” folder, modifying some schemas and naming conventions, updating the item quantities repositories, reorganizing the logic, and including assertions for item quantities and transfer transactions. Soon after, I check the task list which announced the changes and listed tasks to continue. Initially, I try to understand the new schema and updates while resolving the errors and mistakes. After that, I continue refining and updating the transfer transaction. Moreover, during a discussion with Mr. Peter, I was instructed to create more DTOs for the GET API method instead of retrieving the entire schema. We also discussed how to implement search and filter functionality to get specific transfer lists by adding the IsPending schema which allow users to view the list of stocks to work on based on their store identity. Additionally, we discussed the stock command for the work flow process. Thus, more requirements were outlined for me to complete before the end of my internship.

Additionally, following the final discussions, I initially build the relevant code for stock such as commands, services, tests and controllers. This feature was relatively simple to implement, so I quickly complete it and move to testing by initializing more data. After the tests pass successfully, I start creating the transfer order query. Initially, I create queries such as byId, byList, and byNo along with their respective DTOs. Later, I update the byList query to include a search and filter body. Then, I create the mapping profile so users could retrieve the required data values. I also develop the repository for byList and include builders for filtering. However, I encountered difficulties testing queries containing ObjectId data, as the ObjectId could not be converted into a string for reading. Initially, I attempted to add a JsonConverter for ObjectId under the DTO schema, but it was incorrect. Eventually, through persistent effort and seeking advice, I successfully resolve the issue by adding JsonSerializerSettings with an ObjectIdConverter while deserializing string responses. Once the three queries tests succeed, I move on to the IsPending query for the query List. I create a similar query and DTO with its mapping profile. Meanwhile, Mr. Peter reviewed my work and recommended using consistent search and filter logic for builders with the AND gate. Later, we discussed the IsPending statuses, which were allocated under the line item to filter the transfer orders associated with specific line items to be issued. After understanding the new implementation, I commit and push my changes.

Moreover, I pull the branch with additional modifications by Mr. Peter. I review again the changes and check the new tasks and questions on task lists. Mr. Peter mentioned that I hadn’t revert unnecessary changes, especially in the controllers before committing or pushing. There were also other questions and tasks to address the mistakes. After reviewing the changes, I resolve the errors and continue working on the issue list. Filtering the line item data to retrieve the necessary line item for issuing took several hours to succeed. While struggling with this query, I move on to creating the transfer DO query. The process was similar to creating transfer order queries including DTOs, profiles, tests and repositories, which all worked fine. Soon, I discovered a new requirement for a receive list, where users receive orders based on the retail stores. The list also filtered by IsPending which similar to the previous query list.

Additionally, I seek advice and explore ChatGPT for solutions to unit tests. Finally, I found a way to filter the list collection further to identify specific line items. Subsequently, the query tests for both query lists passed as expected. Following that, I update the services by adding the schema and update the tests to include IsPending flags. Once all tests passed, I create the query for the receive list, similar to the query lists and ensure its tests passed as well. In a discussion with Mr. Peter, I was informed that only a few tasks remained, including DO, receive update and receive delete. I aim to complete these by my last day and I push my work accordingly.

On my last day, I focus on refining DO, receive update, and receive delete services. I test the transfer receive queries while initializing additional data for update and delete tests. After successfully testing the DO, I update transfer tests by including the data with IsPending flags to align with the schema. Besides that, I also update the transfer tests by adding assertions for them as well. While working on deletion tests, I encounter issues related to item, I try to debug it but still unsure about the errors. Concurrently, my colleague, Jay inquired about unexpected responses in the query DTO for stores and users. I explain that the query DTO was partially completed and then updated the query, DTO, profile and search repository methods. These changes were tested successfully. Despite accomplishing significant tasks, I couldn’t complete all tests for updates and deletions by the end of the day, leaving me with a slight sense of unfulfillment. Nevertheless, I commit and push my work to the branch, marking the end of my internship at Tong Hin.

Conclusion

As I conclude my internship at Tong Hin, I feel a profound sense of growth and accomplishment. Over the past 13 weeks, I navigate through various technical challenges, deepened my understanding of software development practices, and enhanced my problem-solving abilities. The hands-on experience of working with complex schemas, developing queries, and implementing real-world solutions broadened my technical expertise and prepared me for future endeavors. Working under the guidance of Mr. Peter and collaborating with colleagues helped me develop stronger communication and teamwork skills.

However, this journey wasn’t without its challenges. Struggling to resolve errors, facing technical roadblocks, and balancing multiple tasks were often daunting. But these obstacles pushed me to explore innovative solutions, utilize resources and improve my resilience. While I didn’t manage to complete all tasks by the final day, the experience motivated me to strive for better time management and efficiency in future projects. Reflecting on my internship, I feel immensely grateful for this opportunity. It was a period of continuous learning, self-improvement and achievement. Though it is bittersweet to leave unfinished tasks, I am proud of the progress I made and the skills I acquired during this journey. Thank you to Tong Hin, Mr. Peter, and my colleagues for making this a transformative and enriching experience.

From the first day, Mr. Peter pushed an updated version to fix the configuration error. He also assisted me in modifying the testing environment to make it more understandable and efficient. This included improving the controller naming to reduce confusion. In addition, based on our last discussion, I redesign the schema to reduce the number of objects for better efficiency. I rename the item details for clarity and soon update the relevant transfer services and initialised test data. Then, I proceed to conduct transfer tests for the all the processes, as well as initialised more transfer and item data. I also updated the item configuration to ensure unique data for each record so that I could proceed with my tests. Meanwhile, Mr. Peter mentioned that transfers would occur only in MongoDB, without SQL database involvement. As a result, I remove all references by excluding the “Mongo” naming of transfers. He also pointed out that the initialisation for stores and items should not happen multiple times. Furthermore, Mr. Peter suggested adding error tests to account for missing item required in specific parts.

Besides that, I continue working on transfer order tests as well by adding more possible error tests. I also implement public static methods for initialising store data. After that, I continue on completing the logic for creating and canceling transfer DO. Soon, Mr. Peter reviewed my tests, he then found out that there are some item data referenced with many tests which cannot be ignored. Mr. Peter stated that each item data should only be used for one test. He then suggested if this intialised data make confusion, it is better to separate the controller test with different part. He also recommended that error messages should not be hardcoded but should be added to the ErrorMessage class instead. Additionally, he advised moving the transfer files from the “Orders” folder to the “Transfers” folder for better maintainability. Mr. Peter highlighted that using barcodes to identify specific line items is unacceptable since the orders might have duplicate item orders. So, I decided to use the “No” attribute for uniqueness. Mr. Peter also suggested creating tests for failure scenarios when I have free time. Mr. Peter also emphasized that on every error tests, there will be no updates occur on the collections where proper assertions are necessary.

Moreover, I focus on hardcoding the transfer order error messages and updating the assertion tests for throwing errors. Once all the tests passed successfully, I then continue on the transfer DO by updating its service and restructure the transaction logic for both transfer order and DO. Next, I begin working on transfer DO tests by referring to the transfer order tests. I initially initialising data with another transfer DO data and I start the tests for the create command. Later, Mr. Peter mentioned that using “No” for the line item could be risky and recommended using the ObjectId for each LineItem instead. He then reviewed the line item schema and suggested moving it into its own transfer file. Mr. Peter also reviewed my logic and pointed out confusion in handling multiple exception catches. He advised changing exceptions from Exception to InvalidOperationException or removing additional exceptions entirely for clarity.

Apart from that, I replaced the “No” input with LineItemId in commands, services and tests. To ensure that the ObjectId data could pass tests, I request my friend to send me the relevant ObjectIdConverter file and updated the startup to support serialisation settings. After successfully completing the transfer order tests by adding another throw error tests for LineItemId, I continue on creating the error messages for transfer DO and add them to error assertion tests as well. Once the create tests were successful, I move on to the cancel tests. Mr. Peter reviewed my transfer work and suggested amendments to the transfer schema for better maintainability by reducing the number of objects. He questioned why data instances were used instead of utilising the TestFactory class, so I update the implementation. During the discussion, the offsets should be handled during transfer receive and I understand role of transfer receive. I then pushed my changes to my branch, and the suggestions and additional requirements from Mr. Peter will be addressed next week.

Conclusion

Overall, I feel a deep sense of growth and accomplishment as I tackle complex technical challenges. The journey has been enriching and fulfilling, motivating me to continually strive to improve while appreciating the value of teamwork and mentorship.

Solution for listen button in print preview

This week, my main task was finding a solution to listen for the print preview button. I was working on calling the print count async function when the user clicks the print button. However, this button appears in the print preview, which is a default browser feature. Due to privacy and security restrictions, we cannot access or listen to the button in the print preview. Before arriving at this conclusion, I explored numerous components and libraries to meet the requirements. However, after several days of research, I found that this approach is not feasible with JavaScript.

Create Default page

In addition to that, I worked on creating a retail default page. This page includes default data such as customer, tax, delivery method, etc., which are required for form completion. However, since some customers prefer not to provide their information, these default values can be automatically filled in when the required fields are null or left blank. I also implemented functionality to save this data into local storage. This task took me two days, as I was unfamiliar with saving data to local storage and had to conduct some research. Eventually, I succeeded in saving data to local storage, retrieving it on another page, and using it seamlessly.

Fix Bugs

During the remaining time, I focused on fixing bugs listed on the progress tracker. First, I adjusted the size of the select box in the order create/edit view to make it larger and more user-friendly. Additionally, I worked on adding a confirmation dialog to the return reason line item selection. This feature prevents users from accidentally unchecking a box by displaying a confirmation prompt. Implementing this task took considerable time as I had to figure out how to listen for the event and trigger the dialog when the user attempts to unselect a checkbox. After multiple attempts, I finally managed to make it work smoothly.