Entity Creation for New API Project

Monday, November 4, 2024 – Last week,  which was a short week for me, I focused on building entities for our new API project. My first step was to review our entity-relationship diagram (ERD), a clear diagram we rely on for a clear visual structure of the database. This diagram, equipped with attributes and data types, serves as a reference point for any updates or improvements to the database. After double-checking data types and discussing potential enhancements with my colleague, I proceeded with entity creation within the project.

When defining entity models, I intentionally saved relationship configurations for last to avoid complications, allowing me to focus on careful assignments. After adding a migration, my initial attempt failed, so I reviewed and corrected some errors. Once the migration was successful, I moved on to developing CRUD operations, starting with a “Read by ID” query since it’s the most straightforward. Building the repository required extra attention as, unlike previous projects using EF Core, this one uses Dapper for database mapping, requiring SQL queries to be written manually. Since the entity I queried has a one-to-many relationship with another entity, I researched the practices for crafting SQL queries in such cases.

Before advancing further in the CRUD process, I created a unit test for the query. Running tests allowed me to debug and identify issues in my code and query. Mr Peter also provided valuable advice on tracing errors within the query based on error messages. By the end of the week, I successfully passed the test and plan to expand the test scenarios next week before proceeding to the next CRUD operation.

Streamlining the Seed Data Generator

Monday, October 28, 2024 – Last week, Mr. Peter assigned me the task of refining and to push the seed data generator that was previously created to automate sample data generation. Initially, the code was tailored for use only in my local environment, hence it required significant cleaning before it could be shared. Since I had been testing it extensively in a trial-and-error setup, there was quite a bit of redundant code to sift through.

To start, I revamped the UI page, removing unused buttons and giving it a more streamlined appearance. Then, I focused on optimizing the view model for better functionality.

The seed data generator was designed to handle multiple entities with a single button click, which led to long stretches of code that required careful verification to ensure smooth data generation. Although most of the functions leveraged existing code, a few necessitated extra queries. This meant creating new functions in a separate project, which hadn’t been pushed previously.

In my initial implementation, I used a parallel foreach loop to expedite data generation by processing multiple records simultaneously. However, this approach occasionally caused errors when handling more than two processes concurrently. Switching back to a standard foreach loop resolved these errors but slowed down the data generation, making the process less efficient.

Apart from needing Mr. Peter’s approval for certain functions, as I was limited to using DLL-based functions. Towards the end of the week, the generator worked well in my environment and everything was successfully operational, although further testing might be necessary.

Week 3 Internship: Creating New Page on POS System and Fixing Alert Duplicate Bugs

In the third week of the internship, Mr. Peter gave me a task to create a new page, which is the Return page. It’s all about uploading the reasons that customers return the products. We also had to add some functions, including delete, make changes, and search filtering. In the beginning, all the workflows I was working on were still good, all the API fetching could refer to other pages until I faced the searching and filtering problem. This was because the APIs provided by other pages allowed developers to call and search by query, but the Return Reason API did not have the searching function. I tried to solve this problem by myself, attempting to fetch data without sending a query to the API and instead searching and filtering locally so that it would not be influenced by network lag or latency.

After finishing this page, Mr. Peter asked me to find bugs related to what would happen if users deleted cookies manually and if the network was disconnected. Through these behaviors, I found that while deleting cookies manually, users could still edit data without logging in until the page refreshed. Additionally, after the network was disconnected, the website would pop up with a message saying “reading data null” as usual. Then, Mr. Peter asked me to do unit testing on the page I had just finished, but it seemed like there was something wrong with the Jest configuration. I’m still trying to solve it to ensure the tests can run successfully. Externally, I found that every time a user wanted to delete some data on the page, the website would pop up a confirmation dialog box, but after clicking confirm, the second alert that shows “data deleted successfully” would not appear. So, Mr. Peter asked me to find another alert component to replace the original to fix this problem.

In conclusion, this week was quite busier than the previous week because of solving a lot of bugs and creating new pages. I learned a lot from the experience of fetching real data from the API and working with it.

Create Tables and Unit Testing

Third week as an intern in Tong Hin. The task for the week is to do tables for users, tax and user’s address. At the start of the day, Mr Peter shared the repositories for the project. Creating tables is not hard but connecting the relationship took some time to think and code.

Most of my time has been used in creating unit test. To think about how a unit test can cover all the possible exception that might occur and learning to use breakpoint for debug. Debugging use lot of my time due to unfamiliar with debugging tool, doesn’t know how to trace back to the problem is and couldn’t understand the meaning of the exception. After Mr.Peter demonstration and some telling of Ms.Laili, I get to know the flow for debugging.

Ms. Laili has asked me for committing and pushing the code to Sourcetree. She showed me how to do it and the format for naming the commit and push. Beside that, she also teached me the content for the commit and push. I am happy with the environment of the company as it engaged me to continue learning.

In summary, the study week has been end at the previous week. It is working week starting onward and I am looking forward to it. The task for the week keep me busy. Hope that the weeks onward can also be fun for me.

