Skip to content

Instantly share code, notes, and snippets.

@jelaniwoods

jelaniwoods/test-debug.md

Created October 10, 2022 14:17
Show Gist options
  • Save jelaniwoods/17bcaf918c3ca11730183b3eb8a3f22d to your computer and use it in GitHub Desktop.
Save jelaniwoods/17bcaf918c3ca11730183b3eb8a3f22d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
test-debug.md

Lecture Practice

Intro

Last week, we finally started to explore building web applications with the RPS RCAV project,

now we're finally putting together our HTML and Ruby knowledge.

Luckily for us, the process that every Rails app works is pretty formulaic. We just need to remember - R C A V (non-industry term)

From now until the end of time, if you're building a Rails app, you'll need to understand the RCAV process.

Plan for today is to practice R C A V and using forms and params with a couple of projects.

Be sure to ask a lot of questions, if anything seems fuzzy

The first one is called fortune teller

fortune teller

  • open assignment
  • open readme
    • always keep open the readme
      • all the instructions for the assignment are in there
      • important links to relavent chapters and the target too
  • intro debugging assignment
    • visit some route
    • read the error message
    • attempt to understand and debug it
  • bin/server
  • homepage works
    • displays 5 random lucky numbers
    • look into controller to see how this works
    • then into view template

This is the first of a few different debugging projects that you'll have.

Unlike previous projects, with a debugging project your starting point is a completely build Rails app, with all the routes and view templates created but then we planted a bunch of different bugs all over the app

your job is to go through, find, and fix the bugs and get the app running like the target does

The key way to do this is to READ THE ERROR MESSAGE

Error messages try to help you as much as possible, so read them and start becoming familiar with the common ones, it'll help you debug faster in the future

the first time you see an error message, it might take you an hour to debug it. after the tenth time it might take 20 mintues. after 30 times it takes 1 minute, and eventually, you'll get to the point where you see an error message and can instantly debug it.

it takes time, and that's okay

this project and projects like these are designed so that you can see some of the common bugs that students run into when they're first learning rails

learning how to debug is one of the best ways to improve your skills as a developer

the point here is not to practice pattern matching, and visually spotting typos and errors in the actual code-

the point is to read and become familiar with the error messages and what they mean

lets get started

  • look at routes.rb, it's important

    • great place look at the beginning since it's the entry point of our rails applications
    • two routes available
    • if i try visiting anything else, they don't work
    • both routes use the same controller and action
      • it's fine
    • controller is called "numbers" not "application"
      • we can make our own
    • open controller
      • note, that numbers inherits from application controller
      • class inheritence here allows us to use really powerful methods that other people have already defined, like render and redirect_to
      • rails will look in app/controllers for numbers_controller.rb

  • anything fuzzy about each loops?

  • what's the difference between the ERB w/ = vs w/out =?

    • a loop is meant to control the flow, the important operations happen INSIDE
      • the return value of the loop isn't important

  • what happens if we add an = to the end?

    • syntax error

  • Okay let's look at the target

    • unlucky is same as lucky
    • if i visit unlucky no route matches error
      • means we need to define a route
      • a controller
      • Try to finish this out and see if you run into any questions about how all of this fits together
        • don't just copy paste
      • ~ 7 minutes lab
      • go over solution
        • take baby steps

  • uncomment theses routes one at a time in the order from top to bottom.

    • look at the nav
    • btw where the navbar
    • like application controller, layout comes for free and is used by default
    • all of our view templates go into the yield
    • go over aries

  • if you finish, there are these dice roll routes that you can do to get more practice

omnicalc-debug

  • debugging this time is focused on how forms work
    • forms chapter will pretty helpful to have up
  • how forms work
    • what elements and attributes need to added to make a form work
    • is the form valid
    • which values from the form get put into params
  • to make these forms a little more interesting, they use the umbrella actions and will require the API keys from before
    • but the bugs won't be a part of the API logic in the controller

Goal: come into contact with the error message (or lack of error message) and try to debug the behavior you see

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment