Author: nurlailiyuzi

Last week, my focus was on constructing the UI page for the cleanup process. I adhered to the previous design with minimal changes, removing unnecessary elements and incorporating new ones like checkboxes and buttons. Simultaneously, while working on the UI pages, I started developing the view model. During this process, I realized the necessity for a new API query to facilitate the cleanup procedure. Upon receiving confirmation from Mr. Peter, I proceeded to construct the API query.

During the query development, I encountered a confusion in combining lists from two different entities. After pondering for a while, I figured that the solution was surprisingly straightforward. Utilizing AutoMapper to map the data into a single DTO, the next task was simply to add it to a list separately using the AddRange method. The query also took future pagination into account. However, if the page size was set to lower than 0, the query would disregard the pagination option. After establishing the logic and handler, I thoroughly tested the query until it functioned flawlessly.

Following this, I continued developing the view model, ensuring that UI functionalities like the search bar, buttons, and checkboxes worked seamlessly. In the initial stages of UI development, I created an event parameter, considering its potential use later. However, as I realized that the UI primarily required one mode, I removed the parameter and only used the event for the loading bar dialog, triggered when retrieving data. Towards the end of the week, I successfully completed the UI. Nevertheless, further testing is needed to ensure both the UI and backend code are error-free and functioning perfectly for the cleanup process.

In this week’s blog post, I continued the progress from last week’s clean-up initiative. My focus was on refining the logic used to manage data. The latest logic I developed was crucial for handling different data. It involved creating one and two API queries respectively, designed outside the context but essential for its functionality. These developments were not only pertinent for the present but also aimed at easing future processes.

Achieving the accurate data of certain context posed a challenge as it required data beyond the one database. Fortunately, Mr. Peter patiently guided me on the approach to obtain this information.

Diving into the code, I initially drafted the solution and managed to complete it within a day. However, during code cleanup, I realized I had mixed up service and calling entities in a repository, a mistake that highlighted the importance of writing clean and efficient code. Learning from this, I refactored the entire codebase, ensuring that the code was organized properly, with context and inventory used only in their intended places.

Moving forward, I tackled the next API query with meticulous care, being mindful of my code structure. Towards the end of the week, I presented my progress, Mr. Peter then provided valuable insights, and demonstrated the need for specific validators in the API queries. His guidance ensured that I wrote the validators correctly, enabling efficient utilization without the need for additional checks or data validation in subsequent parts of the code.

While I made significant strides, there was still a need for a minor refactor in the clean-up service before I could proceed to work on the clean-up view page, a task that will be continued in the upcoming week.

Continuing my task from the previous week, based on the latest explanations by Mr Peter, I reviewed and analyzed my code and its underlying logic. Subsequently, I made necessary corrections. Once I outlined my corrected logic, I concentrated on conducting comprehensive unit tests for the clean up functionality within the context. This task was a vital part of ensuring the reliability and accuracy of the system.

To facilitate this process, a dedicated testing environment was established using a factory class, ensuring controlled and isolated test scenarios. Then I also included initialization of diverse sample data, including all the entities and a few more which were meticulously handled. These data initialization was necessary to cover a wide array of potential use cases and scenarios. Subsequently, I meticulously implemented unit tests to validate the clean-up operations for all entities. 

These tests were designed to target specific barcodes, reflecting real-world scenarios where clean-up is essential. Next, I employed FluentAssertions to assert the correctness of HTTP status codes and response data. Notably, I verified intricate changes in all quantities that are important for this clean up process. 

Approaching the end of the week, I developed a new API query to retrieve ordered quantities. The intention behind this was to enable users to obtain ordered quantities effortlessly, without the need for manual counting or redundant logic. This approach ensures convenience for future use. Following the CQRS pattern, I created the necessary properties, handler, and validator to implement the API function. Mr. Peter emphasized the critical role of the validator, emphasizing its importance in validating input data for queries. It ensures that either data is provided and is a non-empty, positive integer when the other corresponding property is not provided. This validation logic guarantees the integrity of the data used in the query, maintaining consistency and validity by enforcing the requirement for a valid identifier while allowing flexibility when data is present. This upcoming week, there’s still few of the clean up service logic must re-analyzed and to be updated as this new API query will be implemented in the clean up logic.

