Forem: James Easter

Visualizing Merge Sort

James Easter — Sun, 19 Jul 2020 18:22:36 +0000

I find algorithms fascinating. I've recently been focusing on the awesomeness of sorting algorithms. This is no coincidence as I dove head first into a personal project with the aim of accomplishing two things: become familiar with Vue.js and grow a deeper understanding/ appreciation for sorting algorithms.

My idea for this project was to create a sorting algorithm visualizer that displayed the moment to moment operations that occur inside of each algorithm. This absolutely helped me achieve the to goals previously mentioned (utilize Vue.js & learn more sorting algorithms).

While building this visualizer I came across several challenges. The first challenge was simply diving deeper into each algorithm and writing my own version. The next challenge was dissecting each operation in order to pick and choose what I needed to visualize. Several of the algorithms them lent themselves to being slowed down by async/await functionality, flipping some colors and values, and then letting the algorithm do the rest. I go over an example of this with bubble sort in this blog post. However, merge sort was not so straight forward.

If you are not familiar with how merge sort operates check out this blog and my visualizer so we can dive into the killer inner workings of animating this dude.

Cutting to the chase: merge sort has several steps that require recursive function calls, because of this, I found it increasingly difficult to know when and where to pause the code and color and move the data appropriately in order to visualize the algorithm's operations.

In fact, I never got it to work... I would slow one part of the algorithm down to visualize it which would then cause another part of the algorithm to get all jumbled up. I knew I needed another solution. My algorithm worked excellently and sorted data quickly, but I was having a heck of a time trying to visualize any piece of it without messing up its entire functionality.

So, brainstorm, brainstorm, brainstorm... I decided to not change anything about the algorithm. Instead, I would let it run like normal and add another parameter which would take an array that recorded the operations as they happened! In other words: at each operation inside of merge sort I would create an object that would record the current action (comparing or overwriting), the index, and the value of each piece of data being sorted.

Example of one of the objects:

      {
        // record what action was happening
        action: "overwrite",
        // which index it was occurring at
        idx1: k,
        // the value at that index
        value: arrayCopy[i].value,
      }

Because Vue.js cannot pickup on the updating of an array or a property of an object without the calling Vue.set(), I could let my merge sort algorithm run, record each computation in an object, then store that object to my animations array.

Once the merge sort was finished sorting (which is just about instantly) the DOM looked the exact same and I had an array of objects that held the information from each computation.

All I had to do then was iterate over this array of animations and slowly animate these changes using Vue.set() and then voila!

Once my merge sort algorithm ran, I ran this method to visualize each animation on the DOM.

async function animate(animations) {
  for (let todo of animations) {

    if (todo.action === "compare") {
      // changes the color of the two indexes being compared
      let { value: val1, color: col1 } = this.numbers[todo.idx1];
      let { value: val2, color: col2 } = this.numbers[todo.idx2];
      this.$set(this.numbers, todo.idx1, {
        value: val1,
        color: this.compare,
      });
      this.$set(this.numbers, todo.idx2, {
        value: val2,
        color: this.compare,
      });

      // pauses the event loop to better visualize the algo
      await new Promise((resolve) => setTimeout(resolve, 20));

      // changes the colors back to original color
      this.$set(this.numbers, todo.idx1, {
        value: val1,
        color: col1,
      });
      this.$set(this.numbers, todo.idx2, {
        value: val2,
        color: col2,
      });
    } else {
      // pauses the event loop to better visualize the algo
      await new Promise((resolve) => setTimeout(resolve, 20));

      // overwrite idx1 with idx2, change color to sorted
      this.$set(this.numbers, todo.idx1, {
        value: todo.value,
        color: this.sorted,
      });
    }
  }
}

It's no secret that merge sort can be very tricky. There are several ways of implementing it, but an important note is that in order to utilize this visualizing approach it is necessary to record the index of the values that merge sort is manipulating.

That being said, if you ever so slightly have a hankering to tackle a visualizing project, do it! There is so much to learn and appreciate from each algorithm. I hope this has been helpful and interesting. Best of luck and share your sorting visualizations - we'd all love to see them!

Merge Sort Talk

James Easter — Sun, 12 Jul 2020 19:02:13 +0000

I had a hankering to learn a new frontend framework so I decided to build something - a sorting visualizer. While I'm far from finished, I wanted to share some fun things that I've come across so far relative to the algorithms.

I have two previous blogs that also deal with this material. One of them focuses on the fundamentals of bubble sort and the other discusses how I managed to visualize bubble sort as it is sorting.

This whole idea of creating a web app that visualizes a sorting algorithm has taught me many things, but specifically two: how to tackle problems in a new framework and how these algorithms actually function.

Merge Sort was certainly the most difficult of the sorting algorithms to visualize for me. Rather than utilizing async/await keywords to manipulate the timing of the call stack, I ended up recording some data after each operation in the algorithm and then iterating over the recorded data to visualize what had just happened. Sounds strange, but trust me it's pretty cool!

However, before I dive into that awesomeness I want to go over a basic example of merge sort to share my interpretation of this algorithm.

Let's kick it off by assuming we are given an unsorted array of integers and we are asked to sort them with merge sort.

The basic premise behind merge sort is that it will repeatedly (AKA recursively) split the given data in half until it consists of arrays of length 1. Why is that? Because an array of length 1 is in fact a sorted array. Then merge sort will begin to merge these arrays back together until it has one array of sorted values.

Let's walk through this process step by step with an actual array of unsorted integers to see this beauty in action. Here is our array:

[ 4, 5, 2, 7, 8, 6, 3, 9 ]

Now let's split it in half.

[ 4, 5, 2, 7 ] [ 8, 6, 3, 9 ]

Then we'll split each of those arrays in half.

[ 4, 5 ] [ 2, 7 ] [ 8, 6 ] [ 3, 9 ]

Finally, we'll split these arrays in half.

[ 4 ] [ 5 ] [ 2 ] [ 7 ] [ 8 ] [ 6 ] [ 3 ] [ 9 ]

As you can see all our array has been split into sub arrays so many times that we now have 8 arrays of length 1. Like we had clarified before, an array of length 1 is a sorted array, so now let's start merging them back together.

From here we will iterate over two arrays and compare the first indexes and return a new array with the two values in their sorted order. Starting with the first two arrays and compare their indexes. Since 4 is less than 5 it will go first and we'll merge the two arrays into one:

[ 4, 5 ] [ 2 ] [ 7 ] [ 8 ] [ 6 ] [ 3 ] [ 9 ]

Continuing, we'll do the same with 2 and 7:

[ 4, 5 ] [ 2, 7 ] [ 8 ] [ 6 ] [ 3 ] [ 9 ]

