Forem: Michael Bazile

Going from JavaScript to Java.

Michael Bazile — Mon, 01 Jun 2020 13:40:41 +0000

Welcome! How are you doing on this beautiful day? Or maybe it's night time, I'm not entirely sure, either way I hope you're doing well. As you can tell by the name of this blog title, I will be trying to give a little insight into the basics of Java. Let's not waste any more time and get straight into it.

Let's start with a little history. Java is a programming language that was first developed by James Gosling in 1995.Java is an object oriented class programming language that is typically used for server side development. Unlike JavaScript, Java organizes software design around data and objects rather than functions and logic.Java is an extremely popular language in the software industry. A few fun facts to show how popular it Java is, there are upwards of 9 million Java developers worldwide, around three billion phones that run Java, around 130 millions TV sets, and every single blue-ray player. With that being the case, there are many different reasons why you should use Java.

For one, Java is platform independent. Meaning once a Java program is compiled you can execute the program on any platform or operating system. This lends to the flexibility in how many different devices you can program with Java. Another reason you should use Java is that you can benefit from the object oriented programming style that the language offers. You can benefit a lot from using the object oriented style of coding from reuse-ability, error handling, organization, and maintenance. To give a little more context, let's take a look at some key differences between Java and JavaScript.

One difference between Java and JavaScript is that Java is a statically typed language, while JavaScript is a dynamically typed language. Meaning declaring variables in Java is much more strict than in JavaScript. You have to explicitly declare what type of variable you are creating in Java, however that is not necessary in JavaScript. This may seem like a hassle at first, but it can reduce the time you may take finding bugs because of it.

In order to do anything in Java, you must use utilize classes. Classes are reusable blocks of code that produce objects for real world examples such as a user signing up on your website. While in recent years JavaScript has updated to include classed, in no way is it required or necessary to run a program. It takes a lot more boiler plate code to run Java programs vs JavaScript programs. Again, this may seem like a hassle, however the fact that Java is so structured can greatly help find and identify bugs.

Java applications and programs are run in a JVM, which is known as a Java Virtual machine. While JavaScript is mainly run in web browsers, but can be run in server side development with a runtime environment such as Node.js. This lends to the fact that Java is platform independent and it's so flexible. Much more flexible than JavaScript in my opinion.

Now that we have some context on a few differences between Java and JavaScript let's look at some code.


public class Main {
    public static void main(String[] args) {
        // declare variable to store age
        int age = 30;

        // declare variable to store name
        String name = ("Michael");

        // declare variable to store if tacos are great
        boolean tacosAreGreat = true;

        // log in terminal
        System.out.println(age);
        System.out.println(name);
        System.out.println(tacosAreGreat);

    }
}

In the code example above is a basic Java program that will log the value of each variable to the console. Notice how the public class Main is the first thing being created in this program. Like mentioned before, in order to do anything in Java you must utilize classes, you will get an error if otherwise. Another thing to take note of is how before every variable is the type of variable that will be created. This goes back to the fact that Java is a statically typed language. Finally, notice how we actually print information in the terminal in Java via the System.out.println. This is how Java programs are able to print information to the terminal. Let's now do the same thing, but in JavaScript.

// declare variable to store age
const age = 30;
// declare variable to store name
const name = 'Michael';
// declare variable to store if tacos are great
const tacosAreGreat = true;



//log in terminal using a function
 const log = (() => {
     console.log(age);
     console.log(name);
     console.log(tacosAreGreat);
 })();


// log in terminal using a class constructor function
 class Log {
   constructor(){
     this.age = 30;
     this.name = 'Michael';
     this.tacosAreGreat = true;
  };

 logValues(){
     console.log(this.age);
     console.log(this.name);
     console.log(this.tacosAreGreat);
     };
 };

 const log = new Log;
 // call .log method
 log.logValues();

// log in terminal using a console.log
console.log(age, name, tacosAreGreat);

In the code example above is a basic JavaScript program that will log the value of each variable to the console. Unlike Java, JavaScript does not constrict you to any one way to set up a program. Another thing to take note of is how before every variable there isn't the type of variable that will be created unlike Java. This goes back to the fact that JavaScript is a dynamically typed language and does not have too many rules. Finally, the many different ways we can log information to the terminal in JavaScript. The code example above uses an immediately invoked function, a JavaScript class method, and just a console.log that all will do the same thing. The thing to take away from this is, unlike Java where you must set up your program in a specific way, JavaScript allows for much more freedom in how you wish to preform different tasks.

In conclusion, even though Java needs a lot of boilerplate to start, it can save time debugging and adding onto code in the long run. The fact that Java is platform independent makes for a plethora of different use cases while learning the language. Also it can be very wise to learn and add to your tool belt along with JavaScript early on to help deepen your understanding of programming and add more value to you as a developer. Until next time!

I can tell you're yearning, to learn about machine learning.

Michael Bazile — Sun, 24 May 2020 21:41:43 +0000

Greetings! How's it going? I hope you and your family are doing well and staying safe during these difficult times. I'm going to assume since you took time out of your day to click on this link, that means you are interested in machine learning. Let's not waste any more time and get straight into it shall we?

First things first. What the heck is machine learning? Machine learning is a subset of artificial intelligence that aims to enable computers to learn from data, and even improve without being explicitly programmed. Arthur Samuel, the inventor of machine learning, coined the phrase machine learning in 1952. That same year, Arthur would go on to develop the very first machine learning program. The program was designed to play checkers, and the program would look for ways to get better by correcting its mistakes each time it played. Crazy, I know. How is this possible? Let's take a look at this quiz below to see how.

Fill in the blanks

I just gave you a quiz out of the blue and you still managed to correctly guess 12 and 20. This is exactly the kind of behavior that developers are trying to achieve when making machine learning algorithms. To give computers the ability to predict an unknown outcome by picking up on patterns each time a program is run.

Machine learning is present everywhere in our day to day lives. Every time we ask Siri or Alexa a question, to face recognition to open our phones, to getting product recommendations based off of something we recently purchased online, machine learning is is the diving force behind all of that and more. There are three different strategies for creating machine learning algorithms:

In general, supervised machine learning works by feeding the computer a labeled input and labeled output, so that the computer can make a connection between the two sets of data. You repeat this process many times, eventually, the algorithm picks up a pattern between the inputs and outputs. Now, you can feed it a brand new input, and it will predict the output for you.

In general, unsupervised machine learning works by feeding the computer an example input without labeling the expected output. You repeat this process many times, eventually, the computer will combine your inputs into groups that are related. Now, you can feed it a brand new input, and the computer will predict which cluster it belongs with so it can then predict the output for you.

In general, reinforced machine learning works very similar to supervised machine learning where you feed a computer a labeled input. The difference is instead of explicitly feeding the computer a labeled outcome to check for, you set up a system to either reward or penalize the computer based off a given output. The more you repeat this process the better the computer will become better at choosing the right output based off of prior rewards and penalizes.

Machine learning is one of the fastest growing areas in computer science, and does not seem to be slowing down. Almost any programming language can be used to write machine learning applications, however having to write every single algorithm from scratch can be extremely time-consuming. Popular languages such as Python, C++, Java and JavaScript have pre-built libraries to assist you in creating your first machine learning program. I hope after reading this blog, you will venture out and dive even deeper into discovering what machine learning is all about. I know I will! Until next time!

I can do you a favor, and teach you about generators.

Michael Bazile — Sat, 16 May 2020 06:44:09 +0000

Welcome one, welcome all! How is it going? I hope that you're in good health and doing well. If you decided to click on this link, that must mean that you are interested in learning about generators. If that's the case, let's not waste anymore time and get straight to it shall we?

So first things first, what exactly is a generator? A generator is a special type of function in JavaScript that has the ability to stop midway through execution, and then continue from where it stopped. For example, imagine reading one of your favorite novels, and inserting a bookmark at your stopping point, and being able to resume where you left off. The next day you pick up your book and turn to the bookmark you left and start reading exactly where you left off at. That is essentially what generators are in a nutshell.

ECMAScript 2015, or more popularly known, ES6, first introduced generators into JavaScript. Generators can be very closely compared to iterators. Iterators is a programming practice that programmers use to loop over a data structure and manipulate each value in some way.

Iterators makes use of the Symbol.iterator method. A symbol is a primitive data type that was also introduced by ES6. The Symbol.iterator method returns an object that has a next property and a done property. The next property is a method that provides a way to get to the next value in the iteration; the done property is used to check if the iteration is complete by checking if the done property is either true or false.

Generator functions behave very similarly to Iterators in the fact that a generator function will return an object with a next property and a done property just like iterators. The difference is the fact that generators, like mentioned before, have the ability to stop mid way through execution. Let's go check out how that's possible. Take the following code example below.

function *generator() {
 yield 'I can';
 yield 'Stop this function';
 yield 'also start';
 yield 'this function';
 yield 'whenever i want';
}