Last week, I had the opportunity to develop a new feature. It was specifically designed for cleaning up items data as their data count is erroneous due to the experiment and error logic across the application. Addressing these issues was crucial for resolving bugs in future fixes. The new feature I worked on aimed to rectify these data discrepancies. When a user clicks a designated button, the feature automatically cleans up the data.

I began by outlining the necessary tasks in Trello and understanding the database’s data flow where the data originated, where it was headed, and which parts needed cleaning. I brainstormed and devised a theoretical framework for the cleanup process.

To kickstart the project, I created a new cleanup folder within the project feature directory and defined essential CQRS components in the command and commandHandler. I meticulously determined the placement of a new service and registered it accordingly. With the fundamental groundwork in place, I concentrated on the logic required to retrieve and recalculate the data before updating them. During this brainstorming phase, I also developed the basic page layout, aligning it with the structure of the main list page. My initial draft of the logic for the clean up service consisted of a list of items that users wanted to clean up, each item paired with its corresponding data.

At this point, Mr. Peter noticed my confusion and patiently explained the key aspects I needed to understand. He emphasized the importance of using a list of Barcodes from the UI. From these Barcodes, I had to calculate the correct data and compare them. If disparities were found, the newly calculated data should overwrite the inaccurate data. Unfortunately, my progress was cut short at the end of the week, and will continue working on this task in this coming week.

Over the past few weeks, I dedicated my time to identifying and resolving bugs and errors in the recently developed feature. Mr. Peter provided me with a list of critical bugs that surfaced during production, requiring immediate attention to ensure the application runs smoothly and error-free for users.

Some of these bugs were unforeseeable, but others resulted from my oversight. This experience taught me the importance of meticulous attention to detail and comprehensive testing across various scenarios. Most of the issues originated from the Module, such as a problem where the comboBox of an entity in a view page failed to display any address information. I resolved this issue by including the address in the Context and mapping it to the UI.

Furthermore, enhancements were implemented to improve the user experience. One concern involved the lack of a clear indicator for obsolete data on the entity view page’s user interface. It was crucial for users to distinguish between outdated and current information. To resolve this issue, I introduced a new column in the view list. Additionally, I modified the entity’s comboBox by setting the Obsolete status to false, guaranteeing that only the most recent entities were displayed. Later, Mr. Peter noticed that I had employed GetAwaiter().GetResult in a section of my code, causing asynchronous operations to be blocked and their results fetched synchronously. This synchronous blocking of asynchronous code can significantly impair performance, especially in applications requiring swift responsiveness. Consequently, Mr. Peter suggested transitioning to using await asynchronous and incorporating Loading Bar dialog. This change ensured that users were kept informed about the loading process, eradicating the frustration of waiting for an unspecified action.

Throughout the process of resolving these bugs, I encountered a significant challenge related to parent-child relationships. Even after deleting data, the parent name persisted when navigating to the next set of data. Initially, I attempted to solve this issue by creating a new list, intending to refresh the data. However, this approach did not address the root cause of the bug. It was only after Mr. Peter explained the underlying issue that I realized my mistake. I had failed to fully grasp the nature of the bug and hastily attempted a solution without a complete understanding.

From this experience, I learned the importance of approaching problems with a deeper understanding before attempting solutions. Rushed attempts to fix issues without fully comprehending the underlying complexities can lead to ineffective solutions and wasted effort. It emphasized the significance of thorough analysis, seeking guidance when needed, and acknowledging the continuous learning process in software development.

Last week, as a continuation from the previous week, Mr. Peter demonstrated the process of generating certificates with expiration dates a few months from now. These certificates were meant to replace the old ones and could only be used in a designated location. Unfortunately, a portion of the code contained an error, possibly due to a minor oversight. In the initial hours, I made efforts to identify and resolve the bugs. Regrettably, I’m uncertain about the source of the problem and how to rectify it, leading me to revert back to the previous certificate system and moving on to the next task.

