DEV Community: MaxwellBoecker

Creating Intents and Entities with Dialogflow

MaxwellBoecker — Mon, 21 Sep 2020 02:03:06 +0000

Introduction

Last week we looked at how to create a Dialogflow agent and integrate it into our NodeJS application. This week we are going to take a more in-depth look at how to use our agent. We will create a new conversational intent, provide some entities and parameters, and get a conversation going with our agent via the simple text-box app from last week. For a better background on what exactly the Dialogflow service can provide, check out the article from last week https://dev.to/maxwellboecker/using-the-dialogflow-api-in-your-nodejs-app-4hd8
or the official documentation https://cloud.google.com/dialogflow/es/docs.

Intents

A conversational intent ‘categorizes an end-user intention for one conversational turn’. This means that our agent is trying to parse exactly what the user is trying to convey with their turn in the conversation. All agents come with the ‘default welcome intent’. This means that they will be able to match our intention based on how closely our message resembles the any of the training phrases stored under their 'training phrases' list in the 'default welcome intent'.

When we say such things as ‘hello’, ‘hey’, or ‘hi there’, the agent recognizes our intent to greet it. It then selects one of the Responses programmed in order for it to fulfill the request.

Now we’re going to walk through how to create a new intent with training phrases and to help our agent recognize this intent by supplying entities and parameters. For the example, imagine we have a small grill that people must place orders for ahead of time. We are takeout only right now due to social-distancing. I am having my Dialogflow agent 'staff' my ordering application so that I can focus on cooking up orders for my customers and getting them ready in a timely and efficient manner. I'm going to train my agent to take an order.
I've created an intent called 'ordering entree'. Let's enumerate some training phrases.

Here, the thing I am concerned with is that my agent can recognize the intent to order, so I provide it with some examples of how people order.
However, I need to actually extract the value of the word used in the user request, the value of the entree. So I have to train my agent to recognize an entree and to distinguish it from something like a side or a drink. For this, I will create a parameter and corresponding entity.

Parameters

Defining parameters helps our agent to extract information from the user input. When our agent recognizes an intent, it searches for parameters and resolves them to the value that it finds in the entity recognized in the text written by the user. These values will then be returned in the agent's response to our NodeJS server where we can use them as we see fit. So I have created a parameter called entree, which has an entity called entree. The entity has two possible values, 'burger' and 'fish special'

Adding automated values allows the agent some freewill to try and make matches out of entities that have not been explicitly defined by the programmer. This essentially means that you trust it to make matches on its own if possible.
When I test my agent by sending a message through the simple application, I am met by the response I defined for recognition of the ordering entree intent.

Understanding the data

When my agent matches an intent sent from my user via my server, it sends back an object that contains quite a lot of information.

Notice how the queryText is the message we sent, fulfillmentText is the response our agent fulfilled the request with, and parameters is an object. Let's take a look at the parameters object:

Our agent was able to parse out the entree item from our ordering entree request! Now we can add it to the ticket.

Conclusion

The more entities we add for each intent, the more flexible our agent is in identifying exactly what it is that our end-user wants from the interaction, and also the precise value of the thing that is wanted. In our example, not only did our agent recognize the request to order an entree, it also was able to find out which entree was being requested. This ability to anticipate and parse valuable information out of user input, which is inherently variable, can give us an advantage insofar as we are able to deal with a wide range of interactions via just a single interface, that of our agent. Allowing such a wide range of services to be rendered from just a single component can help to simplify the structure of our application while still retaining maximum flexibility in how we respond to user input.

Using the Dialogflow API in Your NodeJS App

MaxwellBoecker — Mon, 14 Sep 2020 05:01:44 +0000

Overview

Dialogflow, from Google, is a ‘natural language understanding platform’ that can allow us to easily integrate a ‘conversational interface’ in our application. It is essentially the same thing as training a robot with natural language understanding capabilities to interact with users of our application. This might come in handy if we needed a way to understand one of many possible user intents in order to fulfill the requests appropriately. Imagine we have created an application for a restaurant that takes orders and puts them into a queue. We can use a Dialogflow-type conversational interface to prompt users for input, record responses, re-prompt them if the agent could not parse their request, and finally to submit orders when all the necessary information has been recorded. Perhaps somebody wants to place an order. Maybe somebody is checking on an order to see if it is ready for pickup and so on.

Dialogflow Agent Breakdown

We use ‘agents’ to handle conversations with our end-user. Agents can be trained to recognize the conversational ‘intent’ of our user as well as how to respond appropriately. According to the Dialogflow-ES documentation, “An intent categorizes an end-user's intention for one conversation turn”. Finding the intent of your user allows you to understand what it is exactly that they want. The way Dialogflow agents recognize intents is through a combination of matching ‘training phrases’ with the recognition of certain ‘parameters’. We supply both training phrases and parameters to help the agent understand what we need it to understand. Here is an example of training phrases which fall under the ‘default welcome intent’, or the intent to greet,

