cs online - ralva

Reading about quick sort and median of three partitioning really reminded me of the fake coin puzzles we solved. And in some sense they are very similar -- efficiency is about dividing and conquering. Breaking something down into smaller pieces. Rather than doing exhaustive comparisons you split a large problem into smaller halves. These smaller steps allow for less cognitive load and a quicker solution overall. Median of three partitioning does the same. We look at the first, middle and last. And working with sub arrays allow us to sort much faster. It seems like a lot of this class, and finding efficiency is about finding a pattern to break something down smaller than as presented. It's an interesting concept I hope to bring elsewhere.

This week in class once of the algorithms we covered was Breadth-First Search (BFS). Unlike other search methods that traverse down a single path until they hit a dead end (like DFS), BFS explores like a more intentionally. It checks every single immediate neighbor first, and only when that layer is done does it move on to the neighbors of those neighbors. This made me think about how connections work on LinkedIn and its massive social graph. Think of LinkedIn as a giant graph, where each person is a "node" and every mutual friendship is an "edge." It starts with you as the root node and scans your immediate circle—your 1st-degree connections. It places all of them into a holding area called a "queue." Then, the algorithm moves to the next layer, pulling from the queue to check the direct connections of your friends these are your 2nd-degree connections. For these type of graphs it feels like BFS is a great way to analyze and search.

We covered a lot this week, but particularly the Tower of Hanoi is pretty interesting (beyond its appearance in the recent Planet of the Apes movie). The puzzle is solved by recursion. Initially solving the puzzle seems impossible, but by solving a smaller sub problem first you find the rest of the solution falls into place quite naturally. I have a lot of experience writing web applications, and it really made me think about nested component trees in a complex DOM Structure. For example let's say we wanted to find a simple piece of text. If you want to search to find that specific word, a regular for loop is not useful because you never know how deep the branches go (DOM can be very very nested). The solution to that is a recursive function. You just write two pieces of logic: "Check this element, and if it has descendants, tell them to run this exact same check." This allows for your logic to quickly drill down the DOM and find the text you're looking for rather tha...

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.

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...

Should it be pronounced SEE-QWILL or ES-SKEW-EL ... who knows? Maybe it's like GIF. Potato Tomato. 1. An SQL view is a virtual table whose contents are defined by a stored query. I think of it as a saved SELECT statement that I can interact with as if it were a real table. It's similar to a table because it has rows and columns, and can be queried SELECT to simplify retrieving complex data. However, it's different because a view doesn't store its own data—it just displaying data from the underlying tables. Which sort of makes sense since views don't have their own primary keys. 2. It's hard to compare SQL to a language like Java. Java has a lot more flexibility in data structures. Also Java works synchronously (well unless you count multi-threading) so it's processing data one at a time versus SQL which is fundamentally different under the hood. That said SQL is a lot more "clear" and I think the nature of queries is a lot more determinant than so...

1. From my perspective, a useful example of joining on something other than keys would be to find events that happen in a period of time or specific date. For example, you might need to find all sales that happened during a holiday. This requires joining a Sales table not on an ID, but on a date range. In English, I'm asking the database to "Show me the sales for every sale whose date falls between a holidays start and end date." In SQL, I would write that as something like: SELECT s.SaleID ON s.SaleDate BETWEEN p.StartDate AND p.EndDate; 2. My opinion of SQL is that it's deceptively simple to start with—but very hard to master. I get lost when thinking about queries that require multiple levels of connections or operations. Something like "Find the average number of black cars per car in each state". Even if you had a giant DMV database it would require multiple subqueries or groupings and end up quite complex.

Excited to be starting this database journey! (Albeit with an accelerated timeline thanks to my wedding) 1. From my perspective, the biggest difference between databases and spreadsheets is control. On a spreadsheet, I can type anything anywhere. A database forces me to follow rules, like setting a column to only accept numbers, to keep the data clean. 2. I believe investing my time to learn a database is important for two main reasons. First, apps need a reliable “single source of truth” for data that are both accurate and secure. Second, I want to master the power of SQL. The ability to ask complex questions and get answers from millions of rows of data almost instantly is key when dealing with production data at scale. 3. In this course, I want to learn how to design a database from the ground up. I have had the experience of working with various databases, but in an abstracted form using REST to get data from there -- but its a totally different world getting to design the database...

  Look back at the HW1 Wow Hangman. It feels like a long time since I opened IntelliJ to start working on the Hangman project during the first week of our class. There are a lot of things I could use to improve it based on what we learned, for example: 1. Maybe I would use Room Database instead of a .txt file to store allWords ... that way when the app starts there are already preloaded words that can easily be edited and tracked. 2. Going even further, maybe I would use Retrofit to retrieve a random word from an open API service like this one:   https://random-word-api.herokuapp.com/home 3. Rather than using System.out, I could build an actual UI. Maybe I could build an Android app, and build a View Model structure to show someone the interface of the hangman app. Overall, the exercise proved very valuable. We were working on KEY logic which would be adopted into a more complex and rich hangman app. I'm very sure some of the key functions would remain the same. That said -- w...

