Lithium Labs Visualization Components, The Zen Approach

21 Mar 2014 | By Alex Young | Comments | Tags d3 graphics style-guides

Lithium Labs Visualization Components

Sentiment Wave

Recently I’ve been looking for D3 libraries, and coincidentally Jack Herrington sent in Lithium Labs Visualization Components (GitHub: lithiumtech / li-visualizations, License: Apache 2.0, Bower: li-visualizations). This is a set of D3 visualisations, including Sentiment Wave, Reticule, and Elegant Waves.

It includes some examples written in CoffeeScript and an example application that you can try out locally with preloaded data.

The Zen Approach

The Zen Approach by Nijikokun is a JavaScript style guide. It’s detailed and instructive, so it may work well as a beginner’s guide if you’re looking for documentation that will get existing programmers up to speed with modern JavaScript.

Multiline

Judgement call, the slowest known method is [].join. If you are building something that requires high performance do not use [].join. It’s not bad, it’s just not performant. The two fastest methods of multiline are one-line strings (no breaks), and in second using the \ character (breaks), with + (concat) trailing slightly behind. I’ll let hard data back me up on this. My personal preference is to use one line for performance (word-wrap exists people), and then [].join for non-performant things, like variables and such. Should the line require variables and need to be performant I will use + concat notation.

The author hints that it may become a book, series of talks, or an open source handout – it’s currently MIT licensed.

jspm.io

20 Mar 2014 | By Alex Young | Comments | Tags node npm modules

jspm.io

jspm.io (GitHub: jspm / jspm-cli, License: Apache 2.0, npm: jspm) by Guy Bedford is a browser package manager that supports the ES6, AMD, and CommonJS module formats. It uses SystemJS to load modules based on the ES6 module loader specification.

Loading modules in browsers looks like this:

// a specific module from the latest version of an npm package:
System.import('npm:lodash-node/modern/collections').then(function(collections) {
  collections.max([1,2,3,4]); // 4
});

// a semver-compatible version of jquery:
System.import('github:components/jquery@^2.0.3').then(function($) {
});

Notice that it allows modules to be loaded based on semantic version numbers – you can use it to load modules from a CDN this way, or on the command-line: jspm install npm:lodash-node jquery@^2.0.3.

The design of the API means you can use ES6 modules now, but still get the benefits of a Node-powered command-line tool for quickly downloading and building local bundles.

It has its own registry, so naturally the author is looking for pull requests to get new modules listed. The current registries use SPDY, which has some advantages for a module loading system. Once you’re ready to roll out projects to production, you can use the jspm command-line tool to inject package configuration and specific versions of the dependencies.

Node Roundup: cipherhub, slate, express-di

19 Mar 2014 | By Alex Young | Comments | Tags node npm modules

cipherhub

Cipherhub

Cipherhub (GitHub: substack / cipherhub, License: MIT, npm: cipherhub) by substack is a module for encrypting messages based on GitHub public keys.

The usage is simple: npm install -g cipherhub and then cipherhub USERNAME {OPTIONS} < message.txt.

If there are multiple keys for the user, then you’ll need to add a specific key with cipherhub --add USERNAME < id_rsa.pub.

slate

Slate

Slate is a new IRC client by TJ Holowaychuk that uses node-webkit. It’s a native client in a similar spirit to GitHub’s Atom.

TJ notes that the project started as a small hack that he intended to expand into a Kickstarter project, but he’s released it as an open source project instead.

Conceptually I really just wanted a clean, minimalistic IRC client, completely extensible through plugins. Ideally most of the core is written using such plugins. The entire thing should be themable, and the default theme should be programmer-friendly, aka get all the clutter out of my way, I just want to see chat logs.

I’m making a collection of Node-powered native apps, so send those in if you’re working on them.

express-di

If you’ve got addicted to dependency injection through AngularJS, then you might be interested in Express-di (GitHub: luin / express-di, License: MIT, npm: express-di) by Zihua Li:

var express = require('express');
// Require express-di
require('express-di');
var app = express();

app.factory('people1', function(req, res, next) {
  next(null, { name: "Bob" });
});

app.factory('people2', function(req, res, next) {
  next(null, { name: "Jeff" });
});

app.get('/', function(people1, people2, res) {
  res.json({
    people1: people1,
    people2: people2
  });
});

require('http').createServer(app).listen(3008);

The app.factory method is used to define a dependency, and req, res, and next are handled as default dependencies.

JScrambler

18 Mar 2014 | By Ricardo Martins | Comments | Tags sponsored-content obfuscation services
JScrambler.

Well-known libraries such as Google Closure, YUI compressor or UglifyJS minify, compress and optimize JavaScript. The techniques they use can be collectively referred to as JavaScript optimization. They are great at improving overall page load speed, but fall short if you are interested in protecting your source code from code theft and reuse, tampering, or reverse engineering.

