Suhaib's CS Journal

Week 7 Reflection: Agile and Plan and Document are two different approaches to software development. Agile uses short iterations and allows requirements to change throughout the project based on customer feedback. Design, coding, and testing are done repeatedly during each iteration. Plan and Document, or Waterfall, follows more structured phases such as requirements, design, coding, and testing. It relies more heavily on detailed documentation and planning before development begins. Agile is more flexible, while Plan and Document is better when a project needs a clear schedule, cost estimate, and well defined requirements from the start.

Week 6  This week, I learned more about how modern computing systems are managed efficiently. One thing that stood out to me was how much automation is used to keep services running without constant human attention. I also gained a better understanding of why containers are so useful, especially because they can start quickly and use fewer resources than traditional virtual machines. Another important idea was designing jobs so they can recover from failures instead of starting over completely. This week helped me see how cloud systems are built to be reliable, flexible, and easier to manage.

Week 5 Learning Journal: This week, I learned about large-scale testing and how it differs from unit testing. I also learned about the importance of realistic test data, proper system configuration, and clear ownership of tests. Canary testing and A/B testing showed me how organizations like Google can test changes safely and identify problems before releasing them to everyone. In our group project, our team completed Iteration 2 by reviewing code, merging pull requests, fixing issues found during testing, responding to reviewer feedback, and verifying that the frontend, backend, and database worked together correctly. We also used Git branches, commits, pull requests, and team communication to coordinate our work. I also learned that Agile practices such as assigning priorities and estimating tasks with points are very useful because they help the team understand which work is most important, compare the size of different tasks, and divide the workload more fairly. My main takeaway is...

Week 4 Journal: What is the most interesting thing you have learned in your reading of "Software Engineering at Google"? The most interesting thing I learned from Software Engineering at Google was that code reviews are not just about checking whether code works. They also make sure the code is understandable, maintainable, and easy for the rest of the team to work with. This relates to the group project we are doing right now in this class because we are using GitHub branches and pull requests to combine everyone’s work. When I pulled the latest changes from the main branch, I saw how much code from different teammates had been added to the student controller files. That made me understand why Google uses peer engineers, readability approvers, and code base owners during reviews. Having different people check the code can make it clearer and easier to maintain, especially if the original person who wrote it is no longer available.

 Week 3 Learning Journal -  Before I started using Git, I would make a bunch of backup copies of my files whenever I changed something. I had to keep renaming them with things like “final,” “final2,” or “working version,” and it became confusing to remember which file matched each stage of the project. Git handles that much better by saving organized commits, keeping a history of changes, showing who changed what, and letting developers work on separate branches. It also makes it easier to undo mistakes, compare versions, collaborate, and review code before combining it. However, Git merge only combines file changes. It cannot determine whether two developers’ code actually works correctly together. A merge may finish without conflicts but still introduce bugs, break business rules, create inconsistent designs, or cause one feature to interfere with another. Git also cannot resolve disagreements about requirements, architecture, naming, or which implementation is better. Deve...

Learning Journal Week 2: This week I learned how React can be used to build the frontend for a full customer order application. I worked with components such as Login, Register, Order, OrderHistory, EditOrder, and Settings. I learned that React applications are organized into smaller pieces, and each component is responsible for one part of the user interface. I also learned how useState helps keep track of changing data, such as form inputs, messages, and order information. React Router was useful for creating different pages in the same application, including login, register, order, history, and settings. The lab also showed me how the frontend connects to the Spring backend using fetch requests, JWT tokens, and session storage. One strength of React is that it makes the page feel more interactive without constantly reloading the whole website. For example, the order history table and edit dialog could update based on user actions. Another strength is that reusable components, lik...

Learning Journal Week 1: Before this course, I expected Software Engineering to mostly be about writing code and learning how to build bigger programs. I thought the class would focus mainly on programming, using tools, and maybe working on projects like a real software developer. After completing week 1, my opinion has changed because I realized Software Engineering is more than just coding. It also includes planning, testing, debugging, security, APIs, and making sure software is reliable and maintainable. The labs showed me that writing the code is only one part of the process. Testing the code and proving that it works is just as important. I also learned that software engineers need to think about how different parts of an application connect, like controllers, repositories, databases, and security. I now see Software Engineering as a process for building software correctly, not just getting something to run.