Notice the next two arrays contain the values 8 and 6. Since 6 is less than 8 we'll merge them together putting 6 before 8:

[ 4, 5 ] [ 2, 7 ] [ 6, 8 ] [ 3 ] [ 9 ]

And finally we'll compare the arrays containing the values 3 and 9 and merge them together:

[ 4, 5 ] [ 2, 7 ] [ 6, 8 ] [ 3, 9 ]

So far so good, nothing to outlandish going on here. In fact we're already on our way home! We'll simply repeat this compare and merge process all of the way back up.

If we compare the first two indexes of the first two arrays we'll see that 2 is less than 4 so it will go first. Then we'll compare 4 and 7: 4 is less than 7 so it will be next. We'll then compare 5 and 7 and put 5 next, then 7.

[ 2, 4, 5, 7 ] [ 6, 8 ] [ 3, 9 ]

Repeating this process with the next two arrays we see that 3 is less than 6, 6 is less than 9, 8 is also less than 9 so our merged array would look like this:

[ 2, 4, 5, 7 ] [ 3, 6, 8, 9 ]

Last step, again repeat the process we already have set up: iterate over each array, comparing the first values and merged them in a sorted order and we'll have our merged sorted array!

[ 2, 3, 4, 5, 6, 7, 8, 9 ]

It is certainly a divide and conquer approach. With the recursive nature you can also see a tree like structure appear from the recursive dividing and merging. Before we wrap up let's go over the time and space complexity involved here.

As far as time complexity, we start by splitting the array into a smaller arrays until we reach arrays of length 1 for each value. For starters we have an O(N) amount of operations. Then we eventually combine each of these arrays back together, iterating over each value to merged them into our sorted array which is also O(N) operations. So now we are at O(2N) which simplifies back to O(N). Finally, considering the fact that we cut the array in half and recursively repeat this algorithm on each half until we have length 1 we actually compute this O(N) amount of operations log(N) times resulting in an O(N log(N)) time complexity.

The space complexity can vary depending on how you implement the algorithm, but for this example of recursively calling merge sort and creating new sub-arrays we can see that we will divide and merge each value which gives us a space complexity of O(N). And we will repeat these steps on each recursive call (sub-array) which will come out to roughly O(log(N)). Combining these two considerations together we'll end up with a space complexity also of O(N log(N)).

Merge sort is super interesting and there are a few ways to implement it. Obviously, there will be several recursive calls going to separate and then merge all of these arrays in a tree like fashion which we can dive into next when I go over how to visualize this killer algorithm. I hope this has been helpful and has demystified the inner workings of this great sorting algorithm!

Visualizing Bubble Sort (Vue.js)

James Easter — Tue, 07 Jul 2020 00:12:17 +0000

As an attempt to dive into Vue.js and brushing up on my algorithm chops I decided to make an algorithm sort visualizer app: Algo-Visualizer

It was a lot of fun and there is still so much to explore, but I immediately was hit with some really cool insights I'd love to share.

I'll start at the beginning: I first created the shell of the app, removed all of the dummy data, and put placeholders for the header, the array with random values, and the buttons.

Then I made created the array which is simply iterated over as the vue component renders. Each value in the array is an object with two properties: color & value. The color property is used to give the initial background color to the div that holds it so we can see each of the objects in the array, and the value is the height of the bar.

Once I had my header, array, and buttons I was off to the races. I starting by writing the code for each algorithm and would then test them against hundreds of randomly generated arrays and JavaScripts built in sort function. Once I was sure that my functions were working as desired I attempted to visualize them.

Visualizing something for human appreciation that normally happens in a split second presents a whole set of challenges. I Somehow needed to slow down or pause the sorting function as it was happening, possibly change the colors of the values that were being compared, and then show if a value was in its final sorted position.

Fortunately, bubble sort is quite simple in its make up. While brainstorming possible visualizing solutions I recalled a blog I prepared on the ES8 keywords async/await (you can find it here). Realizing I could actually slow down the code by pausing it, I concocted a fun way to pause the code during the sorting algorithm to better visualize what is going on. This is the super secret special (kinda hacky) line of code that become oh so helpful for this specific algorithm:

await new Promise((resolve) => setTimeout(resolve, 1));

In short you can give your functions asynchronous capabilities when you use the async and await keywords. I simply put async in front of my function declaration and use this line of code in the middle of my bubble sort loop so I could change the colors of the two values in the array that were being compared, then pause the code to await the resolve of a setTimeout inside of a Promise, and then continue the sorting algorithm.

If we pick apart this line we are asking our code to sit and wait (or await) for the result of the Promise which is passed into a setTimeout function for 1 millisecond. The code then continues at its normal lighting speed until the next time it hits this line of code in our loop causing it to pause again for 1 millisecond.

While this is await usage is anything but helpful in the normal application of a sorting algorithm, here, it allows the sorting to be visualized in a way that helps us see and appreciate how bubble sort actually works and sorts values!

Below is my entire bubble sort function from my Algo-Visualizer app. The code comments help guide the overall explanation:

async function bubbleSort(ref, array) {
  // change the color to primary to start sorting algorithm
  array.forEach((num, index) => {
    ref.$set(array, index, {
      value: num.value,
      color: ref.primary,
    });
  });
  let counter = 0;
  let swap = true;

  while (counter < array.length && swap) {
    swap = false;
    for (let i = 0; i < array.length - 1 - counter; i++) {
      // change color of two indeces that are being compared
      let { value: a } = array[i];
      let { value: b } = array[i + 1];
      ref.$set(array, i, { value: a, color: ref.compare });
      ref.$set(array, i + 1, { value: b, color: ref.compare });

      // pauses the event loop to better visualize the algo
      await new Promise((resolve) => setTimeout(resolve, 1));

      // if the first index is greater than the second
      if (array[i].value > array[i + 1].value) {
        swap = true;
        // swap indeces
        let { value, color } = array[i];
        let { value: tempValue } = array[i + 1];
        ref.$set(array, i + 1, { value, color });
        ref.$set(array, i, { value: tempValue, color });
      }

      // change colors back to primary and set the final index color to sorted
      let { value: newA } = array[i];
      let { value: newB } = array[i + 1];
      ref.$set(array, i, { value: newA, color: ref.primary });
      ref.$set(array, i + 1, { value: newB, color: ref.sorted });
    }
    // increment counter
    counter += 1;
  }
  // change the color to sorted on the final iteration
  array.forEach((num, index) => {
    ref.$set(array, index, {
      value: num.value,
      color: ref.sorted,
    });
  });
}

module.exports = bubbleSort;

I extracted each of my sorting algorithms into their own separate JavaScript file as to not clutter the main Vue component.