Despite that, optimized code is often confused with obfuscated code. For example, compressed code is completely encoded, which at first glance may seem to be highly obfuscated, but a simple run is often enough to retrieve something very similar to the original code. In short, these tools do a good job optimizing your code, but they don’t protect it. (fiddle: demo, Google Compiler optimized demo and beautified optimized demo).

JScrambler goes beyond these libraries by offering advanced obfuscation (JScrambler obfuscated version) that can protect your code. It leverages obfuscation by inserting a number of different code traps to control execution and to enforce licensing. For example, you can lock the code to a list of predefined domains. If someone tries to execute the code elsewhere, the code breaks.

JScrambler just released a new version (3.5) that takes protection even more seriously. It introduces a completely new technique that provides JavaScript files with self-defending capabilities by installing a combination of anti-tampering and anti-debugging. If you try to change a single character, the code will react by breaking down intentionally (try it on JScrambler self-defending demo). It also adds new code traps to restrict execution to a certain Browser or OS, code blocks to give the developer the ability to enable/disable individual source code transformations in certain parts of the code.

There are lots of reasons why you may want to protect your code. People might try to steal your code to reuse it, perhaps to build a similar product, or to replicate a similar user experience. You may have secret algorithms or keys hidden in the code that may be easily recovered by inspecting your code. If you are selling your app, you may be worried about piracy. JavaScript can be easily copied and executed, without your authorization. And last but not least, there are all sorts of security risks, like people figuring out ways to interfere with your code, to commit fraud, or to steal data – from you, or from your users. JScrambler goes along way to combating these problems, despite the fact that there are no bulletproof solutions.

As expected, these techniques have a cost in file size and execution, but because JScrambler also has optimization features, this extra cost can be controlled – as proven by running the two protected demos. You don’t have to give up performance to get protection.

JScrambler’s web interface is simple and easy to use. In five minutes you can get your application protected. You upload the source, click a button, then wait a few seconds and download the results. JScrambler provides templates that were designed to work out of the box in most cases. It includes all sorts of JavaScript-based applications, including HTML5 Canvas, Node.js, Windows 8 WinJS Apps, etc. If you want to automate your builds, an API is also provided, and few ready to use clients, including a Node grunt task.

For more examples, see the full set on jscrambler.com.

picturePolyfill, Interfake

17 Mar 2014 | By Alex Young | Comments | Tags json node modules html5 polyfills

picturePolyfill

picturePolyfill (GitHub: verlok / picturePolyfill, License: MIT/GPL2) by Andrea Verlicchi allows you to use picture elements with srcset support so you can include high-DPI images. Here’s an example with media queries:

<picture data-alt="A beautiful responsive image" data-default-src="img/1440x1440.gif">
  <source src="img/480x480.gif"/>
  <source src="img/768x768.gif"   media="(min-width: 481px)"/>
  <source src="img/1440x1440.gif" media="(min-width: 1025px)"/>
  <source src="img/1920x1920.gif" media="(min-width: 1441px)"/>
  <noscript>
    <img src="img/768x768.gif" alt="A beautiful responsive image"/>
  </noscript>
</picture>

It doesn’t make multiple HTTP requests, so only the required images are fetched. It also takes into account browser event handling, so it won’t run while the browser is being resized.

Interfake

Interfake (GitHub: basicallydan / interfake, License: MIT, npm: interfake) by Daniel Hough is a module designed for client-side developers that makes it easy to create JSON APIs. You can create APIs using the command-line interface by making JSON files that define endpoints:

[{
  "request": {
    "url": "/whattimeisit",
    "method": "get"
  },
  "response": {
    "code": 200,
    "body": {
      "theTime": "Adventure Time!",
      "starring": [
        "Finn",
        "Jake"
      ],
      "location": "ooo"
    }
  }
}]

It supports JSONP, and you can use it programmatically in Node. The documentation has some use-case ideas, like using it for a test API for a mobile application, automated testing, and static APIs.

Rendering Large Terrain in WebGL

14 Mar 2014 | By Alex Young | Comments | Tags webgl graphics

Rendering large terrains by Felix Palmer is a tutorial that demonstrates how to render terrain with a variable level of detail. There’s a demo and the source is on GitHub. It’s built with three.js, and is based on a paper on level-of-detail distribution.

Terrain

A simple way to do better is to split our plane into tiles of differing sizes, but of constant vertex count. So for example, each tile contains 64×64 vertices, but sometimes these vertices are stretched over an area corresponding to a large distant area, while for nearby areas, the tiles are smaller.

The code uses GLSL, but the main app/ JavaScript code is all neatly organised with RequireJS, so it’s surprisingly easy to navigate and understand. The tutorial blog post also makes some of these difficult ideas more accessible, so I thoroughly recommend checking it out.

