Forem: Olivia Pomeroy

Learning to Learn How to Code

Olivia Pomeroy — Wed, 20 Apr 2022 19:30:25 +0000

How to Learn

I started a software engineering bootcamp about 2 months ago, and while I wasn't expecting it to be easy, I don't think I fully realized what parts would be the most challenging. One of those for me was re-learning how to learn. I had been out of school for a couple years before beginning the program so when I went back into a learning environment, I wasn't really sure what best practice would be- especially with a topic I had no previous experience in. This are some tips that I found helpful while re-navigating how to learn.

Learning Methods

There are three main learning methods that people learn by: watching, listening, and doing it themselves. There may be one that people gravitate more towards, however it seems the best practice is to do a combination of the three. Watching youtube videos and tutorials was something that helped me through, and then creating "playgrounds" in my terminal or messing around in REPL to try to replicate what I had just seen or read. With coding in particular, the most beneficial learning method I found was to do it myself. That way if I get stuck, you learn how to get good at googling, how to ask the right questions, and how to find the answers.

Practice

Practice! Practice! Practice! Continuous practice helps strengthen our memory and can get us used to thinking in specific ways, rather than just memorizing code. By practicing, we are constantly learning new material as we go through, making it easier each time.

Test Yourself

Testing yourself is a great way to see what you have learned and what you still need to develop. One of the hardest things with learning, is feeling like you're not doing it well. But that's ok- because it's just learning! We need to put away the thoughts that we have to be perfect or that we can't make mistakes, because we're going to (a lot), and those mistakes are what's going to help us out in the long run because we can target our skillset.

Write It Out

The reason why practice is so good is because it is repetition and get's our brains used to looking at similar information. Writing things out by hand is known to also have a longer-lasting effect in our memory. It sounds weird for coding to grab a pen and paper, but something I found helpful was to write out flashcards when I was first starting off with the new terminology and any specific syntax that I had trouble with.

Speak it Out Loud

Similarly to writing it out, speaking it will also help store it in your memory better than just reading about it. In addition, it also is proven that it's helpful to try to relate the topic to something you have already learned or know. You can learn in building blocks. You can relate it to something similar (like relating how Ruby methods are like JavaScript functions), or you can relate topics to metaphors within your own life. Making things personal will also help better store it within your memory.

Teach

When learning something new, although maybe anti-intuitive, it's very helpful to then try teaching that concept to another person. If you have classmates, try to answer their questions when you can. Or challenge yourself to see if you could explain some concepts to a younger child. It will help you solidify any understand you have, and it may help you hone in on what you don't.

Primacy vs Recency

Primacy effect is when you better recall information you learned first and recency effect is when you better recall information you learned last. Both are shown to better store information into long term memory than what was learned in the middle. We can incorporate both of these while we study by starting with concepts that are trickier for us, and then ending by reviewing those topics again.

Keep Learning

Learning is something that can be practiced and the more opportunities we take to learn the easier it will be because our mind will already be used to that state.

Be Kind to Yourself

It's okay to make mistakes. That's how you learn. It's important to be kind to yourself, your brain, and your body. Getting a good nights sleep can help improve our memory. Staying hydrated as well. As much as we want to cram a night before, it's not the most productive thing we can do to actually learn and solidify information. And take plenty of breaks!

Have Some Fun With It

You're going to dread learning if it's not something you're interested in or you're making the information more boring than it may need to be. Here is an article with some mnemonic devices people have used to help them remember topics in software engineering. Some examples are

'I never remember that . = class and # = id in CSS, so I use ‘say no to drugs’ to remember that ‘hash is not class’.” hill79

“.unshift - makes it bigger. Longer word than .shift

.shift - makes it smaller. Shorter word than .unshift” da02

Happy Learning!

Sources

https://www.verywellmind.com/understanding-the-primacy-effect-4685243#:~:text=The%20primacy%20effect%20involves%20rehearsing,items%20in%20short%2Dterm%20memory.

https://www.computerworld.com/article/2947706/how-programmers-remember-all-that-programming-stuff.html

https://www.entrepreneur.com/article/323450

https://www.verywellmind.com/how-to-become-a-more-effective-learner-2795162

https://zapier.com/blog/learning-new-skills/

Ruby on Rails: Validation Errors

Olivia Pomeroy — Wed, 06 Apr 2022 16:27:27 +0000

Validation

Validations are used in Rails to ensure the data saved to the database is valid. It helps prevent any issues further further down the road. Such as if a user were to fill out a form, it's important they fill it out with valid data- like confirming their phone number is 10 digits long. This will save a lot of debugging and headaches, preventing that issue to persist until it's used.

There are a couple ways to check if the object is valid. In rails, validations are run before saving an active record object, and if there are errors then it will not save. If a user tries to input a phone number with 9 digits, the validation will recognize it is not valid and won't save the information in the data base, giving the user an error message.

We can use valid? or invalid? to check this.

class Person < ApplicationRecord
   validates :phone, presence: true, length:{ minimum, 10 }
end

We can open an irb/console session and test out the validity of our Person class, by saving a new instance method.

irb> Person.create(phone: 555-321-112).invalid?
=> true
irb> Person.create(phone: 555-321-112).valid?
=> false
irb> Person.create(phone: 555-321-1128).valid?
=> true

valid? will trigger the validations and return true if no errors were found and false if there are errors. invalid? is the opposite and will return true if there are errors and false if there aren't errors.

Validation Errors

We can run our own validations while writing our code to check the validity as we work. After Active Record completes the validations, any errors that may arise can be looked at through errors instance methods, which will return the errors. In order for an object to be valid, the collection of errors must be empty after running the validation. We'll go through errors collection to help us do this.

Errors Collection

errors : errors returns an instance of the class that contains the errors. It allows us to further look into the different details of the error, so we can attach other methods to the end of it. Some common methods to pair with errors is .message, .full_messages (to_a alias), and .full_messages_for(:attribute)

irb> person = Person.new
irb> person.valid?
=> false
irb> person.errors.message
=> "is too short(minimum is 10 characters)"
irb> person.errors.full_messages
=> ["Phone is too short (minimum is 10 characters)"]
irb> person.errors.full_messages_for(:phone)
=> ["is too short (minimum is 10 characters)"]

irb> person = Person.new(phone: 555-643-2342)
irb> person.valid?
=> true
irb> person.errors.full_messages
=> []

errors[] : To verify a particular attribute of the object we can run errors[:attribute]. It will return an array of error message strings for that particular attribute, and if there are no errors it will return empty.

irb> person = Person.new(phone: 555-123-123)
irb> person.valid?
=> false
irb> person.errors[:phone]
=> ["is too short (minimum is 10 characters)"]

irb> person = Person.new(phone: 555-123-1234)
irb> person.valid?
=> true
irb> person.errors[:name]
=>[]

errors.where : returns an array of error objects. We use this compared to errors[] when we want more information than just the message. From the objects, you can then look further into it to get more information.

irb> person = Person.new
irb> person.valid?
=>false

irb> person.errors.where(:phone)
=>[...] #all errors for :phone attribute. Both presence and length errors

irb> person.errors.where(:phone, :too_short) 
=> [...] # :too_short errors for :phone attribute

irb> person.errors.where(:phone).first.attribute
=> :name
irb> person.errors.where(:phone).first.type
=> :too_short
irb> person.errors.where(:phone).first.options[:count]
=> 10

errors.add : creates the error object by taking an attribute, an error type and additional options hash. These are helpful if you are creating your own validators

class Person < ApplicationRecord
  validate do |person|
     errors.add :phone, :too_long, message: "has too many numbers"
  end
end

irb> person = Person.create
irb> person.errors.where(:phone).first.type
=> :too_long
irb> person.errors.where(:phone).first.full_message
=> "Phone has too many numbers

errors[:base] : can add errors to the objects state as a whole instead of being related to a specific attribute as with errors.add. Also good for when you are writing your own validations.

class Person < ApplicationRecord
  validate do |person|
    errors.add :base, :invalid, message: "This phone number is invalid because ..."
  end
end

irb> person = Person.create
irb> person.errors.where(:base).first.full_message
=> "This phone number is invalid because ..."

errors.clear : used when you intentionally want to clear the errors collection. It doesn't actually make the object valid though, the errors collection will be empty but next time you save or validate that method, the validations will run again.

irb> person = Person.new
irb> person.valid?
=> false
irb> person.errors.empty?
=> false

irb> person.errors.clear
irb> person.errors.empty?
=> true

errors.size : returns the total number of errors for the object.