const gen = generator();
console.log(gen.next().value) // will log 'I can'
console.log(gen.next().value) // will log 'Stop this function'
console.log(gen.next().value) // will log 'also start'
console.log(gen.next().value) // will log 'this function'
console.log(gen.next().value) // will log 'whenever i want'
console.log(gen.next().value) // will log 'undefined'
console.log(gen.next().done) // will log true

First thing to note, is the asterisk being used when defining the function generator. This is the first indicator that a generator function is being defined. Second thing to note, is the use of the keyword yield. Yield is the reason why generators are able to stop a function's execution mid way through execution. It's similar to the return keyword, however yield remembers its place during execution so when the next method is called, it can pick up exactly where it left off. Unlike return, that just stops execution altogether. We can assign the generator function to a variable, and call said function when needed. You know the generator function is completed when the value of next.().value is undefined. You can also confirm if a generator function has completed by checking if the value of next().done is true.

Utilizing generators in your code has many practical use cases, such as, testing your code, handling asynchronous operations, and making your code more efficient. (By having the ability to stop a function midway through execution.)

That wasn't too bad right? Now you know what generator functions are, and how you can use them in your code. Hopefully, you can apply what you learned today the next time you code. Let me know if I fulfilled that favor, of teaching you guys about generators. Until next time!

Don't let your app combust, just use Redux.

Michael Bazile — Sat, 09 May 2020 22:09:07 +0000

Good afternoon! Or maybe it's good morning? Yeah I'm not entirely sure what time you're reading this, nevertheless, I hope you are doing well and being safe. If you did decide to click this link, I'm assuming that you are looking to get a better understanding of what Redux is all about. Well, my friend, you have come to the right spot. After reading this blog I hope you leave will at the very least a baseline understanding as to what Redux is all about. Let's not waste any more time and jump right into it shall we?

So, first things first, what the heck is a Redux? Great question. Redux is an open-source JavaScript library for managing application state. One great thing about Redux is the fact that is framework agnostic. That simply means that it does not matter what front-end frame work you choose to work with, Redux does not discriminate and will work with a plethora of different ones. Frameworks like React, Angular, Vue, Backbone, and Ember just to name a few.

Coming straight from Redux's documentation, Redux is a predictable state container for JavaScript apps. It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. The whole purpose of Redux is to take the onus off of each component in an application to internally manage their state own state and in return have state shared by all components from one centralized location. Having each component manage state isn't necessarily a bad thing at all, it can just get difficult the bigger your application grows to keep track and manage application state in each individual component. In comes Redux.

The logic behind how Redux works can be broken up into three main concepts which are the store, actions, and reducers. First up let's talk about the store.

When referring to the store, you can think of it as a single immutable JavaScript object that includes the state of the entire application. There should only ever be a single store in an application, and that one store will be the place every component goes to to either update the current state or simply get data from the current state. One important thing to note is that the store object is never mutated directly. Instead in order to update the current state you use a function called a reducer that takes in the current state and an action as parameters. Which leads us to our next core concept, which are actions.

Actions are the only way to change the current state by informing the store that an event just took place (A user clicked a button, a form was submitted, an HTTP request has resolved). An action is simply an object that has two properties, type and payload. The type property indicates how the state should change and it's always required by Redux. The payload property instead describes what should change, and might be omitted if you don't have new data to save in the store. Great! We now know the store is where the state of the application is stored, and actions are how we alert the store to update and modify that state, the last step is to respond to that action using a reducer.

Reducers specify how the application's state changes in response to actions sent to the store. Remember that actions only describe what happened, they do not describe how the application state changes. You can think of reducers as being a type of event handler, where actions are the actual event.

Reducers are just functions that take in two parameters, which are the current state and an action. Reducers are extremely important because if you remember from earlier, the store object is immutable and cannot be modified directly. Reducers remedy this by simply being a pure function. Pure functions are functions that always return the same result if the same arguments are passed in and do not cause side effects. It does not depend on any state, or data, change during a program’s execution. It must only depend on its input arguments. This is perfect when using reducers because we can update the state of our application based on an action without having to directly mutate the store object directly. We can make a copy of the current state, mutate the copy, then return that object to represent the new current state of our application.

So to conclude, I hope after reading this blog you got a better understanding of what Redux is and why it can be useful in your next project. It may not always be as useful in smaller projects, however if you ever get involved in a bigger project, Redux may be the saving grace. Also many jobs require that you know Redux in order to be considered to be hired. For whatever reason you may have, if you do not want your app to combust I would suggest using Redux. Until next time!

No need to stress when it comes to SSL and TLS.

Michael Bazile — Sun, 03 May 2020 19:49:29 +0000