In order for Vue to actively change the DOM elements that are created from the height of each value in the array I needed to pass in a reference to the Vue component which is passed in as "ref" and utilizes the .$set() method.

Otherwise, it's a the plain old tried and true bubble sort algorithm plus or minus some async/await tricks. Manipulating the timing of function calls in JavaScript is always interesting and initiates some fun learning opportunities.

While this simple async/await adaptation worked with Bubble Sort, other algorithms, specifically recursive sorting algorithms, required an entirely different approach. More to come on those tough dudes, hope you enjoy!

Bubble Sort Talk

James Easter — Sun, 28 Jun 2020 21:30:01 +0000

I recently have been checking out Vue.js and decided that it's time to build something with it so I can become more familiar with its inner workings and strengths. After walking through some of the intro material, following along with a few tutorials, reading documentation, and building the preverbal ToDo app, it was time to jump in!

So... What should I build? Well, what have I been doing lately? Drinking coffee, as always, but also studying algorithms! A perfect place to start.

My plan is to craft and deploy a Vue application that shows off (visualizes) different sorting algorithms. Deciding to start with one of the most basic sorting algorithms, certainly not the most efficient, I began with Bubble Sort.

In my next post I'll dissect some of interesting solutions I came up with for actually visualizing this algorithm to the viewer. However, before I dive into the visualization I will utilize this blog post to go over how bubble sort actually sorts.

So here we go: Let's say we are given a collection of 5 integers that are not sorted and we are supposed to sort them:

[ 3, 2, 6, 9, 1 ]

Bubble sort compares the first two integers, in this case it would be the values 3 and 2. If the first one is greater than the second, bubble sort will swap them. So, because 3 is greater than 2 it will swap them in place, altering the array to look like this:

[ 2, 3, 6, 9, 1 ]

Then it performs this comparison with the next two indexes comparing the values of 3 and 6. Since 3 is not greater than 6 it will not swap them. Repeating the process again with the next indexes: 6 is not greater than 9 so they won't swap. And finally, 9 is greater than 1 so they will swap. By the time we have iterated over the whole array the largest value of the array is at the end.

[ 2, 3, 6, 1, 9 ]

Now that the largest value has been sorted to the end of the array it is in its final sorted position so we don't have to compare any other values with its value. Keeping this in mind can marginally help the efficiency of our bubble sort algorithm by only comparing indexes that are not in their final sorted position.

Next we would repeat this same process of comparing two adjacent indexes, starting with the 0th and 1st index to sort the next largest value to the end of the array. If we repeat this process n times, where n is the number of values in our array, then by the last iteration all of the values will be in their final sorted position.

Considering the efficiency of bubble sort is very interesting. At its best, bubble sort operates has O(n) time complexity. This only happens when it is given a sorted array and if bubble sort keeps track of if it has performed a swap or not.

If bubble sort was given this array

[ 1, 2, 3, 4, 5 ]

...and it kept track of whether it had to swap two values or not. Then it would iterate over this entire array one time, not needing to swap values, and then return the sorted array.

Conversely, at its worst, bubble sort gives us a time complexity of O(N²) where N is the length of the array, because we will iterate over the whole array N to place each value it its sorted position.

The space complexity is not bad since we are swapping values in place, not creating a new array so it would in constant space or O(1).

Now that we've covered the basic concept of bubble sort here is a code example that walks through and executes the same logic:

const bubbleSort = (array) => {
  let swap = true;
  let counter = 0;

  while (swap) {
    swap = false;
    for (let i = 0; i < array.length - 1 - counter; i += 1) {
      if (array[i] > array[i + 1]) {
        swap = true;
        const placeholder = array[i + 1];
        array[i + 1] = array[i];
        array[i] = placeholder;
      }
    }
    counter += 1;
  }
  return array;
};

We'll start by initializing swap to a boolean value which allows us to use it as a flag in case our list is already in order. If we ever make a pass all of the way through the list of integers and don't make a swap we can assume our list is in order and kick out of the loop returning the array.

The counter variable allows us to not have to consider comparing values to those values at the end of our array that are already in their sorted position.

Following the variables we enter a while loop that is continues only if a swap occurs. Inside of our while loop we iterate over each index comparing it's value to the one next to it. We'll swap their positions if the first value is greater than the one that follows. After an iteration through the array we will increment the counter and repeat the process until the array is completely sorted.

This is a simple yet important algorithm that helps us consider space and time complexity as well as how it might relate to other algorithms. Up next I'll explain how I was able to visualize this with some async/await functions and css properties. See you then!

3 React Native Styling Tips

James Easter — Sat, 30 May 2020 22:06:52 +0000

Building a mobile application can feel intimidating. However, you are much closer than you realize to authoring an excellent app. React Native has made a concerted effort to help new developers dive in and getting started. I certainly recommend following their documentation as well as utilizing all that Expo has to offer in firing up your first mobile app. Both of these docs do a great job explaining the necessary steps to get up and running in a logical and sequential fashion. Two thumbs up!

That being said you can also follow their tutorials on getting started and building out simple components or even begin with one of their mobile templates. Before too long you'll be able to have a mobile app up and running and feel quite comfortable editing it to meet your own preferences.

I was first being introduced to React through building web applications and then jumped into building mobile applications with React Native. This switch illuminated some interesting differences, one of which had to do with styling. It is a common practice to have a React Native StyleSheet component at the bottom of your jsx file which handles all of the styling for that screen/component. Though this is different than how I organized my styling for a web application, I actually really enjoyed this convention as it can simplify styling by consolidating your styles and React Native code to the same file.

I also found that this practice empowers the developer to tweak the styles more readily. If you'd like to change the background color of your app to green, well it is just sitting their waiting to be changed and then immediately renders the change to your iOS simulator. Quick, easy, efficient, consolidated... I'm a fan.

However, with this convenience you might eventually find yourself in a pickle. It is not uncommon to continually and iteratively add styling to an applications not realizing that you are overriding or invalidating a previous style. Then, when you add flex: 1 to a component it oddly shrinks to an imperceivable size. Or, when you add justifyContent: flex-end and the text inside of your Text component it sits there on the left side of the screen more stubborn than you thought possible.

And now you have to start a bug hunt...

You dig and dig through your styling to figure out why your code is not reacting to your commands the way you expect it to. This can be annoying and time consuming to say the least!

So, in an effort to spare any individual from said experience: here are three tips that will help your styling remain effective and productive:

1. Be Intentional (watch for cause & effect)

Styling debacles easily occur when using a willy nilly, flippant, hacking approach. When you add styling to a component you should be able to articulate why you added what you did, and you should be able to explain what your styling is doing to that specific component.

