Month: November 2023

Continuing the task from last week, I modified the arrangement of the item box in the main page as well as the “price” and the “stock in the item box itself horizontally by solving it with CSS style and I controlling the spaces between each of the item box. Besides that, I also adding two navigator tabs with “Code” and “Record/Stock” labels and adding the new table in the item details panel. In the content of the “Code” tab, I added the Barcode of the item and arrange them horizontally and space evenly. In the content of the “Record / Stock” tab, I added the “History Sales Record” table and “Stock” table and space evenly between each of them.

I also modifying the styles of the item detail panel according to the colour, effect and position of the elements inside the panel, especially the division between them. I separate them into 3 part, the main part includes the image, name, stock, price, UoM and some description or remark, the second part include the navigator tab and the content of it, and the third part include the extra information such as the attributes.

On the other hand, I added the additional table as a panel to show the detail of the item and it will pop out when I clicked the particular button in the item detail panel. I also added the dropdown menu and it’s sub navigator, the “Filter” sidebar which is on the right-hand side of the item page – able to filter the item according to the brand of the item and able to sort the price from lower price to lower or vice versa and yet the “Pagination” feature which will control the page of maximum 20 items per page.

Lastly, I modified the position of the drawer navigation to the left-top of the Item Page and push all the elements to the right when I clicked the hamburger icon. Previously, it was appearing under the item list, Mr. Peter suggest me to create a new page that include the drawer and the header only to settle this problem, but actually it is just a division problem, I changed the arrangement of the code according to the division to overcome this problem. I also modified the styling of the dropdown menu with the colour, hover effect and the width of the menu list.

At the onset of last week, my initial assignment involved implementing a temporary item filter functionality within a specific entity section of the application. This entailed making minor adjustments to the view model and slightly modifying the context. Following the implementation, I rigorously tested the filtration process to ensure flawless functionality and accurate data transmission. Subsequently, I undertook another task to incorporate a progress dialog bar in a similar part of the application. Although this task required minimal modifications, I conducted thorough unit tests to identify and address any potential oversights. During testing, I discovered some test failures, which traced back to the omission of mock services necessary after the implementation of SignalR.

Upon Mr. Peter’s review of my work, it became apparent that I had misunderstood the assigned task. It turns out that I was instructed to create an additional button instead of implementing another filter. Upon completing the task, I dedicated time to cleaning up my code, ensuring the removal of any unused or redundant segments. I then proceeded to inspect the user interface of the newly added feature.

Towards the conclusion of the week, several bugs were identified that necessitated fixing and code modifications. One notable issue involved a progress bar loading data, but when it exceeded 100 generations, a message indicating a batch size too large would appear. This particular issue will be my primary focus for the beginning of this week.

Last week I continued with the development of the customer page. Since I had already done the parts of the customer form before, I will continue to complete the customer form. Customer forms contain multiple data that needs to be inserted into, including name, contact number, remark, email, address lines, address options, address types, and detail contacts. This data is stored in one array per customer and some data will have multiple arrays. For example, customer 1 has multiple addresses, address options, fax, address contact and address type in one form. So I need to make the addresses work as an array within the form.

The solution to this problem is to use the “.map” function which allows the array to loop and display one at a time. When the array displays one by one, it is much easier for me to make the form. It is because not only can reduce the code required, but also easier to handle user input. The columns that the user input is the same, but only the array changes. For example, the first addresses will store data in “Addresses [1]”, while the second addresses will store data in “Addresses [2]”. The user can add as many addresses as they like when creating the customer data.  I had tested the functions and the data is stored correctly in the array, which helps me to manage the data.

Besides, I also make a simple button that allows the user to click and add the empty address column. It will display like 2 address array per row, which will be different with the prototype I created before. In the prototype, I make the address array to be shown on the prompt page, but I found it difficult to develop because I already make the form prompt. To solve this problem, I decided to make the address column scrollable. This not only minimizes the number of clicks, but also keeps the length of the prompt page to a minimum. The prompt page will only have the exact same size and will not get longer and longer as you add more and more customer addresses.

Also, at the beginning of the coding, the address loop is in the same file as the other column. This makes the file very long. So I decided to put the functions related to addresses in separate files. However, the length of the file is still very long, I need to further minimize the length and move some functions such as address option, address type, address line and fax contact to new files. Finally, the length of the file has been reduced and the other file also has a shorter length. The files should be less complex and easier to debug. If one of the files has an error, it will be easier to identify and fix.

Finally, the form for the customer page is almost finished. I have managed to add multiple addresses to a single customer record. I will move on to using the API in the next few weeks. The API is a new genre for me and I may face difficulties in the following weeks.

