Category: Experiential

4.3.2024 – In my previous blog update, I’ve been focused on refining the charts report. While the chart portion is nearly complete, there are still some adjustments needed for the timeline feature. This feature allows users to choose between yearly, monthly, and daily views via a convenient dropdown menu. The UI’s idea was achieved after discussing with Mr Peter on what would be more practical for the users. Previously, I only made both UI and the API to only read and return yearly and monthly.

In the yearly view, users can see charts displaying total data for each year. Monthly view shows data specific to the selected year, while the daily view breaks down record on a day-to-day basis for the chosen month. I made the timeline dropdown refreshes automatically upon clicking a button. 

Additionally, I aimed to enhance chart responsiveness by enabling zoom and panning functionality. Thankfully, implementing this feature was straightforward, thanks to LiveCharts’ comprehensive documentation. While most aspects fell into place smoothly, there were some areas that required trial and error to achieve the desired outcomes. For instance, configuring one chart to display data upon hovering and omitting the y-axis label took some experimentation with existing properties.

Towards the end of the week, a few touch-ups were still needed, but I committed to the code first and will continue to improve both the UI and the code.

Last week, Mr. Peter oversaw my progress on the report, especially on the developed graphs. Following this, Mr. Peter provided clear instructions regarding the desired format of the report and the specific types of graphs to include. These directives were concise and entirely feasible. Basically, there were three main things I had to do. First off, I had to merge the three APIs I’d made for yearly, monthly, and the last three months into a single API. Upon seeking guidance from Mr. Peter, he recommended utilizing enums to accomplish this task. On the second task, I was required to refine and enhance one of the existing graphs to improve readability. Finally, I needed to stick one of the new graphs into an existing page that already had similar data.

For the first task, I had to do a bit of trial and error to figure out the best way to call and get data from the API. I also spent some time renaming the API to make its purpose and function easier to grasp. Once that was sorted, I moved on to the second task, which involved using the new API to plot a graph. Mr. Peter had already given me an idea of what the UI should look like, so I just had to make it happen. The UI had two sections, each showing different types of data. I realized I needed another API for the second section, but it didn’t take long to make it since the format was pretty similar to what I’d already done.

Lastly, I tackled the final task, which included adding some extra features like a background datagrid and a search bar to the UI. This way, the apps wouldn’t have to keep going back and forth to get data from the API, it could be done right from the UI.

It was almost the end of the week, I managed to get most of the tasks done, although there were still a few loose ends. I showed Mr. Peter what I’d done, and he pointed out a few areas where we could make the UI even better. Which I’ll be working on this week.

19.2.2024 – Last week flew by with the celebrations of the Chinese New Year Holiday. I am thankful for the chance to rest and enjoy the festivities. As soon as I returned from the holiday, I immediately worked on drafting an API essential for graph display based on user selections: monthly, yearly, or the last 3 months. Initially, I focused on the monthly aspect, ensuring the API could retrieve data for each of the 12 months based on the user’s chosen year. After completing the API, I conducted a simple test to confirm its functionality before integrating it into the user interface.

Subsequently, I tackled the yearly functionality. This entailed the API receiving an integer representing the selected year and the number of years the user wants to view, returning a dataset spanning the specified years. However, nearing the end of the week, I realized the approach might not be the most practical. I believe there’s a more efficient way to consolidate the monthly, yearly, and last 3 months functionalities into a single API call. I intend to brainstorm for a better solution and seek guidance from Mr. Peter for further insights.

Last week, Mr Peter explained a new feature that will be developed that will enhance the data integrity of the data. It was created from the essence of the previous report feature but with more new data calculations included in details. The upcoming feature was definitely a complex one but Mr Peter easily explained it to me and made me understand it very easily. The upcoming feature involved and required a thorough logic, encompassing everything from data input to output in all directions. However, due to its complexity, Mr. Peter advised me to prioritize the current report task for now.

So, I got back to working on the current task, which involved plotting a chart to visualize a dataset over a specific time range. The idea was to provide users with a broad overview or a big picture of their data. For this task, I’m calling data using the API that I’ve created previous week. My initial goal was to create a simple graph to gauge my next steps effectively. However, after producing several graphs, I realized I wasn’t quite confident in their relevance. I started questioning whether the graphs I was making were even suitable. What puzzled me the most was determining the appropriate timeline to retrieve and display the data, considering certain data types correlate with specific timelines.

