Month: January 2025

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.