Time - Denisse & Jocelyn

[wangjoc]

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?	1. def keyword 2. method signature- name & parameters (may have default values specified) 3. method body if not a singletonmethods 4. method arguments may accept an arbitrary number of arguments.
What are the advantages of using git when collaboratively working on one code base?	Being able to work on the same repository at the same time was very useful. Git or the web-based graphical interface(GitHub) was great because we could easily see the changes, comments and more details made for our repo.
What kind of relationship did you and your pair have with the unit tests?	Unit tests helped us better understand what was incorrect in our code. We used the tests in every wave. The file provided for unit testing was appreciated even more when we got all 17 tests passed.
Does your code use any methods from the Enumerable mixin? If so, where and why was it helpful?	We used enumerables in several places. One example is in min_by, which we used as part of our tiebreaker method in wave 4. This helped us efficiently compare two words and select the one that had the shortest length. We also used .map in wave 3 in order to create an array of the scores per letter, which we then performed a .sum on. This provided us with the preliminary score total.
What was one method you and your pair used to debug code?	We found pry to be very helpful when we were refactoring. Our process was to try a modification to the code, then run the tests. If the tests didn’t pass, using binding.pry to stop right before and after the new code we had just implemented and use it to make sure that variables were returning what we expected. We would continue to modify the code until it passed the tests.
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?	One of the things that really worked for us was taking a break and trying to figure out things on our own first before coming back together and discussing. Even though this didn’t quite follow the spirit of pair programming in the sense that we weren’t looking at the same screen the entire time, we found this to be very productive since it gave us time to each practice the syntax for Ruby and then share our findings. Another point that we found productive was getting help from Denisse’s mentor. After putting together the initial code, we asked her mentor to look over the code and give us feedback on best practices. This was a great learning experience because we were able to see how he debugged issues and thought of ways to refactor the code. It also gave us an opportunity to experience what pair programming would be like when a novice is paired with an expert.

[jmaddox19]

Calculator

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	✔️ Yay! 👏👏👏
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	✔️ Glad y'all found unique strategies that worked for you both!

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!! Code looks so good. Very consice and readable.

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	✅