cs online - ralva

The example of the 8 coins problem (9 coins in our quiz), was really interesting and pretty mind-blowing.  My initial instinct was binary search, or halving the pile until I found it in three weighings. But there’s a faster way.  By initially dividing them into groups of three, you can find the fake in just  two  steps. This was a really interesting and practical example that made me think about efficiency in the real world. Algorithm efficiency isn't just textbook theory ... it’s about optimizing problem-solving.  I feel like I actually execute algorithms unconsciously all the time. For example when I lose my keys. I don't look at the whole house randomly, I retrace my steps backward, eliminating irrelevant search spaces just like an efficient function. Overall it's exciting to jump into class and I'm excited to see where else I can make my own thinking more efficient.

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.