Learning Blog

 I gained many insights into software engineering through this course. I think the details about Agile approach to project management were really helpful, particularly for someone about to join the industry. I've seen parts of Agile used in past team projects but I think I like how the team project in this class gave us a more complete view of how Agile would be used. I enjoyed learning about the Waterfall approach. The main reason is that it's not something we're exposed to much as students. Most classes tend to utilize portions of the Agile approach instead. But it was nice to be exposed to both approaches in this class. The readings on Google's approach to testing were pretty informative. In other courses we tend to skip over testing or only learn about it from a technical (coding) aspect. In this class we got to learn in depth about the reasoning behind different types of tests and how a large company like Google handles their own testing. I liked practicing with Re...

 My experience went really well. I had the opportunity to learn about how nonprofit organizations operate. I also had the opportunity to help a community in another city. I learned a lot about the organizations that collaborated with my site and the projects they were able to put together for community members. Part of my role was to reach out to other organizations for opportunities to partner with my site. The most impactful part of my volunteer experience was seeing how many committed organizations and individuals are working hard to bring services to people in need. I think my main challenge was onboarding and getting that done as quickly as possible. But my site manager was extremely supportive and gave me everything I needed to succeed. My advice to future Service Learning students is to ask questions and ask for help when needed. People understand we're students and each site's processes are new to us. It's okay to ask.

 One of my main goals after completing this class is to apply the knowledge I’ve gained to become a more effective engineer throughout my career. Having a stronger understanding of operating systems has already helped me make sense of many confusing error messages I encountered in the past when writing code. In particular, this course has shown me how problems can originate from layers deeper than the high-level abstractions developers typically interact with. Before, I would sometimes fix an error without fully understanding its cause. Now, after working through the material in this class, I feel much more prepared to dig deeper when diagnosing bugs and, hopefully, prevent some of them altogether. I also believe that with this foundation, reading and understanding documentation will be far less intimidating. Knowing what’s happening under the surface of a program gives me more confidence as a programmer and allows me to approach problems with a broader perspective, rather than rel...

 The Plan and Document process is used in software development so that much of the requirements and planning are written at the beginning of the project, and the plan is mostly followed to completion, one step after the other. In contrast, Agile development is a more flexible process where there is far less planning up front, frequent face to face meetings, and constant adaptation to changes in plans throughout the development process. The Plan and Document process is more common in projects where little change is expected and adherence to requirements are more important than flexibility. The Agile method is more common for developing software in fast changing environments where clients are likely to change their minds or market demands change quickly.

This week we learned about the persistence mechanisms and interactions between operating systems and I/O devices. We learned about file systems and hardware interfaces. We covered the structure and management of I/O devices such as hard disk drives, including RAID configurations and file system abstractions. We also learned how operating systems communicate with devices using memory-mapped I/O or explicit I/O instructions, and about the architecture involving CPU, memory, and various I/O buses (like PCI, SCSI, SATA, USB). We learned about how a canonical device interface typically includes status, command, and data registers. We went over communication methods including polling, where the OS checks device readiness in a loop, and interrupts, which notify the OS when a task completes. Each method has trade-offs depending on device speed. We were introduced to Direct Memory Access as a way to offload data transfers from the CPU, improving efficiency. We also learned how file systems inte...

 This week we learned about using service oriented architecture to better organize our application. We also practiced doing this as a group for our assignment. I can see how this would be helpful, especially if this were an ongoing project and each one of us was in charge of managing the codebase changes for a certain a feature/micro-service. For small apps, it's easy for developers to avoid stepping on each other's toes, but as an application grows, service oriented architecture helps us define what that part of the codebase will do, what requests will it take, what will it return, etc. It's easier to communicate with other team members about what we expect from the service they manage so that our service can do its job as well.

 This week, we dug deeper into the power and flexibility of semaphores in managing concurrent access and preventing synchronization issues like deadlock. One of the key lessons was how even a seemingly simple bug, like the placement of a mutex in a bounded buffer, can lead to deadlock if critical sections aren't well defined. We learned that scoping locks precisely is crucial. We also explored reader-writer locks, which allow multiple readers to access shared data at the same time while still giving writers exclusive access. This kind of fine-grained control is powerful, though we saw that it can lead to potential writer starvation if not carefully managed. The dining philosophers problem gave us a view of how deadlock can occur in real systems. The solution, which was changing the order in which one philosopher picks up forks, was surprisingly simple and very effective, showing how breaking circular wait can prevent deadlock entirely. We also looked at thread throttling, where a s...

 This week, we learned about the plan and document process for engineering projects. It's based on gathering software requirements and documenting them, as well as documenting the progress that is made in the design and implementation of software and its cost. We went over the some of the differences in this approach when compared to the agile method. We also learned about UML diagrams, with special attention to three types of these (use case, sequence, and class). I've been exposed to class UML diagrams before, but the other two behavioral type of diagrams were somewhat new to me.

 This week we learned about concurrency in operating systems and topics like threads and locks. We learned the differences between processes and threads, and how threads share memory and have separate execution states. We also learned about how threads allow for concurrency and enable a single process to utilize multiple CPU cores. We also learned how they can prevent blocking by interleaving execution. We learned about critical sections and the need for mutual exclusion to avoid race conditions. We also learned about how the pthreads library is used to manage threads, using functions like pthread_create to create threads, pthread_join to wait for a specific thread to complete, and various functions related to locks like pthread_mutex_lock and pthread_mutex_unlock.  We learned about how locking is used in multithreaded programming to handle synchronization between threads. We learned that locks prevent multiple threads from entering critical sections. We also learned about the...

This week, the most interesting part of the reading to me was the history of how Google felt the need to introduce large tests as the company grew. The diagram in the book showed a sample of the micro-services a simple social media company would use. Just based the nodes in that diagram and the interconnectivity between them, it's easy to see how large tests at Google can become infinitely complex when testing various parts of the codebase at the same time. I also found the part about the ice cream cone anti-pattern interesting in how it relates to large tests at Google. In the pattern, it showed manual tests as the largest portion (the ice cream part) and unit tests as the smaller tip of the cone, with automated and integration tests somewhere in the middle. Basically, large tests were meant to cover the gap between unit tests which are encouraged and manual tests which are discouraged (they tend to take up a lot of time).

This week we learned about how free space is managed in an operating system. Decisions on what to do with free space are based on goals such as accuracy, speed, efficiency, and minimizing fragmentation. Typically free memory is managed as a list.  We also learned about paging as a technique to virtualize memory. It avoids the fragmentation problem we saw last week with segmentation, where segments of varying size are used to store parts of a program. Because segment sizes can vary in segmentation, it creates contiguous gaps of free memory that can be too small to use for new segments of programs. With paging, this particular issue of wasted free memory is avoided by dividing program memory into frames of fixed size. This ensures that a new page will have the necessary memory to store parts of a program. Fragmentation can still occur within the page/frame, but it's less costly since isolated unused memory addresses are smaller. We also learned about how addresses are mapped to physi...