Posts

CST438 Week 5

This week's reading from Software Engineering at Google covered large tests. The main takeaway is that larger tests trade speed and simplicity for fidelity. Unlike unit tests, they test how the system actually behaves in conditions closer to production, which means they catch things unit tests simply cannot. The tradeoff is that they are slower, more expensive to run, and harder to maintain. What stuck with me was that larger tests still use mocks in some cases, and that Google does not rely on full automation scripts for everything. Two key ingredients for large tests to work well are realistic seed data and production data, which makes sense because a test is only as useful as how closely it mirrors real usage.

CST489 Week 13

What project milestones did you accomplish this week? This week I finished 2 certificates and put in over 40 combined hours into the Google Cybersecurity course prior to that. I am on track to finish the Google Cybersecurity certificate by end of this week. What is your plan for next week? Next week I plan to continue studying for the AWS quiz and keep that momentum going. What challenges, if any, are you currently facing in project development? Do you need instructor assistance? No challenges at the moment and no instructor assistance needed.

CST489 Week 12

What project milestones did you accomplish this week? This week was lighter on progress. I did not hit any major milestones but I have a couple of days off coming up that I am dedicating fully to the project, around 8 hours per day. I plan to make up for the slower start before the week is out. What is your plan for next week? Next week's plan is still taking shape depending on how much ground I cover during my days off. I will have a clearer picture of where I stand once I get through those sessions. What challenges, if any, are you currently facing in project development? Do you need instructor assistance? No major challenges right now and no instructor assistance needed. The main thing is just carving out the time, which I have lined up.

CST438 Week 4

This week's reading from Software Engineering at Google was about code reviews. The part that stuck with me most was how Google splits the review across three roles: peer engineer, code base owner, and language readability approver. Each one is looking at the code differently, and that structure makes the whole process more intentional than what I'm used to. What Stood Out The bug fix review point was the most interesting. It's not enough to verify the fix works. The reviewer is also supposed to ask why the existing tests didn't catch the bug in the first place. That's a much higher bar, and a more useful one. Takeaway Reading about the code base owner role, someone asking whether the team can actually maintain this code if the original author leaves, made me realize that question doesn't get asked enough in most places.

CST489 Week 11

What project milestones did you accomplish this week? Honestly this week was a slower one for the project. I did not make significant progress on any major milestones. Most of my energy this week went toward other coursework and responsibilities outside of this class. I did keep up with the NVIDIA RAG course material but did not push as hard as I wanted to on the project itself. What is your plan for next week? Next week I plan to go full throttle. I want to make up for the slower pace this week and push meaningful progress on the project. I will also continue working through the NVIDIA RAG course and keep studying for my AWS certification. The cloud architecture knowledge from the cert prep has been directly useful for the project so I want to keep that momentum going. What challenges, if any, are you currently facing in project development? Do you need instructor assistance? No major blockers right now. The main challenge is just time management and balancing this project alongs...

CST438 Week 3

This week was all about Git and source code version control. Here are the main takeaways. What I Learned Git keeps a full history of every change made to a project through commits. This makes it easy to roll back to a working state if something breaks. Branching lets multiple developers work on separate features at the same time without interfering with each other, and pull requests add a layer of code review before anything touches the main branch. The distributed workflow we practiced, clone a repo, create a dev branch, push changes, open a pull request, merge into main, is the same flow I use at Keasy so this week felt very natural. What Git Does Not Solve The most interesting part of the lab was the warning that a successful merge does not mean the code works. Two developers can edit different lines, merge with zero conflicts, and still break the program. If one developer renames a variable and another references the old name in a different part of the file, Git sees no confli...

CST489 Week 10

What project milestones did you accomplish this week? This week I dedicated approximately 10 hours to the NVIDIA RAG (Retrieval-Augmented Generation) course, making solid progress toward my next certification. In addition to the coursework, I revisited my original project proposal and revised the scope to better reflect a realistic understanding of AWS and cloud architecture. When I initially wrote my proposal, I underestimated the complexity of AWS and set expectations that didn't quite align with what the platform actually involves. Now that I have hands-on experience deploying a real application using ECS, ECR, RDS, and S3, I have a much clearer picture of what is achievable and have adjusted my proposal accordingly. What is your plan for next week? Next week I plan to continue putting significant hours into the NVIDIA RAG course with the goal of completing it and moving toward certification. I want to maintain the momentum I built this week and push to finish the course materia...