Transitioning to the next task, I was tasked with identifying any issues in a new feature introduced by Mr. Peter. After multiple tests, so far, there are no errors in this feature. Consequently, I proceeded to the subsequent task, which involves cleaning up the data. While I was in the process of establishing the basic CQRS pattern on the application side and adding a button in the module side, I received another assignment to uncover bugs in another part of the application system. Prioritizing this task is crucial since it also aligns with the cleanup initiative.

Reflecting on last week’s progress, I also learnt something new: generating an SQL script from the latest migration. Initially, I believed I had to perform this task using SQL, but Mr. Peter guided me in the correct approach. To generate an SQL script from the latest migration, I first ensured that the EF Core CLI was installed in the migration folder. Next, I listed the migrations that had been created and inserted a command to generate the SQL script for the most recent migration.

Last week, I was assigned the task of identifying bugs in a new feature introduced by Mr. Peter. Initially, I began by familiarizing myself with the feature, exploring various functionalities, and observing how data submissions were handled. Later in the day, Mr. Peter provided me with a guided tour of the feature, which significantly improved my understanding of its intricacies. With a clearer picture in mind, I delved into the testing phase, aiming to uncover as many bugs as possible to ensure a smooth and error-free production process.

I documented the bugs I discovered on a Trello board in the form of a checklist. Most of the issues were related to the user interface (UI). Mr. Peter then suggested to mark the list of errors with the ones I intended to address. I selected a few and left aside the remaining errors that I wasn’t confident in resolving.

Around mid-week, Mr. Peter tasked me to replace a dependency I had been using with its source code. This step was crucial for debugging and resolving the identified bugs. It took me a while to replace it because I encountered a few problems after doing it and needed some time to figure them out. 

Subsequently, I began tackling the smaller bugs on the list. However, during one of my attempts to fix an issue, Mr. Peter supplied valuable guidance on a different approach, pointing out the root cause of the problem and to reconsider my approach, which turns out resulted in a simpler and more sensible solution.

Towards the end of the week, Mr. Peter demonstrated how to generate certificates that would expire in a few months, replacing the old ones and ensuring they were used in only one designated location. Unfortunately, a part of the code had an error, possibly stemming from a minor oversight. However, as the week came to a close, I had to postpone addressing this issue until the following week.

During the previous week, my primary focus was resolving a query related to the entity’s unfulfilled list, ensuring the accurate transmission of data. Initially, I crafted a comprehensive query that retrieves all data without any specific conditions. Once I confirmed the success of this initial test, I proceeded to construct a query with two main conditions. These conditions revolved around the status of the fulfillment date, if it was enabled, the query would retrieve a list of unfulfilled dates based on certain criteria, otherwise, it would generate the standard list. Following thorough testing to ensure the correctness of these implementations, I committed the changes before transitioning to my next task.

My subsequent task involved updating a migration in accordance with Mr. Peter’s instructions. Later on, I moved on to the next task, which entailed pulling changes from another branch for a new feature update. During the initial attempt to pull these changes, I encountered a conflict stemming from a test. After successfully resolving the conflict and merging the changes without issues, I proceeded to rebuild the application.

Continuing to follow the provided guide, I encountered errors, one of which was due to my oversight in not copying the necessary files from cloud before editing and using them. This experience taught me to always remember to update files into my own folders instead of directly using them from cloud. Various tasks, including migration, setting up DBs, configuring certificates, and establishing the access key, were primarily handled by Mr. Peter due to my limited competence in following instructions and addressing bugs throughout the process.

The week concluded with Mr. Peter introducing me to the new feature, with my upcoming responsibilities focused on bug identification and prompt reporting to Mr. Peter if any issues arise. Although last week was marked by significant debugging, stemming from my own limitations, I am determined to learn from these experiences and avoid repeating similar mistakes in the future.

Continuing from the previous week, while wrapping up the implementation of a new feature, I encountered an issue stemming from an outdated wrapper that constrained my ability to configure it according to my requirements. To address this, I took the initiative to create a new wrapper tailored specifically for the feature. However, this decision necessitated adding mappings for the new wrapper. As I approached the final mapping for the feature, Mr. Peter noticed that I had been using the wrong service throughout the process. This led to me creating a read operation for the entity’s list using the CQRS pattern. To guide me, Mr. Peter provided a similarly-pattern example from another entity.

I started by making a specific folder for the entity’s Get List Query, initialising the properties query, and creating the List Dto. The Get List Query Handler class that I created later implemented the IRequestHandler interface and took control of handling the request to obtain a list of entities. It used a particular service interface and the IMapper. I followed the example given within the Handle function, but I soon realised that a new service was needed to obtain the entity list because the current service was unable to satisfy the conditions required. Additionally, I also added a new controller responsible for handling GET requests to retrieve a list of entities based on query and also provide Swagger documentation for the API.

My next step involved creating a new service exclusively for retrieving the entity’s list. Initially, I designed a straightforward query to retrieve the list without any specific conditions. Nevertheless, I made sure the methods were implemented asynchronously.  By implementing these methods in an asynchronous manner, I ensure that the retrieval operations can be performed efficiently and non-blocking. This enables better scalability and responsiveness in the application, especially when dealing with a large number of entities or concurrent requests. To validate the correctness of my implementation, I incorporated unit tests that verified successful scenarios for Read List methods. These tests employed a client to emulate HTTP requests and validate the returned status codes and data.

With the foundational work on the backend completed, I shifted my focus to the UI to confirm that data was being transmitted correctly as intended. After some debugging, I successfully verified its functionality and the data was passing. However, the week concluded, and in the upcoming week, my priority is to ensure that the query for retrieving the list functions flawlessly before I can proceed to the next task.

Last week presented an exciting challenge as I embarked on adding a new feature to an existing entity. The task involved creating a dialog that would display a filtered list of orders based on their fulfillment date, allowing users to conveniently cancel orders that had passed their fulfillment date. To kickstart the project, I organized my plan on Trello, ensuring a clear roadmap for the upcoming tasks.

I began by establishing a new view page, harmonizing its design with the entity’s main page to maintain consistency in user interface. With the interface in place, I moved on to the view model, where I initialized the necessary properties for data binding. Ensuring that the properties were successfully linked with the view, I focused on populating the DataGrid with the list of entities. As I delved into modifying the query to fit the desired conditions, a realization struck: the current service I was using at the time didn’t provide the fulfillment date to match the needed requirements.

Seeking guidance, I consulted Mr. Peter, who advised me to tweak the existing service rather than creating a new one. Following his advice, I made the necessary adjustments to the service to accommodate the desired functionality. With the list loading seamlessly, I directed my attention to enhancing the user experience by enabling the selection and deselection of all orders through checkboxes.

Although I successfully bound the checkboxes and established their interaction mechanism, a stumbling block emerged. The binding required the usage of DataContext and ancestor properties, a revelation kindly pointed out by Mr. Peter. His guidance clarified this issue and explained the mechanics behind it.

Moving ahead, I tackled the cancel order functionality, laying out the logic and implementing the function to update cancellation quantities. At this juncture, Mr. Peter recommended incorporating a progress bar dialog due to the potentially extensive list of orders to cancel. Implementing this not only improved the user experience but also added a practical element to the feature.

My only issue remained the inability to refresh the list after successfully cancelling an order, with all other components functioning without a hitch. I turned to Mr. Peter for advice, which he advised using ‘Dispatch.Invoke’. Although I initially found myself puzzled and embarked on reading about threads and dispatch, I still lacked a clear understanding of their usage. To my pleasant surprise, Mr. Peter demonstrated the process, and it turned out to be a concise solution of just three lines of code. As a result, the pages now function perfectly. The first objective for this week is to make a few changes to the page before moving on to the task.