DEV Community: ocole161

Phase 4 Flatiron School Project

ocole161 — Mon, 13 Mar 2023 15:07:31 +0000

In this blog post I'll be looking back at my Phase-4 project for the Flatiron School's Software Development program. This phase focused on Ruby on Rails and is our final phase learning new content, with Phase-5 completely focused on our capstone project.

This project was built with a Rails backend and a React Frontend, using the React Bootstrap css framework.

I had a couple of ideas for my project, however I decided to settle on creating a personal page for my friend who is a real estate agent. On it users would be able to view properties without logging in, and by logging in they would be able to save properties to their favorites and send a message to the agent regarding a property. Additionally, a user with the proper login credentials could log in and have the ability to create, update, and destroy properties, and could also view all the messages from users, in addition to being able to view what properties are being favorited by users.

My real estate agent friend has access to a very robust API with frequently updated information on available properties, known as an MLS (multiple listing service). At first I was very excited to work with this API as it seemed like it would give me a ton of information to work with, and would give a good "proof of concept" if we ever wanted to make the site live. Unfortunately as I looked into it I found that the companies that curate these MLSs are very protective of their data and as for now since I'm just working on a school project I figured I'd hold off on requesting access for now. Another alternative I considered is a service the MLS offered where they generate html code for you that you can basically just copy-paste into your code to give you all the listings, however since all the listings wouldn't actually be hosted on my server I wouldn't be able to get any data from them, making this rather unhelpful for my project. So disappointingly I fell back to using seed data to generate property data for this project, at least for now.

Next step was to get a plan for my databases set up, this was a fairly straightforward project so it wasn't too difficult. I would have Properties, Messages, Users, and Favorite_properties. I set up their relationships as such in the models:

Property:

    has_many :messages, dependent: :destroy
    has_many :favorite_properties, dependent: :destroy
    has_many :users, through: :favorite_properties

Message:

    belongs_to :property
    belongs_to :user

FavoriteProperty:

    belongs_to :user
    belongs_to :property

User

    has_many :messages, dependent: :destroy
    has_many :favorite_properties, dependent: :destroy
    has_many :properties, through: :favorite_properties
    has_secure_password

--Note the "has_secure_password" on the User model, this doesn't affect the relationships between the tables but I included it as it will be relevant next.

With the basic build complete my next step was to add authorization and authentication for my users, and to test deploying my project.

I won't get too into the weeds with the setup for authorization and authentication for now, we can save that for a future blog, but I will say I recommend getting this set up early on in your build, before you start adding too much complexity. You can set up a basic login page with a form on the front end to test, or you can simply use a tool like Postman to generate server requests. A few gotchas I will mention is to make sure your user model has the "has_secure_password" line as I show above, and to make sure your user migration has a column named exactly "password_digest."

After all this initial setup I updated my controllers to make sure my server was ready for any requests, and made sure my serializers were set up so that I could take advantage of the table relationships I set up in the models. And for the most part that was all the back-end setup I needed for this project. Working on the frontend was a bit of a challenge as we had been learning backend for the past 6 weeks, so I had to dust off everything I'd learned in the first 2 phases of our course.

In my frontend build I had my biggest lesson learned from this project. In order to have my logged in user accessible in any components I used useState to set it in App.js:

import { useEffect, useState } from'react';

const [user, setUser] = useState(null);

  useEffect(() => {
    fetch('/authorized')
    .then(res => {
      if(res.ok) {
        res.json().then(user => setUser(user))
      } else {
        setUser(null)
      }
    })
  },[])

And then passed it down as a prop to any component that needed it.

However, what I found is that occasionally a component on the page would load before the user prop was able to be loaded, so user was coming through as 'null' as you can imagine this caused a myriad of issues. In my next project I plan to use useContext or a state management tool to avoid this issue when setting my user state.

The last thing I want to quickly touch on is React Bootstrap. This was my fist time using a css framework and while it did make things easier, I was a bit surprised with the lack of options. Perhaps I didn't dig deep enough but it seemed like it really forced you to either do things a certain way, or choose from a list of only a few options. Css continues to be the bane of my frontend existence, and probably my biggest weakness currently as a full-stack developer.

Dr Seedlove or: How I Learned to Stop Worrying and Love seeds.rb

ocole161 — Fri, 17 Feb 2023 23:48:42 +0000

