gulp.watch High CPU Usage

I noticed frequent slowdowns on my new work PC with Windows 10, an i7 and 16GB of RAM, and opened up Task Manager to see what could possibly have been slowing everything down. To my surprise, I found that the node process was hogging between 25 and 50 percent of CPU while it was running. When developing our frontend application, I run an Express server and several gulp.watch tasks to trigger a build whenever a .scss, .html or .js file in the project is changed. Here is ascreenshot of the process on the lower end of CPU utilization:

gulp.watch High CPU Usage before optimization

Since Express shouldn’t be taking up that many resources for our use case, I narrowed it down to gulp.watch high CPU usage. I looked around and found this GitHub issue in which a user called shama suggested that the interval for the watch tasks should be set higher than the default of 100ms. I set mine to 750ms and the CPU usage dipped dramatically, from a constant 25-50% to a much lower 6-12% as demonstrated below:

gulp.watch High CPU Usage after optimization

The interval must be passed as the second argument to a watch task, and your gulp.watch high CPU usage woes should be banished!

gulp.watch('src/**/*.js',  { interval: 750 }, function(event) {
  // watch code here
}

Changes to NPM’s Unpublish Policy

Today NPM has made some important changes to their unpublish policy to avoid embarrassing fiascos like the one last week. You can read about the new policy here:

http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy

These changes are clearly a step in the right direction and should prevent an individual from breaking the entire NPM ecosystem by removing a package that is depended on by many others. Especially the rules that you cannot unpublish a module greater than 24 hours old without contacting NPM support, and the affirmation that NPM will not unpublish packages that are depended upon by other projects.

I’ve already started to see some people complaining that NPM === dictators now because they have more control over your packages. To me, this complaint is a crock of shit. If you publish a package to NPM with a reasonable assumption that other people will depend on the package then it would be selfish for you to assume that you can just pull the rug out from under the community any time you want. That’s how we end up with dramas like the one last week. It’s not in the spirit of open source and it’s not in the interests of the community for individuals to be able to do that.

For an extreme example, let’s say the author of a popular project like lodash or Babel decides one day to set up a patreon account, delete their package from NPM and then demand a payment of $5000 to republish the package. Effectively, they would be holding the community hostage. Sure NPM could just transfer ownership of their account or republish the module, but it would cause another day of catastrophe and fragmentation for developers everywhere that depend on the module that may end up causing a lot more than $5000 damage in lost productivity.

There are many mitigating strategies you can use to prevent things like this from happening, like privately hosting a copy of the package in your company, but the best course of action is to take more control like NPM has done. I commend their actions and changes to their unpublish policy. They are moving the node and JavaScript communities forward, and I look forward to seeing what other improvements they bring to the table.

NPM Drama

Okay, I’m sure we’ve all seen the npm drama that’s gone down in the past week. Azer had a npm module called left-pad, an 11 line function as a module that should have been in the JavaScript standard library. He also had a module called kik, which clashed with the messaging company Kik’s plans to make their own fancy npm module. So Kik went into

lwyrup

mode which didn’t go over well with Azer, so when they asked if he would change his module name to something else to appease their trademark he was all

and NPM got involved. And like any company would they bent over backwards for Kik and the lawyers and removed kik (the module) from NPM. Then Azer ragequit and removed all of his ~200 modules from npm. Which broke the internet even more effectively than Kim Kardashians big ass (NSFW).

Libraries like Babel and React Native were unable to build at all, which stalled them from making new releases, all because of this 11 lines of code that should have been a) in the standard library or b) included in a npm string utility module, not as some silly standalone function. The code in question:

module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

There are a lot of examples of this in npm such as the brilliant one-liners and small functions like is-positive-integer, positive-zero, isArray and is-thirteen (okay that one was made up after all this stuff went down).

