Learning to Think In Code

Overall this first module has been a good introduction into NumPy, and it was great seeing exactly how useful it is for data science in comparison to normal Python lists. I have used Python before but never actually used NumPy arrays in this much depth, so quite a lot of the slicing and operations were new to me. I quite like how you can operate on a full array rather than having to use a loop for it. For example, creating a boolean mask like tuition > 12000 and then using that mask to pull only certain values from the array was a lot simpler than I initially expected. I also thought fancy indexing and slicing were pretty easy once I could actually see the results of each expression. The 2D arrays took a little more th ou ght for me. I h ad to pay closer attention to which number represented the row and which represented the column, especially when we started combining indexing with conditions. Problem 20 in the 2D lab was probably the part that made me think the most because I had ...

 CST370 Engagement Week 7 This week, the topics studied were dynamic programming and greedy algorithms. It interested me because dynamic programming allows us to re-use some parts of the solution, since it saves the solutions of subproblems, meaning we don't have to re-calculate. The coin-row and coin-collecting problems helped me understand how tables can be used to build toward an optimal solution. I also learned about Warshall's and Floyd's algorithms and how they use matrices to solve different graph problems. The greedy technique was also interesting because it makes the best choice available at each step, which we saw with Prim's algorithm for finding a minimum spanning tree. Overall, the examples this week helped me better understand when these different techniques can be useful.

 Learning Journal Week 6: New data structures are introduced this week. We learned that AVL trees can maintain balance by ensuring each node has a balance factor of -1, 0, or 1 and they use several rotations (right rotation, left rotation, LR, RL) to re-balance the tree after insertion and thus avoid the O(n) worst case search time for a BST. We also briefly learned about 2-3 trees and how they use node splitting and promotion to maintain balance during insertion. Another significant topic for the week was heaps and hashing. We saw how max heaps can be used for priority queues and how heapify-up/heapify-down can maintain heap property after modification. It was also interesting to learn about bottom-up heap construction and how its runtime is better than inserting each element into a heap one by one. Lastly, we learned about hash tables and how hash function is used to provide average O(1) search time. We also studied about collisions and some commonly used collision resolution str...

 CST370 - Class Engagement Week 5: A variety of new algorithmic ideas were presented this week and they all stemmed from breaking problems down into subproblems. One topic that I particularly enjoyed was Quick Sort. I now better understand the partitioning strategy by selecting a pivot before the recursion begins. The various ways to traverse a tree (in-order, post-order, and pre-order) and when each traversal method might be applicable was enlightening. Topological sort using a DFS method and utilizing Kahn's algorithm for it was quite intriguing. Understanding the relationship between in-degree values made the algorithm much more intuitive. A fun example for us to practice making generalizations and deriving algorithms from examples was the King's Reach puzzle.

 Week 4 Learning Journal: This week we covered Merge Sort and did a review on all the major concepts for the midterm. We learned how Merge Sort works on the divide and conquer method, which works by breaking down an array into two smaller halves repeatedly until all the arrays are individual elements. Then they would recursively sort these arrays until they were back combined into one fully sorted array. It was good to get to see the recursion tree and how the Merge sort would be done in order to efficiently put the two arrays back together. We also looked at the Master Theorem and practiced determining what case to pick for a given recurrence relation. Going over graph traversals, brute force, and time complexity this week helped reinforce the ideas from the previous few weeks, leading to a good review for the midterm!

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

This week’s module was all about concurrency, threads, locks and also how locks can be a part of real data structure. Our main focus of the discussion was: basics of concurrency, the Thread API, Locks, and Lock-Based Data Structures. When I first read the four readings, I found it really difficult to see how all of them were connected but later I understood very well that each one is built upon the previous one. The concept of concurrency presented a single physical CPU being capable of acting like many virtual CPUs which, in turn, allows for the running of multiple threads in a program simultaneously. I got the concept that a thread is something like a mini-process but the difference is that it shares the same address space with other threads. That much was clear to me but I needed to go over the part regarding context switching between threads once again since I was not completely sure about how the registers for each thread are saved and restored. The Thread API chapter helped clear...

This week’s module covered a lot about how memory virtualization actually works, and honestly, it tied together a lot of things that were confusing before. The big topics were free-space management, paging, swapping, and translation lookaside buffers, TLB’s. Even though these ideas are all different, I started noticing how they connect to each other as part of a bigger system. Free-space management made the most sense right away because the examples clearly showed how fragmentation can mess everything up. It also helped explain why paging uses fixed-size units. Then we moved into TLBs, and that was one of my “aha” moments. Thinking of a TLB as basically a super fast “cheat sheet” that saves recent translations made the whole idea of speeding up memory access feel a lot more real. Multi-level paging was one of the topics I had to reread a couple times. The part that tripped me up was how page tables get so massive that you literally can’t store them as one giant table. Once I realized m...

