SWE Week 6

 Week 6 CST 438

Write a weekly entry describing important things you learned this week

I was only familiar with unit and integration testing. There are a few different things I learned this week since it is the first time I've performed a system test. I learned that system tests are more complex than unit tests because they evaluate how the front end, back end, databases, and other components work together. Their purpose is to verify the system’s overall interaction, not to repeat unit tests or focus on code coverage.

I also learned that system tests should make up about 10% to 30% of all tests, while most should be unit tests. Integration and functional tests fall between these two levels. Like unit tests, system tests should be repeatable, independent, and self-checking.

System testing can also include stress tests for heavy workloads, long-running tests for resource or performance problems, and failure tests to verify that the system continues working or switches to a backup when a service fails.

SWE - Week 5

 Week 5 - Software Engineering CST 438

Summarize in a few sentences what you have learned this week.

It is shocking to me that 5 weeks went by. This week I, learned frontend features like User Effects, User Loading, User Ref, and other UI features. JavaScript is very different from what I am used to. I work in the back end, but seeing some of the backend coming to life in the UI is somehow exciting. I worked on all the assignment files, so AssignmentView, AssignmentUpdate, AssignmentGrades, and AssignmentAdd. It was fun creating data and simulating how an instructor creates/update/delete an assignment and how they can also grade after a student is enrolled. The iteration planning is particularly useful to talk about with my team what we need to work on next. We keep a really good level of communication to succeed in the project, in our PR's reviews, approval, and keeping Git history nice and clean. Looking forward to what is next.

SWE - Week 4

 CST 438 - Software Engineering Week 4

What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?

There are a few things that have caught my attention from this book. First, it is how they explain that in each Pull Request the code reviewers are expecting to also see the unit test from the created class. And also, how a PR should not exceed 200 lines of code "If the code is over 200 lines of code, it is best to break the code review into multiple reviews so that a single code review deals with less than 200 lines of code". This makes sense because at work, I am currently working on testing multiple classes in a microservice using the Mockito Extension, and I had to split my commit into multiple ones, so the code reviewers don't need a long time reviewing one PR containing 20+ files. This week has been particularly interesting since we started collaborating on GitHub with my team, I am excited to see how the app comes along.

SWE - Week3

 CST 438 Software Engineering - Week 3

Describe what are the good points about using Git for source code management.  What are possible problems that Git merge does not solve when merging code from different developers? 

Even though this week has been surprisingly challenging for me, managing internship + family + school, I am happy that we got into the actual project, which really relates on how things work at work. We have 2 week sprints, and after those two weeks, we go into planning, which usually takes all day. We use GitLab instead of GitHub, but they are both very similar, just a few differences. For instance, GitHub uses pull requests, but GitLab uses merge requests, which are basically the same thing. I am so glad this class is so focused on real industry work because all the content so far applies to my internship.

I think Git is so important because it helps developers try different versions of the code, while giving them the ability to roll back to earlier commits if needed. For example, I work in a program that shares a baseline framework with another two programs, and I was improving the way the swagger gets displayed and I utilized application.properties to add multiple profiles getting rendered, while it worked for our program, it didn't work for the other two, so that means I broke their swagger. One of the senior's response to my mistake was: no worries, that is why we have Git, to be able to see our oldest versions and implement features that might or might not be needed. So Git really helps to visualize all the changes we make, and at the end of the day, it improves efficiency.

One of the problems that Git has is definitely the conflicts when other developers are working on the same feature or on the same line of code, because when both get commited, the second one tends to have merge conflicts. Luckily, Git shows you that, so you can make decisions like Dr. Wisneski was showing in the lecture.

SWE - Week 2

 Week 2 (CST438)

Summarize what you learned about React this week.  In your opinion, what are the strengths and weaknesses of React

It is my first time learning React. I have been working in the back-end, so I don't really get to see what the front-end does besides what they share in scrum meetings. What I enjoyed the most while writing React features was the ability to see how the back-end is running in the background while the front-end is running separately with the `npm run dev` command, but together they make together an app. Without the front-end an user can't really use an app, and without the back end, the UI acts like decoration but with no functionality. The beauty of it to me is how they depend on each other and how they both make an app function. As far as weaknesses, I think the fact that we need to import external packages and does no thave built-in tools for routing, state management, or API calls, and if a package becomes deprecated this might be time-consuming to keep updating it. Another weakness I see is how React re-renders the interface when data gets updated or when it changes. Sometimes this could be unnecessary when one change can make a whole re-render to load again. Overall, I enjoyed learning React.

