Forem: Jessica Joseph

Phase 4 FlatIron Project

Jessica Joseph — Mon, 16 Aug 2021 18:16:39 +0000

Phew! Well, I'm finally finished with my phase 4 FlatIron School project. This time we were tasked with creating a one-page application using JavaScript. For my project I decided to make an application called "Book Briefing" where users can leave book reviews and others can comment and like the reviews. This project was a big accumulation of everything we've learned so far and I definitely enjoyed building it. With that being said, I figured I'd share some tips that may help others!

Setting Up CORS

So right off the bat, this is definitely something you want to set up once you have all of your file structures created. CORS is important because this is what establishes your connection between your frontend and backend, without this set up, your program will not be able to run. So first thing you want to do is add the gem rack-cors to your GemFile. If you set up your backend using rails new, then you should just be able to uncomment it out and then run bundle install. Next, navigate to the config/initializers/cors.rb file, there you should uncomment out the following code:

Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post, :patch, :put] end end

This should properly establish your connection between your front and backend, now you'll be able to get on with coding!

Connecting Your Files

All of your files in the frontend of your application need to be connected to the index.html file. Essentially, your index.html file is where all your code will actually be rendered and your other files, in my case Comment.js, Review.js, and index.js is where mostly all of your code will live. These will obviously need to have interaction with one another, so the way that we do that is using a script tag.

<script src="index.js"></script> <script src="models/Review.js"></script> <script src="models/Comment.js"></script>

In the head of the index.html file I placed the three script tags with the source of each of the three files that need to be connected. The second two, are nested in a models folder hence why they have the models/ in front of the file name. This is all you have to do and now everything should be properly connected.

Combining Two Repos Into One

When creating this type of application, you will have a frontend and a backend, meaning that you will need to create two repositories. You can choose to combine your repositories at whatever point in your application that you would like, but it's preferable to do it before starting any coding in the chance that your pushes to GitHub might not appear after merging(which is a problem that I faced unfortunately). So after creating your frontend and backend repositories, you will then need to create a third repository that will become the parent repository to the other two. In my application I named my parent repository BookBriefing. Next, clone the parent repo onto your machine in your desired location and cd into it, opening it in your prefered code editor. Once you have that open, pull up your terminal and follow the syntax of:
git subtree add --prefix=rails git://github.com/rails/rails.git master Put the proper information corresponding to your project in the code snippet and enter into your terminal. Make sure to do this for both repositories.
git subtree add --prefix=book-briefing-api git@github.com:jessicaajosephh/book-briefing-api.git master
git subtree add --prefix=book-briefing-client git@github.com:jessicaajosephh/book-briefing-client.git master
As you can see, in mine I replaced it with the name of both repositories and then copied the SSH key of each. Once you do this, you can go to GitHub and see that both repositories should now be nested in the parent repository. Now you can code as usual, just make sure to cd into the proper terminals when pushing code to GitHub.

Future Planning

All in all, I'm very happy with the way my application turned out, but that's not to say that I don't want to add more to it. In the near future I plan on implementing user authentication so that both reviews and comments belong to specific users. I would also like to add a lot more styling and make it a better user experience with more features than just creating a review. I feel like all of the knowledge that I've learned so far has been wrapped up in this project, I can't believe I only have one more left!

