Category: Experiential

Fixing Whole System Bugs

Since Mr. Peter has reviewed my entire system, he pointed out some small bugs that could be enhanced to make it smoother. There were over 20 tasks, and it took me two days to complete. These tasks included fixing some input bugs, such as ensuring the page auto-focuses when navigating or when selecting items, as well as allowing decimal inputs for stock management.

In addition, I improved the workflow for stock adjustments. Now, when a user enters a wrong barcode, the system resets all states and refocuses the textbox. I also added a confirmation dialog to the payment edit section to ensure users do not accidentally click the button. Furthermore, I implemented some hotkeys: the Escape key now closes open dialogs, and the Enter key skips the need to press the submit button.

Create Voucher Page

After fixing all the bugs, the system now runs more smoothly than before. I then continued working on the voucher page. The voucher page is easier to create because it only requires three data fields to be uploaded to the API. However, one important thing to watch out for is ensuring that the “last valid date” is not earlier than the creation date. If it is, the API will return an error. To prevent this, I added validation to the “last valid date” to ensure the voucher can be created successfully.

Research On How to Create 1,000,000 Records

After finished the voucher page, the whole system are almost done , but since others backend technologies are still haven’t done yet, so that Mr.Peter asked me to do some research on generating 1,000,000 records data and see how the system performance going on if data fully loaded. It modifies that if this system are being used for several years and look whether the system still can run smoothly. After two days of researching , I have founded a platform name cypress, it is a web testing tools, but it’s more on UI testing. After trying to create a test plan , it can create records smoothly. Unfortunately, Mr.Peter does not accept this type of solution, because it would not work when the UI position are being changed. After that I was trying to create another UI page to generate the data, how I do is just hardcode the data structure and run it in a loop according to the count what user want. But this would make several hours to generate 1,000,000 records.

Eighth week as an intern in Tong Hin. I have finally done all the assigned task. Continuing with last Friday problems, user test do not pass with the authorize in controller. I have solved the problem with removing the authorize, that does solved the problem but do not validate the token.

After some day, Mr. Peter look into my code and saw the client problem. The whole time I was doing with 2 different secret for the token which made the authorize problem. After renaming the secret, all the problem were solved. The code and logic works as the problem are with the secret key. I was also asked to do test script to test regarding the user authorization. It was an hour job.

Moving on, I started to committing the work I have done. Time move to Thursday, Mr. Peter asked me to do client credentials. It was something I am unfamiliar with it, took some time to learn and trying on. I did try and make but It wasn’t what it should be. Mr. Peter figured it is hard for me and will just let it be. I do enjoy the process of trying and learning. The week end with cleaning code and will assigned me a new task on next Monday.

In summary, I have finally completed the task and moving on to a new task. Looking back at my work, I think time does fly. It happened in a blink of eye as I enjoy my work. I am also looking forward for next week new task.

Based on discussions with Mr. Peter, I focus on the Transfer API call functionality, which only interacts with Mongo on each create and update. I initially create the necessary files such as commands, as well as controllers, repositories, interfaces, tests, collections and services. After implementing these components, I directly create the sample data containing the required order details. I then update the controller to read the data to test whether the call function was successful. As I successfully retrieve the data, I continue the create command and keep improving the service. I also manually test this feature by calling the POST API to create a new order, and it worked just fine for the first try. This makes me feel very accomplish and I will continue to update the instructions tomorrow. Soon, Mr. Peter mention that any nullable data should not be seen in the Mongo express interface.

Moreover, I try to update controller tests to initialise data and set up the test environment correctly. After that, I continue on the create and update commands, constantly refining the logic and handling exceptions. At the same time, I also push my user and retail contexts for review. When Mr. Peter reviewed it, he pointed out a major problem with the controller design. The controller should only contain a Mediator constructor. I took his feedback seriously, I then add relevant queries in a timely manner and push an updated version. Mr. Peter also find that there were some unnecessary changes in my work, and require me to review and try to delete irrelevant code.

Other than that, I continue on refining the commands and services. The update command is particularly frustrating due to the complexity of handling multiple states. I found myself struggling to find the best process, I keep questioning myself and iterating on my logic. Meanwhile, I also push my works to Mr. Peter, he still flagged some unnecessary elements in the code base that made it cluttered and confusing. This was a difficult realisation because I had to face the fact that I was adding complexity instead of clarity. Mr. Peter suggested using SourceTree to compare commits line by line.

Additionally, since the deadline was getting closer, I spend the day reverting unnecessary changes as quickly as possible. During our discussion with Mr. Peter, we discovered a serious misunderstanding that I keep synchronising data incorrectly by creating or updating a local dataset instead of just focusing on MongoDB. I then modifying and refining the sync commands to be consistent with the correct context and ensure the API and tests were running as expected. When I successfully manual test the updated sync commands, I felt a sense of relief and renewed confidence. Later, I start to adjust the testing in retail and user contexts. However, there was an error on the user side that I couldn’t resolve in the end and will continue tomorrow.