You will find yourself in a situation where you won't know the exact name and value that you need. All you know is you want "this component" to move "over there." So you try several different styling names and values to see what will happen. This tactic is fine, and harmless, as long as you go back and immediately weed out what wasn't needed afterward.

Remaining accountable to your styling becomes extremely important when you are working with other people. If you leave styling values inside of different components that are lurking, dormant, waiting to explode and cause harm (More specifically: they are not actually doing anything at the moment because they are being overridden by another style), then this can cause a lot of confusion and frustration for someone who is trying to add to your code.

Here is an example of silly styling that unfortunately won't throw an error. You can clearly see the cause for confusion:

      const styles = StyleSheet.create({
        container: {
          backgroundColor: 'blue',
          backgroundColor: 'yellow',
        },
      });

React Native will implements the second of the two styles so you will in fact have a background that is yellow. Keep in mind the other styles you might be overriding with your additional styling.

If you are trying out a new property in your StyleSheet component then simply implement it, see if it created the desired result, and if not - remove it. Very simple, very important.

2. Keep Your Code Dry

This is a useful tip no matter what kind of code you are writing. You don't want to write the same thing multiple times (Don't Repeat Yourself). The more simple and concise your components are the easier they are for people to read and understand in the future (including yourself).

When you are first building out a component it can feel easier to write inline styling and then extract that to the StyleSheet component later on. When you begin extracting your styles out of inline, or even if you began by utilizing the StyleSheet component, keep an eye out for the opportunity to combine style properties. Think big picture. If you have several icons that all have the same styling, don't write out the same styling three times. Instead, combine their styling it a property that you can reuse:

      icon: {
        color: '#228b22',
        marginBottom: 5,
        marginHorizontal: 75,
      },

You'll thank yourself later.

3. Work Outside to Inside

This last tip can be very helpful when debugging a StyleSheet bird's nest. I have found it much easier to find bugs when I start examining the current styles from the outermost component. If you are having trouble viewing a component in your application it could be from how it is behaving inside of its containing Component. When debugging size, orientation, flex, etc. start from the outermost containing component and work in so you can know which styles are being imposed on which components. If necessary, turn the background color to a bright yellow of the component you are trying to edit so that it lights up on your simulator.

Here is an image of three different style properties with a yellow background. I first applied it to the centered container, then the outermost container of this component, and then container of the containing component. Clearly, it is very helpful to know what part of the screen you are actually editing with your StyleSheet.

And that's it! Three tips I continue to use all of the time. I hope these tips have been helpful and I hope they save you some time in your bright and colorful styling future. May all of your components and screens render as desired and your code be a joy for other people to work with!

Async & Await

James Easter — Sun, 24 May 2020 22:20:02 +0000

For most of the new ES6 features I was happy to adapt. It felt fun and cool to be on the hip side of things with my one-liner arrow functions and chic de-structuring. However... as cool as I once was, I met my match when ES8 came along. As soon as I ran into the async/await keywords I just turned around and went home.

I suppose my reasoning was no different than anyone else's when they resist change or refuse to modify an old habit. I mean really, things were going so well with promises and I was totally content with my .then() and .catch() architecture. So, I decided I would just say it like it is and tell ES8, "Thanks, I really appreciate the offer... but I'll pass on async/await. Good riddance!"

Annoyingly, not everyone seemed to follow my lead. I only continued to realize this as I would see these two keywords come up more and more in other developers code. Eventually, I buckled. I had to. The pain of the same was now bigger than the pain of the change.

So what did I do about it? The same thing I always do when I need to confront a monster in my life... I grabbed my sword, shield, and helmet went after that monster like there was no tomorrow! Put another way: I built a concise mobile application to better understand and demonstrate async/await's functionality, and now I get to share that with you. Hope you enjoy!

To get started on our journey I'll begin with some of the commands I ran to get my app up and running and then I'll walk through the code that demonstrates this great asynchronous functionality.

First, let's create our mobile applications (this is by no means specific to only mobile applications, that is just what I've had a large interest in creating as of recent). I installed Expo globally and then used it to initialize my React-Native application, similar instructions can be found in their documentation. I also installed Axios for an API request.

$ npm install --global expo-cli
$ expo init my-project
$ expo install axios

Once everything is installed we can change App.js to App.jsx and include the component we are about to create, AsyncAwait, as well as some simple styling for a full screen view:

import React from 'react';
import { StyleSheet, SafeAreaView } from 'react-native';

import AsyncAwait from './app/AsyncAwait';

export default function App() {
  return (
    <SafeAreaView style={styles.container}>
      <AsyncAwait />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    alignItems: 'center',
    justifyContent: 'center',
  },
});

Now let's work on actually building out our AsyncAwait component. In our project folder we can create a folder named "app" and store our AsyncAwait.jsx inside of it. Next we'll use set up a react native functional component with basic boilerplate code which will include the useState hook, a few react native components, and axios.

import React, { useState } from 'react';
import { StyleSheet, Text, View, Image, Button } from 'react-native';
import axios from 'axios';

const AsyncAwait = () => {
  return (
    <View>
      <Text>This is our AsyncAwait Component</Text>
    </View>
  )
}

export default AsyncAwait

const styles = StyleSheet.create({})

And just like that we're able to see this component render on our iOS Simulator! Let's keep it up and get to some functionality. Here we'll add in two pieces of state and build our aysnc/await function:

// useState hooks
  const [imgSource, setImgSource] = useState(null);
  const [loading, setLoading] = useState(false);

  const showAvatar = async () => {
    // Show loading text
    setLoading(true);
    console.log('Loading...');

    // Request github avatar
    const githubResponse = await axios.get('https://api.github.com/users/jameseaster');
    const githubUser = await githubResponse.data;

    // Pause here for 2 seconds
    await new Promise((resolve, reject) => setTimeout(resolve, 2000));

    // Remove the loading text
    setLoading(false);
    console.log('Image Added!');

    // Show the avatar
    setImgSource(githubUser.avatar_url);

    // Wait another 2 seconds
    await new Promise((resolve, reject) => setTimeout(resolve, 2000));

    // Remove the avatar
    setImgSource(null);
    console.log('Reset');

This being the meat and potatoes of our async/await exploration makes it feel only necessary to go line by line and describe what's happening in our function.

To begin we absolutely must include the async keyword in our function declaration. This does two things:

Allows us to use the await keyword
Allows our function to return a promise.

Next we set the value of loading to true and log "Loading..." to the console. The loading variable in state will affect our conditional which we'll add next.

We have now arrived at our first await keyword. This little guy will wait for the result of our axios request to github. If the request is a success he will return the results, if the request fails he will throw an error. (You can also explore handling these results with try/catch blocks!)

Again we await for the response from github to assign the githubResponse.data to githubUser. Next we pause, literally just pause for two seconds while await waits on setTimeout. This is to help show how await will wait for the result of a function. This also helps pretend like github took that long to send us a response to our GET request (teehee). We remove the loading text and show the image of the github user (me, in this case) we queried for.

Finally, after pausing to look at my avatar for two whole seconds, we clear our state to set up our app to do it all over again.

To see this in action we'll simply reconstruct our return statement with these three conditionally rendering statements and a modest amount of styling.

// return statement
  return (
    <View style={{ flex: 1, alignItems: 'center', justifyContent: 'center' }}>
      // Renders Async/Await button if imgSource and loading are false
      {!imgSource && !loading ? <Button title="Async/Await" onPress={showAvatar} /> : null}
      // Will render "Loading" loading is true
      {loading ? <Text style={styles.text}>Loading...</Text> : null}
      // Will render our image if imgSource is true and loading is false
      {imgSource && !loading ? <Image style={styles.img} source={{ uri: imgSource }} /> : null}
    </View>
  );
};