Phase 3 of our coding course introduced us to backend development using Ruby. I enjoyed working with the more simplified syntax and powerful built in methods as opposed to JavaScript, but one concept we were introduced to didn't immediately click with me, the creation of a seed file. A seed file, for our purposes, was used to create test data for us to use to test our code. Initially when the projects we were working with were so small, creating a seed file seemed to me to be tedious and unnecessary, when it was just as easy to create data manually in the rake console. As we starting working on larger scale projects however, I soon learned the value of not just having a seed file, but having a robust one that provides plenty of well populated data to work with. In this post I will discuss the basics of building a solid Ruby seed file to be used in testing your code.

For example purposes I will use the code my partner and I used for our Ruby project for class -- a webapp that allowed users to view different coffee roasters, the coffees that they made, and for the user to view and leave reviews for each coffee type. We created a simple backend with 3 tables, with the following relationships:

Each roaster has many coffee types, and has many reviews through coffee types.
Each coffee type has many reviews, and belongs to a roaster.
Each review belongs to a coffee type.

Creating test data in rake console

First let's take a look at how we could manually create test data using rake console. We'll start with creating a roaster:

//You can also use rails console here if you are using rails//
$ rake console

irb(main):002:0> Roaster.create(name: "Corvus Coffee Roasters")

//There will be some info here about how the instance was created,//
//then we'll get the details of our created record below//

id: 1,
 name: "Corvus Coffee Roasters",
 img_url: nil,
 website_url: nil,

We can now use Roaster.first or Roaster.find(1) to use this instance to test. Next we can create a coffee type associated with that roaster, using the id we got when we created that roaster:

CoffeeType.create(blend_name: "Morning Blend", roaster_id: 1)

//...//

id: 61,
 roaster_id: 1,
 blend_name: "Morning Blend",
 intensifier: nil,
 origin: nil,
 notes: nil,
 muffin_pairing: nil,
 img_url: nil,

After doing the same process to create a review we'd have 3 instances linked to test on, without much effort. Now let's see what the same process would look like inside of a seeds.rb file:

Creating simple test data in seeds.rb

//This code is here to make sure we wipe all our old seed data//
//before we run db:seed, to keep our test data clean.//
CoffeeType.destroy_all
Review.destroy_all
Roaster.destroy_all

r1 = Roaster.create(name: "Corvus Coffee Roasters")

c1 = CoffeeType.create(blend_name: "Morning Blend", roaster_id: r1.id)

Review.create(reviewer_name: "Owen", review_body: "Great!", rating: 4, coffee_type_id: c1.id)

Note that instead of assigning a roaster_id and coffee_type_id of 1 we declared variables for r1 and c1 and then took their id. This is because if db:seed is run again, it will not start at 1 when assigning ids. In this example if we ran db:seed twice all our instances would have an id of 2. Also keep in mind that the variables r1 and c1 will not be created to be used in your rake console to test with, they are only used inside the context of the seeds.rb file.

Now that a seeds.rb has been created (in our db folder) we can use the command rake db:seed (or rails db:seed) to generate our data.

That was a bit more effort than building manually, but the added benefit is huge. For starters we now have data that we won't need to rebuild every time we reopen rake console to test our data. We also now have a way to reset our data to a consistent point if we end up manipulating our data. The benefit of using a seed file becomes even more clear when you need more than just a few instances created to test your code. Below is the final seed file we created for our project, imagine having to manually type this in every time you wanted to generate your test data!

CoffeeType.destroy_all
Review.destroy_all
Roaster.destroy_all

puts "seeding begun"

# Define constants
muffin_types = ["Blueberry", "Chocolate Chip", "Apple Cinnamon", "Banana Nut", "Lemon Poppy Seed", "Carrot Cake", "Cream Cheese", "Bran"]
coffee_images = ["https://images.pexels.com/photos/1695052/pexels-photo-1695052.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=2", "https://images.pexels.com/photos/773958/pexels-photo-773958.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=2", "https://images.pexels.com/photos/4109743/pexels-photo-4109743.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=2", "https://images.pexels.com/photos/4109748/pexels-photo-4109748.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=2"]

# Create Roasters
Roaster.create(name: "Corvus Coffee Roasters", img_url: "https://testedcoffee.com/wp-content/uploads/2021/03/corvus-coffee-picture-for-denver-coffee-roasters.jpg", website_url: "https://www.corvuscoffee.com/")
Roaster.create(name: "Kaladi Coffee Roasters", img_url: "https://testedcoffee.com/wp-content/uploads/2021/03/kaladis-coffee-roaster.jpg", website_url: "https://kaladicoffee.com/")
Roaster.create(name: "Huckleberry Coffee Roasters", img_url: "https://s3-media0.fl.yelpcdn.com/bphoto/SUP3uukMOvxSYzbO3ESQkg/o.jpg", website_url: "https://huckleberryroasters.com/")
Roaster.create(name: "MiddleState Coffee Roasters", img_url: "https://testedcoffee.com/wp-content/uploads/2021/03/middlestate-coffe.jpg", website_url: "https://www.middlestatecoffee.com/" )


