One More Byte CS Devlog

     This week we focused on unit and system testing. Writing these tests changed how I think about projects. Id previously assumed most effort would be focused into writing the logic for a project followed by testing as a smaller task at the end but working through these unit tests and the Selenium system test showed testing takes just as much effort to perform successfully. A well tested feature often has as much to it as implementation code. At one point I spent some time debugging a multi dialog DOM ambiguity issue in AssignmentViews, a bug that never showed up just from reading and normally running the code, only from testing it properly.          This weeks lecture talk about needing more tests than you'd expect which also clicked once I saw unit and system tests side by side. My mocked unit tests were fast to write and good for edge cases, like an instructor trying to access another instructor's roster. But they couldn't tell me t...

     This week I built out the AssignmentsStudentView and Transcript components so students can view their assignment scores and course transcript. It was good practice tracking down how data is moved from a Springboot dto using a fetch call and putting it into a viewable table.      I had the opportunity to practice my ability to navigation through a multi repo project to find the source of a bug rather than just making a bandaid fix where I first noticed it. When I saw that typing a lowercase semester like "fall" returned no results, I decided to figure out where that value actually originated and traced the input back to SelectTerm, which is a shared component across several student and instructor views. Fixing the case sensitivity there meant the correction applied project wide instead of needing to be duplicated across each view that used it.

     One of the things that I found interesting from 'Software engineering at Google' was the distinction between programming and software engineering. Before taking this class and reading the text, I viewed software engineering as just an advanced form of designing and integrating large systems. While I understood that practices like code reviews, version control, and project planning were important, I thought of them more as supporting tools rather than a defining part of engineering itself.     It makes a lot of sense now that software engineering encompasses much more than writing code or designing architecture. The processes that guide development like code reviews, version control, project organization, documentation, and team collaboration are what allow software to be developed reliably by many people over long periods of time. These noncoding aspects are what separate software engineering from simply programming. I think this shift in perspective i...

     One of the biggest advantages of using git for source code management is that it provides a complete history of a project. If a new feature or bug fix accidentally breaks the program its easy to look back through previous commits and return to a working state. Git also makes collaboration much easier by allowing multiple developers to work on different features at the same time without constantly worrying about keeping every file perfectly synchronized. Branches allow developers to experiment independently before integrating their work into the main project.      Though git doesn't solve every problem that someone might run into when multiple developers are working on the same project. Merge conflicts are an most obvious issue, needing developers to manually decide how conflicting changes should be combined. Additionally, even when Git merges code automatically, its unable to determine whether the merged code makes sense logically. Two developers may m...

     This week we focused on using React alongside Spring Boot to build a full stack web application and learned how the front end communicates with the back end. I really enjoyed this topic because, while previous classes had covered front end or back end development separately, this was one of the first times I got to see how the two actually work together. It was exciting to see how data is passed between the client and server, stored in a database, and then retrieved to update the user interface. Seeing the complete flow made the overall design much easier to understand.      The solo portion of the lab was incredibly valuable because it made me have to think about how to implement the different pieces so they could communicate correctly which really reinforced how each part of the application fits together. Working through the implementation myself helped me understand the mechanics instead of just following along with examples.     ...

     This week was a nice introduction to the course along with some of the services we'll be using, specifically spring boot. I really enjoyed the labs because they gave me a chance to become familiar with spring boot again and refresh my understanding of its components. It was a good balance of reviewing concepts I had seen before while also preparing me for the rest of the course.      Before this week, I thought of software engineering primarily as the process of designing and integrating large systems. In my mind, software development was focused on writing the individual pieces of code, while software engineering was about connecting those pieces through APIs, microservices, and overall system architecture. After this week, I still think those ideas are an important part of software engineering, but I've realized that the development workflow is just as important. The processes, tools, and teams use to build software efficiently are a major part of en...