DEV Community: Jacques Williams

Differences Between Frameworks and Libraries

Jacques Williams — Mon, 12 Aug 2024 13:51:50 +0000

If you're anything like myself, you may have gotten confused at the concept of what a framework is compared to a library at some point. Seeing as though they are used in similar contexts, it's quite easy to confuse the two. Frameworks and libraries are both tools that are commonly used to create applications. So, let's explore what they are and why it's important to separate the two. First, let's discuss frameworks.

Frameworks
Frameworks, can almost be thought of as a blueprint. Meaning, that they are designed to build apps with a very specific structure, along with a specific set of directions. It's like having the blueprint to a house and being given a list of directions on how to build it step by step along with a specific set of tools. Therefore, each framework has it's own unique set of rules that is meant to distinguish itself from other frameworks out there.

An example of a framework would be Angular.js. Angular.js
has a specific structure that you must stay within as you are building. It has it's own way of passing "props" in a sense from one component to another by using the $ctrl tool that is required to reference any other variables from an outside component. Angular.js also requires the use of directives which is their own way of performing general actions. For example, to make a component dynamic, Angular requires the use of the ng-repeat directive to essentially perform a loop within the framework guidelines.

Frameworks also dictate the flow of our applications as well. What that means is that they typically organize how our application, and it's components should talk to one another. If you try to cheat the system, you're pretty much cheating yourself. So when dealing with a framework, it is imperative to have that frameworks documentation somewhere close by to avoid long hours of just trying things out.

Libraries
Libraries on the other hand, offer the developer a bit more freedom when it comes to the process of application building. For one, they aren't as strict as frameworks. Remember, Frameworks tell you how to build the house and what tools to use when building it. No exceptions. Libraries however, allow you to build the house with whatever tools you like. Libraries just so happen to have a ton of tools for you to choose from. They are reusable components that offer specific functionality. Thus, giving you the option to choose when and when not to use a specific tool.

For example, let's examine JQuery. JQuery as a whole, is considered a library. It provides tools that allows us to manipulate DOM/HTML elements to our liking. All while remaining inside a JavaScript file. So, instead of having to update our HTML manually each time we want to add/remove/manipulate a DOM element, JQuery provides a toolset that allows us to reference a specific element and more.

Typically, the syntax for selecting a DOM element must always begin with the $('DOMelementName'). Once you select the DOM element you'd like to alter, we would then chain a method that JQuery offers as well to actually perform the manipulation. For example, let's say we wanted to add a button to the page using Jquery.

When you've injected Jquery to your code, in order to use it on a Javascript file you must prepare the document using a built in Jquery method called ready. Once it's ready, we can now create the actions that we want our callback function to return. Let's try adding a button to the page for fun.

Here, we are using JQuery to prepare the document so that it knows we're gonna be manipulating DOM elements while in a JavaScript file. If we wanted to create a button, we must first reference the body of the document using the correct selection syntax. Notice that we are still using JavaScript to save variable name's like normal. From there, we can repeat this similar logic to create a new DOM element. Which is exactly what we did to create a new button. Finally, we used the built in append method that JQuery provides to actually add the button to the document. That way, we can see our button appear on the screen. Like so:

There are many other libraries out there to choose from. Another commonly used Library in today's world is React. React is known for it's ability to use tools such as props to pass properties from one component to another. Props in React however, can be named whatever. Unlike having to use $ctrl in Angular.js to perform similar functionality. React also offers a tool to help manage your application's state and listen for any changes. It is not considered a Framework because it offers different approaches for you to choose from, and isn't as strict. For example, you can choose to make a functional or class component when building the application.

In closing, Frameworks and Libraries are similar in regards to helping the application building process run smoother. The difference is that Libraries allow the developer to be a bit more flexible in there approach, whereas if you try to deviate outside of the guidelines of a framework, if the docs doesn't support your approach, neither will your application respect it. Unless you stay within the guidelines of how to perform that action while using the framework you chose. I've only given examples of front-end frameworks. But once you get to backend, you'll learn that it also has its own set of frameworks to choose from! Express.js being my favorite so far.

What is RAM?

Jacques Williams — Thu, 08 Aug 2024 04:49:28 +0000

What is RAM in relation to computers? Well, essentially RAM is what gives our applications a place to store, and access data temporarily. Performances such as browsing the web, or even editing a spreadsheet, all use RAM. Programs and documents load from the storage drive, and is then sent to our system's processor. The processor's job is to transfer the data from our long term storage to our short term RAM memory storage, until we are ready to save to our storage drive again after updates are made.

