As part of my Capstone, I have chosen to participate in the certificate track instead of the project track. The certificate track involves selecting 3-4 certificates that interest me and will benefit my future career. The two main certificates I have decided on are AWS Cloud Practitioner and Google's Cybersecurity.
As part of the Certificate Track, we are required to create a proposal that outlines the rationale for each certificate, the learning objectives, a general timeline, and an evaluation of potential risks along with mitigation strategies.
This week, I decided to start the AWS Cloud Practitioner course to prepare for the exam. I found the AWS website a bit convoluted to navigate, and spent some time researching before finally creating my AWS Educate and Skillbuilder accounts. Unfortunately, I fell behind on the modules because I misunderstood that I could begin the process before being graded on my Certificate Track Proposal. I will need to dedicate extra time to make up for the lost time and stay on track to take the exam.
Tuesday, February 3, 2026
Saturday, December 20, 2025
CST438 - Week 8
With week 8 coming to a close and the holidays just around the corner, my time in this Software Engineering class is also coming to an end. Throughout the course, there were several topics that I found particularly important.
A crucial part of any development stage is, of course, testing. Interestingly, you often spend more time writing tests for your code than you do writing the code itself. This highlights the importance of testing and ensuring that there are no critical bugs in the application.
Another aspect I've learned in this class is collaborating with a group on a GitHub project using the Agile process. Collaboration is an essential part of working in the industry, and experiencing the Agile process, rather than the traditional plan-and-document Waterfall process I was more accustomed to, was a valuable learning experience.
Building off my previous point, one of the most crucial parts of the development process is the code review stage. This aspect, I feel, is often overlooked; however, during peer reviews, I identified several code issues that did not meet requirements and needed to be rewritten or updated to address problems that were not immediately apparent to my peer.
One portion of the class that I am glad we covered extensively was the use of Git. I was already familiar with GitHub from personal projects and previous classes, but this course went into more detail about Git and GitHub, including how to better organize a project and how important Git commands interact with one another.
Lastly, I want to mention the introduction to Amazon Web Services (AWS). Before this class, I had never needed to use AWS, and when I had hosted projects in the past, I used a different service. Since AWS is widely used in the industry, having at least a basic understanding of it is important. While I would likely still need to refer to documentation to set everything up, due to the number of available services, this exposure helped reduce how overwhelming the platform initially feels.
A crucial part of any development stage is, of course, testing. Interestingly, you often spend more time writing tests for your code than you do writing the code itself. This highlights the importance of testing and ensuring that there are no critical bugs in the application.
Another aspect I've learned in this class is collaborating with a group on a GitHub project using the Agile process. Collaboration is an essential part of working in the industry, and experiencing the Agile process, rather than the traditional plan-and-document Waterfall process I was more accustomed to, was a valuable learning experience.
Building off my previous point, one of the most crucial parts of the development process is the code review stage. This aspect, I feel, is often overlooked; however, during peer reviews, I identified several code issues that did not meet requirements and needed to be rewritten or updated to address problems that were not immediately apparent to my peer.
One portion of the class that I am glad we covered extensively was the use of Git. I was already familiar with GitHub from personal projects and previous classes, but this course went into more detail about Git and GitHub, including how to better organize a project and how important Git commands interact with one another.
Lastly, I want to mention the introduction to Amazon Web Services (AWS). Before this class, I had never needed to use AWS, and when I had hosted projects in the past, I used a different service. Since AWS is widely used in the industry, having at least a basic understanding of it is important. While I would likely still need to refer to documentation to set everything up, due to the number of available services, this exposure helped reduce how overwhelming the platform initially feels.
Wednesday, December 17, 2025
CST438 - Week 7
Well, that's the end of week 7, and pretty soon this class will be wrapping up with the final exam in week 8. This week, we focused on development processes, in particular Agile and Waterfall.
So far in this class, we've been using an Agile process, which is essentially iterative and evolving. Work is divided into short iterations, about one week for our project. Each iteration involves a meeting, and requirements continue to evolve as we work on the project and discuss progress.
A Waterfall process is different in that it is extensively documented at every stage before development begins. Changes cannot be made on the spot, like in Agile.
So far in this class, we've been using an Agile process, which is essentially iterative and evolving. Work is divided into short iterations, about one week for our project. Each iteration involves a meeting, and requirements continue to evolve as we work on the project and discuss progress.
A Waterfall process is different in that it is extensively documented at every stage before development begins. Changes cannot be made on the spot, like in Agile.
Tuesday, December 9, 2025
CST438 - Week 6
With the end of week 6, my group's project is coming together after working on our system tests. I think working on system tests is a very valuable skill to learn, and working on that for our project has been a valuable experience.
At one point, I ran into an issue where my two databases were not communicating properly. I initially thought it was a problem with the Chrome Driver, but it turned out to be an issue with the schema in my Gradebook repo not having an auto-increment for the primary key. Once that was resolved, it was relatively smooth sailing for the rest of the test implementation.
At one point, I ran into an issue where my two databases were not communicating properly. I initially thought it was a problem with the Chrome Driver, but it turned out to be an issue with the schema in my Gradebook repo not having an auto-increment for the primary key. Once that was resolved, it was relatively smooth sailing for the rest of the test implementation.
Tuesday, December 2, 2025
CST438 - Week 5
This week we continued work on our group project, focusing on implementing the frontend to communicate with our backend. The frontend development tasks were relatively straightforward, and our project management process has been going well; everyone is following the correct workflow to create, review, and merge pull requests.
Outside of the project, we also had a fairly long chapter to read on large tests in Software Engineering at Google. I admit I wasn't very familiar with testing beyond unit tests, and I'm still not perfect at writing them to achieve full coverage. While unit tests are great for verifying individual pieces of code, such as functions, large tests are important for ensuring that the entire system works correctly across many scenarios.
Outside of the project, we also had a fairly long chapter to read on large tests in Software Engineering at Google. I admit I wasn't very familiar with testing beyond unit tests, and I'm still not perfect at writing them to achieve full coverage. While unit tests are great for verifying individual pieces of code, such as functions, large tests are important for ensuring that the entire system works correctly across many scenarios.
Tuesday, November 25, 2025
CST438 - Week 4
This week, we started work on a group project that involves familiarizing ourselves with a partially completed codebase and then implementing the rest.
We also read Chapter 9 of "Software Engineering at Google" on Code Review. Although we have only read a few chapters so far, the most interesting thing I learned was that Google's codebase experiences close to 25 million lines of change every week. I found it interesting how they manage such a massive volume of changes.
Overall, it was a good week. The project was a bit challenging, as it took some time to set everything up and get familiar with parts of the codebase.
We also read Chapter 9 of "Software Engineering at Google" on Code Review. Although we have only read a few chapters so far, the most interesting thing I learned was that Google's codebase experiences close to 25 million lines of change every week. I found it interesting how they manage such a massive volume of changes.
Overall, it was a good week. The project was a bit challenging, as it took some time to set everything up and get familiar with parts of the codebase.
Tuesday, November 18, 2025
CST438 - Week 3
This week, we focused on the basics and importance of Git for managing code, as well as how it functions in a team environment with multiple developers pushing changes to a single repository.
There are a lot of great features of Git, such as simplifying code publishing and updates, enabling the creation of separate working branches, and merging those branches into the main branch.
One issue with Git's merge feature is that it does not flag a conflict if the same line of code was not edited in a different branch. For example, if Developer 1 updates a variable from X to Y, and Developer 2 did not make changes to that line in their branch, there would be no merge conflict. However, the change itself would give an error for Developer 2's code if they tried to use the X variable.
There are a lot of great features of Git, such as simplifying code publishing and updates, enabling the creation of separate working branches, and merging those branches into the main branch.
One issue with Git's merge feature is that it does not flag a conflict if the same line of code was not edited in a different branch. For example, if Developer 1 updates a variable from X to Y, and Developer 2 did not make changes to that line in their branch, there would be no merge conflict. However, the change itself would give an error for Developer 2's code if they tried to use the X variable.
Subscribe to:
Comments (Atom)