I began this week’s work by carrying on with the customer controller tests refactoring. I have combined the address and customer table data creation into a single variable. As a result, debugging and determining whether issues occur throughout the data generating process will become simpler for other users. In addition, it will be simpler for other users to add new customers or addresses for existing customers. Finally, the code will become more comprehensible by altering the customer and address table’s data creation structure.

After modifying the data seeding on the customer controller tests, Mr. Peter has informed me to do a new task, which is to do the query for items. The items will have the query feature of get the item list by name in pagination, get the item list with the filters, and get the item details. The item query will be different from the query for the customer, since the item will be a query from MongoDB. MongoDB is a cross-platform, source-available document-oriented database system. categorized as a database software using NoSQL. Since this is new to me, I’m still learning how to query from MongoDB.

Moreover, Mr. Peter has also given me another task, which is to test my API by using the Postman app. Postman is an API platform for building and using APIs. Postman makes the entire API lifecycle easier to understand and facilitates teamwork, enabling us to produce better APIs more quickly. In order to use the API document in the frontend implementation, I must first create a subdirectory containing it. Subsequently, I must publish my API project and transfer the generated files into the user folder that I have set up in FileZilla. Subsequently, I will need to rebuild the docker file to ensure that everything goes as planned and attempt to use Postman to execute the API.

But, I encountered an issue when utilizing Postman to run the API: I am unable to connect to the database. I’ve attempted a variety of approaches to the issue, such as altering the connection string’s hostname and adding additional symbols. Still, none of the fixes I tried have been successful. So, Mr. Peter has advised me to add some log information in my project to find exactly what is the problem that led to the error of the API. I have tried to add the log information in the controller in the API project. The value of the connection string was exactly what I wanted but the problem still hasn’t been solved. I will try to solve the problem next week.

After receiving some advice from Mr. Peter last week, I’m continuing to modify the customer function this week. First off, I’ve made improvements to my test for creating and deleting commands from customers. This is accomplished by adding the addresses count. I have to make sure that the addresses that customers submit will be added to the address table when they are creating new customers. So, I must verify that the address table’s address count is accurate. I have added a new function in the repository project, which is to get the total number of addresses in the address table. Thus, I can use this function in the testing project to see if the created addresses have been added or not.

The validation for creating and updating client features has then been added by me. The customer and created addresses will be verified as legitimate by further validation. Thus, I have verified the customer’s email address and phone number. The customer must input a phone number that is between 10 and 11 characters long. In the meanwhile, the client must confirm that the email address they supplied complies with the requirements for a valid email address format. In addition, I have developed validation that will determine whether the customer supplied any duplicate addresses. Furthermore, I have also developed validation to ensure that the customer would only choose one address.

Additionally, I modified the list query’s logic such that it now just displays each customer’s default address. In the meantime, the selected customer’s details will be displayed initially by the id query. A button next to the address box allows the customer to click and view all of the addresses they have created. Following the completion of the aforementioned enhancements, Mr. Peter has requested that a swagger be created for the customer feature. With the help of a user interface (UI) called Swagger, our users will be able to test out API calls right in their browsers. It will be possible for me to construct the swagger once I have appropriately configured everything.

Finally, after successfully building the UI, Mr. Peter reviewed my code. He realized that there are some improvements in the coding part that I can refactor it. I will try to refactor the code next week.

Time flies, this week is pretty fast. It might be due to the holiday on Monday or just the joy of development. This week, I was assigned to start developing the system. In the beginning, my first thought of developing the main page was why this is different from designing the prototype. I was confused with the styling of the buttons, columns, and navigators. Because of that, I noticed that rather than styling the pages, I should focus on developing an actual workable function. It is useless when the page is beautiful but without any function.

I had developed the main page for two days, but Mr. Peter required me to develop the customer page first. He mentioned that I should prioritize developing a customer page because the main page needs to search for the customer when placing orders. I listened to him and started working on the customer page. The customer page is different from the main page because it contains a table with a lot of data. The solution for displaying the data is using the .map function to map and display the customer data on the table. However, I was confused with the add address functions. In this customer page, the user can add as many customer addresses as they like. I am not familiar with developing such a function, thus I googled and tried to get some tips.

Also, I noticed that React-hook-Form has provided a method called useForm that helps make a form. The userForm method has successfully reduced the length of my code and I was happy with it. But I still keep the original version of the code as a copy. In case the userForm method has some problem, I am able to use another method to complete my customer page. Besides that, I tried to download and use the mkcert to create a local certificate. This certificate allows me to make my page secure and helps me to view the tokens.

At the end of this week, I had some part of creating customer details, creating the customer details and main page. I will continue my task next week and complete the create and edit function on the customer page. I keep my copy of the code in the server. This ensures that my work will not disappear on the next week.