The use of Random Access Memory, or "memory" for short, allows us to process our applications at quicker speeds. Instead of having to save all of our temporary operations for the long term, our computer can quickly access, remove, and/or store real time data to its memory. This is all done to increase the overall performance of our applications. No one likes a slow running application in 2024!

Being able to access and store memory through RAM has it's drawbacks as well. For one, since our processor has to "process" our data/functions in real time, it doesn't need to keep track of any older changes that were made for the long term. RAM is more focused on the current state of our application data. Thus causing RAM memory to be considered a volatile form of storage.

For example, If you've ever encountered a situation where you lost power on your computer, then odds are you've made the mistake of not saving your work before. You were probably under the assumption that you could leave your computer, handle your business, and come right back to where you left off. Although the use of RAM memory allows us to multitask and maintain sessions, remember it is not meant for long-term storage. So, not only is not saving your work still dangerous, but power outages(and more) are very real. With that said, we don't want to lose our beautiful application because we wanted to keep VSCode open 24/7. So, even though RAM is cool, again it is considered volatile. Meaning, your data has a higher risk of being lost under certain circumstances.

So how does data get stored for the long-term then you may ask? Well, whenever we are saving our work, we are saving it for the long-term on our computer's storage/hard drive. Hard-Drives are a form of external storage. They are designed to "keep" the data that really matters to us for the long road. It is also portable and can be transferred to other machines once you connect them. Keep in mind there are multiple forms of external drives as well, such as a flash drive for example.

Another good example I can think of in terms of maintaining data through external storage, would be playing a PlayStation 2. If you are old like myself, you might remember having to buy something called a "memory-card" to save your game data. Imagine having to play through an entire single-player game without turning your game off at any point? Assuming you don't have a memory card, you can't allow for the game to shut off. Ever. Otherwise, it's game over and you have to start all the way from scratch! There were many days where I would pause the game and leave it on all day to avoid losing progress. Little did I realize, that the pausing of the game itself was the game relying on its RAM memory to keep track of its current state. With that said, I've lost count of how many times people accidentally turned the game off in the middle of my progress back then! Oh the horror..

In regards to RAM on our computer, yes we are able to multitask with several windows open thanks to it. However, the efficiency and speed of those responses really depends on the amount of storage that we have access to in memory. If you think of it like a desk, the more storage, then the more space on our desk that we can use for handling tasks at once. Standard RAM memory size is typically 8gb. But they can range as high as 64gb and even higher!

In closing, RAM is considered to be a sort of X-factor in determining the speed of your operations, as well as multitasking. It also allows our data to persist if nothing major happens to cause a disruption to our current state. The more RAM, the better for your computer. If you let tabs and windows pile up accidentally, then staying on top of your memory usage is important. Even though it's not a solution for long-term storage, it sure is great to be able to resume where you left off after you've closed your computer. Since the computer didn't shut off, your laptop memory will keep track of where you last left it. Just like un-pausing a video-game.

Servers! What are they?

Jacques Williams — Mon, 29 Jul 2024 18:32:04 +0000

Hello! Today we're going to talk about servers. So, what are they? Well if you're familiar with the industry and/or play(ed) videogames in today's world, then 9 times out of 10 you've complained about servers being bad at some point. Turns out, I'd been complaining about them for years without knowing what it technically does, until now. So, let's dive in.

Let's say we are heading to a famous restaurant together. We can imagine that this famous restaurant is renowned for it's excellent service. However, once we arrive there, we find out that the wait time is a bit longer than we'd like it to be. More time passes, and we are finally treated to our table and begin considering our order. Eventually, after 15 minutes, we figure out what we want and are now looking forward to making our order. Suddenly, another 30 minutes passes by and we have yet to make our order. Our waiter finally arrives, but his attitude isn't the best. We order our food with him, and he sends our order to the back of the kitchen. Now, imagine if it takes another hour+ JUST for your food to be made? I'm sure by then, you'd have the urge to walk out, if you haven't already.

In this example, we can confidently say that the service wasn't the best. Not only did we have to wait a while coming in, we also had to wait another hour once the order was made. So even though the restaurant was packed, it still doesn't change the fact that your personal experience wasn't the best. And knowing how popular they are for having great service, it only amplifies your own disappointment.

Keeping this example in mind, "servers" in our code, act as our "waiter" when dealing with specific data. More specifically, Servers are used to fetch information that's requested from the client. They are also responsible for saving requested information to a specific database(aka kitchen)!

