Month: October 2024

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.

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.

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.

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.

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.

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.

During my first week of internship, Mr. Peter assigned me several tasks to enhance my understanding of software development tools and technologies. On the first day, I was introduced to Bitbucket, a software development platform used for storing, tracking, and collaborating on software projects. We practiced creating merge conflicts and resolving them, which helped me gain a deeper understanding of version control systems.

For the rest of the day, Mr. Peter gave me four tasks to focus on. First was TypeScript, a syntactic superset of JavaScript that adds static typing. After learning this programming language, I feel that TypeScript is beneficial as it makes code easier to maintain and reduces the occurrence of bugs. Next, I learned React fundamentals, understanding that React is a JavaScript library that allows developers to create user interfaces. Third was Next.js, an open-source web development framework that provides React-based applications with server-side rendering capabilities. I’ve found it to be an excellent web development framework because it saves users’ storage and provides a smooth web browsing experience. Lastly, I started learning about React testing using Jest, though I’m still in the learning process and don’t have extensive knowledge to share about this topic yet.

In conclusion ,this week has provided me with valuable insights into version control and frontend development technologies, setting a strong foundation for my internship.

Monday, October 14, 2024 – At the start of the previous week, Mr. Peter introduced me to our upcoming project, which will use Next.js for the website and ASP.NET for the backend API. However, instead of using EF Core, we’ll be adopting Dapper for mapping database queries. To help me get up to speed with Next.js, Mr. Peter provided access to a course and other resources to familiarize myself with the technologies involved in this project.

In regard to last week’s issues with message queue consumers in RabbitMQ, Mr. Peter addressed all of my concerns and provided clear explanations. I was very grateful for his guidance in correcting my misconceptions, especially on the Dead Letter Exchange (DLX). With the RabbitMQ issues resolved, I shifted my focus back to learning Next.js.

After completing the Next.js course, I immediately started applying what I had learned. Since we’re using TypeScript in our project, I initially struggled a bit with ensuring that the code I wrote adhered to clean code principles, especially avoiding duplication. Next.js is a powerful React framework that simplifies both server-side rendering and client-side rendering. To create a user interface, I applied Tailwind CSS, which made styling much easier and more efficient.

For data display, I created a dummy JSON dataset and used an online free API that provides images to enhance the product list. This allowed me to develop a simple page where a list of products is shown, and each product can be clicked to view its details on a separate page.

Towards the end of the week, I successfully built a basic dummy page that simulates a product listing with clickable details. Mr. Peter also explained the overall project flow and the different entities we will be working on in the coming week. This project will incorporate multiple databases, including PostgreSQL, MongoDB, and AWS, each chosen based on their strengths for specific tasks. I’m looking forward to diving into this exciting project of multi-database architecture as we move forward.

Monday, October 7, 2024 – Last week, I integrated a new logic for updating bulk modified entities from one context into another within an existing function. Initially, everything worked fine. However, during further testing, I discovered a loophole in the implementation. If only the name was changed, the update worked as expected. But when the user also changed the associated data code (which was used as the search key), the system created a new data entry instead of updating the existing one. After discussing this with Mr. Peter, we decided not to continue with this implementation, as it became unnecessary once the RabbitMQ message handling stabilized.

I then refocused on refining the message queue service. I encountered an issue when running the queue three times in a row: the system threw an error stating, “A second operation started on this context instance before a previous operation completed.” This was due to different threads trying to use the same instance of DbContext concurrently. To resolve this, I implemented a scope within the update data function, ensuring that each operation had its own context instance. Once completed, I tested it and it worked. However, a new issue emerged, the message execution was not happening in the correct order.

After some research, I found that implementing a semaphore could help enforce proper message execution order. Still unsure if this was the best solution, I consulted Mr. Peter. He pointed out that using a semaphore wasn’t necessary, as the issue likely stemmed from unrefined code elsewhere. The next day, Mr. Peter made minor adjustments to the code and explained that the unnecessary use of the using() function was limiting how the message queue was consumed.

With this issue resolved, I then revisited the message flow to identify potential errors or loopholes. I encountered another problem on the consumer side. If an error occurred during message processing, the consumer would issue a basic nack (negative acknowledgment), and the message would be discarded. To avoid data loss, I researched how to handle this more effectively. RabbitMQ’s documentation suggested using Dead Letter Exchange (DLX), a method that redirects failed messages to a dedicated queue for further inspection or retries.

By the end of the week, I was able to implement the DLX mechanism, so if a message received a basic nack instead of an ack, it would be sent to the DLX queue. However, a concern arose as instead of just one message being sent to the DLX queue, four messages were sent. This remains an issue to address.

Monday, September 30, 2024 – Last week, I continued the cleanup of old and unused features, focusing on the entity models that were no longer relevant. This process involved verifying that all removed features were not in use elsewhere in the code before I executed the migration and updated the database.

Previously, I had tried to create a separate connection service for RabbitMQ to avoid hardcoding the connection details. However, when testing this service, I found it failed to read the connection parameters. After consulting with Mr. Peter, I learned that the RabbitMQ connection service was unnecessary and could be simplified by replacing specific hostnames with a general hostname defined in the config file.

Next, while enhancing the message queue, I encountered an issue with publishing messages. I had initially implemented a “Publisher Confirm” mechanism, but it had drawbacks. Mr. Peter demonstrated an alternative approach that involved using transactions, along with commit and rollback procedures. This method helps ensure that messages are processed reliably, mitigating the risk of data loss.

As the message queue service is designed to update data from one context to another, it effectively processes updates one at a time after a message is successfully published. However, this raised a question: what happens to previously created data that has already undergone changes? One solution would be to delete and regenerate this data, but that would be highly inefficient, especially considering the processing time involved.

To address this, I initially considered creating a button to pull any modified changes from the original context. However, I later realized this was not the best approach. Instead, I decided to use the existing regenerate button to call out or update changes effectively. By the end of the week, I had successfully integrated this new logic into the existing function, although further testing is necessary to ensure that no errors or bugs will be introduced in the process.