blog_image

How to set up a Node.js development environment

Context:

Here at IntelligentBee we wanted to establish a few ground rules that all of our developers should follow when developing an app in Node.js. In that way all of us would be familiar with a particular set of tools, something that would make us deliver better software, fast. Here is how we set up a Node.js development environment for a particular project:

  • Installing NPM and Node.js
    To get things started you need to install npm, and Node.js. You can easily do that by downloading them from here.

 

  • Create a project folder, and navigate to it using your favorite terminal. Then create a package.json file in that folder, a file that will save all the libraries you use. Using the terminal, run the command [crayon-5b76cc0c4b4d7547164384-i/] . Write a few details about your project, and that’s it.

 

  • The web framework
    This should be project based, but we recommend Express.js as it the most mature and widely used framework for Node.js. From the Terminal, navigate to the folder where you will build your project, and run [crayon-5b76cc0c4b4e7789700327-i/]

 

  • The testing framework
    To deliver robust code, you need to write tests. Node.js has a lot of testing frameworks available, but Mocha.js is by far the most used and proven test framework out there. To install, run [crayon-5b76cc0c4b4ed130090981-i/] .Here we also need to mention the assertion library that can make life even easier. We recommend Chai.js, as it exposes all interfaces of asset, should and expect. Just run [crayon-5b76cc0c4b4f3731008889-i/]  in your terminal to install.

 

  • The IDE
    We’ve chosen Visual Studio Code over the more widely preferred Sublime Text, as it has a native support for Node.js debugging. Also, it is pretty easy for newer, less experienced developers to adopt it. You can get this free piece of software from here.

 

  • The linter
    We decided to go with ESLint, as it is the most popular linter for Javascript and has a plugin for linting Node.js code. It is recommended that you install ESLint in the project folder that you work in, but you could also install it globally. To install it for your project, run [crayon-5b76cc0c4b4f9637753714-i/]  in your terminal. To make it aware of Node.js and Mocha you need to install these Eslint plugins as well:
    - Eslint-node: [crayon-5b76cc0c4b4fe345679197-i/]
    - Eslint-mocha: [crayon-5b76cc0c4b503426360602-i/]

 

  • The coding standards:
    The Airbnb coding standard is one of the most popular out there, for JavaScript and Node.js. That would help you write clean code, that will be easier to understand later on, or by other people. In your terminal, run [crayon-5b76cc0c4b509197186605-i/]  and choose Airbnb as your coding standard. After you do that, you need to open the newly [crayon-5b76cc0c4b50e518566482-i/]  file that was created, and add "mocha" and "node" in the file. Basically that file needs to look like this, if you saved the file using JSON format:

[crayon-5b76cc0c4b513010065761/]
 

  • Install the ESLint plugin in VS Code
    Go into the VS Code app, and navigate to its Extensions page. Search after "eslint", and install the first result from the list. Restart VS Code.

 

Now you should be all set up and start coding. Enjoy!


How to save a file in Vim after forgetting to use sudo

Many of you probably experienced this. You edit a file in Linux with Vim or Nano or whatever else text editor you might be using and when you try to save, you realise you forgot to launch the editor with sudo privileges, and file can't be written. Exiting without saving and editing again with sudo privileges is not always an option, especially if you lose a lot of work.

Solutions

There are some workarounds. You can open a new terminal and grant the right permissions on the file with:
[crayon-5b76cc0c4e482532848519/]
Now you can go back to your editor and saving will be possible. Don't forget to change back the right permissions for your file.

Also, you could save in a new file and then copy the newly created file over the old one.

But these are workarounds. Vim editor actually offers a solution.

In normal(command line) mode of Vim you can issue:
[crayon-5b76cc0c4e48e380753050/]
And that works like magic. For the geeks, here is how the "magic" works:

  • :w - writes the contents of the buffer
  • !sudo - pipes it to the stdin of sudo
  • tee % - sudo executes tee that writes to "%" file
  • % - Vim expands "%" to current file name