So, how do you make a server as a developer? Well we can choose to use any server-side framework for our implementation. To be frank, there are plenty of different server-side frameworks out there. For the purpose of this blog however, we're going to choose one of the most popular ones that most agree is fairly easy to learn: Express.js.

In order to install the packages for our server-side framework, we must first add it's dependencies to our package.json file. Also, in order to start our server, we must add a "start" script to our package.json that points to our server file. From there, assuming we're using node, we can install our dependencies and run the command npm start in our terminal that will essentially "start-up" our server later on.

Now that we've installed, we can navigate to our server file.
Here is where you will be using express to get your server to respond. In order to use express, we must first "require" it by saving it to a variable. We then create a new variable that would invoke that variable pointing to our require. Like so:

Once that is done, our server now needs a port number, or address in a sense, to run our application on. Thanks to Express.js, we can create it like any other variable, and assign it to a number. From there, we can use the built in "listen" method that express offers to listen for any changes or visitors to our app at a specific port location. Like so:

So now, when we start our server in the terminal, your terminal should ideally respond with a message letting you know that it is working and can be visited at a specific port number.

One thing I want to point out, is that our port number can technically be any number. In most cases, a common port number you'll see in development is the number 8080. From that point, we would use our server to help perform actions requested from the client using middleware. Other than that, that is a quick intro into servers!

What are React Components?

Jacques Williams — Mon, 01 Jul 2024 13:55:05 +0000

If you're pretty new to react like myself, then you're probably familiar with the phrase "components" by now. But what are they? Well, let's dive into it.

In React, there are built in tools that allow us to maintain the state of our application a lot smoother when it comes to how many requests are being sent to the server. React does alot of the work for us inside of the web browser first by managing different "components" of the webpage.

For example, let's say we were navigating a web application in today's world, and we wanted to return to the home page of the app. Typically, in order to do so there would be a home button on the page somewhere. If we were to click that button in the earlier days, the server would then have to fetch that home page once the button is clicked, and spit it back out to the page. The problem, is that the process may vary in speed depending on the design of each web application. Thus making some websites appear to work faster than others back then. To solve this in React, the developers created idea of components.

courtesy of

In this diagram, you notice how the home page is considered the root. The root has two separate branches that each point to their own separate categories. Those categories, are considered "components" to the webpage. Not only that, but in react, the Home page itself, aka our "app" is also considered to be its own component. Since every other component points to the home page, our home page component must have the ability to access each component when being built.

Components, at their core, are simply functions! More specifically, they are functions that represent a specific "component" to the webpage. Because they are functions, that's what makes them reusable, allowing components to be passed from one to another. In React, there are two types of components that we must take a look at.

Functional Component

A functional component in React is useful for several reasons. The first being that it's considered a bit easier to read and write compared to its counterpart. Meaning, the syntax typically requires less lines of code. The hmtl, or "jsx" elements that you want to render are simply returned within your component function.

Courtesy of

This is a fine example of someone creating a recipe list component to their website. As you can see, the recipe list itself is a function. And inside of that function, a list element is being created for every ingredient thanks to the map function. In order to render that list of ingredients to the page, a functional component must simply return the element(s) created. In order for any other component to have access to this recipe list however, the "RecipeList" has to be exported at the end of the file. Functional components also have the capability of passing other component "props" by typing props as a parameter.

Class Components
Class components on the other hand, are defined differently. Defining a class component in React requires you to "extend" from the built-in Component class that is a feature of React. That Component class is used as the base for creating other class components.

If you notice, in order to render your jsx html elements, class components require use of the built in react "render" method, unlike it's functional counterpart that simply returns what you want to render.

Class components also allow you to pass properties of a class down to other components. These properties are referred to as "props" as well in React. Technically they can be named anything, but it is common convention to name them "props" to avoid confusion.

As you can see, we can reference the props of our parent component by referencing them within the class by saying "this.props". From there we are accessing the name property that we would like to pass down to our other components. It's a declaration that we use to later define what we want our props to be. So in the case of this example, we want the name of the prop to be "Taylor", that way other components can have access to this prop should we decide to use it for something else. This is an essential aspect to using React components in general. This allows for reusability.

In conclusion, there are other things that make class components unique such as maintaining state. But for now, these are a few key differences between the two types.

What is Front End Development?

Jacques Williams — Tue, 04 Jun 2024 17:44:42 +0000

Hello! So you may have heard of the phrase "front-end" development before, but you don't quite know what it means. Let's dive into it. Front-End Development is what I like to call the "umbrella" of our code that contains the visual side of things for our client. Essentially, everything you see on the webpage. Our role as the developer is to ensure that our websites are usable and compatible with one other.