Multiline strings in JavaScript

13 Mar 2014 | By Alex Young | Comments | Tags es6 hacks

Multiline (GitHub: sindresorhus / multiline, License: MIT, npm: multiline) by Sindre Sorhus is a clever hack that allows you to write multiline strings by using a callback to wrap around a comment:

var str = multiline(function(){/*
<!doctype html>
<html>
    <body>
        <h1>❤ unicorns</h1>
    </body>
</html>
*/});

This works by calling .toString() on the callback, then running a regular expression to extract the comment: /\/\*!?(?:\@preserve)?\s*(?:\r\n|\n)([\s\S]*?)(?:\r\n|\n)\s*\*\//.

Although this is a hack, I hadn’t thought about it before. Sindre notes that this has a performance impact, but that sometimes it might be worth writing things this way for the added clarity it brings.

EcmaScript 6 will introduce template strings, which can be used for multiline strings and interpolation with ${}:

A template string uses back ticks instead of double quotes or single quotes. The template string can contain place holders, which use the ${ } syntax. The value of the expressions in the place holders as well as the text between them gets passed to a function. This function is determined on the expression before the template string. If there is no expression before the template string the default template string is used.

Node Roundup: 0.11.12, Metalsmith, Promises and Error Handling

12 Mar 2014 | By Alex Young | Comments | Tags node modules npm promises generators
Job ad: Iridize is looking for a lead frontend developer.

Node 0.11.12

Node 0.11.12 is out. It updates uv, some of Node’s C++ code in src/, and several core modules including cluster and net.

One commit that caught my attention was buffer: allow toString to accept Infinity for end by Brian White. He said he sometimes sets INSPECT_MAX_BYTES to Infinity, allowing the buffer’s contents to be printed for debugging purposes. I think it’s interesting that this works, even though it’s not something I’d usually want to do.

Metalsmith

Ian Storm Taylor sent in Metalsmith, a really cool static site generator by Segment.io. Why is it cool? Well, they had me at the entirely plugin-based API that uses chainable calls:

Metalsmith(__dirname)
  .use(drafts())
  .use(markdown())
  .use(permalinks('posts/:title'))
  .use(templates('handlebars'))
  .build();

Promises and Error Handling

Promises and Error Handling by Jon Merrifield is all about error handling with promises in Node. It has guidelines for using promises safely, including the idea that you should reject rather than throw and how to terminate chains early and safely.

Changing the then in the above code to done means that there will be no outer promise returned from this, and the error will result in an asynchronous uncaught exception, which will bring down the Node process. In theory this makes it unlikely that any such problem would make it into production, given how loudly and clearly it would fail during development and testing.

Gremlins.js, Backbone.CustomSync

11 Mar 2014 | By Alex Young | Comments | Tags testing backbone

Gremlins.js

Gremlins.js

Gremlins.js (GitHub: marmelab / gremlins.js, License: MIT) from marmelab is a monkey testing library. According to the authors, it can be used to unleash a horde of undisciplined gremlins at a web application.

If that sounds weird, there’s a handy gif in the readme that illustrates how it works: it basically throws events at your HTML, and is able to report back when something goes wrong:

Mogwais only monitor the activity of the application and record it on the logger. For instance, the “fps” mogwai monitors the number of frame per second, every 500ms. Mogwais also report when gremlins break the application. For instance, if the number of frames per seconds drops below 10, the fps mogwai will log an error.

There are various kinds of gremlins that try to uncover issues. This includes a form filler, clicker, and scroller. You can manually create hordes using a chainable API:

gremlins.createHorde()
  .gremlin(gremlins.species.formFiller())
  .gremlin(gremlins.species.clicker().clickTypes(['click']))
  .gremlin(gremlins.species.scroller())
  .gremlin(function() {
    window.$ = function() {};
  })
  .unleash();

Backbone.CustomSync

Garrett Murphey sent in Backbone.CustomSync (GitHub: gmurphey / backbone.customsync, License: MIT, npm: backbone.customsync), a more pragmatic solution for defining Backbone.sync implementations that allows you to avoid giant switch statements:

To use the extension, all you have to do is use Backbone.CustomSync.Model or Backbone.CustomSync.Collection in place of Backbone.Model and Backbone.Collection, respectively. If you don’t define one of these sync methods - createSync, for example - and Backbone attempts to save a new model, the options.error callback will be invoked automatically. Backbone.CustomSync will only perform the operations you define.

Introducing Web Components to Control Authors

10 Mar 2014 | By Matthew Phillips | Comments | Tags components tutorials
This is a guest post by Matthew Phillips, from Bitovi. You can find him on Twitter: @matthewcp and GitHub: matthewp.

