DEV Community: WestonDease

Nightmare

WestonDease — Fri, 08 Feb 2019 01:49:52 +0000

This is an automated post made entirely using nightmare!

Socket.io

WestonDease — Tue, 27 Nov 2018 21:50:58 +0000

Socket.io is a node package that enables realtime communication between clients and servers. This enables us to have clients interact with each other in realtime without even refreshing the page! Lets look at how this works.

If we were to have our app connect to the server with socket.io we would implement this code in our server:

const express = require('express');
const app = express();
const server = require('http').createServer(app);
const io = require('socket.io').listen(server);

This sets up our server to include socket.io but we need the app to make a connection. So also in our server we need to set up a connection statement to handle client connection. We include the following.

io.on('connection', function(socket){
console.log("we connected!");
//more code for socket.io here
}

This code should log "we connected!" on the backend when a client has connected. But connecting isn't enough, we want to send and receive messages. So to receive messages, inside the connection, we use:

//here we listen for an event called 'some-event'
socket.on('some-event', function(data) {
console.log(data);
io.emit('new-event', newData; //here newData is some contrived data
});

Now let's look at that last line with io.emit. Thats how we send events. If we place a listener in the app files like so:

socket.on('new-event', function(data) {
console.log(data);
});

This code listens for the new-event and console logs it on the console on the client side. This means that we now have all the parts to make this app communicate in real time. This comes with the benefits of changing data in our database and keeping it up to date across all clients. This is only the basics. We can make several different statements to include where our messages emit to. The current statement we have emits to all users. But we can do better than that. Here is a handy cheat sheet for all the emit types we can use:

https://socket.io/docs/emit-cheatsheet/

JavaScript Variables

WestonDease — Wed, 14 Nov 2018 01:29:26 +0000

Variables are everywhere in programming. It makes the process a bit like algebra in that you have an understanding that variables represent some data so you don't have to constantly reenter the same data over and over throughout the application. It also works to make values mutable across the app, allowing you to have a flow of logic that goes beyond hard coding answers into problems. Additionally variables allow you to make a minor change in the value at some point in the code and have it carry across the program. The key to maximizing the use of variables (and any part of programming or even perhaps life in general) comes down to understanding how they work. You must look under the hood and see how the engine works to fix the car.

There are few types of variables in JavaScript when compared to more basic languages like Java and C#. This doesn't however change what types of values can be stored in variables as it is still the conventional types of numbers, strings, booleans, and arrays (though they are objects and objects can also be thought of as variables).

Starting with the basics, lets declare variables. The most basic variable declaration in JavaScript is "var". This sets the scope of the variable to the execution context to the whatever its declared in. That means if it was declared in a function, it still has global scope. Using "let" then allows you to set block scope for a variable. The type "const" forces you to declare its value on declaration but it can still change if its an object.

Naming variables is more form than function. And by form I mean that whatever you name it has to be for the sake of you and others reading your code. Your names should establish in a quick few terms what the variable represents and perhaps what it is used for. Some conventions for naming is to use cammelCase for most variables and ALL_CAPS for constants.

Assignment of variables is done with the "=" operator with the variable on the left and a value on the right. Note that this is different than "==" which is a value comparison and will result in a true/false return value (also this ignore the data type as 4 == "4" will return true, 4 === "4" will not). Some quick assignment shortcuts include "+=" to add to the original variable, the same is true for "-=", "*=", and "/=" for their respective operations. When variables are first declared, unless given a value on declaration, will have the value of undefined.

Overall JavaScript is a smart language. So variables are going to be simple. But this doesn't diminish the subtlety of their implementation. I certainly didn't cover everything in this and the technicality gets even deeper. Perhaps I will comeback to this subject soon and bring a whole new bag of tricks to the table.

OOP Part 2

WestonDease — Tue, 06 Nov 2018 00:08:39 +0000

Last time we took a look at the four main principles behind OOP and what makes them useful. This time we will look at inheritance and polymorphism and how they work.

Inheritance

With inheritance a developer can create large sets of data quickly and easily. When a class is created that expands and is built on another class that object will take on all properties and operations that the parent class has. Classes that have this relationship are called super classes with the case of a parent class and ???? with the case of child classes. For some programming languages like Java and C# these properties can be overwritten in implementation of child classes, however in other cases such as JavaScript this option is not available.

Polymorphism

Polymorphism and inheritance are intrinsically linked together as they are both a natural result of embedded classes. To embed a class requires inheritance as the whole point of classes are to pre-establish attributes of a data set. As you go a layer deeper to embedded classes, these potential classes also gain the attributes in the same way any regular instance of the object would behave. Where this concept really takes off is in the concept of polymorphism.

For embedded classes we take an object and essentially make the parent class and turn treat it as another variable to be applied to the child class. While it's certainly more complex than "just another variable" as methods and groups of variables are added to the picture, it is a useful way to think about polymorphism in this way. When taking this approach the sheer possibilities of classes is reveals itself. Variable types are a bit of a tool belt for programmers and while you could argue that there is a hard limit on the types of data that can possibly represented by variables such as numerical data with int or float, symbolic representational data that has perhaps a cultural meaning like how strings represent words of whatever language is used or perhaps even encoded data with the case of letters in encrypted data, or simple true/false values such as booleans, The way groups of data are defined and manipulated with functions is perhaps the true "variable" we are looking for in the cases of high complexity solutions. Of course we should try to make our functions and objects pure, that is, have them perfectly implemented to be self-contained by relying only on data stored in the object and have functions only rely on data passed to as an argument. By designing in this way, programs can interact with each other in such a way to make unfathomably complex programs.

Conclusion

Ultimately, OOP is a (maybe i haven't used this word yet) complex concept but exists for us as flawed, simple humans. The uses for these principles are designed to help us understand what it is were actually doing when were stringing together long chains of 1's and 0's. This is the same concept that provides the power behind programming languages and compilers, operating systems, and even user interface whether that be digital or analog. Humans cant really understand the enormous number of boolean operations required to create what we have with computers. I start to loose myself in the complexity of an ALU graphed out with all of its logic gates and flags. But anyway I hope this guide gave understanding and context to just how gargantuan an undertaking computer systems are and their potentially infinite uses.

OOP Part 1

WestonDease — Thu, 01 Nov 2018 19:58:19 +0000

Programming is a field where many elements come together to form complex interactions. Some problems will need to manage separate yet similar objects for the sake of handling data, performing operations, or to even simply the task. If you are not familiar with the concept of object oriented programming or its properties and uses, this guide is a great place to start.

Object orient programming (OOP) is a common and powerful logical process where variables and operations are grouped into objects based on their uses towards some end goal. There are four main pillars of OOP: abstraction, encapsulation, inheritance, and polymorphism. We will take a look at each of these elements to give you a clear sense of what these words mean and demonstrate their use.

Abstraction

Abstraction is a topic that fascinates me because ultimately (not to get too philosophical) human understanding of everything is heavily rooted in this concept. When a system has many repeating process that that layer over each other and those processes display some emergent property, the human mind uses abstraction to simplify and understand it. This is done so that a system can be understood without thinking about how each individual part of the system works and more complex logic can be built on top of it. For example, you generally understand how atoms work. They're made of particles like electrons, neutrons, and protons. They come together to form molecules which are just different atoms bonded together. Then molecules come together to form compounds and mixtures. These can interact to form proteins. Proteins interact to form cell organelles. Those interact to form cells. Cells form tissues. Tissues form organs. Organs form organisms. Organisms form ecosystems. Ecosystems form the environment. And the process could go on and on seemingly endlessly as we have yet to uncover the true extent of complexity in the universe. Even before atoms there are quarks and it is still unknown how far the rabbit hole goes. But enough about physics, where here to program.

So how does this apply to programming? When we approach a problem we don't need to know how every element works to understand the whole system, especially when we are only working on some narrow slice of it. When we are making "hello world" we don't need to understand the way the compiler works, or machine language, or really what a computer is. If we were writing these instructions on a piece of paper and sliding it under the door of some "Programming Chinese Box"
our understanding at the core level would be the same. So if we look at Node.js, Express, or whatever framework/library you are using to program, you don't need to know how Node fetches tags and classes from an HTML doc. The implementation of the library is irrelevant to your aims. It's the problem that you implement the library in that matters.

Encapsulation

Data is key. There has been more data created in the past two years than in the rest of human history combined. Security of data is an increasingly difficult problem as the years progress due to hackers becoming more voracious and aggressive and the data their after becoming more precious to its holders. But we're not trying to fix that, we just want people to not mess up our logic.

With encapsulation, we can choose how much information is given to whoever is utilizing our programs. Setting things to public or private is a simple way to achieve this, however this doesn't quite get it all. Some languages like JavaScript have no public or private attributes. And even the languages that do aren't exactly flexible enough for our purposes. If, when defining our objects and functions, we include them in a return statement with the attributes we want to be public, we can define precisely what and how things can be accessed.

That's all for now but comeback next time when we go deep into inheritance and polymorphism.