Hi there, how are you doing today? I hope that that cool title got you to click on this link to read my blog. Well I'm glad you did, and hopefully, by the time you finish reading this you'll leave by learning something new. Let's not waste any more time and jump right into shall we?

Let's start from the top and just break down what the heck SSL and TLS even stand for. SSL stands for Secure Socket Layers, while TLS stands for Transport Layer Security. SSL and TLS are both cryptographic protocols that provide authentication and data encryption between servers, applications, and users. A cryptographic protocol is simply a set of rules or instructions that are designed to allow for secure communication through an unsecured network.

Note: If you see this lock in your web browser then you know that the connection is secure.

Now that we have a basic understanding of what SSL and TLS are and what they are used for let's dig a little deeper into how each of them relates to each other. First up is SSL.

Secure Socket Layer (SSL), was originally developed by Netscape Communications in 1994 which was twenty-six years ago. SSL was created as a solution for the increasing concern around cyber and internet security. Up until 1999 when Transport Layer Security (TLS) was developed, SSL had been the industry standard to ensure sensitive data was protected from hackers and unwanted third parties. Here is how a typical SSL connection works:

1.) When a browser visits a website and communicates with a server, provided the site has an SSL certificate, the client and server begin what is known as the SSL handshake.

2.) The first step of the SSL handshake involves the browser checking if the SSL certificate is legit or not, to ensure the connection is trustworthy before continuing.

3.) Every SSL certificate has two keys, a public key and a private key. Together the job of both public and private keys are to handle the encryption and decryption of data to communicate securely during the SSL handshake so third parties won't be able to just eavesdrop on senstive data.

4.) After the client confirms the SSL certificate is valid using the public and private keys, the client and the server create what’s known as a session key, this is a third key. The session key is used for the remainder of the secure connection.

Like stated previously, SSL had been the industry standard up until 1999 when TLS was proposed by the Internet Engineering Task Force (IETF). The Internet Engineering Task Force is just an open standards organization, which develops and promotes Internet standards. TLS evolved directly from its predecessor SSL. Actually the first TLS version 1.0 actually began development as the last version of SSL which was SSL version 3.1, however the name of the protocol was changed before publication in order to indicate that it was no longer associated with Netscape. Because of this history, the terms TLS and SSL are sometimes used interchangeably.

The latest version of TLS, TLS version 1.3, was released in March of 2018 and came with a bunch of new features and improvements to previous versions. When talking about TLS, its always important to keep in mind that it was bulit upon its predecessor SSL so they both have many similarites. Some of the improvements include faster performance, less latency, and of course enhanced security.

With the internet evolving and expanding so quickly, along with the amount of people and information that is on the internet right now it is nice to have reassurance that your information is being protected. With that in mind, always look for that padlock next time you are passing sensitve information over the internet and let SSL and TLS relieve your stress. Hope you enjoyed this read, have a good one!

Can't be dishonest when you make a Promise.

Michael Bazile — Tue, 31 Mar 2020 03:29:42 +0000

Welcome. How are you doing? I hope you're doing great. If you're not, after reading this blog I can promise that you will. Just hold onto that promise until then.

To get things started, let's have a quick recap about JavaScript, in particular how JavaScript is interpreted. When coding in JavaScript, it's important to note that when a program is run, it is run synchronously. This is because JavaScript is a single-threaded language and will only execute code one statement at a time. This becomes an issue when you need to have multiple things happening at the same time. Be it either sending HTTP requests to a server, dealing with event handlers or any other asynchronous task that will take an undetermined amount of time to complete. If a user comes to your application and has to constantly wait to interact with different parts of the page, you can guarantee that the user is going to leave your page and never come back.

In comes asynchronous JavaScript. This concept allows for your program to run, and when an asynchronous action occurs, your program will still run without being blocked. When the action is finished, the program will be notified and then gain access to the results of that action. Prior to Promises, developers would use callbacks to handle asynchronous tasks in JavaScript. Take this code snippet for example. In which order do you think the following will be run?

function greeting(){
console.log('Hey! How are you?');
console.log('Nice to see you');
}

console.log('Hi, there');

greeting();

console.log('Okay, have to go now!')

This will be the order in which the code will be run:

'Hi, there'
'Hey! How are you?'
'Nice to see you'
'Okay, have to go now!'

Notice how once we hit the function call of greeting, the interpreter had to block the thread to execute everything inside of that function. If it were the case that a web page was filled with synchronous code like that, it will make the user experience terrible. It will also make your web page or application very inefficient. Enter asynchronous callbacks. Let's take the same example from above and make it asynchronous. Let's look at the code snippet below, and can you guess the order in which the following will be executed?