SWE - Week 1

Software Engineering - CST438

Week1

What did you expect a course in Software Engineering would cover?   

So I am currently interning at a Defense company as a Software Engineer, and I was so surprised to learn that we were going to be learning Spring Boot because this is what I currently use every day at work, I did not expect that. I am supporting a team in the backend, and I've been learning Spring Boot, OpenAPI, and some of the frameworks that Spring offers. The first lab was the intro to what I do at work, and I am very happy that what we are learning in this class is actually very related to the current industry. With Spring Boot, we can avoid all the boilerplate code and simplify the use of RESTful APIs. At work, we use Kubernetes for deployment, Redis for caching, Kafka topics for data records where producers write the events and consumers read the stream of data. I am looking forward to learning more and collaborating with my teammates.

Service Learning CST462S

 Reflection:

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?

The results we obtained after we finished the service project hours, is what went well. I was able to deliver a step-by-step manual of how to list and ship items on eBay for the non-profit organization Homeless to Forever. They were very grateful to how much we helped them understand from a non-technical side how to run their shop without having to face so many technological challenges. This goes in hand with this being the most impactful action we did too. They expressed they have been looking for these kind of results for over a year but no volunteer/intern has been able to achieve this. The challenges I achieved were in the beginning of the service project, our supervisor did not have the technological tools and the time to provide us with the work to do, so it was very challenging to follow up with her so we can get hours up to speed and not to fall behind. The best advice I have for future SL students is actually keeping very throughout communication with their supervisor so both parts know each other's expectations.

Week 7

 Week 7 (2/18-2/24)

This week's content had a lot of topics and algorithms to cover. These are some of the concepts I learned this week:

Counting Sort: Count how many times each value appears (frequency), then build the cumulative distribution to place items in sorted order.

Radix Sort (LSD): Sort numbers digit by digit starting from the least significant digit (ones place), using a stable sort each pass.

Dynamic Programming (DP): Solve problems by storing results of smaller subproblems and building up to the final answer.

Coin-Collecting Problem: In a grid, find the maximum coins collectable when moving only right or down using a DP table.

Coin-Row Problem: Choose coins in a row to maximize value without taking adjacent coins

Warshall’s Algorithm: Finds the transitive closure of a graph (reachability: whether a path exists between vertices).

Floyd’s Algorithm: Finds all-pairs shortest paths by updating distances with intermediate vertices.

Greedy Method: Build a solution step by step by always choosing the best local option at the moment.

MST (Minimum Spanning Tree): Connect all vertices in a weighted graph with the minimum total edge weight and no cycles.

Prim’s Algorithm: A greedy MST algorithm that starts from one vertex and repeatedly adds the smallest edge connecting the current tree to a new vertex (weights matter first; alphabet only breaks ties).

Week 6

 Week 6 (2/11-2/17)

For this week, we practiced AVL trees by inserting values and fixing balance with rotations. We did 2–3 trees by inserting keys, splitting 3-nodes, and reading results level-by-level. We worked with max heaps: inserting (bubble/sift up), deleting max twice (swap with last, sift down), and connected this to heapsort and the array/bottom-up heap build method. Finally, we covered hashing: using 𝐾 mod 𝑚, detecting collisions (separate chaining), resolving them with linear probing, and using load factor thresholds to trigger rehashing to a larger table size. Going to office hours has been extremely helpful for me in this class to better grasp the concepts.

Week 5

 Week 5 (2/4-2/10)

I made a little summary based on what I learned this week's content. I am hoping that this summary helps me to study for the final.

QuickSort:

QuickSort is a divide-and-conquer sort. It picks a pivot, then partitions the list so numbers smaller than the pivot go left and numbers bigger go right. After the first partition, QuickSort recursively sorts the left and right parts.

Partitioning (i and j pointers):

You keep moving i from the left (looking for a number too big) and j from the right (looking for a number too small), in other words, i moves from the left until it finds a value > pivot (too big, belongs on the right). j moves from the right until it finds a value < pivot (too small, belongs on the left). Then you swap those two.

When i and j cross, you swap the pivot into its final spot. 

Median-of-Three Partitioning:

This improves QuickSort when the data is already sorted or reverse-sorted (which can make QuickSort slow). It chooses the pivot as the median of (first, middle, last), then does partitioning using that pivot idea. Also, we can’t use median-of-three when a subarray is size 3 or less.

Binary Tree Traversals:

Traversal is just “the order you visit nodes”:

Preorder: root, left, right

In order: left, root, right

Postorder: left, right, root

Binary Search:

Binary search works on a sorted list. You check the middle value, then go left half or right half depending on whether the target is smaller or bigger. Each step cuts the search space in half, so it’s fast (log time).

DAG and Topological Sorting:

A DAG is a directed graph with no directed cycles.

A topological order is a list of nodes where every arrow goes from earlier to later. If there’s a cycle, you cannot do a topological sort.

Kahn’s Algorithm:

finds nodes with in-degree 0 (no incoming arrows), removes one (using alphabetical order when there are ties), updates in-degrees (depending on incoming arrows), and repeats.

Week 4

 Week 4 (1/28-2/3)

Besides studying mainly for the midterm, this week's content was focused on merge sort. Merge sort is a clear divide-and-conquer method: split the array, sort each half, then merge them back in order. It runs in O(n log n) time, is stable, and works well for large data. The tradeoff is that it needs extra memory for merging, so it’s often used when predictable performance matters most. As always, office hours help me to clarify all my questions and to have a wider view of the theory and the logic. Looking forward to the next half of the class.

Week 3

 Week 3 (1/21-1/27)

This week's content was very interesting to me. Brute Force, TSP, Knapsack, Divide & Conquer, Master Theorem, and Depth-First Search and Breadth-First Search Algorithms were the main concepts for this week. I personally found DFS and BFS the most interesting ones, not just because of the development of their graphs but also because of the logic behind them and their functionality in different situations. DFS plans to go deep in a node (vertices) and backtracks when it gets stuck. Meanwhile, BFS plans to identify each neighbor's node first before moving on. TSP and Master Theorem were both easy to understand for me because it is very clear the time efficiency for them, especially in real world's cases. 

I am actually looking forward to next week's content and apply these algorithms in more advanced settings.

Week 2

 Week 2 ( 1/14-1/20)

This week's content was very math-oriented. Out of all topics, recursive and nonrecursive algorithms, use cases of Theta notation, recurrence relation, and backward substitution, and brute force algorithm, the topic I had the most trouble with was backward substitution. It is good practice to look at different examples to see this algorithm from different perspectives. I attended office hours, which helped me quite a lot. I compare this algorithm to proof by induction in math classes, showing the steps to identify a pattern that eventually leads to the general formula or equation needed to understand the recurrence relation and the initial condition. Below is the example I was having trouble with, along with how each step helped me identify the general number i.

M(n) = M(n-1) + 2 // recurrence relation

As an initial condition, we know that if the input number n is 1, there is no multiplication. We can express it as follows.

M(1) = 0 // initial condition

We can solve the recurrence relation using the backward substitution as below

M(n) = M(n-1) + 2 // replace “M(n-1)” with “M(n-2) +2”

                   = [M(n-2) + 2] + 2

        = M(n-2) + 2 + 2 // replace “M(n-2)” with “M(n-3) +2”

        = [M(n-3) + 2] + 2 + 2

        = M(n-3) + 2 + 2 + 2

…

        = M(n-i) +2*i // For a general number i, we will get this.

...

        = M(1) + 2*(n-1) // Note that the initial condition M(1) = 0.

        = 0 + 2*(n-1)

        = 2*(n -1) (n)

Week 1

 Week 1: Algorithms

This week, I learned pseudocode, GCD, graphs, trees, and the algorithm analysis framework. The book has been a great resource for understanding the content before watching the lectures. What I had the most trouble with was the basic operation. I thought the basic operation was only one: the most used operation in an innermost loop to measure the efficiency of the algorithm, but then I learned that there is not only one basic operation. Sometimes, there are a few operations that depend on each other in the same innermost loop, and together they determine the performance needed for the loop to execute its full cycle.

As an example, from the algorithm analysis framework, the pseudocode Display_2D_Stars:

1. Algorithm Display_2D_Stars (n)

2. // Input: A positive integer number n

3. // Output: Display the * symbol in two dimensions.

4. i ← 0             

5. while ( i < n ) do

6.     j ← 0

7.     while ( j < n ) do

8.         write '*'  

9.         j ← j + 1

10.     write '\n'

11.     i ← i + 1    

12. return 0

Lines 7, 8, and 9 are part of the same innermost loop; lines 8 and 9 depend on the execution of line 7 (the execution difference is small compared to the < operation ). Therefore, all operations on lines 7, 8 and 9: <, write and +) are part of the basic operations.

Week 8

 Week 8 (8/13-8/15)