export default AsyncAwait;

const styles = StyleSheet.create({
  text: {
    fontSize: 20,
  },
  img: {
    width: 250,
    height: 250,
  },
});

That'll do it! I hope this code, pseudocode, and concise mobile application have been helpful in introducing you to async/await and provided you with a simple template to explore even more functionality. As you continue to build out your own applications with this awesome feature your code will certainly grow flexible and dynamic. Don't (a)wait!

Organizing with express.Router()

James Easter — Sun, 17 May 2020 16:56:50 +0000

To Router() or not to Router()?

Over the last several applications that I have been working on I noticed just how useful express.Router() can be. I also noticed that I don't always use it. In fact, on some apps, I forget it exists.

So when is it useful and to what extent? Glad you asked! We'll examine when it can be helpful and why, along with some code snippets that will get you on your way to using express.Router() the next time you need it.

Let's start with what is this router object. Express's documentation gives us three important short paragraphs to ponder:

A router object is an isolated instance of middleware and routes. You can think of it as a “mini-application,” capable only of performing middleware and routing functions. Every Express application has a built-in app router.
A router behaves like middleware itself, so you can use it as an argument to app.use() or as the argument to another router’s use() method.
The top-level express object has a Router() method that creates a new router object.

To summarize, an express router is an object that performs middleware and routing functions and behaves like middleware. Router() creates new instances of this object.

I'm not sure my summary was any more clear but once we look at the application we'll be able to see all of this in action.

To begin let's start with a basic express server setup:

const express = require('express')
const app = express()
const port = 3000

// Respond with Hello World! on the homepage:
app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`App listening at http://localhost:${port} 🚀`))

If you fire up the server with $ node your_server_filename or if you use the VSCode debugger (my personal preference) then you should see "Hello World!" in your browser when you go to http://localhost:3000.

Now let's think on down the line for this application when you are wanting to handle API requests and from your frontend to render and manipulate different data from your database. Woh! That was a big step. And I guess that is kind of my point. If you are building a small app to try out new tech, experiment with a new frontend, or test out a new database management system then setting up an entire system for handling API routes with express.Router() may be overkill.

However, if you are working on an application with several other developers and have a lot of API requests coming in, this could be your lucky day, new best friend, and your favorite post.

For a quick example, let's pretend we have users, messages, and posts in a database for a social media app we are building. Now at different points we will need to make api requests to our server for this information. To try this out we can utilize Postman to make api calls to our server.

Let's add the following to our server below our current get request handler and above our app.listen:

// Respond to a GET request to the /api/users route:
app.get('/api/users', (req, res) => res.send('Got a GET request at /api/users'));

// Respond to a PUT request to the /api/users route:
app.put('/api/users', (req, res) => res.send('Got a PUT request at /api/users'));

// Respond to a DELETE request to the /api/users route:
app.delete('/api/users', (req, res) => res.send('Got a DELETE request at /api/users'));

This only covers the /api/users route... We said we were going to handle users, messages, and posts. As you can see this will clutter our server file, quickly making it an extensively long amount of code that we'll have sift through and try to keep clean.

OR......

We could break up this code and organize it into a few files that are clean and easy to find. Yes, I like the sound of that.

Please welcome, the express.Router() to the stage!

First lets create a folder called "api" that is next to our server file, my server file is called index.js and is in a folder called server. Then let's add an index.js file to the "api" folder followed by these files in the same folder: users.js, messages.js, and posts.js. My file structure looks like this:

├── server
│   └── index.js
│   └── api
│       ├── index.js
│       └── messages.js
│       └── posts.js
│       └── users.js

From here we will build out our routing functionality. I'm going to walk through the users api requests code and you can copy and paste accordingly for as many new api routers as you'll need.

Code to add to server/api/users.js

const { Router } = require('express');

// Handles requests made to /api/users
const usersRouter = Router();

// Respond to a GET request to the /api/users route:
usersRouter.get('/', (req, res) => res.send('Got a GET request at /api/users'));

// Respond to a PUT request to the /api/users route:
usersRouter.put('/', (req, res) => res.send('Got a PUT request at /api/users'));

// Respond to a DELETE request to the /api/users route:
usersRouter.delete('/', (req, res) => res.send('Got a DELETE request at /api/users'));

module.exports = {
  usersRouter,
};

Notice we changed app.get to userRouter.get because we are utilizing Router() from express. Also our url is just '/', this is because when we import this into server/api/index.js we'll pair this usersRouter with '/users'.

Here's what we'll add to the server/api/index.js file:

const { Router } = require('express');
const { usersRouter } = require('./users');

const apiRouter = Router();

apiRouter.use('/users', usersRouter);

module.exports = {
  apiRouter,
};

Again notice we are using apiRouter instead of app (similar to users.js) and we are using usersRouter as middleware here.

And finally let's remove the three request handlers we originally had inside of server/index.js and add two lines of code require the apiRouter and use it as middleware.

const express = require('express')
const app = express()
const port = 3000

const { apiRouter } = require('./api');

app.use('/api', apiRouter);

// Respond with Hello World! on the homepage:
app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`App listening at http://localhost:${port} 🚀`))

Again we have abstracted all of the api request handlers into the two other files and are now using one piece of middleware to handle all /api routes and keep this code nice and clean.

If your server file is starting to look big and scary express.Router() is there for you. Hope you enjoy clean code and clear routes!

@react-google-maps/api thoughts (pt.2)

James Easter — Mon, 11 May 2020 06:02:19 +0000

On my last blog I went over my favorite react component setup for using @react-google-maps/api. I sang the blues about having to read multiple docs just to get the map component set up which motivated me to the point of blogging. After doing so, I realized there is more to the story than just rendering a map to a webpage, so much more!