function greeting(){
console.log('Hey! How are you?');
console.log('Nice to see you');
}

console.log('Hi, there');

setTimeout(() => { 
greeting()
}, 0); 

console.log('Okay, have to go now!')

This will be the order in which the code will be run:

'Hi, there'
'Okay, have to go now!'
'Hey! How are you?'
'Nice to see you'

Notice how this time the interpreter did not have to wait to execute greeting function? The interpreter got to the greeting function and sent that function call to what is referred to as the event loop. Then once the last statement on the page finished executing, the console logs from greeting were printed to the console. One piece of context, setTimeout is used here to mimic the behavior of an HTTP request, or any asynchronous tasks may that an undetermined amount of time to complete.

There are a few different things at play there. However, to give you an overview of why asynchronous code is so important in JavaScript is that example right there. The thread did not have to stop at any point in execution. The interpreter reads every statement from top to bottom, and if any asynchronous tasks appear the interpreter will wait until every other statement on the page is ran to execute that function.

This is all possible with the help of what is called the event loop. The event loop allows for the asynchronous model that JavaScript relies on to produce fluid and non-blocking applications.

Asynchronous callbacks are amazing, they enable JavaScript to be dynamic and non-blocking and all the sort. The only issue comes in when we need to code out a plethora of asynchronous callbacks one after another. Take the following code snippet for example:

 if (req.method === 'POST') {
    //parse chunks
    let body = '';
    req.on('data', (chunk) => {
      body += chunk.toString() + '\n';
    });
    req.on('end', () => {
      let url = querystring.parse(body).url;
      archive.isUrlArchived(url, (exists) => {
        if (exists) {
          httpHelpers.serveAssets(res, path.join(archive.paths.archivedSites, url));
        } else {
          archive.isUrlInList(url, (exists) => {
            if (!exists) {
              archive.addUrlToList(url, () => {
                res.writeHead(302, httpHelpers.headers);
                httpHelpers.serveAssets(res, path.join(archive.paths.siteAssets, '/loading.html'));
              });
            }
          });
        }
      });
    });
  }
};

The code example above is an example of a node.js server setting up routes from an incoming HTTP POST request. This request is handling multiple different conditions, and with each condition, in order to receive the information that the request is asking for, we have to go out and get that information using asynchronous functions, and then bring it back to the client. In order to implement this without blocking the thread, we have to have a callback function in place to wait for the data to get back to the server then manipulate the data from there.

This is perfectly fine and will work, the problem with asynchronous callbacks is when your application grows in size and you need to include more and more callbacks. This makes your code hard to read and maintain not only for you, but the next person that may come and read your code. People normally identify and reference this pattern as callback hell. That's something that needs to be avoided if possible. Enter promises.

Just as the name suggests, promises are a declaration or assurance that one will do a particular thing or that a particular thing will happen at some point in the future, with thing being asynchronous functions. Promises in JavaScript are extremely useful for asynchronous tasks because they abstract away the exact time data will become available, and simply leave us with the task of handling that data if/when it comes back from that asynchronous function.

Coming from MDNs web docs, promises in JavaScript are objects that represent the eventual completion (or failure) of an asynchronous operation, and its resulting value. When implementing promises in JavaScript, it's important to note that a promise will be in one of four stages:

1.) pending - Hasn't fulfilled or rejected yet
2.) fulfilled - The action relating to the promise succeeded
3.) rejected - The action relating to the promise failed
4.) settled - Has fulfilled or rejected

Let's take a look at an asynchronous promise in action:

let promise = new Promise((resolve, reject) => {
//conditional is here to handle errors that may happen
   if (error) {
  reject(error);
   }
//set timeout is here to mimic an asynchronous task
    setTimeout(function() { 
        resolve('Hi, my name is');
    }, 2000);
});

In this example, we created an instance of a promise using the new keyword and assigned that to a variable. The promise constructor function takes a callback function as an argument, and that callback function takes two parameters which are resolve and reject. Reject is called if there was an error at any point in execution, and resolved is called there weren't any errors in execution.

We can now use the promise like so:

promise
.then((data) => {
    console.log(data);
})
.then((data) => {
    console.log('Hi, my name is');
})
.then((data) => {
    console.log('Hi, my name is');
})
.then((data) => {
    console.log('errka errka slim shady');
})
.catch((error) => {
console.error(error);
});

The function above will log:

1.) 'Hi, my name is'
2.) 'Hi, my name is'
3.) 'Hi, my name is'
4.) 'errka errka slim shady'

