DEV Community: Andrea Esparza

My Time At Flatiron School

Andrea Esparza — Wed, 05 Oct 2022 17:57:22 +0000

The past 15 weeks have been a whirlwind. I was, understandably, nervous about starting a bootcamp, but I don't regret it at all. My goal is to dive into each phase of the course and what I learned. While Phase 1 feels like a lifetime ago, I'll start there.

Phase 1: JavaScript

Phase 1 was tough simply because it was first. It was completely new to me, they threw a million different things at us, and it moved really fast. We learned how to write functions and manipulate the DOM in two weeks. Note to self: go back and try that code challenge again. I was lost for most of it, I felt like I was always behind, and the lectures seemed irrelevant. By the time week 3 rolled around and we had to create our first project, things started to click. It wasn't until phase 2, though, when I felt comfortable calling it "vanilla" JavaScript.

Phase 2: React

The moment we were introduced to React, my world turned upside down. I really struggled to understand JS, but now it made way more sense. We learned how to write JSX, update state, and build components. It made such a difference for me during the code challenge and project. During this phase, I really began to appreciate our instructors and their lectures. It finally clicked for me that lectures were one big "putting it all together lab" during this phase.

Phase 3 and 4: Ruby and Ruby on Rails

I'm putting these together because they go together. Similarly to the transition from JS to React, going from Ruby to Rails made a lot of things make sense. In Ruby, we learned about SQL and object relational mapping (ORM), Sinatra, and Active Record. We learned how to make queries and create databases, but it wasn't until we got to Rails that we really took off. With Rails, we were able to do the same stuff as Ruby but faster and more efficiently. Which left room for higher level topics. We learned about user authorization and authentication, RESTful routing, and building a full-stack application with a React frontend and a Rails backend.

Phase 5: Capstone Projects

The phase 4 project was special because it was a) our last group project, and b) our capstone would be very similar in size. Working on this project has been a rollercoaster between "I know exactly what I'm doing" and "what does that mean!?!?!" My cohort has developed a very tight relationship so we have helped each other out. It's been fun watching everyone create something they are proud of.

As I get ready to present my project, I am filled with nostalgia. I said earlier that phase 1 feels like a lifetime ago. My life before that feels even farther. I am so glad I signed up for this program.

Basics of Rails Generators

Andrea Esparza — Thu, 15 Sep 2022 16:22:12 +0000

Rails generators have become common practice for me since we started learning Rails because they have streamlined the process of creating files. The purpose of this blog is to have a descriptive list of the different generators available. Above all, Rails generators are terminal commands. If you follow their rules and conventions, you will be able to use them efficiently.

Set Up

Before you start typing terminal commands, it's important to know what you are going to create. If you are creating a table, make sure you know the name of the table, the names of the columns, and the datatype for each column. While it's not obligatory to write out every piece of information in the terminal, it does make it more efficient. For each table we follow our MVC - Model, View, Controller. Therefore, we will be creating a model, a controller, and a serializer for each table.

Model

The first generator on the list is the model. This needs to be first because it's the piece of the puzzle that sets up our table and its columns. To create the model, run this command:
$ rails generate model table_name column_a:datatype column_b:datatype and so on. This command also creates the migration that goes with the model.

One of my favorite things about Rails is that it lets us use 'g' instead of typing 'generate.' It also sets the default datatype to be string, so you don't need to specify that one. All other datatypes need to be specified.

Controller

The controller is the middle-person between the model and the view. We can create it using a rails generator as follows:
$ rails g controller table_name

View

For the view side of things, we use serializers. Therefore, we will use this command:
$ rails g serializer table_name

There's gotta be another way...

There is! When you are setting up a Rails application and you know that you're going to need a model, a controller, and a serializer, we can use a resource generator.

Resource

The resource generator takes care of creating a model, a controller, a serializer, a migration, a test suite, and adds the route. The command looks like this:
$ rails g resource table_name column_a:datatype column_b:datatype

What if I mess up?

If you make a mistake or need to redo any of these generators, we can use the drop command as such:
$ rails drop [generator] table_name
The generator depends on what you need to drop, whether it be a model, a controller, a serializer, or a resource. And again, Rails lets us use 'd' instead of the word 'drop.'

Final thoughts

Rails generators are a way of creating files through the terminal, but it doesn't mean it's the only way of doing things.
At Flatiron, we've learned to add --no-test-framework at the end of our rails generator commands so we don't mess with the existing test suites.

Instance vs Class Methods in Ruby

Andrea Esparza — Wed, 24 Aug 2022 15:56:04 +0000

The term "self" in Ruby was one of the toughest things to wrap my head around. There are times when "self" refers to a class and there are times when "self" refers to an instance of that class, which affects the way we write methods.

Classes and Instances