Learning log week 7: This week we covered encoding categorical variables, logistic regression, and overfitting. I learned that categorical variables need to be changed into numerical values before most machine learning models can use them. One hot encoding made sense to me because it creates separate columns for each category instead of assigning numbers that could accidentally suggest an order. Logistic regression was a little confusing at first because the name sounds like it should predict a numerical value, but it is actually used for classification. I understand now that it predicts the probability of an outcome, such as whether a customer will churn or not. I still want more practice interpreting the coefficients and understanding exactly how they affect the predicted probability. The topic of overfitting also stood out to me. A model can perform very well on the training data but still perform poorly on new data. This helped me understand why we need test sets and cross valida...

Learning Log | Week 6 This week we learned about hyperparameter tuning, KNN regression, linear regression, and how to evaluate regression models. Hyperparameter tuning helped me understand that some model settings are chosen before training and that the best values depend on the dataset. Grid search seems useful because it tests different combinations in an organized way, but I still wonder how to choose a reasonable range of values without testing too many combinations. The difference between KNN regression and linear regression was also interesting. KNN uses nearby training examples to make predictions, while linear regression learns coefficients that describe the relationship between the predictors and the target. Linear regression seems faster when making predictions, but it may struggle when the relationship is not close to linear. The hardest part for me was interpreting regression errors and predicted versus actual plots. I understand that lower MSE and MAE values are better, ...

Learning log 4: This week we learned more about how important preprocessing is before building a machine learning model. One thing that stood out to me is that missing data is not always obvious. Sometimes it shows up as actual NA values, but other times it can be hidden as values like 0 or “information requested,” depending on the dataset. That made me realize that cleaning data is not just a technical step, but also requires thinking carefully about what the values actually mean. I also learned why scaling matters, especially for models like KNN. Since KNN uses distance to compare points, features with larger numbers can have too much influence if the data is not scaled. This helped me understand why preprocessing and modeling are connected instead of being separate tasks. The test/train split and cross validation topics were useful too. I understand that the test set should be saved for checking how well the model works on new data, while cross validation helps compare models or hyp...

Learning log 4: This week I learned more about how to compare two discrete or categorical variables, especially using statistics and visualizations. One thing that stood out to me was how useful crosstabs are for organizing categorical data. Before this, I mostly thought about looking at one variable at a time, but now I can see how comparing two variables can show patterns that are not obvious at first. I also learned that choosing the right kind of plot matters a lot. For example, bar plots are useful for categorical variables, and grouped or stacked bar plots can help compare categories across another variable. I am starting to understand why we should think about the type of variables first before choosing a visualization. Something I am still trying to get better at is knowing when to use counts, fractions, or percentages. Sometimes the code is not too hard, but deciding what the graph should actually show is harder. I also want more practice with crosstabs and the normalize opt...

Learning log 3: This week I learned more about how to describe and visualize different types of variables. A lot of the week focused on continuous variables, like using density plots, histograms, and box plots to understand the shape of data. I also learned that the way you choose bins in a histogram can change how the distribution looks, so graphs are not just automatic answers. They need choices that make sense. The famous distributions topic helped me see why distributions matter in data science. The normal distribution is starting to make more sense, especially the idea of mean, standard deviation, and how values are spread out. I still find probability density a little confusing because the y-axis is not exactly a probability by itself. I understand that the area under the curve matters, but I need more practice with that idea. For two continuous variables, correlation and visualization were useful because they show how two things can move together. I understand that correlation...

Learning log 2: This week I learned more about pandas and how it is used to work with data in a more organized way. Last week we used NumPy arrays, but this week pandas Series and DataFrames made the data feel easier to understand because the rows and columns can have labels. I learned that a Series is like one column of data with an index, while a DataFrame is like a full table with rows and columns. One topic that made more sense after the labs was indexing. With a pandas Series, I can use dictionary style indexing like mpg['Ana'] , or I can use .loc to get values by label. With DataFrames, I practiced getting columns, rows, and specific values. I also learned that pandas lines up data by index, not just by position. That was important in the series lab because one student was missing from the distance data, so pandas returned NaN for that calculation. I also learned about aggregation, which seems like one of the most important skills so far. Simple aggregation uses func...

