Month: August 2023

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.

The past week was occupied by debugging and troubleshooting sessions to ensure the seamless functionality of the sandbox application for the upcoming task. I continued to test the data entry pages for each entity to ensure that they could be saved and edited successfully, building on the work I had done the week before, which involved developing three unique seed generators for various entities. 

However, I encountered an issue with editing one of the entities, which prompted me to dive into another round of debugging in order to identify and resolve the error. Despite spending a considerable amount of time on this, the source of the error remained unresolved Fortunately, later in the day, Mr. Peter aided me. He assessed the error and stated that it may be related to the function I was using. He pointed me in the direction of a different function, one more suited to the seed generator of this specific entity.

The following morning brought a pleasant surprise, as everything operated smoothly without any errors cropping up. In an effort to introduce diversity and practicality to the generated data rather than producing the same type repeatedly I incorporated the use of the Random() function. This allowed the application to select data at random from the available options whenever new seed data was being created.

With the application’s functionality well in hand, Mr. Peter assigned me a fresh task: implementing additional features within an entity’s list page. Specifically, the task involved on unfulfilled orders that had surpassed their fulfillment dates, and granting them the ability to cancel these orders. After the briefing, I comprehended the feature’s concept and proceeded to outline the necessary steps to plan out the execution of the task in the upcoming week.

Following the successful generation of batch commits as previously discussed, I delved into the primary reason for the creation of the seed generator over the last week. This objective was to facilitate testing of the pages and an entity combo box, employed within a dropdown button. The goal was to monitor the response and ensure the correct appearance of the dropdown button, as well as accurate data display. In line with Mr Peter’s predictions, the button that should have displayed a comprehensive list of entities was not displayed as expected.

To address this, I initiated a debugging phase. My digging eventually led me to the conclusion that the problem could be solved by adjusting the query’s page size limit when invoking the list of entities. Due to my lack of knowledge about setting up an unlimited page size, I initially manually set the page size to display 100,000 entries. Mr. Peter, thankfully, provided guidance, recommending the use of “-1” to indicate an unlimited page size. After getting familiar with this method, the entity successfully transmitted its whole list without issue.

Following that, I discovered another entity within the seed data generator that did not yet have 5000 records. It also revealed a new error that only appeared when attempting to generate over 100 records on the fly, halting at 100. My first thought was that there was an issue with the entity mapping because I wasn’t able to edit any existing data for this entity. After I successfully solved the mapping issue, I attempted to create 5000 data entries once more. Regrettably, this endeavor failed once more, with an error message referencing time parsing.  The issue was ultimately resolved after I adjusted the date format inside a method that processes a list of objects in batches, that was generating and accumulating SQL INSERT statements to save the object data into a database using batch operations. 

My next attempt was met with yet another setback, this time with an error message indicating a ‘batch too large’ problem. Looking for solutions from other developers who faced similar issues from stack overflow, I discovered that inserting multiple inserts (> 10) into a batch for can have a negative impact on performance. As a result, increasing the batch limit was not an option. After some experimentation, I discovered that only by setting the batch maximum to 15 was I able to generate data that exceeded the 100-entry threshold.

Continuing from last week’s progress, I needed to add two more seed generators, each representing different entities. This time, the process was more straightforward as I didn’t have to register for additional classes. All I had to do was initialize the required data and create buttons for each entity. Once the setup was done, I eagerly tested the new additions to see if everything was functioning correctly. After a few debugging sessions, I confirmed that both new seed generators were working as intended.

I decided to test the app with 1,000 entities first. The test took an average of 2 minutes to complete, which was reasonable and within an acceptable range. However, a larger workload was actually the goal which is to generate 10,000 for this one entity and 5,000 for another 2 entities.

Feeling ambitious, I decided to raise the stakes and test the app with 5,000 entities this time. To my dismay, the process took significantly longer, stretching beyond 10 minutes. During this time, the entire application froze, and it was evident that the main thread was being used to create all 5,000 data, causing the freezing issue.

Thankfully, Mr. Peter taught me how to create the entities in batches, implementing BackgroundWorker to handle the process more efficiently. This way, the application wouldn’t freeze, and users could continue interacting with it while the data was being generated in the background. By implementing BackgroundWorker, the app was now capable of handling large data generation tasks while keeping the user interface responsive. The experience was smooth, even with 5,000 entities being generated. The background process took some time, but the users could still interact with the app, explore other functionalities, and initiate new data generation tasks without any hindrance.

Furthermore, I enhanced the text box input interface responsible for specifying the desired number of data to be generated. This improvement ensured that non-numeric input was restricted from being displayed on the screen. By following Mr. Peter’s recommendation, I took cues from another entity’s UI to achieve an overall design improvement. In conclusion, the addition of two more seed generators increased the application’s diversity and complexity. Thanks to Mr. Peter’s guidance and the successful integration of BackgroundWorker, the app’s performance and user experience were significantly boosted.

Last week was a wonderful learning experience for me as I dived into the subject of seed data thanks to Mr. Peter’s introduction. Seed data plays a crucial role in providing initial data to an application, which helps developers to interact with the system and understand the user experience before actual user data is available.

Mr. Peter patiently guided me through the process of creating seed data, starting with a practical example. To generate the seed data, we employed a function along with ‘for’ loops. This combination allowed us to efficiently produce a specific amount of data for a particular entity. One fascinating aspect was the utilization of GUIDs (Globally Unique Identifiers) to generate unique data. We organized this seed data generation process within a dedicated view model, specially designed for creating seed data.

With the essential data initialized, I proceeded to create the corresponding view. Keeping it simple yet effective, I added a button for each entity that I intended to populate with seed data. This approach allowed me to generate the desired amount of data for each entity with just a click of a button.

Prior to testing the application, I made sure to register the navigation, ensuring that users could seamlessly navigate through the application once the seed data was in place. However, an unexpected hurdle surfaced when I mistakenly clicked on “clean solution” while trying to build the application. This action inadvertently wiped out some of the previously set up configurations, resulting in a debugging session. Fortunately, the difficulties were fixed and the appropriate settings were restored with thanks to the help of Mr Peter.

Despite the hiccup, I was determined to further explore the benefits of seed data and decided to create seed data for another entity. This provided me with additional hands-on experience, and I gained a deeper understanding of how seed data can streamline the testing and development process, making it an indispensable tool in the application development journey.