So Vim actually makes magic happen.


should your online business use API?

Why Should Your Online Business Offer API

There are several ways to extend a business model but API is a hot topic right now as the online world is expanding very fast. If you’re a developer or at least interacted with APIs before, you probably know why public APIs are so important, but there’s a big chance you didn’t hear or care about them before and now you’re wondering why everyone talks about them.

What is an API

In computer programming, an application programming interface (API) is a set of subroutine definitions, protocols, and tools for building application software. In general terms, it's a set of clearly defined methods of communication between various software components. (Wikipedia)

There is a simple way of saying this: an API is like a contract between two computer software agreeing to share information in a more or less standardised way.

Now it’s pretty clear what are we talking about, but why are them so important? How can APIs help us? In the following rows I will try to argument some good reasons.

Getting Started with Building APIs in Symfony2

Grow your business

You can grow your online business by integrating with additional tools or apps and engaging with others. This can be done using public APIs.

Let’s take Uber and Google Maps: everytime you search directions in Google Maps (from home to work, i.e.) you can automatically request an Uber, see your driver on the map or even contact him, all without having to leave Maps app thanks to Uber’s API.

Or if you have an online store, you might wanna offer public APIs so other apps can request price offers and display your products on their platforms.

Get ready for scaling

It’s all sweet and fun to start a new business and you probably want to do it faster and cost effective. Usually this means a monolithic application.

Success means scaling and this can be done by breaking the app into microservices. This will enable multiple options for you.

Let’s say you have a microservice that is being used very often and affects your server. That microservice can be moved on a new server with dedicated resources only for it and it will be accessible for the rest of the app via an API.

Or there is the case when you want to rewrite a single microservice (some languages are more efficient than others). This is the beauty of standardised API - you only have to make sure you accept the same API call as before and return the answer in the same format, so other dependent services won’t be affected.

Time saving

UX/UI is very important and we strongly advise you to continue to invest in that area, but there are cases when having to explore an UI for some actions is time consuming for some (more technical) users.

Let’s take SendGrid and their Marketing Campaigns app. You can create a new campaign by going through the UI process or you can simply make a call to their API. Second option is usually faster (but for more technical people or at least you need to develop an integration first) and the flow will always be the same, while UI can suffer some modifications over the time.

Mobile app

At some point you will probably want to add a dedicated mobile app to your business. Having APIs makes it possible. You are free to develop a new design or a new template without any changes on the API side.

Providing APIs must be a concern for every company, whether they focus on internal operations, partner integrations or public access. Join the revolution! Add API support to your product! Get a free quote now.


Ruby-gems

Start writing tests in Ruby: useful gems

