DEV Community: Daniel Trejo

Project 5 Capstone

Daniel Trejo — Thu, 03 Oct 2024 17:32:10 +0000

I just completed my Phase 5 and it threw me for a loop. It was one of the hardest challenges I have ever done. I have never seen so many issues to debug and reasons I wanted to just quit but with every inch I climbed, I would learn something new and get that much closer to finally getting it done. The easy part was starting the project. Creating all the initial routes and models took no time at all.

The hardest part was re-familiarizing myself with React and all that front end stuff. That is what made this project take so long. Trying to remember how to code all the handleSubmits, handleDelete, etc... took so freaking long. There are tons of people out there that might look at this blog and say "Oh, all that stuff is easy", but I'm still learning and I plan to keep on learning. This program is so insanely good because not only do you get amazing teachers and staff but you also make a lot of friends. Having these online cohorts really made it easier to reach out and talk to other.

I definitely will never stop learning code. It is so cool and fulfilling to get a project working just right. It's worth all the struggle to me. For some reason specifically one of the biggest issues I ran into was my CRUD, usually that wasn't much of a problem but once I created one, the other stopped working which was super annoying for a few hours. Finally I was able to get them both to work but not fully. I am able to update fully and the delete worked on the first try, but any following attempts to delete would just throw me an error that I couldn't figure out.

If you are thinking about doing coding at all regardless of the field you go into. I fully recommend it because it is one of the most fulfilling things you can do. There is a lot of long nights and a lot of coffee, but I still think it's fun. One thing I learned is the importance of teammates. Working with a group on one project relieved so much stress because you weren't the sole person responsible for the entire project. Being able to bounce ideas of off people and ask for help is something you will be doing for the rest of your life and I'm totally ok with that.

A Beginner's guide to APIs: Understanding POST, PATCH, GET, and DELETE

Daniel Trejo — Fri, 13 Sep 2024 12:47:06 +0000

It took me a good while to figure out what I was going to write about but i decided to go with APIs. Today we are going to dive into a subject that at first might seem a little scary but it's actually super easy and essential for building web applications. I'm just going to cover the four fundamental actions you can perform with APIs: POST, PATCH, GET, and DELETE.

Before we jump into the different type of actions, let's cover what an API is. API stands for Application Programming Interface. It allows programs to talk to each other. When coding, you often need your program to interact with other programs or services. APIs is how your going to get that done.

Think of an API like a waiter at a restaurant. You (the user) tell the waiter (API) what you want from the menu (the service), and then the waiter brings back the food (response).

Let’s start with GET.

What It Does: GET is used when you want to retrieve or fetch data from a server. It’s like asking the waiter to bring you a menu or to show you a dish that you’re interested in.
Example: Imagine you’re working on a website that shows user profiles. If you want to display a user’s profile information, you’d use a GET request to fetch that data from the server.

@app.route('/users/<int:user_id>', methods=['GET'])
def get_user(user_id):
    user = users.get(user_id)
    if user:
        return jsonify(user)
    else:
        return jsonify({'error': 'User not found'}), 404

Next up is POST.

What It Does: POST is used when you want to send new data to the server. It’s like telling the waiter you want to order a new dish.
Example: Let’s say you’re building a sign-up form for a website. When a user fills out the form and hits submit, a POST request is sent to the server to create a new user account with the provided details.

@app.route('/users', methods=['POST'])
def create_user():
    new_user = request.json
    user_id = max(users.keys()) + 1 if users else 1
    users[user_id] = new_user
    return jsonify({'id': user_id, **new_user}), 201

Now, let’s talk about PATCH.

What It Does: PATCH is used to update or modify existing data on the server. It’s like asking the waiter to change an ingredient in your dish.
Example: Suppose you want to update the email address of an existing user. You’d use a PATCH request to send only the updated information to the server.

@app.route('/users/<int:user_id>', methods=['PATCH'])
def update_user(user_id):
    user = users.get(user_id)
    if not user:
        return jsonify({'error': 'User not found'}), 404

Finally, we have DELETE.

What It Does: DELETE is used to remove data from the server. It’s like telling the waiter you don’t want a dish anymore and asking them to take it off your table.
Example: If you want to delete a user’s profile, you’d use a DELETE request to remove that user’s data from the server.

@app.route('/users/<int:user_id>', methods=['DELETE'])
def delete_user(user_id):
    if user_id in users:
        del users[user_id]
        return jsonify({'message': 'User deleted'})
    else:
        return jsonify({'error': 'User not found'}), 404

One-to-many & Many-to-many

Daniel Trejo — Thu, 01 Aug 2024 03:25:06 +0000

Hello, my name is Daniel and I'm a student at flatiron. I am currently working through my project in phase-4 which is really challenging but I am learning a lot from all of it. One thing that screwed me over before and took me some time to understand was one-to-many and many-to-many. It took me way too long to understand what that meant and how it was supposed to work in my project. I understood a one-to-many a lot faster than I did a many-to-many because in my last project. I created and library management system and it allowed people to create authors and books using python.

Author was one and that books were the many. Each author had an infinite number of books they could have while a book could realistically only have one author. One(author)-to-many(books).

Now for many-to-many, we had to use both in phase 4 project and I went with a blog page ironically. Post was a one-to-many and so was the user but the comments was a many-to-many because it had both the posts and the user connected to it. It showed which post it was commented on using the posts id and then also showed who wrote the comment by showing the user's id when they comment. So that's a many-to-many and that took too long for me to understand.

Phase 3 sql, tuples, and object problems

Daniel Trejo — Thu, 11 Jul 2024 20:29:48 +0000