I get the idea of small modules of reusable code, really I do, but this one function stuff is kind of crazy when you think about it. The more dependencies you add to your project, the more can go wrong. As babel et. al. found out the other day. If you are going to add more dependencies to your project you should be sure that it’s worth it by checking out the source code, how many issues the project has, and how many recent commits it’s had. And if it would really be that worthwile to include 11 lines of code instead of using something like…

lodash

Go check out lodash if you haven’t already, seriously. It is one of the most used NPM modules and contains utility functions for just about everything that you could ever want. It’s well maintained and tested, and if you are worried about file size you can include individual functions from lodash instead of the whole project. It even includes padStart!

So, there’s my 2c on the issue, as everyone else is putting in right now. Feel free to call me out for being a quack!

Dr._Riviera

I’m Back

Unbeknownst to me my site was down for 7 days with the message “Error establishing a database connection.”. This occurs when the mysql service crashes on the server. I currently have no way to get notified of this, so any tips on how to do so on a DigitalOcean droplet would be great! The command used to get the mysql service up and running again is:

sudo service mysql restart

ES7 Decorators

I read a fantastic article the other day by Addy Osmani, who among other things created Yeoman, TodoMVC, Material Design Lite, and who works at Google on Chrome and Polymer. The article was what we can expect from ES7 Decorators, which can be found below:

Exploring ES7 Decorators by Addy Osmani

You should definitely read the article because it is a succinct and clear explanation of decorators and what you would use them for. They are available to use now in both Babel, though not at the time of writing in Traceur. Generators along with other languages features like async/await, are major additions to JavaScript that should be coming along next year, so you should read up on them now! This article is just a quick summary of Addy’s with some different examples of what you can use decorators for.

You can check out the examples presented in this article in the online Babel REPL, as long as you check the “Experimental” checkbox. You can then run the generated result in something like JSFiddle.

So, what’s a decorator?

A decorator, put simply, is a function that can transparently wrap another function, class or property to provide extra functionality. Here’s what one might look like, from Addy’s article, a readonly decorator that prevents a class property from being overridden.

// decorators.js
function readonly(target, key, descriptor) {
  descriptor.writable = false;
  return descriptor;
}

export default { readonly }

// person.js
import { readonly } from 'decorators';

class Martin {
  @readonly
  dateOfBirth = '1990-09-25';
}

The @readonly declaration above the dateOfBirth property is how you would use the decorator, which in this case I’ve defined in another file. Let’s have a look at what happens if we try and write to the property:

let me = new Martin();
me.dateOfBirth = new Date();

// Exception: Attempted to assign to readonly property

You can see that you get target, key and descriptor method parameters in your decorator function. They each target different things and have their own properties:

  • target – The class that the decorator is used on.
  • key – If using the decorator on a property, this is the name of the property.
  • descriptor – Contains the properties value, enumerable, configurable, and writable for the property/function.

You can also define your decorator as a factory, so you can pass extra parameters into the decorator function. This can be used to do things like attach extra properties to a class. For example:

function gang(name, location) {
  return function(target) {
    target.name = name;
    target.location = location;
  }
}

@gang('The Warriors', 'Coney Island');
class Group() {}

@gang('The Riffs', 'Gramercy Park');
class Group() {}

@gang('Turnbull ACs', 'Gunhill');
class Group() {}

Thoughts

I don’t know about you but I’m getting really excited about using decorators. They remind me of Attributes in C#, which I’ve used a lot before when writing REST APIs in .NET. I think they have massive potential in large frontend applications to tightly implement security functionality. For example, if you don’t want someone making certain API calls via the frontend (you should also apply the same rules on the API) you could do something like this:

function adminOnly(user) {
  return function(target) {
    if (!user.isAdmin) {
      toast.error('You do not have sufficient privileges for this area!');
      return false;
    }
  }
}

@adminOnly(app.identity.currentUser)
function deleteAllUsers() {
  app.api.users.delete().then((response) => {
    toast.success('Yay you deleted everyone!');
  });
}