The .then(), and .catch() are properties on the promise object that we can chain to manipulate exactly what happens if the promise, either is rejected or resolved. You can equate chaining to saying, "Hey promise, go get this thing for me while I go to the store, and if/when you get that thing I'll handle it from there."

So in conclusion, when using promises we can still get all the fantastic benefits of handling multiple asynchronous tasks without having to go through callback hell to do it. I hope after reading this blog you'll get at least a little bit better understanding of what promises are and why they are so important and amazing in JavaScript. I promise you won't regret it.

Come explore Node's humble abode.

Michael Bazile — Wed, 25 Mar 2020 05:23:09 +0000

Welcome. How are you doing? Here to learn about Node and all the neat stuff you can do while using it? Fantastic. Let's get straight to it shall we?

To start things off, let's first go over what exactly is Node. Coming straight from the source, Node.js is a JavaScript run-time built on Chrome's V8 JavaScript engine. For people that may be new to JavaScript, that simply means Node.js is a place where you can write and execute JavaScript code outside of the web browser.

Node.js was created in 2009 by a software engineer named Ryan Dahl. Since that time, Node.js has grown to be one of the most, if not the most, popular JavaScript run-time environments today. Node.js has quite a few reasons why it's highly used and is extremely popular to use.

For one, Node.js is powered by Google's V8 engine so the environment still has all the same great features and speed that the browser offers. From the crazy event loop, to the single threaded non blocking I/O that is preformed and executed asynchronously. This allows for code to continue to run even if some other part of your program has not yet resolved, be it due to an HTTP request or a setTimout function or any other asynchronous task that is currently happening.

You may be thinking, I can just do all of this stuff in the web browser, big whoop. There is something I haven't mentioned yet. Node.js allows you to also run server side code in the same environment. That's so convenient and helpful for JavaScript engineers to be able to write client side and server side code all in the same environment in the same language! There's no need to use one language for the client side and then a different one for the server side, it's all the same from top to bottom.

To get started using Node.js, you can go straight to their website and download it straight from there. Just follow the steps and boom, you have Node.js on your own computer. To check if everything was properly installed you can go to your bash terminal and enter the command node -v. This will show you the version of Node that you have installed. After that you can enter node in your terminal, then your all good to go.

From there, you can start to write JavaScript even right in the terminal with no problem.

Cool right? Straight out of the box you can either start running JavaScript code in your terminal or your text editor of choice. If your are familiar with JavaScript that's no problem at all. Let's dig a little deeper and let's explore running server-side code. Before we do, I want to go over a few more great features that make Node.js so popular.

Node comes by default with npm already installed and ready to go. According to Node.js's website, npm, is two things: an online repository for the publishing of open-source Node.js projects; second, it is a command-line utility for interacting with said repository that aids in package installation, version management, and dependency management. This allows for quick and easy automated dependency and package management. So you can just specify all the dependencies you are using for your current project and you can just run npm install on the command line to ensure every other dependency is loaded so you do not have to.

So now we know how to install Node, and get a project up and running quickly with the help of npm. I feel like you're already starting to love Node.js already, and you're probably ready to go and start coding with Node.js. Before you go, let me explain how to write server-side code using Node.

const http = require('http');
const port = 3000;
const ip = '127.0.0.1';
const server = http.createServer();

console.log(`Listening on http://${ip}:${port}`);
server.listen(port, ip);

The code above is inside of a file called nodeblog.js, and this is the bare bones of a basic Node.js server. There are a few different things going on here so I'll break them down one by one. On the very first line you'll notice a variable called http that is assigned to the results of a require function call that's being passed in an argument of http.

This keyword required is essential to the Node.js ecosystem and how workflow is conducted. The keyword is apart of a module formatting system called the CommonJs Pattern which promotes the structuring and organizing of JavaScript code. The CommonJs pattern is vital to be able to pass functionality from one module to another. So now the nodeblog.js file has access to the http object that will allow us to create a server.

const port = 3000;
const ip = '127.0.0.1';
const server = http.createServer();
server.listen(port, ip);

So now that we have a good idea as to what require and the CommonJs pattern is, we can look at the rest of the file. You'll notice that there is an ip, port and server variable in the file.

In order to be able to receive and respond to outside http requests you need a port number and an ip address so your server can listen to any incoming requests. Your local computer will have the same ip address or you can swap 127.0.0.1 out for localhost they both point to the same address.

Along with the ip address, every server needs a port and port number also. A port is a communication endpoint that identifies a specific process or a type of network service. Ports are identified by a combination of 16-bit numbers, commonly known as the port number.