Hello, my name is Daniel Trejo and I'm a student at Flatiron School in the Software Engineering program. Phase 3 was definitely the hardest one yet because of the sheer amount of curriculum. The hardest part for me was the project which is probably not surprising due to the fact that it is the final project of the phase. However I ran into a ton of issues right off the bat but once I got started it wasn't actually that bad. That was until I finished it. Now you might be saying, "It's being done a good thing?" Normally yes but with coding, finishing coding doesn't always mean the project is done.

Now I ran into a heap of issues at this point and they were are super simple fixes except for one. I needed get some data to display at the end of another piece of data but these 2 pieces of data are from different places. Now to some people that might be a simple fix but to me who has been struggling a lot recently with personal stuff and just the scope of the phase. It took me until doing the project to even start completely understanding python, cli, orm, and sql as is.

The problem was I wasn't grabbing the information correctly so I had to create a whole new function and test run for hours trying to get the right thing. Once I finally did, I was so happy but that was until I ran into another problem.

I needed it to return an object but all it kept returning was a tuple. Which meant the information I was getting wasn't returning at all. That's when I found out through using one of the best tools in python,

breakpoint()

that it WAS returning something and it was a tuple but my program didn't know what to do with that tuple. It wasn't actually showing anything on the return until I grabbed the index of that information with [0] brackets. Yay finally it was fixed, however, what everyone will deal with after fixing something. Another problem popped up. It was that I was returning everything as a tuple which meant as a string. A requirement of the project was to be able to view related object. I was viewing just the string of what I needed which isn't an object. So that's when I figured out that I needed to return an object not a tuple. Instead of using sql like this,

sql = """
    SELECT name
    FROM authors
    WHERE id = ?
"""

I had to use it like this,

sql = """
    SELECT *
    FROM authors
    WHERE id = ?
"""

The first way was just grabbing the string(name) instead of grabbing the whole object, which the second version did. Then I had to call it in my repr as self.author().name because doing .name is one of the 2 ways to grab something from an object.

Exploring Destructuring in JS

Daniel Trejo — Wed, 12 Jun 2024 21:15:32 +0000

Hello, my name is Daniel and I'm a beginner at coding. I am an active student at Flatiron School. In phase-2 we delve heavily into react and all the amazing things it can do. Today I decided to talk about Destructuring a little because it is a super simple yet amazing piece of code. Destructuring allows for a more concise and cleaner code. If I were to have code like this;

function EmojiButton(props) {
  return (
    <button>
      <span role="img">{props.emoji}</span>
      {props.label}
    </button>
  )
}

If you take a look at the code block, you will see that in some brackets there are some react components that lets us access that information we are grabbing from the props.emoji and the props.label. Destructuring can be used to clean up some of the the unnecessary words. We can do this a couple ways. One way to do it is doing a const and assigning them as variable that equal the word "props". That will allow us to go without the word props within the components.

function EmojiButton(props) {
const { emoji, label } = props
  return (
    <button>
      <span role="img">{emoji}</span>
      {label}
    </button>
  )
}

As you can see, it looks a little nicer not having the props all over the place. Now I know it doesn't look like it's doing to much here but I promise when you start coding bigger and longer projects. It will start looking all over the place. Props will be literally everywhere. This way you can see exactly what is it's talking about in a specific piece of code instead of looking through "props" over and over again.

Now, I prefer a different way of desctructuring and it looks like this;

function EmojiButton({emoji, label}) {
  return (
    <button>
      <span role="img">{emoji}</span>
      {label}
    </button>
  )
}

It does the same thing as the code block before however I really like the fact that it is integrated into the function itself instead of creating a const variable. It looks a lot nicer and cleaner. Now there will be use cases for both and obviously go with whichever one you feel more comfortable with. A lot of coding is preferences with how you want to go about it. Anyway, destructuring is super useful later one when you coding more than a few lines.

Exploring addEventListeners

Daniel Trejo — Thu, 30 May 2024 17:24:39 +0000

Hey, my name is Daniel and I'm a beginner at all this coding stuff. I'm currently enrolled in Flatiron School for Software Engineer. The first phase was predominantly on JavaScript and it already caught my interest. There are so many things you can do with JavaScript. There's iterations, variables, scope, and the one I'm going to be talking about, Events. Events where there first subject I really thought I grasp almost fully and that was a good feeling on it's own.

At first it was a lot to try and take in at once but after a couple times implementing it into my code for project, labs, and challenges. It really helped get it into prospective for me. It peaked my interest the most because the code itself made sense on it's own. For example, if I were to have something in html with the id of Search, if I wanna select that specific id and add a eventlistener to it, I would use either,

document.querySelector("#search")
or
document.getElementById("search")

Both roughly do the same things, however that have a slight difference as well. querySelector selects the first element in the DOM that matches the specified CSS selector. It is more versatile then getElementById however it is lest straightforward a little slower. Using getElementById is more straightforward and it's generally faster when specifically selecting id's. To add an event to the id="search" You would follow

document.getElementById
with
document.getElementById("search").addEventListener("click", function() { alert("I've been cliked!"); });

The addEventListener piece is giving the search id an event and in our case it's a click event. Now when we click on whatever we have as our search, either a 🔍 or a search button. It will send an alert to the user with whatever you put for the alert to say.

There are tons of different events that you can use like:

mouseover
click
key(any direction)

and so many more that it would take awhile to list them all out here but the fact that there are so many intrigues me. It means that I will constantly be learning and that actually excites me. I would love to pursue as many of those events that I can and not just those but all of coding. I tried so many times to find something that actually interests me and finally I have a profession that actually excites me to learn about.

//Information on eventlisteners
https://www.w3schools.com/js/js_htmldom_eventlistener.asp