To understand instance and class methods, let's first dissect what instances and classes actually are. A class, essentially, is a collection of instances. If we think about it along with the database, the class represents the overall table and the instances represent each row of that table.

Instance vs Class Methods

Now that we understand how instances and classes are related, we can talk about methods. Methods are what we use to manipulate and extrapolate details from our database. We can create methods to find, sort, delete, and so much more. The million dollar question becomes "do we want our method to affect the class as a whole, or do we want our method to affect each instance?"

Class Methods

If we want our method to affect our class as a whole, then we need to write a class method. Class methods are usually presented with a period, such as ClassName.method_name. This let's us know that our "self" is the class, so our code would look something like this:

class ClassName
   def self.method_name
      ClassName.method
   end
end

Instance Methods

If we want our method to affect each instance of the class, then we need to write an instance method. Instance methods are usually presented with a hashtag, such as ClassName#method_name. This let's us know that our "self" is the instance, so our code would look something like this:

class ClassName
   def method_name
      self.method
   end
end

Umm, okay but I'm still confused

If you're still feeling like this "self" thing is daunting, I recommend using a console to test things out. At Flatiron, we've been encouraged to start a pry session to test our methods out in the console. For class methods, we type ClassName.method_name. For instance methods, we need to think of a specific instance to test. One built in case is the "first" instance. That would be the first row of the table. So when testing methods in the console, we can type ClassName.first.method_name.

Conclusion

I'll leave you with something that I've repeated to myself many times: class methods affect the whole class, a.k.a. the whole table; instance methods affect an instance of the class, a.k.a. a row of the table.

Search Bar Functionality Using State In React

Andrea Esparza — Wed, 03 Aug 2022 00:20:00 +0000

Adding a search bar is one of the most user friendly components of a website. Without it, users would be sifting through countless items trying to find what they are looking for. Luckily adding one only takes a few steps.

State

First and foremost, we need to import useState with React. useState is going to let us change the target value to match what the user types in the search bar. Without useState, we wouldn't be able to keep track of that change. Along with importing useState, we need to define our state variables. In this case, our default state will be an empty string since users will type strings into the search bar.
While the name of the variables doesn't truly matter, convention dictates that we use the pattern demonstrated in the image.

Filtering Array

The next step in the process is to filter the existing array so that our search query can match the string the user types to it. Our updated code should look something like this:

Event Handler

Since our state depends on user input, we can use an event handler to alter our state. I personally prefer to declare the function outside of the return so the JSX is more legible. In this case, we can use an onChange event since the user input is a type of change. Thus, our code should look as follows:

Rendering Array

The final step in this process is to render content. If we return our original array, the search won't work because it's not being affected, therefore we need to render our altered array, which is named filteredArray in this case. Here's what our code should look in the end:

Other Cases

In the example above, the array consisted of numbers. When dealing with letters, we need to add a check in the form of .toLowerCase() so the user can input any letter in any case and it won't affect the search. It should look as follows:

Navigating the Terminal for the First Time (on a Mac)

Andrea Esparza — Wed, 13 Jul 2022 04:02:20 +0000

Many years ago, I watched a friend of mine access a file in my computer using solely the terminal and it blew my mind. She moved so quickly and was unfazed by what seemed like gibberish to me. I remember thinking there was no way I could ever do that. And yet I am here now, by no means an expert, feeling confident that I can get from point A to point B using only terminal commands.

Opening the Terminal

Starting from the very beginning, it's important that you, the user, are feeling confident as soon as that terminal window pops up.

Print Working Directory

Now is the time to introduce our first command (don't type the "~"):
~ pwd

"pwd" stands for "print working directory," which is not very helpful if you've never done this before. What "pwd" does is it shows you a path from the very beginning to where you are now. It might not show much the first time you run it:

That just means I am at the beginning and there is no other folder (or directory) left.

List Directories

Let's take a look at our next command (again, don't type the "~"):
~ ls

That's a lowercase L as in Larry, by the way. "ls" means "list", as in list all the folders (directories) ahead of us. It's a list of ~possibilities~.

"pwd" and "ls" are both very helpful to see where we are, where we've been, and where we can go in the terminal.

Change Directory

Buuuuuut those two don't actually do anything or take us anywhere. That's where this next command comes in (don't type the "~" or the brackets):
~ cd [directory-name]

"cd" (to me) means "go to." It actually stands for "change directory" but you already know how I feel about that word by now. So if we look at the image above one more time, we can navigate to "Users" by typing the following command:

The change here is subtle, but you can see the "/Users" is now before the "%" meaning we are inside of the directory (ugh) called Users.

There are many other commands in the terminal, but these three are the ones I use the most and I think are the most essential.

Tl;dr
pwd to see where you are and where you've been
ls to see where you can go
cd to go!