Skills
Knowing how complex a working webpage is, you can imagine the different parts that all align with each other to form them. Essential skills required to learn front end development as a whole include knowledge of HTML, CSS, JavaScript, and Frameworks.

HTML is the section that includes all of the elements that create a webpage. For example, things such as creating a header tag, a title, a paragraph and even images. Here is how we divide our webpage into sections that we could even investigate within the browser.

For the sake of time, here we just created a header tag for the title of our blog. However, you can imagine there also being a body tag which would then include a p tag for every paragraph text of our blog. So if we were to debug our webpage, we can inspect which elements are what based on their structure in the html page.

CascadingStyleSheets (CSS)
The styling of our webpage typically goes here. From changing the color of a specific DOM element, to altering the background image of your page. CSS is a world of it's own because there are so many different ways to style a page and it grows by the day! So if you're a fan of designing how things will look on the webpage, CSS may be right up your alley.

JavaScript
Although there are many other coding languages, JavaScript remains to be one of the most commonly used. Not only that, but many people agree that learning JavaScript first can make your transition to learning other languages a lot easier.

For example, if I had an array of data that I wanted to be multiplied by 2, we can use javascript to create higher order functionality that achieves certain goals faster for us. In this case, the map function logs [2, 4, 6, 8, 10] to the console.

Frameworks
Frameworks are different tools that we as developers can use ensure that our webpages are able to "communicate" with one another. For example, if I wanted the client to add a tweet to the page, or even add a background image to their profile, we expect the state of our webpage to update to an entirely new one that includes that tweet and/or background. Frameworks allow us to do that! Just like there are many different coding languages, there are other frameworks as well. Some of them include Jquery, AngularJs, Bootstrap, Vue.js, and ReactJs; the most popular being React.

There are many other layers to front end development that can be a focus career wise such as maintaining Asynchronous HTTP Requests (AJAX) for the client side, DOM manipulation, learning about package managers (such as npm), hosting the webpage and more. Salaries can range between $60,000-$120,000 depending on your experience level. Some senior devs make up to $150,000. So it's imperative that you find your niche as a developer for job hunt. If you're one that loves to focus more on the client side of things, then you would narrow your search to anything under the front-end development umbrella.

FUNctions!

Jacques Williams — Fri, 19 Apr 2024 05:54:01 +0000

Hello! My name is Jacques and today we're going to be talking about the blueprints to our code - functions!

So what are functions? Well functions are blocks of code that once executed, will perform a specific action. They are typically defined by their return statements. However, that does not mean your function won't do anything if a return statement is not included.

So how are functions made? Well, functions are made by first declaring the function keyword, followed by a parenthesis, and then an open and closing body {} using the curly brace symbol like so:

function printName() {
console.log("Jacques");
}

Now that we made a function called printName which is designed to, in theory, print my name, we want to see if it will work now. In order to do so, We invoke aka "call" the function by referencing it's name, followed by parenthesis. Like so:

printName(); //logs "Jacques" to the screen

Think of the parenthesis as the way to actually activate your named function. Without it, you're just referencing a function body aka a function definition. So for example, if I were to try:

console.log(printName); // logs the entire function instead of the console.log aka result within the function

The thing that makes functions so awesome is that they allow for a more broad/dynamic approach to real problems that we may encounter. For example, if I wanted my printName function to print anyone's name besides Jacques every time, it would not work based on how it's currently built. This is where those parenthesis come in! The parenthesis serves as a placeholder for any amount of variables (aka parameters) that we want to replace later on with actual argument(s) for the function. So, instead of having nothing in the parenthesis of our printName function, we can do this:

function printName2(name) {
console.log(name);
return name;
};

Now, once we try to call this printName2 function we created, we can pass in what's called an argument for the "name" parameter to see if it will log whatever name we pass in, instead of logging "Jacques" specifically each time we invoke it. Let's try the name "Nico" this time to see if it works!

printName2("Nico"); //logs Nico and the return value for the function is also Nico since we're returning the given name as well.

Remember, functions are defined by their return statement. Without them, the actions we perform within might not stick per say. Once a function returns, it will stop the function's execution to return that specific value. Without it, your function just won't return anything. The console however, can always print a result that you specify.

Great! So to test out this 2nd printName function, we can try passing someone else's name besides "Nico". Let's try "Sara" instead.

printName2("Sara") //Logs Sara to the console

What about "Buzz LightYear"?

printName2("Buzz LightYear") //Logs Buzz LightYear to the console