Learning log 1: This week I learned the basics of the course, the homework policy, and how Python is used in data science. The biggest topic for me was NumPy. I learned that NumPy arrays are useful because they make it easier to work with a lot of numbers at once. Instead of writing loops for everything, I can use vectorized operations like tuition > 12000 or x * 10, and NumPy applies it to the whole array. One thing that made more sense after doing the labs was slicing versus fancy indexing. Slicing is like x[:3] or x[-3:], where I am taking a range of values. Fancy indexing is when I choose specific positions, like x[[0, 2, 4]]. At first these felt similar, but now I see that slicing is more about a continuous section and fancy indexing is more about picking exact values. Boolean masks were probably the most important idea for me this week. A mask is an array of True and False values that can filter another array. For example, tuition[tuition > 12000] gives only the tuition val...

Service Learning Journal Reflection Overall, my service learning experience went well and felt very relevant to my major. I was able to apply my computer science skills to a real organization by building automation scripts that reduced manual administrative work. One of the most successful parts of the project was developing solutions that improved efficiency in data handling and reporting. Seeing how automation could directly save time and reduce errors made the work feel meaningful and impactful. If I were to improve anything, it would be communication and collaboration throughout the project. Since I completed the work mostly independently, there were fewer opportunities for regular feedback. More consistent check-ins could have helped align development more closely with the organization’s evolving needs and possibly expand the scope of the project further. The most impactful part of this experience was realizing how technical skills can be used to support real-world organization...

Week 7 Learning Journal -  This week focused on advanced algorithm design techniques including non comparison sorting, dynamic programming, and graph algorithms such as Warshall’s and Floyd’s algorithms. I learned how algorithm efficiency changes depending on the approach used. For example, Counting Sort achieves linear time by avoiding comparisons, and Dynamic Programming reduces repeated computation through optimal substructure. In our group bonus project, we also applied algorithmic efficiency principles. For example, we used an unordered_map for fast keyword searching with average constant time lookup. We also used a priority_queue to efficiently rank bookmarked verses. Even though we did not actually code dynamic programming or graph algorithms in our project, working on it still made me think more about why choosing the right data structure matters. When we picked unordered_map and priority_queue, I could clearly see how much easier and faster certain operations became compar...

Week 6: This week focused on balanced search structures and priority based structures. At first AVL trees were confusing, especially keeping track of balance factors after each insertion. After doing several rotation examples, I started noticing patterns in the cases instead of just memorizing steps. Some insertions only needed a quick fix, while others required adjusting two levels of the tree. It started to make more sense when I followed the height updates step by step from the leaf up to the root. After that, 2 3 trees felt like a shift in thinking because instead of rotating nodes, the structure avoids imbalance by storing more than one key in a node. That contrast helped me see that both methods are trying to keep searches fast, just in their own way. Heaps and heapsort clarified how the heap property supports efficient removal of maximum elements and sorting in place. Finally, hashing introduced constant time access ideas, along with handling collisions and load factor considera...

Week 5: This week focused on core algorithm design ideas and how they are applied in practice. I learned how Quick Sort works step by step. Particularly how partitioning affects performance and why the median of three approach helps reduce worst case behavior. The binary tree lectures helped me clearly understand preorder, inorder, and postorder traversal, along with how tree height is calculated. Decrease and conquer made binary search easier to reason about by breaking problems into smaller parts. I also learned how DAGs and topological sorting work, with Kahn’s algorithm showing a clean and logical process. Pre sorting showed how preparation can simplify complex problems. The materials this week connected theory with real algorithm behavior in a clear way.

Week 4 This week we learned MergeSort and divide and conquer. We split the array into smaller parts until there is one element and then merge everything back in order. Once I followed the steps slowly it made sense. MergeSort always runs in Theta n log n which makes it efficient. While reviewing for the midterm I realized I messed up because I rushed. I missed questions about when Theta notation can be used, how to count comparisons in recursive functions, and how backward substitution works. Getting those wrong showed me I need more practice and I need to slow down during exams instead of guessing when I don't fully understand something.

 Week 3: This week we covered different algorithm design techniques and how they behave in terms of efficiency. Brute force string matching helped me see why checking every possibility becomes slow as input size grows. The exhaustive search examples, especially TSP, showed how permutations guarantee correctness but don’t scale well. I also learned how DFS and BFS work, how traversal order matters, and how to analyze recursive algorithms using divide and conquer and the Master Theorem.

