cs online - ralva

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