Month: February 2024

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.