# Create CoffeeTypes
20.times { CoffeeType.create(
    blend_name: Faker::Coffee.blend_name, 
    roaster_id: Roaster.all.sample.id,
    intensifier: Faker::Coffee.intensifier,
    origin: Faker::Coffee.origin,
    notes: Faker::Coffee.notes,
    muffin_pairing: muffin_types.sample,
    img_url: coffee_images.sample
) }

# Create Reviews
50.times { Review.create(
    reviewer_name: Faker::FunnyName.name,
    review_body: Faker::Quotes::Shakespeare.romeo_and_juliet,
    rating: [1, 2, 3, 4, 5].sample,
    coffee_type_id: CoffeeType.all.sample.id
)}

puts "seeding finished"

Note: if you are unfamiliar with Faker, Faker is a gem that generates fake data.

Now not only do we have a huge amount of test data to work with, but anytime we want to reset it all back to it's original state it's as easy as running rake db:seed.

I hope you've now realized as I have how valuable it is to put in the time upfront to make a robust seeds.rb file to give you lots of good test data to work with.

Phase-2 Project Review

ocole161 — Sat, 28 Jan 2023 03:08:31 +0000

Our phase-2 project was an individual project using React to build a webpage with multiple Routes used. Fairly straightforward and with very basic deliverables, so it left us open to get creative and see what we could do with all we learned. In this post I'll reflect on things I learned and struggles I had.

With the project being so open ended, I used the opportunity to try building out an idea I've had for some time - a website to view happy hours in Denver. Being a happy hour connoisseur myself I've had the desire for an easy way to view what bars and restaurants in Denver had specials. What limited resources there were already online had become quite out of date post-COVID, when many reopening establishments either reduced or outright eliminated their happy hours. My goal was to build a site where it would be easy for users to add and update specials, while giving access to an admin role to review any changes made by users.

So on to the build. For this project I decided to use Vite, a tool that among other things, provides a much quicker server. I'm sure there is much more Vite can do that I didn't utilize in this project and I hope to learn more about it in the future. One nice side effect of Vite is that generating a default project had some basic build and styling pre-built, so I was able to use some of that as basic guidelines for building out my css. On the topic of css, for this project I opted to attempt to use vanilla css, as I wanted to work on my own knowledge of css. In the future I will likely try something like Bootstrap, as that is what I would be using in a professional setting.

One early lesson learned was that I should be better about planning my components before building. Not that it caused any major long term issues but I ended up building two redundant components, a "Home" component and a "CardList" component, the "CardList" component didn't end up having any functionality built into it other than to pass props up and pass functions down so it was just unnecessary. I ended up leaving it in as it wasn't breaking anything, but in a project I would actually be publishing I would want that to be cleaned up.

Other than that most of the basic build was straightforward and I had the core deliverables completed on day 1. React is so much quicker and more intuitive to build out than vanilla JS! This was also my first time really working with React Routing but that proved to be quite intuitive as well.

The thing that this project gave me the most difficulty with was working with the radio buttons for "locationNeighborhood" in my 'edit' form. I wanted the form to be automatically populated with the values from the special that the user was trying to edit, and I was able to do this pretty easily for all forms except for the radio buttons.

After some quick searched I found some info that said that a radio button would be checked by default if they had a property of "checked" with a value of "checked." Seemed easy enough. I build out a property with logic like this (in this case for the LoDo neighborhood):

checked={locationNeighborhood === "LoDo" ? "checked" : ""}

This accomplished part of what I was looking for - the correct radio button was selected by default, however clicking on other radio buttons would not change it from whatever was already set as the default. After at least an hour of playing around with it to no avail I went back to Google and found that a 'true' value will also set the radio button to be checked by default. So I was able to simplify my logic to be:

checked={locationNeighborhood === "LoDo"}

That ended up making everything work! Lesson learned -- don't rely on the first Google result you find.

My final issue was with an admin page I set up with a password. Submitting the correct password triggers a setState function that changes the jsx that is returned for the /admin route:

  function handlePassword(e) {
    e.preventDefault()
    if (e.target["password"].value === "admin") {
      setAdminPage(
        <>
          <HeaderAdmin handleHomeClick={handleHomeClick}/>
          <AdminPage specials={specials}/>
        </>
      )
    } else {window.alert("That is not the correct password")}
}

