Category: Experiential

I spent my second week working on the coding side of the Retail Business which was briefed to me last week.

I started off the week by setting up my workspace, SQL workspace and Source Tree. Moreover, I concentrated on learning how a test case is executed for an API, for example; how handlers work , repositories, entities, and also how to debug a test case. 

Next, I was given my first task to create an API with simple entities and test cases. I kicked off the API by creating entities with relevant fields and also their config file which helps mapping entities and their properties and relationships to a relational database. Once the fundamentals of the entities were created, I shifted my focus towards the commands and query aspect. Started it by defining repositories, updating the Database context file and adding dependency injection. 

Furthermore, I completed the Create and Delete commands with successful testing and made relevant commits. Moreover, I finished the Get query with test cases which was not until I had to fix some bugs in my Data Transfer Object (DTO) file. Lastly, I finalized data testing which tests the logic of your repository and started building logic for the Update command.

As for the final part of the command for stock take is to allow the user to be able to query the status/progress of the ongoing accept command. This is done through the use of concurrent dictionary. The dictionary will hold the value of the progress of the accept command and return it to the user.

Next, I need to create a background service for the concurrent dictionary so that the value can be display to user. To do this, I have to create monitor class to monitor the dictionary and check if the key for the dictionary exist which in this is a Guid. After that, the progress of the accept command can be display to the user. After creating the monitoring class, I have registered it as a singleton in the source code.

Currently I’m still trying to figure out on the logic of the monitor class which will check the dictionary every 5 seconds and report back. I’m also trying to figure out on how to return the value in the dictionary to the monitor class to be presented to the user.

This week was essentially a continuation of last week’s work, for which I needed to fix errors and improve the logic. Some critical bugs were reported that required immediate attention. Changing the Focus logic in the Decimal Text Input component and failing to write a correct test script for the Combo TextBox component. That what mostly happened during this week, and what I’m going to talk about in this blog.

First, I got complaints about some bugs after patching the last update. Such as, Undo operation, was not working after searching and selecting a customer. Another bug was that when processing order with multiple line items, the app didn’t navigate to the second item after processing the first one. Next, with Mr. Peter’s guidance, I found that most of the bugs occurred because of the warehouse identifier, which was hardcoded in many places in the code, so altering that fixed the problem.

After that, I worked on fixing the errors with multi-line items. On the other hand, this caused another issue that occurred whenever a single object was processed, as the rendering time was around 5 seconds. The bug was addressed by modifying the reset box code so that it would only operate with multiple items.

Modifying the focus logic in the DecimalTextInput component was also done this week, where I fixed the bug with the OnBlur property. And I created a unit test for the component to ensure that the input number will always round off based on the specified decimal places. On the other hand, I have been searching and trying different ways to run a correct test for the Combo TextBox component. Most of the ways I found were always getting me a pass result even if the test should be fail. I also came across several techniques for testing that mock the “focus” but unfortunately, those also didn’t work for me.

In conclusion, this week was consumed by fixing the issues raised following the last deployment. Fixing the decimal component focus and doing a test for it, but not conducting enough testing for the combo component, where this and other critical issues will be addressed next week.

I spent my first week at the company mostly concentrating on learning some softwares and understanding the fundamentals of the task I would be doing during this internship.

I started off the week by learning git immersion. Using Git I learned how to create repositories, commit changes, merge repositories, and push any changes made in the repositories using the git commands.

Next, I was briefed on the area I would be focusing on during the internship which is the API. After grasping the structure and the business rules provided to me I extracted out entities, fields and relations and came up with a Crow’s Foot Notation (CRD) of the business. Verification of payments was a challenge I faced while forming the CRD, as there are multiple means of payment with possibility of multiple transactions. However, after having some productive conversations with my supervisor I was able to finish it.

Lastly, I was introduced to the Stocks API code since I would be creating a API therefore going through the Stocks API would really help me understand the concepts and fundamentals of RESTful API and how to test it using Test Driven Development (TDD).

In this week, the final touch up of the accept command for stock take was done. First, the I added a query to get all the stock take that is still pending in accept so the user can easily look up the stock take that they want to accept. Next, A stress test of the accept command logic was done to ensure that the logic is capable to handle large amount of data and do the accept process rather quickly.

The stress test was done with 10000 items, 200 places, 200 places and 300 stock take line items. The entire process of the accept for the large quantity of item took roughly around 5 to 6 seconds. After that, I wrote another unit test which involve the stock take having different items from the existing item list. The test is to ensure the existing item on the following is replaced with the items in the stock take itself.

Lastly, I need to add a query for the accept command in which the user is able to look at the status of the ongoing accept command. Not only that, the user should also be able to cancel the ongoing accept process as well. Once all the touch ups are done, I will move to creating the UI for the stock take feature.

In this week, the accept command of the stock take was further improve on. Firstly, the command will get both the existing item list with the line item for the stock take. From there, the algorithm will compare both the existing item and the new line item. After that, it will update the quantity to the new quantity. The item with zero quantity will automatically be remove from the existing.

Next, I need to rework the function which will update the item list. First, I need to change the parameter that it takes to a list. From there, I need to rework the logic so that I can take the list as the input and update all items at once. Moving on from there, I need to ensure that the update function transaction only run once after being called.

Lastly, I need to change the logic for the updating the existing and matching item so that the last checked date and the last checked by property will match the one in the stock take itself. I then need to do the unit testing to ensure that everything is working fine and as intended. I also completed the testing for most of the logic of the accept command.

After patching the new updates to the system, I had new tasks for this week which were mostly focused on fixing the unnecessary re-rendering. Fixing minor bugs across the system and editing some style with the assistance of a real device as opposed to emulator. and encountering  new issues in the Decimal text box component.

I began debugging the code to fix the re-rendering bug by focusing on the Pick and Pack views, where it was primarily occurring. Initially, I attempted to create a render counter that counts each time a render occurred, which was really useful. It demonstrates that whenever the Data is requested from the API, it is rendered twice. Thanks to Mr. Peter’s explanation, I see now that it was due to an unnecessary application of useState; replacing it with useRef resolved the issue.

Afterwards, I fixed a few issues that were occurring in unpack view. I added the implementation of the error message for scanning the incorrect item and made sure it doesn’t interfere with the existing functionality. In addition, the Focus implementation in other views was not functioning while mounting, and also I managed to get that fixed.

As usual, no work week can pass without some Focus implementation challenges being encountered. After extensive experience with all sorts of errors encountered while implementing the focus in various ways. Nonetheless, I ran into another logic issue with the focus implementation, this time in the Decimal Text Box component.

To wind things up, I was successful this week in fixing a few minor problems, as well as one significant one, such as the render bug. Next, fix the focus bug in the Decimal component before beginning the testing tasks for the upcoming week.

This week’s efforts have been concentrated on perfecting the focus feature and putting it into action. I was introduced to a new type of react native hooks, and the old logic was discarded in favor of the new. By the end of the week, the update had been successfully patched, and the overall result was encouraging.

Fixing last week’s bugs and running through all of the scripts to make sure the focus moves from one box to another as intended, was where I started this week. In addition, after consulting with Mr. Peter and digging into the code, we realize that using Boolean to implement the focus is problematic and leaves behind obvious problems. To that end, he advised that I study the useReducer hook and try to execute the focus with it.

Following that, I gained an understanding of the useReducer concept, structure and implementation, which is typically utilized for complex state logic. However, I met some difficulties to apply the focus implementation in the reducer because we are using a separate component so that was more complex than I expected.

Next, Mr. Peter devised the optimal solution by implementing the focus in a function using ref and invoking it. Compared to the previous usage of a timer that was unpredictable or a boolean that was producing bugs, calling one function by passing the box ref only was far more efficient.

Lastly, after implementing the new solution on every screen, I had to modify the keyboard toggle logic to operate well with the text box focus. I also altered the styles a bit to make the content fit more with the device. And with my supervisor’s confirmation on the current version so I eventually patched the update successfully with all improvements and bugs addressed.

After finishing up the logic of the update command and doing the unit testing as well, I moved on to the accept command. The accept command involve a few logic where the accept command will take the list of item in stock take and compare it to the existing item location and update the stock quantity. To ensure that the process of updating the stock quantity of the item location is not executed properly, the entire logic is put inside of transaction so that any error that occurred will roll back any changes made.

Next, in order to compare the item in stock take and existing item location, an algorithm was needed. After doing some research online, I found LINQ to be somewhat suitable for the job. Then, I tried to implement the LINQ and tested it out and it worked. During the testing of the accept command, I encounter an error where another transaction was being created while the first transaction was still going on. After discussing with Mr. Peter, I was able to fix the error.

Lastly, after some discussion with Mr. Peter regarding the logic of the accept command, I needed change it so that the update process can be done much more faster. I also needed to stress test the LINQ algorithm to see how long it will take for the algorithm process a large amount of data.

In order to effectively upgrade the application version this week, it was necessary to resolve all bugs associated with the new text box component. New difficulties prevented me from completing the task, and the outcome did not meet expectations.

First, I encountered a new problem in an old component that is mostly used for selecting the quantity option. The defect is that the quantity value accepts only the auto value. In addition, I spent time resolving the error in which I replaced OnChangeText with SetQuantity. The idea sounded successful at first, until I realised that it could not be tested. Therefore, I had to look for a different approach that could be tested.

After that, it was necessary for me to configure the newly added reusable component on each screen that makes use of it. This is where I ran into issues; the focus has been adjusted and is  totally dependent on the timer. But in the code, it was completely sloppy causing distractions. Furthermore, I needed to refactor all the related code from the beginning to find the desirable outcome. So, the current usage of It is depending on user interactions with the system.

This week, I ensured that every screen is compatible with the new component. However, this does not indicate that everything is perfect, as there is always a failure when a negative event occurs. I tried my best to make it function before the end of the week, but I was unsuccessful. Therefore, my main task is to update the incorrect scenario script and ensure that all displays follow the same coding sequence.