How to list all dependents of a Node package

You can use the web npm web site as it lists the dependents for any given package.

Like coffee-script for example:

http://npmjs.org/browse/depended/coffee-script

Or, you could get JSON results for the same query (using curl) (just substitute the name of the package with "sql" in the example:

> curl -g 'http://registry.npmjs.org/-/_view/dependedUpon?group_level=2&startkey=["sql"]&endkey=["sql","ZZZZZZZZZZZZZ"]&skip=0&limit=1000'

Results:

{"rows":[
{"key":["sql","anydb-sql"],"value":1},
{"key":["sql","dbal"],"value":1},
{"key":["sql","ectypes-downstairs"],"value":1},
{"key":["sql","fixr"],"value":1},
{"key":["sql","fixr-compiled"],"value":1},
{"key":["sql","forerunner-postgres-store"],"value":1}
{"key":["sql","pg-dal"],"value":1},
{"key":["sql","relational"],"value":1},
{"key":["sql","sequelize"],"value":1},
{"key":["sql","sql-generate"],"value":1},
{"key":["sql","sqlbox"],"value":1},
{"key":["sql","triplie"],"value":1},
{"key":["sql","voltron-postgres-adapter"],"value":1},
{"key":["sql","worm"],"value":1}
]}

The second value in the key array is the name of the package dependent on the sql package.

This of course only will find other published packages, and doesn’t help find applications, etc. that are using a specific package.

Using Airport Utility to recover wifi password

If you find yourself trying to remember what the wi-fi password was for an Apple Airport wi-fi access point (such as the Airport Extreme or Airport Express), and you remember/stored the base station password, then you’re in luck!

Start the Airport Utility.

Select the device for which you want to retrieve the password on the left.

image

Then, click Manual in the lower left corner:

image

And you’ll see a screen similar to this:

image

Then, from the application menu, select Base Station and Equivalent Network Password:

image

A dialog will be displayed:

image

At the top, your wi-fi password should be listed.

I copied it to 1Password so I wouldn’t lose the password again. 🙂

Loading Models in NodeJS

I’d answered a question on StackOverflow about where to put “models” in a NodeJS project. I wanted to elaborate on the simple auto loader I use to load a folder full of models (and I use this pattern other places as well). Normally, I create a folder called models:

image

Inside the Models folder, I have a file called, models.js.

Inside another module (like app.js), I’ve got a line of code that looks like this:

var models = require('./models').initialize(app, services);

While the require (reference) by default looks for a file called index.js in the folder models, I’ve in this case added a simple package.json file with an override:

{
    "main": "./models.js"
}

The reason I do this is that in a tabbed source code editor, having several index.js files can be confusing to see. So, this allows me to name the file something that is more memorable and understandable at a glance.

Inside of the models.js class, I’ve written code to automatically load all of the models (and call an initialize function once for each module):

var initialize = function(app, services) {
    var models = {};
    var currentFile = path.basename(__filename); // just file name
    var modelFiles = fs.readdirSync(__dirname);
    // loop through all of the files in the current directory
    for(var i= 0, len = modelFiles.length; i < len; i++) {
        // ignore this file (via global NodeJS variable)
        if(modelFiles[i] === currentFile ||
            path.extname(modelFiles[i]).toLowerCase() !== '.js') {
            continue;  // skip the current file and anything without a "JS" extension
        }
        // require it
        var model = require(path.join(__dirname, modelFiles[i]));
        // call its intialize
        model.initialize(services, models);
    }
    exports.models = models;
    return models;
};

exports.initialize = initialize;

The logic is simple enough – grab all of the files in the current path, then loop through each, filtering the current file and any that don’t end with “js”. This logic could be adjusted of course to reflect other coding styles and requirements.

Finally, each module is loaded and then an initialize method is called (admittedly, I could make it more robust by checking for the existence of the initialize function before calling it (but in this case, I know each module should be initialized in a particular way).