irb> person = Person.new
irb> person.valid?
=> false
irb> person.errors.size
=> 2 #phone does not exist, and is less than minimum length.

irb> person = Person.new(phone: 555-123-123)
irb> person.valid?
=> false
irb> person.errors.size
=> 1 # phone exists, but below minimum length.

Errors in relation to custom methods

We can add errors to our collection when they are invalid. We can conditionally render out errors.

validate :phone_cannot_be_more_than_number

def phone_cannot_be_more_than_number
  if phone.present? && phone length > 11
  errors.add(:phone, "number is too long")

When added to custom methods, it will run every time you call valid? or save the object, unless we give it an :on option to validate the method with either :create or :update.

Sources

https://guides.rubyonrails.org/active_record_validations.html#custom-methods

https://api.rubyonrails.org/v6.1.3/classes/ActiveModel/Errors.html#method-i-messages

https://guides.rubyonrails.org/active_record_validations.html#working-with-validation-errors

Active Record Associations Guide

Olivia Pomeroy — Tue, 22 Mar 2022 23:53:24 +0000

Active Record Associations

Programmers use associations in code to be able to access data in different tables. Associations allow us to shorten down our code and makes things simpler but helping us not write as much SQL. Associations follow the idea of "convention over configuration", which is the most ideal practice when it comes to programming.

Types of Active Record Associations

There can be different types of relationships between Classes. We're going to go through the following:

one-to-one
one-to-many
many-to-many

Our Example

To be consistent throughout this blog, we're going to stick with one example and create different associations through that. In our example, we are going to have a Cookbook, which has an author, a publisher, recipes, and ingredients. We'll walk through the different relationships each of these may have with one another.

Where to Begin

The best place to start is by mapping out what data we have and understanding how our different tables will relate to each other. This helps us understand what kind of relationship the Classes have with each other, and will especially help us figure out where the foreign keys belong. The best way to do this is by creating an Entity Relationship Diagram (ERD).

This ERD shows us our different tables, which columns that may have, and a rough idea as to the relationship amongst by tracking which tables have other tables foreign keys. This table may make a bit more sense as we walk through each relationship so take a look back at it along the way.

Now we can start building out our associations in code by using Active Record macros (a method that helps write our code).

One-to-One Relationship

A one-to-one relationship means that one table belongs to solely another. In our example, we can say that the cookbook has one publisher, and that publisher belongs to the cookbook. We write this using the has_one macro along with the belongs_to

class Cookbook < ActiveRecord::Base
  has_one :publisher
end

class Publisher < ActiveRecord::Base
  belongs_to :cookbook
end

Syntax Notes: has_one and belongs_to both will point to a word in singular form.

This establishes a one-to-one, bi-directional connection since they point to each other.

We can establish a one-to-one, one-directional connection by using belongs_to on it's own. Such as, an editor may belong to a publisher, but the publisher may not always have or use the editor.

class Editor
  belongs_to :publisher
end

We can create another one-to-one, bi-directional connection by using a join table. In this case we would use the macro has_one through:. We have an author, that has a publisher, who publishes their cookbook. Therefore, the cookbook has an author. The publisher belongs both to the cookbook and the author, as a "middle-man". We would write this like this:

class Cookbook < ActiveRecord::Base
  has_one :publisher
  has_one :author through: :publisher
end

class Publisher < ActiveRecord::Base
  belongs_to :cookbook
  belongs_to :author
end

class Author < ActiveRecord::Base
  has_one :publisher
end

Note: The order of macros matters! We need to put our has_one :car, before going through it in our Owner class.

One-to-Many Relationship

A one-to-many relationship means that one class has many instances of another class, and that second class will belong to the first class. Our cookbook has many ingredients in it, and those ingredients belong to the cookbook. We can write this out using the has_many macro, along with the belongs_to macro.

class Cookbook < ActiveRecord::Base
   has_many :ingredients
end

class Ingredient < ActiveRecord::Base
   belongs_to :cookbook
end

Syntax Notes: has_many will always point to a word in plural form.

If you ever get confused, it's helpful to say aloud what it would sound like, as Ruby is very programmer friendly and makes it sound like our day to day grammar.

Many-to-Many Relationship

Many-to-many means one table can have many instances of another, and visa versa. We've established our cookbook has many ingredients. Those ingredients make up (belong to)a recipe. We can then say our cookbook has many recipes, through the ingredients it has listed. We would write this using the has_many through macro.