In essence, the true beauty with functions is not only can they resolve to a specific value once they return, but you can also use a function within *another * function as well! Sounds intimidating, but don't be afraid! For now, let's create another function that checks if the given parameter/argument is a string to follow along!

function isString(value) {
//check if the datatype of our value is not a string,
if (typeof value !== "string") {
//if not, console.log false!
console.log(false)
//return false also
return false;
}
// otherwise, return true if it is a string!
return true;
}

Now let's try invoking our isString(value) function with a number as our value.

isString(9); //logs false and the return value of the function is false since 9 is a number and not a string! The first condition was met.

Now Here's where the fun comes in. In a perfect world, name will always be a string. However, we don't live in a perfect world! Some people actually have numbers for names. So now, let's try using this function inside of ANOTHER "printName" function to check if the "name" argument we give it is a string.

function printName3(name){
/notice we're calling the isString() function to check if the name passed in is a string or not./
if(isString(name) === false){
//if the name is NOT a string,
console.log("That is not a name dude!");
}
/here, we're calling our printName2 function which simply prints and returns the name that's passed in as our final return value./
return printName2(name);
};
printName3(9); //"That is not a name dude!"
printName3("Jacob"); //"Jacob"

If we call printName3 with a number argument for example, the console will log the message "That is not a name dude!" since 9 is not a string datatype. However, if the name "Jacob" was passed in as an argument, the first condition fails allowing us to call the printName2 function on "Jacob" instead. Jacob will then log to the console!

In short, functions are really beneficial to our coding life. They are reusable blueprints that can even help condense our code. If you find yourself repeating the same logic over and over in your code, consider putting that logic inside of a function that can be called at any point to get the same result. FUNctions!

Promises Broken Down

Jacques Williams — Mon, 16 Dec 2019 14:15:34 +0000

What are promises? Well, what is anything essentially in javascript? (Hint: it starts with an "O"). Hopefully by now you've guessed it. If not, then spoilers ahead. Promises are considered objects at its core! Promises are objects that hold our data. More specifically, they hold the data returned from asynchronous function calls. Once these calls take place, the promise object "promises to respond" once the calls are complete. In other words, we have the assurance of guaranteed responses with promises if they're set up correctly.

SO, why promises? Well, for starters JavaScript is considered a single threaded language. Meaning, that the interpreter reads our code line by line, aka "synchronously". But what happens if we're super awesome web developers and we need multiple things to work at once for our websites? Would synchronous functionality save the day? Nah. We need the ability to have multiple functions running at the same time. Enter the idea of callbacks. Callbacks, are just functions passed as arguments for other functions. Without callbacks, we simply cannot develop. We need functions to trigger after one another in order to become asynchronous. However, as great as callbacks are , there is a huge downside to it's typical use. When you're trying to handle a big asynchronous task within your app, having nested function calls can become a pain to read! And if we can't read our own code, then surely another developer would encounter that same issue. The term for having a ton of nested callbacks "Callback Hell". The reason it's considered a hell is because code has to be legible for us humans in order to tackle any tasks.

With promises, the intent behind it is to reduce callback hell while gaining other benefits as well! Besides promises being asynchronous, they also have a simple execution pattern. Promises allow for the term "chaining". This means, that instead of defining your typical function using the "function" keyword as a callback, we can just add another method to the promise object that's returned from the call.

There are three states to a promise, pending, fulfilled, or rejected. The pending state means the promise’s outcome hasn’t yet been determined because the asynchronous operation that will produce its result hasn’t completed yet.The fulfilled state, well simply means the asynchronous operation that produced the result, worked! Whereas the rejected state means that something went wrong somewhere. The fulfilled and rejected states are really your responses that you get back from promises.

Let's say we we're creating an asynchronous function to do something. In english, we would say, "Hey function, I need you to do something! Oh, then after that, I need you to do something else. Oh! and then right after that, I need you to do something else! But while you're doing those things, please catch any mistakes you might make. Thanks" This is how that would normally look.

However, since promises "promise" data back, we know we can attach callbacks to the function. Wouldn't it be nice to actually read the code almost the same way as we would read it in english? Well lucky for us, there's a built in promise method named "then". Using the .then() method allows for sequences like such to continue without taking so much computer, and brain space. The ".then()" is a method on a Promise that takes the result of that Promise and passes it as the argument for the then function (essentially, a callback function!).

This idea of simplified callbacks is called "chaining", where you just "attach" a method by placing a dot behind the call of the function. The call of the function is an expression, which means it has a result once called. That's why it works that way. Then is the next function, whereas catch is the built in function that "catches" any errors along the way. We could also go even further and make this more legible with es6 syntax.

