Month: December 2023

Last week, I had developed some part of the order page. The orderList page was the first thing I built. The orderList will be able to list all orders and filter specific orders based on the order number. I had not established the layout appropriately because the order list was still missing the dummy data. By the end of the week, I saw that the layout of the orderlist page was flawed and needed to be corrected.

Following that, I created the order creation function. Because every order system requires an order creation function, the order creation function is regarded as the most crucial aspect of this project. As a result, I spent some time on the layout. I divide the main page into two sections; the left section is fixed and cannot be scrolled, and vice versa. In addition, I made a header for the search customer Id and cancel order functions. The user can search for the customer by entering the customer’s name, and the customer Id is important for order creation. Every order has a customer Id; if the customer is making a one-time purchase, the order system will record the sales order under a default Id.

Between the new and previous orders on the order page. The user can return to the order page and adjust the orderList row that needs to be changed by clicking on it. It differs from the prototype created by one of my coworkers since she intended to change the order data in the order list page using the prompt form function. Fortunately, the changes were not difficult to implement, and I should be able to complete the task within a day. However, this will cause a new issue; now I should create a button to reset the order page, which will affect the layout I already specified.

In addition, I modified sections of the customer page and integrated Mr. Peter’s general alert feature. The general alert function is the one that occurs after the API connection is established. For example, if I click to create a new customer data, the data will be provided over API and an alert page will notify me whether the creation was successful or unsuccessful. When creating, changing, or removing customer data, the customer page will now display a notification. In addition, I integrated a webcam option that will capture the data. Mr. Peter told me that he will buy a webcam to record the data, and I believe that the webcam function will be useful.

At the conclusion of the week, I successfully created a sales order using dummy data, and it appears in the sales order list. I should keep working on improving the order page so that sales orders may be created without having to set up dummy data. Mr Peter told me that I must use the item API to choose the item to be included to the sales order. This will be my primary task, which I intend to complete by the year 2024.

Last week, I started out by concentrating on a specific segment of the report and exploring the functionality of LiveCharts packages for practical applications. To begin, I set up a blank solution and systematically established folders in adherence to the MVVM approach. After ensuring the smooth execution of the application in the initial stage, I proceeded to create views and view models, integrating a fundamental chart as per the LiveCharts documentation.

With the successful display of charts, I transitioned to the subsequent important step. I commenced by generating a JSON file encompassing essential data elements such as IDs, barcodes, and names. Integrating this data into the properties, I concurrently implemented the region manager to facilitate the presentation of multiple charts within a single view. Later, I noticed that keeping track of the changes I made over time became challenging as the application expanded. To address this issue, I decided to set up a Git repository for efficient revision management.

Following the integration of the region manager and Prism into the solution, I encountered a hurdle wherein the charts were not displaying. It took some time to identify the issue, which was eventually resolved by refining the way I passed the data into the LiveCharts element. After updating Mr. Peter on my progress, he recommended an additional step: ensuring that LiveCharts values respond to interactions. This will be my focus in the upcoming week.

Continuing the task from last week, I successfully create a Sequence Generator page with a CRUD functions. In the page, I show the sequence name and the pattern in a table form. To create or edit the sequence, it will pop up a panel form to ask the user fill up the name, pattern and the count. After I complete this task, Mr. Peter told me the purpose of creating the sequence generator is used to connect to the “Store” to generate the sequence.

Therefore, I modify the Store detail panel to add sequence name input but it is just read only. The user can search the sequence name by clicking the “Search” button provided. Once it is clicked, it will pop up a panel to show the sequence name and the pattern like the Sequence Generator page to let the user select the sequence he/she wants. When the sequence is selected by the user, it will close the panel and display the sequence name in the input field of the store detail panel. When the user clicks the “Save” button to save the store detail, the system will auto generate the sequence generator id which will bind with the SequenceId in the Dto.

Besides that, my colleague also created a “General Alert” for this project which will alert the message to showing an error, Yes or No, Confirm or Cancel and success message to the user. I apply this component into my CRUD functions which are in the Sequence Generator page as well as Store page and their detail panel. On the other hand, I also fix the CSS style file what I use “.className” method instead of directly use “body” method, so when I refresh the page, the style will not disappear.

In the end of this week, Mr. Peter check my work, he suggests me clean the code and create a page layout for all my tasks. He also told me prevent used any magic strings as it will hard to maintain it later.

I started this week by implementing the category API as part of my ongoing refactoring of the item API. The ability to query the category list, category by id, and other list has been implemented. In addition, I’ve introduced the ability to generate random items from the HTTP POST request using the item API. This API will generate random things with the item name “item” and a randomly generated GUID value when the user uses it. Furthermore, it will also generate more details for the item. It will also generate new brands and new categories when the user first uses the HTTP POST request. When the user uses this HTTP POST request to generate random items for the second time, it will not generate new brands and categories.