const server = http.createServer(requestHandler);
server.listen(port, ip);

Great we having pretty much everything in place to start using our server live on the internet. All we have to do now is call http.createSever(), and listen for any incoming requests passing in the ip and port numbers. If we go to our terminal and run the command node nodeblog.js you'll see this:

Pretty cool right? There is so much to love about it honestly. I'm currently a student just learning about Node.js and I really enjoy all the great features Node.js brings. I hope after that you can go out and start exploring Node's humble abode on your own. On that note, thanks for reading! Until next time!

It's time to give a gleeful eye at RESTful APIs.

Michael Bazile — Sat, 21 Mar 2020 17:53:09 +0000

Hi there, how are you doing? If by chance, you decided to click on this link, that must mean you're here to learn about RESTful APIs. Hopefully, after reading this blog, you will accomplish that. Let's not waste any more time and get straight into it, shall we?

Let's start from the beginning. What exactly is an API? Great question. An API is an acronym that stands for an application programming interface. That's just a fancy way of describing how two different pieces of software can communicate with each other. It's probably unbeknownst to many people that they actually interact with a variety of different APIs every single day.

Let's take the music discovery app Shazam for example. The Shazam app is an app that will identify any song that you do not recognize by simply pressing a button and holding your device close enough to the music. This is an extremely powerful tool to have and all we, the user, have to do is just press one button to use it. We do not need to know how or what happens behind the scenes. We simply download Shazam, follow their steps to log in, and voila! Next time you and your friends are in the mall, and you can't remember the name of the song playing, you just pull out your phone open Shazam, and press a button.

That, my friends, is an example of an API at work. In this case, the user (you and I), goes to Shazam, hits a button, something happens in the background, and in return, we get information from Shazam indicating the song that is currently playing. That's the beauty of APIs in a nutshell. They hide the abstraction of the how and why, and in return, all you need to know is how to access them.

Now that we know what APIs are let's dive into a specific type of API. The one you came here for, and is RESTful APIs. REST is another acronym that stands for Representational State Transfer. The originator of this architectural style is Roy Fielding. If you want to learn more about him, here's a link to his dissertation on REST.

Up until Roy Fielding came out with REST, there was not a universally accepted way to go about designing APIs. So it was really difficult to go about accessing other developers' APIs because each API came with its own set of rules of how to access them. Thinking back to the Shazam app, signing up to use their app isn't very difficult. Just imagine if every app you have on your phone has drastically different ways to go about logging in and using them. That would make the user experience very frustrating and confusing.

The same goes for developers trying to access APIs to use in their applications. In comes RESTful APIs. The ideology behind RESTful APIs is that any API designed with REST in mind will make it easier for other developers to access and consume them since mostly all RESTful APIs have the same characteristics. So when a developer comes across a RESTful API, that developer will know what to expect when accessing information.

Pretty neat, right? Now that we covered what APIs are, and we've dug into what RESTful APIs are, how about we get into how to go about accessing one of these wonderful RESTful APIs?

I'm not sure if you've ever heard of this application before, but you and I will consume information via an API from this thing called YouTube.

const search = (query) => {
      $http({
        method: 'GET',
        url: 'https://www.googleapis.com/youtube/v3/search',
        params: {
          part: 'snippet',
          q: query,
          key: YOUTUBE_API_KEY,
          maxResults: 5,
          type: 'video',
          videoEmbeddable: true
        }
      }).then(function successCallback(response) {
        console.log('success', response);
      }, function errorCallback(response) {
        response.error.errors.forEach(function (err) {
          console.error(err.message);
        });
      });
    };

The more you research APIs, you'll find that there are many different ways to go about interacting with APIs. The code snippet above is an AngularJS HTTP GET request that is going to request information from the URL provided in hopes that we can get data back from YouTube's API to use in our app. Please, do not worry if that code seems daunting. We are about to go over precisely what it's all doing in a moment. First, I want to give you some helpful insight into a few concepts before then.

Here comes another acronym. HTTP. This acronym stands for hypertext transfer protocol. When I first learned of this concept, it flew clean over my head and went who knows where. However, after breaking down the acronym into smaller components, it started to make more sense as to what it meant.

The main thing I want you to get from that is the last two words. Transfer Protocol. As the name implies, in order to access a RESTful API, you must follow the proper protocol that is specified by the developer(s) who built that API.

So an HTTP GET request is one of five different methods that you can implement in your code when consuming RESTful APIs. It depends on your particular task, but generally, you'll mainly be using GET requests to retrieve information from the API of your choice. In this case, it's YouTube's API, and you must specify exactly what method you intend to send to it.