Beyond that, after a lot of hard work, I finally find the solution and pass the test. I then review my work again until satisfy, then I commit and push to the repository. I then turn my attention back to completing the command and service. Soon, I found out the create command shouldn’t have any big issues. Later that day, Mr. Peter and I discussed about the item adjustments during the ordering process along with some additional requirements to be updated.

Conclusion

Looking back on this week, I experience all sorts of frustrations. I begin to realise the importance of clarity, communication and iteration in coding and collaboration. I keep refining and modifying the commands and the services in order to achieve better logic. While there is still much room for improvement, I will keep my encouragement to handle the challenges ahead.

Monday, December 2, 2024 – Continuing the development process, I implemented the core functionality for displaying the data groups in a newly created component. The primary goal was to create an interactive and user-friendly interface where users could navigate the brands grouped by their initial characters.

To achieve this, I introduced a filtering mechanism using buttons for each group, such as “A-Z,” “0-9,” and special characters. The state management was handled using the useState hook to track the currently selected group. This allowed me to dynamically update the displayed data based on user interaction.

One of the significant challenges was ensuring a seamless experience while maintaining clean and reusable code. Each button was styled conditionally based on its state, whether it’s active, disabled, or default to provide visual feedback to the user so that the user won’t be able to click the group with the empty list. The “All” button was also included for users to reset the filter and view all available groups.

To display the grouped data, I designed a layout where each group had a header styled distinctly to highlight the group name. The list of brands under each group was displayed as cards, each containing an image and a title. I used Next.js’s Image component for optimized image loading and included links to next pages for further exploration.

Next, I focused on cleaning up the entire codebase before pushing the changes. Previously, the API URLs were hard coded directly into each page, which is a poor practice as it risks exposing sensitive information. To address this, I centralized the API URL by placing it in an environment file, enhancing security and maintainability. Additionally, I thoroughly reviewed the codebase to ensure no unnecessary or redundant code remained.

Fix Line Item Problem

This Monday, I found an issue with the line item functionality while creating an order. Regardless of the item I ordered, it always showed item 1’s line item. After debugging, I discovered that the item ID was hardcoded to 1 while uploading the line items. I resolved this issue and implemented a new function to handle the selected line item and upload it to the API.

Return Order page

Next, I continued work on the return order page. Most of my time was spent on the “Edit Return Order Details” view. I was figuring out how to display the line items correctly, as the detail view included both selected and non-selected line items. I tried to combine these two elements, showing selected items with a ticked checkbox and non-selected items with an unticked checkbox. However, my attempts faced issues, such as duplicate entries or incorrectly unticked selected items. This problem took me 1-2 days to resolve. Eventually, I found a solution by printing all the line items from the invoice, comparing them with the return order DTO, and ticking the items that matched. This method helped me better understand how to handle line item data while updating an existing return order.

At the same time, I faced another challenge regarding the return order line item ID and the invoice line item ID. Initially, I didn’t understand the difference and used the return order line item ID as both IDs while updating the return order. This caused issues where incorrect items were displayed after uploading or the upload failed entirely. After completing the line item display functionality, I finally understood how the IDs work. Differentiating between the two IDs was difficult because the line item ID to upload depends on various scenarios. Users might select new line items, modify existing ones, or perform both actions simultaneously. Implementing this logic took me 2-3 days, but I eventually succeeded in fully updating all the required data.

After completing the main part of the return order, I enhanced the search bar in the list view. I noticed the “Get Query” function allowed three types of search data, so I added a dropdown menu to let users select their search type, such as by name, and IDs.

Conclusion

In conclusion . this week, I resolved significant issues with line item handling, improved my understanding of line item ID logic, and enhanced the return order page and search functionality.

This week, according to Mr. Peter’s suggestion and I start by adding a new user manager file that overrides specific methods within the identity server. By utilising the base function which includes the overridden virtual method of user create, update and delete operations. As each method are able to execute in both SQL and MongoDB. After successfully implementing these operations, I proceed with manual testing. During this process, I encounter service issues and quickly realise that forget to include the necessary services. Once the services are added to both the API and the identity server, I login and test all CRUD operations again. While this time, everything function perfectly, it is a relief to see my hard work pay off with smooth operations across the board.

Soon, I continue by manually testing the synchronization process between systems to ensure everything work flawlessly. Luckily, I encounter no issues during this phase, giving me confidence to proceed with mock testing for the user manager component. Meanwhile, during his review, Mr. Peter noticed a lack of exception handling in the user manager. He advised prioritising MongoDB operations before SQL. He also suggested adding more exception handling when in the event of an error, operations will roll back to their previous state.