Granted this is an extremely basic example that skips around things like Dependency Injection (if you’re using Angular) or ES6 import statements. I’ll be writing an article where I explore how decorators can be used with Angular in the future. What’s more important is the recognition of the power that decorators bring to JavaScript, and that they are something you should be keeping an eye on as ES7 is developed further and comes closer to release.

If you thought ES6 was good, ES7 is really exciting! Check it out!

Duration Parsing Using Juration

I’ve been working a lot with appointments and calendaring lately, and one of the requirements to create a new appointment was to have a duration parsing input that was easy to use. One that would let the user input combinations like 1h 10m or 3h or 25mins. It didn’t take me long to find Juration.

It’s a simple little library, only 2.6kb minified that does one thing and does it well, and it was exactly what I needed. For the string inputs, juration will return the equivalent number of seconds, which you can then determine the hours, minutes and seconds from. For example:

juration.parse('1h 30m');
// 5400

Juration also works the other way, you can give it a number of seconds and a formatting option and it will output the string representation, for example:

juration.stringify(5400, { format: 'long' });
// 1 hour 30 minutes

Juration parses anything from seconds up to years and is a simple, elegant solution for parsing duration inputs.

Angular Directive Isolate Scope Explained

I’ve written a lot of directives this year, and one of the best ways to learn the ins and outs of Angular is to write a lot of isolated directives with lots of different options. One thing I’ve still felt myself occasionally struggling with is the isolate scope on the directive definition object. Not the concept of the isolate scope, but just what in the hell the difference between all the little symbols you can use is. I aim to explain the difference between these symbols because there are some important things to know about them.

(more…)

A Review

Over the next week or so I’m going to be blowing out the cobwebs of this blog so to speak, in a review, because I’ve been neglecting it quite a bit and I want it to be a better platform for my tech writing. I’m aiming to:

  • Rewrite the theme (again) for an easier to read and navigate blog, including the return of syntax highlighting. I’d previously converted about half of my code samples to use gists but I am going to go back to using a syntax highlighter (probably prism or highlight.js) to reduce load.
  • Go through old posts and put disclaimers on those that are old and probably no longer valid, or have misleading information. I may just implement a flag for posts to display this warning so  I don’t have to do it manually.
  • Speed up the performance of my site. If anyone has any tips on speeding up WordPress I’m all ears, I’ve tried to do a lot of things but they don’t seem to work for long. I may end up upgrading to a larger digitalocean droplet.

Apart from that, I aim to come up with more articles more frequently, a lot about JavaScript since that is what I’m primarily working with now. Thanks for reading, the changes will be coming soon.

‘this’ is not allowed before super

I recently decided to try Babel out as a build system for work in place of Traceur. Along the way I found a spec-compliance issue in much of our ES6 Angular codebase. We have several main classes that other classes inherit common functionality from, for example a Model, Collection and Table class. These classes use dependency injection, naturally, because they are being used to write an Angular application.

To initialize the parent class and inject dependencies we were using the $injector.invoke() call on the child class like so:

// parent
class Collection {
  constructor($thingToBeInjected, Model) {
    this.Model = Model;
  }
}

// child
import Collection from './Collection';

class PeopleFactory {
  constructor() {
    class People extends Collection {
      constructor($injector, Person) {
        $injector.invoke(super.constructor, this, {
          Model: Person
        });
      }
    }
    
    People.$inject = ['$injector', 'Person']
    
    return People;
  }
}

export default PeopleFactory;

This was not a problem for us on Traceur v0.0.79 but as soon as I tried to run code like this through Babel it crashed and burned. The error I was getting was either:

'this' is not allowed before super()

or

'super property' is not allowed before super()

Both mean similar things. Basically, the older version of Traceur that we were using was not as spec-compliant as it should have been whereas the brand new Babel version I was using was. I checked it out on the latest version of Traceur and the exact same error came up.

In the spec, if you are extending a class you must call the super() method before accessing either this or a property of super e.g. super.constructor. The reasoning behind this is that technically JavaScript doesn’t know what this is until you call the superclass. Yehuda Katz gives a really great explanation of it on another similar babel.js issue.