After deliberation, I sought Mr. Peter’s guidance, specifically regarding the timeline, graph type, and pertinent data for display. Mr. Peter provided a sample timeline for reference and elucidated the preferred graph type for data analysis purposes. Approaching the week’s end, I developed a comparative bar graph representing two datasets. Users can adjust the timeline and specify a time range, facilitating sorting between the two datasets within the bar graph.

Last week, I was assigned the task of identifying bugs in the previously developed report module of the application. The initial issue I encountered was with the generation of a substantial amount of data. Despite clicking the “update” button, the data for the entities was not being refreshed in the table. Upon debugging, I discovered that the collection of entities was utilizing an outdated list, prompting a simple solution – adding a function call to retrieve the latest entity list whenever the “update” button was clicked.

The second bug was associated with Cassandra, where a persistent bug message, “committed or rolled back,” appeared when alternating between the “generate” and “undo” buttons. Following Mr. Peter’s advice resolved this by removing the Cassandra functionality in the data-saving process.

Subsequently, I implemented additional features, including buttons for undoing all margins and exporting to CSV. Additionally, I introduced an API query for another entity to gather detailed data for a report, focusing on specific aspects. Throughout this process, I created a corresponding view and view model complete with a simple table and a date search bar. This setup is designed to streamline reporting tasks.T he simple table serves as the initial step before delving into the creation of the subsequent graph.

Towards the week’s end, Mr. Peter identified a gap in the feature related to how certain details were displayed. This highlighted the critical importance of attention to detail in the report, as overlooking such nuances could compromise data integrity.

Last week, I addressed a 404 error, signifying that the server couldn’t locate a client-requested webpage. Resolving it involved correctly registering the connection API in both context and module. Subsequently, a 401 Unauthorized response status code emerged, indicating a lack of valid authentication credentials for the requested resource. Mr. Peter guided me in handling this by adding necessary credentials to the identity server.

Ensuring all settings were in place, I tested data retrieval functionality. With successful data retrieval, I verified the proper functionality of the date and confirmed that the request correctly reached the backend API. Two main buttons were set up—one for searching data and the other for saving data into a CSV file. However, I temporarily halted work on the second button until all functionalities were working seamlessly. After confirming the search button’s ability to retrieve and map data to the datagrid, I proceeded to implement the export button functionality.

With everything running smoothly, the next step was testing. In the backend logic, particularly in the handler, I performed a calculation involving summing up values. My task was to ensure the correctness of the calculated data. Testing also involved confirming that the data being called matched the expected data. To enhance the testing experience, I generated a minimum of 100 data points for more insights and a robust testing foundation.

Moving into this week, additional testing is required to guarantee the module runs without errors.

Last week, as I was in the process of developing a specific feature that centered around a data report emphasizing quantity, in the mid of it I received an urgent task task that required immediate attention and prioritization over other ongoing tasks. Without delay, I delved into creating the necessary queries for the report data using the CQRS approach. After confirming the proper configuration of everything, I proceeded to verify the functionality of Swagger and then proceeded to conduct the xUnit test. Regrettably, the test consistently failed, possibly attributable to some overlooked configurations or initialization steps that I may have missed.

Without lingering too much on the error, I immediately started drafting a straightforward UI design for the feature, including views and view models. The views were designed with buttons and tables, featuring one button for generating a report and another for exporting the report to a CSV file. While uncertain about the export functionality, I decided to revisit it after ensuring the stability of all the fundamental features. The next day, with Mr. Peter’s assistance, the API test was successfully rectified, and the xUnit test began passing.

Despite still harboring some reservations about the backend logic, my primary focus was on ensuring the basic functionalities and data flow operated smoothly. However, upon attempting to retrieve data from the API, I encountered a 404 error, indicating that the server couldn’t locate the requested resource. Addressing this issue will be my foremost priority for the current week.

This is the last week of the internship at Tong Hin company. Before I discuss the tasks I completed, I want to express my deep appreciation to the company for accepting me as a temporary employee. It has been a truly enjoyable experience spending 13 weeks in this company. Now, let me detail the tasks I completed this week.

