DEV Community: John Paul Fababaer

Sprint 5: Creating Sample Data

John Paul Fababaer — Mon, 11 Mar 2024 16:43:13 +0000

When creating an application, it is helpful to generate a sample data that populates our tables. In doing so, we can visualize how we want our users to interact with our application.

Taking an example from our Industrial Photogram, here's an example of a "sample_data" rake task:

desc "Fill the database tables with some sample data"
task example_sample_data: :environment do
  starting = Time.now

  if Rails.env.development?
    FollowRequest.delete_all
    Comment.delete_all
    Like.delete_all
    Photo.delete_all
    User.delete_all
  end

  12.times do
    name = Faker::Name.first_name
    User.create(
      email: "#{name}@example.com",
      password: "password",
      username: name.downcase,
      private: [true, false].sample,
    )
  end

  users = User.all

  users.each do |first_user|
    users.each do |second_user|
      next if first_user == second_user
      if rand < 0.75
        first_user.sent_follow_requests.create(
          recipient: second_user,
          status: FollowRequest.statuses.values.sample
        )
      end

      if rand < 0.75
        second_user.sent_follow_requests.create(
          recipient: first_user,
          status: FollowRequest.statuses.values.sample
        )
      end
    end
  end

  users.each do |user|
    rand(15).times do
      photo = user.own_photos.create(
        caption: Faker::Quote.jack_handey,
        image: "https://robohash.org/#{rand(9999)}"
      )

      user.followers.each do |follower|
        if rand < 0.5 && !photo.fans.include?(follower)
          photo.fans << follower
        end

        if rand < 0.25
          photo.comments.create(
            body: Faker::Quote.jack_handey,
            author: follower
          )
        end
      end
    end
  end

  ending = Time.now
  p "It took #{(ending - starting).to_i} seconds to create sample data."
  p "There are now #{User.count} users."
  p "There are now #{FollowRequest.count} follow requests."
  p "There are now #{Photo.count} photos."
  p "There are now #{Like.count} likes."
  p "There are now #{Comment.count} comments."
end

Let's break this down.

desc "Fill the database tables with some sample data"
task example_sample_data: :environment do
  starting = Time.now

-Line 1: "desc" stands for description. Essentially, in this line we are giving a proper description of what the task would do when called.

-Line 2: we use the "task" method which takes in a Hash argument. The key is a Symbol of the name of our task "sample_data" and the value for this should be ":environment". This makes the Rails environment have access to all models, gems, and initializers.

