Author: nurlailiyuzi

18.3.2024 – Last week, I focused on refining the progress of the previous week’s report. Ensuring code cleanliness and passing all tests became the priority. To start, I addressed the omission of temporary data that should have been included as input for the new report’s table. This was achieved by creating the required services. Subsequently, I proceeded to conduct tests for this implementation. However, a challenge arose when these tests only passed when executed separately. They failed when run collectively. Seeking guidance, I consulted Mr. Peter, who suggested two approaches: testing the services separately or using IFixture to run all tests together. Initially opting for the latter for test consolidation, I encountered an error when attempting to implement a file from the context API due to circular dependencies. Consequently, Mr. Peter recommended creating separate tests for each scenario to facilitate future debugging.

Additionally, there was a service test that persistently failed despite successful data validation, specifically in failing to change one particular boolean property to true. Upon investigation, I realized this was due to an oversight I made when using the AsNoTracking() function within the Get() function, which prevented any changes from being applied. As a result, the boolean property failed to reflect the intended modifications. At the week’s end, I completed a new migration for the latest updates across several databases and generated the migration SQL script.

Last week, I started to work on a new task that was one of the important parts in the report section. I needed to make a new database table that would record all the incoming and outgoing data, enhancing the integrity of the data. As it’s already previously being discussed and explained by Mr Peter, so I jumped right in and built the table. First, I sorted out how both incoming and outgoing data models would look and set up their configuration. Then, I tested their type configurations, which turned out to be a very straightforward test.

Next, I started working on the services to store data in the new table. Developing these services took some time due to various considerations. Afterward, I immediately focused on the integration service test. Initially, I followed an example from an existing test that used Func() to generate sample data. However, Mr. Peter pointed out that I was referring to an old test and gave me a new test reference that is much more simple and would run much faster than Func() which sped up the testing process. By creating this test, it helped me understand how to improve the services in order to store data into the new table even better.

By the end of the week, I still had a few more things to do that I had listed out my to-do list but shall continue my progress next week.

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.

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.