This week I want to make a reflection of all the topics and challenges faced throughout these 8 weeks, since in my last journal, I already talked about this week's content: persistence. Before starting this class, I was apprehensive, especially when I learned we would be working with C. I had always heard that C is low-level, unforgiving, and complex compared to higher-level languages I’ve used before. Since I have been leaning toward career paths like cybersecurity or data science, I was more comfortable with analysis than raw systems programming. 

One of the most challenging topics for me was CPU scheduling, particularly the Round Robin algorithm. Implementing time-slicing logic while maintaining correct queue order required a precise understanding of process states and context switching overhead. I iterated through several incorrect solutions before finally deriving a correct implementation after a teammate shared his approach via a recorded walkthrough.

Collaboration and teamwork were essential throughout the course. Each of my team members had strengths in different OS concepts, and knowledge sharing allowed us to fill each other’s gaps. For example, I created a video explaining FIFO, LRU, and Belady’s Anomaly in caching policies, which I had mastered after repeated simulation exercises. In return, a classmate helped me understand segmentation and memory protection mechanisms.

Persistence mechanisms were also challenging, particularly concepts like hard drive rotation and inode-based indexing. Understanding the relationship between rotational delay, seek time, and data transfer rates, along with inode-based metadata and pointer structures, required deep reading. I struggled partly due to limited study time while balancing my internship workload, where I was finalizing deliverables for my project.

For our final project, my team explored Triangulating Python Performance Issues with SCALENE. While I understood SCALENE’s ability to profile CPU, memory, and GPU usage simultaneously, the hardware test bench—an 8-core 4674 MHz AMD Ryzen 7 with 32 GB RAM and an NVIDIA GeForce RTX 2070 running Linux—required me to contextualize performance data in terms of underlying hardware capabilities.

Overall, this course strengthened my understanding of OS fundamentals—process scheduling, memory management, file systems, and performance analysis—while reinforcing the importance of collaborative problem-solving. Thanks to Dr. Ogden for making this class super interesting and for being one of the best professors I've had so far in the program.

Week 7

 Week 7 (8/6-8/12)

This week, we covered persistence. From I/O Devices, I learned that devices can be block (e.g., hard drives, storing fixed-size blocks with random access) or character (e.g., keyboards, handling byte streams). The OS interacts with them via registers—status, command, and data—using polling, interrupts, or Direct Memory Access (DMA). Device drivers isolate OS code from hardware specifics.

From Hard Drives, I discovered that performance depends on rotational delay, seek time, and transfer time. For example, reading 2 MB with a 4 ms rotational delay, 5 ms seek time, and 100 MB/s transfer rate takes 29 ms. Sequential workloads are much faster than random ones, and I/O scheduling (e.g., SSTF, elevator) reduces unnecessary head movement.

From Files and Directories, I learned that files are linear byte arrays with metadata in inodes, while directories map names to inode numbers. Hard links point multiple names to the same inode; symbolic links are files containing paths to targets. Mounting attaches a filesystem to a directory in the system tree, unifying access.

From File System Implementation: Data, I saw that a filesystem uses disk blocks for data, inodes, bitmaps, and a superblock (global info). Inodes store file type, size, and pointers—direct, indirect, or double indirect—to data blocks, enabling large files. Directories are just files containing (name, inode) entries.

From File System Implementation: Access, I learned how to traverse the directory tree to access /foo/bar: starting at the root inode, reading directory blocks to find each component, then retrieving the file’s inode and data blocks. The VSFS simulator showed how operations like mkdir(), creat(), link(), and unlink() change inodes and bitmaps. For example, creating a hard link adds another directory entry to the same inode without duplicating data.

Week 6

 Week 6 (7/30-8/5)

In this week’s readings, PA5, lectures, and quizzes, I learned how condition variables and semaphores are used to manage synchronization in multi-threaded programs. As an example of this, I learned that a condition variable lets threads wait efficiently for some condition to become true, like waiting for a buffer to be non-empty before reading. The Anderson/Dahlin method showed how to design shared objects safely by first building basic object-oriented code and then adding one lock, condition variables, and wait/signal logic in a step-by-step way. This helped me understand how to write safer and more precise threading code, such as in a simple producer-consumer buffer.