Being a QA engineer is a continuous struggle in finding the right resources in order to get the job done easier and more efficiently. If you are planning to write automated tests in RSpec (Ruby's testing framework), then you should take a look over these gems. Please notice that I am most of the time automating backend tests only, so the libraries I am using are for this purpose mainly.

 

1. RestClient

 

gem install rest-client

If you want to make API calls on RESTful endpoints this should definitely be your choice. This library is easy to use and the response includes code, cookies, headers and body.

Let me show you how to make some calls (GET, PUT, POST, DELETE):
[crayon-5b76cc0c4ef7d363352402/]
Now you simply use this response for your purposes (response.code, response.body, etc.).

 

2. JSON

 

gem install json

If I told you about RestClient, then the next one should be json. RESTful services will return JSON format in body most of the times so you should parse that response to be easier to work with.
[crayon-5b76cc0c4ef89983526119/]
See how simple this is? You only JSON.parse that response and that's all!

Since we are talking about JSON, let me show you how to build one:
[crayon-5b76cc0c4ef90744533146/]

 

3. Nokogiri

 

JSON and XML are the most used formats in web development. So you probably guessed that now I will show you some tricks on how to use XML in your awesome tests.

gem install nokogiri

When I have installed this gem on my ubuntu (v14.04) virtual machine, I have had the following error:
[crayon-5b76cc0c4ef95011056437/]
But this was quickly fixed after installing ruby-dev and ruby1.9.1-dev:

sudo apt-get install ruby-dev
sudo apt-get install ruby1.9.1-dev

Now let's say you have the following XML:
[crayon-5b76cc0c4ef9b174575166/]
If you want to access the values for username and password, simply do this:
[crayon-5b76cc0c4efa0406594919/]
Also, you can use xpath instead of css.

Let me show you how to build the previous XML file using Nokogiri:
[crayon-5b76cc0c4efa6017955787/]

 

4. Sinatra

 

This gem is used to mock endpoints. See more about it here.

 

5. Dotenv

 

gem install dotenv

It is recommended to keep environment variables and stuff like usernames, passwords and URLs in a .env file. In order to load those variables in your tests, you must use this gem.
[crayon-5b76cc0c4efac411375419/]
First you load the .env file, then use those variables in your tests.

 

6. Mysql

 

gem install mysql

The name itself says what this is used for. See below how to open a connection to a MySql database and do a simple operation:
[crayon-5b76cc0c4efb2287231782/]
 

I will update this post when I will use some new awesome Ruby library. What gems are you using?


Building a Face Detection Web API in Node.js

Introduction

As a follow-up to my previous article on how to use your webcam for face detection with OpenCV, I’d like to show you how you can create your own web API for that.

There are a few Node.js modules out there that do just that. A few of them even provide bindings for OpenCV so you can use it directly from Javascript.

The catch is that most of these modules either rely directly on binaries or they need to be built for your machine from a makefile or a Visual Studio project, etc. That’s why some of them work on Windows for example, but not on Mac, or vice-versa.

The objective of this article is to show you the steps needed to create such a module for yourself so that you can customize it for your machine specifically. What we’re going to do is create a native Node.js add-on and a web server that will use that add-on to detect faces and show them to you.

Prerequisites

I’ve built this on a MacBook Pro running OS X El Capitan Version 10.11.1.

Since we’re going to use OpenCV you’ll need to set this up for your machine, I’ve described how to do this in this article.

Next, we’ll need Node.js which you can get from here. This will also install NPM (the package manager for node) which we need to install some extra node modules.

The next thing we need is node-gyp which you can install using npm. But before you do that make sure you have all the dependencies required which are described here. For Mac they are python 2.7, xcode, gcc and make. So basically if you followed the OpenCV installation guide you should be good on everything except python which you should install. After that you can install node-gyp like this :
[crayon-5b76cc0c4ff16820424756/]
Node-gyp is used to generate the appropriate files needed to build a native node.js add-on.

That’s pretty much it. Next up, we’ll generate a simple native add-on.

Setting up

First, we need to create a folder for the node project, I’m doing this in my home directory :
[crayon-5b76cc0c4ff23018096704/]
Now we need a folder to hold the native module and navigate to it :
[crayon-5b76cc0c4ff29352261826/]
Node-gyp uses a file which specifies the target module name, source files, includes and libraries and other cflags to use when building the module. We need to create that file and call it binding.gyp. It’s contents should look like this :
[crayon-5b76cc0c4ff2f884809583/]
Node-gyp still has some hiccups on Mac OS X and will use only either cc or c++ by default when building (instead of gcc/g++ or whatever you have configured).

Now we use node-gyp to generate the project files :
[crayon-5b76cc0c4ff38498638304/]

The native module

As specified in the binding.gyp file, we now need to create the source file of the native module i.e. src/face-detect.cpp.

Here is the source code for that :
[crayon-5b76cc0c4ff3e301093036/]
 

Basically what this code does is register a method to our module. The method gets the first parameter as a buffer, decodes it to an OpenCV Mat image, detects the faces within the image using the classifier (which should be placed next to the binary), and returns a JSON string containing the coordinates of the faces found in the image.

Now that we have all the pieces in place for the native module, we can build it using :
[crayon-5b76cc0c4ff46896206875/]
If everything goes well, in the folder ./build/Release you should find a file called face-detect.node. This file represents our native module and we should now be able to require it in our javascript files. Also, next to this file, we need to copy the lbpcascade_frontalface.xml from the OpenCV source folder under /data/lbpcascades/.

The Server

Now we have to create the server.js file for the node server. We should load the native add-on for face detection, create a server that will listen to PUT requests and call the native add-on on the contents of these requests. The code for that should look like this :
[crayon-5b76cc0c4ff4c730873031/]
To start the server just run :
[crayon-5b76cc0c4ff53928399101/]

Test it out

Save an image containing human faces as image.jpg. Then, using curl from the command line send the image via a PUT request to the node server like this :
[crayon-5b76cc0c4ff58373914174/]
Depending on the image you send, you should see something like this :
[crayon-5b76cc0c4ff5e360012782/]

Conclusion

Sometimes Node.js libraries might not meet your application needs or they might not fit your machine resulting in errors during npm install. When that happens, you can write your own custom native Node.js add-on to address those needs and hopefully, this article showed you that it’s possible.

As an exercise you can try changing this application to return an image with rectangles surrounding the detected faces. If you’re having trouble returning a new buffer from inside the native add-on, try returning the image as Data URI string.


How To Mock Endpoints in Automated Acceptance Tests

The purpose of acceptance testing is to reproduce production environment as much as possible in order to evaluate the software in a 'real-world' situation similar to what the customers will experience and this includes using real endpoints.

But using real endpoints has some disadvantages. In automated acceptance tests, the endpoint will be stressed out and this is not performance testing. Also, you must use production data (even usernames and passwords) and this is not good because you might break something there. The list with the reasons could go on and on and this is why you should mock some endpoints in automated acceptance tests. Also, you should keep your endpoint's URL stored in environment variables to be able to change it easily (production URL or mock URL).

I will show you some basic examples of mocking endpoints written in Ruby, Python and GO.

Mock endpoint in Ruby

I have used Sinatra (DSL for quickly creating web applications in Ruby) which is very easy to use.

Install the gem:

gem install sinatra
[crayon-5b76cc0c51b0e842962830/]
 

ruby myapp.rb -o 0.0.0.0 -p 5000 > /dev/null 2>&1 &

This will start the process in background and your endpoint on http://localhost:5000.

If you make a GET request on http://localhost:5000/your_username you will get a ‘success’ message, else a 404 status code.

Mock endpoint in Python

In Python it is very easy to create an endpoint with Flask.

To install it you have to run:

pip install flask-restful
[crayon-5b76cc0c51b1a293570534/]
 

As you can see, this does the exact same thing as the endpoint created in Ruby.

You simply run it with

python myapp.py

Mock endpoint in GO

[crayon-5b76cc0c51b21278678169/]
This does the same thing as the previous two endpoints and you run it with:

go run myapp.go

Thanks for reading this. What other ways of mocking an endpoint did you find?


What Is the Difference between QA and QC/Software Testing

If you work in IT or, at least, had any experience in this area, you definitely know that there are multiple terms to define the testing world. The biggest competitors here are QA (Quality Assurance) and QC (Quality Control) which is basically the same as Software Testing.

Let's see how these are defined:


Quality Assurance (QA) is a part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISO 9000]

Quality Control/Testing is a process that consisting of all the life cycles activities, both static and dynamic, concerned with planning, preparing and evaluating software products and related work products. It tries to determine if they satisfy specified requirements in order to demonstrate that they are fit for purpose and to detect defects. [ISTQB glossary]

Quality Assurance

This is about process oriented and preventive activities. It means that these activities are focused on improving the software development process and that the system will meet its objectives. The QA Engineer is active throughout the product’s lifecycle and communicates with all the people involved in the process, from Project Manager to Software Developer and QC Engineer. The QA analyses and seeks the continuous improvement of both process and product while ensuring all tasks demonstrate appropriate quality and that are finished on time.

Quality Control/Software testing

Well, this is about product orientated activities and it is a corrective process (testing is a process rather than a single activity - there are a series of activities involved). The QC Engineer must find bugs in the system before users do, investigate and report on how well the software performs relative to its expectations and is generally active at the end of a coding cycle.

Conclusions

QA and QC both have to make the software better, however, QA is about process orientated and preventive activities, while QC involves a corrective process and product orientated activities.


Usability Rules and Principles for Websites

 

We all now that nowadays there are some well known standards when creating a new web application: it must support a big number of users, no errors on loading, it must be responsive and clear. Beside those, every website must have a user-centered design and to have that, here are some rules and principles for usability.

1. 7+-2 Principle
– there must be 7+-2 elements in a navigation bar

2. 2-Second-Rule
– a user shouldn’t wait more than 2 seconds for a response from the server

3. 3-Click-Rule
– if a user cannot access a site functionality or the information in 3 clicks, he will leave the site (this underlines the necessity of having a clean navigation, a logical structure and a simple to follow site hierarchy)

4. Shneiderman’s rules for design
a. Consistency
– consistent sequences of actions should be requested in similar situations
– the same terminology should be used in prompts, menus, help windows
b. Informative feedback
– for every action there should be a feedback system. For minor and frequent actions the response can be modest, and for major and rare actions, the response should be substantial
c. Closure dialogs
– action sequences should be organized in groups with a beginning, middle and an end
d. Easy handling of errors
– the user shouldn’t be allowed to make serious errors
– if an error is produced, the system should be able to detect it and to offer an easy to understand mechanism for treating it
e. The system should permit action canceling

5. Banner-Blindness
– users tend to ignore colored and animated banners, same for other graphic elements
– the focus is moved to the text and hyperlinks

6. Users should be allowed to test a functionality without authentication
– to continue using the functionality, users would be more than happy to fill in a form

7. Registration form
– filling should last about 30 seconds
– if there are too many fields and the user must scroll, horizontal alignment can be a solution
– [Labels] because the forms are vertically oriented (users fill the form from top to bottom), the input label is indicated to be placed above
– [Search box] the ideal width of a search box is 27 characters
– ‘Submit’ button should be either left aligned or centered
– it's better not to name a submit type button “Submit”, but the actual action that is done when the form is sent, for example: 'Create Account', 'Subscribe Now', 'Send Message', 'Register Free'

8. Text
– it's appropriate to use within 3 typefaces in three sizes
– for a natural result you can choose the font size value for the body from the Fibonacci series (16-24-40-64-104)

I hope these rules help you become a better web developer! Good luck :)


How to Show the Full Path in the OS X Terminal

Working and constantly switching between multiple projects in the OS X Terminal or iTerm (whatever you prefer) can be hassle since, by default, you cannot see the full path of the directory you're working in. Here's how to change that.

 

But first, in the spirit of full disclosure, I'd like to mention that I only found out how to display the full path after I accidentally destroyed the virtual machine of the wrong project and I had to install the whole damn thing all over again.

 

As you might have noticed, the Terminal only displays the current folder in which you're working so it can be pretty easy to make a mistake when your projects have a similar folder structure or are built with the same framework.

 

This first thing you need to do to address that is to fire up your Terminal and open your .bash_profile file:
[crayon-5b76cc0c55052182751046/]
Then head over to a new line and add:
[crayon-5b76cc0c5505d953979870/]
Save and close the file, then restart your Terminal. You should now notice that when you browse through your directories, the path should look something like this:
[crayon-5b76cc0c55063436142485/]
The \w symbol you noticed stands for "Current working directory, full path (ie: /Users/Admin/Desktop)" while the $ mark followed by a space is simply a separator between the working path and the input area.

 

If you want to make the Terminal look even more awesome, here are some other options you can add to PS1:
[crayon-5b76cc0c55069697997056/]
So for, example, using PS1="\u@\w$ " will output "Sebi@~/Development$ ".

I really hope this small tutorial helped. Have fun!