While I won't be able to cover my entire mapping adventure I wanted to at least talk about a very important part of maps, markers. This blog will be useful to anyone who has the initial google map component set up and rendering to their web application. If that's not you, and you'd like it to be, check out my previous post "@react-google-maps/api thoughts (pt.1)" and that should get you up and running. Then come back here to add some sweet markers to your shiny new map.

In this post I'll cover these three things (almost simultaneously):
1. Adding a marker to a map
2. Clearing a map of all markers
3. A few drops of useful code for future killer features

Let's get to it.

To utilize a marker with @react-google-maps/api we'll have to import the component at the top of our page so make sure you have destructured Marker as well:

   import { GoogleMap, useLoadScript, Marker } from '@react-google-maps/api'

Next we'll add need to add three things to our state: an id for the markers, an array for the markers, and a boolean, drawMarker, so we can know if we are drawing markers on the map or not.

   const [ id, setId ] = useState(0);
   const [ markers, setMarkers ] = useState([]);
   const [ drawMarker, setDrawMarker ] = useState(false);

Let me pause here for a short disclaimer...

My goal here is to provide a quick and dirty guide to rendering a map with markers all while understanding some simple tools for future develop of even more interesting features.

I normally would not recommend building out one solitary component to hold all of these features/functionalities. However, in the interest of sharing a smidge of insight, that's what we'll be doing here.

Well... I feel better. Let's carry on.

Next we need some buttons. These buttons will eventually allow us to add markers to our map and remove markers from our map. If we are going to add buttons we will have to wrap our current component in a . Then underneath the , but inside of the , we'll add some buttons.

     <div>
      <GoogleMap
      {/* a bunch of stuff we added from the last blog */}
      </GoogleMap>
      <button
        type="button"
        style={{backgroundColor: drawMarker ? "green" : null}}
        onClick={()=>{setDrawMarker(()=>!drawMarker)}}
      >ADD & DRAG</button>
      <button
        type="button"
        onClick={()=>setMarkers([])}
      >CLEAR MAP</button>
    </div>

At this point we should still have a google map displayed on http://localhost:3000/ as well as two new buttons. The ADD & DRAG button should even change colors when it is clicked on.

Let's pause for a worthy cause to understand where we are headed. When ADD & DRAG is green, which happens when drawMarker is set to true, we will soon be able to add markers with the GoogleMap's onClick functionality. When ADD & DRAG's background is null, the map will operate as normal. The background color of the button is dependent on truthiness of drawMarkers. We will write out the function to actually add the markers to the map next. The second button simply clears all (theoretical) markers off of the map by setting the markers state to an empty array.

Here comes the big kahuna. First we'll add an onClick function to the map which can come in handy for just about any future features you might want to add. Honestly this next console.log is why I wanted to write this entire blog in the first place. It took me a while to find this guy and once I did I started to realize some of the amazing potential that a map can offer. Put your seat belts on people:

      <GoogleMap
        {/* some other code we wrote inside of this component... */}
        onClick={(e)=> console.log(e.latLng.toJSON())}
      >

Open your console and start clicking on your map! As you can see, when you click anywhere on the map it logs the actual latitude and longitude to the console! It is not weird mouse coordinates that you have to convert, it is not a random click event, our app is logging specific, real, live, actual coordinates! So totally awesome.

Now, gather yourself and let's use these coordinates to add markers by their latitude and longitude.

To wrap this up we need write out a function that adds markers to our markers array in our state, rewrite our onClick to create a new marker only if our drawMarker is true, and then map over all of the markers to render them to the page.

Final step 1 of 3 - Add marker to Map

  // add marker to Map
  const addMarker = (coords) => {
    setId((id)=>id+1);
    setMarkers((markers) => markers.concat([{coords, id}]) )
  }

Final step 2 of 3 - Rewrite GoogleMap's onClick

   onClick={(e)=> drawMarker ? addMarker(e.latLng.toJSON()) : null}

Final step 2 of 3 - iterate over markers and create a Marker component with each one

    <GoogleMap>...{/* this goes inside of your GoogleMap component*/}
      {markers ? (
        markers.map((marker) => {
          return (
            <Marker
              key={marker.id}
              draggable={drawMarker}
              position={marker.coords}
              onDragEnd={e => marker.coords = e.latLng.toJSON()}
            />
          )
        })
      ) : null }
    </GoogleMap>

That was a lot of code to wrap up, but we are really just utilizing basic JavaScript to render these markers. The power of knowing that we have actual latitude and longitude coordinates at every click of a mouse is amazing to me. Go forth and map-make to your hearts content. See if you can remove a marker by its id, reset the center of the map (hint: myMap.center.toJSON()), or add info windows to the markers. There are some really cool capabilities in this library and hopefully these two blog posts will help you on your own mapping adventure. Best of luck!

@react-google-maps/api thoughts (pt.1)

James Easter — Sun, 03 May 2020 19:51:05 +0000

There I was... On a team... Given a task... make a map (or two)

And then this happened:

I needed a map. But not just picture of a map. I needed a google map to use inside of react. Specifically I needed to generate a map that would render data dynamically from our database. I also wanted to use another smaller map as an input field for a user who wanted to select a location of their liking, but didn't want to share their current location. I first turned to react-google-maps. Unfortunately, I found that this library - though very useful - was unmaintained. What to do, what to do, what to do... Yup, you guessed it: @react-google-maps/api to the rescue!

Well, almost.

While @react-google-maps/api did solve my problem of needing a "non-deprecated" library, I found their documentation functioned much more like a dictionary than a helpful guide. The walkthroughs and getting-started material was helpful for only a short portion of my map making adventures. I needed to render a map (documentation did help with that)... Then I needed to: render markers, compute the longitude and latitude of the markers, store that information in the database, and possibly change the map's center based on user interaction.

During this several-hour journey I eventually found what I was looking for and was able to create a couple of maps to my liking, however I spent a lot of time looking for information that I still think should be clearly outlined in the documentation in a more overtly obvious way. My biggest issue was that I found myself reading google maps documentation, react google maps documentation, and react google maps/api documentation and then having to combine all three to get a simple result.

So, enough jibber jabber and let's get on with the some pointers that I hope can be helpful for you in your map generating journeys.

We'll start here: My favorite component set up for a map

Again, simple, but I have to say it would have been nice to know this setup a week ago. Let's begin.

You will need to create a react app, install the react google maps/ api library, and then install dotenv for environmental variables.

npm i -S @react-google-maps/api

npm install dotenv

