React article, reading later

https://medium.freecodecamp.com/yes-react-is-taking-over-front-end-development-the-question-is-why-40837af8ab76

No compiler for old coders

I found a medium article with a great many links to additional resources.

https://trackchanges.postlight.com/modern-javascript-for-ancient-web-developers-58e7cae050f9#.6r1vf6b4u

I also ended up joining Free Code Camp, they provide you with a certification program (very detailed too) and you provide free labor in working on a website for a non-profit company. Sounds like a win-win-win!

Anyways I have already finished the first project and started the second one. I will continue to post resource I find and my thoughts on this experience as I go.

https://www.freecodecamp.com/

Resource: A guide to making a Serverless App

http://serverless-stack.com/

Know thy self, or if I only knew what I did not know I needed to know

As I focus on gaining mastery over the "MEAN" stack and explore the many libraries available, I read a lot of different articles and listen to various podcast on the subject. This article ( https://www.quora.com/How-do-you-judge-a-JavaScript-programmer-by-only-5-questions ) caught my eye and I gave it a read, including the comments.

What its interesting about this type of article is that it gives details on what one should know on a given technology. You can then compare this to your own knowledge and identify any gaps in your knowledge.

For me I gather a number of topics I feel are missing from my JavaScript knowledge, which includes:

• call
• apply
• bind
• map / reduce
• closures
• prototype ( as you may recall from my last post )

So in order for me to go forward in node.js and company, I must at least have a passing knowledge of how what all of these topics mean. I say passing knowledge because mastery will come with use. So step one, what the heck is "call".

Before I look at what a call is I ran across this article ( http://hangar.herokuapp.com/javascript/guide ) which was recommended by another article. It is a great refresher on the basics of JavaScript that we should all be familiar with, provided you have made any web page with some JavaScript on it. It then quickly builds on the basics and goes into more advanced features of the language like scope and prototypes.

For Call, Apply and Bind read this post from StackOverflow.com ( http://stackoverflow.com/questions/15455009/javascript-call-apply-vs-bind ) Of particular interest is the 2nd answer by "CuriousSuperhero". While not the selected answer, it gives a set of very simple examples on how these are used and what makes them different.

Another great article on the difference between apply and call can be found at ( https://hangar.runway7.net/javascript/difference-call-apply ) and here ( http://javascriptissexy.com/javascript-apply-call-and-bind-methods-are-essential-for-javascript-professionals/ ) for a very detailed read on call, apply and bind.

On Map and Reduce ( https://www.sitepoint.com/map-reduce-functional-javascript/ )

On Closures this makes for a good read ( http://javascriptissexy.com/understand-javascript-closures-with-ease/ )

On Prototypes ( http://sporto.github.io/blog/2013/02/22/a-plain-english-guide-to-javascript-prototypes/ )

JS Higher-order Functions and Class Inheritance

I was planning on making a tutorial to explore JS higher-order functions, but during my research I found an interesting article that gives a very good introduction of the different types...

https://www.sitepoint.com/demystifying-javascript-closures-callbacks-iifes/

Be certain you read the comments as it has a nice debate on the closure examples that could offer more insight into them.

I had a question on the IFFY 4th function example which produced a undefined result. After playing in JS Bin, I was able to get a result outside of the IFFY with this...

var test = function(){

  var today = new Date();
  var currentTime = today.toLocaleTimeString();
  // output: the current local time (e.g. 7:08:52 PM)
  console.log(currentTime);   
  return { currentTime:currentTime };
}();

console.log(test.currentTime);   // output: current time

Segway

The idea of the return value came to me from a project I did for work. In that I converted a set of PHP classes to Node.js. while working on it I needed to find a way to implement classes with inheritance in Node.js. So I found an article on it a while back and did not write down the source (grr). So below is the basic idea on the structure:

base_class.js:

"use strict";
// private var
var name = '';

// public
function base(){
  console.log("base");
  function set_name(input){
    name = input;
  }
  function get_name(){
    return name;
  }
  
  return { 
    set_name:set_name,
    get_name:get_name
  };
}
module.exports = base;

The base class will define all of the common functions used in the inherited classes. You could also include additional features, like a debug flag, connection data, etc...

inherited_class.js:

"use strict";
var base_class = require("./base_class.js");

var inherit = {};
inherit.__proto__ = base_class();

function inherited(input){
  console.log("inherited");

  var inherited = {};
  inherited.myname = function(input){
    inherit.set_name(input);
    return inherit.get_name();
  }
  
  return inherited;
}
module.exports = inherited;

Calling the inherited class in the final class permits you to use the public functions and variables declared from it. While the base class is called from outside of the function "inherited" and hides its public functions and variables.

final_class.js:

"use strict";
var inherited = require("./inherited_class.js");
var naming = new inherited();


console.log("My name is: "+naming.myname("Chris"));

// calling this will cause an error, so no access to base class
// console.log("Calling Base Class Function: "+naming.get_name());

Calling these "classes" is most likely wrong in the classic sense, but I was more interested in providing a modular separation of code and inherit common functions.

The real code I made was connecting to a 3rd party API. This API had different parts like send customer data as one API and lookup customer as a separate API. Since both the send and lookup APIs used the same basic connection data and common function. Building my code like this made sense...at least to me.

Is this the best way to design code for this use case? I am not certain! From my point of view making code that works is more the point of my job than conforming to a purist point of view. On the other hand, conforming to a more purist coding practice makes understanding each others code easier.

Perhaps it is better to just admit, I have more to explore.

List of nice NPM modules to look at later....

Database:
https://github.com/sequelize/sequelize
https://github.com/typeorm/typeorm


Reporting:
https://github.com/Nathanaela/fluentreports


Workflow:
https://www.npmjs.com/package/shep