DEV Community: Daniel Wilder

Rails API, beyond the basics

Daniel Wilder — Wed, 19 Feb 2020 20:18:26 +0000

For my final project at Flatiron, I developed a web app for volunteers to signup and help keep the streets of San Francisco clean. The idea was inspired by my roommate. She expressed frustration in the way San Francisco Public Works operates. There was even one time where she contacted public works multiple times, contacted our district supervisor, and contacted the mayor as well. It took all of that just to deal with the issue outside of our building. After dealing with this, She came up with the idea to leverage community to address some of San Francisco's issues. And so, I built "SF Heroes," a React web application to do just that.

While the front end design took a while to build, it is actually the backend that I am most proud of. During this project I leveraged the power of a Rails API and the API is doing all of the heavy lifting. In previous projects I used a Rails backend as well. However, for those projects the API was built to do less lifting and I relied on the logic of the front end. This may have worked for previous projects, but not SF Heroes.

SF Heroes has a map page which displays the SF 311 Public Works cases I gathered. Users are given the ability to sort through these cases by status, district, and/or service subtype. Users can apply as many filters as they's like. On my initial draft I had originally made a fetch request to get all of the 311 cases. Each filter would be set in state. On submission, the display map would be set by filtering through all of the cases using state. However, this method created many bugs on the display map.

On my first draft, my backend controller looked something like this...

class CommunityEventController < ApplicationController

    def index
     community_events = CommunityEvent.all
     render json: community_events
    end 

end

You can see I am calling on the ActiveRecord relations method "all" to return all instances of the cases. However, given the bugs I was dealing with, I decided to remove some logic from the front end and leverage the power of the back end.

Upon revision, I decided to use the ActiveRecord relations method "where" instead.
Let's take a look at the revision...


class CommunityEventController < ApplicationController

    def index

           community_events = [ ]
           if params[:title] && params[:district] && params[:status]
                community_events.push(CommunityEvent.where(title: 
                params[:title], district: params[:district], status: 
                params[:status]))


           elsif params[:district] && params[:title]
                    community_events.push(CommunityEvent.where(district: 
                    params[:district], title: params[:title]))


           elsif params[:status] && params[:district]
                        community_events.push(CommunityEvent.where(status: 
                        params[:status], district: params[:district]))

           elsif params[:title] && params[:status]
                    community_events.push(CommunityEvent.where(status: 
                     params[:status], title: params[:title]))

           elsif params[:district]
                    community_events.push(CommunityEvent.where(district: 
                    params[:district])) 

           elsif params[:title]
                    community_events.push(CommunityEvent.where(title: 
                    params[:title]))

           elsif params[:status]
                    community_events.push(CommunityEvent.where(status: 
                    params[:status]))
           else 
                    community_events.push(CommunityEvent.all)
           end 
                    render json: community_events


    end

The ActiveRecord relations method "where" takes in two arguments the key of the query params and the value of the query params. It then uses SQL to query the database for all of the instances that match those parameters. My fetch request on the front end was now pinging the database for instances that matched only the query parameters set by the user.

The front end code looked something like this...

let url = 'http://localhost:3000/community-events?'
        let params = filterData
        if(params.district !== " "){
        url += `district=${params.district}&`}

        for(let i = 0; i < params.title.length; i++){
             url +=`title[]=${params.title[i]}&`
        }

        for(let i = 0; i < params.status.length; i++){
            url += `status[]=${params.status[i]}&`
        }

        return fetch(url, {
            headers: {
                "Content-type": "application/json",
                'Accept': 'application/json',
                'Authorization': `Bearer ${localStorage.getItem("jwt")}`
            }
        }).then(response => response.json())
        .then(json => { 

            dispatch({ type: "SET_DISPLAY_MAP", displayMap: json})
        })

Every filter applied updates the fetch URL accordingly.

Using the relations method "where" gave me one other positive outcome. I was now able to pass in an array of values for one key. Users could now select multiple values to chain on to their fetch URL.

One thing to note:
If you want rails to understand one param having multiple values, you need to use an array in the URL. Let's say I want all of the cases where the tittle of those cases is either "Graffiti" or "Noise Reports," I would need to pass those query params as such:

http://localhost:3000/community-events?title[]=Graffiti&title[]=Noise%20Report

After leveraging the power of my backend and ActiveRecord relations, my display map had less bugs and rendered content faster.

Object Oriented JavaScript

Daniel Wilder — Wed, 22 Jan 2020 20:04:56 +0000

The Problem

When creating dynamic web apps, JavaScript is an amazing tool which enables us to write functions that can be used to manipulate the DOM and handle client-server interactions. However, as our web apps grow in size, these functions can quickly get meshed together in a complicated web, leaving more room for bugs and code which is generally harder to read and change. It's very likely that as our web apps grow in size we will be dealing with dozens, if not hundreds of HTML elements. In turn, our DOM manipulation will quickly become messy. Luckily for us, there is a way to structure our code in a way that changes the layout from a web of free-standing functions to a structure or collection of components or cells. This way of organizing our code is known as Object Oriented Programming.

Object Oriented Programmin: An Overview:

In object oriented programming, our code is separated into containers. These containers are composed pf data, information, variables as well as behaviors we define pertaining to the information. Object oriented programming gives us structure. It establishes the relationship between our data and the functions that define the behavior. We structure our code in a way where we instantiate data that inherits behavioral properties we define in the class the object is associated with. Benefits of organizing our code in such a way include:

Our code becomes easier to change. There is a clear place to add/remove code.
We can design our code in a way that the behavioral functions we define only interact with the data they are supposed to.
Our code is easier to replicate. When an object is created with unique data, the instance methods we define in the class operate in such a way that is unique to that object.
Our code becomes easier to read by adding more organization.

In Practice

On a high level, this makes sense. Let's take a look at how object oriented JavaScript differs from purely functional JavaScript. Here is some functional javascript:

let model = "Honda Civic";
let mileage = 50000;

function goVroom(typeOfCar){
  console.log(`${model} goes vrooooom!!`})
};

function howOldIsMyCar(mileage){
  console.log(`my car has ${mileage} miles.`)
};

function driveToSanDiego(mileage){
  return mileage + 1000;
}

goVroom(model);
//=> Honda Civic goes vrooooom!!

howOldIsMyCar(mileage);
//=> my car has 50000 miles.

mileage = driveToSanDiego(mileage);
howOldIsMyCar(mileage);
//=> my car has 51000 miles.

This code works and we can tell it is related to behaviors and attributes of a car. However, there is nothing that structurally relates this code.
If we were to write the previous code in an object oriented way, it would encode the relationship of the data and behavioral methods. That code would look something like this:

class Car {
 constructor(model, mileage){
  this.model = model;
  this.mileage = mileage;
  }

  goVroom(model) {
   console.log(`{this.model} goes vrooooom!!`);
  }

  howOldIsMyCar(mileage) { 
   console.log(`My car has ${mileage} miles.`);
  }

  driveToSanDiego(mileage){
   this.mileage += 1000; 
  }

}

let jalopy = Car.new("astro", 150000);

jalopy
//=> Car {model: "astro", mileage:150000};

jalopy.goVroom()
//=> astro goes vrooooom!!

jalopy.howOldIsMyCar()
//=> My car has 150000 miles.

jalopy.driveToSanDiego()

jalopy
//=> Car {model: "astro", mileage:160000};

Here the Car object is a class or the structure for all of JavaScript object oriented programming. We create an instance of this class, in this case it's jalopy. This takes in two arguments: model and mileage.The instance methods we defined have access to the data using the keyword this. This refers to the instance or specific object associated with the class. Our code now has structure and methods associated for specific instances of data. Neat!

Conclusion
Object oriented programming is a powerful way to organize our code and allow specific instances of related data to share behavioral functions. We have gone over how it is not only good practice to keep this when working with our models and the backend but with the frontend as well, using the class object constructor provided to us by JavaScript.

Transitioning from SQLite to Postgres in Rails

Daniel Wilder — Thu, 02 Jan 2020 21:07:46 +0000

