Category: Experiential

In this week, I managed to complete the create command of the stock take API. Moving on to the next part, I managed to finish the update and delete command together with the queries as well. In the delete command, the command will take the stock take id as an input. A unit test was done to ensure that the delete command was working properly.

After that, the queries for the stock take was either query to get the list of stock take or get the stock take by the id. Similarly, unit test was also made for the queries as well. In the get stock take list query, the stock take will have an item count to show to the user how many there are in the stock take. While, get stock take by id will have the list of item display with it.

Lastly, the logic of the update command was rework again after discussing with Mr.Peter. The rework was to ensure that every time the stock take item is updated that it wouldn’t crash the software. Currently, I’m still working on the reworking the logic of the update command, After that is done, I only have the accept command left for the stock take.

This week, I have mostly concentrated on fixing last week’s issues and cleaning out redundant and unnecessary lines of code. The keyboard toggle, specifically the focusing function, was mostly affected by a bug last week. Consequently, it was my responsibility to ensure that focus functions properly and smoothly as required.

First, the focus functions was separated for each text box and connected with its reference, and the usage of them were very unorder and not following certain sequence. Moreover, the submit functions holds unwanted codes that may just make conflicts and make it harder to understand and maintenance. Therefore, creating the reusable keyboard toggle component solved the issue but unfortunately the focusing function still not addressed.

Subsequently, in an effort to resolve the issue, I attempted many times to alter the logic, but to no effect. Mr. Peter provided me with an additional solution to this issue by combining the textbox and keyboard toggle into a single component. Fortunately, after several testing and tweaks, everything ultimately worked as planned.

In the end, this week was helpful for me in a different way because I was able to make a new component and combine two existing components into a reusable one. Making the set ups and configuring the props gave me more understandability,  which will allow me to make faster decisions while dealing with the code.

After finishing the stock feature of the sandbox application, I was assigned to create the stock take feature next. Inside the stock take feature will have the create, update, delete and accepted commands together with the get stock take list and get stock take by id queries. The first thing that I need to work on was the create the entity relationship diagram (ERD).

After finalizing the ERD, I moved on to creating the API of the stock take. The part that I am currently working on is the create stock take command. After figuring out what the user need to input for the create command, I moved on to the create command handler. After completing the command handler, I moved on to the validation and the response of the command.

Next, I created the unit testing for the create command and tested out the POST method of the create command. After running the test, the test resulted in a bad gateway result. Then I went to debug the code itself. After sometime, I found out that in the create command handler there was a null exception when I tried to map the child class of the stock take. Currently I am working on trying to resolve the bug.

At the beginning of this week, the main goals was to fix the bug that caused Views to render multiple times. And changing the style of the whole application by putting all of the styles into a single style file and using it on every page.

I followed the previous work to use the correct UseEffects and the render problem got addressed. I next went on to the pagination issue, where the list of items was inconsistent. And page pagination did not function at all. The bug was at the pagination function, so after I altered the function by using UseInterval solution, the problem is fixed. In addition, I started performing Async tests on the UseInterval function to have a better understanding.

After that I started to work on the styling because the application. The point of the style wasn’t the style itself, but rather to make it easier for me to make changes or style a component. The previous style was somewhat random, and each component was styled independently, which made the code more complicated. Therefore, the main purpose here was to clean the code and make the style easy to edit.

Next, I styled the main page and the primary background, in addition to all other components in the main pages. The result for me is great, now I can change any component style in only one place for all pages.

While Mr. Peter was testing the application before to this version’s upgrade, we discovered a bug again in the keyboard toggle. It took us some time to solve this problem, but after we did, Mr. Peter showed me how to make it a reusable component for our app, which was wonderful and helpful.

To conclude, the keyboard toggle were functioning properly with no bugs. However, it was not as we expected it to be, so we postponed the upgrade until the following week, when I will fix the issue.

On the forth week of my internship, I was introduce to WPF. WPF is the main UI component of the sandbox application that I was working on. After going through an introduction of it together with prism. The main design pattern used when developing the WPF page was the MVVM model where the code that implement the business logic is separated from the UI code where it usually consist of the view and view model.

