Notes/Report from Wednesday 3/4
Ok, let's get started on the debugging section. I'm pretty stuck on doing things in order -- I think it's a compulsive thing and I don't feel right doing it any other way, even though I know the best strategy would be to do all the labs first and then go back and read the text lessons.
Anyways, starting with the Debugging section:
Introduction to Debugging - Add'l Practice
bug and debugging - attributed to Admiral Grace Hopper, 1940's. removed a moth that was stuck in a relay of a Mark II computer at Harvard University and said they were "debugging" the system.
More on Pry this section.
Debugging Errors in Ruby code
1. Always read error messages and understanding what they are referring to first before jumping back into code. Don't run away from them.
2. Helpful part of error messages: line number, file name, and type of error
3. Error Types
* Name Errors
* when ruby interpreter encounters a word it doesn't recognize, it assumes the word is the name of a variable or a method, but will throw an error if that word was never declared/defined as a variable or a method.
* Syntax Errors
* incorrect syntax
* e.g., if you forget to put an 'end' for if statements, do..end statements, etc
* No method Errors
* e.g., have an integer set as a string and try to divide
* most common is when a variable is set to nil - this will almost always result in NoMethodError
* asking an object, like nil, to do something it doesn't know how to do will result in this error -- aka, you're calling a method that is not defined for that particular object
* Argument Errors
* passed too few or too many arguments
* e.g., if you forget to pass an argument, you'll get this error
* TypeErrors
* e.g., try and index into an array with a variable that doesn't evaluate to an integer
* e.g., try and do a math operation on two objects of a different type
Lab: Fixing Our Broken Program
Instructions:
1. Run learn to see which test fails
2. fix the error
1. file should read: puts "Hello World!"
3. Save and run learn
basically a quick practice to read the error messages
Lab: Debugging with Pry
remember REPL: an interactive programming environment that stands for Read, Evaluate, Print, Loop that includes irb and pry
this is where we answer the question about pry I've had in mind about binding because we use a line, binding.pry to pause the code so we can play with variables and methods locally.
so what is binding?
built-in ruby class whose objects can encapsulate the context of your current scope and retain them for use outside of that context.
Part 1:
Instructions
* look at lib/pry_is_awesome.rb and notice where binding.pry is used
* remember, to use pry:
1. require 'pry' (at tope of file)
2. use binding.pry (where you want the context to call variables/methods, etc)
* run the file in the terminal by running the ruby command
* type inside_the_method to see its value
* type this_variable_hasnt_been_interpreted_yet to see a value of nil
* type exit to continue executing the program
Part 2: Using Pry to debug
1. broken method in pry_debugging.rb
2. run learn to see test fail
3. place binding.pry before the keyword 'end' in the indicated method
4. run the test suite with the learn command
Lab: Debugging with Pry
Use pry to fix all the errors
got the first one. It was an easy one of just reading the errors. didn't need pry for this one.
this next one has 2 errors: a NameError and an ArgumentError
the name error is easy: one of the variables was mispelled when called in the body of method.
and the argument error is easy too: they used two variables but only passed one parameter. just need to add the missing one to the parameters.
this next one gives a type error that says "String can't be coerced into Integer." this error was called because they were multiplying "s" by 10. I fixed it by using string.insert(0, "ssssssssss")
pry didn't work though and I don't know why. conflict with other binding.pry's in other files? i think because another file had require and learn runs the entire suite so maybe that's why.
yep, that's why. I took it out of all other files and put it in the file I need it in and that worked with the 'learn' command
ah, weird. having binding.pry inside the do...end somehow messed with the map and caused all the new elements to be nil.
Definitely used pry for that one and it definitely helped.
Last one.
this last one throws a No Method Error
undefined method 'each' for "party dude" :String
line 13 of turtle_traits method
(Ninja Turtle theme if you couldn't tell)
I don't need pry for this one. hash doesn't include map -- that's only for arrays. you have to switch them here so that .each is called on the hash and .map is called on the arrays
ok, pry helped a bit, but it didn't help me realize that one of the attributes in the hash was being read as a string and not as an array.
I fixed the hash in the file and the test passed.
all tests pass, yay!
New section!
Ruby CLI Applications
first lesson:
Simple Blackjack CLI Application
goals:
* utilize conditional logic and looping
* gain an introduction to the command line interface
Let's see how quickly I can go through these
simplified blackjack: goal is to have a card total of or very close to but never exceeding 21.
* player is dealt two cards, values are 1 through 11
* prompt for hit or stay
* if hit
* receive 1 new card
* else if stay, nothing
* if sum of all cards exceeds 21, player loses
* if it doesn't, prompt again to hit or stay
How do puts and print methods output text to your console?
they use the $stdout global variable provided by Ruby
puts and print send ouput to $stdout which sends the information a file called stdout on your computer which in turn communicates with your operating system which in turn outputs that info to the console.
running this command line app:
ruby <filename.rb>
separation of concerns: have one file whose job is executing the program
this lab uses runner.rb:
ruby runner.rb
Testing the command line app:
user input is essential so in order to use rspec for our tests to work, we need the test suite to fake the implementation of the puts and gets methods. This is called stubbing
stubbing: fake implementation of a method
1. expect($stdout).to receive(:puts).with("Type 'h' to hit or 's' to stay")
1. test suite is 'expecting' the method's execution to use puts method to output the string.
2. expect(self).to receive(:get_user_input).and_return("s")
1. test suite is 'expecting' this method get_user_input to use the gets method to store user input and return that very input
3. this command line appliacation will have one file for all the methods, including the final method called run_program
4. then we'll have a file whose sole purpose is to run the program -- it's called a runner file and it hase only one line: a call to the run_program method
Instructions:
1. all code will go in blackjack.rb
2. once all tests pas, run this line: ruby lib/runner.rb to play
3. methods to define:
* welcome
* welcomes the user
* deal_card
* pass it an array
* return an array with 1 element
* each card is a random number between 1 and 11
* display_card_total
* return their currently card total
* prompt_user
* ask them if they want to hit or stay
* if they want to stay, ask again
* get_user_input
* receive their answer and store/return it
* end_game
* if card total exceeds 21, game ends
* initial_round
* deal the user their first two cards, i.e., their initial_round
* arguments: array to store cards
* returns: array with two cards
* call deal_card twice and return
* hit?
* returns true if get_user_input returns yes
* returns false if get_user_input returns no
* runner
* this will be the method that calls all the methods above such that the game will execute as intended
* a loop constructor is recommneded, until, to enact the gameplay
* welcome
* initial_round
* loop until total is greater than 21
* display_card_total
* hit?
* calls on prompt_user
* calls on gets_user_input (gets.chomp is great!)
* if 's', returns current total, unchanged and doesn't deal any new cards
* if 'h', deal_card
* if neither,
* display "Please enter a valid command"
* prompt_user
* end_game
I notice that in order to link to another file to use its methods, we use the keyword require_relative (not just require).
So I got all the tests to pass, but something isn't working. I'm reading ahead as a break and will come back to this later.
I like this image here about the programming process:
Ooh, something noteworthy here:
state table:
table that keeps track of the inputs,outputs, local variables, and conditions in a bounded or fenced-off 'bloc' of code or pseudocode.
Because the blocs are fenced off, sometimes we have to provide input that would be available if the bloc were part of a larger program. It's okay to do this because we'll assume that other code does its job properly.
Variable
State
State
State
State
State
State
State
State
State
Input: baguette
Input: n
Output: even_pieces
Local: baguette_length
Local: even_length
Local: collection
Cond: baguette_length > even_length
Local: piece
Local: rest
State will be the value of each variable at each point in the program's execution
Triangle process of debugging
verify the inputs, outputs, and implementation of individual code blocs (a procedure, a function, a method, etc)
"white boarding" is when you use a white board to write down your pseudocode or work through your "pseudocoding"
"the ability to craft focused pseudocode that solves problems is the essential focus of the "whiteboard" interview used in engineering teams.
The ability to demonstrate, with state tables, that your pseudocode works is a strong signal to other developers of your ability to think clearly about programming.
The final step (and, to be honest, it's also expected in whiteboard interviews) is to take these ideas and turn them into code in a particular language."
https://qz.com/1365059/a-universal-way-to-solve-problems-from-a-mathematical-genius/
Took a quiz and learned a lot.
Next Section: Version Control
version control system: VCS for short
software that controls collections of versions
most popular is "Git"
popular VCS's: Git, Mercurial, Subversion, and others
VCS's allow us to experiment without fear and try new and improved techniques
article that uses oil paint as historical example of version control and how it unlocks freedom and creativity: article: http://www.paulgraham.com/hp.html
Other benefits:
* automatically create a backup of your work
* provide an easy way to undo mistakes and restore previous versions easily
* document changes and log comments as to why, etc
* keep file names and hierarchies consistent and organized
* branch work off into multiple "sandboxes" that can be experimented with but won't impact each other
* collaborate with others without disturbing each other's or our own work
Git vocabulary terms
* repository (repo for short) - directory of files tracked by Git
* track - Git will track a file and notice any difference aka changes aka diff's -- then gives you choice to add the change in order to keep it
* diff - short for difference. diff for file is changes since the last commit; diff for repo is all the diffs in all the tracked files inside the repo that have been made but have not yet been committed (sometimes called the 'diffset')
* commit - command to save the diff. when commit is made, we're asked to write a "log" message describing what happened in the diff
* log - the record of what happened in each commit
* local/remote - when we start working with a git repo, we "clone" it from a remote source and have a copy of that directory on our own system. we call the repo on our personal system, the local repo.
* master branch - multiple branches are basically the sandboxes where we can experiment and change code without worrying about destroying anything -- for the moment, for me, whenever I create a Git repo, I'll be working on the master branch
* branch - the combined history fo all the changes of all the files in the repo
Conclusion: version control helps us maintain the overall stability of our code so that we can feel free to explore.
Next Section:
Git Basics
commands:
* git init
* mkdir git_project_name
* cd git_project
* git init
* make sure to only type this command in the directory you want git to track
* git status
* run it in the git directory
* tells information about the directory
* tell information about number of commits, etc
* touch README.md and run git status to see what it looks like
* git add
* git add <filename or path>
* preserves changes you make to a file
* this tells git what file to track. enter git add README.md and then look at git status
* git commit
* this will commit the file changes we added with git add
* git commit -flag "COMMENTS"
* git commit -m "Initial commit"
* once run, it'll create an ID called SHA to track the version you commited
* make more changes to README.md and then run git commit -am "Updates README.md"
* use the flags -am if all files in the directory are being tracked
|