At this point unless you’ve been living under a rock you’ve likely heard at least a little about web components, a collection of emerging standards created with the intent of making web development more declarative. Among other things, web components allow for custom elements, an easier way to encapsulate your widgets. If you’ve been developing with MVC frameworks there is a learning curve to using components, but once things start to click you’ll want to use them everywhere in your application. Who hasn’t wanted an easy way to insert a random cat picture?

<randomcat width="200" height="300"></randomcat>

Creating widgets that are well encapsulated is something we do on a daily basis on as JavaScript engineers. In this article I’ll explain where traditional control-based MVC has fallen short of that goal and how web components can resurrect the ease of development from the web’s early roots.

MVC’s Brick Wall

Traditional MVC frameworks encourage you to organize your view code by creating constructor functions called Controls or Views. If you’ve developed in this way you probably recognize some of the problems you encounter with this approach.

Tracking Down Instantiation

Since Controls are implemented as constructor functions that operate on a template, any sub view must be manually instantiated within one of the control’s lifecycle methods, usually either init or render. Consider the following in Backbone:

var Widget = Backbone.View.extend({
  initialize: function() {
    this.subView = new InnerWidget({ el: $('#inner') });
  },

  render: function() {
    this.$el(this.template());
    this.subView.render();
  }
});

That’s a lot of code that will become more complex as you add additional subviews or conditions for rendering.

(Lack Of) External API

While creating a widget, its common to create an external API to interact with. With traditional MVC controls, there is no standard way to do this, so it ends up being ad-hoc at the whim of the author. For example, here’s an accordion containing Panel subviews:

var PanelView = Backbone.View.extend({
  template: _.template($('#panel-tmpl').html()),

  render: function() {
    this.$el.html(this.template(this.model.toJSON()));
    return this.$el;
  }
});

var AccordionView = Backbone.View.extend({
  template: _.template($('#acc-tmpl').html()),

  addPanel: function() {
    if (panel instanceof PanelView) {
      this.$el.find('.panels').add(panel.render());
    }
  }
});

And then to use this:

var panel = new PanelView({ model: data });
accordion.addPanel(panel);

You’ll want to abstract some of these pain points to create your own “standard API” for controls. You’ll probably create some base classes with stub functions for common tasks. Pretty soon you’ve created your own mini-framework. We’re learned to put up with these little things and they don’t bother us day-to-day, but when you discover a better way it will change the way you architect your application.

Hidden Model

Similarly, widgets commonly need to interact with external model data. Most MVC frameworks provide some way to pass data into the control so a lot of people have established a pattern of passing in a “model” property to fill this hole. Having a clearer way of setting the model for a control opens a lot of doors in terms of composability. With the traditional control pattern you usually wind up using an adhoc ViewModel created with some properties passed in to the constructor and some created as part of the control’s own logic.

Enter Web Components

Web Components are a W3C spec for an HTML and JavaScript construct that, at its heart, is a way to define custom HTML elements. The spec includes:

  • Native templates (spec)
  • A way to load them (spec)
  • A method to define custom elements and extend existing ones (spec)
  • Hooks to run functions when an element is inserted in the page.

A custom element can be as complex as the main router for single page application, a simple widget to display markdown inline:

<x-markdown table-of-contents-depth="2">
# Heading

## Sub-heading

* List item
   - Sub list item
</x-markdown>

or as simple as a way to embed a YouTube video.

<rick-roll></rick-roll>

Web Components provide an alternate way to define traditional MVC based controls, with several key advantages.

Maximal Encapsulation

The power of web components is their ability to easily encapsulate the details of a widget while still maintaining the ability to compose them together, thanks to the legacy of HTML’s document-oriented roots. Because it is layout-based, web components can be neatly organized in templates, solving the instantiation problem that a control-based workflow suffers from. Applications can become more template driven rather than instantiating controls with complex event handler logic. Let’s say you were A/B testing a feature, you could have your template (in Mustache) look something like this:

{{if randomlyPicked}}
  <rick-roll></rick-roll>
{{/if}}

Obvious API layer

The API layer for web components is easy to understand. Data is passed to components through HTML attributes.

<x-injector href="/some-page.html" />

Layout is passed through the element’s inner content, as shown in the markdown example above.

Models and Templates

The web components spec includes templates for the first time in the web’s history. This means no more script tag or hidden div hacks to include templates on a page. Templates allow you to create fragments of markup to be used by your components later. They are parsed, but not rendered until inserted into the page.

Models can be bound to the templates, and, through the power of Object.observe changes in the model, would result in relevant parts of the template being automatically rendered. If you’ve used an MVC framework with template binding and observable models you’re probably already familiar with this.

Models are passed into components the same way as all types of data, through attributes.