I worked with Branden from my team. With this assignment (and with most assignments) I always try to work directly off the prompt, filling out each defined method from the UML diagram of the assignment. Once I feel good about implementation, I use the unit test as a guide to help debug and get each function fully ironed out. Afterwards I go back in, format and clean up variable names and add single line comments for clarity. Through this process I am working through the logic in my code 2-3 times which leads to a cleaner output. Branden mentioned his strategy was, “For Project 1, I took it one step at a time. I started with the Monster class and followed the prompt closely, making sure each method matched what was expected, especially with things like output formatting and phrases. I tested as I built each part, and when something didn’t work, I used the error messages to figure out what needed fixing. I created each monster type one by one and kept everything organized using Git branc...

How fun to do some code review. I often tell early career engineers that as you progress in your career you will tend to read more code than write it, as architectural reviews, design docs and pull request reviews become a major part of a Software Engineer's day. I reviewed all three of my team members code. Overall it was a good exercise, and especially interesting to see how each of them approached the problem in a different way. What improvements would you make to your code/what was suggested?  Definitely some good learnings in looking at other group members code. Just from observation, I think I would likely add a little more thorough explanation in my JavaDoc comments. One of my group members really added a lot of detail there and I could see how helpful that would be looking at the code months from now. As far as critical feedback to my code, I agree with all of it. Adding Javadoc comments for all methods Use a StringBuilder to increase the efficiency of my makeGuess() functi...

Week 1 was a fun week that jumped right into some good coding exercises in Java. It touched upon a bunch of different themes like basic Java, Unit Tests, Git, Interfaces and more. I could probably write a lot about how much I fought with IntelliJ (let's be honest it's not the best) but will touch on more substantiative topics. First let's talk about unit tests. I know JUnit would not be considered a first-class citizen, but the way it is autogenerated by IntelliJ is quite sleek. In that sense writing unit tests and running them is extremely easy. We often read about TDD (test driven development) as a paradigm some organizations use, and building out tests in Java for our exercises really makes me see the value for that approach. Not only does it verify the output for a given input, it also helps us write our functions in a more ... well functional kind of way. I would argue that if you can't write a unit tests, that may actually be a code smell more than anything else. ...

The Coding Bat exercises were a fun way to get reacquainted with some of the basic features of Java. I imagine that going through them over time will help me to get familiar with more advance features and "gotchas" of the language. I would use the example of Java String-1 `withoutEnd` because it led me down an interesting rabbit hole and provided nice value that I will describe here. I have a lot of experience writing Javascript, so the basic prompt seemed very simple: "Given a string, return a version without the first and last char, so "Hello" yields "ell". The string length will be at least 2." Easy enough, I know in Javascript I would use the `slice` method. So I simply looked up what the equivalent would be in Java which was the `substring` method. Using the `.length()` method was familiar to me, so that came naturally -- easy enough right? Well sorta. This is where my rabbit hole came into play. I know that using `.slice()` in Javascript cr...

Video Review 1 Professional Video:  https://www.youtube.com/watch?v=Rdt3Mdls-Ac Video Review 2 Professional Video:  https://www.youtube.com/watch?v=ZRtEIxSY2Ms Video Review 3 Professional Video:  https://www.youtube.com/watch?v=z8uvy34Bmxs Our video project Professional Video:  https://www.youtube.com/watch?v=6EXtT8xbndI General Video:  https://www.youtube.com/watch?v=0ZY62Fh_UB4 Although I may be bias, I think we did an amazing job with our video. It really is a culmination of our collaborative efforts through the class, and was only possible because we were able to work with each other effectively. Overall, I am extremely proud of what the team was able to accomplish. We were consistent in our team meetings, and always on top of deadlines. We optimized for asynchronous collaboration on assignments, but structured them for success. Overall this course taught me about how to work well with a remote team. Beyond that the writing assignments helped me assess ...

  Part One Working on the final research video project with the team has been extremely smooth! One of the team members created a great template on Google Doc, which allowed all of us to “claim” pieces of the assignment, and work on it asynchronously. This doc served as kind of the template, with each of us adding links to our audio files and video files inside of it. We worked on it relatively fast, and were able to review a draft version this week during our normal team meeting. Overall the project has been extremely smooth, and the output is going to be great. I’m looking forward to the class's reaction, and maybe hoping for that “win” in the voting process 😀. Rather than describe how I would approach future projects differently, it’s easier to describe how I would do them the same. I think working off a clear template, with clearly defined deliverables was a BIG part in why this was so smooth. I will continue to repeat that process moving forward. Part Two I learned a lot from...