Anya and Lina's Adagrams

[lina5147]

Assignment Submission: Adagrams

Congratulations! You're submitting your assignment. Please reflect on the assignment with these questions.

Reflection

Feature	Feedback
What are the components that make up a method?	method signature, parameters, block code, return
What are the advantages of using git when collaboratively working on one code base?	Good version control, where there is a clear most recent version. We would be alerted in case of any merge conflicts, meaning if both people altered the same section of code. It is a quick and easy way to push new changes to the main branch.
What kind of relationship did you and your pair have with the unit tests?	Instead of using puts to print things directly from the lib file, we ran the unit tests file using rake to verify whether our methods were passing. If they weren’t passing, we would pay attention to the error messages and make changes to our code accordingly. We also commented out tests that were not applicable to the methods we were currently working on. So, while working on Wave 1, we commented out tests for Wave 2, 3 and 4.
Does your code use any methods from the Enumerable mixin? If so, where and why was it helpful?	The enumerable methods we used were .any?, .find, .min_by, .max_by, and .select. We thought of them as a .each method with an added power and greater efficiency. For example, .select iterated through an array of word hashes and pulled out hashes with the highest score, and saved them to an array. .min_by helped us find the words with the least amount of characters, while .max_by helped us find the highest score. In an instance of a score tie of 10 letter words, .find located the 10 letter word that appeared first in the array of words. .any? helped us verify if there were any highest scoring 10 letter words in an instance of a tie.
What was one method you and your pair used to debug code?	We used the “rubber ducking” method by talking each other through our thought process. We also used puts every once in a while to see if parts of our code was outputting what we expected. We didn’t use the debugger because we were just getting the hang out pair programming and it was easier for us to just talk to each other and fill in each other’s gaps in knowledge.
What are two discussion points that you and your pair discussed when giving/receiving feedback from each other that you would be willing to share?	(1) If the driver seems to be going the wrong direction with code, we discussed that it would be helpful for the navigator to ask clarifying questions and make suggestions when appropriate. Navigator should also point out positive parts of the code to keep up morale. (2) We discussed the driver being open and attentive to the navigator’s feedback. The driver would ask follow up questions which would lead to a discussion about potentially incorporating feedback into our code.

[beccaelenzil]

Adagrams

Major Learning Goals/Code Review

Criteria	yes/no, and optionally any details/lines of code to reference
Correctly creates and calls methods with proper syntax (parameters, return statements, etc.)	✔️
Uses correct syntax for conditional logic and iteration	✔️
Practices git with at least 3 small commits and meaningful commit messages	✔️
Utilizes unit tests to verify code; tests can run using the command $ rake and we see test successes and/or failures	✔️
Practices pair programming; the reflection question on pair programming is answered	✔️

Functional Requirements

Functional Requirement	yes/no
For the draw_letters method, there is an appropriate data structure to store the letter distribution. (You are more likely to draw an 'E' than an 'X'.)	✔️
Utilizes unit tests to verify code; all tests for draw_letters and uses_available_letters? pass	✔️
Utilizes unit tests to verify code; all tests for score_word pass	✔️
Utilizes unit tests to verify code; all tests for highest_score_from pass	✔️

Overall Feedback

Great work on this project! Your code is clear, concise, and you've done a great job working through some tricky logic. It is clear that the learning goals around writing methods and manipulating data were met. Keep up the hard work!

Overall Feedback	Criteria	yes/no
Green (Meets/Exceeds Standards)	4+ in Code Review && 3+ in Functional Requirements	✔️
Yellow (Approaches Standards)	3+ in Code Review && 2+ in Functional Requirements	✔
Red (Not at Standard)	0-2 in Code Review or 0,1 in Functional Reqs, or assignment is breaking/doesn’t run with less than 5 minutes of debugging	✔

Code Style Bonus Awards

Was the code particularly impressive in code style for any of these reasons (or more...?)

Quality	Yes?
Perfect Indentation	✅
Elegant/Clever	✅
Descriptive/Readable	✅
Concise	✅
Logical/Organized	✅

[beccaelenzil]

Consider simply returning false here.

[beccaelenzil]

While this case statement works, it means that the information about which letter has which score is locked into this piece of code, and can't easily be used elsewhere. For example, if you wanted to display the value of each letter in a hand, you would need to repeat this work.

An alternative approach would be to store the letter scores in a hash, something like this:

LETTER_SCORES = {
  "A" => 1
  "B" => 3,
  "C" => 3,
  "D" => 2,
  # ...
}

Then to get the score for a letter, you can say LETTER_SCORES[letter].

[beccaelenzil]

Great work breaking out this logic into its own helper method

[beccaelenzil]

Great use of comments to increase readability.