If one of these phrases is directly matched, a predetermined response is selected and returned to the user. The intent has been recognized, and has been responded to.
Another way to help your agent determine intent is to provide certain parameters, which are categories for words or phrases, that help it to recognize your intent. Once a category is created, we can enumerate different possible values that fall into this category. If one of the values is recognized, the agent will assume a certain intent is being conveyed and will select an appropriate response.

Sounds good! Now let’s see how to integrate a Dialogflow agent into a simple node.js application.
First we need the application. For this task I have created a very simple app with an Express for NodeJS back-end, and a ReactJS front-end which renders a text-box and a list of messages. This is the format we will use to communicate with our Dialogflow agent. We are going to send a message which will get passed to the server who will contact the agent, who will parse the request and send back a response.

Since the app is ready to roll, let’s dive right in to creating our agent.

First off, we go to the Dialogflow ES console.
We select the menu on the top left and select ‘Create new agent’

Here I just create it with the default settings and name it DemoBot

Excellent! Our bot comes with a default welcome intent! We'll see more about using intents in the next article. When we send our initial request through the API to our agent, we will send 'hello', and it will register our intent as 'default welcome'.

Now lets go to the google developer’s console. If you don't have a google developer's console, it is quite easy to create one. This is the console that you manage all projects from. Creating the Dialogflow agent also creates a project in your console.
In the console, I search for demo, and DemoBot pops up. I select this project.

Now its time to enable the api. In the dashboard of our project we hit 'Enable APIs and Services

We can then search for Dialogflow and enable it.
Ok! Easy enough.

Navigate to the credentials screen, and notice that we have a service account for this project. This one was created automatically. Now click on the email of the service account. We need to get the credentials we will use to call our DemoBot API from our app.
Scroll down to where the keys are listed. Hit ‘add key’, select ‘create new key’ and select JSON option. This will automatically download a json file to your local machine. Do not lose track of this! It will be our .service.json file.
Now we go to the NodeJS app, we have all we need here to make contact with our bot! First, we have to add .service.json in the root directory. Copy and paste the JSON file we downloaded from Dialogflow inside here.
Then, we add GOOGLE_APPLICATION_CREDENTIALS to the .env file and point it at the .service.json file we created above.

Google automatically knows to look at this file for the credentials when you are making the request. This is all baked in for you.

Then we use this file from https://github.com/googleapis/nodejs-dialogflow
I put it into a file I called chatbot-helper.js which I then exported and imported in my request handler. This file contains a function called 'runSample' which contains all the proper config to start communicating with your agent. We will have to edit a couple of things here.
The only thing you have to change here is your actual project id in the parameters of the function. I stored my project id in .env and imported it here. Later on, we will add a parameter called message and pass it in for the value of text.text in the queryInput object.

const dialogflow = require('@google-cloud/dialogflow');
const uuid = require('uuid');
require("dotenv").config();

const { PROJECT_ID } = process.env;
/**
 * Send a query to the dialogflow agent, and return the query result.
 * @param {string} projectId The project to be used
 */
async function runSample(projectId = PROJECT_ID) {
  // A unique identifier for the given session
  const sessionId = uuid.v4();

  // Create a new session
  const sessionClient = new dialogflow.SessionsClient();
  const sessionPath = sessionClient.projectAgentSessionPath(projectId, sessionId);

  // The text query request.
  const request = {
    session: sessionPath,
    queryInput: {
      text: {
        // The query to send to the dialogflow agent
        text: 'hello',
        // The language used by the client (en-US)
        languageCode: 'en-US',
      },
    },
  };

  // Send request and log result
  const responses = await sessionClient.detectIntent(request);

  const result = responses[0].queryResult;

  if (result.intent) {
    console.log(`  Intent: ${result.intent.displayName}`);
  } else {
    console.log(`  No intent matched.`);
  }
  return result;
}
module.exports = {
  runSample
}

make sure you run

npm install @google-cloud/dialogflow

The only changes I made here were to put PROJECT_ID in dotenv(your project Id is contained in the .service.json file), to return result so that I actually returned the results from the Agent, and to export the function for use in my route handlers. I left a couple of the console.logs in because they help to illustrate some of the elements we look for. The object which contains all of our useful information is set to the variable 'result'. Let's take a look at what we get when we send a request to our new agent!

queryText is what we sent, and fulfillmentText is what our agent responded with. We are all set up to start communicating with our chatbot.

The next thing is add the message param in runSample so that we actually send user input to our agent.

async function runSample(projectId = PROJECT_ID, message) {
  const sessionId = uuid.v4();
  const sessionClient = new dialogflow.SessionsClient();
  const sessionPath = sessionClient.projectAgentSessionPath(projectId, sessionId);

  const request = {
    session: sessionPath,
    queryInput: {
      text: {
        text: message,
        languageCode: 'en-US',
      },
    },
  };
  const responses = await sessionClient.detectIntent(request);

  const result = responses[0].queryResult;

  return responses[0].queryResult;
}

Now when we send a message via the text box, it is received in our request handler, the function runSample is called which hits the dialogflow agent's default welcome intent, and one of the default responses is relayed back to us.

