CST438 - Week 1 Learning Journal

         Upon attending the orientation for CST438: Software Engineering, I was surprised to learn that this class positions physical programming as more of a backseat concept to the core subject matter of the presented curriculum. After having read through chapter 1 of Software Engineering at Google, I see there are many non-programmatic concepts a developing programmer must learn--pun absolutely intended. This class somewhat reads as more of a conceptual and spiritual sequel to Software Design since that class focused on sound design patterns for building functional, scalable, and reworkable software. To address how my perspective has shifted upon completing week 1's materials, I will dedicate a paragraph to the REST labs and a subsequent paragraph to the SAG reading.

        The REST application labs 1 and 2 were a strong start of blending a small programming challenge into illustrating how responsibility is delegated across entities, repositories, controllers, and data transfer objects (DTOs.) Annotations allow Spring Boot and Jakarta Persistence APIs (JPA) to provide functionality. With proper persistence from JPA, dependency injections, and the callback to databases via entity relationships, the first couple labs of CST438 demonstrated how to expose only necessary data and avoid directly exposing database entities. Despite even some object-oriented programming making a small celebrity appearance, the labs ultimately served to show the power and importance of relying on existing frameworks and conventions over simply writing the entire application ex nihilo. 

        The SAG textbook reading additionally solidified some of these concepts but expanded to discuss and qualify programming integrated over time--both physical time and the business requirement timelines common to any industry--and amid the logistics of shifting personnel involved in any respective long-term project. Programming versus software engineering is an important immediate distinction: programming focuses on ensuring software works, software engineering focuses on ensuring the software remains maintainable in a landscape where hardware, software, and team personnel will inevitably change with the passing of time. Much as Professor Wisneski promised during the orientation, the textbook focuses much more on time, scale, and tradeoffs over syntactical or algorithmic knowledge. A few standout concepts from chapter one include Hyrum's Law which states that users depend on observable behavior of an API, including undocumented behavior, which is why long-term changes become difficult. Shifting Left describes finding problems related to security and performance early in development as they become much more expensive after further development. The Beyonce Rule states that if a feature or behavior is important, it must be included in continuous integration (CI) testing. Finally, deferring and accepting a tradeoff of technical debt is sometimes necessary in various stages of development. 

        

Comments

Post a Comment

Popular posts from this blog

CST462 - Service Learning Reflection: LibreOffice

 Service Learning: LibreOffice Software Development Reflection           Throughout my service-learning experience with LibreOffice, I gained a much-needed and hands-on understanding of what it actually means to engage with a large, long-lived open-source codebase. One of the biggest victories was simply learning how to navigate the environment--getting the project to build, understanding the workflow through Gerrit, and becoming comfortable using tools like "git grep" to locate and modify relevant code. These may seem like small steps but in a project of this scale they are foundational and non-trivial. I feel very prepared to dive into another huge codebase where I must accept that I simply will not be able to understand much of what I see and instead will have to drill down into one specific focus to gain understanding and contribute efforts.           The most impactful parts of the experience were seeing how rea...
Read more

CST370 - Week 7 Reflection

   Week 7 Learning Recap           Week 7 of CST370 was a reinvigorating volley of algorithmic delights. I found myself looking forward to the programming assignment during this week’s lectures and puzzles. I always love actionable steps, the pathway to victory as my Calculus professor once called it. As the shadow of the final exam looms ever closer, I have been quite intentional about fully absorbing the lecture, example, and textbook excerpt before moving onto the next concept.           This week's algorithms folded very nicely into each other throughout the module. Counting sort using frequency and distribution to place in the index was the perfect simple intro to stack Radix's LSD method of going digit by digit.  The coin collection problem was my first "alright pausing on this and clocking back into work" moment, but upon returning became quite clear--I appreciate that dynamic programming is tactile and ca...
Read more

CST334 - Week 7 Reflection

          This week of CST334 saw the class exploring file system implementation, low-level storage performance, and file system-related system calls. The lab work on persistence calculations proved to develop muscle memory on cranking and understanding disk access times. The calculation involves computing rotational delay, seek delay, and data transfer delay using given parameters such as RPM, transfer rate, and read size. These exercises reinforce how physical disk characteristics affect overall performance, and how to estimate the latency of accessing files on spinning disks. We also worked with inode-based file systems. Given inode sizes, inode numbers, and starting locations, we calculated exact inode addresses, identified their containing blocks, computed their offset within those blocks, and determined their index. This helped further solidify my understanding of how a file system maps logical structures (like inode numbers) to physical disk addresse...
Read more