It was a little over a year ago when I embarked on my journey to become a software developer. I knew I wanted to work in this field and I desired to start somewhere so I could grow my skills while in school. Through hard work, and God's direction, I found a local business that was hiring web consultants to help customers create drag-and-drop websites on the company's platform. I loved helping others find solutions when they were struggling with difficult tasks. My desk still has a few gifts on it which were sent by customers as a thank-you for assisting them.

After working a few months as a web consultant, a position in quality assurance opened up. I put in for the opportunity, and after testing and interviewing, I was selected for the promotion in the fall of last year. Since then, I have discovered how much I truly enjoy working with software and creating great products for others to use.

What I Do

As a quality assurance specialist, I have a few different tasks I am responsible for. My company is small enough, that I oversee many tasks by myself, but large enough that there is a large customer basis from all over the world. Sometimes, others in the company assist me with testing large products. In my role, I get to work closely with other teams and assist them when they might need extra help. I am responsible for mostly manual testing of the software before it is released to the production environment. I am not able to share all the details of my job, as it would violate company policy.

My Primary Role

It is my responsibility to be at the center of all of the company teams to ensure a quality product for our customers. However, I work most closely with the developers and designers. I have learned that testing is much easier when I can review the specifications the design team set out for the developers. This helps me locate areas that may be problematic, and communicate issues to the development team. I have also learned that not always can specifications be followed, so sometimes it is best to communicate with the developers about why they crafted an item in a certain way. Thankfully, I work with a great group of people who are alright with challenging one another. A question about why someone took a certain approach is not seen as an insult, but as a learning opportunity that allows us to produce the best product we can.

My second largest role is to respond to issues, or bugs, in the production environment. By way of research and testing, I get to investigate what might be causing the problem, as sometimes the problems are caused by misuse of the product. Other times, there are bugs in the software. It is my role to document these bugs and relay the urgency in which they might need to be fixed to a project manager. For example, it is essential I make sure our customers can receive payments through their websites, as this is the sole source of income for some artists. A day with income can be a huge deal to some of the larger businesses. As a result, a bug in the payment system would likely take priority over all other tasks assigned to the developers.

What I Have Learned

Quality assurance has given me a great advantage in my software engineering studies. Every day, I get to work with the entire lifecycle of software and see it to production. I have learned areas where issues can hide within the software and how to address these issues. I am grateful the developers are willing to take the time to explain why something is malfunctioning. This has helped me improve my projects, grow my knowledge base and adapt to technologies I have not experienced yet.

Here is a list of some of the most important things I have learned so far:

Patience is Key

It can be super easy to overlook a problem if you do not spend time on it. Other times, it can be super easy to make a big deal out of something, when in fact the issue was created by your own doing. Taking the time to slow down and think through problems creates less work for other teams and yourself.

Communication is Needed

Before I even begin testing, I am presented with specifications to assist my testing plan of the software. I have learned that it is essential to ask all the questions I might think of during the specifications meeting to avoid assuming something, and getting it wrong. Even during the testing process, I have learned to be in constant communication with the design team and developers to ensure the software is working as intended.

Test Plans Help You Achieve More, Faster

It is very easy to get lost in the testing process of a major project. When an issue occurs, it is essential to document what triggered the issue. It is difficult to do this if you can't remember the steps you took to get there. Test plans take time at the start, but they are well worth it. I use Google sheets more than anything else to develop my test plans. They allow me to quickly share the plans with others in cases where I need their help. A simple test plan which allows you to jot down testing scenarios as you think of them can be a huge help in uncovering and solving issues.

Be Prepared

