Month: December 2024

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.

Eleventh week as an intern in Tong Hin. Monday start off with fixing the code I did on webapi. After fixing most of the problem last Friday and help from Mr. Peter, I fix on the extract token and has finally end on user and address API.

After that, resuming with the media playing by getting chunk by chunk. It took me a while to figure it out as there is no reference from OwnCloud. I looked at other people code and use it as a reference to create my own one. The one I did is more direct and able to control it with variable. Mr. Peter showed me another alternative named DashJS. It is almost the same as mine but DashJS provide dynamic video quality based on internet connectivity. Both of it still cant solve one of the major problem, but we proceed with the one I done.

Thursday continue with updating the brand by putting in the file and also delete and update file on one single API. I had also add batch update on the brand based on the IsEnable, redirecting of expired URL by making previous URL to API and also did Sitemap simulation by just changing some code it will be working.

Summary, I had done different task that have listed out and has done 66% of it. We do have a holiday on Wednesday to celebrate Christmas and it has been a happy week. My internship period left with only 2 weeks and I hope I can surely done all the task flawlessly.

Monday, December 23, 2024 – Last week, I focused on testing the core functionality of the entity, which is to dynamically call APIs and replace the previously hard-coded UI pages. To do this, I integrated the API into the existing hard-coded UI. The design schema was created with flexibility in mind, capable of storing data for multiple pages using a general field name that can be applied across different types of content.

The flexibility of this schema is a crucial aspect of its design. It enables the system to store dynamic content, which can be rendered on various pages without the need to manually create separate DTOs for each page in the UI. Each content section within a page is represented by its own FieldName and FieldValue, where the FieldName can correspond to different parts of the page, such as headers or body text. Additionally, this structure supports nested blocks, allowing content hierarchies where sections can contain other sections, making it adaptable to a wide variety of content needs.

Instead of creating static pages for each type of content, this approach relies on the API to fetch the data for each page, reducing redundancy and making content management easier for the admin. Mr. Peter also suggested adding a preview section to the UI to help users understand what to expect. This introduced a challenge, since the page was designed to be used for multiple types of pages, I had to figure out how to implement a preview specific to each page. After some trial and error, I found a solution, though I’m not sure if it’s the most optimal approach.

Currently, since there’s only one confirmed page for the UI, I inserted a conditional check to determine if the page being managed was the specific one. If it was, the preview would be shown, otherwise, a “nothing to preview” message would be displayed. To facilitate the preview, I divided the UI into a separate component that can be called with the necessary values passed into it.

Additionally, I began working on creating another entity for managing metadata on the backend. This entity follows a similar schema design and will be accessible to admins. Towards the end of the week, I still have few CRUD API functionalities to be completed and will continue working on them next week.

Starting for the first day of this week, I create various file versions for line items that required for the user to input only the important data to be processed. As these different line items are needed for the specific transfer commands where we discussed last week. Soon after creating, I also update for the relevant name for the services and the commands. Meanwhile, I also update for the validator to ensure only valid property is included. Then, I update the implementation for transfer services by replacing the replaceOne method with the suggested updateOne method. In the method, I also include the updateDefinition for the data updating for the transfer. After that, I test the updated code manually by calling APIs, to determine any potential errors may happen. After successfully testing, I then initialise the data by referencing the other files provided as suggested to use the factory data creation method. Also there some typo error on naming the commands folders, and I rename it with a more suitable names.

Moreover, I try to move the transfer and user logic from handler to service, as mentioned that the logic should be processed under services. I initially move the transfer logic, my approach is that using switch case to match the different commands to pass it to the related method. However, I realise that it may be over coding, so I discard this approach. I then create various task methods so that the command can just call the service method to process the input. After that, I also manually test them as well with API callings, and soon everything is success. Meanwhile, I also update for the user service, and soon I commit my changes and push them to my branch. Moreover, I continue on refining the transfer order services. I also implement a new method for item for transfer, and try to understand what had created and updated. Then I try to continue doing my tests where I just successfully create the success part only for create and update tests.

Furthermore, I start modifying the DO files by adding the suitable logic to create a new DO and the update along with the cancel. I try do this part by this week, where I try to read the manually create data from the collection. Then, I try to create a DO data, as creating will also update for the related transfer order with the quantity and also add the new transfer DO into the list. After creating, I then continue to do the cancel part. So, it can reset the quantity to the transfer order as well as remove the transfer DO form the lists. After these two are succeed, I then realise that, I should prioritise for the transfer order, I then continue on modifying the logic on transfer order. Mr. Peter mentioned that there are some amendment for the naming and also realised that I should complete the tests before proceed to the next part. Mr. Peter also advised that mock test is better that testing from the database.

