Software development is an art. It isn’t predictable enough to be engineering. It isn’t rigorous enough to be science. Developers are artis and that is not a good thing.

One of the biggest problem today is that we can’t write software faster enough. We can’t write software that meets business and that is sufficiently accurate and reliable.

When the requirements change in the middle of a project it damages the architecture so badly that we spiral into a death march of hacks and kludges our data structure, concepts, entity relationships into a compliance.

Requirements are always underspecified. Bad management wastes time and eats up development schedules. Our non technical colleagues have complex challenges of their own, it’s time to grow up and accept that we have a problem: we can’t write software fast enough.

There is a difference between technical infrastructure and the business logic. One of the key roles is to make the big things out of the small things.

Microservices create too much overhead at the start of a project. The business logic implementing a microservices con have multiple runtime configurations, meaning it can partecipate in the system in many ways, without requiring changes in the business logic code.

With microservice approach you can follow the principle of additivity, your only action is to add new microservices, leaving the others running.

There is no downtime, and the risk of breakage is low. In case you want to experiment a new version of micorservice you could deploy and start a new instance of it keeping the old one. In this way you can have multiple version of a service deployed in production.

This is very far by the updating the entire system and there are no unforeseen effects in production. The big advantage of using microservices architecture is its own composability.

Adding a new feature does not consist of extending an existing service, but you will add a new microservice. This avoid technical debt by moving complexity into message routing configuration and out of conditional code.

You have to understand the system by organising the message patterns into a hierarchy, which is mush easier to comprehend them an object relationship graph.

In a traditional system you end up putting most of your data in one big central database because that is the path of least resistance at the code level. In microservices would you are freed from this constraints.

The microservices are not affected by each others choice of data store and this makes cadges easier. If you find the need to migrate to a different database then the impact of the change will be minimised.

In a monolith you have too many ways to interact with other objects. Every developer has access to the entire code base and can create dependencies faster and when it’s clear that encapsulation is suffering there is often no time for refactoring. This is a recipe to increase the technical debt.

If you use complexity as a proxy measure of technical debt you can see that object oriented monolith are more vulnerable to technical debt. The measure is given to you by the total of possible interaction between the elements.

The prefix micro indicates that the components are small avoiding accumulation of technical debt.

Composition works well only when the means of communication between the components is uniform. It’d not the mechanism for the communication that matters, but its simplicity.

Microservices in practice are small, because the smaller a service is, the easier is to compose. And if it’s small its implementation language matters less.

A service may be disposable, because rewriting it’d functionality does not require much work.

The power of additivity helps to contain the technical debt, the changing of business requirements can be met by adding a new microservices not modifying or breaking the old ones.

You need some automations to control the large network of the services. This immunise you against human errors. Move from the general to the specific you should solve the simplest general problem first and then the special cases. Following this approach preserves the additivity and keep the technical debt lower.

The system management is too complicated and needs automation. Unlike with the monolith, where scaling is all or nothing you can easily have variable numbers of different microservices running and applying scaling only when needed.

There is no excuse for not doing this and it is not a criticism of the microservices architecture to say that it’s difficult to achieve. This is a baseline feature of any reasonable deployment tool or cloud platform.

The monitoring of microservice system is different from the monolith, because the used measurements of low level health such as CPU and memory usage are far less significant. From a system perspective what matters is the flow of messages.

Additivity allows the microservices architecture to clean itself.

The microservice attitude is the belief that it helps to deliver fast and to create a business value with the software in a practical and efficient way.

Sometimes we believe that microservices are mini web server offering a small REST based api that accepts and returns JSON documents. This is a limited view on what microservice really is.

A microservice is an independent software component that takes no more the one iteration to build and deploy.

When there are a few services you can configure each services with the network locations of the other services, but this practice becomes unmanageable as the numbers of the service grows. The standard solution is to use a service discovery mechanism (etcd, Consul, Zookeeper, …).

You could have a policy to scale a group of microservices or a single one and to do that you need a load balancer (NGINX, HAProxy, Eureka, Envoy, …).

You should avoid the distributed monolith this happen one service is starting to strictly depend on other. This condition go under the name of “The trap of the distributed monolith”.

In microservices environment you can safely violate the DRY (Don’t Repeat Yourself) principle, because very often the general case is not sufficient to handle the complexity of a specific case. This will contribute to keep every service isolated from each other.