chatbot.get('/', (req, res) => {

  runSample(PROJECT_ID, req.query.message)
  .then((data) => {
    res.send(data);

  })
  .catch((err) => console.log(err));
})

and here's the result!

Conclusion

In conclusion it is quite easy to set up a Dialogflow agent and just as simple to start using the agent for conversational purposes via NodeJS.

Passing Data Between Components in Vue.js

MaxwellBoecker — Mon, 07 Sep 2020 02:38:30 +0000

Introduction

Building applications with Vue.js requires the composition of nested components. In this article, we will see how to pass data between these components to arrive at the desired functionality of our application. We will talk about two ways of passing data: we can pass data from parent to child by passing props, or we can use the $emit method in order to make data in a child component available to its parent.
Passing props, despite always being passed from parent to child, can actually allow for events to be triggered in the parent. We will investigate one such case when passing a function to a child component results in this very phenomenon.
The $emit method will not only make data available to a parent component, it can actually trigger a series of events in the parent component. We will see more about this below.

Meet The App

Let’s meet the app. We’ll be looking at a main page which contains data about a user's garden. When the user wishes to edit this info, a modal will be rendered which contains a form. The form will handle the user input and through a series of transactions, the data will be passed back to the main page in order to re-render the newly input data.
This is what our info bar looks like on the main page:

Changing Hands

As props, we will be passing a function down from the main page as well as the original data to be edited. The function takes a single parameter. The updated data from the submit will be passed in as the argument for this parameter. Because the function is called in the local scope of the edit form, we have access to the updated values, and they can be passed in as the argument to the function. However, since the function comes from the upper scope, when we call it, the values on the main page will be updated because the function is bound to that scope.

The component that calls our main-page function needs a way to receive the updated data from the form. For this we will use the $emit method. When the form submit button is clicked, the component will emit data. When this data is emitted, a function is triggered in the parent component which has this data automatically passed in as an argument. This function then updates the database as well as the data displayed on the main page. Lets take a look.

first we pass the props from the main page
GardenMain.vue

<editmodal
        :id="gardenId"
        :name="name"
        :lat="location.lat"
        :lng="location.lng"
        :width="gardenSize.width"
        :height="gardenSize.height"
        :updateMain="updateMain"
      ></editmodal>

The function updateMain looks like this:

updateMain: function (garden) {
      const { id, lat, lng, width, length, name } = garden.data;
      this.gardenSize = { width, height: length };
      this.name = name;
      this.location = { lat, lng };
    },

These props are being passed to the component EditModal, so let’s take a look at that component next
Since the props were passed as independent properties, we must prepare to receive them as such. Here is a look at how we register props in the receiving component:
EditModal.vue

