Posts

CST 438 Week 8

Image
WELCOME TO WEEK 8 Learning Journal -  This week I reflected on the five most important things I’ve learned in this course and why they stood out to me. The SDLC Phases Understanding the software development life cycle helped me see how projects are structured from start to finish. Breaking work into phases like requirements, design, implementation, and testing makes it easier to stay organized and avoid skipping critical steps. This gave me a better framework for thinking about my own assignments. Agile vs. Plan and Document Learning the differences between Agile and traditional Plan and Document (Waterfall) processes showed me that there is no “one size fits all” approach. Agile focuses on iterations and continuous customer feedback, while Plan and Document emphasizes stability and complete specifications. I chose this because our labs showed how Agile aligns better with frequent testing and changing requirements, which is closer to real-world software. However, it was also...
Post a Comment
Read more

CST 438 Week 7

Image
  WELCOME TO WEEK 7 Learning Journal - CST 438 Describe some of the differences between using an Agile process and using a  Plan and Document (or Waterfall) process.        This week I reviewed the differences between using an Agile process and a Plan and Document (Waterfall) process. In a Plan and Document approach, requirements are written as a detailed SRS during a dedicated requirements phase, with the expectation that they remain complete and stable for the rest of the project. Changes are handled through a formal change control process, which involves evaluating the impact on cost and schedule before updating documents, code, and tests. Design is completed after requirements and is intended to be stable, while cost estimates are based on person-weeks from past experience. Scheduling uses tools like PERT charts with periodic status meetings, and testing is split between developers writing unit tests and QA handling system and acceptance tests. Howeve...
Post a Comment
Read more

CST 438 Week 6

WELCOME TO WEEK 6 Learning Journal - CST 438 Write a weekly entry describing important things you learned this week.        This week I read Chapter 25 on Compute as a Service and learned how Google turned running code into an automated system. For example, instead of rebooting machines by hand when they fail, engineers set up policies to kill and recreate a container or virtual machine automatically after a health check fails. I saw why treating servers as cattle not pets matters. When one node goes down, the system simply stamps out a new instance without any human intervention. Using Linux control groups and namespaces made it possible to safely share machines among different workloads. Writing software for this environment means dividing tasks into small units, storing all important state in durable services such as Spanner or Bigtable, and designing retries so they can run more than once without causing errors. Finally I was struck by the description of the Code...
Post a Comment
Read more

CST 438 Week 5

  WELCOME TO WEEK 5 Learning Journal - CST 438 Summarize in a few sentences what you have learned this week.        This week I learned about the role and challenges of larger tests in software development. Unlike unit tests that focus on small parts of code, larger tests help ensure the entire system works as intended by simulating real-world conditions. Larger tests focus on higher fidelity, meaning they aim to reflect the actual behavior of the system as closely as possible. For example, Google runs A/B diff tests that send traffic to both an old and new version of a system and compare the results to catch unexpected changes. These tests are useful for finding issues like configuration errors, performance problems, or integration bugs that unit tests often miss. However, they can be slow, unreliable, and hard to maintain, so it's important to design them carefully, make them as small as possible while keeping them meaningful, and ensure someone is respon...
Post a Comment
Read more

CST 438 Week 4

Image
WELCOME TO WEEK 4 Learning Journal - CST 438 What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?      What stood out to me the most from this chapter was how Google sees code review as more than just making sure the code works. It’s really about whether the code can be understood and maintained later on. I didn’t realize before how much they focus on making sure code will still make sense to other people in the future, especially as teams grow or change. The part that said code is a liability really changed how I think about adding new features.       Writing code isn’t always progress if it just adds more work for someone else down the line. I also thought it was interesting how greenfield reviews are handled. They’re not just about checking the code but also making sure it follows an approved design and is fully tested. That made me see how important it is to plan ahead before even writing anything...
Post a Comment
Read more

CST 438 Week 3

Image
  WELCOME TO WEEK 3 Learning Journal - CST 438 Good points about using Git: Git is really helpful for managing code because it keeps track of all the changes made over time. If something goes wrong, you can go back to an earlier version easily. It also lets different people work on the same project at the same time without getting in each other’s way. Everyone can make changes on their own branch and then bring them together later. This makes teamwork a lot easier and keeps the code organized.  Problems Git merge doesn’t solve: Even though Git helps bring code together, it doesn't always know how to fix conflicts when two people change the same part of a file. In those cases, someone still has to go in and figure out which version to keep. Also, Git can’t tell if the combined code actually works well together. If developers weren’t fully aligned, the merge might go through but the program could still break. So some issues need human judgment, not just Git.
Post a Comment
Read more

CST 438 Week 2

Image
  WELCOME TO WEEK 2 Learning Journal - CST 438 In Lab 1 on JUnit, we used a Mock to simulate parts of the application, like a database, without actually connecting to the real one. A mock acts like a stand-in for something real, such as a database or web service, and helps us see how our code responds without needing to use the actual system. This is helpful in unit testing because it keeps the focus on the specific piece of code we’re testing. If there’s an issue, we can be confident it’s coming from our code and not some outside system. It also helps tests run quicker and more consistently since they don’t rely on anything external.
Post a Comment
Read more