Apart from that, I continue doing the transfer order testing by adding many possible testing for each commands. Fortunately, all the tests are pass as expected. Mr. Peter then reviewed my tests and suggested that some other tests that I missed. Meanwhile he also guided me on how to test for the new item status for each item. Besides that, I also update all possible testing suggested and passed as expected. Meanwhile, Mr. Peter also push with a new implementation of item status, so I uncommit back my work and stash the staged file in order to pull the new changes. After pulling, I review the changes and also Mr. Peter guide me on the new implementation and initially try for the the RTP. Soon, I try to understand the services and update for the method. However, something errors after updating the method of transfer logic, so I try to look through for the exception and determine it. Then, Mr. Peter reviewed my codes as well and also mentioned that there is unnecessary code updates. During the testing, Mr. Peter suggest to amend for a better transfer order design for the line item. He also found that I haven’t modify the naming where I supposed to do it. Then, after the little modification for the test there are some config error occurs. Soon, I push my works to my branch after some modification and will continue on next week.

Conclusion

In summary, the week is highly productive and focus on refining and optimising various components of the project. I restructure the transfer logic alongside creating and refining methods for transfer order. The rigorous testing and reviews help identify areas for improvement and ensure robust coverage.

Tenth week as an intern in Tong Hin. Monday start off with another testing with OwnCloud after doing local file explorer on last Friday. Owncloud is a file platform, one of the advantage is to prevent Distributed denial of service (DDoS) which the web site need. Researching is time consuming as need to look for every details and questions in mind. Some of the information are even from discussion of other user to get the answers.

After setting up and build the API and test for file explorer, I have faced another issue. The video are not suppose to be download directly from the video player. Downloading directly from the video player will bring down the OwnCloud.

Another round of research off again, beside the looking for player. I was also doing some update on the code. Mr. Peter gave me another new set of task, which include sitemap, history API and etc. I took some time to digest it from his word and list it out. I start off by the sequence order of his word.

Friday, Mr. Peter has checked my address and user API code and there were lot of mistakes. I spend the whole morning to fix it, it was fast and almost done. I did some question asking on the afternoon and clean the code for the last 2 hour. I spend a whole day just to do my previous submitted works.

In summary, I have start doing on a file platform and also new task are coming by. Fixing old code sure is time consuming and hope that is the end. Next week is sure a busy week. Hope I can get to do my best for the following weeks.

Solve Signal R function

In the first three days, I worked on connecting SignalR to receive the progress count from the item API. Since connecting to SignalR was new to me, I initially faced several challenges. First, I struggled with determining the correct URL to send to SignalR for establishing the connection. Despite trying various URLs, I couldn’t connect successfully. Finally, I sought help from Mr. Peter, who provided me with the correct URL. However, even after using the correct URL, SignalR still showed an unsuccessful connection.

After debugging, researching, and consulting ChatGPT, I discovered the second issue: the HTTP transport type needed to be explicitly initialized. By default, SignalR uses WebSocket as the transport type, which didn’t work for this connection. Switching to long polling as the transport type resolved this issue, and the connection was established. However, a third problem soon arose.

While fetching the sync progress, I noticed it always got stuck at 120/240 and stopped. After reviewing the log reports, Mr. Peter explained that the syncing process needed to be completed before fetching all item data. Some items were stored and appeared in the database, while others located in stores did not appear in the MongoDB database. This mismatch caused errors. By creating a sync function, I was able to synchronize the items successfully and fetch progress without issues.

Next, I developed a function to cancel the sync progress. This function stops the sync process for an item that hasn’t finished syncing by calling the stop API and passing the GUID, which halts the sync automatically. However, I encountered another issue: the cancel button didn’t work as expected. Initially, I suspected the API, but debugging revealed that the function was rendered twice, causing the cancel function to be invoked twice. As a result, pressing cancel stopped one progress instance, but the other continued syncing. This behavior was due to the Next.js configuration, which caused the useEffect hook to render twice. After adjusting the Next.js configuration, all SignalR-related functions and sync item processes were finalized successfully.

Generate 1 million data

On the first day, I tried to generate 1 million data records for each page on the system. Since this process would take several hours, I asked my colleagues to help by generating the data on their computers and accessing my IP address. After generating all the datasets, I performed some performance testing on API queries for item or user details and created new data after reaching 1,000,000 records. By the end of the tests, all functionalities worked smoothly, ensuring the system could remain operational for many years.

Generate invoice pdf template

While the data was being generated, I researched how to build a PDF template for invoices using HTML and JavaScript. I explored several components like html2pdf, react-pdf-html, and others, but none of them worked for my needs. Some required API calls to generate the PDFs, which would incur extra costs, and others weren’t compatible with Next.js. Eventually, I found a component called PDFMake that met all my requirements. It allowed me to customize the template, and once the PDF was generated, it provided a temporary URL. This feature is very useful when generating large numbers of PDFs, as it prevents storage overload by not saving them to local files. I also added an iframe component to preview the PDF and a print function, which allowed users to print the document without navigating to another tab. However, while coding according to Mr. Peter’s template, I ran into an issue: the component couldn’t import images or draw outlines for certain information. Mr. Peter then advised me to stop working on this task, as he had found a better solution for generating the PDFs.

