Mocha string diffs
Mocha 0.14.0 adds a single feature - string diffs! This is a small but very handy feature for some. When the strings are small, Mocha will use a character diff, when consisting of several lines a line-numbered “gutter” is added and a word diff is used as shown in the following image:
This is very useful when authoring things like template engines, transpilers, and other string-based libraries. For example the Stylus test suite is comprised of nothing but acceptance tests, the input file is compiled, and the resulting CSS is checked using actual.trim().should.equal(css);. In combination with Mocha’s BDD interface I can now simply iterate through the files and define test-cases as shown here:
var stylus = require('../')
, fs = require('fs');
// test cases
var cases = fs.readdirSync('test/cases').filter(function(file){
return ~file.indexOf('.styl');
}).map(function(file){
return file.replace('.styl', '');
});
describe('integration', function(){
cases.forEach(function(test){
var name = test.replace(/[-.]/g, ' ');
it(name, function(){
var path = 'test/cases/' + test + '.styl';
var styl = fs.readFileSync(path, 'utf8');
var css = fs.readFileSync('test/cases/' + test + '.css', 'utf8');
var style = stylus(styl)
.set('filename', path)
.include(__dirname + '/images')
.include(__dirname + '/cases/import.basic')
.define('url', stylus.url());
if (~test.indexOf('compress')) style.set('compress', true);
style.render(function(err, actual){
if (err) throw err;
actual.trim().should.equal(css);
});
})
});
})
Now if something were go to wrong, you get a nice diff!
Assertion library authors
To support this feature all you have to do is populate err.expected and err.actual with their respective values, Mocha will take care of the presentation.
NOTE: I just toggled the colors, green is now the expected color
Mocha test coverage
The latest release of Mocha adds two new reporters, now totaling 13 packaged with the library. The two new ones are “json-cov” and “html-cov”, the latter inherits from the former in order to produce a single-page test coverage report.
If you’re curious what a live example looks like, check out this page.
Setup
With Node’s require.paths array out of the picture there’s a bit of boiler-plate involved in setting up test coverage for your project, but it’s pretty minimal. First you’ll want to install the jscoverage executable, this program parses your source code and spits out an instrumented version, effectively a bunch of lines that look like this:
$_jscoverage[filename][line]++;
This enables libraries like Mocha to execute the code as they normally would, however we can then extract this coverage information and generate fancy reports. jscoverage takes the input directory, and an output directory, I usually calls this “lib-cov”:
$ jscoverage lib lib-cov
Typically when testing your library you’ll use relative require() calls that look like this: var express = require('../'), and the library entry point is ./index.js. Normally this file might look something like below, or you may not have an ./index.js file at all.
module.exports = require('./lib/express');
By using ./index.js we can then alter this statement to conditionally export the instrumented version when the EXPRESS_COV environment variable is present:
module.exports = process.env.EXPRESS_COV
? require('./lib-cov/express')
: require('./lib/express');
Then all you need to do is invoke mocha with --reporter html-cov and redirect the stdout to a file such as coverage.html. Line 25 the test-cov target of the Express Makefile illustrates how I typically handle this but depending on your setup it may vary.
That’s it! remember to add “coverage.html” to your .npmignore and .gitignore files ;)
This short Vimeo screencast illustrates why Stylus is the most like CSS as a stylesheet “preprocessor”. More on Stylus here.
Stylus 0.15.1 - new property reference & @keyframes fabrication features
Stylus 0.15.x adds a bunch of cool new functionality as well as some important bug fixes.
@keyframes fabrication
The new keyframes fabrication support automatically duplicates your @keyframes definitions to support vendor prefixes. Note that this is only a default, as shown below:
@-moz-keyframes foo {
0% {
color: #000;
}
100% {
color: #fff;
}
}
@-webkit-keyframes foo {
0% {
color: #000;
}
100% {
color: #fff;
}
}
@keyframes foo {
0% {
color: #000;
}
100% {
color: #fff;
}
}
one can tweak this functionality using the vendors list as shown in the following snippet which will only expand to the -webkit- vendor prefix.
vendors = moz official
@keyframes foo {
from {
color: black
}
to {
color: white
}
}
The vendors property may be utilized more in the future, and perhaps in frameworks like “nib” to unify configuration.
Property reference
The syntax @<property> has been introduced to reference values of existing properties. For example if you want to re-use values, you may typically do something like below instead of typing the value several times, also allowing you to use functions with w.
.button
width: w = 50px
height: w
The new property reference syntax allows you to treat properties as variables, which can also be accessed within mixins:
.button
width: 50px
height: @width
Comment compilation
When the compress option is true Stylus will not output single-line nor multi-line comments, which are commonly found used for licensing in stylesheet frameworks etc, so it’s useful to strip these out however you can now force output with the ! character /*!.
New built-in functions
The math functions cos() and sin() were added, as well as exposing PI.
Bug fixes
Game prototyping with JavaScript & CSS3
I wanted to share a quick few-hour game prototype to hopefully inspire a few people! The industry let-alone browser-based games seem very lacking in imagination and storytelling, or maybe I’m just not looking hard enough ;) but I miss games like Grim Fandango.
Below is a screenshot of the demo, consisting of several DOM nodes to represent parts of the main character, the birds, and the scene. Most of the animation is performed with CSS transitions / animations, some of which are dynamic and use the move.js library.
I have yet to profile anything but it runs quite smooth on my machine, and there are many aspects that could be optimized, and some simple ones like ditching jQuery.
iPhone gaming
Back to the original plan, roughly two years ago before the Ipad came out, I was writing an Objective-C iPhone game with Cocos2d and Chipmunk physics, two really wicked libraries. The iPhone seemed too small, and at the time the resolution was not great either, not to mention the image size restraints that Apple enforced, so I gave up after a few prototypes, and one full-screen PC prototype.
Browser gaming
With the advent of modern browsers, browser gaming is already a lot less shitty than a year or two ago, and it’s only about to get much better with all the work browser vendors are putting into making sure canvas and friends run smooth as butter.
The first prototype I wrote was written entirely with Canvas. One of the main benefits of this is a certain level of control that you obtain, it’s extremely easy to implement features like pausing, to apply post-processing, or ad-hoc features that are difficult with the DOM.
At first I was pretty happy with the result, until I wrote the prototype using CSS3 and HTML, the performance impact was pretty significant (though I had not implemented dirty rects etc). Certain aspects of gaming are significantly easier using the DOM, for example leveraging z-index and CSS transitions, however contrasting canvas pausing and post-processing are more of a problem. At least with the currently state of browser technologies, it’s a good idea to mix and match. You can build a large portion of your game using the DOM, and canvas for aspects like particle emitters, or perhaps even WebGL shaders like this awesome demo.
Demo
The video below shows off some of the interactivity, as well as the tiny scene building tool.
The demo consists of ~200 lines of js and ~200 lines of CSS, using CSS for transformations, animations and obviously for styling, while the js performs some basic interactions like the eye-ball targeting, and randomized cat walk routine. The demo also has a small toolkit for
creating scenes, but it’s certainly nothing robust.
Source
You can grab the source on Github. Ping me of you come up with some cool prototypes!
Concepts
Some more concepts:
Introducing Texty & Super Agent screencast
In this 20 minute screencast we dive into the full-text Redis search library reds for nodejs, an introduction to the canvas-only text editing library Texty, discussing how you can style canvas drawings with CSS, and the “ajax with less suck” library superagent.