Okay, how are you doing? I know it's a lot of information, but I mean, you already know this much more already. Take a moment, it's cool; I'm not going anywhere. Once you've come back, we'll get right back to it.

url: 'https://www.googleapis.com/youtube/v3/search',

The next thing is the URL from above. This URL will act as directions from the request from our computer to the API that we intend to access. With /search being our endpoint. An endpoint is the point at which the two pieces of software will communicate. Two pieces of software being our request from the code snippet above, to YouTube's API. Specifically, their search API, because that is the endpoint that we specified in the URL.

Nice! We have everything pretty much in place. We have our HTTP request, we have specified the method of HTTP request we want to send, and we have the location we want to send our HTTP request. Not finished yet. Just a few more things to cover.

params: {
          part: 'snippet',
          q: query,
          key: YOUTUBE_API_KEY,
          maxResults: 5,
          type: 'video',
          videoEmbeddable: true
        }

The params above are specific to YouTube's API. Going back to the Shazam app, you must follow specific steps before you can access what the app has to offer. The same goes for APIs. This will vary from API to API, so it's vital to lookup the documentation for whichever API you plan on using.

.then(function successCallback(response) {
        console.log('success', response);
      }, function errorCallback(response) {
        response.error.errors.forEach(function (err) {
          console.error(err.message);
        });
      });

Lastly, once you've sent the request, you'll either receive the information you requested or an error message indicating what went wrong with the request. If you get an error message, it's best to google the error message and refactor your request from there.

Other than that, we did it! We sent an HTTP request to YouTube's API and got information back from it. It's time to play The Weeknd's new album all day now!

So, in conclusion, we've learned what APIs are. We learned what RESTful APIs are. We learned how to make an HTTP request to a RESTful API to consume information that we can in turn then use in our application. Fantastic! Good work. I hope you've gained something from reading this post, so you can now go out in the world and gleefully eye other RESTful APIs!

Memoization

Michael Bazile — Sat, 14 Mar 2020 03:53:20 +0000

Hi there, are you perhaps looking for a blog that can explain what the heck memoization is? Well my friend lucky for you, you've come to the right place. My name is Michael Bazile, I'm an aspiring software engineer from New Orleans. I currently attend Operation Spark, and this is my very first blog ever, so come and join me on this educational journey together.

To get things started, I'll just give a basic overview of what memoization is. The basic concept behind memoization is the idea of saving the results of function calls inside of a cache so if that same input is given to the memoize function again, the result is already saved on the cache so the function in return does not have to do the entire computation of that function.

Caching means storing the copies of frequently used data in cache memory so that we can access it faster. Cache memory is faster to access.

This is amazing for reducing the time in which how long a computation has to take in order to get a result. As a current student myself, one major concept I've learned about is time complexity. Meaning how much, on average, does it take to start and finish an algorithm. Memoization is an awesome way to so do, let me show you how.

let memo = func => {
  //cache variable, to store all of your key/value pairs
  let cache = {};

  //return a function
  return (...args) => {
    //make keys for cache
    let key = JSON.stringify(args);

    //check if key is not on cache
    if (!cache[key]) {
      cache[key] = func(...args);
    }
    //if key
    return cache[key];
  }

That was an example of a basic memoize function. As you can see on line one, memoize functions will always take in a function as its first parameter. Moving down to line two is where the cache (object) is declared and saved into a variable. This is the cache that will be saving all the expensive function calls each time that memo function is called. Moving down to line six, the memo function must return a function as well as take in a function. Inside that return function is where all of the interaction with the cache will be. On line eight is where we start to store key value pairs. Any arguments that is passed into the anonymous function will be turned into a string using the JSON.stringify() method. Lines eleven and twelve and fifteen is where it all happens.

On each function call, the memo function will check the cache to see if that key is stored on the cache, if it is, the memo function will simply return the value on that key. If it is not, then the func parameter will be called on the arguments and will be stored on the cache at that key. When the size of your input data increases, having a memoize function to decrease the time it takes to get information will better improve the performance of your algorithm as a whole.

That was a pretty thorough and detailed explanation, but that's how I learned to understand how memoization works by breaking down what the function is doing bit by bit. With this implementation, the time it takes your functions to run will drastically decrease and in turn better optimize your functions.

So in conclusion, memoization is a great tool to optimize function performance by reducing time it takes to run. Memoization does this by saving the results of function calls on a cache (object) where the key is the input and the value is the result of the function call. So with this newly gained knowledge, I hope you use a memo function to memorize some of your function calls in the near future.