Week 2: This week focused on analyzing algorithm efficiency using asymptotic notations such as Big O, Theta, and Omega. I learned how to formally and informally describe time efficiency and applied these ideas to nonrecursive and recursive algorithms using loops and recurrence relations. The brute force design lecture helped me understand when simple approaches are acceptable and when they become inefficient. The puzzles, especially the clock hands problem, helped connect algorithmic thinking to real situations.

 CST 370-30 - Algorithm Design & Analysis Week 1 This week in CST 370, we went over the basics of algorithm design and analysis and what to expect from the course. A big focus was on understanding how to think about problems in terms of best case and worst case scenarios, not just getting an answer. We worked on logic puzzles like the fake coin and ball matching problems, which helped me see how algorithms can be about strategy and guarantees rather than code. These problems showed how careful reasoning can minimize steps while still covering all cases, which I think will be important later in the class.

Week 8 Overview: This final week combined advanced routing concepts with hands-on work through Programming Assignment 4, which expanded our network simulation and programming skills. The first part involved creating a custom Mininet network with multiple routers, switches, and hosts, manually configuring IP addresses, static routes, and verifying full connectivity using pingall and dump commands. This deepened our understanding of routing tables and network configuration. The second part extended our TCP chat service from the previous assignment into a group chat system supporting three clients simultaneously. We integrated this chat setup into the Mininet topology so each host could communicate with the server in real time. I also produced a narrated demo video showing message exchange and graceful exits. This week tied everything together: networking theory, routing logic, and socket programming, rounding out the course with a strong mix of conceptual and practical skills.

Week 7 Overview: This week shifted focus to the control plane of the network layer, which governs how data paths are chosen and managed. We studied routing algorithms, specifically link-state (Dijkstra) and distance-vector (Bellman-Ford) methods, learning how routers exchange information and compute optimal paths. The lectures and practice problems helped visualize how these algorithms dynamically adapt to network changes. We also learned about intra-domain routing (like OSPF) and inter-domain routing (like BGP), which manage routing within and between networks. The quizzes and assignments strengthened our understanding of route calculation, convergence, and how control-plane logic differs from data forwarding in the data plane. This week emphasized how routers “think,” not just how they move packets.

 Week 6 Overview: This week wrapped up the data plane and focused heavily on Programming Assignment 3, where we created a TCP-based chat service. We built both the server and client programs to enable two-way communication over reliable TCP connections. The project introduced multithreading, allowing simultaneous message sending and receiving between multiple clients, which made the chat feel more realistic. Everything was tested in Mininet with three hosts simulating a small network setup. For extra credit, I extended the program by adding username functionality, letting users identify themselves instead of generic client names, and implemented offline messaging, where messages sent before another client connects are stored and delivered once they join. These additions made the chat system more dynamic and closer to real-world applications. This week really tied together everything about TCP reliability, sockets, and concurrent programming in a practical, hands-on way.

 Week 5 Overview: This week introduced the network layer’s data plane, focusing on how packets are forwarded from source to destination across networks. We studied the role of routers, packet switching, and datagram forwarding, as well as the structure of the IP header and how IP addressing works. A major topic was subnetting, learning how to divide IP address spaces efficiently and NAT (Network Address Translation), which allows multiple private devices to share one public IP. The Wireshark IP and NAT labs gave us hands-on experience capturing and analyzing packets to see how IP addresses change through routers and NAT devices. Through the quizzes and practice problems, we became more confident reading IP headers, identifying subnet masks, and understanding how routing decisions are made inside the network layer.

Week 4 Overview: This week expanded on TCP and UDP concepts through both theory and programming practice. We learned how TCP ensures reliable communication using sequence numbers, acknowledgments, retransmissions, and congestion control. These ideas connected directly to Programming Assignment 2, which focused on developing two UDP-based client-server applications in Python. In Part 1, we built a UDP Ping Service to simulate sending and receiving packets while handling timeouts and calculating round-trip times. The server introduced artificial packet loss to show the unreliability of UDP, while the client measured packet loss rates and RTT statistics. In Part 2, we created a UDP Heartbeat Service, where the client periodically sent heartbeat messages with sequence numbers and timestamps. The server logged missing or received messages to track reliability. Running both applications in Mininet reinforced how real-world networking handles packet transmission, timing, and loss across unrel...

Week 3 Overview: This week introduced the transport layer, focusing on how data moves between applications running on different hosts. We covered the core concepts of multiplexing and demultiplexing, which allow multiple applications to share the same network connection while keeping data organized. The lectures also went over UDP, the connectionless protocol known for its simplicity and speed, but lack of reliability. Through quizzes and examples, we learned how UDP works in practice, including checksum calculations for error detection. The Wireshark TCP lab previewed what we’d dive deeper into next week, giving us a look at how TCP segments appear in real network captures. Overall, this week built a strong understanding of how transport protocols serve as the middle layer between applications and the network core.