I am going to assume that you are comfortable with create-react-app and that you can make a google API key and hide it in a .env file. If not, there are fortunately gobs of tutorials out there on how to do so. Check out those tidbits and jump back over here once you're all set up. Now, this is what my most basic, stripped down Map component might look like:

import React, { useState } from 'react'
import { GoogleMap, useLoadScript } from '@react-google-maps/api'

const Map = () => {
  const [ myMap, setMyMap ] = useState(null);
  const [ center, setCenter ] = useState({ lat: 29.972065, lng: -90.111533 });

  const { isLoaded } = useLoadScript({
    googleMapsApiKey: process.env.REACT_APP_GOOGLE_KEY,
  });

  const renderMap = () => (
        <GoogleMap
          mapContainerStyle={{
            height: "50vh",
            width: "50vw",
            margin: "20px",
          }}
          zoom={10}
          center={center}
          onLoad={map => setMyMap(map)}
        >
        </GoogleMap>
  )

  return isLoaded ? renderMap() : null;
}

export default Map

This can look like a lot is going on here, especially for starter code, but it's easily broken down. I'll explain it from the top down and you'll be making some killer maps in no time.

At the tippy top we are importing React and utilizing the useState hook. Then we are importing the @react-google-maps/api library and using its GoogleMap component which is what will be our actual map.

We then created a functional component and named it Map and exported it at the bottom so that we can import it to whichever part of our app we would like it to be displayed. So far, so good. Let's skip the hooks for now and go to the line that starts with

const { isLoaded } = useLoadScript...

This deconstructed variable assignment functions in a really cool way. Your current predicament: you have to get the map from google and they have to approve your API key all before you can load it. This, isLoaded, combined with the returned ternary operator at the end will make sure your map is ready to go so you can have a smooth rendering each time.

Now diving into the meat and potatoes of the component. It might seem silly to add styling, but forewarning, if you don't specify width and height it will render so small you can't see it. We're talking 0 x 0 pixels, so you're going to need to specify something here. The next line concerning the margin is simply there so the map is not stuck at the very top of where ever you are wanting to render it. Please change these values as your heart desires.

Next we have the zoom, this is found in the documentation and tells google how far zoomed in our out you would like to the initial view to be.

And last but not least, we have our center and onLoad which will tie us back into our hooks. The center value is the longitude and latitude of where you want the center of the map to start. Google likes to use "lat" and "lng" so keep that "o" in "long" outa there. To take us home we have our onLoad which is saving this specific map instance to our myMap value in state so we can use and examine later.

That should do it for getting started with @react-google-maps/api. There are more snags and hurdles to overcome and we'll tackle some of those issues by finding going over useful tools in future posts. Fun mapping!

Schema Design: Basic Tables & Relationships

James Easter — Sun, 05 Apr 2020 18:37:44 +0000

About to tackle a huge task? Like building a full stack app and your own database. You're going need a plan, that's for sure. In the next few paragraphs I will aim to share with you some basic/ introductory insight in to how you can make a plan to organize your data with your schema design.

Let's start with what is a schema. When the word schema was first introduced to me it was in class. It is not a word I used before and doesn't seem to be a word I use often in my normal (non-coding) interactions. However, when I learned that schema can be analogous to the word blueprint, things started to click. I also quickly realized that word schema is use a lot in the development world, but it did not originate here nor is it confined to the development world.

If you google "schema definition" (at least at this point in time) the first definition you'll see says:

"a representation of a plan or theory in the form of an outline or model." -from Oxford

Again, no profound software development insight here... Except that we're talking about an idea. Or a plan. Something abstract that represents something else. So this was a lightbulb moment. A schema is what we put our tables on in a relational database management system, more on that in a moment, which acts as a blueprint for how we want to organize our data in our database. Schemas also address how we want our data to relate to each other if at all.

One of the reasons I enjoyed learning about schema design is because I like a good plan. Building out your schema is a great way to make a solid plan for how to house your data in your database before you even interact with it. I'll be specifically talking about what I had mentioned before, designing a schema in a relational database management system (RDBMS) like mySQL.

These RDBMS, which is much easier to type, are programs that allows us to manipulate (e.g create, update) relational databases; most of which use the SQL language to access their database. The relational part comes in to play with the tables and how each table might relate to one another.

We'll look into three different kinds of relationships between tables that we can utilize when designing our schema. The first relationship we'll start with is called a one-to-many relationship.

Here we have one album that can have many songs on it. This schema shows two tables where our 'one' in the relationship (the album) has a foreign key on the 'many' of the relationship (the song). The 'one' in the relationship is always puts its foreign key on the table of the 'many'. What this does is it references the data from the one's id rather than creating new data to (repetitively) store in the table of the 'many'. Think copy by reference verses copy by value. Foreign keys are great tools that allow us to show relationships between data and prevent ourselves from having to write code/data twice.

Next we'll look at a many-to-many relationship. As you noticed there are three tables here. We have our table of students, our table of teachers, and then a third table that they are both connected to. This is called our join table. It joins the primary keys (id) from both students and teachers tables and again allows us to not repeat ourselves when storing data, as well as prevents multiple pieces of data to be stored in the same box. Advantages here: dry code, clear relationships, easier data manipulation.

And finally we have our one-to-one relationship. We are online at our favorite store about to check out and our shopping cart is full of items that will hopefully make our lives even better. Well, each of these shopping cart items has quite a bit of information attached to it. The brand, the size, where it was made, etc. This information can be organized in a one-to-one relationship. These two tables are sharing id's because they are referencing the same thing but holding different information about this piece of data. Efficient and effective, what more could you ask for?

These are three must-know relationships when designing your next amazing schema. With a some planning and organization you can make sure that your data is stored in the best possible way by paying careful attention to how your data might best relate to itself. As always, keep that code dry and remember: design/plan now and save time later!

Backbone - Getters & Setters

James Easter — Sun, 29 Mar 2020 17:54:38 +0000

Dogs are amazing. Man's best friend, one could say. One of my favorite dogs is a golden retriever. They are happy, loyal, seem to smile all of the time, and they will retrieve whatever you throw at them. It often doesn't even matter what it is: newspaper, tennis ball, golf ball, frisbee, etc.

This wonderful piece of joy has somehow manifested itself into Backbone JS in very useful way. The get method. It retrieves attributes for you. Any attribute. Yup, it's that simple. But let's not stop there. If you pair this helpful method with the usefulness of the set method, you can have a whole slew of commands at your fingertips. Let's take a quick look at what each of these methods are and what they can do for us.

The get method is a built in method in Backbone that retrieves an attribute for us. If you recall, Backbone models and collections store information in their attributes property. A collection stores an array of models, while a model stores key/value pairs of attributes. Rather than using dot notation or bracket notation to look up attributes or models(inside of a collection) we can use the three letter word, get.