Internship (Week 2): Brainstorming solutions while running project file

On the first day, I review the notes from PDF files and the transcript documents to consolidate my learning. I also watch tutorial videos multiple times to grasp complex concepts and complete the exercises and quizzes as learning checks. Then, I was brainstorming potential solutions for the project involving two systems.

On the next day, Mr. Peter share access to the sandbox project on Dropbox to help me practice API development. I then clone the repository and successfully run tests to get familiar with the project structure and functionality. Then, I explore creating APIs using features, data and controllers while hosting PostgreSQL on Docker for practice by running some code and use pgAdmin to connect to the PostgreSQL server. I also follow specific steps in Visual Studio to manage the database and migrations. Soon, I successfully ran the sandbox API project and authenticate it via Swagger. Meanwhile, I also discuss with colleagues to solve setup issues like update databases and successfully test the project using Docker.

Besides that, Mr. Peter ask me to brainstorming solutions for synchronising the difference datanases between the systems. We initially try to sync data manually through API, but we discuss implementing RabbitMQ for automatic synchronisation. I also search online resources to look for potential solutions for hosting and synchronisation mechanisms.

Moreover, Mr. Peter sent me another folder on Dropbox to explore the existing system and other module. However, I face configuration issues when trying to access all project files. I questioned about this and Mr. Peter considered as a config error, he then provide me additional documentation related to them to implement synchronisation properly. I then ran the project, but encounter some errors because certain folders were not share initially. Unfortunately, I forgot to inform Mr. Peter immediately about this issue, which delayed my progress slightly.

Conclusion

This week, I felt excited about the technical challenges, but at the same time, the tasks were stressful. Brainstorming solutions was tough and I struggled to confidently answer some questions from Mr. Peter. I realised that I still need to familiarise myself with the project and improve my critical thinking skills. Meanwhile, I felt stressed and unsure of my abilities which made it harder to keep up with Mr. Peter’s expectations. A key takeaway this week is that I need to communicate issues more effectively so that problems can be resolved faster.

Moving forward, I’ll stay proactive in raising questions and flagging blockers early. Despite the challenges, I am determined to refine my problem-solving skills and gradually gain more confidence. I’ll keep learning, practicing and collaborating with the team as I work towards completing the system integration. I’ll continue refining my problem-solving skills and look forward to completing the system integration soon.

Week Two as an Intern: Setting up Dropbox and Working on a POS System Project

Last week, I dedicated my time to advancing my knowledge in Jest Testing, React Next.js, and TypeScript. Building on this foundation, I spent this week focused on the company’s POS website project, where my primary responsibility was to identify bugs through a method known as monkey testing. This involved testing all system functions and thoroughly exploring different paths of interaction within the site, which allowed me to identify several unexpected issues and glitches. This testing process provided valuable insights into the website’s robustness and usability under varied conditions.

After reporting my findings, Mr. Peter tasked me with addressing several UI design bugs. I concentrated specifically on improving the user experience when the screen was zoomed in to 150% or more—a scenario where readability often suffers due to text scaling issues. I reworked the drawer navigation, enhancing its functionality to allow for better filtering and categorization. This was not only an improvement for current users but also a forward-looking solution, preparing the layout to accommodate future additions as more pages are integrated into the system. To further improve user experience, I also added a cover to the navigation drawer, ensuring a more seamless and polished interface.

Through these tasks, I gained substantial experience with Tailwind CSS, learned techniques for handling screen zoom effectively, and strengthened my skills in layout design. This project provided an excellent opportunity to apply these tools and practices to real-world UI challenges, enhancing the accessibility and functionality of the POS system.

Continue learning and hands-on experiment

Second week as an intern in tong hin. Resuming to Dapper and PostgreSQL on Monday, I had learnt SQL in university so it wasn’t hard to learn some extension for SQL. After that, I return back to ASP.NET core to continue learning.

Time move forward to Wednesday, Mr. Peter share the company sandbox and able to have some hands-on experiment. Besides that, I am able to learn how to run the tests and also how to write an API using features, data, and controllers. Even though I met some problems during the setting up phase such as unfamiliar with Docker and unused to the config settings, everything are solve at the end of the day.

Experimenting with the sandbox is fun. Getting to know the architecture the company used and the way the company write the code is some sort of interesting for me. By Friday, the task of reviewing ERD, create tables and commands and run unit test has come by. I discuss with Mr. Peter about the ERD on some questions I thought on the diagram and meet some problems while creating the tables.

In summary, this week is still a study week and get to learn by having other hands-on experiment. At the end of the week, get to do some task that I have been learning for the past weeks. It’s been a happy learning week for me.

Internship (Week 1): Learning version control and back-end technologies

During the first week of my internship at Tong Hin, I had the opportunity to meet my colleagues including my new friends, as well as our supervisor Mr. Peter.