Week 2 Overview: This week focused on the application layer, where user-level network programs operate. We learned the principles behind network applications, like how clients and servers communicate through sockets using established protocols. The lectures went deep into HTTP, explaining how web browsers and servers exchange data through request and response messages, covering topics like persistent vs non-persistent connections and status codes. We also explored the Domain Name System (DNS), understanding how human-readable domain names are translated into IP addresses through hierarchical servers. The labs were very hands-on: in Wireshark HTTP, we analyzed browser-server communication, while in Wireshark DNS, we captured and examined DNS query and response packets in real time. Together, this week tied theory and practice, showing how core Internet applications actually function behind the scenes. A major part of this week was Programming Assignment 1, where we practiced socket prog...

Week 1 Overview:  This week introduced the fundamentals of computer networking and how the Internet actually works. We started by defining what the Internet is and understanding protocols as the rules that allow systems to communicate. The lectures explained the network edge, the devices and access networks that connect users, and the physical media that carry data. We also explored the network core, comparing packet switching and circuit switching, and how data moves through different layers of the Internet’s structure. A key focus was on performance concepts like delay, loss, and throughput, which affect how efficiently information travels. The chapter closed with an overview of protocol layering and Internet service models, setting the stage for everything else in the course. Lastly, we touched on network security and how vulnerabilities can be exploited. The lab with Wireshark gave hands-on experience observing real network traffic.

Week 8 (Final Week) CST 334 - Before this class, I honestly never thought twice about what happens when I save a file or open a folder. You just click and it is there. That was all I cared about, but after learning how it all works I can’t really unsee it. Now I picture all these little pieces like the pointers, the metadata, and the blocks moving around in the background getting everything where it needs to be. It makes everyday computer stuff feel a lot less mysterious and very cool. One of my challenges were when I first started the disk I/O counting problems, I was a mess. I was skipping steps without noticing or I would double count something and then end up with totals that made no sense. It was kind of annoying especially because I thought I understood the process. Turns out I didn’t, at least not completely. After running through the practice quizzes over and over, something finally clicked. I began to see the steps in my head without forcing it and the numbers actually came ou...

Week 7 Summary: This week in CST 334, I learned in depth about how file systems are organized on disk and how they are accessed by the operating system. The lectures broke file systems into two main parts: the on-disk data structures (like the superblock, inodes, data blocks, and bitmaps) and the access methods used to navigate those structures to find and read files. I now have a much clearer picture of how the superblock acts as a “map” to the file system, pointing to where the inode region and data blocks begin, and how inodes store file metadata and pointers to data blocks. Bitmaps turned out to be an efficient way of tracking which inodes and blocks are free or used, reducing the need to scan every single block. We also discussed how files use direct, single indirect, and double indirect pointers to scale up file sizes, and how directories are simply files with structured data that map names to inode numbers. In the access portion of the lectures, I learned the step-by-step proces...

Week 6 Overview: This week in CST 334 felt like everything I’ve been learning about threads and synchronization finally came together. We didn’t have actual coding assignments for the lectures on the Bounded Buffer (OSTEP 30a), Semaphores (OSTEP 31), and Synchronization Barriers (OSTEP 31a), but we dove deep into how all these concepts work behind the scenes. It was honestly helpful to slow down a bit and focus more on understanding the patterns and problems before jumping straight into code. The lectures on the Bounded Buffer really helped clarify how semaphores control access between producers and consumers, and how you can use just a few semaphores to avoid race conditions and deadlocks. It made me realize how important the order of operations is when multiple threads are sharing data. The semaphore lecture helped things click a bit more for me. I’ve come across wait() and signal() before, but I always kind of just accepted them without fully grasping why they were used the way they...

Week 5 Overview: This week in CST 334, I learned a lot about locks and concurrency. The most interesting part was understanding how different types of locks work especially spin locks vs ticket locks. At first, I thought all locks were the same, but now I see how much design actually matters. Spin locks are simple but waste CPU cycles under high contention. Ticket locks are smarter. They use a “take-a-number” approach, which makes things more fair and avoids starvation. We also learned about hardware instructions like test-and-set and compare-and-swap. These are used to build locks at a lower level. It really showed me how messy things can get when threads share data without proper coordination. Even a small race condition can lead to unpredictable bugs. We also had the midterm this week, which was honestly rough. The one-hour time limit was tight, and it felt super rushed, especially since we’ve had unlimited time on quizzes before. Some of the questions were a lot harder than expecte...

