A not so short and simple guide to project user proofing.

So, you’ve reached the point that you have to do your first project. Congratulations! This may be daunting and a little bit unnerving, but don’t fear! You’ll get through it, you’ll do great, and you’ll learn.

There’s probably hundreds of guides and videos on what you should look out for or do. These are some of the things that I learned and found helpful along the way!

gets.chomp- This bad boy is pretty cool, but it’s actually two parts! gets is what takes in user input from the terminal, but the chomp bit gets rid of the newline character at the end of strings(/n).

Here you can see that I’ve placed my gets.chomp inside of a variable input. Now, every time I use input, my program knows to grab whatever the user has placed in my terminal. Sweet! On several lines I’ve compared strings to the input, bringing back methods or simply terminating the program all together. The logical || (or) operator takes in a set of operands and if one or more is greater than 0 (in this case if the user input is equal to my string), then it returns true and passes the code on.

if, elsif, and else statements- Everyone knows these, but if you’re having a hard time grasping, I like to think of them as hot potato statements. if line 18 is true, pull up method. if it’s not, pass the potato (in this case, the input) down to the elsif, and so on.

capitalize method- Another really solid one. See, as I was testing my code, things were breaking. One of those breakages was whenever I’d put in a villager name in the terminal that wasn’t capitalized, it would return false. Not great. This is where .capitalize comes in. Basically what it does is it takes the string that was put in and returns an identical string with an uppercased first letter, this way my code will be able to find the correct name and match it with the input. So, if your user doesn’t like to use the shift key, or they accidentally have caps lock on, your code will fix that!

gsub method- This one has become a meme amongst my cohort, thanks to a very passionate coder who really likes this method. G standing for global, and sub standing for substitute , what this does is replace words, patterns, etc, in your string. Another thing that was breaking in my code was adding a space at the end. While to us, a space is exactly that, a space. To my program, it’s an extra component that was making my user’s input false! So, using gsub, I had it substitute any spaces with empty ones (" ", "") or (“if this is here”, “do this”).

So, my code is coming along, I’m getting my list of names and the info. Cool. But, with the API I was using, I was getting back 391 villagers. On top of that being a long list, maybe you didn’t know how to spell a specific villager’s name or you wanted to randomly select one. What’s easier than typing a name? Typing a number.

to_i method- Standing for To integer, this method interprets leading characters in the string as an integer base. (Ex: "123Balloons".to_i => 123).

between? comparable- I also needed to use this in order to set my parameters for the user, and what it does is brings back a true or false statement if it’s within the (min, max). In my case (1, 391).

But, my villager names didn’t have any numbers already inside of them. How do I get them in?

.each.with_index method- What this basically does is iterates through the block for each new instance and places a number. The difference between each.with_index and each_with_index being that the former takes an optional parameter while the latter does not.

Example from stack overflow:

[:foo, :bar, :baz].each.with_index(2) do |value, index|
    puts "#{index}: #{value}"
end

[:foo, :bar, :baz].each_with_index do |value, index|
    puts "#{index}: #{value}"
end

In the above image, I placed my instance variable villagers and iterated with .each.with_index(1). Basically I made it so that if the user were to use a number, the program would go through each iteration adding a number to each villager and then returning the desired index associated with the villager.

To put all of that together, I needed to add my index to each villager and print that out for the user. From there, I needed to grab (if the user used a number) the index, and match that up with the corresponding villager in order to return the method with all of the assigned attributes.

Calling Methods.

In a lot of my program I’ve called other methods inside of methods. This is important because you don’t want your user to go start>choice>list>done. It makes your app linear and almost annoying to use. You want to give them as much maneuverability throughout your program as you can without overworking yourself. Instead of bringing the user back to the main menu every time they’ve got what they wanted, give them the option to do it again! Put it in laymen's terms as well because you never know. Or, do what I did and hot potato them.

A few things to make sure of while you do your project is to put yourself in the users feet. Even if no one is going to use your app, the best way to “user-proof” is to really put it through the ringer. Will your app break if you add a space? What if something is spelt wrong? What if they just press enter without input? All of that needs to be accounted for, and it’s actually pretty crazy how much this makes you realize that everything has or needs a purpose, and relies on so many other components to print out a simple list of information.

I hope this was as informative for you as it has been for me, and I wish you luck on your endeavors! May your apps be fruitful, your will strong, and your patience stronger.