-Line 3: Using the Time class to create a timestamp. (We will later call another Time.now so we can determine how long it took to create the sample data.

if Rails.env.development?
  FollowRequest.delete_all
  Comment.delete_all
  Like.delete_all
  Photo.delete_all
  User.delete_all
end

-This enables us to destroy previous iterations of the sample data every time we call on this task in the terminal. Use it with caution since we do NOT want to destroy records associated with the user = wrap the whole delete_all logic inside an if statement.

  12.times do
    name = Faker::Name.first_name
    User.create(
      email: "#{name}@example.com",
      password: "password",
      username: name.downcase,
      private: [true, false].sample,
    )
  end

-This block of code utilizes the gem "Faker" to generate randomized data. In this case, we are trying to create randomized "first_name". Before we decide what properties we want to define, it is a good idea to reference the corresponding model to know which columns need to filled.

-Afterwards, it is just up to you to define the Ruby logic needed to fill up each column of an Instance.

users = User.all

  users.each do |first_user|
    users.each do |second_user|
      next if first_user == second_user
      if rand < 0.75
        first_user.sent_follow_requests.create(
          recipient: second_user,
          status: FollowRequest.statuses.values.sample
        )
      end

      if rand < 0.75
        second_user.sent_follow_requests.create(
          recipient: first_user,
          status: FollowRequest.statuses.values.sample
        )
      end
    end
  end

-The idea behind this code block is to iterate through the 12 randomly generated Users to have the chance (75%) to send follow requests to other users + randomly define the status of that follow request (pending, accepted, or rejected).

users.each do |user|
    rand(15).times do
      photo = user.own_photos.create(
        caption: Faker::Quote.jack_handey,
        image: "https://robohash.org/#{rand(9999)}"
      )

      user.followers.each do |follower|
        if rand < 0.5 && !photo.fans.include?(follower)
          photo.fans << follower
        end

        if rand < 0.25
          photo.comments.create(
            body: Faker::Quote.jack_handey,
            author: follower
          )
        end
      end
    end
  end

There are 3 different things happening within this code block:

-Part 1: randomly determine how many photos the block variable "user" is going to post. In it, we use the faker gem + robohash to randomly generate values for our caption and image column, respectively.

-Part 2: if a follower of the user does NOT like the photo and the rand() method returns true, add the follower to the fans record, which is a list of User Instances that liked the photo.

-Part 3: give the follower a 25% chance to leave a randomly generated comment (via Faker) in the photo. Also populate the author_id column with the user_id.

Finally, the hardest part.

  ending = Time.now
  p "It took #{(ending - starting).to_i} seconds to create sample data."
  p "There are now #{User.count} users."
  p "There are now #{FollowRequest.count} follow requests."
  p "There are now #{Photo.count} photos."
  p "There are now #{Like.count} likes."
  p "There are now #{Comment.count} comments."
end

-As said before, we create another Time.now to take a timestamp of when the whole sample_data process ends. The remaining "print" lines is to show us that we created the sample data we wanted for our application.

It is always useful to create a sample_data task in order to aid in our development process. Make sure you are aware of the columns you want to fill out by referencing the models you created previously.

CY@!

Sprint 4: Ruby on Rails - Helper Methods for Forms

John Paul Fababaer — Sat, 02 Mar 2024 02:53:50 +0000

More helpers! Now we focus on using helper methods to create our form tags in our view template files:

Part 1: using form_with + form builder object (contains the form Object with a bunch of methods to create our tags i.e. ".label") for POST requests.

<%= form_with(model: @movie, data: { turbo: false }) do |form| %>
  <div>
    <%= form.label :title %>

    <%= form.text_field :title,  %>
  </div>

  <div>
    <%= form.label :description %>

    <%= form.text_area :description, { rows: 3 } %>
  </div>

  <%= form.button "Create Movie" %>
<% end %>

Part 2: for a PATCH request, we alter the form_with slightly by adding "method: :patch"

<%= form_with(model: @movie, method: :patch, data: { turbo: false }) do |form| %>

NOTE: the beauty of using the form_with helper method is that it automatically add the extra < input > tags we need to protect ourselves from CSRF attacks.

NOTE 2: form_with also handles the setting of attributes for="" and id="" which defaults to "title" and "description. Therefore, we do NOT need to add this option as long as we follow convention.

NOTE 3: by using the argument "model: ", the form Object is associated with the ActiveRecordObject.

-Therefore, this knows to reference that Movie Instance to access the columns we are referencing for values.
-In that same way, we can drop the prepopulated values, Rails will do it for us since it just has to look at the Instance Object and match it with our defined symbol column.

CY@. I'm confused. Lol.

Sprint 4: Ruby on Rails - Helper Methods for Routes and Links

John Paul Fababaer — Sat, 02 Mar 2024 02:06:06 +0000

Basics are basics. Once we get the hang of the underlying mechanisms that make Ruby ideal for learning and development, we can start learning the many helper methods that automate these functions.

This post will focus on the many helper methods we can to avoid dealing with unnecessary bugs.

Part 1: Helper methods for naming routes and links

Naming routes: there are several levels to utilizing helper methods here. Depending on your comfortability with helper methods, the level of abstraction increases or decreases.

-Level 1 - new Hash syntax + optional parenthesis:

A route like this:

get("/", { :controller => "movies", :action => "index"})
get("/movies", { :controller => "movies", :action => "create })

can be transformed into:

root "movies#index"
get "/movies" => "movies#create"

-Level 2 - Prefix methods + _path and _url helper methods:

Using the "as:" keyword, we can define prefixes for our routes that we can reference = DRY principle.

Rails.application.routes.draw do
  root "movies#index"

  # CREATE
  post "/movies" => "movies#create", as: :movies
  get "/movies/new" => "movies#new", as: :new_movie

  # READ
  get "/movies" => "movies#index"
  get "/movies/:id" => "movies#show", as: :movie

  # UPDATE
  patch "/movies/:id" => "movies#update"
  get "/movies/:id/edit" => "movies#edit", as: :edit_movie

  # DELETE
  delete "/movies/:id" => "movies#destroy"

end

NOTE: we only need to define a prefix ONCE if the routes are identical but the HTTP Verb is DIFFERENT. Rails is smart enough to know which route to take as long as the proper HTTP Verb is defined.

NOTE 2: in order to reference these paths, we can either use _url OR _path. Use _url for fully qualified URL.

Example:

<div>
   <a href="<%= edit_movie_path(@the_movie) %>">
          Edit movie
   </a>
</div>

NOTE 3: when we're dealing with dynamic paths, we can pass the ActiveRecord Object like an argument in the _path() and Rails is smart enough to know to look for the "id" column.

-Level 3 - resources: we completely abstract the routes away because the CRUD functions are so common. Resources will define all the routes and helper methods we generally need - following convention.

root "movies#index"
resources :movies

Part 2: Shortening template names

Level 1 - shortening render template: when passing render as a SINGLE argument, Rails assumes its a view template.

Therefore, a code like this:

def new
    @the_movie = Movie.new

    render template: "movies/new"
end

can be shortened to:

def new
    @the_movie = Movie.new

    render "movies/new"
end

Level 2 - remove it entirely: if the folder name that contains the view templates match the Controller name + the view template name matches the action name, Rails can just assume which view template is being referenced.

def new
    @the_movie = Movie.new
end

Part 3: link_to

Level 1 - using link_to to create an < a > tag.

<!-- <a class="navbar-brand" href="/">Helper Methods 3</a> -->

     <%= link_to "Helper Methods 3", root_path, class: "navbar-brand" %>

Level 2 - using link_to but ONLY passing the ActiveRecord Object itself for the route: behind the scenes Rails takes the class of the Object then uses .downcase before doing a + "_url".

<%= link_to "Show details", movie_path(a_movie) %>

<%= link_to "Show details", a_movie %>

-NOTE: in the example above, both < a > tags will work identically. The assumption that Rails make is that: a_movie.class.downcase + "_url" = movie_url

-Example 2 - dealing with the delete verb:

<%= link_to "Delete Movie", @movie, data: { turbo_method: :delete } %>

CY@

Sprint 3: Setting up databases with draft:resource and Devise.

John Paul Fababaer — Sun, 25 Feb 2024 23:44:45 +0000

Now that we have a better understanding of setting up our RCAVs (route, controller, actions, view template), we can worry about handling the back-end and displaying our desired data.

Luckily for us, we can utilize a gem called "draft_generator" in order to generate the necessary SQL commands to build our databases. This is quite easy as long as we have done the necessary preparation beforehand to know the desired tables we want to utilize.

(However, we don't have to be perfect. We can add or remove columns as needed if we find flaws in our ERD (entity relationship diagram). Honestly, we can even nuke the whole database if needed - I had to do it a couple of times...)

Using draft:resource, this is how we set up our desired database(s). In the terminal, follow this command FORMAT:

Format:

rails generate draft:resource <DATABASE_NAME> <COLUMN_NAME_1>:<DATA_TYPE_1> <COLUMN_NAME_2>:<DATA_TYPE_2> <COLUMN_NAME_3>:<DATA_TYPE_3> ...

Example 1:

rails generate draft:resource delivery description:string supposted_to_arrive_on:date details:text user_id:integer arrived:boolean

Example 2:

rake db:migrate

What is happening?

In the example above, we are creating a database called "Deliveries" (plural since it is the database itself). We refer to the single instances (rows) as a "Delivery".
The rest of the command line specifies the desired columns we want and the data-type it should be stored as. BUT...
...that is not the best part. With this single command, it also auto-generates the RCAVs related to this database. While it is boilerplate code, as long as we've done our due diligence, it should be easy to understand the CRUD commands defined by the generator.
Do NOT forget to input the command: db:migrate. Without it, the SQL commands necessary to generate this database is pending!

Using Devise to generate our Users database: allows User authentication.

If you haven't already, go ahead and use the command:

rails generate devise:install

to install Devise. There will be a prompt on how to initialize this gem so make sure to follow the steps. (I usually do 1-3).

Afterwards, we can use this command:

rails generate devise user

What is happening?

This command generates our Users database. By default, this will create the SQL commands to make the id, email, and password columns for Users.
In addition, this will create the RCAVs for User related functionality. (i.e. /users/sign_up, /users/sign_in, /users/edit, /users/delete). The functionality for these routes are hidden behind the scenes and we just get to take advantage of it!

Therefore, if anyone wants to take advantage of our web application, they would first need to create their own email account to start CRUDing.

There are other generators we can take advantage of to automate this process. The important thing is to know what is happening with the boilerplate code it generates. By doing so, we are able to adapt our web application to our specific needs without dealing with the "formulaic" part of setting it up. NEAT.

CY@.

Sprint 2: Refactoring Models with belongs_to and has_many

John Paul Fababaer — Mon, 19 Feb 2024 14:46:36 +0000

Defining methods inside of our model files allows to a more readable and manageable code. Methods like this: app/models/character.rb

class Character < ApplicationRecord
  def movie
    key = self.movie_id

    matching_set = Movie.where({ :id => key })

    the_one = matching_set.at(0)

    return the_one
  end
end

and this: app/models/movie.rb

class Movie < ApplicationRecord
  validates(:director_id, presence: true)
  validates(:title, uniqueness: true)

  def director
    key = self.director_id

    matching_set = Director.where({ :id => key })

    the_one = matching_set.at(0)

    return the_one
  end
end

allows us to reuse these methods wherever we see fit and enables us to adhere to the DRY principle - do not repeat yourself.

Now what is happening in the two examples above?

Both of these methods are Many-to-One relationship in which the "Many" (i.e. Character and Movie) uses its foreign key (i.e. movie_id and director_id, respectively) in order to query the "One" database (i.e. Movie and Director, respectively).
These association accessor methods follow the same pattern... so what does Rails do? MAKE IT EASIER!

We can use the meta-method belongs_to() to make direct associations and define our association accessor using three arguments (could really be ONE if you carefully plan it beforehand!)

Here's how it looks: app/models/character.rb

class Character < ApplicationRecord
  belongs_to(:movie, class_name: "Movie", foreign_key: "movie_id")

  # def movie
  #   key = self.movie_id

  #   matching_set = Movie.where({ :id => key })

  #   the_one = matching_set.at(0)

  #   return the_one
  # end
# ...
end

What is happening?

belongs_to requires THREE arguments:

First argument: name of the method -> a Symbol that is carefully named to describe the purpose of the method (think carefully!)

Second argument: the first key/value pair of a Hash with the Key as a Symbol "class_name". The value associated with this Key must be a String that matches the name of the database we want to query.

Third argument: the second key/value pair of the Hash with the Key as a Symbol "foreign_key". The value associated with this Key must be a String that indicates the foreign_key value used to connect the "Many" database to the "One" database.
In the example above, we defined a method "movie" that wants to query the database "Movie" for any Movie instances that match the movie_id value.
Shortcut: if the values for both of your Keys matches the name of the method, we can short-hand the belongs_to like this:

belongs_to(:movie)

Rails already knows what we mean by this and performs the method as usual.

Using has_many():
We have examined how to use belongs_to() in order to handle the Many-to-One relationship. Now we need to deal with the other side of this relationship, One-to-Many.

Here is an example: app/models/movie.rb

class Movie < ApplicationRecord
  validates(:director_id, presence: true)
  validates(:title, uniqueness: true)

  belongs_to(:director)
  has_many(:characters, class_name: "Character", foreign_key: "movie_id")

  # def characters
  #   key = self.id
  #   the_many = Character.where( {:movie_id => key })
  #   return the_many
  # end
end

What is happening?

In this method, we are now dealing with "One" movie that can have "Many" characters. Using the belongs_to() method is NOT sufficient to create this direct association (behind the scenes, has_many() functions differently despite the same format).
Therefore, it is important to know which side of the relationship the Class is representing:
-If it's in the "Many" it has to belongs_to "One".
-If it's in the "One" then it has_many "Many".
Lastly, we can still create the short-hand! As long as it matches, we can turn the code above into:

has_many(:characters)

Hail Rails on Ruby! Isn't that a little bit easier? :)

CY@.

Sprint 2: Data Integrity with Validations.

John Paul Fababaer — Mon, 19 Feb 2024 00:11:25 +0000

When we deal with data input from users, we want to handle valid information for our database to process. If not, we start to deal with invalid values that invites chaos all around.

If anything, we would have to write a bunch of defensive conditionals, if/else/elsif/end statements, to deal with any invalid information. This can get tiresome and who has time for that?

By using the "validations" feature of ActiveRecord, we can create validation rules that will disregard any user input if the conditions are not met.

Here is an example of one: /app/models/[Class_name].rb

class User < ApplicationRecord
  validates(:username, {
    :presence => true,
    :uniqueness => { :case_sensitive => false },
  })
end

What is happening in the example above?

Inside of the Class "User" we use the method validates which takes in two arguments.

First argument: a Symbol that represents the name of the column we are declaring constraints for (i.e. "username").

Second argument: a Hash that defines the constraints we are applying (i.e. Common ones to use: :presence, :uniqueness, and :numericality).
What do these do?
1. :presence -> an input NEEDS to be present.
2. :uniqueness -> values can NOT be a duplicate.
3. :numericality -> validates that the value input only has numeric values.
Essentially, the example above is saying:

-> When creating a new User class, the user input MUST have a "username" info present AND it has to be a unique value within the User database.

One more practice!

What does this say?

class FollowRequest < ApplicationRecord
  validates(:sender, { :presence => true})
  validates(:recipient, { :presence => true })
  validates(:recipient_id, {
    :uniqueness => { :scope => [:sender_id] }
  })
end

Answer:

The column "sender" should have a value present during user input.
The column "recipient" should have a value present during user input.
The column "recipient_id" should have a unique value from the "sender_id" column.

WOHOOOO! Check your data! It'll help in the long run.

CY@.

Sprint 1: Introduction to Ruby on Rails

John Paul Fababaer — Sun, 11 Feb 2024 22:29:32 +0000

After dealing with some Sinatra, it is time to graduate and learn how to utilize Ruby on Rails. It is probably the most intimidating task I've ever had to deal with. Files upon files, and it doesn't seem to end.

Here's the first task, define the routes we want the users to access. To do so, we first have to head to /config/routes.rb. This is where we can define our routes (rails automatically comes with this code):

Rails.application.routes.draw do

end

Inside this do/end block, we can use our get() method (or post(), if necessary) to define our routes. This is where it gets confusing:

get("/divide", { controller: "division:, action: "show_division_form" }

It looks a little different, what's happening?

The get() method takes on two arguments: first -> a String defining the URL route and second -> a Hash containing two keys, :controller and :action.
The first Key, :controller, is a Class we define in order to house the Ruby logic for the specified route.
The second Key, :action, is the method contained within the Class which is the actual Ruby logic we create to perform certain tasks.

Connecting the FIRST dot: config/routes.rb -> app/controllers/[:controller_value]_controller.rb

Create a new file: /app/controllers/[:controller_value]_controller.rb and define the Class specified in routes.rb:

class DivisionController < ApplicationController

   def show_division_form
      render({ template: "division_templates/division_form"})
   end
end

What is happening?

We create a new Class "DivisionController" and inherit from a Parent Class "ApplicationController". In doing so, we can utilize all the useful methods this Child Class would need.
We connect the next dot: inside of render, we use another Hash to tell our route which view template it should connect to. The Value paired with this Key should be the name of the .html.erb file we are going to create to house all of our HTML/CSS.

Connecting the LAST dot: app/controllers/[:controller_value]_controller.rb -> [ChildClass_name]_templates/[template_name].html.erb

To check if we have properly connected the three files (i.e. routes.rb, [controller_name]_controller.rb, and [template_name].html.erb, we have to get back to our roots. In the .html.erb file, write this:

<h1>Hello world!</h1>

When you check the URL: yourdomainname.com/divide, it should now have an H1 heading of "Hello world!"

NICE! Welcome to Ruby on Rails.

CY@.