Mr. Peter suggested that I restructure the detail query once I had completed implementing the API for categories and the command for creating random items. He stated that there are several drawbacks when querying an item by its MongoDB ObjectID, which is why this query will take a long time. He advised me to use the barcode as a basis for my query to obtain the item detail since it is a unique value. In addition, he recommended that I combine the two query item lists: which is the primary query item list using the search name and the secondary query item list based on details into one. This is due to the fact that these two queries’ codes are quite similar.

I tested the item API using the Postman tool after I had made the necessary changes to it in accordance with sir’s advice. However, there is an error since I do not add the MongoDB connection variable to the docker. As a result, the server is unable to connect to the actual server. I therefore inserted the variable with the proper format, “mongodb://username:password@host:port,” to the docker file. After entering the variable for MongoDB, I rebuild the docker-compose and use the Postman to test the API again.

Adding the new entity to the retail system is my final task for this week. The name, id, code, and foreign key id will be its four properties. The link between the new entity and the store will be one to many, meaning that each store may have multiple entities. But every entity will only be associated with one store. The entity will have the feature of creating, updating, and deleting commands as well as the feature of querying list, and detail by id. Since I haven’t completed implementing this entity, I will continue to do this task next week.

Because of the public holiday, this week is relatively short. This week, I finished the customer page and began work on the main page. The customer page made use of each api, and the apis worked well in the customer page. The customer page can now retrieve customer data, update customer information, add new customer information, and even delete customer information. When I presented the page to Mr. Peter, he advised me to include a prompt page that displays the success or failure status of the update when changes have been made. However, because the industrial training period is coming to an end, he just provided me the code for the prompt status on the next day. He even gave me some helpful functions. Now I am free from worrying about the useEffect issue because the getStatus will be updated immediately after the change is made.

Aside from that, the backend team had finished a new API. I should use this new api called to create a new page to keep track of all orders. However, I encountered difficulties because the order api contains a large number of elements that must be used. I was concerned that I would not be able to complete the job by the end of the internship because it was less than a month. Furthermore, as December and January have many public holidays, particularly Christmas and New Year’s Day, I have less time to develop the main page. Nonetheless, I will do my best to use this API and hope that the functions of creating, updating, and deleting orders function properly.

The order API is used not just on the list page, but also on the main page. The order should be created on the main page, and the order list page will display all of the orders created. In the coming week, I will attempt to construct an order and display it on a distinct page.

Last week, I addressed a minor bug in the pagination functionality and incorporated an additional progress bar that was deemed necessary. Following that, I delved into researching the components to include in the data report and began outlining drafts to present to Mr. Peter.

Initially, I outlined four segments: the dashboard page, finance, customer, and comparison charts. The dashboard page serves as the main hub, featuring total sales, sales trends and etc. For the customer pages, I integrated charts and bar graph visualizations derived from customer data. For instance, a donut bar illustrating the percentage of high spenders, moderate buyers, and low buyers based on customer revenue. To outline these, I utilized Google Slides, focusing on conveying the general idea and content layout without delving into design intricacies.

Upon presenting the overall concept of the data report to Mr. Peter, he suggested trying out the first small section of the report and immediately experimenting with the LiveCharts packages I recommended to assess their practicality for real-world use. This is also the direction I will be pursuing in this upcoming week.

I began improving the item API code this week by giving the item a new functionality that allows you to filter the item list based on a characteristic of the item. In its initial iteration, this feature consists of querying the object only by using its name. It will query the objects that, based on the filter, have the same name. I add tests to the testing class to test the API after I’ve created it. I discovered that the feature was operational. Next, I removed the unnecessary details that won’t be shown when querying the item list or querying the item list by details. This details will only be shown in the item detail page. When removing these details, I found out that I only need to remove the details shown in the dto class of the feature, since the dto class is the place that will show which details will be passed for a particular feature. 

I kept refactoring the query item list by API by adding more details to be filtered after eliminating the superfluous details that wouldn’t be displayed in the query item list feature. I have included details like model, uom, brand, and category. I discovered that certain categories might have a parent category, while other categories might not, when I added the category to the details to be filtered. As an illustration, Category B can have a parent category that is Category A. Therefore, I must include the items that belong to Category B when I want to filter the item list that contains Category A. After doing some research on the internet, I managed to find the solution that will query the item list based on the category and its child category.

After I had completed all of the item API and tests, Mr. Peter advised me to create an API that can produce random items based on the number entered by the user. As an illustration, if the user input 1000, 1000 items will be created at random. Front-end testing can be made easier using these API. In addition, he recommended that I include the categories API.