There are often times when the developers or one of my supervisors will ask me detailed questions about a bug. It is easiest to explain the issue based on its impact vs priority. An issue may have a low impact (misspelling of the company's name on the home page), but this would be a high-priority issue because misspelling of the name might confuse customers. On the other hand, a high-impact bug might be a button that does not click because it impacts all customers, but it is a low priority because there is another easily accessible button that accomplishes the same task. Explaining issues in this sense helps clarify the urgency in which a bug might need to be fixed.

Screen Recordings are a Must

It is so much easier to remember the specifics about bugs when you can review screen recordings, or screen captures, of the issue. A screen recording helps the developers in that they can view the issue without needing to re-create all the documented steps in the bug task. It also assists in the testing process once a fix has been provided because it can be easy to forget what a bug looked like if you last looked at it a few weeks ago.

Overall

This is just a brief overview of what software quality assurance looks like and some things I have learned. If you are interested in this line of work, I would encourage you to try it out. The work is not physically demanding, but it can be mentally challenging at times. For the most part, quality assurance is very rewarding. It allows you to see your work help others succeed. It is always my goal to do the best I can with testing a product to help lighten the load of others. By helping to produce a quality product. I am learning more than I ever have about software engineering and I am very thankful for my experiences.

Recently, I completed my build of a full-stack application using React on the front end and rails on the backend. This application had the most components out of all of my projects....21 (and counting). In my past applications, I used React state and props to handle state. In these applications, I made sure to add state in the appropriate parent component. I passed it for miles, through props, to the smallest child component. Then, I realized I needed to pass objects from the child component, back to the parent, so off I would go creating a callback function and passing it down the component tree all over again. This process became old, and I was thankful to find Redux (a global state management library) to avoid this endless process. I am far from an expert, but I would like to relay how I used redux in hopes it might help you with your next application.

What does Redux allow you to do?

Redux allows the storing of state in a "store." Unlike React state, which is only accessible to children components by way of passing props from their parent components, the store is accessible by any component, at any time. Every component can update state. Greatest of all, Redux eliminates the need to remember which components state was passed through since it is always available to each component.

Redux does not have to eliminate all props, or local state, but it certainly makes global state much easier to handle.

Getting Started:

Install Redux

After setting up a react application, we will need to install redux and react-redux. We can do this with npm by using the following command: $ npm install redux react-redux.

Install Middleware Thunk

Thunk middleware for Redux allows us to write, "functions with logic inside that can interact with a Redux store's dispatch and getState methods." This will help us out in our process. To install this with npm, you can use the following command $ npm install redux-thunk.

Set Up

In my react app, I always add a .src file. This file contains all my components, and it is the perfect place to build out our redux items. In the .src file, we first need to create two folders. To keep these straight, title the first folder reducers and the second actions.

Reducers Folder

In order to have a physical store (like Walmart), you must have products inside for customers to purchase. In Redux, reducers are what will make up our store. They are the items that will contain and manipulate our state so we can view it on the front end. They give us the ability to move complicated functions from our components to one place where we can handle all requests.

Set Up a Reducer

In the reducers folder create a file. It is easiest to name the file with the title of your state, followed by the word "Reducer." This file will be a .js file. In my case, I am going to create state for a user who has logged into my react app. I titled my file userReducer.js.

In this file, we are going to set up a function to return state based on what our component calls for. I will explain this in a little more detail shortly, but let me start by showing you what my a basic outline looks like:

const initialState = null

const userReducer = (state=initialState, action) => {
  switch(action.type) {
    //If there are no other cases, we will just return state which is curently null. 
    default:
      return state;
  }

}

export default userReducer;

I know this might look crazy, but hang in there. Let me go over some basics. This reducer takes in an action that has a type and a payload. We will form our action later, but currently, you can see action is the second item our function takes in. The first is state. Just like when we use useState to set a default state in React components, we can set a default state (like initialState in the example above) and assign it to our state. In the case above, we have set our reducer to always return null if we do not add any other cases to it.

The switch statement above will return a case based on the action.type we pass to it. So, let's add some case statements to our switch to help clarify what we would like the reducer to return:

const initialState = null

const userReducer = (state=initialState, action) => {
  switch(action.type) {
    //If a user signs in, we want to return the user as state. 
    case "ADD_USER":
      return [action.payload]
    //If a user signs out, we want to delete the user information from state, and return our initial state of null. 
    case "DELETE_USER":
      state = initialState;
      return state
    default:
      return state;
  }
}

export default userReducer;

In our reducer, we now have a case statement allowing us to add and delete a user. As you might notice, we can use simple JSX and javascript methods to change state based on what we are doing in our component. The payload (action.payload), which is coming through our action, is the data returned from our fetch request in the component.

Now that we have a simple reducer, let's set up an action so we can pass objects to our state. Make sure to remember the case statements declared in the reducer, so we can use them in the action. In the example above, we will remember ADD_USER and DELETE_USER.

Actions

Actions are what allow us to connect our reducer to the component. They are what we create to pass data to state from a component.

Setting Up an Action

Next, we need to create a file in the actions folder. It is simple to title this file with the title of the state we are trying to manipulate. This file will be a .js file also. For example, I named my action folder user.js.

In this file, we need to export functions for each of the cases we have in our reducers folder. This will connect the reducer with our component and allow us to update state in the reducer. It might make more sense to describe this as the setState function we use in a component. Before I explain further, let me show you what this looks like:

export const addUser = (user) => {
  return {
    //Our type must match the case statement from the reducer file. 
    type: "ADD_USER",
    //The payload is passed to this function by our component calling this function. 
    payload: user
  }
}

export const deleteUser = (user) => {
  return {
    //Our type must match the case statement from the reducer file.
    type: "DELETE_USER",
    payload: user
  }
}

In the action above, you can see we have an action type defined for each case in the reducer. For example, in the addUser function, we are sending the ADD_USER case a payload of user. user is the data we are sending from our React component, and we will see this in action in just a second. In order to pass user to our state, we will import the addUser function to the component, and send (or dispatch) our user data to the reducer where state is held.

Now that we have these folders set up, let's connect our state to the front end.

Set Up an Index.js File

Your application likely already has an index.js file in the .src folder. We want to create a second one that is different from the first. You can create this file in the reducer folder and title it index.js. The reason we need to create this folder is to combine all of our reducers into the store. Without this folder, you can only have one reducer in the store, and likely this will not work for most applications that need to maintain state for multiple areas of the application.

In the index.js folder, we need to start by importing { combineReduces } from 'redux'. After, we need to import each of our reducers. I am going to add more reducers to demonstrate this idea:

import { combineReducers } from "redux";
import userReducer from "./userReducer";
import incidentReducer from "./incidentReducer";
import personnelReducer from "./personnelReducer";
import resourceReducer from "./resourceReducer";

Next, we need to combine all the reducers like so:

import { combineReducers } from "redux";
import userReducer from "./userReducer";
import incidentReducer from "./incidentReducer";
import personnelReducer from "./personnelReducer";
import resourceReducer from "./resourceReducer";

export default combineReducers({
  user: userReducer, //store.user when using the selector
  incident: incidentReducer, //store.incident
  personnel: personnelReducer, //store.personnel
  resources: resourceReducer //store.resources 
})

That's it for this folder. Make sure to include all your reducers so you can access them on the front end!

Configure the True Index.js

Now, we need to do some configuring inside the index.js file contained in the .src folder. (Different from the one we just created) This would be your normal index.js file.

import { Provider } from 'react-redux';
import { createStore, applyMiddleware } from 'redux'; //!!!!createStore is no longer the recommended way to handle state. A strikethrough will strike through this, but it will still work. 
import { composeWithDevTools } from '@redux-devtools/extension'; // We can use a chrome extension to provide redux dev tools
import thunk from 'redux-thunk'; //Thunk middleware
import rootReducer from './reducers'; //This is the combination of reducers we created in the other index.js folder

Once we import the items described above we can implement them by creating a variable for the store, and wrapping our app component in the <Provider>. Lastly, we need to pass our store variable as a prop to the provider.

This will look something like this:

import React from 'react';
import { composeWithDevTools } from '@redux-devtools/extension';
import { createStore, applyMiddleware } from 'redux';
import { Provider } from 'react-redux';
import rootReducer from './reducers';
import thunk from 'redux-thunk';
import 'materialize-css/dist/css/materialize.min.css';
import { BrowserRouter } from 'react-router-dom';
import ReactDOM from 'react-dom/client';
import App from './components/App';
import reportWebVitals from './reportWebVitals';

//Creating a variable for the store
const store = createStore(rootReducer, composeWithDevTools(applyMiddleware(thunk)));

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <BrowserRouter>
      <Provider store={ store }> 
        <App />
      </Provider>
    </BrowserRouter>
  </React.StrictMode>
);

