Learning Blog

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...