class Cookbook < ActiveRecord::Base
   has_many :ingredients
   has_many :recipes, through: :ingredients
end

class Ingredient < ActiveRecord::Base
  belongs_to :cookbook
  belongs_to :recipe

class Recipe < ActiveRecord::Base
   has_many :ingredients
   belongs_to :cookbook
end

In this case, the Ingredients class is a join table, because it joins the relationship between the two others, by allowing Cookbook to go through it to access Recipes.

We can also use the macro has_and_belongs_to_many which creates a direct many-to-many connection with another model, without the joined table. We could say we have a recipe that combines two ingredients, to then use as an ingredient in another recipe (think making your own pasta sauce). The recipe has many ingredients, the ingredients have many recipes, the recipe belongs to the ingredients, and the ingredients also belong to the recipes. (Ik ik, it's a lot). This is how we would write it:

class Ingredient < ActiveRecord::Base
  has_and_belongs_to_many :recipes
end

class Recipe < ActiveRecord::Base
  has_and_belongs_to_many :ingredients
end

*Of note, this does not follow the relationship set up with our ERD since there will be a change to the foreign keys. In this situation, another join or junction table will be created to hold both foreign keys. The standard is to call the join table "recipes_ingredients".

Creating Associations during Migration

We have been creating our associations through macros in our classes. We can also create associations when we make our tables before migration, which will help assist us with setting up the foreign keys. For example with our Cookbook:

class CreateANewCookbook < ActiveRecord::Migration[6.1]
  def change
    create_table :cookbook do |t|
      t.string :name
    end

    create_table :ingredient do |t|
      t.string :name
      t.belongs_to :cookbook
      t.belongs_to :recipe
    end

    create_table : recipe do |t|
      t.string :item_name
    end
end

Polymorphic Associations

Polymorphic associations are when a model can belong to multiple other models, but with only a single association and doesn't go through a join table. Let's say we have food pictures. Those pictures could either belong to a recipe or it can belong to the cookbook (spread throughout not connected to the recipe). These two locations aren't connected to each other, and the pictures have a single association with each.

class Picture < ActiveRecord::Base
  belongs_to :imageable, polymorphic: true
end

class Cookbook < ActiveRecord::Base
  has_many :pictures, as: :imageable
end

class Recipe < ActiveRecord::Base
  has_many :pictures, as: :imageable
end

*imageable is an unwritten naming-convention. Imageable means that the Picture model doesn't belong to either Cookbook or Recipe, but belongs to imageable, which can then be used to create the association between either Cookbook and Picture or Recipe and Picture.

To Conclude

When we establish these relationships, it allows us then to use various methods on the classes. If we create a relationship between Ingredient and Cookbook, we can then call self(Cookbook).ingredient as a method, and so on and so forth. These Active Record Associations act as our getter and setter methods we may have used previously, so we no longer need to initiate or read the instance, because this does it for us.

You know have your associate degree - Happy coding!

Sources

https://guides.rubyonrails.org/association_basics.html

https://stackoverflow.com/questions/59173076/correct-foreign-keys-for-has-and-belongs-to-many-association

https://www.pilanites.com/polymorphic-associations-rails/

Understanding Inverse Data Flow

Olivia Pomeroy — Wed, 09 Mar 2022 04:06:47 +0000

This blog requires some base knowledge of Props and State in React. You can read up on both here.

What is Inverse Data Flow?

Up until this point, we have learned that the way data flows is from a parent component to a child component in the form of a prop. With inverse data flow, we are switching that flow so the data is passed up from the child component to the parent component.

How Does It Work?

In order for a child component to pass up data up, the parent must pass down a callback function to the child. The callback function will be passed down as a prop to the child (like in regular data flow). By having the function defined in the parent component, we can invoke it in the child and then the parent will have access to the passed data.

Conceptualization

This is a pretty important concept in React and something that you can use all the time. Once you get the hang of it, you can use it for component reusability, cleaner code, rendering components and help with your events. Before we jump into actually writing out code to show how it works, let's break it down to a very simplistic concept, using a situation many may be familiar with outside of code. Take a look at this diagram and below we will walk through how it helps explain inverse data flow.

We have our parent (mom) and two of her children (Bob and Sally). Mom gives Bobby some toys (our state data) and Bobby now has access to those toys. Bob's sister wants access to toys as well so she asks Bob. Bob says no- this is important to note because Children cannot pass data to another child component. It must pass through the parent first and then to the child. Sally asks mom for some toys and mom goes to Bob, who has all the toys(data). She puts out her hand (callback function) and Bob hands her a toy(invoking callback and passing data back up to parent). Mom now has possession of the toy, and she could hold it and do something else with it, but instead she passes it back down to Sally (setting a new state). To put it into a hierarchical structure, it'll look like this:

Seeing it in Code

Now with that visualization of how data is passed, let's walk through an example of code.

We are starting with an App component (our parent), which has GroceryItemsList and GroceryCart as children components. We are keeping State in our App component (an array of groceryItems)and passing it down to GroceryItemsList, and then iterating over it so it creates a list of individual grocery items(an object). Our goal is to be able to click on a GroceryItem and have it added to our GroceryCart component. This is visualization of our data flow:

Let's start by making a callback function in our App component and passing that as a prop to our GroceryItemsList.

function onGroceryItemClick(item) { //this is our callback function
 console.log("We are adding this to GroceryCart", item) //making sure it passes it down and back up smoothly
}
  return (
    <div> 
        <GroceryItemsList 
            onGroceryItemClick={onGroceryItemClick} //we are passing our callback function as a prop
            groceries={groceries} 
        />
        <GroceryCart />
    </div>
  )
}
export default App;