Afterward, I have to convert the existing feature of the stock threshold so that it uses the API end point that I have created previously. Firstly, I registered the container which will connect to the API. The first page I was working on was the page which display the list of the stock threshold. In this page, the entire list of the existing stock threshold from the database will be display to the user. Not only that, I also added a feature to allow the user search for the desired stock threshold through the item name search bar.

Next, when I tried running the application and navigated to the stock threshold page, the code return a 404 not found response. I realized that the container was mapped to the wrong API end point which resulted in 404 not found response. After registering the proper API end point, the page was able to display the stock threshold list.

Lastly, the next page I was working was the page which is responsible for the create, update and delete of the stock threshold. At first, I was having some difficultly in understanding the code. After some guidance, I was able to figure out what needed to do. The mapping of the data was mainly done with the Auto Mapper.

Following what I did last week, I spent this week learning how to debug the code, using breakpoints more in the debugging. I tried to solve the fake-timers issue I had last week, by reading the react native docs. I dived more into testing asynchronous code, and learnt several ways to make the test effective. So I used async/await correctly to pass that.

The flatList component of react native was a major time-consuming task that I needed to test. Unfortunately, I spent a lot of time trying to solve the problem and I failed to resolve it. The error message given was always related to the testing configuration, which already set up and working successfully last week. Therefore, I considered changing the code and replacing the FlatList components with SectionList to avoid all of this, but it was not the perfect option.

Finally, in order to solve the aforementioned problem, I had to mock the FlatList at the end. it seemed quite impossible to test or to get an element form a FlatList unless it is mocked.

On the second week of my internship, I begin to dwell deeper into the concept like ASP.NET Core, RESTful API and TDD. In ASP.NET Core, I learned the best practices to use whenever I work with the framework. Not only that, in ASP.NET Core, I learned on how to create an API where API allow for communication between 2 different application that uses different programming language. Lastly is the mediator pattern and CQRS. The mediator pattern is how two object communicate between each other and this promote loose coupling between the 2 objects. CQRS is the separation between the command model and query model where the command model is usually the create, update and delete operation which can change the data but doesn’t return data to the user. Meanwhile, the query model is the read operation in which it doesn’t change the data and return a result to the user.

The RESTful API is the communication between to application when it’s based on the CRUD (Create, Read, Update and Delete) operation. In an API, the client will send a request to the server through the API using the HTTP method like GET, POST, PUT and DELETE request. Afterward, the API will then fetch the appropriate data and send it back to the client. The REST is the constraint applied when creating the API. The constraints are usually, client-server architecture, stateless, cache-able, uniform interface and layered system.

Lastly is the concept of Test Driven Development (TDD). In TDD, the development of a software usually start with the testing first. The cycle of TDD involve creating a failing test first then applying the logic of the code to make the test green. Finally the last part of the TDD cycle is to refactor the code to make sure the code is clean. The process is then repeated again for the other part of the code. TDD allow for easier to test to code and provide a fast feedback to know whether or not the logic is working properly.

The first week I spent at the company was mainly focusing on learning the technology that will be used in the subsequent week. First thing I learnt was how to use git. In git, I learned the command in git, how to create repository, committing to changes, merging repositories and push any changes made in the repositories.

Next, I also touch up on my C# fundamentals again in order to fully prepare myself to learn the new concepts as listed below. From the C# fundamental course, I revised on the syntax used in C#, how to work on the classes and objects, testing my code through unit testing, differentiating between reference types and value types and the object oriented programming in C# as well.

Lastly, I was introduced to the concept of asynchronous programming. Asynchronous programming allow for 2 operations, operation A and operation B, which doesn’t depend on each other to run asynchronously when compare to synchronous programming which has to wait for operation A to finish first then it will execute the operation B. Asynchronous programming mainly uses the keyword async, await and task. The other concepts that I have briefly gone through are ASP.NET Core, RESTful API and Test Driven Development(TDD).