Syncing users and items data

After completing the previous task, I was assigned a new one: syncing data from MongoDB. My first task was to sync the user data. I called the sync API, which synchronized the data from the retail system with the Mongo database, integrating data from different systems. I then tried to separate the data views: one for the retail system only and one for all users, including those from the other system. However, I discovered that I couldn’t view the details for the “All Users” page. I may need to create a separate API to search for specific data details. Afterward, I worked on syncing item data. Mr. Peter asked me to use the SignalR component to track the progress of the data syncing. This was because when calling the sync API function, there was no way to monitor its progress. By using SignalR, we could connect to the API and receive a progress count, which we could then display as a progress bar.

Starting for this week, I continue doing the transfer order tasks. After the discussion with Mr. Peter last week, there are several commands needed for transfer orders, transfer delivery orders and transfer receive. So, I start to create the necessary commands and update the transfer order services and controllers. Meanwhile, I also create some empty file folder for all transfer repositories and services. These files are just as a reminder for future me while priortizing the transfer order tasks. After that, I spend time familiarising myself with the existing System again to ensure that the retail functionalities align with the system. I then perform a git pull to fetch the additional item file given to review the file changes. Meanwhile, I add the necessary migrations to update the database but I encounter some issues when updating. I try to truncate the affected table and restart the identity and the database updates are build succeed. Next, I also try to understand the new tables along with the item repositories and services.

Moreover, I continue working on the cancel commands. The cancel command are somewhat complex due to their relationship with the commands. I spend time on analysing the problem, trying various solutions and eventually I succeed in maintaining the relationship. Additionally, I update the create commands to validate input for prevent same item barcodes are being input. Afterward, I update the functionality to ensure proper interaction with the database, I plan to finalise it this week. Similarly, I also work on the undo commands by updating their logic and testing their flow. Once these updates were successful, I move on to the other service. This task also particularly challenging because it also required interaction with the database. I also plan to complete the necessary database-related work for command by this week.

Besides that, I continue on refining and updating the logic for the transfer order services. I then return to the service and add extra collections such as along with their respective repositories, commands, controllers and services. So, when every command API call related would create details in the collection, while undoing command would remove those details. However, after discussing this approach with Mr. Peter, he suggested that creating additional collections would add unnecessary complexity. Instead, he advised extending the information within MongoDB itself. Although I initially found this feedback a bit disappointing because I had worked hard to create additional collections, I realise that simplifying the architecture would benefit the entire project in the long run. His advice made me reflect on the importance of seeking guidance early to avoid wasted effort.

Apart from that, I keep refining various commands and removing unnecessary work to streamline the process. Then, I revisit the doing for the commands, I add the necessary item repository function so that they can interact with the database to validate item quantities in the respective stores. After successfully implementing these changes, I update the transfer order MongoDB schema by adding additional information. Then, I continue working on the services. Once the command and undo command functionalities are fully operational, I explore the database to verify what data was being created and updated. During my discussions with Mr. Peter, he suggested separating the logic for items with the same line item to avoid user confusion when processing inputs. Additionally, he advised using the correct repository for database interactions within command and moving some of the logic from the handler to the service layer. Lastly, he also recommended using the updateOne method instead of replaceOne in certain service updates.

Conclusion

In conclusion, there were moments of complexity and setbacks, especially when dealing with architecture adjustments. Despite these challenges, I feel that I’ve made solid progress and tackled significant aspects of the transfer order tasks at hand, even though some remain incomplete.

Monday, December 16, 2024 – Last week, my focus was on developing an entity to store and manage information about the website and company. Initially, I designed a simple UI to display this information although everything was hard coded directly into the application. Later, Mr. Peter tasked me with creating an entity/schema capable of storing data for multiple pages, eliminating the need to define a separate entity for each page.

Following Mr Peter guidance, I drafted the potential structure (including key fields and their types) for the entity and discussed it with Mr. Peter. Once the design was finalized, I quickly started creating the context project. Since this entity was built for MongoDB, I discovered that setting up its schema model did not require the same configuration initialization as SQL entities, which I found interesting.

Next, I developed APIs to support the entity, including endpoints for creating, retrieving by ID and URL, and updating. Each API was accompanied by unit tests to ensure proper functionality. Although I encountered a few issues due to oversights, I managed to resolve them, and all tests eventually passed. The logic for retrieving data was notably simpler, likely because only one filter was required at this stage.

Once the backend APIs were functional, I moved to the front end to integrate and test them. Previously, the UI displayed hard coded information, but now I needed to enable admin users to create and edit pages dynamically. I started by creating a page to list all pages, including a “Create” button to navigate to the creation form. After completing the list page, I developed the creation page to test both the list retrieval and creation APIs in action.

By the end of the week, I successfully integrated both the APIs and front-end functionality. Next week, I plan to test the entity’s primary purpose, which is to dynamically call the created APIs to replace the previously hard coded UI pages. Additionally, I’ll also focus on updating the admin page, which requires some additional modifications.