With CanJS’ can.Component you can pass the name of your model through the attributes and get the live-binding today, without waiting for standardization to flesh out that part of the spec. This brings me to my last point…

Using Web Components today

Despite this being early days for Web Components, there are already a few options if you are interested in getting started. Polymer and X-Tags are two projects started by Google and Mozilla engineers working on the Web Components spec. These projects are bleeding-edge and break compatibility often. Additionally they don’t attempt to extend the spec with functionality that won’t eventually end up in it. What they do offer you is the ability to start using components the way they will be used when browsers have fully implemented the specifications. can.Component, on the other hand, is an early implementation of Web Components that provides additional functionality that is beyond the scope of custom elements.

can.Component adds two-way binding between a component’s model (which is not yet part of the web component spec) and its form elements. Additionally it adds declarative binding to a component’s templates through it’s scope object. Scope is an object that is used to render the template, but with the addition of declarative binding it does much more than that. The scope can be used to update the state of a component and respond to events. Here’s a typical example of can.Component that shows off all of these features:

Usage:

<color-selection></color-selection>

Implementation:

<script id="color-section-template" type="text/mustache">
  <form>
    <span class="validations">{{validationMessage}}</span>
    <input name="name" type="text" can-value="color" can-change="validate">
  </form>
</script>

This is the component’s JavaScript:

can.Component.extend({
  tag: "color-selection",
  template: can.view("#color-selection-template"),
  scope: {
    color: "blue",
    validate: function() {
      if (!isAColor(this.attr("color"))) {
        this.attr("validationMessage", "Not a valid color");
      } else {
        this.removeAttr("validationMessage");
      }
    }
  }
});

We Still Need Libraries

I hope I’ve demonstrated the way in which web components breaks some of the boundaries we’ve hit with traditional control-based MVC. At the same time the specification is intentionally low level and leaves room for libraries to improve upon the experience, as can.Component is doing today.

As a consequence of Web Component’s inherent declarative nature your code will become more condensed, with far less boilerplate. We’re truly approaching a paradigm where separation of concerns is being achieved. But you can’t appreciate the way web components changes the way you write applications until you try it yourself. So I encourage you to choose a library and start on your first widget today.

Further (required) Reading

npm-stat

07 Mar 2014 | By Alex Young | Comments | Tags npm node

Recently npm added back download stats, which means you can see how many downloads a package has had. The announcement includes the note that Mikito Takada submitted a pull request for the D3 graphs – it’s things like this that make me glad npm’s website is open source.

npm-stat

There’s a public API for the statistics, which is written using hapi.

Paul Vorbach sent in npm-stat (GitHub: pvorb / npm-stat.com, License: MIT), which generates another set of views on npm’s stats. It displays downloads per day, week, month, and year, and there are graphs for authors as well. Pages for certain authors that I won’t link to directly naturally take a while to generate, but it’s generally fairly responsive.

I’m interested in seeing what people build with npm-www and the stats public API, but so far it seems like they’ve made a big improvement over the older versions.

Book Review: Quality Code: Software Testing Principles, Practices, and Patterns

06 Mar 2014 | By Alex Young | Comments | Tags books testing jquery

Quality Code

Quality Code: Software Testing Principles, Practices, and Patterns ($44.99, eBook: $35.99, Addison-Wesley Professional) by Stephen Vance is a book about testing. It uses examples from several languages – Java is the most prominent, but there are JavaScript examples as well. The most significant part for DailyJS readers is a long practical exercise that involves testing an open source jQuery plugin, but there is a lot of general software design advice that you will find useful.

The book introduces automated testing, but also discusses how tests can be managed in real teams. One of the main points here is how the same best practices that you use for production code should go into automated tests – if you use certain object oriented patterns, small methods, SOLID principles, and so on, then these techniques should be used for test code as well.

This leads into the practice of writing maintainable test code: the relationship between engineering and craftsmanship.

Civil engineers may supervise and inspect the building of bridges or buildings, but they spend little time driving rivets, pouring concrete, or stringing suspension cables. Probably the closest to software engineers’ total immersion might be the handful of test pilots who are also aeronautical engineers, in that they participate in design, construction, inspection, and verification of the craft they fly.

There are JavaScript examples for code coverage issues, dynamic dispatch, scope, asynchronous computation and promises, and Jasmine:

Dynamic languages like JavaScript are less tied to an explicit interface, although usage still defines a de-facto interface. Jasmine’s spyOn functionality provides the full range of test-double variations by substituting a test-instrumented recording object for the function being replaced and letting you define how it behaves when invoked.

What I learned most from, though, was the higher-level advice, like “test the error paths”:

Many people stop before testing the error handling of their software. Unfortunately, much of the perception of software quality is forged not by whether the software fails, because it eventually will, but by how it handles those failures.

