Posts

CST 438 - Week 7

Describe some of the differences between using an Agile process and using a Plan and Document (or Waterfall) process.  The agile approach breaks work into smaller units called iterations, where teams meet frequently with the customer. This approach allows developers to provide continuous releases for the customer, while receiving frequent feedback. Compared to the plan and document approach, the agile process is more flexible since the development team can adjust priorities as the project progresses. The Plan and document approach is much more rigid than the agile approach. The project is divided into phases where the project follows a linear progression. In this approach, objectives are better outlined, requiring less coordination between teams. This may be beneficially to teams when frequent meetings in the agile approach is not possible. Additionally with the plan and document approach, costs of the project can be identified early in the project lifecycle during the requirements...
Post a Comment
Read more

CST 438 - Week 6

     This week I learned about the evolution of Compute as a Service at Google. The reading covered compute service options, such as containers, serverless computing, and virtual machines and the tradeoffs between them. Virtual machines run their own operating system, allowing an organization more control over the environment. The organization using the compute service however, is responsible for more configuration and overhead. If this level of control is unnecessary, containers offer a lighter weight solution, as more of the configuration is abstracted. Containers share a host operating system, allowing growing production systems to scale more easily. An even lighter and more abstracted option is to use serverless computing. Much of the infrastructure configuration is handled automatically, so that developers mainly need to manage handler functions to accept request parameters. Serverless apps are stateless as well, meaning they do not store data between requests and el...
Post a Comment
Read more

CST 438 - Week 5

     After completing assignment 3, I have developed a better understanding of the peer review process. I have become more familiar with the steps I need to take before approving pull requests and merging them into the main branch. Previously, I had not put any of the pull requests I had reviewed into an accept state, but now I understand the importance of formally accepting pull requests and following a structured review process. Overall, the experience I have gained from this has helped me become more comfortable with collaborating with others. Additionally from this week’s reading materials, I have gained insight into large scale testing and the thought process behind it. Given an issue, I have a better idea of how a test engineer may address it, depending on the data they are working with and the system under test.
Post a Comment
Read more

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...
Post a Comment
Read more

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...
Post a Comment
Read more

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...
Post a Comment
Read more

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...
Post a Comment
Read more