In conclusion, a Promise is an object representing the eventual completion or failure of an asynchronous operation. Essentially, a promise is a returned object that holds the data we'd like to attach callbacks to.
It can have a resolve(fulfilled) if the function returned successfully, or a reject if function returned an error by chaining methods.
This simple syntax helps reduce callback hell by a ton! However, callback hell can still exist. Large amounts of calls can be hard to read no matter what. Having promises just makes it more legible.

React PropTypes vs. Angular Bindings

Jacques Williams — Mon, 09 Dec 2019 07:40:02 +0000

What are PropTypes in React? Well for starters, let's remind ourselves of what props are in the first place. The term props in React is short for "properties". Properties in React are passed from component to component, so that those components may inherit the same qualities. This reduces code reuse throughout our app, while maintaining the integrity of our MVC format! Here, we have a simple example of how props are used in React:

When rendering DOM elements to the page of a component, we can use props. Notice within the render function, we're passing {this.props.name}. Although at the time of it's declaration it has no value, when creating another element, props.name's value would then get set to whatever we choose. In this example, the variable "element" inherited the props from our "Welcome" class, and set the value of the name (attached to props) to "Sara". Now, when passing properties to certain components, the simple rule of thumb is that those properties should never change in order to maintain our functionality. However, with react, there's a slight drawback due to it being an un-opinionated framework. Let's investigate.

Here we have a salary Component written in es6 that uses react’s defaultProps method to set the default return of "props" to 0 if no argument is given. With that said, let's assume that this component successfully renders the annual and monthly salary.

Upon it's completion, we see how simple it is to pass values to props. Now, let's try adding another component that simply views the current salary.

Remember how easy it is to pass props right? Well here, we notice within the render of our ViewSalary Component, that the annualSalary property that we created within "Welcome" has been set from 0, to an empty object. Our output now becomes:

This is the downfall with props. There is nothing stopping me, or anyone else for that matter, from changing the value of props to whatever I want! Switching the prop's datatype to an object caused an emotional wreck in our salary! Here's where propTypes come in. Proptypes are React’s way of typeChecking, but for props. Meaning, that it is a built in, react method used to check the datatype of our expected output, against our actual output to ensure it matches. All it takes is a simple assignment! Take a look:

Notice what happened under our defaultProps. In order to prevent our props from being altered, we've allowed for strict type-checking by setting the datatype of our annualSalary to a number. Now, we don't have the stress of wondering whether our data will come back the way we expect. Although this is effective, it is technically an extra step the developer has to account for if he chooses to use react. Enter Bindings in Angularjs.

Now unlike React, Angularjs is considered an opinionated framework. Meaning, if you're gonna code, you're coding Angular's way. Angular also maintains the integrity of MVC format. With that said, it shares the same capabilities in terms of passing information (or properties) to components! Angular utilizes a strict syntax when passing those props. This syntax is known as bindings. Let's examine a video-list entry component in Angularjs.

Data binding in AngularJS is the synchronization between the model and the view. Here, we're passing the videos from the parent component to our video-list entry. How you might ask? You see where we added "bindings"? The "

The Idea Behind Time Complexity

Jacques Williams — Mon, 02 Dec 2019 13:53:11 +0000

What is time? And how is it "complex"? Well, the answer to that question is a long one. To put it simply, time is relative. Meaning, that time is measured depending on the circumstance. For example, the time in New Orleans may be 7 pm., while in Florida, it may be 9 pm. So in this case, time is measured based on the time zone you're in. Another simple example to consider would be a race between two people. Say we have a referee on the side that's recording their speeds with a stopwatch. In most cases, one person will turn out to be faster than the other. That person's speed will be measured at a faster time rate on the referee's stopwatch. So, looking at these two examples, we can see that time is measured differently depending on the circumstances or variables at play. Now let's dive back into our home world, "Computer Science"! Computers, like the stopwatch, have their own "time complexity". If you're a javascript master, you know fully well that there are many ways to skin a cat. Meaning, that there are tons and tons of ways to find solutions when building algorithms! And the speed that it takes for the interpreter to run all those functions, varies. Since we're dealing with computers, We refer to this as computational time complexity.

To represent computational time complexity, we use a specific notation known as "Big O". Just like anything else, while measuring time, there are always factors to consider. With functions, one of those factors being the size of the input taken in. Another would be the number of operations performed within the function. And to go even further out, another factor would be the amount of storage, and the type of processor your computer has. For example, let's take a look at these two functions.