This week’s module focused heavily on memory virtualization, and honestly, this has been the first week where all the topics felt like they finally connected into one big picture. We covered address spaces, the C memory API, address translation, base-and-bounds, segmentation, and paging. At first, each of these topics felt separate, but the deeper I got into the readings and the PA3 instructions, the more I started seeing how they all fit together under the idea of how the OS makes memory feel simple even though the hardware underneath is anything but. One of the clearest ideas this week was the concept of an address space. I always understood virtual vs. physical memory at a high level, but reading OSTEP 13 made it click that an address space is basically the illusion the OS gives each process, its own clean slate, even though everything is ultimately sharing the same physical RAM. That idea tied directly into the C Memory API, because malloc, free, and even pointers all rely on the O...

 During this week's class, the operating system's capability of managing multiple programs simultaneously was the main point of our discussion. The key point was the process concept, which can simply be defined as an executing program. I was not aware of the number of programs that my computer was "running" simultaneously, and thus it was fun to find out that the OS creates the illusion of having several CPUs through the continuous process switching. Physically, there may exist only one CPU, however, the impression is that everything is happening at the same time. The Process API was also a topic of discussion, mainly the fork(), exec(), and wait() functions. The fork() function, to be honest, was the most confusing to me in the beginning, as it creates a duplicate of the program and the parent and child process go on executing from the same point. This concept was a bit difficult for me to comprehend but when I saw examples, it became clearer. On the contrary, exec()...

Week One: This week was a good introduction to how computers really work behind the scenes. I’ve used operating systems my whole life without ever thinking about what’s actually going on when I open an app or run a program. The fact that the OS is the connection point between hardware and software made me realize why it is so important to speak about it. It manages memory, controls processes, handles input and output, and basically keeps everything running smoothly. Without an OS, a computer would just be a pile of hardware that doesn’t know what to do. Beside that, we took a look at computer architecture too which described the interaction of CPU, memory, and storage. I had a rough understanding of the functions of these components already, but this week was enlightening for me. It was like a visualization of the data flow between the processor and the memory, and the instruction execution was like a fine step by step movement of the machine. The lesson about binary, decimal, and hexa...

Briefly summarize the what you consider to be the three (3) most important things you learned in this course. One of the most important things I have learned in this course was how databases actually work behind the scenes, from how data is structured with tables and relationships to how SQL brings it all together. I also learned how normalization improves efficiency and prevents redundancy, which made database design make a lot more sense. I learned how to split up work accordingly as a group efficiently and how to trouble shoot databases, as well as help my group trouble shoot. I learned how SQL and Java can be intertwined as well, which was interesting to learn about and will be useful in my career later! Lastly, I gained a stronger understanding of how to use joins and queries to pull meaningful information from data, which I know will be really valuable for future software projects.

Comparing MongoDB and MySQL: Similarities between MongoDB and MySQL: Both MongoDB and MySQL are popular database management systems used to store and manage data efficiently. They support indexing, replication, and querying to enhance performance and reliability. Each allows for scalable data storage and can be integrated with various programming languages. Plus both have powerful community support comprehensive documentation and are widely used in the web development environment. Differences between MongoDB and MySQL: MongoDB is a no sql database that stores data in flexible, JSON like documents, while MySQL is a relational database that uses structured tables with predefined schemas. MongoDB results in the processing of unstructured or rapidly changing data where MySQL confirms the consistency of strict relationships. MongoDB is more easily scale while MySQL is often preferred for structured data and complex connections. When to Choose One over the Other: MongoDB is ideal for applica...

 Summarize what you have learned this week. This week, I learned how to connect a MySQL database to a Java web application, which has really contributed to my understanding of the back end of web development. Lab 17 prepared the groundwork to form and use SQL queries to interact via data, as Lab 19 is built on that concept by implementing everything into a working web app. Setting up the JDBC connection and testing different inputs taught me how databases, applications, and servers work together efficiently. Concepts covered in the quiz also reinforced my understanding of primary and foreign keys, database normalization, and entity relationships, helping me see how database structure directly affects how information is retrieved and managed in a web application.  I am really enjoy these concepts, working on databases are becoming more comfortable and exciting to work with!

The web site   "Use the Index Luke"  has a page on "slow indexes".    https://use-the-index-luke.com/sql/anatomy/slow-indexes Links to an external site.   If indexes are supposed to speed up performance of query,  what does the author mean by a slow index?  In the article "Slow Indexes" from Use the Index, Luke! , the author explains that not every index lookup is automatically fast. A "slow index" happens when the database still has to do extra work after finding the right index entries. An example of this would be if there were multiple matching rows, the system has to follow the leaf node chain, and then access the table data for each match. These table blocks might be scattered, which increases input and output operations with the storage system and slow things down. In other words, the index itself is not corrupt, it just contains such a huge amount of data that it makes the query run slower than would have been expected, still accessing the...