I found all of this out by filing an error in the Babel repo at ‘this’ is not allowed before super() for AngularJS $injector.invoke() calls #1582. I got a quick reply from sebmck telling me that I was using a very old Traceur if this actually worked, and that this is the expected behaviour of the spec, which led me in the right direction.

Turns out sebmck had actually caused this issue to be fixed in the Traceur compiler too, as seen in the issue https://github.com/google/traceur-compiler/issues/1797.

So…how can we fix this?

As I mentioned this was all over our entire application so I had to spend an arduous couple of days fixing it. The solution was simple, but the find and replace was the most time consuming. Thankfully I had Johnny Cash’s At Folsom Prison album to keep my company while I worked. Here is what I needed to do – instead of importing the superclasses I made them into Angular factories and injected them into the child class that way. Here is what the class definitions looked after extensive rework.

// parent
class CollectionFactory {
  constructor($thingToBeInjected) {
    class Collection {
      constructor(Model) {
        this.Model = Model;
      }
    }
    
    return Collection;
  }
}

CollectionFactory.$inject = ['$thingToBeInjected'];

// child
class PeopleFactory {
  constructor(Collection) {
    class People extends Collection {
      constructor(Person) {
        super(Person);
      }
    }
    
    People.$inject = ['Person'];
    
    return People;
  }
}

export default PeopleFactory;

Notice that I moved $thingToBeInjected into the factory definition constructor, and I’m just returning the Collection class from the factory without initializing it. This leaves the subclass free to inject and extend it without importing it.

After replacing all of the $injector.invoke() calls and creating factories for our common classes the build went off without any hitches in the newest versions of Traceur and Babel!

Using $q.all() to Resolve Multiple Promises

If you have a lot of promises in Angular that need to be run sequentially, you can go about it in one of two ways. There is the classic way of chaining callback functions together to achieve the desired result. Assume that all of the functions in the example below follow this format:

function promiseX() {
    let deferred = $q.defer();
    
    ajaxCall().then((response) => {
        deferred.resolve(response);
    }, (error) => {
        deferred.reject(error);
    });
    
    return deferred.promise;
}

Consider the way of callback chaining your promise results.

let values = [];
promiseAlpha().then((val1) => {
    values.push(val1);
    promiseBeta().then((val2) => {
        values.push(val2);
        promiseGamma().then((val3) => {
            values.push(val3);
            complete();
        });
    });
});

This, as you can see, is not very pretty at all, and will make it difficult to a) get the resolved value of each promise and use it and b) chain more than a few promises without pulling your hair right out of its sockets. Thankfully there is an alternative in the form of $q.all().

The $q.all() method takes either an object or an array of promises and waits for all of them to resolve() or one of them to reject() and then executes the provided callback function. The values returned from the resolve function are provided depending on the way you give the promises to all().

If you provide them as an array, then the values will be available as an array with the same corresponding order of the promises array. For example:

let promises = [promiseAlpha(), promiseBeta(), promiseGamma()];

$q.all(promises).then((values) => {
    console.log(values[0]); // value alpha
    console.log(values[1]); // value beta
    console.log(values[2]); // value gamma
    
    complete();
});

However if you provide an object literal to all(), the values are attached to an object with the same corresponding property names in the all() callback. I find this way a lot easier because in most (but not all) cases you will have a set number of promises to complete.

let promises = {
    alpha: promiseAlpha(),
    beta: promiseBeta(),
    gamma: promiseGamma()
}
$q.all(promises).then((values) => {
    console.log(values.alpha); // value alpha
    console.log(values.beta); // value beta
    console.log(values.gamma); // value gamma
    
    complete();
});

This article comes out of a situation where I had to match values against ids from lists returned from an API, where the list data was not preloaded. As you can see, $q.all() becomes a very useful and much shorter way of chaining promise resolve()s than callback chaining.