Posts

Showing posts from July, 2026

CST438 - Week 6 Reflection

 Write a weekly entry describing important things you learned this week.          At first glance, this week's reading materials appear to cover different territories while ultimately tying together nicely and cohesively. The weekly SAG reading, written piece on React material, and Assignment 4 description all concern maintainable, scalable, and thoroughly tested software on both an infrastructural and application level. SAG introduced Compute as a Service (CaaS) to explain how Google transitioned from manual server management to automated compute platforms such as Borg. Borg would later inspire systems such as Kubernetes, this innovation would become a mainstay in development as developers could now decide which machine runs an application and automatically deploy workloads, allocate resources, monitor health, and restart failed services. The chapter illustrated how manual work does not scale and automation is instead a necessity as an organization grows. ...

CST438 - Week 5 Reflection

Summarize in a few sentences what you have learned this week.            This week's reading of SAG served to expand upon the various roles and varieties of larger tests and test styles including integration, end-to-end, performance-based, and production-based testing. Unit tests persist as a cornerstone of fast, isolated, and useful testing that verifies individual classes or components that comprise large systems. These unit tests cannot provide complete assurance on their own for an application's functionality when services, configurations, databases, interfaces, and external dependencies are to be combined and collectively accounted for. Large tests close the gaps by exercising the actual system--or at least an accurate approximation of the system--to produce results that reflect the behavior real-life users will encounter once the system enters production.          Fidelity--the degree to which a test accurately portrays or rep...

CST438 - Week 4 Reflection

          What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?          Throughout reading SAG, I have found myself repeatedly fascinated with the granularity with which Google has established software engineering methodology. The level of depth that each respective workflow boasts--whether this is code reviews, ownership, testing, or readability standards--is a departure from my work experience where establishing SOPs has historically been a substantial challenge. It is a miracle that these engineers have managed to get this much written down and canonized. The guardrails and approval steps can appear daunting and restrictive at first glance but ultimately, they serve to provide an engineer the proper runway to make the most effective additions and changes to a code base that they can. These processes prevent slowing development by allowing programmers to focus on writing maintain...

CST438 - Week 3 Reflection

 Describe what are the good points about using Git for source code management. What are possible problems that Git merge does not solve when merging code from different developers?          This week's lab 5 demonstrated why Linus Torvald saw the need to create Git and additionally why it has become the standard tool for version control management. Git's unmatched traceability when seeking out code change history via commits makes it simple to see all additions, subtractions, adjustments and remediation of the code. Git's use of branches allows developers to work separately on features and bug fixes without disturbing the main branch before verifying the new additions to the code are safe to merge. Git allows for an organized work flow that enhances collaboration while preventing developers from stepping on each other's toes.           As lab 5's merge conflict illustrates, Git cannot solve every collaborative coding problem o...

CST438 - Week 2 Reflection

           This week's offering from CST438 demonstrated the usefulness and sensibilities of a web development framework known as React. Instead of manipulating a web page directly via its Document Object Model (DOM), React uses a component-based architecture that updates a copy of the DOM to determine which portions of the page need to be changed. Lab 3 familiarized the class with the fundamental aspects of the React framework: reusable components for the user interface such as a login page, props to pass inputs between relevant component, JSX (which exists somewhere between JavaScript and HTML), state management, sending user changes to the backend, and making REST API calls. These concepts became increasingly practical throughout the lab as controlled form inputs, event handlers, session storage, conditional rendering, and REST API communication combined to create responsive user experiences while minimizing unnecessary communication with the backend. As...