Learning to Think In Code

 Week 3 Learning Journal: This week, a new family of design techniques and graph traversals were presented. First, brute force design techniques were reviewed which rely on enumerating and checking each potential solution, like how we discussed brute force solution to both TSP and the Knapsack Problem, also why brute force may be impractical for large problem instances. Next, we also went over Breadth-First Search and Depth-First Search traversals to graphs, and I was surprised to learn where to use each type of traversal and their time complexities for graph representations using either an adjacency list or an adjacency matrix. I enjoyed the discussion of divide and conquer algorithms and the Master Theorem, which showed an organized technique for reasoning about time complexities of recursive functions rather than unrolling each one.

CST370 Module 2 Weekly Engagement  This week we dove deeper into algorithm efficiency, and how we can approach analyzing it using notation such as Big O, Big Theta, and Big Omega. I got more practice in finding the time complexity of an algorithm through pseudocode and recurrence relations for algorithms that included brute force methods and recursion. I also worked through algorithm puzzles such as finding the angle of the clock hands, and the racing car puzzle to provide better context to the theories rather than pure memorization. The quiz helped solidify my knowledge, while also testing it, allowing me to understand what I need to work on for future.

Class Engagement Week 1 Many core ideas for algorithm design and analysis were covered in Module 1, and one major idea that resonated with me in this part was being taught to express algorithms using pseudocode first, and then translating them into the actual program. I think dividing an algorithm into step-by-step logic really helps organize the problem in a more coherent and digestible way, and it makes programming easier later on. The algorithm puzzles, such as the fake coin, traveling salesman and matching pairs puzzles were very enjoyable as well because they challenge my ability to think from multiple angles. Another thing that I thought was really interesting was getting introduced to Sorting, Searching, Graphs and Trees, and what the purpose of different STL data structures are in efficiently organizing data. We also started touching upon algorithm analysis and time complexity. Identifying the basic operation and comparison between the worst-case vs the best-case performances w...

What went well? What would you improve? What was the most impactful part? What challenges did you face?  What advice do you have for future SL students?      Overall, the service learning project at the Kern County Sheriff's Mounted Posse was a valuable experience. The goal of my project was to design and implement a photo upload and storage system that would enable event participants and volunteers to upload photos via a mobile friendly website. Something I feel I was particularly successful in was applying the skills and principles that I have learned through the computer science courses, to solve  a real world problem. Planning, designing, and developing this system had provided me with real world experience of not just developing a system, but also how a system as such can be beneficial to an organization even after the class is done. I feel that I accomplished something useful by providing a solution for the organization.      The most signif...

This week’s module focused on how operating systems manage I/O devices, hard drives, and the basics of file systems. The main topics we covered were I/O devices, the structure and performance of hard disk drives, files and directories, and finally how a simple file system is implemented. All of these tied back to the bigger idea of how the OS communicates with hardware while keeping everything organized, reliable, and efficient. We discussed I/O devices, where we distinguished between block devices and character devices and the way the OS communicates with both categories. The discussion revealed that disks, keyboards, and USB peripherals, for instance, differed markedly in their performance requirements. I grasped the main ideas but had to struggle a little bit with the concept of hierarchical buses and the reason behind faster devices being nearer to the CPU. It dawned on me that it’s all about minimizing latency and maximizing data transfer rate, thus the concept clicked. Next, we w...

The week was primarily about concurrency, and among the most important things that we studied were condition variables, semaphores, implementation of a bounded buffer, synchronization barriers, the Anderson/Dahlin method, and some typical bugs in concurrency. It is true that all these topics are related, but they all deal with thread coordination in different manners. Condition variables made sense to me once I realized they basically act like a “waiting room” for threads. A thread can go to sleep until some condition becomes true, and another thread signals it when it’s time to move forward. Semaphores felt similar at first, but I learned they’re more like counters that let a certain number of threads access something. The difference between binary and counting semaphores stood out to me. Binary feels like a simple lock, while counting semaphores allow more flexibility depending on the resource. The hardest part this week was keeping the differences between locks and condition variabl...