First of all, I added a function that can display the serial number and allows for adding multiple serial numbers. After a discussion with Mr. Peter, I made some changes to the add serial number functionality. I limited the process to only accept a new serial number that is different from the barcode. If the user adds a redundant serial number to the list, an error will be prompted, and the payment button is disabled.

Next, I implemented the hotkey function in the order page. Hotkey functions are really useful to minimize the usage of the mouse. I used “enter” and “control” as hotkeys to control the input focus point. When I press “enter,” the input will focus on the search item box, and pressing “control” will focus on the quantity box. Additionally, with the help of the pre-defined “tab” button, I can easily change the input focus to different boxes. The “tab” button will make the input focus on the next input area, further minimizing the usage of the mouse.

Additionally, I added an invoice list page to the system. However, the invoice list page does not have the correct API connected as it has not been created yet. Even though the API is not created, I still have a draft idea about what data should be displayed on the invoice list page. After completing the invoice list page and presenting it to the supervisor, he was satisfied with what I have done. Finally, Mr. Peter taught me how to test the API using React testing elements. Since I had no idea how to test the API, he patiently taught me the steps needed to test the function and API. Now, I am more familiar with React testing and should be able to test APIs in my future projects.

In conclusion, I implemented the hotkey function, added, modified, and deleted serial number functions, created the invoice list page, and learned React testing. Once again, I want to express my gratitude to the company for accepting me as a member of this team. I hope that the company will have a bright future and an even better software team.

Last week, following a successful demonstration of LiveChart’s fundamental features, Mr. Peter granted me access to a new repository encompassing contexts and modules for the upcoming task centered around Report Data. Having dedicated previous weeks to research and testing, I began by pulling the repositories and setting up the new module and context. Initially, I focused on creating basic views and view models without implementing complex functionalities. Realizing the need to prioritize completing the context first, I shifted my attention to ensuring the required data could be successfully passed.

After receiving approval from Mr. Peter, I incorporated a new API within the context, with the goal of improving future maintainability. With the context groundwork in place, I then proceeded to implement the first feature for the report data task, employing the CQRS pattern approach. As the end of the week approaches, I need to continue my progress into the following week. My primary focus in the next week will involve creating tests for the featured data and ensuring the seamless transfer of information from the backend to the UI.

This week is the last week I intern in Tong Hin. Continuing modified the category panel, I install the “Chip” react native paper from “mui-material”. These chips are compact elements that can represent inputs, attributes or actions. They can have an icon or avatar on the left and a close button icon on the right. They are typically used to present multiple options, represent attributes active or chosen, present filter options and trigger actions related to primary content. I used the chip function for trigger the options of the category. When a category is selected, there have a close button on the right which can remove the selected category.

On the other hand, I modified some small changes in the item detail panel. First of all, I call the ItemDto from the API to obtain the data for other table. Next, I replace the price with UoM in the UoM table which is the checkbox will be checked which UoM for that item. Thirdly, I move the Barcode to the position that easily seen by user. Lastly, I switch the navigation tab between the Stock and the Record. That’s means, I will display the Stock content for the user first then it will show the sales record when click to the tab. For the other detail panel, I make the date time more readable which separate the date and time with a comma.

In addition, I also modified the pagination for this item page. For the input of the page, I modified the input to be changeable by number. When it is invalid input the page is set to current page. For the previous, I set the previous button to disable when the page is 1. For the next button, I set to disable when the page is equal to total page. I also display the total items beside the pagination which is count the items from the API. For calculating the total pages, I use Math.max to set the minimum pages is 1 not 0 and use Math.ceil to calculate total page equals to total items divided by page size. Then, I make this pagination as a component to implement for Item page, sequence generator page and store page.

When Mr Peter checking my code, he found that I repeat creating the same layout for each page. So, he told me to DRY the layout and he also ask other colleagues to ping my computer to help me testing the page. When I doing the layout, the console there showing a warning said that validateDOMNesting(…): <div> cannot appear as a child of <html>. To solve this issue, I add <meta> and <title> at <head> at the Root Layout there, and for the <body> of the layout which is the part React app will be mounted.

During last day of this week, I did the validation for the sequence and store pages. For the store page, I validate the error when the required input field is blank. For the sequence page, I validate the same thing as store page, and add the checking for the sequence pattern to check the user is input the correct pattern which is start from alphabet then is number with 3 to 6 digits. Finally, I push all my task to server by using git.