Saturday, February 4, 2017

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.

Thursday, February 2, 2017

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!