In a monolith you have one code base a single developer could break the build then all others will be blocked. In the monolith the technical debt increase rapidly. A well structured design is too weak to resist the immediate needs of an entire team working against the clock to deliver a feature.

The deployment risk associated with a monolith causes slow, infrequent releases of new features. You can only mitigate the problems arisen by the monolith, but in reality there is not project management technique that can overcome the engineering deficits of the monolith architecture.

You can reserve different effort for different service. Not all services are mission critical and need to follow the same quality rules.

The power of the microservices architecture comes from the fact that it offers a unified solution to many different scaling problems.

What many developers don’t know is that you can use node-gyp to create an Xcode project. This is possible following few steps:

• Go inside the folder of your project
• Execute the following command:

node-gyp build &&
node-gyp configure --debug -- -f xcode

At the end of the execution of the previous command a new folder called build has been generated on your project and inside it you can find two new files:

• binding.xcodeproj
• config.gypi

Now you can open the file binding.xcodeproj through Xcode and use this IDE to edit, debug and build your native addon.

Edit and build your code is a simple task you only have to select the source file change it and then press the button Build and run …

Now it’s time to configure the debug and like first thing you need to select the project addon and then Edit Scheme …

In the tab info set the executable that Xcode will use when you want to execute the debug operation. In this case you have to set the executable to the path of your Node.js installation that you can retrieve with the following command:

which node

The result of the command should be something like this:

/usr/local/bin/node

In the tab arguments you have to set the script that you want to start on executing the debug. In my case it is the index.js file placed in the root folder of my project.

Finally it’s all set and you can start using Xcode to debug your native code.

In this article I used very simple code example that you can find here:

NickNaso/debug-addon-xcode

Acknowledgements

Thank you to all people that encourage me every day.

Nicola Del Gobbo

This is my final result and I want thank to my colleague Pierluigi Iannarelli to suggest me this wonderful JavaScript module.

Here my final results:

Here my notes:

Useful resources about noUiSlider:

Documentation

Source code

Anyone who has used Node.js should be familiar with events. This module has the responsibility to facilitate the communication between objects of your application.

Much of the Node.js core API modules are built around an idiomatic asynchronous event-driven architecture in which some kinds of objects (called emitter) periodically emit named events that cause Function objects (“listeners”) to be called.

Sometimes you need to promote loose coupling system by ensuring that instead of components (modules) referring to each other explicitly, their interaction is handled through an exchange of message using the events.
This can help to decouple the systems and improve the module reuse.

Let’s start off with a simple example to illustrate how an instance of the EventEmitter class can be created and used to listen to and trigger events.

By default, all listeners attached to a particular event object are called by the EventListener object synchronously in the order in which they are registered or attached to the event object.

How can emit an event from a native function?

Usually a native add-on is composed by two parts one written in JavaScript and another written in C / C++. In most common cases the JavaScript part will use the functionality exposed by the native function to do something.

If you want emit an event from a native add-on the basic idea is to use the EventEmitter interface provided by Node.js core API. Specifically as reported in the code below it possible bind and pass the emit function to a function exposed by a native add-on.

What we expect in the code is that when the emit function will be called inside the native function it emits some events and then the corresponding listener will be executed.

Launch an event from the native function now is very simple because we only need to call the emit function like reported in the code below.

Every time we want trigger an event we have to call the emit function with the right parameters, but sometimes we want that our native object inherits all the behaviours of the EventEmitter and to achieve at this purpose we can use the inherits function like reported in the code below.

Now the native object has all the fields and methods of EventEmitter and we can use them inside the C++ code.

In the following example we are creating a class that in its instance method emit some events.

In this short article I wanted to illustrate how to use the EventEmitter interface provided by Node.js core API in the native add-ons and hope that it could be useful to someone.

In the examples that I proposed I triggered events from a native function that is executed synchronously on the event loop thread, but it could be more interesting emit an event from a native asynchronous function. I will update this article when all these other example will be ready.

All the code illustrated in this article is hosted in the following repository

NickNaso/addon-event-emitter

With my great joy these examples have been included in the official examples for Node Addon API and you can find them in the following repository, too:

nodejs/abi-stable-node-addon-examples