After spending some time creating a single page web application with a rails API and a vanilla JavaScript frontend, I decided I wanted to host the application on cloud platform such as Heroku. A cloud-based platform is a great way to host applications and make it easy for friends and potential employers to see what you have been working on. An important thing to keep in mind before hosting your rails app is what database are you working with.

Sqlite Vs. Postgres
The default rails database is operated through sqlite. sqlite is great for the novice developer because it can be run in local memory and stored in small files in your local working directory that are easily created and moved. Given how sqlite stores its files on disks, it is not intended to be used for production. On the Heroku website it explains that Heroku's stack is an ephemeral filesystem. You can do all the CRUD actions with this filesystem, but it clears its contents periodically. Meaning, if you were to use a sqlite database, the entire database would be deleted at least once every 24 hours. If you'd like to read more about how Heroku's filesystem is managed, you can click here.

Given the nature of the filesystem stack, Heroku recommends using the Postgres database.
Postgres is different than sqlite in how it stores files. Postgres databases are only portable once they are hosted on a server. Practically, this means that any changes you make to your database will not be persistent until the database is hosted on a server. This is a very useful feature during the development phase of your project. If you are working with one or more partners on your project and are using a host like github during development, you will likely run into merge conflicts with the database if you are using a locally stored database like sqlite. Because of this, Postgres is a better database system to use for applications intended for production.

How To Use Postgres With Rails
If you don't already have Postgres installed, you can download it here.

If you have Homebrew installed on your computer you can also use your computer's terminal to install postgres by typing the following command into the command line:

brew install postgresql

Once you have postgres installed, you can create a new rails app.
Rails has a built-in function to set the application's default database.
simply run

rails new -d postgresql

If you'd like, you can also set the name of the database and its associated username and password.
Before creating your new rails app
type the following commands into the command line.

su -postgres

create role <appName> with <createdb> login password <password1>

replace the words in <> with the names you'd like to fill in.
Afterwards, you can create your new rails app with the command listed above.

Change an existing sqlite database to postgres
Up until now, we have only discussed how to create a new rails app with a postgres database. However, if you want to transition from sqlite to postgres mid-development, you can follow these steps:

In your gemfile you will want to change the line

gem 'sqlite'

gem 'pg'

then run

bundle install

After you will want to access your config/database.yml file.
change the lines from

development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

test:
  adapter: sqlite3
  database: db/test.sqlite3
  pool: 5
  timeout: 5000

production:
  adapter: sqlite3
  database: db/production.sqlite3
  pool: 5
  timeout: 5000

development:
  adapter: postgresql
  database: my_database_development
  pool: 5
  timeout: 5000
test:
  adapter: postgresql
  database: my_database_test
  pool: 5
  timeout: 5000

production:
  adapter: postgresql
  database: my_database_production
  pool: 5
  timeout: 5000

Next run

rails db:create && rails db:migrate

And your app will now be using postgres as the database.

Hosting on Heroku
Once you are ready to host your finished application on Heroku, you can follow these steps:

You will need to login to your existing Heroku account, or you can create one here
run the command

heroku login

this will prompt you for your info.

After log in, run the command

heroku create

and a new Heroku app with a random name will be created.

If you would like to rename the application you can run

heroku apps:rename appName

run

git add .

to add all the changes and

git commit -m "commit message"

to commit the changes.

Lastly run

git push heroku master

and you are done!

The Command Line

Daniel Wilder — Wed, 04 Dec 2019 20:50:34 +0000

The Command line is a powerful tool and one you should become familiar with. Today most people use what is called a Graphical User Interface (GUI) to interact with their computer. A GUI is a way to communicate with a computer using icons and the "point-and-click" method. However, many software developers rely on the command line to perform tasks because it can increase efficiency and allow you to perform tasks not available through GUIs. In this post I will briefly touch up on what the command line is, how to access it, and display some time-saving shortcuts...

A Brief History Of the Command Line
During the 60's and 70's when computers were growing in popularity and functionality, many users would interact with one main computer, known as a mainframe, using a terminal. A terminal primarily consisted of a monitor and keyboard. Each user would use a remote terminal to communicate with the mainframe to perform tasks. Simply put, a computer terminal was a way for a user to interact with a computer to enter, display, and/or print data.