CST 334 Week 4: This week was honestly a bit of a grind, but I learned a lot. We were working on virtual memory and page tables stuff I’ve heard of before but never actually had to code myself. The main task was writing a function that maps a virtual page to a physical one, while setting all the right permissions like read, write, and execute. Sounds straightforward, but once I started getting into bit manipulation and flags, it got confusing really fast. One tiny mistake like shifting something the wrong way or using the wrong constant would break everything, and sometimes the errors didn’t even point me in the right direction. On top of that, clang-tidy was being super picky this week. It wasn’t just finding actual bugs it was complaining about random stuff like not having curly braces around one line if statements or using a plain number like 8 in a calculation. At first, I didn’t even understand what the warnings were trying to say. I ended up copying the error logs into ChatGPT ju...

Week 3 Summary: This week in CST 334 was a rollercoaster. We started working on PA3, which is all about building a memory allocator. Basically our own version of malloc() and free(). At first, I thought, “okay cool, pointers and structs again,” but this assignment humbled me quick. Managing memory manually, keeping track of chunks, splitting them, and then coalescing them back together sounds simple on paper but actually implementing it without causing segmentation faults or crashing everything was tough. One thing that stood out was just how fragile everything becomes when you're directly manipulating memory. A wrong pointer or forgetting to update a linked list will break the whole thing. A lot of my time was spent debugging and going through each line of my code just to figure out where things were going sideways. The split_node function specifically gave me a hard time. It took me a while to realize how important it is to keep the fwd and bwd pointers clean or everything falls ...

Week 2 Summary:  This week in CST 334, we dug into how operating systems handle processes, and honestly, things are starting to make more sense now. I’ve heard the term “context switching” before, but I never really got what it meant until we broke it down. Learning the difference between voluntary and involuntary switches like when a process is just waiting for input vs. when the OS forces it to stop, helped a lot. It’s kind of wild to think about how much the OS is doing behind the scenes just to keep everything running without us even noticing.  We also got into how processes are created in C with fork(), exec(), and wait(). The fork() function really threw me off at first. I was like is the same program just running twice? But it made sense after printing out a bunch of values and looking at the return codes. It’s pretty cool how the parent and child processes end up doing different things, even though they start from the same place. Later in the week, we went over schedul...

CST 334 Week 1 Summary: This week was a solid intro to how operating systems work especially around the idea of processes. I learned that what feels like multiple programs running at the same time is really just the OS switching between them really fast — way faster than we notice. The OSTEP reading broke down how context switching works and what’s actually saved when the OS switches from one process to another. It basically tells us that every process has its own state and memory even if it’s just sitting idle. I also brushed up on basic computer architecture and got more comfortable using the Linux shell. In one of the assignments we used gcc to compile C programs. We also practiced navigating files and running commands. We also went through the process of using gdb to debug C code. Setting breakpoints and stepping through the program made it way easier to see what was actually going wrong. The PA1 assignment was definitely challenging especially getting String__resize to pass all th...

1. While taking CST 363, I learned how to write real SQL queries with joins, subqueries, and views and got a lot of hands-on experience with it using the MySQL Workbench during our labs and homework assignments. 2. We learned how to design a database using ER diagrams and normalization also through the workbench. 3. I got hands-on with MongoDB and saw how it’s different from SQL, plus how to connect databases to simple web apps and got experience doing that through the command prompt/ terminal.

  MongoDB vs MySQL These are both databases, but they work pretty differently. MySQL uses tables like a spreadsheet. Everything is organized in rows and columns. MongoDB doesn’t do that. It stores data in a more flexible format, kind of like writing it in a JSON file. They do have some stuff in common. You can use them to search through data, they both support big amounts of information, and you can use them with most languages. The main difference is how strict they are. MySQL wants everything to follow a specific structure. MongoDB lets you throw in different kinds of data and it won’t complain. Personally, if I was doing something like tracking student grades or a store inventory, I’d go with MySQL. But if it was something like a social media app where the data changes a lot, MongoDB would be better.