For most of you that want start to write their Node.js native addons using N-API I just repost some useful resources that was very useful to me:

C++ Addons

C++ Addons N-API

Node Addon API

N-API the next API for Native Addons

How I ported bcrypt to new N-API

Speed up Your Node.js App with Native Addons

Acknowledgements

Thank you to all people that encourage me every day.

Thank you Pierluigi Iannarelli to help me with all the illustrations present in the article.

Nicola Del Gobbo

Node.js includes an event system which is an implementation of the Observer pattern that is the most common used event pattern in Node.js application and for good reasons: it’s incredibly simple and useful.

Hertzy adds additional messaging related features called frequency that represents a communication bus through different parts (modules) of one application that can communicate each other.

Anyone who has been used Node.js should be familiar with events. This module has the responsibility to facilitate the communication between objects of your application.

Much of the Node.js core API modules are built aroud an idiomatic asynchronous event-driven architecture in which certains kinds of objects (called emitter) periodically emit named events that cause Function objects (“listeners”) to be called.

Sometimes you need to promote loose coupling system by ensuring that instead of components (modules) referring to each other explicitly, their interaction is handled through a central point. This can help to decouple the systems and improve the module reusability.

In implementation terms Hertzy use the mediator pattern that is ideal for application level notifications such as the communication between different subsystems that are themselves complex.

Mediator Pattern Intent Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. (GoF)

The largest benefit of the mediator pattern is that it reduces the communication channels needed between objects or components in a system from many to many to just many to one.

Both pattern mediator and observer promote loose coupling, however, the mediator achieves this by having objects communicate strictly through it, while observer creates observable objects that publish events of interest to objects that are subscribed to them.

In the specific case of Hertzy, it allow to create multiple event bus represented by frequency object and every module can listen or emit an event over the selected event bus.

As example you can think at web application where every time a user complete the signup process through the user module another module need to be notified the subscription module and on the other hand the user module need to be notified when subscription will be created.

To start using Hertzy you have to import it in you project. After that you need to obtain a frequency or create new one. A frequency object is a channel where you can emit or listen for an event issued by other modules.

Using Hertzy you avoid to create high coupling between the previous two modules (user and subscription) and in the near future if you want split your monolithic application in a set of microservices you can do that in a more easy way and you will need to replace Hertzy with something like ØMQ or RabbitMQ.

All the API provided by Hertzy is really simple but very powerful, if you interested in using it you can find all you need on npm

If you want contribute to Hertzy feel free to create a PR to its repository:

NickNaso/hertzy

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

To go more deeply on the concepts around mediator and observer pattern you can consult the following resources:

Mediator pattern

Observer pattern

Acknowledgements

Thank you to all people that encourage me every day.

Mantainers and creators of backbone.radio a module that has inspired my work on Hertzy.

Big thank to Pierluigi Iannarelli that created the concept behind the new logo of Hertzy.

Nicola Del Gobbo

Hertzy an event bus channel was originally published in CloudBoost on Medium, where people are continuing the conversation by highlighting and responding to this story.

They are a bridge between our application programming language JavaScript and native environment that is completely written in C/C++.

They allow us to call C/C++ functions and methods directly from JavaScript.

One of the most important experimental feature announced with Node.js 8 was N-API which is aimed at reducing maintenance cost for Node.js Native Addons.

It is independent from the underlying JavaScript runtime (ex V8) and is maintained as part of Node.js itself.

This API will be Application Binary Interface (ABI) stable across versions of Node.js. It is intended to insulate Addons from changes in the underlying JavaScript engine and allow modules compiled for one version to run on later versions of Node.js without recompilation.

Addons are built/packaged with the same approach/tools outlined in the section titled C++ Addons. The only difference is the set of APIs that are used by the native code. Instead of using the V8 or Native Abstractions for Node.js APIs, the functions available in the N-API are used.

As you can understand from the N-API documentation it’s completely JavaScript engine agnostic and it guarentees the API and ABI compatibility between different version of Node.js. So if you switch to a different version of Node.js you must not reinstall and recompile the addon.

I was really enthusiastic about N-API specially after I followed the talk reported above at Node Interactive 2017

N-API — Next Generation Node API for Native Modules

I discovered that there is a C++ Wrapper of N-API called node-addon-api so I just started on experiment using it and in 4 or 5 days of my spare time I ported bcrypt to N-API.

