Posts

Showing posts from March, 2026

CST 438 - Week 4

     One of the topics I have been interested in “Software Engineering at Google” is testing culture. The testing overview chapter discussed the evolution of testing at Google from being non-existent to official company practice. What stood out to me was how it compares to the view of some software engineers I have talked to in the past. While sharing their views on unit testing with me, an engineer told me at the time that it's something they don't do often. Their reasoning was that after spending so much time writing a code, the last thing they want to do is write even more code for unit tests. Another engineer shared with me that writing unit tests is something that is left for the interns. From their perspectives, I can see how engineers can become complacent and the testing culture at an organization can degrade.      In contrast, reading about Google’s systematic approach to testing and how it was needed after the Google Web Server failures highlighte...

CST 438 - Week 3

       Git is a version control tool used for tracking and effectively storing changes within a project. Git does not store entire copies of the code base as it stores snapshots of line code changes. Source code can be branched from and new code can be developed in different branches. This enables the development of new features, reducing the risk of introducing new code that may compromise the main branch. Separate repositories can be used to store copies of the entire project, which can be used developing different versions of the application or separating the development of large components of the project.      The Git merge command merges changes from another branch into your working branch. A merge conflict occurs when Git can not automatically perform the merge due overlapping changes in the same lines of code. In this case, the developer must manually edit code to resolve conflicting changes. Otherwise, Git will automatically perform the merge e...

CST 438 - Week 2

       In lab 3 this week, I developed a simple frontend to communicate customer and order data to the Spring Boot backend. To accomplish this, I used the React library to create reusable interface components. This involved building a user interface for certain tasks such as registering customers and updating customer settings. In React, data can be passed to components as props, which is useful for tasks like providing the EditOrder component data to display a customer's order history prior to editing it. This lab also introduced special functions called hooks  to access the React state and features. The useState function accepts a variable’s initial state and returns an array containing the state variable and function to update the state variable. The useEffect function is used to synchronize with an external system, which in this lab, was used to get orders upon refreshing the page.      This was not my first time using the React library, but t...

CST 438 - Week 1

       This week I got to work with the Java Spring Boot Framework for the first lab of this class. This lab covered building a RESTful API to update customer and order information, which included using HTTP methods like GET, POST, PUT, and DELETE. By creating API endpoints, Customer/Order data received from the client through data transfer objects could be passed to the database through repositories. This application also covered authentication using tokens that were generated during the login process. User authentication in this lab ensures that users can only alter data pertaining to their own account.       While I thought this lab was helpful for learning how to use the Spring framework, I still want to develop a better understanding of how the framework works internally. One concept I was interested in was how the repositories were implemented without explicitly creating classes that implemented them. In my research, I found at runtime, Spri...