Lab 17 -  In this lab, I learned how to connect a Java program to a MySQL database using JDBC. I handled user input, inserted data safely with checks for duplicates and valid departments, and used transactions with commit and rollback. I also tested everything from both Java and the MySQL terminal to make sure it worked as expected. Lab 19 - Group Project Our group built a prescription management system using Spring Boot and MySQL. I worked on the patient update controller, where I handled retrieving the patient's current info, displaying it in a form, validating the doctor’s name, and updating the patient's address and assigned doctor in the database. We also created tables for doctors, patients, drugs, pharmacies, prescriptions, and inventory. Then we wrote Java controllers to handle registering and updating doctors and patients, creating prescriptions, and validating input.

Slow Indexes I learned that even if a query uses an index, it can still be slow. It’s not the index itself that’s slow, but what happens after. If the index finds a lot of matches, the database has to scan extra pages and go back to the table for each row. That’s what really slows things down, not a “bad” index. Week 5 Reflection: This week was interesting and fun as well because of the practical assignments we did. Lab 18 was a good practical experience where we designed a real-world database for a pharmacy system. Setting up the tables and connecting everything made it easier to see how this stuff would actually work outside of class.

  5 things I’ve learned so far: I’ve learned how to break down large, messy data into normalized tables using 1NF, 2NF, and 3NF to reduce redundancy. I now understand how to write proper CREATE TABLE statements with primary and foreign keys to enforce relationships and data integrity. I’ve gotten comfortable using basic SQL commands like SELECT , INSERT , UPDATE , and DELETE to interact with databases. I learned how to read and design Entity-Relationship diagrams, and how those translate into actual table structures. I’ve seen how indexes can make data lookups way faster, especially when dealing with thousands of rows. 3 questions I still have or need more clarity on: How exactly are indexes structured and stored behind the scenes? Like what data structures are used? What should I consider when designing a database for a really large or growing application? I still want to understand how database transactions work, especially when multiple users access or ...

  1. What is an SQL view? A view in SQL is like a virtual table. It doesn’t actually hold any data itself, it’s more like a saved version of a query that we can reuse. It works like a table since you can select from it just like any regular table, but it has some limits. A good example is that you usually can’t insert, update, or delete rows in a view unless it’s really simple and includes all the necessary columns like a primary key. It’s more useful for organizing or simplifying complex or complicated queries so you don’t have to rewrite them every time. 2. Comparing SQL to Java SQL and Java are pretty different overall, but they do share some ideas. In SQL, you use the where statement to filter results which is kind of like an if-statement in Java. And the select statement in SQL is like Java’s return statement as it tells the system what data to give back. But the big difference is that SQL is mostly about handling a lot of data like working with entire tables at once, while ...

  1.   Example of a non-equality join: We have a list of people and a list of products. We want to find out which products each person can afford based on their income. This join doesn’t use an equal condition. Instead, it uses a greater than ( > ) comparison. English sentence: Match each person with the products they can afford where their income is greater than the product's price. SQL query: select people.name, products.item, people.income, products.price from people join products on people.income > products.price; 2. Opinion on SQL as a language: I think SQL is pretty easy to learn when it comes to basic queries. The structure is simple and readable. But it can get tricky when joins, groupings, or nested subqueries are involved. Once you practice it starts to make a lot more sense as you're essentially just pulling data from databases and files. The SQL language is what makes this process of pulling data easy because of its simple syntax and logic.  Most ch...

  1. Differences between databases and spreadsheets: They might look pretty similar at first, but databases are way more structured. They have rules like primary keys and data types, and they’re built to handle a lot of data, multiple users, and complex queries. Spreadsheets are good for small tasks, but databases are better for anything bigger and serious. 2. Why databases are worth learning: It takes some effort to set them up and learn, but it's worth it. Databases keep data clean, organized, and secure. You can search through a lot of data quickly and make sense of it. That’s super helpful in real-world jobs or any big organizations. 3. What I want to learn: I want to get comfortable with SQL and really understand how databases work. I think it'll help a lot in any tech-related job, especially in backend development or data analysis which I am really interested in.

  Look back at the HW1 Look back at the HW1 assignment and think about how you would approach it now.  Think about all the things we have covered and how far you have progressed. - Looking back at HW1 (the Markov assignment), I’d approach it with a much better understanding of the concepts now. In the beginning, I had some difficulty understanding how to implement the Markov chain and random text generation because of how complicated the different methods looked. But through the course, I gained more clarity on algorithms, handling edge cases, and how to structure my code for better readability and efficiency. I would also apply more testing in projects, ensuring edge cases are covered, and leverage better use of helper methods to keep the code clean. Overall, the learning from this course helped me approach the task with a more systematic and confident mindset.  Highlight at least two victories.  It is very important to celebrate things that go  right .  I...

 Do it later