I started to modify the package.json file where I added the right dependencies as reported on setup documentation

The next step was to modify the binding.gyp file that contains all the building configurations for the bcrypt addon.

At the end bcrypt addon is composed by two parts one written in C++ and another written in JavaScript and as usually the JavaScript part use the native code to expose its features. I didn’t want change the JavaScript API exposed by bcrypt so I focused on the C++ part and changed the code following the node-addon-api documentation.

I started to rewrite the parts that has the responsibility to create the codes that will register a module named “bcrypt_napi” and in addition it will ensure that a function init will be called when the module is required.

bcrypt exposes synchronous and asynchronous API, so method after method I completed the refactor and now the code is as reported below

The last step was to execute the entire test suite and with my pleasure all tests passed successfully and they were executed more fast than the addon created using NAN. In the next days I will will perform most effective performance tests after that I will deploy my first Node.js application that will use this version of bcrypt, so stay tuned I will update you very soon.

For most of you that want start to write their Node.js native addons using N-API I just repost some useful resources that was very useful to me:

C++ Addons

C++ Addons N-API

Node Addon API

N-API the next API for Native Addons

Nicola Del Gobbo

How I ported bcrypt to new N-API was originally published in Node.js Collection on Medium, where people are continuing the conversation by highlighting and responding to this story.

On the way I usually taken notes about native addons that now I scanned and want share with all of you.

Here you can find the PDF i generated from my notes:

NickNaso/nodejs-native-addons-notes-2017

By the way sorry for my bad calligraphy

In general if you are interested on native addons I report some

• C++ Addons
• C++ Addons — N-API
• N-API the next API for NAtive Addons
• Node.js With Steroids video
• Node.js With Steroids repository

Today ES6 specification known as ES2015 is almost supported in many JavaScript engines but not completely. For programmers sometimes is very frustranting cannot use some interesting and useful new language features.

In the case of ES6 JavaScript developer that want use new ES6 functionalities scuh us arrow function, class, generators, promise, maps, sets now can do that thanks to tools as babel and webpack.

In this article i explain how to setup ES6 to use it in the Node.js environment. To do that we transpile ES6 code dynamically (at runtime) thanks to Babel.

In general there are two alternatives to transpile ES6 code, static and dynamic. Dynamic approach is convenient for experiments and development because it uses on the fly transpilation, which means that startup is slower and Babel need to be installed on the production system. We focus on the dynamic approch and we’ll configure a Node.js project to use it.

The first step is to create an empty Node.js project with your favourite IDE or simply make an empty folder and create a package.json file like this:

{
  "name": "My Application",
  "version": "0.0.1",
  "description": "My frist Node.js ES6 Application",
  "private": true,
  "homepage": "http://www.mywebsite.com",
  "author": {
    "name": "NickNaso",
    "email": "nicoladelgobbo@gmail.com",
    "url": "https://github.com/NickNaso"
  },
  "contributors": [
    {
      "name": "Nicola Del Gobbo",
      "email": "nicoladelgobbo@gmail.com",
      "url": "https://github.com/NickNaso"
    }
  ],
  "bin": {
    "start": "./myapp.js"
  },
  "scripts": {
    "start": "babel-node ./myapp.js"
  },
  "dependencies": {
    "babel-cli": "*",
    "babel-plugin-transform-regenerator": "*",
    "babel-preset-es2015-node4": "*"
  },
  "devDependencies": {},
  "babel": {
    "presets": [
      "es2015-node4"
    ],
    "plugins": [
      "transform-regenerator"
    ]
  }
}

Now from shell launch the command:

npm install

At the end of this process all node modules are installed for your project and your new project structure contain a new folder node_modules.

It’s time to program and create in the root of project our first ES6 module so make a file named Person.js and edit it as reported below:

export default class Person {

    constructor(firstName = "John", lastName = "Doe") {
        this._firstName = firstName;
        this._lastName = lastName;
    }

    get firstName() {
        return this._firstName;
    }

    set firstName(firstName) {
        this._firstName = firstName;
    }

    get lastName() {
        return this._lastName;
    }

    set lastName(lastName) {
        this._lastName = lastName;
    }

    toString() {
        return `You are ${this._firstName} ${this._lastName}`;
    }

}

In the previous module we just created and exported a class Person with properties _firstName and _lastName and their getter, setter methods with additional toString method that have the responsability to print the properties’ values.

To complete our project we have to create a file named myapp.js that will be the application starting point as reported below:

import Person from './Person';

let myTeam = new Set();

myTeam.add(new Person("Brendan", "Eich"));
myTeam.add(new Person("Ada", "Lovelace"));
myTeam.add(new Person("Dennis", "Ritchie"));
myTeam.add(new Person("James", "Gosling"));

for (let person of packlyTeam) {
    console.log(person.toString());
}

It’s time to start our first ES6 application in Node.js environment so execute the following command:

npm start

The output will be something like that:

> MyApplication@0.0.1 start G:\Projects\Web\GitHub\BNode-ES6
> babel-node ./myapp.js
You are Brendan Eich
You are Ada Lovelace
You are Dennis Ritchie 
You are James Gosling
G:\Projects\Web\GitHub\BNode-ES6>

Now you are ready to start use all ES6 features in your Node.js project.

At pack.ly (https://www.pack.ly/create) we use it because more features are very useful for us and especially because they make the javascript code more understandable at semantic level.

You can find the scaffolding of the code described in this article here:

BNode-ES6

In this project i used Node.js 4.3.1 so in package.json i installed “babel-preset-es2015-node4” and in babel configurations under presets keys i setted “es2015-node4”. If you have different version or configuration please refer to Babel docume ntation here: https://babeljs.io/

Thank you all.

@NickNaso

This brief tutorial is going to show you how to easily install MongoDB database server on Ubuntu 15.10 without any troubles.

A stable version of MongoDB packages are already in the default Ubuntu repository. However, the version in Ubuntu’s repository isn’t the latest. If you want to install the latest version you must add a third-party repository to your system and install it from there.

You can find more information about MongoDB and its installation here:

https://docs.mongodb.org/getting-started/shell/tutorial/install-mongodb-on-ubuntu/

To do that, run the commands to add the repository’s key to your system. Without this key, you won’t be able to install packages from the repository.

user@HOST:~$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927

Next, run the commands below to add the repository to your machine

user@HOST:~$ echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.2.list

Update your system and refresh existing repositories by running the commands below.

user@HOST:~$ sudo apt-get update

Now you can install the latest MongoDB version through the following command.

user@HOST:~$ sudo apt-get install -y mongodb-org

If you are on Ubuntu 14.04 or 14.02 this was the final step but for the 15.10 version we have to set up some extra configuration so let’s start to check if the actual installation is good as it is now. To do that launch the command reported below.

user@HOST:~$ sudo systemctl status mongod

If the result of this command tell us that there’s no one mongod active process on the system try to restart the system and rerun the predecing test and if we obtain the same result we need to use the following script to fix the things.

So after downloaded the script execute it as follow:

user@HOST:~$ sudo chmod 755 enable_mongo.sh
user@HOST:~$ sudo ./enable_mongo.sh

Now all is ok and you can try to connect to your MongoDB server by mongo client

user@HOST:~$ mongo

In response to this command we should receive something like the picture reported below.

Finally we finished to install and can have fun with our MongoDB server.

Nicola Del Gobbo

When you install WebStorm on ubuntu 15.10 and start it at first you receive this error message:

IDEA-78860 Keyboard input sometimes is blocked when IBus is active https://youtrack.jetbrains.com/issue/IDEA-78860

Solution:
Either upgrade IBus to version 1.5.11 or add “export IBUS_ENABLE_SYNC_MODE=1” to your ~/.profile, then restart a session.

Alternatively, you can turn off IBus at System Settings | Language Support | Keyboard input method.

IDEA 15 will show a warning if an incompatible version of IBus is in use.

To resolve that i preferred to install new version of IBus and to do that i created a folder colled ibus in my Downloads folder

user@HOST:~$ mkdir ibus

After that i downloaded in the ibus directory all binary package files present here:

amd64 build of ibus 1.5.12+git20160201-0ubuntu1~xenial1 : Testing for Wayland : tista

From the shell move in ibus folder and execute the following commands:

user@HOST:~$ sudo dpkg -i *.deb
user@HOST:~$ sudo apt-get install -f

That’s it now all is fine and WebStorm start without error.

Nicola Del Gobbo