I also learned how semaphores can be used for the same types of problems, like enforcing mutual exclusion or synchronizing multiple threads at a barrier. Unlike condition variables, semaphores are more powerful but also more complex—they combine locking and signaling in one tool. For example, to solve the rendezvous problem (where threads must wait for each other), I saw how to use two semaphores to make sure both threads complete the first step before moving on. In the synchronization barrier problem, I learned that we can count how many threads have arrived and use a turnstile pattern (wait then signal) to let all threads through. These examples made abstract ideas more concrete for me.

This week's concepts helped me understand the overall idea of concurrency, especially how to coordinate and manage access to shared resources safely and correctly, which is a key challenge in modern operating systems.

Week 5

 Week 5 (7/23-7/29)

This week, I learned in OS that concurrency means letting different parts of a program make progress “together.” I also learned that threads are light‑weight units of execution inside a process, which share memory but each has its own stack and registers. For example, two threads updating a shared counter can cause problems if they both do counter = counter + 1 at the same time.

I also learned that a race condition happens when threads access shared data without coordination, and the result depends on timing. I learned that a critical section is the code that touches shared data, and that a mutex lock ensures only one thread enters at a time. I learned that locks rely on atomic instructions like test‑and‑set to flip a flag in one step without interference.

Another thing I learned about the pthreads API: pthread_create lets me start a thread, pthread_join waits for it to finish, pthread_mutex_lock and pthread_mutex_unlock guard critical sections, and pthread_cond_wait and pthread_cond_signal let threads sleep and wake up based on conditions.

I also learned that I can make a simple counter safe by putting a mutex inside a struct and locking it around increment and get operations. The coarse‑grained locks are easy to write but slow down all threads, while fine‑grained locks let more threads work in parallel but are harder to code.

I finally learned that concurrency helps in real programs like browsers, where one thread loads images while I type in another. I learned that balancing safety and speed means choosing the right locking level for your data structures.

Week 4

 Week 4 (7/16-7/22)

This week's content was very interesting; the labs were particularly helpful in simulating the methods. I learned several memory management methods used by operating systems: paging, Translation Lookaside Buffers (TLBs), multi-level paging, and swapping.

Paging splits virtual memory into fixed-size blocks called pages. It avoids memory fragmentation and simplifies memory allocation. Each virtual address has a virtual page number (VPN) and an offset. The page table translates VPNs into physical page numbers (PFNs). However, paging can be slow and needs large tables, making it less efficient.

To speed things up, a Translation Lookaside Buffer (TLB) caches recent VPN to PFN translations. This cache exploits the fact that programs often reuse the same memory areas repeatedly, a phenomenon known as locality. Using a TLB significantly reduces the average memory access time.

Multi-level paging solves the issue of large page tables. It breaks the page table into smaller chunks, storing only necessary parts. A page directory points to these smaller page tables. While this saves memory space, it makes address translation slightly more complex.

Swapping happens when there's not enough physical memory (RAM). Less-used pages are temporarily moved from RAM to disk. When a needed page isn't in memory, a page fault occurs, prompting the OS to bring the page back from disk. Different policies, such as Least Recently Used (LRU), First-In-First-Out (FIFO), Random, or Optimal (Belady’s policy), determine which pages to swap out. I personally struggled more with Belady's policy, so I had to practice that specific method a bit more to get it right. These methods help manage memory efficiently, balancing speed and resource usage.

Week 3

 Week 3 (7/9-7/15)

What did I learn this week in CST 334?

I learned different concepts this week. The book and lectures teach how computers use virtual memory to let each program act like it has its own private memory, even though all programs share the same physical RAM. This is done through a system of address translation, where virtual addresses (used by programs) are converted into physical addresses (used by the hardware).  One method is base-and-bounds, where each process is assigned a block of memory, and hardware checks ensure it stays within limits. A more flexible method is segmentation, which breaks memory into parts like code, stack, and heap with their own base and size, allowing for better protection and organization.

The book, lecture videos, and assignment for this week include simulations showing how virtual addresses are split and mapped to physical memory, making concepts like translation clearer. They also explain address spaces, which are the ranges of addresses a process can use. Each process has its own address space to prevent interference. To manage memory efficiently, the operating system uses free space management techniques. These include first fit (choosing the first block big enough), best fit (choosing the smallest block that fits), and worst fit (choosing the largest block to avoid leaving tiny gaps). These strategies help reduce wasted memory and prevent fragmentation, when free memory is split into unusable pieces. The chapters and assignments also discuss how malloc() and free() in C are used to request and release memory manually, and the risks of doing so incorrectly, such as memory leaks. Overall, this week's content builds a strong foundation for understanding how the OS manages memory safely, efficiently, and fairly among processes.