In addition, he has asked me to create a branch from the item feature branch as he has completed the sales order API. The most recent code from sir’s order feature branch will also be pulled into this branch. I will then use the Windows PowerShell to produce the codegen code. I builded up my project and updated it for server after producing the codegen code. Finally, I keep rebuilding the docker file and using Postman to test the updated API. I discovered that every API functioned well.

This week, I continued modified the Store page, there are 2 DTOs I should used in this page, they are used to facilitate communication between two systems like API and server without potentially exposing sensitive information. I used dto to display the details of the specific store like name, addresses and other details, the other dto is used to display a list of the store name.

Besides that, I received help from my colleague to add the API address to .env.local, this API address is important which allow me to get and post the data from or to the API. Since last week I was hard coded the CRUD function, so I modified some part to ensure all the data is success connect to the API and success fetch the data according to the CRUD function. I also added some CSS style for it. For example, I added the condition for saving progress, if the data are in the progress, the button will show the “Saving….” And when it is completed, it will show “Save” and the button is disabled to clicked. For the delete function, it will pop out an alert message to ask user a confirmation to delete the data again.

At the end of this week, Mr. Peter give me a new task, this task is about the generator which will generate a counter for the store. This task is same like the “Store” page which need to create the CRUD function first. Currently, I had completed the create function and update function. This task also consists of 2 DTOs, which consists the id, name, and other details but only detail has the count. Therefore, I need to create a page to ensure these functions in this task can run smoothly.

I’m still working on debugging the item API that needs to be connected to the MongoDB server this week. Mr. Peter discovered that my code had a number of issues. First off, I have the MongoDB server that will be used for testing incorrectly identified. I just need to connect to the local MongoDB server, construct the necessary databases, and collections within it since I need to test if the item API is functioning or not. I don’t have to establish a connection with the actual MongoDB server that houses the actual data and item metadata.

Next, Mr. Peter also realized that there is another problem in my code, which is I put the server details and login credentials when committing my work and push my work into the working branch. This is dangerous as other people may steal the server details and login credentials by looking through our codebase. So, Mr. Peter has informed me to use the git command of “git reset HEAD~1” to reset or revert back my commit and “git push origin branch -f” to delete and remove all the problems that I have made in my branch. After removing the file that includes the server details as well as the login credentials, I tried to force commit these changes and I realized that the error that I made in my working branch has been deleted.

Once the connection issues with the MongoDB server are resolved, I begin working on the item’s first feature: using pagination to query the item list based on the item name. Firstly, I tried to add an item class inside the core project that includes the details of the item, for example the id, name, others. Next, I utilized the CQRS design and put the feature of query item list by search name with pagination inside the query folder of the item. I also added mapping between the item and dto class to make sure that the data passed to the dto is correct.

In addition, I made an item controller class that will call the item’s API method inside the API project. In addition, I verified that the API test was successfully completed by testing the item controller within the API test project. Following that, I produced the query item list and details based on the item feature. Additionally, I kept adding tests for these two features, and I discovered that they also functioned properly. I’ll keep refining the item API code next week.

Earlier, I came across a bug related to progress bars experiencing lags whenever a user attempted to click the cancel button. As I’ve mentioned in the previous blog, I observed that GUIDs were overseeing the progress bar, causing it to increment each time a user initiated the cancel action. I suspected that the cancellation process might not be fully executed, and the accumulation of GUIDs during each cancellation could be the root cause of the lagging problem. Thankfully, Mr Peter helped and solved the GUID bug by eliminating the progress signal that triggered multiple GUIDs. As a result, the problem of the bug of the unresponsive cancel button of the progress bar was effectively resolved.

Subsequently, I made sure to clean up the code before making the final commit and push. The following day, Mr. Peter assigned me a new and interesting task. This was prompted by the software’s maturation, which allowed for the collection of extensive data with the aim of extracting more information and insights. Mr. Peter provided a general overview of the task, where the objective of this new task is to get the most value out of the data that had been made. He instructed me to conduct preliminary research.

I began my exploration on YouTube to gain a general understanding of report data and data analysis, aiming to discern the optimal outcomes. Next, I delved into researching the appropriate medium to use, debating between PowerBI and WPF. My initial inclination leans towards WPF, incorporating the widely-used LiveCharts package. This lightweight library is known for its ease of use and seamless integration into applications, particularly excelling in real-time data visualization scenarios where data is frequently updated. LiveCharts being open-source adds to its appeal, allowing for free and customizable use by developers. While PowerBI boasts a broader range of features for data visualization, business intelligence, and analytics, its learning curve may pose a challenge for new users. Further research is needed to make an informed decision.

Approaching the end of the week, a minor bug surfaced in the previously committed code. Pagination was malfunctioning, and additional progress bar implementations were deemed necessary.