When measuring the time it takes for a function to run, we use a notation known as "Big O". Here, we have an example of what would be considered a "constant" time lookup because our function essentially performs one operation each function call. The syntax is O(1).

On the other hand, what if we didn't know the actual index position that holds my name? Lets say we had to traverse the array to find it.

Here, we have what's considered a linear time lookup. In order to fully run the function, the interpreter has to increase it's lookup step by step based on the for loop. Each iteration, the time complexity increases "linearly" The syntax is for this example, is O(n).

There are a couple of other keywords to represent the time complexities of more complex code. Remember, the size of the input itself has to be considered! If I used an entire "phone-book" object as an input for example, you could imagine how long the computer will take to process it alone (not to mention run the function itself). For example, A logarithmic time speed, O(log n), gradually increases, but at a seemingly decreasing rate. However, for the sake of this article, we won't dive too deep into that.

In short, time is complex due to the factors at play. For computers, more specifically Computer Science, time is represented with a notation known as the Big O. Just like anything else, functions have different qualities based on their construction. Therefore, each function maintains their own time complexities.

What is Rest? (Pt. 1)

Jacques Williams — Sun, 20 Oct 2019 00:59:00 +0000

Gotcha! No this is not an article about Rest API's or anything like that. Nor is it about representational state transfer. Yes, I am talking about the one word that seems so foreign to us nowadays, "rest". As of late, I felt encouraged to do a quick post on the love of my life and why it is so important. Coding can become quite a taxing task. People just look at the average coder and assume that the work we're doing isn't exactly hard to us. As if you're automatically an expert just because you know how to read what's on the screen. To the average viewer, It's a phenomenon even to understand this stuff. Even though they are accurate in their interpretation of it's difficulty, that difficulty doesn't get thrown out of the window just because we "know" it. As most of us may know,coding is filled with those "I don't know" moments! And if you are someone who doesn't like the idea of being ignorant, then boy are you in for a roller-coaster of emotions! This stuff isn't easy! Some days you have those creative juices flowing, you're on a roll, everything seems to be going your way. All until you come across that one error that you can't figure out for your life. Just to find out (sometimes hours later), that it's because you forgot to include the "s" at the end of your variable name! Yea, a long day. Now our day has gone from being a productive, relatively easy one, to a pain in our butts! All because we've just wasted so much time on that one silly error. Now, imagine you still have a ton of other projects to work on. No fun at all. Which is exactly why as coders, it is ESSENTIAL that we rest.

For a field such as ours, we have to be at our best mentally at all times. Sometimes when coding, the cycle inside of your brain goes a little like this; you're trying to create representational algorithms, something like telling an event listener when to trigger throughout your app. Well, in order to know which event you wish to tamper with, must know what the components within your app consist of. There's also those moments where you're like: "But wait, I forgot!", or "let me go back and check what's referencing what". Followed by you finding out that the variable you're looking for is actually undefined because you're not accessing it properly (-_-). The list of tedious activity never ends. Unless you're an alien, human beings can only produce so much results before their brains go haywire. At most, we're only capable of true, maximum focus for the consecutive amount of 4 hours. That means, that for those 4 hours, you were at your sharpest, most productive self for every second of that window. But once that time has elapsed, the mind then starts to wander. And as your mind is wandering, the clock on all of your other projects is still tickin'. So would it be smart to try to aim for another 4 hours without so much as a break? Yeeaaahh, I think not.

We have to realize that we are not immortal! The general consensus of the coding community have an innate desire to be the best. Deep down we are perfectionists! However, do be careful not to cross what I call, the "no-return" zone. Which means that you've gone so far down the rabbit hole of possibilities, that you end up neglecting all of the other more important aspects of your life. For example your family, your loved one, or even worse, yourself. True your love for them may reach beyond the stars, but in order to make sure they're okay, you have to be okay as well. So, get your rest! Just like any job, you can't come to work groggy and un-alert. It makes a job such as coding twice as hard since it requires 100% focus. Therefore, attaining your rest saves you, and everyone else's time.

Cross-Cutting Concerns

Jacques Williams — Thu, 10 Oct 2019 06:21:30 +0000

What is considered a concern in general? Well in short, a concern is virtually anything that may cause a disturbance with the flow of your code. It can range from something as small as forgetting an "s" at the end of an already declared variable, or forgetting the difference between addition and concatenation. It could even be the fact that one of your functions simply aren't performing the way that you intended. Imagine if we made an app and put all of it's components under one file. Can you imagine reading down that long list of code? The thought itself scares me.

