testing javascript array membership, V8 oddness

Given an array that you are going to test membership against, for example if you are creating a set:

var arr = [‘some stuff’];

Instead of

arr.indexOf(‘not here’) > -1

you can

~arr.indexOf(‘not here’)

which is a bit more compact, and possibly more readable once I get used to it.

Out of curiosity, I created a benchmark to compare the two, which is ridiculous since they are both so fast.

However, the interesting thing is V8’s performance with a second pass:  http://jsperf.com/using-for-indexof-vs-1

Firefox gives results that I would have expected.

Advertisements

Mongoose and unique indexes

When testing a model’s unique index, you may find that your specs do not fail as you would expect.  You may find that the unique index appears to not be taking effect.

If that is the case, you can:

describe(“something unique”, function(){

  beforeEach(function(done){

    model_under_test.ensureIndexes(done);

  });

  it(“fails with an error..”);

});

Another (possibly better) alternative is to make assertions on the model schema.

DD-WRT filters DNS?

I just spent a few odd moments figuring out that my DD-WRT router was filtering out some development-related DNS records.

Perhaps it’s for some sort of security reason?  That seems odd, since an IP address could be used in a URL just as easily.

Odd.

Faster tests through overriding defaults

I’m using an excellent piece of abandonware called connect-assets on a project.  It works well and does its job fairly well.  It’s a shame that it’s so neglected.

Yesterday I started to get a staging environment up and going on my project.  Connect-assets wants to serve static assets out via hostname.com/js/ and hostname.com/css/ where I normally prefer to serve static assets out via hostname.com/static/js and hostname.com/static/css which results in a simpler nginx config for serving these static assets.

As I looked through the documentation and code for how to do this, I came across a configure option named “detectChanges” that defaulted to “true” which (as near as I can tell) serially and synchronously stat()ed each file involved for every request.

One of the reasons why I’m doing development in node.js/express is because it’s leaps and bounds faster than doing ruby on rails.  My test suite (including integration specs) takes ~3.3 seconds from execution to completion (including compilation, etc.) on my shiny new workstation.  After overriding the default of “detectChanges” my suite takes ~2.6 seconds.

Yay!  🙂