Moreover, I apply similar enhancements to the context by adding more exceptions to both sync commands and the service. After the testing and necessary updates, I extend these improvements to the context. Next, I update the controller tests with the similar base tests of factory and initialising data. While the controller tests run smoothly, I encounter a issue with missing services during user manager mock testing. I seek advice from my colleague but couldn’t resolve it so I consult Mr. Peter. He then clarified that I need to use the new user manager file instead of the original one. However, further issues persisted, he suggested we might need to set up a separate project for testing but continue on manual testing.

Besides that, I review my works push to my feature branch for Mr. Peter’s review. He then pointed out some minor improvements, such as removing unnecessary API calls and addressing test failures. I review and refine my work and discover that I hadn’t commit the latest user service updates. Meanwhile, I remain determined to resolve the user manager testing issues. I notice that both the identity server and API referenced the Data folder, so I move the user manager file there and add the specific service. To my surprise, this approach works and the tests ran successfully. Meanwhile, Mr. Peter suggested to integrate the store Mongo repository into the user context to associate each registration with the appropriate ID.

Additionally, I include the mongo repository along and refine the context to ensure operations only read from the store collection when necessary. Afterward, I update the user manager and run the operations workflow one last time to confirm that everything worked flawlessly. When everything works as expected, I update and run the tests before pushing my final changes. Apart from that, as my user manual synchronising done, Mr. Peter then discussed with me on the next task of transfer order. He then suggested me on watching some Mongo videos.

Conslusion

This week, I have resolve service integration issues and improve user manager through improved exception handling. The challenges through rigorous testing has enhanced system reliability and my problem-solving abilities.

Seventh week as an intern in Tong Hin. Resuming last week task, done the Read and Update for address including the test. All the test have gone through and pass.

Second, had added the 3 address id on user to check on each address purpose. The address and user is now same as the Entity Relationship Diagram.

Third, the test has some problem when run all. Some test had been using the same set of data to proceed and end up failing. I had done separate data and test with it. The test can be run all at once and pass now.

Fourth, due to misunderstanding, I have done the check token by sending it with the body request. It was suppose to be at the header and check for the token claims. I have changed it to header and it works except for the test. The test can’t locate where’s the token at.

Last but not least, Mr. Peter look through my code and found out there some problems. The password is visible at the backend which might lead to exposure. Besides that, I have used httpContextAccessor. This might be a extra thing to move on.

In summary, I had done different changes to improve the logic and making it complete. This week has been a busy week for me. Will continue the problems that haven’t solve on next week. Hope that can solve it quickly.

On the first day, Mr. Peter had provided me several Docker commands for running Mongo Express with different replica sets. After executing the commands, I am able to login the Mongo Express. I then create some databases for users and stores along with their respective collections. Meanwhile, based on the provided “stores” files, I reference it to create users and subsequently build and update the contexts, repositories, services, interfaces and commands. Initially, I populate the MongoDB with sample user data after updates the Mongo connections of environment. I then create a controller and try to get all the user data created. However, there are some issues since the Object value is in different format with “timestamp” and “creationTime”. So I use ToString function in order to retrieve data in string value, and I successfully read all the user data.

After that, Mr. Peter emphasised that the users in MongoDB should be checked against all system databases so that there will be no extra users for new user creation when synchronising. Moreover, I consult with Mr. Peter for a clearer understanding of the concepts discussed yesterday. His clarification helped immensely that I need to retrieve all data and merge them to avoid overlaps, and then compare with MongoDB data to check the users existence before deletion. Then, I continue the manual synchronisation process of creating and updating data and the deleting in MongoDB. However, I face challenges while trying to merge user data. So I do searching about this scenario and understand how to union the data to remove redundant users from MongoDB. As all the manual synchronising successfully, the sense of accomplishment I feel after solving this is very motivating.

Additionally, I move on to mock testing using the “stores” files as references. I encounter an issue while initialising the MongoDB data and try various approaches without success. After discussing it with my colleague, she then provided some useful code snippets that helped me understand the process better. Despite this, I still face difficulties that I couldn’t get the initialised data. Upon consulting Mr. Peter, he identified that the issue was due to using capital letters in the collection name instead of lowercase. Once corrected, everything worked smoothly. In addition, I continue with my testing and fortunately, all the tests passed successfully.

I then update the synchronisation command for the warehouse MongoDB connection, and create another controller to call user data from MongoDB. By reusing the existing code for the retail sync, I could just making minor adjustments which help streamline the process. I successfully sync data from MongoDB to create new users, although I realize later that I had missed implementing the update functionality for changes in MongoDB. I plan to address this the next day. Meanwhile, I refine the mock testing environment for the warehouse and test the original code with initialized data, which worked successfully. Mr. Peter and I also discuss changes in MongoDB collection naming and connection settings.

