Josh's CSUMB Learning BLOG

  Josh Goldberg CST 334-40_2262 Mar 17, 2026 This week we learned about processes. What is a process, the difference between a process and a program, and how the OS manages processes. A process is an instantiation of a program and has a state; the program is just code and data on disk that is turned into a program when the OS starts executing the code. Last week we talked about CPU virtualization which is the gateway to this week. Each process gets to behave like it has it’s own CPU through virtualization, and the OS has time sharing mechanisms and policies by which it shares the CPU between processes. Mechanisms describe how things work, and policies describe what is acted on by the mechanisms. For example, how does the OS perform a context switch vs. how does it decide which process to switch in and out of a running state. Each process state describes the process’s address space reserved for code, heap, and stack, what is in the registers for each process, and information about a...

  This week was a good overview of the main purpose of operating systems: abstracting the hardware away from software, enabling concurrent program execution, and persisting data to non-volatile storage. The lectures starting working from the ground up, tying together these concepts. Computer architecture review of cpu execution and memory layout, access, and management brought us to the operating system discussion. The history of unix and linux gave an overview of what the operating system abstraction layer is that we’ll be working with. Programming in C is how we interact with the operating system and get a window into the lower level system. C abstracts away the cpu cycles and most of the memory management, but still gives us the ability to directly address and manipulate memory if we want to. The command line is a much safer way to interact with the operating system through system calls, most of which are written in C. This is the main userspace interface to the operating system...

 This week we reviewed sql functions and referential integrity. functions are scalar or aggregates, like CONCAT or GROUP BY. referential integrity refers to different kinds of constraints we can place on tables. primary keys must be unique and not null unique keys can be null foreign keys relate tables by column references we can place other constraints on our data like enforcing NOT NULL and enforcing values within certain ranges.

 This week we setup postgres locally. Going over the basics of what is a relation and formal representation of relational algebra such as selection, projection, union. selection: get one or more rows from a table based on criterion projection: get one or more attributes from a table union: add the rows of two tables something like `select first_name from people where id > 100` is a combination of selection and projection. we are selecting rows where id > 100, and then restricting the result to just the first_name attribute: projection(selection(people,id > 100), ["first_name"])

  HW1 post mortem I’m pretty happy with how I implemented hangman, but we could make some structural changes to be more object oriented-ish.  I would separate out the game state tracking from the game play mechanics. This would make it easier to reuse gameplay scorekeeping logic and let Hangman class be dedicated just to the gameplay mechanics. readFile should be in its own class since it’s also separate from the gameplay mechanics. Something like a HangmanCorpusLoader that could be overridden to load from different kinds of files or from raw streams or from APIs or generate random strings or whatever. Instead of calling new Hangman directly from gameplay, a factory method would be appropriate to encapsulate the constructor implementation.  I might even go so far as to make a separate class for the chosen word itself to hide the logic of word state, tracking letters, etc. from the outer gameplay I/O. Two Big Wins 1. I think the abstracted test logic I made for our project...

I worked with Anthony M and Christopher B on the code review. I followed my typical strategy for project development. After reading the full documentation on the assignment, I began by writing out all the class and method stubs to match the specified UML. After that, I worked through the business logic of the assignment method by method, testing as I went. I follow method calls as I go and fill them in to get tests to pass/fail as soon as I can so I can effectively debug as I develop. I did not plan it out on paper. The existing specification and UML was sufficient for me. My classmates used varying strategies. Chris did work things out on paper to better understand how markov chaining works. Anthony did all the stubs first like I did, but Chris went class by class and did all the debugging at the end. We all hit the linter! I think my strategy worked well. It's good to sketch out the higher level abstract logic flow before implementing each method. This is a pattern that scales we...