cs online - ralva

We covered a whole lot this week! Though I want to focus in specifically on CPU scheduling, which was probably the most mind-boggling to me. We obviously covered the different scheduling policies and what they mean: First in, First Out: Run the jobs in the order they are received. Hopefully how a drive through operates. (Except for when they make you pull over OMG) Shortest Job First: Run the shortest job first, simple enough right? Shortest Time to Completion: The scheduler is comparing the remaining run time to the run time of the current job. Round Robin: Run each job with a given time slice and move on, cycling through them. There's obviously a ton more in depth, and a ton to grep here -- but what was really interesting were all these different strategies. As someone who spent most of his time writing Javascript, FIFO feels familiar to me. Javascript is a single-threaded language -- which means the entire Javascript event loop runs very similar to a FIFO in concept. This is why...

We covered a lot in the first week! I generally have a lot of experience in Linux and the shell, having written many bash and Makefiles in the past while building CI pipelines. So it's nice to see that knowledge will crossover into the class! Similarly I have good experience in the command line since I usually test APIs with cURL and only use Git via the command line. Despite the good foundation, I think one of the big learnings curves from this first week was writing C. I definitely have written C in past CS classes, but it's been a long time and much of the code we've written in CS Online has been Java. So the first coding exercise was definitely a little bit of a struggle. Sure C to Java has familiar control structures (if, else, for, while and switch) and they're both statically typed. But there are a lot of critical differences in the two. Java handles garbage collection (while JVM more specifically) whereas C does not. I imagine as we get deeper into the class we...

Coming from MySQL, the biggest difference with MongoDB is how it stores data. In MySQL, I had to carefully plan out my tables and columns ahead of time, and every row had to follow that exact structure. With MongoDB, it feels like I'm working with flexible JSON documents instead of rigid tables. One document can have different fields than the next one and the same collection, which is a huge change. It seems like you can just start building without having everything perfectly mapped out, which is both cool and a little scary. I imagine it would be easy to build yourself into walls. Even though they feel totally different, I'm seeing some similarities that make sense. Every document in MongoDB gets a unique  _id , which feels just like the primary key I'm used to in MySQL for identifying a specific row. They both also use indexes to speed up searches, so the basic idea of making queries fast is the same. The main challenge is learning how to ask for data. I'm used to wri...

Working on a database schema during the group project has been surprisingly challenging. Turning ideas into a single, correct SQL file that everyone agrees on is tough. If someone changes the casing on a column name (like from  doctor_id  to  doctorID)  you can easily break queries. Sharing a .sql file on Google Drive is far from ideal lol. I really wish there was a better tool for this, something like Google Docs but for database design. It would be amazing if we could all see the ER diagram and the schema at the same time and watch changes happen in real-time. We could leave comments, see a version history, and merge our ideas without invaliding someone's code. It feels like a problem that must have a modern solution, because just passing a text file around seems so clunky and makes it hard to focus on actually learning how to design the database. GitDB pls?

We've learned a lot about indexes. Indexes are like the index at the back of a textbook. If we need to read on a topic like "Video Games", we turn straight to page 150 (listed in the Index) and voila -- done. Fast search for something. In essence -- that's how an index works. But how could it be "slow"? What would cause a slow index. I guess to extend the book metaphor it would be like if the index for "Video Games" said page 150, 200, 231, 240, 250, 400, 656, 800, etc. It would take you a LONG time to flip from Index Page to Information Page to Index Page to Information Page and so on. That back and forth gets slower and slower the more pages you have to go through. That's a slow index. In the case of a DB, sometimes if data is scattered -- you should just do a full table scan! Which is what the article on  https://use-the-index-luke.com/sql/anatomy/slow-indexes  talks through.

What have I learned in this quick tour through SQL: 1. Generating EER documents using a SQL Script via MySQL workbench is extremely slick. It actually beats using a drawing program by A LOT. 2. SQL is very functional, being able to run a query and get a deterministic result is very nice. This compared to writing Javascript and dealing with async operations is great. 3. A SQL view is extremely powerful if you want to work with large sets of data. Being able to "hide" complex queries in simple views seems like it would be extremely useful if you're working at scale and with a team. 4. NULL in SQL is weird. Well not weird, but different from Javascript where null is more of a value. In SQL NULL being a state is definitely something that is odd. 5. SQL executes in a way I don't understand. It's not looping through data, instead it's operating on multiple data sets simultaneously. The nature of this is how its so fast, but it's quite a mind-bending concept to t...