Now we need to go into our GroceryItemsList and destructure our prop, and pass it along to our GroceryItem. Of note: we are passing along our onGroceryItemClick callback function as a prop but naming it handleGroceryItemClick to make it clearer what it will be doing.

function GroceryItemsList({onGroceryItemClick, groceries}) {
   const groceryItem = groceries.map((groceryObj) => {
      <GroceryItemCard
         key={groceryObj.id}
         groceryItem={groceryObj}
         handleGroceryItemClick = {onGroceryItemClick} //passing callback down another child level
      />
));
  return(
    <div> 
       {groceryItem}
    </div>

Now in our GroceryItemCard, we are going to take that callback prop and give it the data it needs to invoke it.

function GroceryItemCard({groceryItem, handleGroceryItemClick}) {
   const {name, description, price, image} = groceryItem

   return(
      <div onClick={()=> handleGroceryItemClick(groceryItem)}> //This says 'when we click on the GroceryItemCard we are going to invoke our function and send it a groceryItem (an object)
        <img src={image} alt={name} />
        <h5>{name}</h5>
        <p>{description}</p>
        <p>{price}</p>
      </div>

We now see that when we click on a GroceryItemCard it is console.logging:

We are adding this to GroceryCart
 {id:1, item:'Milk', price:'$3.99', brand:'Lucerne', image:'https://media.istockphoto.com/photos/kefir-milk-or-turkish-ayran-drink-are-poured-into-a-glass-cup-from-a-picture-id1198789194?b=1&k=20&m=1198789194&s=170667a&w=0&h=f85XhCzCWQhdFn0LaRckyOkJui88sYNoctN9zEmS4y0=' }

We have successfully passed down a callback function and invoked it from child to parent! That's inverse data flow!!

Now that the parent has the GroceryItem object, it can set the state of the GroceryCart to that object and render it.

function onGroceryItemClick(item) { //this is our callback function
 setGroceryCart([...cart, item]) //Adding item to our GroceryCart by setting its state
}
  return (
    <div> 
        <GroceryItemsList 
            onGroceryItemClick={onGroceryItemClick} 
            groceries={groceries} 
        />
        <GroceryCart />
    </div>
  )
}
export default App;

And there we go- Inverse Data Flow. In my experience inverse data flow works really well for events (onChange, onClick, etc (especially search bars or any kind of filters)). It helps with component reusability and organizing where we put State in our library. It is a tricky concept to understand, but what's helped me is to make sure you name props appropriately and work from top to bottom, from parent to child, so you can keep track of what is being passed down.

References:
https://reactjs.org/docs/thinking-in-react.html

How to Debug in JavaScript

Olivia Pomeroy — Tue, 15 Feb 2022 21:10:12 +0000

How To Debug In JavaScript

Unlike the systems we use- we are human! Which means we are going to make mistakes, and probably a lot of them. There is nothing worse than writing a giant chunk of code, just to realize it isn't working the way you hoped. Is it a syntax error? Did you forget to call the function? Thankfully there are some tools we can use to help us figure out the issue so we can continue creating some really cool stuff! In this post we're going to understand what debugging is and look into two options on how to debug in JavaScript.

The browser I'll be using is Chrome, but most other browsers have a similar process.

What is Debugging?

Debugging is a tool developers use in order to go through their code and fix any errors that may arise. It can be done by examining a line of code to ensure it runs the way we'd like, or by forcing the code to pause at a certain line, letting us inspect the set block of code.

Using Console.log()

Console.log() is one method of debugging we can use. This is part of the browser's developer console panel. To access the developer console, you can right click on the browser page, click inspect, and go to the console panel. (You can also click on the view tab at the top of your computer, click developer, and then developer tools). Console.log() can be written in the browser's developer tools itself, or wherever your line of code is written. To use it in the browser's developer tools, follow along below:
Say we had a variable set as an array:
const flowers = ['Orchids', 'Tulips', 'Roses'

We can check that we declared it correctly by console logging console.log(flowers); in our console. We should get an output of (3) ['Orchids', 'Tulips', 'Roses']

That's what we got! We can see that our variable 'flowers' is now assigned to that array, so we can use it in future codes without worry.

For more complex functions, we can implement our console.log() within the function and verify it logs to our console. Such as, if we had the following variable and event listener:
const btn = document.querySelector("#button") btn.addEventListner("click", function() { console.log ("I was clicked"); })
Once we invoke that function, when we click the button we should see in our console:
I was clicked

This was important to us because it confirmed that we properly set a variable, grabbed it, and assigned an event listener to it. Now that we know the button works, we can continue on writing what we would actually like it to render to the DOM.

Essentially, console.log() will do just that- log what we choose in the console!

Using Debugger Keyword

The debugger keyword is...(wait for it)... "debugger;". Like console logging, debugger can be done in the browser's developer tools(under the source panel), or inputted into your line of code. The JavaScript code will run until it hits the debugger keyword, which acts like a breakpoint. Debugger allows us to pause the code, which means we also can resume the execution with the provided buttons (check out this linkfor a more descriptive walk through of how to use the buttons in developer's tools sources. Follow along in the example below to see how to implement debugger in your line of code.
This is a basic function in our index.js to make the concept a bit easier:

function math (){
 let x = 2 * 5
 let y = 3 / 8
 let z = 9 - 9  
 debugger;
 return z + y;
}
console.log (math())

(A debugger within a debugger! The reason for putting console.log is to just to show you where the debugger keyword stops the code, as shown later in this section)

If we open our index.html in our browser, and navigate to our developer tool's source panel, when we run this code we should see this:

The code stopped executing where we placed the debugger, so that we could inspect everything was running properly above it. We see the variables are returning the proper data so we can resume our debugger. (It's important to note that because it has stopped at the debugger and only able to read what was declared before it. Console.log(math()) value is not appearing in our console because it comes after the debugger)

Once we resume our execution of code, it will then give us the desired output.

To implement debugger in our developer's tools, we can choose where we would like to place it by using the pane in the right-hand side (or bottom depending on how wide your browser is) of the source panel. The YouTube Channel Google Chrome Developers does a great job of showing you where you can place the debugger.

When to use Console.log vs Debugger Keyword

So which one is better? Well, that depends on what you already know about your code. It's nice using console.log() when you have a better understanding of your code and exactly where to place it. If you want to make sure your "click" event listener is working, console.log a message and then click on the button! I personally think console.log() is great for when you are checking as you go, practicing frequently.

The debugger keyword is good to use when you get an error message and aren't really sure where the error could be. Instead of going back and console logging multiple things, it would be best to put in the debugger keyword to scan through a general area, and pause to take a look at each line of code. The debugger keyword as a debugging tool can be faster and more efficient if used in this way, and allows us to work with the code more than console logging does.

Now Go Debug Like an Exterminator

In short, we went over that debugging is a tool we can use to help us find our errors and fix them. As a developer, a lot of our time is spent debugging and we need ways to make this process more efficient. We learned we can use our console.log() or debugging keyword to help us out, and the different situations we may use one over the other. It's important we debug as we go, in order to help ourselves out in the long run. Bugs will happen (and that's okay!), just remember to take it slow, work through the errors, and you'll be back to creating in no time!