Last week, I was required to solve a bug where the progress was not being displayed gradually but immediately showed completion. Initially, I suspected the issue might be in the implementation of the progress bar within the view model. However, after multiple debugging attempts, I shifted my focus to the server-side code.

Despite several debugging sessions, I found myself perplexed about which part of the code was responsible for updating the progress of the progress bar. Taking a deliberate approach, I meticulously studied the flow of the sample code and compared it to my own implementation. While I suspected a missing piece of code, pinpointing its location proved elusive.

Ultimately, I seeked guidance and consulted with Mr. Peter to clarify some aspects of the code that were unclear to me. It was brought to attention that a callback function, responsible for sending progress data to the client side, had not been implemented as of yet. This newfound understanding allowed me to comprehend how the callback could be effectively incorporated.

Following this insight, I made modifications to various sections of the code that involved implementing progress bars with SignalR. I ensured that the progress bar functioned seamlessly after the adjustments.

This week, I started to code the prototype which I completed last week by using React with TypeScript. I add the header, navigation bar, drawer navigator with a hamburger icon, search bar and item list. Meanwhile, I started created the style for each part by using css. Since I used the latest version of the node which is newer and it cause some errors that lead to the code cannot run completely, so I downgraded the version by installing the v13 to solve the problems.

Besides that, I create a json file to store some mock data of item list and the details of the item. This json file can help me decrease typing the same things by using the loop. This json file can also keep adding new items without any issues.

I also create a dynamic panel for showing the items detail when I clicking the item I want in the “Item Page” which will show the image, name, price, and others. I also added table into the dynamic panel which is the conversion factor of UoM (Unit of Measure).

As mentioned last week, my task was to employ a progress bar that implements SignalR. However, this approach revealed a bug that necessitates some debugging. Initially, upon integrating the SignalR method into the feature, I observed that the progress bar was not functioning properly. This prompted me to embark on a debugging session to identify the source of the mistake.

It turned out that the issue arose from me directly using instances injected through the constructor. This led to problems with transactions, as these instances might be associated with a different scope or not properly disposed of when the loop iterated over different input or command. To address this, I created a new scope and obtained instances of the contexts from that scope. This ensures that each transaction operates within the correct scope, preventing interference between transactions and potential issues with the lifetimes of the database contexts.

Subsequently, I focused on the main objective of the week, which was identifying a bug in the progress bar when users repeatedly clicked on a button requiring the usage of the progress bar. Initially, I assumed that the bug might originate from the context. However, after conducting multiple tests, all aspects within the context successfully passed data without encountering any errors. The issue, as it turned out, originated from the client side, specifically during the attempt to initiate the SignalR connection after the initial connection had already been established.

In my initial attempt to resolve the bug, I proposed a solution and discussed it with Mr. Peter. He then refined the code to implement a cleaner approach. As the week concluded, one lingering issue still required debugging: the progress did not display its progress but instead showed completion right away. I plan to address this in the upcoming week.

This week I have continued to modify the customer feature. Mr. Peter had instructed me to add another table address. The customer table in the customer feature will have some relationships with the address table. Each customer will have many addresses. In addition, each customer will also have default address. Furthermore, each address can only belong to one customer. Mr. Peter continued by pointing out that I had made a mistake in the customer table, as I had accidentally used the plural word when referring to a single field.

First, I changed the column name from a plural term to a singular word in the customer table. In addition, I eliminated the extraneous column that was appended to the address table. In the customer table, I have further included the addresses. The return type of address will be present in these two attributes. In the meantime, an additional feature has been added: customer addresses. This attribute will hold a list of addresses that are specific to a given client. Next, I created the address table and included the attributes needed for the address table. I have also included the customer attribute, that has the type of customer since I need to know which address belonged to which customer. 

After creating the new address table and implementing the relationships between the customer and address table in the core project,  I will need to change each of the customer features, for example: list query, and others. The relationship I have built in the core project must be implemented in all customer features. So, I started to modify the id query. I’ll start by adding the attribute that this query will display after it is implemented. I then have to change this query’s dapper implementation. This is due to the fact that the earlier iteration of the dapper implementation only had a basic query method for retrieving data from the customer table. I must, however, query the customer and address tables for the time being. As a result, I must modify the dapper implementation such that these two tables have a one-to-many relationship. This is the trickiest part since I have to write a lot of additional code to make sure this stuff works. 

After making various changes to the dapper implementation, I can now execute the query correctly and test it multiple times. I can therefore keep changing other client features. After modifying all customer features, Mr. Peter advised me that there are several improvements that I can do for the customer features, such as adding validation when creating or updating the customer, simplifying query and others. So, I will try to improve the customer feature next week.