Archive for the ‘ JavaScript ’ Category

NodeJS Loopback

Looks very promising, I think I will give it a try these days.

Wonderful new world of nodejs!

About LoopBack.IO

  • Use the CLI to generate REST APIs
  • Connect devices and browsers to data and services
  • Open Source and extensible

Set up models and create REST APIs in minutes

  • Easy-to-use CLI wizard
  • Create models based on your schema if you have one
  • Create dynamic models if you don’t
  • Built-in API Explorer

Model relation support

  • Define hasMany, belongsTo, hasAndBelongsToMany relationships
  • Automatically generates corresponding REST endpoints

Easy authentication and authorization setup

  • Built-in role-based access controls
  • oAuth user and registration models baked in
  • Add custom policies using CLI or JSON
  • Browser support (JSONP and CORS)

MIT open-source license

Client SDKs

Native Mobile and Browser SDKs

  • Easily persist data with a database API on the client
  • Store files, send push notifications, and call custom server-side code
  • Android / Java
  • iOS
  • Browser JavaScript (Angular)


Connect to backend data stores

  • MySQL, Oracle, MongoDB, and others
  • Other REST services
  • Discovery APIs for Oracle and MySQL

Run ad-hoc queries

  • Run dynamic queries on devices, browsers and the server
  • Support for NoSQL-style queries against relational databases

Mobile Services

Send push notifications

  • Backend push system with simple API calls
  • Supports both Android and iOS


  • Validate and store geolocations
  • Find nearby results with geo filters

Webstorm / PHPStorm get basic Ruby syntax highlighting

It is possible to get the basic syntax highlighting for Ruby files in PhpStorm using the TextMate bundles support plug-in. It’s already included with Webstorm and you don’t need to install it, just make sure it’s enabled in Settings | Plugins.

  1. Git clone Ruby.tmbundle into some directory.
  2. Add this directory in Settings | TextMate Bundles:

Ruby bundle

For older versions of Webstorm TextMate Bundles support will not recognize *.rb files as supported by this bundle. To fix this problem open the file ‘Ruby.tmbundle\Syntaxes\Ruby.plist’ in some text editor, find ‘<key>fileTypes</key>’ section, add ‘<string>rb</string>’ under ‘<array>’

Restart Webstorm, verify that *.rb is now associated correctly:


Now you get Ruby syntax highlighting in Webstorm:

Ruby syntax

via php – Is it possible to get Ruby syntax highlighting in PHPStorm? – Stack Overflow.

7 tips for a Node.js

7 tips for a Node.js padawan

Or stuff I wish I knew when I started.

Logo nodejs

Node.js development is extremely fun and satisfying. There are over 35k modules to choose from, and overall node is very easy to develop a working application that can scale easily.

However for developers just starting off with Node.js development, there are a few bumps along the road. In this short post I cover a few of the things I questioned and ran into while learning Node.js.


Tip 1: Use nodemon for development. pm2 for production.

When you first get started with Node.js development, one of the things that will stick out like a sore thumb is having to run node [file].js over and over again. When I got started with node, this was extremely frustrating and painful. Especially having to control C every time I modified something.

Luckily I discovered a great tool called Nodemon
Install it by:

running npm install -g nodemon

Nodemon is an awesome tool, once you install it globally you can run your node.js scripts via:

nodemon [file].js

Doing so will tell nodemon to monitor your script and all the scripts that it depends on for changes. This is an awesome way to do Node.js development and speeds everything up.

What about production? Unless you are using Heroku, Nodejitsu or other great Node.js hosting providers, chances are you will be using EC2 or another cloud provider to run your Node.js app. How do you properly run a Node.js app to make sure it’s always running?

The answer to that question is a great tool called PM2 PM2 is a tool like nodemon which is intended to run your node app in production. Like Nodemon it will monitor your app for changes and redeploy them, but unlike Nodemon, if PM2 encounters a crash, it will restart your node.js app right away.

Where PM2 excels though is when you need to scale your app to multiple cores. PM2 comes with a built in “load balancer” that lets you easily specify how many instances of your Node app to run.

pm2 start app.js -i max

The -i parameters lets you specify how many instances to run, in this case PM2 comes with a built in constant called max which auto scales your app to the amoutn of cores you have. Remember Node runs only on one core!


Tip 2: Async or Q

The more you start to write node.js apps, the sooner you’ll realize the pain of callback hell. If you don’t know what callback hell is, here is an example:

function register(name, password, cb){
    checkIfNameExists(name, function(err, result){
            return cb(“error”);
        checkIfPasswordGood(password, function(err, result){
                return cb(“error”);
            createAccount(name,password, function(err,result){
                    return cb(“error”);
                createBlog(name, function(err, result){
                    sendEmail(name, function(err, result){

While not a very useful or amazing block of code, it should get the point across that callback hell is a very real thing. But how do you avoid this?

One simple way is to use events. I personally don’t like using events because then you are using events to call private functions which have only one purpose, which defeats the point of a function.

How do you do this then? There are two competing libraries out there, async.js and Q. Both offer their own take on how callback hell should be prevents.

Async.js or “async” allows you to easily execute functions in series or parallel without the need of nesting them back to back.

Below are some of the patterns that Async supports taken from their readme. For a list of all the patterns async supports check out their repo.[‘file1',’file2',’file3'], fs.stat, function(err, results){
// results is now an array of stats for each file
async.filter([‘file1',’file2',’file3'], fs.exists, function(results){
// results now equals an array of the existing files
], callback);
        callback(null, ‘one’, ‘two’);
    function(arg1, arg2, callback){
        callback(null, ‘three’);
    function(arg1, callback){
        // arg1 now equals ‘three’
        callback(null, ‘done’);
], function (err, result) {
    // result now equals ‘done’

If we take what we did previously with register, we can apply the waterfall pattern in async. The result of this is a very readable code pattern that doesn’t involve the pyramid of doom.

Another great library is Q This library is exposes the concept of promises. A promise is basically an object that is returned from a method with the “promise” that it will eventually provide a return value. This ties is very neatly with the asynchronous nature of javascript and node.js.

For example, taken from Q’s repo page.

    .then(function (value) {
    }, function (reason) {

The promise me function returns an object right away. Calling then on the object will call the function you pass in with the value you want returned. Then also takes an additional callback which is run when the object fails to return the value.

This is a very neat way to avoid the insanity of callback hell. If we take our registration example, you can easily make it so that each of those functions is called when then is executed.

    .then(function (result) {
        // Do something with the result
    .catch(function (error) {
        // Handle any error from all above steps

As I said previously, I dislike creating single purpose functions. Instead of passing in the function name to “then”, I would just create an anonymous inner function and pass that in, however the choice is yours.

In summary, if you start to realize you’re creating callback hell for yourself then it’s time to look into async.js or Q.


Tip 3: Debugging Node.js apps easily

Debugging Node.js apps will be confusing if you are coming from a language with heavy IDE integration like Java or C#. Most new node developers adopt the “flow” debugging pattern, where your best friend becomes console.log.

However there are still alternatives that are more convention to debugging. Node.js comes with a built in debugger that you can run by calling node debug, however the one I love is node-inspector.

Taken from their github repo “Node Inspector is a debugger interface for node.js using the Blink Developer Tools (former WebKit Web Inspector).”

In a nutshell node-inspector lets you debug your applications using whatever editor of your choice and chrome web tools. That is sexy.

Node-inspector lets you do some really cool things like live code changing, step debugging, scope injection and a bunch of other cool stuff.

It’s bit involved to setup, so I’ll let you follow the instructions over at


Tip 4: Nodefly

Once you have your application up and running, you might ask yourself how you could monitor it’s performance and profile it to make sure your app is running at optimum speed. The simplest answer to that is a great service I use called Nodefly.

Nodefly with a simple line of code starts to monitor your application for memory leaks, measure how long it takes for redis, mongo queries and a bunch of other cool stuff.


Tip 5: Module management with NPM.

One of the most common things to do in node is installing packages via NPM. Node has an amazing package manager which installs all the modules specified in your package.json manifest file. However one thing all beginers run into is keeping this package.json file updated with all the modules you are using.

It seems like a pain to always be opening your package.json to update the dependcies property with the new module you just installed, but what many don’t know is npm will do this for you!

Simple run npm install — save module_name and npm will automaticly update your package.json with the correct module and version name. npm install —save module_name


Tip 6: Don’t check in your node_modules folder

While we are on the topic of modules and npm, not many know that you shouldn’t check in your node_modules folder. The biggest reason behind this is there is no need for you to check this folder in. Whenever someone checks your source out they can just run npm install and download all the modules required.

You might say that it’s not a big deal if you check in node_modules, but what if the person checking out your source is using an operating system other than yours and one of the modules that your app uses is compiled when it’s installed via npm? Your app will crash and the person that checked out your source will have no idea why!

For example modules like bcrypt and sentimental are compiled on the host system when you install them because they have native components written in C.

The best way to avoid checking in your node_modules folder is by adding it to .gitignore.

// .gitignore node_modules/*


Tip 7: Don’t forget to return

A common mistake made by all early node developers is forgetting to return after a callback. While some times this has no implications, there are many times where you’ll run into odd issues because your callback is being called twice.

Lets take a look at a quick example

function do(err,result, callback){

At first glance, this snippet makes sense. If there is an error, send “error” in the callback, if not send good. But calling the callaback is not stopping the method from completing the execution. It will just move on to calling callback(“good”).

Inside long and complex lines of code, doing this will save you hours and hours of debugging.

Node.js is great platform to develop on. If you keep these 7 things in mind while developing, debugging and deploying to production you can save your time and prevent your hair from graying out.