learning_new_tools.md

Learning to Use New Tools

General Google Tips

• Be sure to include search terms for the specific context in which you’re using the tool:
  • ‘RSpec Rails’ will return results that give you a gem specifically to use in Rails apps
  • 'Capybara RSpec Rails’, or ’select second div Capybara' will return more relevant results than ‘Capybara'

First Time Setup

• If you’re looking to set a tool up in your application, check docs to see if they have some description.
• Within the docs, check to see if there’s a section specifically geared towards setting it up in your environment.
• In rails, frequently you’ll find the first step is to add a Gem to your Gemfile. From there, you may need to update additional files. For example:
  • Tools that help with testing frequently require you to update your spec_helper or (if you’re using RSpec) rails_helper or make adjustments to your spec directory
  • Tools that help with user interaction or styling often require you to make updates to files in your app/assets directory and potentially your app/views/layouts/application.html.erb.
  • Tools that provide additional convenience when interacting with your database may require adjustments to your models (e.g. adding has_secure_password when using BCrypt)

Specific Functionality

• When trying to learn how to use a tool remember that in many cases you will not be the first one to encounter this problem, but also remember that problems that look similar may not be as helpful as they first appear.
• Be sure to check multiple sources.
• If it seems like implementing a solution is more difficult than it should be take time to step back to see if there might be alternatives you haven’t considered.
  • Open a few tabs (around five is a good starting point) and check to see what you’re seeing that they have in common. Try to get a general sense for available solutions before more carefully picking one or two to read more carefully.
  • In documentation:
    • If documentation seems scarce, check for links in the documentation to more detailed guides. For example, the FactoryGirl documentation on GitHub is extremely sparse, but includes links to more detailed documentation and [a video] (https://thoughtbot.com/upcase/videos/factory-girl?utm_source=github&utm_medium=open-source&utm_campaign=factory-girl) with additional information.
    • Check for code examples and see what information you can pull from them. Be sure to pay attention to:
      • Comments included in snippets. Often the first line of a snippet will include a path to a file meant to indicate where in your application the code will live.
      • Capitalization. As in our code, capitalized words will generally indicate a class that is being used in the code. Lower case variable names will often indicate instances or method calls.
      • Descriptions. Generally there will be some description of the example that developers are using to document functionality. Class, attribute, and sometimes method names will suit this specific example, but can be replaced with the specific names in your application. One of your key tasks will be to determine which names/conventions are specific to the example (that can be changed to suit your needs), and which are specific to the tool (which you will need to follow when using the tool). Good documentation will attempt to make this clear, but sometimes you will need to experiment.
      • Other Conventions
        • A commented out line with a file path (e.g. #spec/spec_helper.rb) will indicate that the code on the following lines exists in that file.
        • In order to identify methods without attaching them to a specific object or instance, the convention is to use a prefix of . or #. Class methods are indicated with a . (e.g. .average_sales_price), while instance methods use the prefix # (e.g. #formatted_price).
  • On StackOverflow:
    • Skip the question - sometimes a confused person’s thinking can confuse you further
    • Look for answers that have many up votes and/or a check - this is the community’s way of confirming a solution
    • Prefer answers with actual code snippets
    • Don’t skip the comments on the solution - sometimes a solution will get a check/upvotes, but comments will point out potential flaws/drawbacks/alternatives
  • On blog posts:
    • Prefer posts with code snippets that are using similar tools.
    • Check for other solutions before you install an additional tool to make what you’re currently using work.
    • As with all problem solving, maintain a bias towards action. Once you’ve collected information from various sources, tend to try to implement some functionality to see what it does rather than identify a perfect solution. Consider checking out a branch if you feel particularly unsure of your course of action.

Checklist

• Google the tool with search terms that will maximize the value of your results.
• Open at least six tabs. At least one of these should be a page with official documentation.
• Skim the tabs to see if there are any patterns.
• Pick one or a combination of approaches to try.
• Try to implement!
• Debug with the tools you have (pry/byebug/save_and_open_page).
• Reach out to cohort members, instructors, mentors, or other devs.
• Consider alternative solutions.