Liam's Computer Science Learning Journal

Week 3 Learning Recap          Another week, another dizzying array--or in my case with the homework, vector--of concepts, time-complexity conundrums, and new perspectives on age old programming cornerstones I have only vaguely glanced upon prior to CST370. As the perilous march to the top of the Algorithm mountain persists, I feel both comforted and daunted. On one hand, it is evident that the best cases and best algorithmic solutions to complex problems are a constant moving target that can require varying blends of planning, experimentation, calculation, brute force, and elegance--perhaps even all at once, when necessary. On the other hand, amid the raw mass of strategies and concepts I find myself somewhat awash in a sort of mountainside river that can quickly carry you downstream and force you to retrace your steps back up the range.          In an attempt to gain more stable footing on this week's slew of mental hikes, I will ...

  Week 2 Learning Recap           The second week of Design and Analysis of Algorithms reminds me that "computer science" can perhaps be a bit of a misnomer. By the same naming convention, time complexity and recurrence relations would be reduced to "telescope science" if they were astrological phenomenon. The mathematical and proof-rooted logic presented in CST370 this week wove many strands of thought together--I may have panicked when I heard "induction"--that I will attempt to unweave and reweave here for the sake of my own understanding.          Big O, big omega, big theta ruled--and I sense will continue to rule--the time complexity conversation. I will surely never forget O means upper bound, theta means lower bound, and omega means exact. Prior to CST370, I had some negligible and nebulous understanding of how loops are interpreted for the sake of n , but the lecture and textbook have laid it out very plainly as T(n) g...

 Week 1 Learning Recap          The first week of CST370 - Design and Analysis of Algorithms wrought a rousing return to one of my most revered regions of Computer Science: creative problem solving! While I spent the time before this class lightly reviewing typical Algorithm/DSA coding problems, I can appreciate that the curriculum requires first discussing how to approach problems and consider structured solutions before diving straight into the syntax and implementation details. The reading material and lectures from Week 0/1 invite students to think about how we think about problems.          Revisiting the concept of an algorithm was a sturdy if not somewhat expected kickoff to the materials for CST370, this class and textbook provided an initial and familiar concept to get started: Euclid's algorithm for computing the greatest common divisor. Having worried about GCD since elementary school math, peering into this numerical qu...

           While we didn't cover much new curriculum this week, I made significant progress on the group project and feel thoroughly inspired by  A Cloud Gaming Framework for Dynamic Graphical Rendering Towards Achieving Distributed Game Engines to further explore distributed computing. Through this project, I learned how the architecture of cloud gaming impacts both performance and accessibility. I was especially interested in the authors’ motivation to move away from monolithic, single-VM designs toward a distributed system that dynamically shifts rendering between cloud and client devices. This approach not only improves frame rates but also allows games to keep running under network degradation, which gave me a deeper appreciation for fault-tolerant design. I also spent time refining my ability to break down technical content for a presentation. Since our project involved presenting to the class via video, I practiced distilling the compl...

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

 Weekly Learning Reflection         The core focus this week was firmly rooted in safely managing access to shared resources using synchronization primitives like mutex locks, semaphores, and condition variables. I learned that mutexes are essential for protecting critical sections, ensuring that only one thread can access shared data at a time. We extended this idea by using condition variables (pthread_cond_t) to block threads until specific conditions are met, a powerful tool for coordinating complex thread interactions. I applied this in the big readers-writers assignment this week, where multiple threads may read from a shared database concurrently, but writes must happen exclusively. Implementing this pattern required carefully checking conditions, signaling waiting threads, and managing a maximum number of concurrent readers to avoid race conditions or deadlocks. I loved how well the lecture and reading matched up with the programming assignment...