Who did you work with? I worked with my teammates Nasser, Noah, and Jian. What was your strategy for solving the Markov assignment? I kept it simple and just went step by step. After going through the instructions, I didn’t waste much time and jumped straight into the code. I focused on writing each method one by one, starting with the main functionality of the Markov class—building the word dictionary and generating random sentences. I also made sure to get the file reading and punctuation handling right. What was THEIR strategy for solving the Markov assignment? Nasser, Noah, and Jian all took a similar approach. They also worked through the assignment step by step, carefully following the instructions, and coding method by method. How would you change your strategy having worked on the assignment? Honestly, I wouldn’t change my approach because it worked well for me. The instructions were clear, and breaking the task into steps was effective. If the instructions were less clear...

  Work with some of your fellow classmates and go through your solution to project 1: LDPM With whom did you work? I worked with one of my teammates named Nasser.  What was your strategy for solving the assignments?       -  Did you start writing code right away? Did you plan it out on paper?  I have a very simple way of doing these kinds of assignments. I open the directions and start following the order and do it step by step. Thankfully we have clear enough directions to do that or else I wouldn't be able to as these projects are a little complex. I also don't like games at all so making a game is even harder for me. After looking through directions I just started coding method by method with the directions given until I completed it.       -  What was THEIR strategy for solving the assignments Nasser said he did the same thing.       -  How would you change your strategy having worked on the as...

 Project 1 Part 1 and 2 Reflection: Who did you work with? I worked with all my teammates: Jian, Nasser and Noah What improvements would you make to your code/what was suggested? Based on the feedback I received, I would work on simplifying the logic in some of the methods, like attackModifier() and calculateAttackPoints(). These methods can be optimized and made clearer, as the game didn’t require overly complicated logic. I would focus on reducing the reliance on if statements and instead explore alternative approaches to handle multiple conditions more efficiently. Which unit tests were the hardest to pass? defTest. That one was very hard to pass for some reason. And the others I found out weren't passing because of the calculation methods not being correct. After editing those it passed.  How do the existing tests function and could they be improved? I think they function pretty nicely and can't think of any practical improvements as of right now...

 Update later

  Week 1 Learning Journal: Reflection on HW 01 and Other Assignments: Week 1 we worked on multiple assignments. Since these are all 8-week courses, we have to learn really fast which is a big challenge for me. I'm the type of person to work better as the days go on and the more I get used to something. As soon as I'll grasp everything here we'll already be finishing up with the course. Anyways, I worked on CodingBat exercises, learning UML and JUnit, setting up the LDPM project, etc. I really liked the Project 1 starter and IntelliJ stuff as I got to use the software and get accustomed to it. I am feeling more comfortable everyday as I use it. I can say I feel proud that I can use such a software. One of the challenges with this class is the Git platform. That will take a bit to get used to. “The submission is missing the screenshots of fields and auto generated setters+getters.” I received this comment in the first check in for the big project that’s coming and this was on...

Week 0 was mainly introducing us to Java. I haven't coded in this language for over a year so it was really rusty for me. However, thanks to Codingbat, I got to relearn some of my java capabilities. Here is a recap: Did you plan it out or throw code at it? In the first few exercises I did initially try just throwing code at it. I quickly realized that this was more than just solving a problem. We have to be systematic and organized as we learned in CST 300. You can't just get work done; you have to do it right.  What worked? I was thinking of hurrying through it and take only 45 minutes to an hour as it said it would take that long for these assignments. However, when I started planning out my solution and actually working through it, it took me much longer. What worked was to understand what the problem is asking from you and then to complete it step-by-step.  What DID NOT work? Throwing code at it didn't work. I had to look through the different functions and lines that j...

Part 1: Video Review #1 (Evaluation and Suggestions included) - Replicant Collective: Biomimicry Video Link:  https://www.youtube.com/watch?v=ukOhBReFl5k 1. is the topic well covered?       Yes, very well. Intro is clear, then jumping into what they will present during this presentation.  2. is the presentation clear?      For the most part, yes. Speaker's spoke a little low or maybe audio was cut down during the editing of     the video and the background music . 3. how is the quality of the research?     The quality of the research is very good and is seen throughout the presentation.  4. how is the quality of the video production?     It is beautiful. The background music and video was very engaging and kept the audience engaged.  5. is the video engaging and interesting?     Yes. Because of the background effects, music and scenery.  6. is the team work evident?     Ye...