Category: Experiential

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.

In the previous week, I further modified the prototype of the main page and the customer page. I noticed that the required steps using the UI are minimized compared to the previous prototype. I was happy with the minimization because the user now can use the system with the minimum steps required. Also, the checkout page is one of the focus points for the last week. This is because the checkout page is fundamental for the system. I had created multiple payment methods for this system and was confused with the cash payment. The reason for the confusion is due to the payment was not fully paid. This system enable customer to pay their bill in multiple times. For example, they can pay by partially first time, second time, and the third time. I was confused with the steps that enabled the changes the second time. The checkout page only can enter the amount of receiving but not the exact amount that the customer needs to pay. This caused the customer not to get their cash back in the first or the second payment. The customer needs to pay the exact amount for their bill, or else the last payment with become less. If some people are willing to pay 88 for the first time but this person paid 100, this person will not be getting any changes because he or she still owes the company.

Mr. Peter and I had no solution for solving this issue. He said that he would receive all the money without paying back the customer because the customer still owed the company. But I do not agree with him. Even though we can’t solve the payment problem, I still completed the prototype of the pages. The customer page is added with the functionality of adding multiple addresses. Mr. Peter told me that the customer might have multiple addresses and need to be recorded down in the system. Besides that, I added two new pages. The page will record the payments for customer A and help the staff to understand the payment done. On the other hand, the payment list will list all the payments from the customer. It helps the customer understand the overall payment history. In the payment list, it will only show the date, customer name, amount, and payment method. The staff are not able to see the profit this company made when looking at this page. 

In conclusion, the prototype was almost completed and I was ready to start my coding life in the following weeks. I will try my best to use my skills and make a comprehensive system just like the prototype. The actual system will contain multiple pages, which can still be added through the lifecycle.

Continuing the task from last week, I modified some features of the “Item List” in Axure RP 10. The description of the item, I modified some of the details to make them as a table form. Since the dynamic panel was too small, I adjusted the panel size and modified the position and arrangement of the items inside the panel to fit all the features in a panel.

After that, I added the UoM (Unit of Measure) which is a standard unit of measurements used when accounting for stock, and expressing them in quantities for each item’s description. Due to the fact that each item not only sales in a UoM, I also modified it as a table to view all the conversation factor of pricing based on the UoM.

Beside that, I modified the item’s name based on the brand, model and part number of the item. I also make it to a table to easy the user to see which categories are and other information of that item. Lastly, I create a pagination feature in the prototype to easy the user browse the items.

Mr. Peter has given me a new assignment for the third week of my internship: creating a new entity for the system. The entity includes functions such as create a new entity, edit or delete an existing entity, and list out the entity list. Firstly, sir has instructed me to use the Microsoft Visio tool to develop the table for the entity. Microsoft Visio is a diagramming and graphics application. The client properties, such as names, addresses, and other details are included in the table I created.

After developing the table in Microsoft Visio, Mr. Peter asked me to write the code for the entity that included the feature mentioned above. We have used the domain driven design approach to develop the system. The domain driven design approach is a software design approach, which focuses on modeling software to match a domain according to input from that domain’s experts. So, I need to separate the code for the SQL portion from the domain part. Next, I started to develop the first feature of the entity, which is the feature of getting the full list. Since the feature of getting the full list is a query, I put this feature inside the query folder of the feature folder. This is in line with the CQRS design which is to divide a system’s command portion from its query portion.

In addition, I created the API controller for the entity object so that the API could utilize the features I had created for the entity. I also write the testing code for the API controller in order to test whether the API will function correctly when I use it. During testing one of the features in the entity, I faced an error in which I couldn’t retrieve the correct status code of HTTP. Following Mr. Peter’s advice, I utilized Visual Studio’s debug button to identify my mistake. Debug is a feature that can detect the errors in computer programming and software development. I discovered that there was a mistake I had made when developing this functionality for a different project after activating the debugging button. After fixing it right away, I discovered that the test had succeeded.

Later, I continued to develop other features inside the entity. In conclusion, this week of internship was quite hectic for me since I had the chance of trying to create the first feature for the web-based system.  

Last week, I completed the UI design for the cleanup task and proceeded to test the UI flow to catch any potential bugs I might have missed. After ensuring that the basic interactions, such as using the search bar and checking data checkboxes, were smooth and functional before the actual data cleanup, I began to assess the cleanup logic. I meticulously examined the results to confirm if the cleanup process was working correctly.

During this process, I not only fixed the logic but also cleaned up the code. Given that this task was not new to me, I took extra care in placing the code precisely where it belonged. While validating the data’s accuracy, I identified a few instances where the logic did not fully align with the intended conditions. This prompted me to refine the logic and code, resulting in a more robust implementation. I encountered challenges when dealing with specific data. Achieving the correct data required a tricky approach, involving retrieving data from different repositories before obtaining the desired data.

Toward the end of the week, I presented my progress to Mr. Peter. One decision I made, which I had reservations about, was using a loading bar dialog instead of a progress bar dialog during the cleanup process. This choice was influenced by the complexity of sending a list of data to the backend, making it difficult to track and update the cleanup progress bar. However, Mr. Peter introduced me to an alternative method using SignalR to execute tasks and achieve the desired progress data. However, adopting this method also necessitated my efforts to identify bugs within its implementation, which is my main task for this upcoming week.

This week I have been assigned the task of creating three pages of prototype. I was charged on the prototyping system page and the customer page. Before starting prototyping these pages, I studied the concept of the page and drew the first draft of the page on a paper. The first draft of the pages did not satisfy my colleagues and she suggested I further enhance the user interface.

After a few moderations, I came out with the first prototype of the page on the Axure RP 10. However, the page I created was too complicated for Mr. Peter. He wanted me to reduce the “clicks”, his perception of the system is to minimize the “clicking” process, which means the amount of the button needs to reduce. After listening to the feedback, I come out with a better version of the page and a customer page. In the process of combining the task, we used git to merge the page with my colleague’s task. However, she mistakenly replaced my work with her work. I need to revert the file to the older version of the file. Now I finally knew the importance of updating the files using Git. When presenting the customer page to Mr. Peter, he mentioned that the customer page was fine to him, but still needed to reduce the “clicking” process. He told me that the user will never click on the edit button to edit the customer details, but will click on the places that need to edit. He also mentioned that the edit function will be similar to an Excel file, the user can straight away click and edit the files.

In conclusion, I used Axure RP 10 to draw the prototype of the page and customer page. Even though the prototype I created is not perfect in the sense of the design, but still acceptable. He told me that the prototype would end next week and we would proceed with coding it out.