Mr. Peter gives us various tasks about the version control tool as it will be used extensively in Tong Hin during internship. I explored Git tutorials while practicing commands in Git Bash. After the tutorials, I worked closely with my friends with Bitbucket and learned how to push/pull requests, create branches and resolve merge conflicts. Then, I explored the Git Flow methodology. I also faced some difficulties especially when following the tutorials which made me feel discouraged when certain tasks didn’t work as intended. I reminded myself that this is part of the learning process. With my colleagues’ support, we discussed the problems and worked through the challenges together.

The next day, to enhance our programming knowledge, Mr. Peter recommended to me Pluralsight courses about back-end technologies. I began learning C# to prepare for my internship, focusing on key .NET features. Through a gradebook project, I practised .NET CLI commands, mathematical operations, arrays, xUnit testing and OOP concepts. I also explored delegates, events and file handling which gave me a solid foundation in C# development. Next day, I learned ASP.NET by building APIs with the “GloboTicket” project, where it applied clean/onion architecture principles to organise components like API, core, and infrastructure layers. I also used some tools like MediatR, AutoMapper, FluentValidation and Swagger. Additionally, I gained experience with JWT-based authentication, Serilog for logging and explored Blazor with NSwag. There are many concepts that were complex but this course broadened my understanding about API design.

Moreover, I dived into Test-Driven Development (TDD) with the “Wired Brain Coffee” project. Although writing tests before code was initially challenging, the red/green/refactor cycle gave me a sense of accomplishment after each passed test. I further improved my testing skills with a course on Mocking. Learning about Test Doubles (Fakes, Mocks, Stubs) and behaviour vs. state testing using Moq and xUnit. I also studied Dapper, the micro ORM I will use in my internship, that focuses on CRUD operations, repository patterns and advanced topics. Finally, I explored PostgreSQL through pgAdmin by practising SQL queries with a DVD rental dataset. I enjoyed learning concepts like CTEs, transactions and grouping operations, even though some topics were challenging.

Conclusion

This week’s focus is on getting familiar with Git for version control and exploring various back-end technologies through Pluralsight courses. The first week is filled with learning opportunities and challenges. I explores a variety of tools and methodologies includes Git, C#, ASP.NET, and PostgreSQL, which provides the foundation for my development work during my internship. Despite the steep learning curve, I found the process extremely valuable and motivates me to continue improving my skills as I continue my software development journey.

Lessons from Setting Up PostgreSQL on Sandbox Project

Monday, October 21, 2024 –  Last week, I was given access to an API sandbox project. In this sandbox, Mr. Peter had already outlined the necessary components for building the API, serving as a reference for the new project. To get started, I needed to set up a Docker container for one of the databases we would be using, PostgreSQL. After configuring everything, I ran the application and tested the Swagger page, successfully verifying that the API was working.

However, I later noticed that the intended database was not appearing in PostgreSQL. After consulting with Mr. Peter, it was discovered that one of the configuration settings had not been correctly applied. Once this was resolved, the database was successfully created. I then quickly dove into creating a table for an entity and took the opportunity to learn more about how Dapper and PostgreSQL were integrated, ensuring I fully understood the technology stack I’d be working with.

Since we used EF Core to create the tables, much of the code structure remained familiar, even with PostgreSQL as the database. Without wasting time, I began working on an API query for one entity. Toward the end of the week, Mr. Peter advised that when working on the real project, I should start by working on smaller, less complex tables first and tackle the more complex ones later. Initially, I had assumed the opposite approach was better, but his guidance gave me a clearer perspective on how to approach the project.

1st Week Internship

This week is my first week of internship at here. The first task of the week is to get familiar with git. Even though I have learned git at the university, Mr Peter would like me to refresh with Git with tutorials. It is indeed useful as the tutorials cover some part the university did not cover. Besides that, it also does help me get back to hand on Git. After that, I created my own private repositories on Bitbucket as a Git cloud server as this will be the server we will be using through out the company. I tried to pull, push and merge it with other interns in the company to have an experiment. It was fun. Mr Peter also introduce git flow at the end of the day.

Second day, the second task has come by. Mr Peter introduce Visual Studio as the primary IDE for work. I was told to learn C#, a language similar to Java but better readability and more organized and I agree. I found that C# does easier to understand compared to Java and the company used C# as the main language. It took me about three fourths of the day to learn the language. After learning C#, I continued with learning ASP.Net Core. This is challenging as it introduces lots of concept, I haven’t heard of such as SOLID, DRY, POCO and application architecture which seem complicated. After learning and trying tutorials for almost 3 days, I am able to understand and get the logic behind it but still just a beginner at the end of the week.

Task 2 also includes Test Driven Development, Moq and xUnit to write text scripts and the concept of it. This is easy to understand and able to quickly absorb the knowledge about it. Moving on to PostgreSQL and Dapper, I was able to learn a bit of it as this is the end of the week. Will proceed to learn on the next week.

In conclusion, the week has been a wonderful week and looking forward for my internship at Tong Hin.