export default {
  name: "EditModal",
  props: {
    id: {
      type: Number,
    },
    name: {
      type: String,
    },
    lat: {
      type: Number,
    },
    lng: {
      type: Number,
    },
    width: {
      type: Number,
    },
    height: {
      type: Number,
    },
    updateMain: {
      type: Function,
    },
  },

Each prop that is expected must be registered here along with the type expected.

Summarily we will pass these along to the next component, which is rendered in the modal, named Editor. Editor will in turn render the form and on submit, will capture the emitted data. This in turn calls the updateMain function. Our transaction will then be complete. Let’s take a look at two crucial elements in Editor, the template, where the form EditGarden is rendered, and the methods object in the script, where the submitEdit function is located.
Editor.vue

<template>
  <div>
    <EditGarden
      v-on:edit:garden="submitEdit"
      :id="this.id"
      :name="this.name"
      :lat="this.lat"
      :lng="this.lng"
      :width="this.width"
      :height="this.height"
    />
  </div>
</template>


methods: {
    submitEdit(info) {
      axios.put("/garden/gardenupdate", {
          id: this.id,
          info: info,
        })
        .then((garden) => {
          this.$emit("close");
          this.updateMain(garden);
        });
    },
  },

The first thing to note is the line of code

v-on:edit:garden="submitEdit"

in the template. edit:garden is a reference to the function found in the child component, handleSubmit. let's take a look.
EditGarden.vue

methods: {
    handleSubmit() {
      this.$emit("edit:garden", {
        name: this.gardenName,
        lat: this.latt,
        lng: this.long,
        width: this.wid,
        length: this.hei,
      });
    },
  },

Notice how the first argument to handleSubmit is "edit:garden". This is what the function is known as in Editor.vue. It is like the export name. The this.$emit method will make the values in the options object, the second argument to handleSubmit, available in the parent component whenever the handleSubmit function is called.

Notice also how in the v-on in the Editor.vue file we call the function submitEdit whenever the EditGarden child component emits data. In this way, the components are reactive and a change in one component can trigger a series of changes in others. The submitEdit function first makes an axios call to update the database. Then, if that has been successful, it calls its own $emit which takes only one argument, 'close'. This closes the modal in the parent component. Finally, it calls the updateMain function which was passed in from the main page. This updates the data in GardenMain, immediately re-rendering it to the page.
Here is our EditGarden form inside the modal

Here is the updated GardenMain

So, in recap, our data flow is:

props passed from GardenMain to EditModal
props passed from EditModal to Editor
props passed from Editor to EditGarden
data emitted from EditGarden to Editor(the user input)
data emitted from Editor to close the EditModal modal
updateMain function call in Editor immediately updates the data in GardenMain

Conclusion

Here we have demonstrated passing data every which way between parent and child components. Props was used to pass data from parent to child. $emit was used to emit data from child to parent. And a function passed down from the parent was called in a child which updated data in the parent.

Vue.js Introduction: Components

MaxwellBoecker — Mon, 31 Aug 2020 01:01:02 +0000

Introduction to Vue.js

Vue.js is a lightweight MVVM framework created by Evan You and released in 2014. It is a ‘component based framework’. This definition refers to the structure of a Vue.js app wherein nested components pass data between each other to achieve the functionality of the application. In this introduction we will understand how to create and import basic components, how the 'template' section of a component works, and how to use the v-bind, v-for and v-on directives. In the next article, we will understand how the 'script' section of a component works, how the v-model directive works, how to use the ‘$emit’ method to render and pass data, and how to use the ‘mounted’ lifecycle. First up, the Vue component.

About The Example App

The app in the example is very simple and is comprised of just two Vue.js components, App.vue and PlantSearch.vue. The App.vue renders a PlantSearch component within its template, which captures user search input. On submit, the searchPlant function is called which sends a request to our express server, which which sends back an array of plant objects from the trefle.io API. These are in turn rendered in the App.vue template.

Components in Vue

By convention, Vue.js files and components are named according to PascalCase, with the initial letter of each word being capitalized. Single-file components are made up of three parts in Vue.js; the template, the script and the style. The example I will use is from our PlantSearch component in the PlantSearch.vue file. We will learn more about the functionality of the PlantSearch component below. For now, we just want to illustrate the component’s most basic essential features.

<template>
  <div class="search">
    <form @submit.prevent="handleSubmit">
      <label>Search A Plant</label>
      <input v-model="plant"/>
      <button>Submit Search</button>
    </form>
  </div>
</template>

<script>
  export default {
    name: 'plant-search',
    data () {
      return {
        plant: ''
      }
    },
    methods: {
      handleSubmit(){
        this.$emit('search:plant', this.plant);
      }
    }
  }
</script>
<style>
  .search {
    color: blue
  }

</style>

The template comes first and contains some HTML, in particular, a search form. When the component is rendered, this is what will be displayed. In between the script tags, we have our export statement which in this case contains the component’s export name, data (similar to state in React.js), and a handleSubmit method in the ‘methods’ object. Inside the script tags is where most of the JavaScript goes down. This will become apparent when we view the App component a little later on.
The final part of our single-page PlantSearch component is the style tag. This is where we put the CSS pertaining to our template elements. In this case, we have given a rather simple directive to make the text blue.

Attaching Components to the DOM

At least one of our single-file components must be attached to a root-instance of Vue.js. This root-instance is in turn attached to a DOM element in the index.html. In our example, the root-instance, declared in the index.js file

import Vue from 'vue'
import App from './app.vue'

new Vue({
  el: '#app',
  render: create => create(App),
})

attaches itself to the DOM element with id ‘app’ in the index.html. This is specified by with the value given to the key 'el' in the options object given to new Vue. This file imports and and the root instance renders our first component, called App, which in turn renders the aforementioned PlantSearch component. Let’s take a look at the App.vue file.

Given the App.vue file is fairly long, we will present it by section; ‘template’ followed by ‘script’ followed by ‘style’, for the sake of readability.

App.vue: Template

<template>
  <div class="divclass">
    <plant-search v-on:search:plant="searchPlant"/>
    <ul v-for="(p, index) in plants" v-bind:key="index">
      <div>
      <li>{{p.common_name}}</li>
          <div>
            {{p.scientific_name}}
          </div>
          <img v-bind:src="p.image_url"/>
      </div>
    </ul>
  </div>
</template>

Here we are introduced to our first directives, v-on, v-for, v-bind.

v-on

v-on is a directive that listens for DOM events and runs JavaScript when they happen. In this case, v-on is found in the plant-search component which we have imported and rendered in the App.vue template. When a search is submitted, the corresponding method searchPlant, found in the App.vue script section, is run. The exact way that the plant-search component passes the data to searchPlant has to do with the $emit method found in PlantSearch and will be discussed in the next article. The syntax,

v-on:search:plant="searchPlant"

is v-on followed by the exported handleSubmit function name from PlantSearch 'search:plant', followed by the function in App.vue, searchPlant, that we want to run when search is submitted.

v-for

v-for is roughly equivalent to a Vue.js version of a loop. When using v-for in a parent template element, the values can be passed to any of the child elements, as we see above. The syntax is

v-for="(p, index) in plants"

where 'p in plants' refers to each plant in our 'plants' array found below in the 'script' section. v-for can also provide an extra second parameter index, just like in the native map function. This helps us v-bind a unique key for each entry. With v-for, a unique plant entry is created and rendered to the DOM for every plant in the 'plants' array.

v-bind

v-bind binds a style or a class to whichever element it is called on. In the above template, we v-bind a unique key to each plant rendered

<script>
import axios from 'axios';
import PlantSearch from './components/PlantSearch.vue'

const API_URL = "http://localhost:8000/";

export default {
  name: "App",
  components: {
    PlantSearch,
  },
  data: function () {
    return {
      plants: []
    };
  },
  mounted() {
    axios.get(API_URL).then((plantInfo) => {
      this.plants = plantInfo.data;
    }).catch(err => console.log(err));
  },
  methods: {
    searchPlant(plant){
      axios.get("http://localhost:8000/search", {
        params: plant
      }).then((plantInfo) => {
        this.plants = plantInfo.data
      })
    }
  }
};
</script>

Conclusion

Next week, we will go in-depth on the specifics of the 'script' section of our App.vue. We will understand the 'data' function and how data is updated as well as how it is passed between the PlantSearch and App components. For now, we have gained a basic understanding of single-file components and a few essential directives.

Proxy Servers and Using Proxy Middleware in ReactJS

MaxwellBoecker — Mon, 24 Aug 2020 12:21:30 +0000

What is a proxy?

A proxy is a server which acts as an ‘intermediary’ between the client sending requests and the server which will be responding to them. They act on behalf of the client to request information from the server.

A Brief History

According to the Wikipedia entry on proxy servers, they were 'devised to add structure and encapsulation to distributed systems'. A distributed system is a system of 'components' which are located on separate computers and which communicate via the transmission of messages to one another. An example of a 'distributed system architecture' is the client-server system.

Encapsulation in networking refers to separation of concerns in the request-response process. In this case, a proxy helps separate the concern of communicating directly with a server from the client-side, abstracting away the complexity of that task into its own module.

Why Use Proxies?

Proxies have many uses and are integral to network communication. One of the uses of proxies is as additional processing middleware to modify requests and responses. Many times this can help simplify the request being sent because the proxy will deal with sending information to the server that would normally have to be sent in the client's request.
Frequently, they are used to avoid blockages by the CORS policy. A request that otherwise might be rejected based on cross-origin policy may be accepted via a proxy.
Another practical use is in the development process when the client-side files and the server-side files might be served on different ports, and need a proxy in order to communicate. In this case, the proxy will route the request from the client-side to the appropriate back-end URL in order to hit the server. In particular, this configuration is frequently found in applications using create-react-app. Let’s take a look at exactly where they would be found in a react application using an express server.

A React App Proxy

In create-react-app, the client-side files are contained in the ‘src’ folder.
They make requests to the react-app dev server running at the default PORT 3000, or another PORT if specified. However, our files containing request handlers are being served at a different port, in this case 8080. In the bottom of the src folder, just underneath components, we can see the setupProxy folder. When serving the client-side files, the front-end server running on PORT 3000 will need a proxy in order to actually communicate with the express server we have running on 8080. Let’s take a look at the setupProxy file.

First we require dotenv, and set the SERVER_PORT from process.env. This is the port that the express server is listening on and the port we want our proxy to redirect to.

require('dotenv').config();

const { SERVER_PORT } = process.env || 8000;

Then we require 'http-proxy-middleware' and import the middleware function createProxyMiddleware.


const { createProxyMiddleware } = require('http-proxy-middleware');

Now we use it to proxy all requests from the server serving the react files to our SERVER_PORT, which is our express server running on 8080 which will handle the requests. The function takes a route as its first argument which corresponds to a specific route in the express back-end server. It takes an object as the second argument which here contains the target url where the server is listening.

module.exports = (app) => {
  app.use(createProxyMiddleware('/auth', {
    target: `http://localhost:${SERVER_PORT}`,
    })
  );

  app.use(createProxyMiddleware('/notify', {
    target: `http://localhost:${SERVER_PORT}`,
  }));

  app.use(createProxyMiddleware('/route', {
    target: `http://localhost:${SERVER_PORT}`,
  }));

  app.use(createProxyMiddleware('/park', {
    target: `http://localhost:${SERVER_PORT}`,
  }));
};

Now we have successfully created proxies that will route us to the express server, listening on SERVER_PORT which is handling the routes '/auth', '/notify', '/route', and '/park'. Notice that although we define these middleware instances in a module.exports statement, they do not need to be imported anywhere. As long as they are in the 'src' folder they will be found.

Conclusion

Proxies are a practical technology which help us add encapsulation and modularity to the complex process of network communication.

Promises in Javascript

MaxwellBoecker — Mon, 27 Jul 2020 13:13:02 +0000

Overview

In Javascript, the Promise is ‘an object’ which, according to MDN, is ‘a proxy for a value not necessarily known when the promise is created’. It is an improvement on using callbacks and helps us to avoid the ‘Pyramid of Doom’ while building asynchronous operations. There are several essential features of Promises which will help us to understand exactly how they behave. Of these we will investigate their constructor and prototype methods.

Using the Promise Constructor

In creating a new promise with the promise constructor, we pass it a function with two parameters, ‘resolve’ and ‘reject’. These ‘static methods’ are called on the result of the asynchronous operation being performed in the function which is returning a promise or in the promise body itself. We use ‘resolve’ to return the value out of the Promise when the operation has been successful. We use ‘reject’ to return an error out of the Promise when the asynchronous operation has been unsuccessful. Let’s take a look at building a promise with the promise constructor.

const getStatusCode = (url) => {
  return new Promise((resolve, reject) => {
    request(url, (err, res) => {
      if (err) {
        reject(err);
      } else {

        console.log(res.statusCode);
        resolve(res.statusCode);
      }
    });
  });
};

Here we have a function called getStatusCode which takes in a url and returns a promise. Inside of the promise, we use the NodeJS function 'request' to make a request to the url given as an argument to getStatusCode. Request takes a callback in the normal style and when it returns with its result, we will resolve or reject the promise passing in the result as an argument.

Notice how resolve essentially corresponds to the part of the callback that deals with 'data' while reject corresponds to the part that deals with 'error'. However, using promises 'in the wild' looks a little bit different than what we've seen with the constructor and utilizes the prototype methods of the promise object.

Promises in Action

To investigate the prototype methods of the Promise we will need to see it in action. In the below example we will grab the result of the promise, either resolved or rejected, inside of our function via the ‘then’ block(resolved) or ‘catch’ block(rejected). The ‘then’ and ‘catch’ are prototype methods of the promise which allow us to use the values returned out of the promise inside of other asynchronous functions. The then-block will return a function which is supplied with the return value of the previous promise, kind of like the argument for ‘data’ in a callback. The catch-block will return a function which is supplied with the value of the error, kind of like ‘err’ in a callback.

Corresponding to our example above, we will chain on 'then' and 'catch' blocks to capture the values returned by resolve and reject.

getStatusCode('www.google.com')
.then((status) => console.log(status))
.catch(err => console.log(err));

This syntax makes it possible to chain multiple promises together, making for cleaner code than the 'Pyramid of Doom', which refers to the phenomenon of callback hell

instead we use promises. Imagine that 'useStatusCode' is another asynchronous function we have written

getStatusCode('www.google.com')
.then((status) => useStatusCode(status))
.then((data) => console.log(data))
.catch(err => console.log(err));

This keeps our code neat in the event of needing to chain multiple asynchronous functions together.

Conclusion

Promises are a great way to simplify our code. When we create them with the constructor, we use the resolve and reject parameters to signify what we want the promise to do at time of invocation. When we invoke promises or functions that return promises, we work with the return values of the promise (specified as resolve and reject in the constructor) inside the 'then' and 'catch' blocks.

Introduction to RDBMS with SQL and Examples in SQLite3

MaxwellBoecker — Mon, 20 Jul 2020 04:30:00 +0000

SQL

SQL, short for ‘Structured Query Language’ is a language used to manage data in a RDBMS, short for ‘Relational Database Management System’. The data in a relational database is ‘structured’, meaning that significant interrelations exist by means of references between ‘entities’ and ‘variables’. Originally developed at IBM in the early 1970s, SQL remains a ubiquitous database querying and manipulation language today. One of its primary advantages consists in that it boasts a ‘human-readable syntax’ via which introduction to and initial grasp of working components and syntax is facilitated rather effectively, as I found out upon meeting SQLLite3 for the first time not so long ago.

SQLite

SQLite differs from SQL in that it is not a ‘client-server database engine’. It is a RDBMS intended to work on the database of a file system of an application. Another key difference is that SQLite is ‘weakly-typed’ meaning that type conversion might automatically occur while the code is being interpreted. For example if we give a string in the place of an integer, SQLite will try to perform a data-type conversion. This is comparable to the way the javascript interpreter will try to convert types before evaluating an expression. For example console.log(‘1’ + 1) will result in ‘11’ being printed to the console. Javascript converts the number type to a string and evaluates the + as string concatenation.

Relationships in our data

One of the basic relationships we will describe in our code example is the ‘many-to-one’ or ‘one-to-many’ relationship. In our example, we will see two tables, one of pets and one of guardians. When planning out how we want to structure our data, it is important that we consider how to accurately reflect the real nature of the relations between data. In this data, each pet has only one guardian, while each guardian can have multiple pets.
Imagine we want to reference all the pets that a given guardian is caring for. One way to do this would be to add a pets column on the guardian table. However, this column would have many different pets and perhaps would be messy to maintain. However, we could add a GuardianId on the pets table signifying which of the guardians is the given guardian of the pet. This way, we create a new column with only one entry per row, which makes querying rapid and efficient.
Generally in a one-to-many scenario, it is more logical to make reference to the one from an identifier in the many table, in this case, make reference to the guardian from the pet table. Lets take a look at a representation of our data below.

pets

Name	Species	GuardianId
Barry	Zebra	1
Larry	Bear	2
Gary	Tiger	1
Leonard	Dog	3
Randy	Cat	3
Anastasia	Horse	2

guardians

Name	Id
Lisa	1
Bob	2
Frederick	3

Looks like We've got some nice data to work with. Time to explore some basic commands with SQLite3!

Commanding

Viewing a table with SELECT

When used with * SELECT allows us to view all the columns in a table

sqlite> SELECT * FROM pets;

will display

name	species	guardianid
Barry	Zebra	1
Larry	Bear	2
Gary	Tiger	1
Leonard	Dog	3
Randy	Cat	3
Anastasia	Horse	2

However it is possible to select only one column with the following command

sqlite> SELECT name FROM pets;

will produce

name
Barry
Larry
Gary
Leonard
Randy
Anastasia

Imagine, however, that we want to select the name and species columns from the pet table for all pets whose names end in 'y'?
Here we will use the wildcard % operator to accomplish our task.

sqlite> SELECT name, species FROM pets
   ...> WHERE name LIKE '%y';

This gives us:

name	species
Barry	Zebra
Larry	Bear
Gary	Tiger
Randy	Cat

For our last example, let's imagine we want to find out who the guardian of our tiger pet Gary is. Here we use a technique called sub-querying to select the field guardianid on pet, which is a foreign key that refers to id of a guardian in the guardian table. However, we only want the guardianid of the pet who has a species field value of 'tiger'. Thus the sub-query

sqlite> SELECT name FROM guardians
   ...> WHERE id IN (SELECT guardianid FROM pets
   ...> WHERE species = 'tiger');

Here we come up with

Name
Lisa

Conclusion

SQL and sqlite are powerful languages that allow us to interact with and manipulate data in a myriad of ways. Identifying the different relationships between data, such as one-to-many or many-to-one can help us structure our data appropriately with future queries in mind. In the end, it is up to us to properly structure the data and understand which relationships are most effective in designing a certain schema.

Introduction to HTTP Requests with AJAX

MaxwellBoecker — Mon, 06 Jul 2020 02:14:33 +0000

What is HTTP?

HTTP is short for Hypertext Transfer Protocol. According to Wikipedia it is defined as, “… a request–response protocol in the client–server computing model”. In other words, it is the process by which messages are sent on behalf of a client using a web browser or application. These messages either get data from a server or send data to a server.

HTTP Methods:

There are many methods for communicating with a server. The GET method allows us to get requested data from a server. The POST method requests that the server accept the data we are sending and add it as specified by the URI. PUT and DELETE methods are used for altering data on the server.

These methods are the basic building blocks of communication integral to running web-based applications.

What is Asynchronous Programming?

Asynchronous programming practices allow us to send and receive HTTP requests while still allowing the user to interact with the application. Contrast this with a synchronous approach.

In a synchronous approach to programming, all processes in the program run one at a time. This means no other process can start until the current one is finished. It might not seem like a big deal until we consider just how many processes might be running in any given application. This can introduce obvious problems in the context of running a web application.

Take the example of a bakery. We have an oven that can bake many loaves of bread at once, but we have hired a ‘synchronous’ baker, who completes each loaf before starting the next one. He mixes the flour, kneads the bread, waits for it to rise, then puts it in the oven and waits for it to finish baking. How many loaves will he finish in a day? However, imagine a scenario where he could make and knead the dough and while it rises, start another batch. Then while the oven is baking his bread, he is preparing to bake another batch. This seems much more efficient.

Introducing AJAX

One efficient way for communicating HTTP requests to a server is the AJAX technique. AJAX stands for ‘Asynchronous Javascript and XML’. It allows us to update certain information on the browser without having to refresh the entire page. The great benefit of AJAX is that it can perform asynchronously. This way our client can still interact with the browser while the process of updating the data is being executed in the background.
Lets take a look at how the AJAX technique is executed. Here is an example of an AJAX POST request:

$.ajax({
      url: this.server,
      type: 'POST',
      data: JSON.stringify(message),
      contentType: 'application/json',
      success: (data) => {
        console.log(data);
      },
      error: (data) => {
        console.log('POST failed');
      },
    });

Above we have a jQuery call to AJAX. The specified url is the server to which the request will be sent. The type property tells the server which type of HTTP method we are requesting the server to complete. The data property contains the data we want to send to the server. The contentType property lets the server know what type the data is. The success and error properties contain functions to be called depending on whether or not our POST request was successful. Below is an example of a GET request.

$.ajax({
      url: this.server,
      type: 'GET',
      data: {order: '-createdAt'},
      contentType: 'application/json',
      success: (data) => {
        console.log(data);
      },
      error: (data) => {
        console.error('GET failed');
      }
    });

Conclusion

AJAX is a popular and powerful way to perform HTTP requests asynchronously. Since this increases the power and efficiency of our applications, it is a highly important technique to be competent in.

Using Linear Time Complexity and Binary Search to Understand Logarithmic Time Complexity

MaxwellBoecker — Sun, 28 Jun 2020 18:58:14 +0000

Intro and Brief Overview of Big-O

Intro

Sooner or later we must come to wrestle with the beast that is Big -O Time Complexity. Wikipedia has a good definition of Time Complexity:
'Time complexity is commonly estimated by counting the number of
elementary operations performed by the algorithm’
Here we will be talking about linear Big-O (O(n)) as a path to understanding the more elusive nature of logarithmic Big-O (O(log n)).

A Brief Overview

Big-O Time Complexity evaluates the number of operations required for an algorithm to produce its result in the 'worst-case'. In order to see how Big-O works in practice, let's first analyze the Big-O for running a recursive indexOf function on a sorted array.

Linear: O(n)

Here is a fairly straightforward recursive implementation of an indexOf function using 'es6 recursion patterns with default and rest params'. The implementation is my own, but it is modeled off the syntactic patterns found in the implementations of various other functions as per this excellent article.

const indexOf = ([x, ...xs], target, index = 0) => x !== undefined 
  ? x === target ? index : indexOf(xs, target, ++index) 
: -1;

const newArray = [1, 2, 3, 4, 5];

console.log(indexOf(newArray, 5))//returns 4, as 5 is found at the fourth index of newArray

The time complexity of performing this operation is linear O(n) due to the fact that, in the worst case, for every element ‘x’ in the array numbers, we would have to perform an operation: comparing it to the target value, 5. No matter how big or small the numbers array gets, in order to find whether or not the target value exists inside, in the worst case (our element exists at the final index or not at all), we have to perform exactly one operation for each element in the array. Thus the growth of the Big-O is directly proportional to the growth of the data set: One more element, one more operation.

Here is a graphic representation:
Note the yellow linear curve

The number on the n-axis(commonly the x-axis) represents the amount of items in our JavaScript array 'newArray' from above. The number on the f(n)-axis(commonly the y-axis) represents the number of operations required, in the worst-case, for the algorithm to produce a result.
It helps me to imagine when we run a function, say indexOf from above, that we're starting at the point on the yellow line where
n = the number of items in the array and moving left along that line as the function runs until we hit n = 0 and no more items are left to be processed. A steeper curve(or line) means more operations(f(n) axis) required to complete our algorithm. This process will help us to envision logarithmic complexity.

Logarithmic time complexity:

What is a logarithm? A logarithm has two components, “a base ‘b’ and a given number ‘x’” A logarithm finds out how many times the base b would have to multiply itself to become the ‘given number x’
‘For example, log2 64 = 6, as 2^6 = 64’ from Wikipedia on Logarithms

It might help to rearrange this equation a bit though for our purposes, because division is really what we are doing when logarithmically traverse a data set. Say we are using a 'divide-and-conquer' algorithm, such as Binary Search(described below) to search our sorted array of size 'x'. We start with x = 64 and divide it by the base 2 until we get 1, which should be the result. How many operations does this take??
64/2 = 32/2 = 16/2 = 8/2 = 4/2 = 2/2 = 1
-> 6 operations

Basically we are asking, in the case of a Binary Search, “how many times will I have to divide my data set of size ‘x’ values by 2 to isolate one value? i.e. to find (or not find) the target”

What is Binary Search?

The Binary Search Algorithm operates on a sorted array to find a target value in logarithmic time complexity. Given a sorted array Binary Search finds the middle index of the array and compares the value found at that index to the target value. If the target value is less than the value found in the middle index, we know we only need to search the ‘lower-half’ of numbers in the array. It cannot be located in the 'upper-half' because those numbers are all higher than the value at the middle index.

In the implementation and example below, at first iteration, min will be set to the first index in the array and max will be set to the last index. Binary Search will 'discard' either the ‘upper half’ or the 'lower-half' of numbers in the given array by resetting either the min value or the max value based on the middle value's comparison with the target value. On the next iteration it will only search between the newly updated min and max indexes. The 'discarded' half will never be searched, thus eliminating half of the size of the array and half of the potential operations immediately.

Below we implement binarySearch and use it to find the index of 47 in the nums array

let nums = [2,3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61,67,71,73,79,83,89,97]

const binarySearch = function(array, target, min, max) {
  min = min || 0;
  max = max || array.length -1;
  let index = Math.floor((min+max) / 2);
  if (array[index] === target) {
    return index;
  } else if (min > max) {
    return null;
  } else if (target > array[index]) {
    min = index + 1;
    return binarySearch(array, target, min, max);
  } else if (target < array[index]) {
    max = index - 1;
    return binarySearch(array, target, min, max)
  }
};

console.log(binarySearch(nums, 47))//logs 14 because 47 has been found at the 14th index

Bringing it All Together

As the given input size increases, an algorithm which processes data in logarithmic time will arrive at its result using substantially fewer operations than one which operates in linear time. Let’s imagine a sorted JavaScript array of 128 items. Using indexOf, we have to perform potentially 128 operations in order to find the target. Using Binary search we have to perform just seven operations:
128/2 = 64/2 = 32/2 = 16/2 = 8/2 = 4/2 = 2/2 = 1
If we double the data size we will have to perform potentially double the operations with indexOf, while we only have to perform one more with Binary Search.

Let's take another look at the graph from above:

We see that in the long run, yellow linear curve diverges more and more from the light-blue logarithmic curve.

Conclusion

Hopefully this article helps to elucidate just how efficient an algorithm operating in logarithmic time complexity can be when working with large data sets.