Nowadays, we emulate the terminal using a "terminal emulator" like Terminal in OSX. We no longer communicate with a remote computer but rather with the computer we are operating on.
Because we are operating on computers that are the complete package, when we start a terminal session, we are also initializing a shell program. What you see on the screen will be the shell program.

Because we are operating with the complete package, Your computer's terminal and shell program work together. Your terminal handles the input going in and displays the output to the shell. The software that handles the input and uses the computer's central processing unit to interpret input and render output is called the shell. If you are using a Mac, your default shell will most like be bash.

Using a Terminal Emulator
Now that we've discussed briefly the history of the terminal and how it works, let's discuss some commonly used commands and some less common but nifty shortcuts.

To launch a terminal session type "terminal" in your computer's finder or search spotlight (cmd space).

Once you are in the shell, here are some helpful commands to help you get started:

pwd

Print Working Directory: this command does exactly what it sounds like it does. Prints your Working Directory. It tells your terminal to display what directory/folder you are currently in.

ls

List: This command lists all of the files in your current directory.

cd and cd ~

Change Directory: These both will change your working directory to your home or root directory. You can also type a specific directory in which you would like to change your working directory to.

cd ..

This moves your working directory one directory up from your current working directory.

mkdir

Make Directory: This command creates a new directory or folder.

touch

This command creates a new file in your current working directory

ctrl a

Takes you back to the beginning of the line you are typing on.

ctrl e

Takes you to the end of of the line you are typing on.

ctrl l

Clears the screen.

ctrl c

Terminates whatever you are running.

These are just a few commands to get started with and some others that are useful to know. If you would like a more extensive list of commands Here is one that provides a lot of useful commands to know.

Ruby and Bang(s)

Daniel Wilder — Wed, 13 Nov 2019 20:48:21 +0000

Chances are during your course of learning ruby, you will come across some exclamation marks in your ruby code. Most people know this as a plain ol' "exclamation mark" (!). And they are happy with that. But not us Rubyists! we call these little guys bangs. If you are like me when you first saw this operator, you may have been a little intimidated by its implications and implementations. However, studying the documentation and practicing the functionality can help us understand the use of bangs. In this post I will discuss pairing bang methods with other built-in ruby methods and what that means for your code.

What is a bang?
When paired with other built-in ruby methods, the bang operator will change the original object the method is called on in place of creating a new object.
For example let's say we have an array of numbers and we only wanted to see the the unique numbers in that array. Luckily for us, ruby has a built in method called .uniq.

array = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 9, 9, 9, 9, 9]
array.uniq

This would output

=> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

When we then call the original array object, ruby will output just that. The original unaltered array.

array
=> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 9, 9, 9, 9, 9]

When we pair the .uniq method with the bang operator, we seemingly accomplish the same thing.

array.uniq!
=> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

However, when we call on the original array object, something different happens. We no longer have access to all of the original elements particularly those we excluded with the .uniq method. This is due to the functionality of the bang operator. Remember, the bang operator works with ruby's methods to alter the existing object- not create a new object.

array 
=> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

At first glance, this seems, great! We can clean up our code and cut out many lines of code without having to assign new variables to new objects created by our built in methods. If only that were the case. The bang operator has another functionality. When called, it coerces our data into boolean expressions and inverts the truth value of that data.
For example...

!true
=> false
!false
=> true

Let's take another look at our array. It's not unlikely that at a later point we would want to call on our array object. However, if we were to forget that we had previously called the .uniq! method, and we used that method again...

array.uniq!
=> nil

we would no longer get our array of unique elements. Instead we would receive a nil value. This is due to the bang operators boolean inversion functionality.

Conclusion
The bang operator has its use in ruby and in a later article I will discuss more practical applications of the bang operator. like != or not equals to and the double bang (!!) operator. However, it is important to understand what a bang does and how it modifies methods first. Because the bang operator is destructive by nature, use caution when pairing it with other methods