This is where the concept of Model, View, and Controller helps. Smart people of the world figured that in order to make our lives easier, let's create a sort of format for app building that allows us to pinpoint, or "separate" the concerns that may take place. Concerns may include things like logging, security, or data transfer(s). With that said, it explains the phrase "separation of Concerns". With the way the Model, view, and controller (MVC) is setup, everything is essentially talking to each other. The model holds all our data, the view is what is displayed to the client's screen, and the controller is how we control which actions we want to take place by listening for events to occur.. Right?

But what happens when I change something in one file but my application's state doesn't update? For example, if I had a file that held medical records within a collection, and I hard coded a specific change to one of the patient's records, I would then need to make sure that my model is setup properly to update the state of my application. But if it isn't for some reason, then you would know that the concern has affected the model, thus making it a cross-cutting concern.

One of the most common concerns when creating applications is security. When app building, we want all of our apps to be safe. With that said, knowing the MVC format, we help separate concerns yes. But that doesn't necessarily mean that everything is "safe". Attacks such as an XSS attack are quite possible. XSS attacks are considered "cross site scripting" attacks against your application. So if a malicious hacker decided to inject some mean code into app, he most totally could if the application is vulnerable. We can avoid this concern by setting up something called API keys. These keys are a form of access to your application, hence the name "Application Program Interface". This would be one example of a way to avoid a concern such as XSS attacks. However, there are still tons of other concerns to account for like not encrypting your data that's being sent to the web using a secure socket layer(SSL). Yeah, sounds like a lot to account doesn't it?

That's because it is! Remember, we are human and concerns are bound to happen, so stay cautious! SO yes, having a MVC setup allows for an easier experience when separating concerns. However, cross-cutting concerns range and could still take place if you haven't actually secured your information by using tools such as an API key. Your app may work just fine, but is it really secure? And What concerns have you accounted for?

Collections, Collections, Collections, Oh My..

Jacques Williams — Mon, 07 Oct 2019 11:13:44 +0000

The Beauty Of Collections In Javascript

Collections! You might have heard a thing or two about "collections"
throughout your career. No? You haven't? Darn! that reallllyy sucks. Hmmm... wouldn't it be nice if someone came along and explained what they are? Well today's your lucky day because this just so happens to be my very first dev post! So Let's get started.

The word Collection has a certain connection with every Javascript web developer. If it doesn't, well, that's a shame. Because without collections, would you be able to do virtually anything as it pertains to code? Ehhh.. technically yes but you wouldn't get very far. Collections in Javascript are a combination of two datatypes: Objects and Arrays.

Arrays in Javascript are considered a 0 indexed list. Which is a nice way of saying that they are a way of storing data. Let's say you needed to go shopping in the coding world. That's great and all but how exactly will I write my list down? What if I forget the ice cream again!? Well, consider it included! All you have to do is create an array literal and store your data inside of it like so: ["Food", "water", "ice cream"]. Pretty cool. Now if I wanted to check my list, I could just count the index position that holds a specific value (in this case, the index position of 2 is the culprit that has my ice cream). However life has never been easy for most of us. In reality, the internet is a big place that needs to hold a ton of information. So you can imagine how many lists are being used at a time! Not only that but arrays are virtually infinite in size! We have tools such as loops that help with traversing Array collections. But let's say I wanted to go to the movies and know the details about every showing before I picked one? And doesn't every movie have its own details? How would I store the data then? Surely that will get tedious by using this format.

Enter Objects! The next great "Collection". Objects are formatted a bit differently. Not only that, but they are not an indexed list like their sibling. Instead, objects hold properties. A property consists of 2 things, a key, and a value. So, going back to the movie example, I can use said format of objects to create one movie. The movie has a title property, release date, and a main actor. But remember! We're trying to compare movies right? Well what we could do is store each movie object to a variable and then compare those variables to see which movie I'd prefer. Sure. But that's tedious and not the best idea in terms of optimization. I'm a coder! Aren't we supposed to make life easier? Exactly. This is where the beauty comes in. What if I told you that we could make a list of objects similar to the same way we format arrays? How is that possible you say? Simple! Just store your objects inside the array! Wait wha? Yes. In javascript, you can simply store all your "movies showing" objects inside of an array literal.

Sure you would then have to loop through each object as well to access its values. But there are other methods out there that will help with that process such as underscore's version of the for Each function, or even recursion. This type of versatility within javascript is a prime example of how awesome it is. Essentially, Collections are the bread and butter of Javascript next to functions. Without collections, we wouldn't be able to use things such as prototypical inheritance down the line, which is a way that we pass data from one object to the next. And remember folks, all things in Javascript are objects! (Jk... not really)