And the following point reinforced the way I work, mixing “spec”-like tests with integration and unit tests:

I prefer to test each defect, at least at the unit level.

Stephen sometimes talks about how most of our programming languages and tools aren’t designed specifically to support testing. One idea that runs through the book is about how to design code to be testable, and writing decoupled tests is part of this. Balancing encapsulation with access to internal state for testing is something that I think most of us struggle with.

As we have seen, verification of those internal representations sometimes occurs through interface access. Where null safety is either guaranteed by the representation or ignored by the test, we see code like A.getB().getC().getD() Despite the blatant violation of the Principle of Least Knowledge, we frequently find code like this-of course we do not write it ourselves!— in tests and production.

Chapter 12, “Use Existing Seams”, left an impression on me: it’s about the idea of finding places in code that allows you to take control of that code so you can bring it under test. Since reading that chapter I seem to have found more convenient places to grapple Express applications and test them more thoroughly.

If you write tests, but find they become unmaintainable over time, then this book may guide you to create less entangled tests. It mixes material for dynamic languages like JavaScript with statically typed languages such as C++ and Java. I find this useful as someone who writes a lot of JavaScript but works alongside Objective-C and .NET developers.

Stephen has combined years of experience into a rare, testing-focused book, that relates principles that we use to write well-designed code to the problems inherent in automated testing.

Node Roundup: npm Trademark, Cha

05 Mar 2014 | By Alex Young | Comments | Tags node modules npm

Charlie Robbins and the npm Trademark

Charlie Robbins, who you may know as indexzero, recently published An open letter to the Node community:

Being part of a community means listening to it. After listening to the deep concern that has been voiced over our application to register the npm trademark we have decided to withdraw the application from the USPTO. I want to apologize for the way that our message came across. We hastily reacted to something that clearly needed more thought behind it.

Nodejitsu previously announced its intention of registering the npm trademark, and although it seems like it was with the best intentions, the confusion that arose was understandable.

Charlie signs off the post by saying the Node community needs a non-profit “foundation” that helps manage Node:

There is little beyond GitHub issues and discussions as to the questions like roadmap and long term plans. A non-profit organization could get more of this tedious work done by having more dedicated resources instead of relying on individual community members to go it alone.

Many of us have seen something similar happen in companies we’ve worked at: we use GitHub issues and small, informal groups to manage things quite happily until the business grows and management mistakes become more dangerous.

Recently we’ve seen the arrival of npm, Inc and TJ Fontaine take over Node, so things are changing. I’m not sure how a non-profit Node Foundation fits into this, but as someone who depends on Node for his career I think Charlie has raised some important questions that need addressing.

Cha

Cha

Cha (GitHub: chajs / cha, License: MIT, npm: cha) is a module for defining tasks and chaining them together. It can be used to define build scripts, or whatever else you’d like to automate, and the author shows how to tie them to npm scripts as well.

This is what the basic API looks like:

var cha = require('../')

// Set a watcher.
cha.watch = require('./tasks/watch')

cha.in('read', require('./tasks/read'))
   .in('cat', require('./tasks/cat'))
   .in('coffee', require('./tasks/coffee'))
   .in('write', require('./tasks/write'))
   .in('uglifyjs', require('./tasks/uglifyjs'))
   .in('copy', require('./tasks/copy'))

There is a specification for tasks, and it allows text-based “expressions” to be defined that can glob files and do other cool stuff with less syntax:

cha(['glob:./fixtures/js/*.js', 'request:http://underscorejs.org/underscore-min.js'])

8 Bit Procedural Sound Generation, Flappy Bird 2

04 Mar 2014 | By Alex Young | Comments | Tags games audio

8 Bit Procedural Sound Generation

8 Bit Procedural Sound

8 Bit Procedural Sound Generation by Jerome Etienne is a post about generating sounds using jsfx. Jerome’s demo shows visualisations for sounds that might be useful in a game.

He also introduces the webaudiox WebAudio API helpers, which includes methods for converting from byte arrays to floating point numbers.

Flappy Bird 2

Thomas Palef sent in part 2 of his Flappy Bird tutorial:

In the last HTML5 tutorial we did a simple Flappy Bird clone. It was nice, but quite boring to play. We will see in this post how to add animations and sounds to our Flappy Bird clone. These won’t change the game’s mechanics, but the game will feel a lot more interesting.

There’s also an article about his experiences on the IndieGames.com blog.

I think games are an interesting way of teaching full stack development – if you can hook a game like this up to a server-side Node project that stores player details, scores, and perhaps multiplayer, then it covers a wide range of skills.

Some Atom-related Node Packages

03 Mar 2014 | By Alex Young | Comments | Tags node editors tools

Atom

Hugh Kennedy sent in npm-install, an Atom package for automatically installing and saving the npm modules in the current file.