This all worked just fine except I had expected this state to persist, so that once you entered the correct password you wouldn't have to enter it again as long as the page didn't refresh. However when navigating elsewhere on the page and then returning to the admin page you would be shown the login screen again. It seems that navigating to a different route on the page does in fact trigger a page refresh. I played around with trying to fix this for awhile but ultimately decided it wasn't really worth it, as this password method isn't really something that would be used in a practical sense anyways as you wouldn't handle something like a password on your front-end.

All-in-all this was a very fun project for me not only because it was on a topic I was excited to work on but I also was able to get the core deliverables done so quickly that I could just focus on adding fun bells and whistles.

Phase 1 Project: Brewery Searcher

ocole161 — Fri, 06 Jan 2023 21:05:08 +0000

This week we completed our first project, combining js, css and html to build a website that pulls from an API. I worked with Josiah on this project.

Our first task was to find a good API to use. We wanted to find something with a solid dataset, was stable (we had heard that other students in the past had had problems with their API being down when they had to present), and preferably an API that contained image links. We found an iTunes API that checked all those boxes, so we decided to use that.

Using the iTunes API we figured we could make a website that would allow you to search the API using different criteria and then allow you to either rate or favorite each song. However as soon as we sat down to start our build we realized that the iTunes API required you to apply for it, so that was our first major roadblock.

Luckily we were quickly able to find a new, open API, a list of breweries, that we could easily adapt to our original wireframe. However, while reading the documentation we realized the API only returned 50 results at a time, which was an issue. This we quickly resolved by simply creating a local json file with all the data from the API, which they conveniently had on a GitHub page.

Anyways on to the code!

Our first challenge was to create a search that would look at three different fields and return results combining all three. We put our heads together and created a way to do that by iterating over all the breweries using .forEach and using an if statement that returned TRUE if all the inputted values either matched that brewery or were blank. So a search with all values blank returns all breweries.

if((stateSelect.value === item.state || stateSelect.value === `Select State`) && (typeSelect.value.toLowerCase() === item.brewery_type || typeSelect.value === `Select Type`) && (item.name.toLowerCase().includes(nameSearch.value.toLowerCase()) || nameSearch.value === ``))

We were pretty proud that we were able to successfully create this line filled with logic and have it work on our first try!

Our biggest challenge came not in the functionality of the website built via our js code but instead from making the site look decent using the .css. Both my partner and I struggled in trying to add different classes to our elements to make them appear as we wanted. In particular we found it extremely difficult to get elements to appear where we wanted on the page, without them overlapping with other elements, for example. It seemed like we were just playing a guessing game by trying different things in the .css file and seeing if it changed anything on the page. It was very frustrating that it seemed like most of the time whatever we changed didn't actually affect anything. I'm hoping we will learn some tools in the future that make all this easier.

I actually ended up coding some things into the js file that I probably would've been better off doing in the .css file put I just couldn't figure out how to do. In particular, to add a page break between the input elements in my edit form to edit the brewery I created a 'br' element and then appended it to every element that I wanted a page break after. I found, however, that the 'br' element I created was only being appended to whatever the last element that I appended it to in the js. After some research I found that you can use '.cloneNode()' to prevent this from happening.

var br = document.createElement("br")
h5.append("Name: ", nameEdit)
h5.appendChild(br.cloneNode())
h5.append("City: ", cityEdit)
h5.appendChild(br.cloneNode())
h5.append("State: ", stateEdit)
h5.appendChild(br.cloneNode())
h5.append("Type: ", typeEdit)
h5.appendChild(br.cloneNode())
h5.append("Address: ", streetEdit, ad2Edit, ad3Edit)
h5.appendChild(br.cloneNode())
h5.append("Website: ", urlEdit)
h5.appendChild(br.cloneNode())
h5.append(submitEdit)
h5.append(deleteBtn)

This had the intended result of giving me my page break, but I get the feeling there is a cleaner way to do this in the .css using class names.

Another challenge we encountered had nothing to do with code, but was simply using GitHub to manage our different branches. This is definitely something I look forward to learning more about as it seems like this will be very important to have a solid understanding of when working on larger projects in the future where there are many people all working on the same code. It can be scary when merging your branch with a main branch, as you want to make certain that you aren't overwriting or removing code that someone else has worked hard on. Keeping large numbers of branches in sync seems like it must be almost as hard as writing the code itself!

To sum up my experience with the project, I found meeting the basic deliverables to be quite easy, most of the difficulties we had came from additional goals and challenges we gave to ourselves. There is much more functionality I would've liked to add and more style changes I would've liked to play with given more time, but I'm happy with the final product that we delivered.