nodejs: Continuous Code Deployment using Node.js and AWS Stack

Yesterday we had our monthly Node.js usergroup meetup. I want to thank all for coming and exchanging interesting ideas for us to ponder.

We looked into how to create a complete deployment cycle using cloud technologies to support our node development.

We reviewed the complete process (build, test, deploy) and how tools like:
- AWS CloudPipeline
- AWS CodeCommit
- EBS (Elastic Bean Stalk)

We also used Solano Labs CI build service which is a cloud based alternative to build tool like Jenkins.

Building a continuous deployment cycle can change the game for even small shops to roll out quality code from development to production in very little time.

Here are the slides from the presentation, this will probably help those that were taking diligent notes. Most command line text are present on the slides.

http://downloads.boncode.net/downloads/CharlotteNodeJSSeptember2016.pdf

Cheers.
B.

serverless: Serverless Framework and ethics vs the shiny object dilemma

For the last little while I was working on serverless concepts and exploring the Serverless Framework. It allows me to automate many manual steps but at the same time  it also imposes its way of thinking. Thus, it is a highly opinionated framework.

Though one can be of different opinions some of the good things provided by this framework are the ability to organize your project locally, abstract configuration, and deploy to different clouds from the command line.

The local development and testing paradigm is still rough and docs and examples are rather high level in many places.

It is also very much at the beginning stages with version 1.0 just about to be released. As such it has an enthusiastic crew with a lot of passion to push things forward. So, in short it is the new shiny thing that is cool and thus enjoys mindshare and interest.

In general that is a good thing. In particular, I can already see that there are cracks in the foundation. Two things in particular come to mind:

A) Dogma 

There is a sense of "we know better what you need" that permeates much of the later work on this framework. Whether it is through heavy configuration driven mechanisms in lieu of any convention elements or the careless breaking of implementation from earlier beta releases. For example, here is just a sprinkling of frameworks that believe in less configuration is better:

• Apache Maven
• Appcelerator's Titanium Alloy
• ASP.NET MVC
• CakePHP
• ColdBox Platform
• Contao
• Crosslight
• Durandal (JavaScript SPA Framework)
• Ember.js
• Enduro.js
• Grails
• Java Platform, Enterprise Edition
• Laravel
• Lift (web framework)
• Meteor (web framework)
• Play Framework
• Roxy rest-API
• Ruby on Rails
• Sails (web framework)
• Spring Framework
• Symfony
• Yii

This does not appear to be relevant to the current team and my fear is that the shininess will not overcome the effort it takes to maintain this when an alternate framework emerges. Ignorance in this case is not bliss.

B) Ethics of Tracking

The framework uses automatic enabled tracking of usage data. To discover this you will need to dig deep into docs and code. I understand that this is anonymous, however, this is not the way to approach the issue. Take Apple's location tracking for example, it is anonymous as well. How good do you feel about it?

For me the issue is with the enabled by default attitude. It is the complete undermining of faith of the user community. I believe firmly that any company making the automatic assumption of collecting data about me is living on the edge of ethics. Rather than playing in the muck, I would like to encourage the team to elevate themselves from questionable practices. There is time, and there are better alternatives.


Yes, you can disable all this once you find out where in the documentation it is hidden and run the right commands. This is not the point. If you don't ask me assume that you should not do it.

Here is the disable command if you are looking for it (run against all instances and all machines that you own):

$ serverless tracking --disable

Conclusions

So in short, this framework has potential but it is sliding into the area of big, obtuse, and rather in-the-way-of-the-task with ethical dangerous undertones before even hitting version one. These are achievements we should not be proud off given the great promise that it has.

If you have a project that is small or medium sized there are alternatives that work equally well and don't involve you sharing your personal command history. You still get automation and deployment in place with full control. Look at connecting AWS Code Commit to Lambda through Continuous Integration Pipelines via CodePipeline. That is some sweet stuff.

I am planning on outlining how to do this in more detail in later posts.
I will also put some things on serverless how-tos as contrast. There is good stuff there so an eye should be kept on it.

Cheers,
B.

node: April 2016 Charlotte Node.js User Group material

Folks please find the links to the presentation materials and code samples from our April 2016 Node.js meeting. I hope this will get you kickstarted with node:

The presentation slides
The sample code

Here again the objectives from out meetup "Kicking it with Node, starter edition" :
By popular demand we will focus our sessions on how the node ecosystem works. This will include the setup of the environment the idiosyncrasies of JavaScript and base understanding of the event loop and asynchronicity.

So in the next session we will look at some of this:

• installing Node.js 
• understanding async tasks 
• understanding the event loop 
• what are callbacks  
• creating projects 
• understanding node modules and packages  
• organizing code  
• writing your own module 
• what is the package.json file 
• managing 3rd party packages with npm 
• the require system 
• exploring core module examples in node

Cheers,
B.