reportWebVitals();

Connect With a Component

This has been a lot of work, but we are super close, so hang in there. Last, but not least, we need to connect our state with our components. We will need two more items to do this.

Dispatch

Dispatch is how we send data through the action to the reducer in order to update state. Always remember, we dispatch data to the store. We select state (more on this in a second) to retrieve state.

First, find a component you would like to dispatch data from. In this component:

import { useDispatch } from 'react-redux';

Now set useDispatch to a variable:

const dispatch = useDispatch();

Lastly, you will need to import the function you set up in the reducer for the task you would like to complete. In my example, I wanted to fetch a user's information if they were currently logged in, and assign their information to the user state. I first import the addUser action we set up earlier, then dispatch the user data to the reducer through this function. I know this might be a bit confusing, but it looks like this:

import { useDispatch } from 'react-redux';
import { addUser } from "../actions/user";

function App() {
  const dispatch = useDispatch();

  useEffect(() => {
    fetch('/me').then((r) => {
      if(r.ok){
        r.json().then(user => dispatch(addUser(user)))//I am dispatching the addUser action to the reducer where the reducer will update state with the users information. 
      }
    });
  }, []);

export default App;

To delete the user, I can simply dispatch(deleteUser(user))to the reducer, which will reset my state.

Select

Now that we have updated our state, we need to access it. We will do this with a selector. The setup process is very similar to setting up dispatch. You can access state in any component by following these steps. State can still be passed down to children props through normal props. For instance, if you have nested data, you may want to use useSelectto grab state and .map nested objects to a different component.

To get state, you will first need to import useSelect into your component:

import { useSelect } from 'react-redux';

Then, we can assign a variable to select the state we would like to retrieve. Remember, if we have multiple reducers, we need to grab state from the appropriate reducer by using store.ourStateReducer. This looks like this:

const user = useSelector((store) => (store.user)); //Returns our user state.

Now, we are able to use the user information to set up our app however we might like. Altogether, select and dispatch might look like this:

import { useDispatch, useSelector } from 'react-redux';
import { addUser } from "../actions/user";

function App() {
  const dispatch = useDispatch();
  const user = useSelector((store) => (store.user));

  useEffect(() => {
    fetch('/me').then((r) => {
      if(r.ok){
        r.json().then(user => dispatch(addUser(user)))
      }
    });
  }, []);

  return (
    <>
      <div>
        <Navbar />
      </div>
      <div className="container">
        {user ? (
          <Usercard props={user}/>
        ):(
          <SignIn />
        )}
      </div>
    </>
  );
}


export default App;

Conclusion

Redux makes handling state much easier. Initially, it can be a little challenging to grasp, but after discovering the flow of data, Redux will become a simple tool of great help to you. Never forget, you can still always handle simple state inside a component, but Redux can handle the state you need multiple components to have access to. I have created a short list of all the steps above should it be helpful. I do not claim to be an expert, but hopefully this will get you started.

Review of the Steps:

1. Install Redux - $ npm install redux react-redux

2. Install Thunk - $ npm install redux-thunk

3. Create reducer and action folders in the .src folder.

4. Set up the reducer:

   1. Create a default state.

   2. Create a case to update state in the way you would like.

5. Set up the action:

   1. Assign the type to the case in the reducer.

   2. Assign the payload to the payload you will be passing the reducer.

6. Create an index.js file in the reducers folder and set up this file:

   1. import { combineReducers } from "redux";

   2. Import all the reducers you have created to this folder.

   3. Combine them together.

7. Configure the normal index.js file in .src to work with Redux:

   1. Import the appropriate tools from redux and thunk (see above).

   2. Create a variable for the store.

   3. Wrap the <App/> component in the Provider component and pass the store variable as a prop.

8. Depending on if you are dispatching or selecting state:

   1. Dispatch (updating state):

      1. import { useDispatch } from 'react-redux';

      2. Assign useDistpach() to a variable.

      3. Import the function you would like to use from the action.

      4. Dispatch the action with the data(payload) to the reducer.

   2. Select (accessing state):

      1. import { useSelector } from 'react-redux';

      2. Assign a variable to get the appropriate state.

      3. Use the variable as state wherever you might like.

Bonus

A cool thing about actions, is that you can use them to handle tasks you might repeat in various components. For example, maybe you want various components to fetch data when they render. You can create an action that handles this for you and updates state so you do not have to type the fetch multiple times in multiple components.

Here is an example of my set up, and how I used this in the component upon the pages render:

Action:

export const loadIncidents = () => {
  return (dispatch) => {
  fetch('/incidents')
  .then((r) => r.json())
  .then((incidents) => dispatch({type: "LOAD_INCIDENTS", payload: incidents}))
  }
}

Reducer:

const initialState = []

const incidentReducer = (state=initialState, action) => {
  switch(action.type) {
    case "LOAD_INCIDENTS":
        return action.payload
    default:
      return state;
    }
}

export default incidentReducer;

Component:

import { loadIncidents } from "../actions/incidents";
import { useDispatch } from "react-redux";

const Home = () => {
  const dispatch = useDispatch();

  useEffect(() => {
    dispatch(loadIncidents());
    dispatch(loadResources())
  }, []);

It's official, I have completed another application using REACT as the frontend framework, and Rails on the backend. Inside Rails, I used ActiveRecord as my ORM framework. My project "has many" (no pun intended) forms throughout. A form for a user to log in with a username and password, a form for a user to create new content, a form for a user to create new projects within the new content, and a form for the user to edit a project they already created. To say the least, there are a lot of forms, and I needed validations to prevent a user from submitting bad data. Data that could harm the database, or blow up the frontend. Thus, I wanted to write about validations, why we need them, and which validations are better, frontend or backend.

FrontEnd Validations

Frontend validations are great for many reasons, but they also have some downsides. One reason they are great is some frontend validations are easy to implement. For example, in REACT, I simply added the required property to the end of my form input field like so:

<form onSubmit={ handleSubmit }>

        <input type="text" placeholder="Username" name="username" value={ signInForm.username } onChange={ handleChange } required/>

        <input type="text" placeholder="Password" name="password" value={ signInForm.password } onChange={ handleChange } required/>

        <button>Sign In</button>

</form>

This property caused each of my input fields to require data before the form could be submitted.

Another reason why frontend validations are great, is they prevent any need for a request to the backend and this saves a user valuable time. For instance, if the user of our app is at home, hooked up to blazing-fast internet speeds, this might not be an issue. However, as we all know, many people use mobile devices in today's world. Mobile internet speeds have increased, but often slow down due to many factors. A user on a mobile device may become irritated at the slow form submission and give up using our app altogether. To prevent this, it's simple to set up frontend validations so our users can immediately see any errors they might have made.

On the other side of the coin, I have found two large issues with only using frontend validations. First, validations can become very complex and cause our app to not be as optimized as it could be. Second, frontend validations still leave our database exposed to users submitting bad data. For example, we could easily use an application like Postman to submit bad data to our backend without the frontend validations looking at the data. Without backend validations, our database can easily become corrupt.

BackEnd Validations

As stated above, backend validations have bonuses and drawbacks. The bonuses are that backend validations prevent users on the frontend, and users who circumvent the frontend, from sending bad data to our app's database. The downside is a user must wait for a request to be sent to the database, and returned, before they know if the data they entered will be accepted.

Although there are downsides, backend validations are crucial. Outside of preventing bad data from entering our database, the greatest bonus I found is that they are incredibly simple. I used ActiveRecord as an ORM Framework in Rails and this made the job even easier.

To briefly summarize how easy validations are, let me provide a screenshot of my users model. It is titled contractors since a contractor is the user of the app.

class Contractor < ApplicationRecord
  has_secure_password
  has_many :projects
  has_many :houses, through: :projects

  validates :name, presence: true
  validates :specialty, presence: true
  validates :company, presence: true
  validates :city, presence: true
  validates :state, presence: true
  validates :username, presence: true, uniqueness: true
  validates :password_digest, presence: true
end

For a contractor(user) to sign up for an account using the form I provided on the frontend, I wanted to verify that all fields contained some sort of data. I did this simply by requiring the presence: to be true. For the username, I desired each user to first have a username, and second, to have a unique username. I simply added uniqueness: true to require this and boom, my validations were created in the backend. No sophisticated logic, or endless functions on the frontend. I could have added many more validations to my app, but for my simple app, I decided to simply validate the presence of data for all of the fields.

A developer could easily validate the number of characters, uniqueness, email, or dates within a specific range. These and so many more validations can be quickly implemented on the backend. Not only is the validation process super easy, but errors can usually be shown on the frontend to a user who may have provided wrong information. Combined, these features show the power of backend validations.

For more ActiveRecord validations, I would encourage you to visit the ActiveRecord validations page.

So, BackEnd or FrontEnd Validations?

Frontend or backend? Which area of validation should you choose? In my opinion, you should use both frontend and backend! At the very least, you should always validate data on the backend to protect your database. Some frontend validations are easy to create. Thus, they are an easy solution to overcome the downside of using backend-only validations. By using both, a user does not need to wait for a server request for most of the validations to appear. However, if the use manages to enter bad data on the frontend, our backend validations should catch any errors.

Give validations a shot, and see what you can come up with to protect your database!

Up to this point, I have desired to have an automated process to "seed" a database with user information. Many times in my early stages of programming, I desired to create applications where users would input information. This information would then be displayed on the application in some way. However, with no data to reference, it was difficult at certain times to visualize what my application would look like or how the data might display. My difficulty was all too evident. I needed to add data to my database, but until I designed a way to input the data, it would be impossible to have the references I desired. I desired to have realistic data in a database which I would not have to enter manually, one by one.

It wasn't until I learned Ruby, and how to use Active Record, that I learned about great options where I could create a realistic database in a matter of seconds.

Set-Up

First, let me show an example from a recent project I created. It was my desire to build a web basic API with Sinatra and Active Record to support a React frontend. My app would allow a leader of a youth group to keep track of fundraising for students attending a group trip. The leader could input a student and each student would have many donors. The app would track how much each donor gave to a particular student and would allow the youth leader to easily see if the donation from a donor was received. A donor could also be deleted or added.

In the back end of my app, I created two models: a student model and a donor model. Each student has many donors. Here is an example of each migration I created:

class CreateDonors < ActiveRecord::Migration[6.1]
  def change
    create_table :donors do |t|
      t.string :first_name
      t.string :last_name
      t.integer :donation
      t.boolean :donation_received
      t.integer :student_id
      t.timestamps
    end
  end
end

class CreateStudents < ActiveRecord::Migration[6.1]
  def change
    create_table :students do |t|
      t.string :first_name
      t.string :last_name
      t.integer :age
      t.timestamps
    end
  end
end

My dilemma, was that I wanted to create many students and a few donors for each student. I understood how to do this using the .create method like so:

Donor.create(first_name: "Joe", last_name: "Smith", donation: 25, donation_recieved: false, student_id: 1)
Student.create(first_name: "Joe", last_name: "Smith", age: 25)

I could do this in the seeds.rb file for ever single donor and every single student, but quite frankly I did not have the time. More importantly, the data would not be unique to each donor or student because copy and paste would have been my next solution.

Thankfully, I found a gem to create randomized data for me while I was busy learning at Flatiron School.

The Faker Gem

The faker gem became my saving grace. Not only would it seed as much data as I desired, it would allow me to create random data. The amount of data generators I could choose from were unreal! For example, Faker can create random addresses, names, video games, military ranks, and so much more! Check out their resource to find out all they offer. However, let me show you how I used this gem to easily seed data into my project.

Add the gem to Your Gemfile

First, you must add the gem to your Gemfile. You can easily get access to the most current Faker gem by adding the following to your Gemfile:

gem 'faker', :git => 'https://github.com/faker-ruby/faker.git', :branch => 'main'

If you want access to all the Faker generators, including the unreleased generators, you will need to use:

gem 'faker', :git => 'https://github.com/faker-ruby/faker.git', :branch => 'main'

Make sure you install the gem

Using bundle install you can install all the gems in your gem file.

Use the generators in a seed file

Using the list of generators provided by Faker, you can now choose which generators you might need to seed data to your database. In the seed file, you simply need to add a generator like Faker::Name for each input like so:

puts "🌱 Seeding data..."

# Seed your database here

8.times do

  #Create a list of 8 students 
  student = Student.create(
    first_name: Faker::Name.first_name,
    last_name: Faker::Name.last_name,
    age: rand(12..18)
  )

  #Create 1-10 donors for each student
  rand(1..5).times do
    Donor.create(
      first_name: Faker::Name.first_name,
      last_name: Faker::Name.last_name,
      donation: rand(10..100),
      donation_received: Faker::Boolean.boolean,
      student_id: student.id
    )
  end
end

puts "✅ Done seeding!"

For my project, I asked Ruby to run a loop for eight times. Each time the loop was ran, I desired for a student to be created. For each student, I desired to create a donor one to five times. Each student was given a random first name from Faker and a random last name. You can see this by the Faker::Name.first_name and Faker::Name.last_name generators I used. The .first_name allowed me to generate names which were strictly first names.

Seeding the Data

Just like with manually entering data, you can simply use bundle exec rake db:seed in the console to seed your database.

Wrapping Up

Overall, I would highly recommend using Faker to help seed your database. Especially if you need to create a lot of data fast. By using the Faker gem in your developer environment, it will allow you to have a much more successful launch of your application. I hope this helps you, as much as it did me!

Resources

Faker Gem

Approximately two months ago, I began using REACT to further my software developing skills. It was the core of my phase 2 curriculum at Flatiron school, and quickly I discovered some incredible benefits to using REACT. However, this blog is not about the entire database of REACT, but one of the powerful features - the useEffect hook.

What is the useEffect hook?

The useEffect hook allows us to run additional code in our REACT component which is not triggered by a user input, like a form submission, or click. The hook allows us to handle side effects when a component is called upon. For example, useEffect might be used to GET information from an API that you would like to display on your page. Rather than making a user click a button to see the information, it can be displayed on the page right from the start of the application. This helps with data, like current weather, or fetching the most up to date user information from an API so it is ready to use within an apps page. Side effects are changes caused in our application outside of a function itself and can be very helpful.

By using the useEffect hook in a component, it tells REACT to perform another task after rendering all the components and building the DOM elements from the components JSX. (Remember, components return JSX.) useEffect will be called when a component is rendered and tells REACT our component will need to perform another task after rendering.

Starting with useEffect

In order to use the useEffect hook in a component, we must first import it to our component. The following code will import useEffect into our component, just like other hooks.

import React, { useEffect } from "react";

Now, we need to insert useEffect into our component like so:

import React, { useEffect } from "react";

const Component = () => {
  useEffect()

  return (
  <div>
  <div>
)}

Passing useEffect a Callback Function

In order to get our useEffect hook running we must pass it a callback function, which will run as a side effect. This function will be the first argument we pass useEffect and can look like this:

import React, { useEffect } from "react";

const Component = () => {
  useEffect(() => {})

  return (
  <div>
  <div>
)}

The Second Argument - A Dependencies Array

If we only use the code we have created above, we can run into an issue. This is because useEffect will run every time our component renders. This can be an issue, for example, if we only need to fetch data from an API when our app or component first renders. It would not make sense to have our app continuously fetching data every time state changes. This could slow down other processes occurring in our app or cause errors. Possibly, we might only want useEffect to run when a specific variable changes. Both of these scenarios are easily solved by placing a dependencies array as a second argument in useEffect.

If we want to tell REACT we only want our side effect to run the first time our component renders, we can simply pass an empty array like so:

import React, { useEffect } from "react";

const Component = () => {
  useEffect(() => {}, [])

  return (
  <div>
  <div>
)}

If we want to tell REACT to run our side effect when a variable changes, we simply pass the variable into the array like so:

import React, { useEffect } from "react";

const Component = () => {
  useEffect(() => {}, [someVariable])

  return (
  <div>
  <div>
)}

We can even pass multiple variables, separated by a comma if we would like.

Lastly, if you would like our sideEffect to run every time our component renders (like when state or props change), don't include the dependencies array at all. Here is a brief overview to simplify everything we just explained.

• useEffect(() => {}) No Dependencies Array = We will run the side effect every time our component renders including when state and props change
• useEffect(() => {}, []) Empty Dependencies Array = Our side effect will run only the first time our component is rendered.
• useEffect(() => {}, [variableOne, variableTwo]) Dependency Array with Elements = Our side effect will run any time the variable(s) change.

Cleaning Up

The last great feature of the useEffect hook which we will cover is the ability to "clean up." Sometimes we might have a component which runs continuous code, like a timer, or clock. We may only want this code to run when we display the component. For example, a user might have the ability to hide or show this component, and we do not want the code to continuously run while it is hidden. This could use memory and resources we would like to have elsewhere in our application. It might also cause a "memory leak" which we will likely get an error message for. Thankfully, we can use clean up in our useEffect hook to prevent our code from continuously running.

In order to cleanup, we simply insert the following code into our callback function: return function cleanup() {clean up code goes here} This will allow us to stop the timer for example when it is hidden from the screen, or when a different component is rendered where we no longer need the timer to continuously count.

Conclusion

Over all, the useEffect hook is very handy and quite simple to use. It allows use to handle side effects outside our components and start/stop tasks from only being handled when certain variables change.

For more information on using the useEffect hook, I would encourage you to visit the REACT Documents here.

Location On the Keyboard

My first issue, after learning single quotes were not backticks, was figuring out where they are located on the keyboard. Just to make this as simple as possible, here are the main locations of each character on the keyboard. Although, you will likely need to search your own keyboard or use Google to verify the location on your keyboard.

Backtick (`): Located on the same key as the "tilde" (~) key, the backtick key is usually located just above the "tab" key, on the left hand side of the keyboard.

Single Quote ('): Located on the same key as the double quote, usually two keys right of the "L" key. Press the key once for a single quote.

Double Quote ("): Located on the same key as the single quote, usually two keys right of the "L" key. Press the key once, while holding the shift key, for a double quote.

How to tell the Difference Between a Backtick (`) and Single Quote (')

The easiest way to tell the difference between a backtick and single quote when looking at code, is to look at how they are standing. A backtick leans to the left. Thus, the reason for the name backtick. A single quote will usually stand straight, or lean to the right, making it easier to identify. The single quote will also sometimes appear bolder than the backtick character.

The Difference Between Single Quotes and Backticks

When I first started to learn to coding in javascript, I was greatly disappointed when I could not get something as simple as interpolation to work. I ended up doing something entirely different until I discovered my error. The reason, I was using single quotes instead of backticks. They looked similar, but according to the computer, they were very different.

How to use Backticks (`), Single Quotes ('), and Double Quotes (')

Single and Double Quotes

Single and double quotes are used in javascript to create strings. Strings store a series of characters between single or double quotation marks. They look something like this:

const string = "String of characters inside double quotes.";
const singleString = 'String of characters inside single quotes.';

Using a Single Quote as an Apostrophe:

What if you wanted to include an apostrophe inside the text in your string? Without some modification, javascript will not differentiate between an apostrophe and a single quote. That's because they are the same character. This is what happens if you try to enter an apostrophe without any other characters.

const apostropheString = 'I know the computer's not going to like this!';

Notice how the string stops at the apostrophe. This is because the computer believes it to be a single quote. In order to show javascript this is intended to be an apostrophe, we must use a backslash () before the apostrophe.

const apostropheString = "The computer\'s going to like this!";

Using Javascript Methods on Strings

A nice feature of using strings in javascript is the fact you can use javascript methods on them. For example, you can have javascript return a specific character (I.e. character 2).

let string = "ABCDEFGH This is the alphabet!";

console.log(string.charAt(0)); //returns A
console.log(string.charAt(3)); //returns D
console.log(string.charAt(29)); //returns !

To reference more javascript methods you can use on strings, visit W3 Schools.

Backticks and Interpolation

Now, the most important reason to find the backtick key, is that you need it for interpolation. Interpolation is a very useful tool when forming strings. It allows you to embed an expression inside a string. You must use the backtick in place of the double or single quotes, and include ${ expression } inside the backticks in order for this to work. After adding these features, interpolation becomes very useful.

For example, you can add two numbers together:

let string = `The sum of 2 and 5 is ${2 + 5}!`;

console.log(string); //The sum of 2 and 5 is 7!

Or, you can add one string expression into another string:

const weather = "cloudy";
const string = `The weather is ${weather} today!`;

console.log(string); //The weather is cloudy today!

The options are really limitless, but make sure to use backticks in order to get interpolation to work.

One Last Tip: Merging Strings Using Concatenation

Strings can also be merged using concatenation. To do this, two or more variables which have been assigned to strings can be placed inside another variable with the plus (+) symbol between them. The return will be one complete string.

const weather = " cloudy";
const string = "The weather is";

const theWeather = string + weather + "!";

console.log(theWeather); //The weather is cloudy!

Notice the space between the double quotes and the word 'cloudy' in the first string. This allows for the final string to return like a normal sentence. Spacing can be added in between the quotes and string characters in order to form the string you are looking to create.

Conclusion

Javascript has some great features which make working with strings very easy. By looking into various tips and tricks, these features can be used to create some amazing features in javascript. Don't forget to use the correct characters (double/single quotes, backticks, etc.), because without them a string will not return properly. Have fun and give some of these practices a try!

From as far back as I can remember, I enjoyed spending time outdoors. In fact, it was likely the hobby I loved the most. More than warm beaches, coffee shops, roller coasters, entertaining friends, or spending time in cities, I enjoyed the great outdoors. I found a love for hiking, and soon, a passion for exploration. Without cell service or GPS, I would often hike trails while using a map to guess where I might be in a vast sea of trees. Hours easily turned into days, and flat trails quickly became steep. I often found myself exhausted. Not knowing where I was going, what I might see, or if I would ultimately get lost. Too often then not, I spent hours, or even days searching for mystical views only to find more trails leading to endless other options. It was in the midst of this exploration that I unleashed a disease in myself which has affected me to this very day. A disease that can be dangerous if not tamed, but powerful if used appropriately. It's difficult to give this disease a specific name, so instead, I will describe its side-effects.

The Challenge

Soon, hiking the usual trails became monotonous. I started to set out to find areas of wilderness barely touched by human kind, where paved trails didn't exist, and majestic sights could be found around every curve in the trail. I desired challenges few had conquered with the need to complete them myself. My ideas started small until I received a phone call from a dear friend. He lived outside of Wyoming (where I currently lived) and he asked if I would be willing to join him on a backpacking journey to Wyoming's Cloud Peak Wilderness. He spoke of summiting a mountain called Cloud Peak, the tallest peak of the Big Horn Mountain range, in the middle of the state of Wyoming. He expressed a desire to climb the 13,171' tall mountain in two days in order to explore it for future backpacking trips with groups. He explained the trail was approximately 24 miles long (round-trip), with a 5,000 foot elevation gain, and it would likely be difficult. Neither of us knew how difficult it would truly be, but for the sake of time, let me say we found it to be extremely difficult....Both of us has to push through limits we had never reached before...I was used to running 7 miles a day, but this mountain, was a much steeper giant to conquer. As we reached false summit after false summit, we became discouraged wondering if we would even reach the top, or if we should have given ourselves more time. Our legs became weak due to the lack of oxygen at that altitude, it felt as though we could not inhale deep enough to fill our lungs with vital oxygen our tired muscles needed. The incredibly steep rock face continued to mock us until we finally reached a ledge where we could see the summit. It still took us two hours to reach the top from this point, but we did, and the reward was well worth it! With 2,000 foot cliffs all around us, we could see from one side of the state to the other.

The hike out was exhausting. When we reached the trailhead, I felt as though I did not have enough strength to press on the brake pedal of my truck. For the next year, I told myself and others I was done, and would never climb such a mountain again......

.....That was until the next summer, when I decided to participate in raising funds for a non-profit group benefiting orphans, missionaries, and teen camps. Only this time, I decided to climb Cloud Peak in ONE DAY. The view, the excitement, the achievement....the disease...begged me to return, to prove to myself this was possible. So, I did it...I climbed the mountain in one day, with great assistance from milky way candy bars. Again, I hated the pain, but loved the wonderful feeling of accomplishing something so difficult.

The Physical Trail Leads to the Technical Trail

At this point, you might be wondering why I would start my first blog (ever), and more specifically my first technical blog, with a story about hiking in the wilderness and some weird disease infecting me. I understand how this might be confusing, but I think it might help those who read this understand me: I am someone who strives to take on difficult tasks (whether physical or mental) and work at them until I can achieve them. This mindset has allowed me to help others, and solve major technical issues for many church congregations across the United States.

My love for taking on, and solving, tough problems is ultimately the main reason I decided to start a journey of software engineering. The challenge of solving difficult problems, so that others could benefit, excited me. With having just completed my first web-based javascript app in the Flatiron Bootcamp School, I continue today with this faith: that one day I will be able to help others succeed by building critical code to assist in our technological world. I have never been one to desire fame, and it's another reason why I love software engineering. It gives me the ability to build limitless apps, while letting the app get the credit. In this journey, it is not my desire to earn lots of money, or become famous, but it is my desire to change the world for the better! To find impossible tasks which are around us today, and solve them for the generation tomorrow.

So, this disease that led me to climb mountains in an impossible manner, is now leading me assist in solving impossible tech problems around us. I am excited to see where the journey leads me and the others I will meet along the way. I hope my background shines a light on who I am, and why I decided to take on the challenge of software engineering.