To use it, you just need to open the Command Palette and type npm install. The Command Palette can be opened with cmd-shift-p.

There’s another npm-related Atom package as well: npm-docs by Jonathan Clem. This allows you to use the Command Palette to easily look up a module’s readme or homepage. This is the kind of thing I do all the time when I write about Node on DailyJS.

Tyler Benziger kindly sent me the Atom invitation, but I’ve only used it for a few small things so far. I’ve been trying to figure out how it fits in with the Node community, and whether or not it’ll be popular with DailyJS readers.

If you look at the screenshot in this post you might notice that I’ve got a folder open with lots of items. That’s DailyJS’s 1127 posts, which Atom handles without any trouble.

The Atom Editor

28 Feb 2014 | By Alex Young | Comments | Tags node editors tools

Atom

“Alex, you love talking about text editors, why don’t you write about that GitHub Atom project?”

Ah, text editors. Arguably our most important tools, yet we’re more fickle about them than our choice of programming language, web framework, and preferred caffeinated beverage. Atom is made by GitHub. It’s built using dozens of related open source projects, and some of these include “packages” that extend the editor.

All of the packages seem to be written with CoffeeScript, but before you get your pitchforks out, take a look at this thread:

You can use plain JS to develop packages.

Phew. The reason I wanted to write about Atom on DailyJS was it’s built using Node and a web view. The fact it embraces Node means it should be easier for us to extend it. It also claims to have TextMate support, and can use native extensions through Node C and C++ modules.

Parts of Atom are native as well, so it should feel desktop-like rather than web-based:

Atom is a desktop application based on web technologies. Like other desktop apps, it has its own icon in the dock, native menus and dialogs, and full access to the file system.

I’ve seen a few generations of desktop text editors come and go: BBEdit, TextMate, and Sublime Text. I expect the excitement around Atom to follow a similar pattern. I’m going to write about interesting Atom packages if I think they’re of interest to DailyJS readers (please send them in), but you’ll still find me happily plodding on with Vim. And vin (rouge), but that’s another story.

Nodyn: No Dice

27 Feb 2014 | By Alex Young | Comments | Tags node java

Nodyn (GitHub: projectodd / nodyn, License: Apache 2.0) is a Node API-compatible JVM-based project. That means you can technically use Java libraries from within Node programs.

I’ve been using it on my Mac, running Mavericks. Here’s what I had to do to get it to work:

brew install maven
git clone https://github.com/projectodd/nodyn.git
cd nodyn
export JAVA_HOME=`/usr/libexec/java_home`
mvn install -Dmaven.test.skip=true
cd nodyn-standalone/target
java -jar nodyn-standalone.jar --console

It took me a while to figure all of this out. I already had Homebrew installed, but I didn’t have Maven. I’m an amateur Android developer, so I only ever really write Java through Google’s recommended IDE tools.

Maven installed without too much trouble, except I found it used the wrong version of Java. The export JAVA_HOME line makes Maven use the right version. I’m not sure why this is required because java -version showed 1.7, but for some reason Maven was building Nodyn with 1.6, which generated a long and inscrutable error message.

The mvn install -Dmaven.test.skip=true line builds Nodyn, and skips tests. I wanted to skip the tests because they seemed to hang on this line:

Starting test: src/test/resources/os|os_test.js|testFreemem

Once I built it, I ran a small program that reads its own source and prints it to stdout:

var fs = require('fs');

console.log('I can print my own code');

fs.readFile('test.js', 'utf8', function(err, text) {
  if (err) console.error(err);
  console.log(text);
  console.log('When I work correctly');
});

This printed the following output, which is incorrect:

log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFactory).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
I can print my own code

The expected output is this:

I can print my own code
var fs = require('fs');

console.log('I can print my own code');

fs.readFile('test.js', 'utf8', function(err, text) {
  if (err) console.error(err);
  console.log(text);
  console.log('When I work correctly');
});

When I work correctly

It seems like Node API compatibility isn’t quite there yet. I also noticed it takes much longer than Node to start up, but I seem to remember jRuby developers complaining about startup time so that might be something to do with how Java works. It probably doesn’t really matter for long-running server processes, but I quite like the fact Node programs start up quickly.

If you’re a Java programmer Nodyn might seem cool, but so far I’ve struggled with it. Despite my Maven issues, the project looks neatly organised and carefully written, so I’m going to keep watching it.

Node Roundup: No More Force Publish, Counterpart, mock-fs

26 Feb 2014 | By Alex Young | Comments | Tags node modules npm testing internationalisation

No More Force Publish

Isaac Z. Schlueter wrote on npm’s blog that publish -f will no longer work:

If you publish foo@1.2.3, you can still un-publish foo@1.2.3. But then, you will not be able to publish something else to that same package identifier and version. Ever.