Mr. Peter requested updates to the user and store contexts for their respective databases. After making the updates and testing them successfully, I proceed with synchronising the other data. The mock testing for sync commands also went well. However, I face challenges when implementing create, update and delete operations due to service issues. Despite adding scopes to the relevant interfaces and repositories, I couldn’t resolve the problem. After consulting Mr. Peter again proved helpful, as he discovered that a persistence configuration was missing during startup. Once fixed, everything functioned as expected. Meanwhile, he suggested using either the override or base method for my logic, which I plan to tackle next week.

Conclusion

This week was a valuable learning experience filled with challenges, problem-solving and significant progress. Each day presented new tasks that deepened my understanding of MongoDB, synchronisation processes and testing environments. I learn a lot and feel a sense of achievement after overcoming each obstacle. The journey reinforced the importance of patience, attention to detail and continuous learning.

Optimizing user interface details

In the first three days, Mr. Peter assigned me tasks to optimize user interface details and enhance data handling processes. Firstly, I tried to add a function for validating data to ensure that the main data uploaded is not null. I also added a UI/UX feature that allows users to remove or add images in the payment edit view. After that, I worked on rebuilding the latest API to include a barcode for the store and integrating it into the code. Furthermore, I modified the subtotal printing logic to display 0 instead of NaN when the unit price is null. Additionally, I updated the payment statement to allow users to separate bills.

On the payment page, I enhanced the search bar functionality, enabling users to choose a search type, such as customer name, and various IDs. Besides that, I added hotkey and focus-handling features, allowing users to press the arrow key to select a customer in the POS page. Later on, I modified the network handling functionality to show an alert only when the user tries to call an API. For this, I added a function in the retail API service file to check whether the network is connected.

Thereafter, I redesigned the table alignment in the POS system to improve the layout for better clarity. However, I noticed that when zooming in on the page, the table header would stack with the table itself. I plan to find a better way to resolve this issue and enhance the design further.

Create Return Order Page

After completing these tasks, Mr. Peter assigned me to work on the return order page. This task was quite challenging because it involved multiple APIs. Firstly, I designed the UI page and drew a workflow for it. After that, I added an invoice search dialog as a component and imported it into the return order page. This dialog allows users to click the “Create” button to display a search interface listing all paid invoices that have not been canceled. Once an invoice is selected, all its line items are displayed. The most difficult part was enabling users to select specific items and input the quantity to return, which took me the entire Friday to solve and refine the workflow.

There are still more tasks to complete on this page, such as setting authorization for different user types. For instance, administrators can accept or reject return requests. Different users may have varying privileges to access this page based on their roles.

Conclusion

This week has been a productive and challenging experience, as I worked on enhancing various features and tackling complex tasks, particularly the return order workflow. These assignments helped me develop problem-solving skills and improve my technical abilities, especially in handling APIs and refining the UI/UX.

Monday, November 25, 2024 – Last week, I focused on refining the user interface of the website I am currently building. A key milestone was improving the breadcrumbs component, which I initially created by referencing a popular tech blog. While the component functioned well, it did not fully accommodate the dynamic routing I had implemented. Additionally, the homepage unnecessarily displayed the “Home” breadcrumb, which was not ideal.

To resolve this, I added a condition within the component to filter out the “Home” breadcrumb when the route was read in the component originated from the homepage. This adjustment worked; however, another challenge arose, displaying the dynamic slug route appropriately within the breadcrumb. Since I used Next.js optional dynamic routing for SEO purposes, the breadcrumb also displayed irrelevant object names instead of just the intended page titles. To address this, I added a filter to clean up the route data, ensuring it displayed the desired output. After some iteration, this solution worked, but I am still reflecting on whether my implementation aligns with clean code principles.

In addition to the breadcrumb enhancements, I revisited the thumbnail gallery component I had previously created. While the design required only minor tweaks, I realized that turning this component function to a client-rendered only on the edge component was essential. The gallery’s functionality relies on a callback to update the main image display when a thumbnail is hovered over. This required using useState, which automatically converted the page to a client-rendered component.

To enable server-side rendering, I refactored the gallery by exporting the main image and thumbnail into their own components. This allowed state changes to be handled outside the page itself. After some trial and error, I successfully implemented this approach.

Throughout the week, I also worked on basic structural components like the navigation bar, footer, and header. While these designs are currently simple, I prioritized practicality to ensure functionality.

Towards the end of the week, I discovered an oversight, one of the pages was still fetching data from a JSON sample file instead of a dummy API. This conflicted with my plan to render the page on the server side. After switching to the API, the page became client-rendered again. I’ve marked this as a task to revisit later, as my focus is currently on completing higher-priority items.

While there’s still much to do, these iterative improvements have brought me closer to achieving goals for the project.