You can check out my project repo if you would like at:
(https://github.com/jessicaajosephh/BookBriefing)

Understanding :source on a has_many_through Relationship

Jessica Joseph — Fri, 30 Jul 2021 13:27:49 +0000

As you know, associations are a crucial part of any Rails project in order to get your program to start functioning. I recently created a Ruby on Rails application called "Five Star Movies". A user can signup and review movies, as well as leave a review on other users movie reviews. While creating this application I was introduced to the concept of using :source on a has_many through: relationship. This was something I've never used before and had to familiarize myself with, so I figured I'd walk you through my thought process with me!

Setting Up My Associations

One of the firsts steps you should take when creating a Rails project is figuring how your models interact with one another and setting up your associations. In my application I had 4 models; user, movie, review, and genre. Each of my associations are as follows:

Movie-

belongs_to :user belongs_to :genre has_many :reviews has_many :users, through: :reviews

Genre-

has_many :movies has_many :users, through: :movies

Review-

belongs_to :user belongs_to :movie

User-

has_many :movies has_many :reviews has_many :reviewed_movies, through: :reviews, source: :movie has_many :genres, through: :movies

If you look close enough, you'll see that one of those associations are not like the rest. As you can see, in the users model, there is an association called :reviewed_movies. Again taking a closer look at it you will also see in that association is something called :source. It is also important to note that the movie model is singular in source, this is the basic syntax for writing this code.

Deciding When to Use `has_many_through` with `:source`

In my Users model when setting up my associations I have a has_many :reviews and a has_many :reviewed_movies, through: :reviews, source: :movie. Before deciding to use :source the second association above originally looked like; has_many :movies, through: :reviews. As you can see before changing the code, the two associations for the through model are both looking to the Movie model, which can get confusing and may run you into problems. To avoid this I implemented :source. Using source allows you to specifically name your associations while still being able to correctly grab the data from the proper model.

Importance of Implementing `:source` in this Application

Now that we established why the associations are set up as followed, taking a further dive into it, I wanted my users to be able to leave a review on other users movies as well as have access to all the reviews left by other users. The join table in my application is the Review model, so setting up my association like so allows the Users model to have access to the Movie model to grab all the movies with reviews left on it. This was important because it allows users to interact and see other one anothers reviews on the movies, which in turn allows for a better user experience. As you can probably see by now, using :source in my has_many through: association allowed for my application to become more dynamic and gives users access to more data.

Wrapping it Up!

Using :source in your Rails application allows for the customizable naming of associations. While creating this application, researching this concept made it possible for me to be able to get my app to behave exactly how I intended for it to. This concept(a very useful one I might add!) not only improved my app, but also helped improve my skills as a developer. It is definitely something I will be using again in the future as I create more Rails applications.

Phase 3 of FlatIron

Jessica Joseph — Sun, 18 Jul 2021 23:13:28 +0000

This is my third project I created since starting my coding journey! It's crazy to think that I started with no knowledge of coding and now I have just completed my third project for FlatIron School. For Phase 3, we were tasked with creating a Ruby on Rails application. I created an app called 'Five Star Movies', which users can create an account to review and rate movies. I was really excited to start building this app, because I felt as if all my knowledge that I learned over the past few months have finally come together. With that being said, I successfully created a ruby on rails application that reviews movies!

Silly me to think that this project was not going to present me with many issues, because that was totally not the case. I was not aloud to create the app with Scaffold, because, well that basically does all the work for you! Building it from the ground up was very challenging but also very rewarding. I ran across a lot of errors and mishaps, but it's all done now and hopefully some of these tips can help others in the future!

Setting Up Your App

Once you have your idea for you application and are ready to start building, where do you start? The first thing you want to do is in your console run:

rails new project_name

What this will do is, populate the foundation of your application and will create the basic files and folders that you will need to build it. If you are familiar with Sinatra, it's almost like how the corneal gem will populate the basics of your Sinatra app. Pretty neat!

Setting Up Your Associations

This part is very important for the functionality of your app. Once you've created all your, model, view and controllers, in the models, you will need to set up your belongs_to, has_many and has_many :through associations. Associations are an important part of building this app, because it will let the program know how each of the separate files are connected to one another. Without setting these up, your application will not be able run because your files don't know that they are all working as a collective. In my app "Five Star Movies", I have a user, movie, review and genre models. My associations are set up as follows:

class User < ApplicationRecord 
    has_many :movies
    has_many :reviews 
    has_many :reviewed_movies, through: :reviews, source: :movie 
    has_many :genres, through: :movies 
end

class Movie < ApplicationRecord
    belongs_to :user
    belongs_to :genre
    has_many :reviews 
    has_many :users, through: :reviews
end

class Review < ApplicationRecord
    belongs_to :user
    belongs_to :movie 
end

class Genre < ApplicationRecord
    has_many :movies 
    has_many :users, through: :movies 
end

Partials

Partials come in handy quite a bit when building a rails application. In your view files, when you have the same bit of code written in multiple spots, that is usually a firm indication that you will need to set up a partial. When creating the erb file for your partial, always make sure to name the file with an underscore before the filename. In my application, a place where I created a partial was in the views/movies. For both my new and edit erb files, I had the same block of code for the form to either create or edit a movie. With that being said I created a new view/movie file called

_form.html.erb

I copied the code that I had for my new movie form and pasted it in the new partial that was created.

<%= form_for @movie, html: { multipart: true } do |f| %>

  <%= f.label "Choose a genre:" %>
  <%= f.collection_select :genre_id, Genre.all, :id, :name, include_blank: true%>

  <p>Or create a new genre:
  <%= f.fields_for :genre do |g| %>
    <%= g.text_field :name %>
  <% end %>
  </p>
  <br>
  <br>
  <%= f.label :title %>
  <%= f.text_field :title %>
  <br>
  <br>
  <%= f.label :description %>
  <%= f.text_area :description %>
  <br>
  <br>
  <%= f.label :movie_length %>
  <%= f.text_field :movie_length %>
  <br>
  <br>
  <%= f.label :director %>
  <%= f.text_field :director %>
  <br>
  <br>
  <%= f.label :rating %>
  <%= f.text_field :rating %>
  <br>
  <br>
  <%= f.label :image %>
  <%= f.file_field :image %>
  <br>
  <br>
  <%= f.submit %>
<% end %>

With that code now being moved to the partial, I removed the form from both the new and edit erb files. I then rendered the partial in both of those file like such:

<%= render partial: "form", locals: {movies: @movies}%>

This not only made my code look a lot nicer, but if someone else were to go and look at my code, they wouldn't have to scroll through a whole view page to look at the form that is mixed in with other code. Partials make life a little bit easier when building your rails app.

Future Project Plans

Overall, I really enjoyed creating this app and learned a lot while doing it. In the near future I hope to really expand the functionality of the app and add a lot more styling to it. I'm planning on continuing to build this app and I'm going to add new features that will make it an overall better user experience.

You can check out my project repo if you would like at: (https://github.com/jessicaajosephh/FiveStarMovies)

My Phase2 FlatIron Project

Jessica Joseph — Sun, 28 Mar 2021 19:43:24 +0000

Well, it's been one crazy week but I finally did it, I created a Sinatra-based web app called "What Am I Doing Today?"!! Essentially what this app is, is a to-do list that allows a user to create an account and easily keep track of their day-to-day tasks. This project came with a lot of struggles and roadblocks, so much at times that I thought I wasn't going to be able to complete it in time. That's all over now though because I have a fully functioning Sinatra web app using CRUD!

Creating an application from scratch is not something that I would consider easy. I had a lot of moments where I had to step away from the computer and really think things through before starting to write any code. One thing that made my life so much easier while creating this was the Corneal Gem. This gem was made by a former FlatIron student and boy did it come in handy. Essentially what the corneal gem does is it creates the complete structure of your Sinatra app for you. All you have to do is run gem install corneal and once it is installed, run corneal new APP-NAME. Once you run the commands it will populate a whole file structure for you consisting of an app folder with views, models and controllers, a gemfile, db folder, etc. Pretty much everything you would need to create a Sinatra application. This definitely helped me to get my project off the ground and not have to figure out all the code necessary to make this program run as a proper Sinatra app. I highly suggest taking a look at this!

Now, getting into the creation of all the methods and making the program function at a user-friendly level. With this app we had to use something in Sinatra called CRUD. CRUD stands for Create, Read, Update and Delete. I had to make sure that when a user creates an account that they can create a new task, read their tasks, update them and also delete them. In Sinatra we store these methods in the controllers files using get, post, patch, and delete.

1. Create

First I had to create a method that allowed my users to have the functionality to create a new task.

get '/tasks/new' do
        if logged_in?
          erb :'/tasks/new'
        else
            redirect '/users/login'
        end
    end

    post '/tasks' do
        @task = Task.create(name: params[:name], description: params[:description])
        current_user.tasks << @task
        redirect "/tasks"
    end

Using the get and post method, once a user logs in they can create a task that is specific to them only.
It will display a form for the user to input the task name and task description. After the user submits that info it will be saved to their user_id.

2. Read

Second, I had to create a method that allows a user to have the functionality to read/view their tasks that they have created.

get '/tasks/:id' do
        if logged_in?
          @task = Task.find_by_id(params[:id])
          erb :'/tasks/show'
        else
          redirect '/users/login'
        end
    end

    get '/tasks' do
        if logged_in?
          @tasks = current_user.tasks
          erb :'/tasks/index'
        else
          redirect '/users/login'
        end
    end

Using these two get methods, if a user is logged in to their account, they will be able to view only their tasks that they have created. No post method is needed because get methods only give you the ability to view/read something which is exactly what we need in this situation.

3. Update

Next, I had to create a method that gives a user the functionality to update their existing tasks.

get '/tasks/:id/edit' do
        if logged_in?
          @task = Task.find(params[:id])
          if current_user.id == @task.user_id
            erb :'/tasks/edit'
        else
            redirect '/users/login'
        end
    end
    end

    patch '/tasks/:id' do
        if logged_in?
          @task = Task.find(params[:id])
          @task.update(name: params[:name], description: params[:description])
          if @task.save
            redirect "/tasks/#{@task.id}"
          else
            redirect '/tasks'
          end
        end
    end

Using these get and patch methods, a user can easily update a task whether they want to change the name or the description. It finds the task that the user wants to update and then gives the user the options to edit either or both of the fields. Then it will save that updated information and store it as the new updated task at that id number.

4. Delete

Last, I had to create a method that allows a user the functionality to delete a task.

get '/tasks/:id/delete' do
        if logged_in?
        @task = Task.find(params[:id])
        if current_user.id == @task.user_id
            erb :'/tasks/delete'
        else
            redirect '/users/login'
        end
    end
    end

    delete '/tasks/:id' do
        if logged_in?
          @task = Task.find_by_id(params[:id])
            if @task.destroy
                redirect '/tasks'
          else
            redirect '/users/login'
          end
        end
    end

Using these get and delete methods, a user is able to delete a task that they have already previously created. It finds the task by its id number and then renders to an erb form that allows the user to delete that task.

Using CRUD it gives the user the ability to do everything necessary to pass the project requirements. In all of my CRUD methods you can see that I used the a helper method called logged_in?. This helper method makes it possible that there won't be any issues regarding creating, reading, updating, or deleting any other users tasks. This is used by enabling sessions. Essentially what sessions does is, that it stores all of the specific users data in a cookie so that way it knows what data belongs to what user.

configure do
    set :public_folder, 'public'
    set :views, 'app/views'
    enable :sessions
    set :session_secret, ENV['SINATRA_SECRET']
  end

As you can see, in my application controller is where I enabled my session as well as setting the session secret. This will ensure that a user can only deal with their own tasks and data.

Well there ya go! This week was quite the rollercoaster, but hey I was kinda expecting that after all my issues with my first ever project. All in all though, building this app taught me a lot better how things kind of flow and function in Sinatra. I'm pretty proud of myself for what I was able to create and I can't wait to continue to build upon this app and hopefully one day be able to deploy it!

You can check out my project repo if you would like at:
(https://github.com/jessicaajosephh/what-am-i-doing-today)

My Phase 1 FlatIron Project

Jessica Joseph — Fri, 26 Feb 2021 17:33:57 +0000

Where do I even start? This is my fourth week at FlatIron School and we were tasked with creating a CLI project from scratch using an API. It completely intimidated me at first, I had no idea where to even start. My cohort leads gave the advice that even if you don't know where to start, just start somewhere. I know that statement sounds vague, but hey, I listened to that and figured the first thing I would need was the API.

I searched and searched the internet for hours for what I thought a good API would look like. This step took me way longer than I would have liked and I must admit, I got a little bit hung up over it. At last though, I found an API that I liked and would be perfect for this kind of project. It's an API that lists dog breeds and then returns information on each bread. Perfect, it's right up my alley since I'm a dog lover of course.

With this API I wanted to be able to create a project where the user gets to scroll through a list of breeds and then picks one that they would like to know more about. Simple enough right? Well..... let me just say I struggled! I felt like it was the first time on my own where there was no lab tests, just me and all the information I learned in the previous three weeks.

With that being said it was time to actually start building the project. I would be lying if I said I was able to just get right in there and start typing out code. It took watching videos upon videos to understand the basics that go into building a CLI. Thankfully, my cohort leads are amazing and also provided us with more than enough information to get my project up and going.

After hours of watching YouTube videos it was time to jump in. There were now things that I had to tackle in order to get a final product:

What files to create
How to push all of my work to GitHub
How to get my API data to work in my code

Knowing What Files to Create

Knowing where to start and what files to even create was half the battle. From the videos I watched, I sort of knew what needed to be created, but I didn't fully understand why/how they interacted with one another. I started with what I knew, I knew I needed a file for the API. This was an obvious to me, because well yeah if we're going to be planning on building this project with an API we need a file that has code to actually pull the data out of it.

I also created a CLI file. I knew I had to create this because, again, the videos I watched, but I wasn't sure exactly what it did. After researching I came to terms that the CLI file is where I am going to be putting my code that pulls the information and then displays it to the user in an easily understandable manner.

I knew I had to create a file that somehow connected all of my files together. For this I created an environment file. What this environment file does is, it requires all of my other files into it so that way when I code in, let's say the API file, it was also register in the CLI file for example. If there was no environment folder my code would not know how to interact with one another, therefore making my program not feasible.

How to Push Work to GitHub

My next battle was learning how to save and push all of my code that I was working on to GitHub. The way GitHub works is actually pretty cool, because say if unexpectedly my computer crashed in the middle of building out my project, you would think all of my progress would be lost right? Well, think again, with GitHub it allows you to push your code to your account while you are working on it. This way you can avoid the disaster of losing everything that you were working on.

How do you do this though? That's what I had to find out. I'm pretty lucky because one of my cohort leads did a whole bonus lecture all about git. After rewatching that lecture and Googling a couple of things, I found that it was actually quite easy. There are a few basic commands that you can enter in your terminal as you are working on your project, or whatever it may be that you are coding.

git add .

git commit -m "<descriptive message>"

git push

These three commands came very much in handy. What "git add ." does is that it saves all the new changes that you made to your code and prepares it for the next command that you will need to use. The next command is "git commit -m """, this allows you write a message about the new/improvised code that you just created. Make sure to make this message as descriptive as you can, because say in the future you want to come back to your project and build upon it more, you'll be able to fully understand each step of code that you previously created. Lastly, "git push" actually pushes all those changes up to GitHub allowing you to now see all you code that you've created, up until this point, in your repository.

How to get my Code to Work

The heading says it all, how was I even supposed to get my API data to properly interact with my code? Well this is definitely what I struggled the most with. It's not like I wasn't able to get everything to work, but there were definitely times where I thought that I was never going to end up with a fully functioning project.

How was I supposed to get all the code from my different files setup the right work for it to work? Well I had to take a step back and really examine what I was doing and what my code said. I tried to make sense of everything in my head and think if this does this, then that should do this. With that being said, I was still running into the problem with initializing my DogBreed class. What I needed the initialize method to do here was take the information from the API that I was using and make it work in a way where it can nicely display it to the user.

Initially I was trying to set up the initialize method with an attr_accessor:

attr_accessor :name, :weight, :height, :bred_for, :life_span, :breed_group, :temperament

Coding my method in this way would mean that my initialize method would end up looking a little something like this:

@@all = []
attr_accessor :name, :weight, :height, :bred_for, :life_span, :breed_group, :temperament

def initialize
@name = name
@weight = weight
@height = height
@bred_for = bred_for
@life_span = life_span
@breed_group = breed_group
@temperament = temperament
end
@@all << self
end

I mean it would get the job done, but then I would run into hurdles of other problems I want to implement this information into my CLI class. One more watch of the instructor led videos and the lightbulb clicked in my head; metaprogramming!

Metaprogramming, is essentially code that writes other code. It's a pretty cool concept and it helped me a lot on this project. With metaprogramming it can pull key/value pairs from my data and make it work more effectively in my code. Key/value pairs is a simply concept, for example, a key would be "name" and the value of it would be "John". So using this logic of metaprogramming I could pull those specific keys or pieces of information from my API and display the correct value corresponding with each dog breed.

With that being said my initialize method would now look like:

@@all = []
 def initialize(breed_hash)
        breed_hash.each do |key, value|
            self.class.attr_accessor(key)
            self.send("#{key}=", value)
        end
        @@all << self
    end

I didn't have to explicitly code out every piece of information that I wanted from the API in my initialize method. It's a lot more concise and gets my code to function exactly how I want it to.

So, basically this week was quite an experience. It took long days and a lot of coffee to end up with a final result. I'm proud of myself for what I was able to do. I went from not knowing a single thing about coding to three weeks later creating a whole CLI application on my own. I know building the project is only half the battle, but I hope my technical review goes just as well and feels just as rewarding as creating this project.

You can check out my project repo if you would like at:
(https://github.com/jessicaajosephh/dog-breeds)

The Other Side of Fear

Jessica Joseph — Sat, 13 Feb 2021 15:11:43 +0000

In life there will be many moments where you have to choose to either, stay comfortable and remain where you are or take a leap of faith into the unknown. Applying to Flatiron School was what I like to consider my leap of faith. There are many scary things about taking on a new challenge that you have no knowledge about. It's the unknown that not everybody will choose to venture out into. I choose to not stay comfortable with where I was at and to challenge myself to something that I know can potentially change my life by throwing myself into the unknown, into the fear.

Fear stops many people from doing risky or unfamiliar things. It almost stopped me from applying for the coding bootcamp because I was fearful that I wouldn't be any good, fearful that I wouldn't belong and fearful that I would let myself down. I came to the conclusion that I had to face that fear and just throw myself into it and embrace it. Now, I'm two weeks into my program at Flatiron School, in no way am I an expert, but I have really surprised myself with how much I was capable of learning in just two weeks. If I would have let that fear stop me, I wouldn't be in the position I am today, about to go on a journey that is going to change my life for the better. As Will Smith once said, "God placed the Best Things in Life on the Other Side of Fear!". So far the view from the other side is looking amazing.