Keshab Neupane

When I think back on HW1, I remember having trouble with the fundamentals of Android programming, like structuring code, setting up a project in Android Studio, and comprehending how various elements like Activities, XML layouts, and Java classes interacted. I would feel much more assured at every stage if I were to tackle that task now. I now know how to construct features like data logging and login windows, as well as how to utilize Room for database persistence and meaningful entity associations. Additionally, I know how to handle merges and maintain Git branches, which was really helpful while we worked on Project 02. I now have a better understanding of the entire Android development process thanks to my experience creating a multi-activity app with permanent data storage. This semester, I achieved two significant successes: accurately configuring the Room database with DAOs and repositories, and effectively working with my team using GitHub, where we tracked our progress usin...

This week,I learned understanding of how operating systems control file systems and storage devices, beginning with how the system communicates with input and output devices. I now recognize the crucial functions that interruptions and polling play in device communication. Polling may be time-consuming, particularly for slower devices, as it requires the CPU to continuously check if a device is available. In these situations, interrupts are more effective since they let the CPU focus on other tasks and only react when the device indicates that it is finished. I saw how Direct Memory Access (DMA) enables the device to manage data transport directly, lowering CPU involvement and enhancing system efficiency while transferring large volumes of data. Additionally, I discovered that memory-mapped I/O simplifies communication by enabling device registers to be accessed similarly to memory addresses. The structure and optimization of disk storage was another subject that caught my atte...

We studied semaphores and monitors this week in CST 334, two crucial synchronization primitives for concurrent programming. Particularly intriguing to me were semaphores, both conceptually and practically. Semaphores are shared integer variables that regulate thread-to-thread access to shared resources. The basic POSIX functions acquire () and release () (or wait () and signal() were covered, along with their applications in establishing thread coordination and mutual exclusion (mutex). I liked how the operating system makes sure these actions are atomic, removing busy waiting by stopping inactive processes. The notion became much more robust when semaphores were used to handle issues like the parent-child thread synchronization or the producer-consumer situation.The usage of locks and condition variables in the development of semaphores (such as the "Zemaphore") was also helpful to me in comprehending how lower-level processes contribute to higher-level synchronization tools...

This week in CST 334, Virtual memory rules and the operating system's handling of page replacement under memory strain were the main topics of discussion. When physical memory is full and the OS has to choose which pages to remove to create room for others, I discovered how important these policies are. We focused on four main algorithms: Random, Optimal, FIFO (First-In-First-Out), and LRU (Least Recently Used). These policies are essential for maintaining system responsiveness and preventing excessive disk usage when multitasking with large processes. Because it depends on future information of memory access, the optimal replacement strategy, while ideal, cannot be applied in practical systems. Nonetheless, it provides a useful standard by which to compare actual policies. Because of Belady's Anomaly, which states that expanding memory might actually result in more page errors, I discovered that the FIFO technique was shockingly incorrect. By utilizing the idea of temporal l...

1. Who did you work with? I worked with the Ethan, Liam, and Matthias. 2. What was your strategy for solving the Markov assignment? My strategy was to not overcomplicate anything and to adhere closely to the task instructions. I avoided from attempting to rework some of the already established reasoning. To keep on course, I made careful to follow the codebase method by method and constantly consult the comments and TODOs. I trusted the framework supplied this time since I had erred in previous projects by creating more than was necessary. 3. Did you start writing code right away? Did you plan it out on paper? I didn't do a lot of formal planning or handwrite anything. The assignment's layout essentially handled our planning. To be honest, it was less stressful since it seemed more like filling in the details of a planned framework than creating anything from new. To direct my work, I used the method list and built-in comments. 4. What was THEIR strategy for solving t...

With whom did you work? I worked with Ethan, Liam and Matthias. C What was your strategy for solving the assignments? I built the abstract class first, then implemented the specific monster subclasses as part of my approach to the LDPM assignment. I appropriately put up the structure using the UML diagram. I concentrated on the tests after creating a general schedule of every lesson. My reasoning was aided by the test file, particularly in sections like attack(), setPhrase(), and takeDamage(). In light of the test findings, I debugged and improved. Did you start writing code right away? Did you plan it out on paper? I used method stubs and inline TODO comments to plan inside IntelliJ rather than on paper. Before implementing the methods in order of difficulty, I started by writing the class skeletons. I checked the output frequently to ensure accuracy and used the test class as a checklist. What was THEIR strategy for solving the assignments? Ethan addressed the need of care...