The common wisdom is changing the code that a version number describes is dangerous, so it’s better to publish a new version. If you’re a module author, you may feel that this is frustrating – what if you just released something with a dangerous security flaw? In cases like this it may be best to remove the version and publish a new, fixed version.

Counterpart

Counterpart (GitHub: martinandert / counterpart, License: MIT, npm: counterpart) by Martin Andert is an internationalisation module based on Ruby’s I18n gem:

translate('damals.about_x_hours_ago.one')          // => 'about one hour ago'
translate(['damals', 'about_x_hours_ago', 'one'])  // => 'about one hour ago'
translate(['damals', 'about_x_hours_ago.one'])     // => 'about one hour ago'

You can write translation documents using JSON. Features include interpolation, pluralisation, and default fallbacks.

mock-fs

mock-fs (GitHub: tschaub / mock-fs, License: MIT, npm: mock-fs) by Tim Schaub is an API-compatible version of Node’s fs module that essentially allows you to temporarily use an in-memory filesystem.

It provides a mock function that accepts a specification of the files you want to mock:

mock({
  'path/to/fake/dir': {
    'some-file.txt': 'file content here',
    'empty-dir': {/** empty directory */}
  },
  'path/to/some.png': new Buffer([8, 6, 7, 5, 3, 0, 9]),
  'some/other/path': {/** another empty directory */}
});

You might find this useful if you want to write tests that avoid touching real files.

Matter.js

25 Feb 2014 | By Alex Young | Comments | Tags webgl html5 physics

The Matter.js Wrecking Ball demo.

Matter.js (GitHub: liabru / matter-js, License: MIT) by Liam Brummitt is a stable and flexible rigid body physics engine for browsers. The author describes it as an alpha project that came about as a result of learning game programming.

If you’re interested in reading more about physics for game programming, Liam has collected some useful resources in Game physics for beginners.

Matter.js uses time-corrected Verlet integration, adaptive grid broad-phase detection, AABB mid-phase detection, SAT narrow-phase detection, and other algorithms for managing collisions and physical simulation. More well-known engines like Box2D support these features, but if you take a look at the some of the classes Liam has written then you’ll see how clean and readable his version is.

I’ve been looking at the source to see how to use it, and the API seems friendly to me:

var Bodies = Matter.Bodies;
var Engine = Matter.Engine;
var engine = Engine.create(container, options);
var World = Matter.World;

World.addBody(engine.world, Bodies.rectangle(300, 180, 700, 20, { isStatic: true, angle: Math.PI * 0.06 }));
World.addBody(enigne.world, Bodies.rectangle(300, 70, 40, 40, { friction: 0.001 }));

The demo is cool, so try it out if you want to experiment!

Angular Selection Model, Normalized Particle Swarm Optimization

24 Feb 2014 | By Alex Young | Comments | Tags graphics optimisation angularjs

Angular Selection Model

Angular Selection Model (GitHub: jtrussell / angular-selection-model, License: MIT) by Justin Russell is an AngularJS directive for managing selections of items in lists and tables. It’s indifferent to how data is presented, and only tracks what items are selected.

This example allows a text input to filter a list of items, and also allow the user to select items from the list:

<input type="text" ng-model="fancyfilter" />

<table>
  <thead>
    <tr>
      <th></th>
      <th>#</th>
      <th>Label</th>
      <th>Value</th>
    </tr>
  </thead>
  <tr ng-repeat="item in fancy.bag | filter:fancyfilter"
      selection-model
      selection-model-type="checkbox"
      selection-model-mode="multiple-additive"
      selection-model-selected-class="foobar">
    <td><input type="checkbox"></td>
    <td>1</td>
    <td></td>
    <td></td>
  </tr>
</table>

The directive does a lot of things behind the scenes to make this work naturally. An internal read-only list is used to represent selected items, and there’s a provider for setting things like the selected attribute and class name assigned to selected items at a global level. Checkboxes are automatically managed, including support for multiple selection.

Justin has included tests, documentation, and examples.

Normalized Particle Swarm Optimization

Swarm optimisation

Adrian Seeley sent in this gist: JavaScript Normalized Particle Swarm Optimization Implementation. If you want to try it, just click “Download Gist” then open the HTML file locally.

The reason I wanted to write about it was he decided to license it as “Abandoned”, so rather than letting it languish I thought I’d share it in case someone finds it useful.

Here’s how Adrian described the project:

Particle swarm optimization is an incredibly viable machine learning structure, but is often implemented using database oriented designs splayed across multiple files in c++ or java making it very inaccessible to newcomers. I present a simple, unoptimized, and easy to follow javascript implementation of normalized particle swarm optimization, making use of full descriptive variable names entirely encapsulated in a single inlined function.