Here we have a model, song, which has an attribute of title. If we want to know what the title is we'll use the get method to 'get' the title for us. The syntax is simple and straight forward.

// returns the value of the attribute title
song.get('title');

Next, let's look at the set method. Set seems awfully similar to get, if for no other reason because they rhyme. Set is as direct and simple as get, but has a few extra features that are worth noting. You can utilize this method by passing in an attributes name (key) and then passing in what you want the value to be set to. Below, we are setting year to an integer so it doesn't need quotes.

// sets the value of year on the song model
song.set('year', 1958);

// you can also set multiple attributes at once
song.set({genre: "Jazz", studio: "Van Gelder Studio"});

Set not only will set the value for the attribute you have assigned to it, it will also trigger a "change" event if any of the attributes change the Backbone model's state. In other words, you can manipulate a model's state and alter its attributes with this little (powerful) method.

Let's put it all together by creating an album (we'll use a Backbone collection) with songs in it (made from Backbone models) and practice what we know about the get and set Backbone methods.

I am a huge John Coltrane fan. Love his music. So, since we are creating an album, let's use his first record "Blue Train" as our example. We'll start by extending Backbone's Collection and Model.

const Album = Backbone.Collection.extend();

const Song = Backbone.Model.extend();

Now that we can construct our album and its songs. Let's fill in the information we know about "Blue Train" by John Coltrane:

const blueTrain = new Album();
const song_1 = new Song({title:"Blue Train"});
const song_2 = new Song({title:"Moment's Notice"});
const song_3 = new Song({title:"Locomotion"});
const song_4 = new Song({title:"I'm Old Fashioned"});
const song_5 = new Song({title:"Lazy Bird"});

Great, we recreated the album and each song. The only issue is our songs aren't yet on our album. Set method to the rescue! As we know, collections hold arrays of models so we can use set on our collection and just pass in an array of the song models:

blueTrain.set([song_1, song_2, song_3, song_4, song_5]);

Let's check out progress with map and get...

blueTrain.forEach(song => song.get('title'));

// returns an array of all of the titles, very nice!
[
  "Blue Train",
  "Moment's Notice",
  "Locomotion",
  "I'm Old Fashioned",
  "Lazy Bird"
];

Perfect. To wrap it all up, let's see if we can add an attribute to each model to show this album's record label, Blue Note.

blueTrain.forEach(song => song.set('label', 'Blue Note'));

// and to check our result...

blueTrain.at(3).get('label'); // 'Blue Note'

These methods are awesome. They can give us direct attribute access and smart manipulation on Backbone's models and collections. We can use set and get to update and change attributes or even alter state which gives us so many dynamic possibilities inside of our code. Whether you love John Coltrane, golden retrievers, or both (I can't image anyone not liking either!), these two methods will serve you well.

Http Requests

James Easter — Sun, 22 Mar 2020 15:12:05 +0000

Sometimes understanding the innards of common processes can be strange because we've never thought about them before. For instance, what happens when you click a like button on a social media website? How does that little number next to the like button increase? Who told it to? Enter http requests.

Http requests are ways clients send requests to retrieve or modify resources/data, and servers then send responses back to the client to these requests. This clearly involves two parties. The client needs information, needs to give information, and/or needs to change information, and the server is there to listen and respond.

A server can create their own http request methods that a client must adhere to in order to send, receive, or alter their data. However clients and servers commonly follow the REST pattern which allows for clients to assume that there are a handful of http requests that the server has already set up for them. This format of RESTful API's is one that we will assume for sake of simplicity.

These are the four commonly used http requests: get, post, put, & delete. Let's examine each of these to see what they do when a client uses them to interact with a server.

GET - reads/retrieves a data. Requests using GET should only retrieve data, not send data.

POST - sends/creates new data to the server causing a change in state or side effects on the server.

PUT - updates specific data by replacing current representations of a specified piece of data with a new one.

DELETE - deletes a specified piece of data.

There are several other http request methods that you might see in addition to these four including OPTIONS, HEAD, CONNECT, TRACE, and, PATCH. As you might have noticed these are all verbs (with the exception of HEAD, and OPTIONS). Referring to to these methods as verbs is another common practice when following the RESTful guidelines.

So why would we need to know about these methods? Let's look back to the early days of internet surfing when web pages were made up of simply HTML files. Every web page was a static piece of data that you could view, but not interact with, certainly not in the way that we can now.

Tim Berners-Lee and his team at CERN are first proposed the original "World Wide Web" project in 1989. The first versions of what is now known as the World Wide Web had only one HTTP request method, the GET method. Clients would type in a URL which utilizes the GET method and then receive an HTML page from the server that would render as a static webpage for them to read and look at. Oh, how far we have come since 1989!

Now every time you post something on social media, like a friends's picture, change your profile picture, or delete your user from a website you are using these methods that we've talked about. Http request make the World Wide Web so much more dynamic and easier to interact with.

Now that we better understand these request methods, how do we utilize them as programmers? Let's first take a look at what JavaScript offers us:

var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function() {
   if (this.readyState == 4 && this.status == 200) {
      document.getElementById("demo").innerHTML = xhttp.responseText;
   }
};
xhttp.open("GET", "filename", true);
xhttp.send();

We are looking at an example of how to make a GET request with JavaScript. Admittedly, this is a little confusing and convoluted at first glance. We are creating a new instance of the HMLHttpRequest object and assigning it to xhttp utilizing pseudoclassical instantiation. Then we attach an event handler that calls the function is it assigned to whenever the "readystate" attribute changes on the xhttp object. This anonymous function sets up the document object with the our http request response text. We then call the GET method using .open() and finally send the request to the server with send().

The JavaScript approach is functional, but in reality it is likely something you will almost never use it. Most client side frameworks and libraries actually provide their own. For instance, jQuery gives you the AJAX method which offers a much user-friendly method, at least when compared to the native JavaScript approach.

Here is a GET request from jQuery:

$.ajax({
  url: url,
  data: data,
  success: successCallbackFunction,
  dataType: dataType
});

Here we are passing an object that lists the url to where we are sending the request, data which refers to a plain object or string that is sent to the server with the request, a success callback function that is executed if the request is successful, and dataType which is the type of data expected from the server. Ahh, how brevity can be so sweet.

Let's sum up what we've explored so far... Http requests are methods that the client uses to send, retrieve, or modify resources, and servers send responses to these requests. Thanks to Tim Berners-Lee we started out with a simple GET method for HTML and have now developed many more that make our internet surfing experience very dynamic. And while JavaScript has an XMLHttpRequest object built in, most client side frameworks and libraries provide their own way of making these requests which makes our lives a little bit better. Request away!