Found a great article on NoSQL data modeling

While my employer has afforded me an opportunity to explore NoSQL, one of my largest concerns about pursuing mongo db (the M in MEAN) is how to handle complex data. This is a more pronounced issue if your goal is to make a SAAS solution.

Doing some work in AWS I did see a possible approach and a further Google search found this gem...https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

js resources

Speaking JS - http://pdf.th7.cn/down/files/1411/Speaking%20JavaScript.pdf
You Don't Know JavaScript - https://github.com/getify/You-Dont-Know-JS
Learning Advanced JavaScript - http://ejohn.org/apps/learn/

nodejs debugging module

https://blog.risingstack.com/post-mortem-diagnostics-debugging-node-js-at-scale/?utm_source=RisingStack+Engineering&utm_campaign=b56bd14274-EMAIL_CAMPAIGN_2017_05_09&utm_medium=email&utm_term=0_02a6a69990-b56bd14274-474900697

This looks good, I will need to take a closer look at it later.

3d resources

https://www.udacity.com/course/interactive-3d-graphics--cs291

Learn the basics of 3d graphics


https://threejs.org/

A free (MIT license) JavaScript 3d library for use in WebGL.

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

Spent Energy

Since this blog is new, I already have 2 repos in git covering:

node-study-1 )

Covers my setup and configuration on Windows 10, including a basic introduction into how I will be using the git desktop

https://github.com/ChrisJokinen/node-study-1



node-study-2 )

Goes a little more into a GitHub work flow using feature branches and how to avoid multiple contributors overwriting or deleting work.

https://github.com/ChrisJokinen/node-study-2


My next goal will be to take a closer look at one of the most common pain points in node.js, the callback. This will also lead into an exploration of how one can work around asynchronous programming when your logic requires a specific order of steps.

Introductions

I first started developing for the web in 1999. Netscape still roamed the planet doing battle with IE4+. Specialized tags like blink and marquee were cool and table-based layout was just how you did it.
Microsoft had just released something called XMLHttpRequest in IE5 and the profession web community took notice. This was the beginning of Dynamic HTML.


For coding on the server side, developers had a few choices. Adobe's Cold Fusion, which was powerful, but expensive and ran in java. Sun Microsystem's JSP which was just released so lacked a strong community...and ran in java. Microsoft's ASP which was fine in it's own right but you were restricted to Microsoft OS's....and ran LIKE java. OK that last one may not be fair, my bad! A few other languages existed that fell into obscurity, but the one I decided to target was PHP.


PHP was a magical place! A fine dynamic community of people willing to help one another with free code snippets, free libraries, free advice, free tutorials, free meetups (before meetups) and lets not forget, free tools! It is an oddly wonderful place where so much human effort is embraced by a single concept...PHP. What did you think I would say?


Meanwhile the big browsers; Internet Explorer, Firefox (formerly Netscape) and introducing Opera continued to fight each other. Changes in browser features happened at a rapid fire pace. Libraries like jQuery did not exist, so anyone developing back then had to write there own custom code to not only control a web page, but make it work on all of these different browsers and versions of browsers and even the version of browser on specific operating systems...IE5 on Windows had a different feature set (or implementation of a feature) than that of IE5 running on a Mac.


I sometimes think I should have a t-shirt that reads, "I survived web development pre 2006". Because at that time jQuery was released and web development became a happier place. I must admit I did not jump on jQuery when it was first released, but in time I did and almost immediately wanted to kick myself in the backside for not doing so earlier. Gone are the days of "feature sniffing"...why does that read weird?


PHP continued to grow in dominance on the server side driven by a horde of cost conscious developers mad on Mountain Dew and Doritos. Well maybe that was just me. An ever growing number of profession PHP frameworks where soon followed by Content Management Systems. Being a purist I have steadfastly maintained that PHP is the only framework or CMS one needs!


Voicing this is like standing in a room full of like minded believers. Developers all milling about and having a great time sharing stories of coding successes. Then as time passes you start to realize the voices are getting quieter. Looking around the room you notice people are leaving through doors marked, Drupal, Word Press, Joomla, and others. Does this mean I'm not a part of the cool kids? Ah...now I'm sad.


Somewhere in all this table-based layout was replaced with CSS layout. Frameworks came and went. PHP added OOP, got fat, and is now dieting.  HTML5 and CSS3 had FINALLY been released. And this landscape known as web development is moving from physical servers to "The Cloud"...which is a cluster of physical servers...that creates virtual servers...with the ability to provision other virtual servers on demand...Try not to think about this too much, you will get caught in some virtual endless loop...virtually.


I am still in that PHP room, standing in front of that door marked Drupal. I can not help but wonder, if I open it and walk through....how will I respect myself in the morning.

Welcome

My goal with this blog will be to compliment my GitHub account where I have started to make a series of repos covering my study of the MEAN stack. MEAN is a collection of software used to make web apps and sites. The parts of the MEAN are MongoDb, Express.js, Angular.Js and Node.js.

In addition, I will record my studies in related and additional technologies as I work toward gaining mastery of Amazon Web Services (AWS) and the serverless webserver, using the services of S3, API Gateway, Lambda, DynamoDb and many more.

So, you might be curious as to, why MEAN and AWS? well, in a few words, I feel strongly that this is the future of web development.

For MEAN the reasoning is in how an application is designed as a fat client. This design sends much of the application logic to run on the client and less on the server. The MEAN stack focus on JavaScript as a unified language provides the programmer with a non-blocking code execution when using the node.js style. While very powerful it does come with a learning curve and a new set of headaches. I will try to dive into these issues at length going forward.

Amazon Web Services (AWS) offers power to the developer at a price point that is most impressive. And the one feature that really got me to notice AWS was its serverless offering. Serverless is a group of related technologies (S3, API Gateway, Lambda, DynamoDb and others)  that can serve dynamic webpages. These pages are served from AWS S3, which is a object storage service.

Objects can be HTML, CSS, JavaScript files, images and more. Since S3 supports the 3 basic files needed for a website (HTML, CSS, JS) then turning an S3 Bucket (think folder-ish) into a website must have been a natural progression for AWS. Using the API Gateway to make a REST interface will allow you perform AJAX like calls to node.js code running in a Lambda instance. Lambda is a place to store code and execute it. Lambdas have limited memory and execution time limits, but they have the ability to interact with a growing number of services designed to handle specific kinds of work.

Now all of this runs on a virtual environment that can scale dynamically as your load demands. This scaling is limited by your settings so you should not fear a run away expense.

So much to do and so little time!