substack

I've complained about this before too, but if you click the "i" with a circle around it in the bar that says "this pull request can be automatically merged" you get a nice box with all the git commands to do a local fetch and merge. I think this functionality should be less hidden away but it is there and quite useful.

If you want to play with this new version but also have code running on older versions that hasn't been completely ported yet, I recommend using nave to manage your node versions. After you `npm install -g nave` you can just `nave install 0.8.0` to get node 0.8 then type `nave use 0.8.0` to start using it!

https://github.com/isaacs/nave

The verify phase was just defining an inline function but not running it. However, I just noticed that a program with carefully placed braces could jump out of the function box and actually run. I replaced the checker with just Function(src) which shouldn't have that problem and is much faster.

Nice to see people using some of my libs to do nifty stuff but I must caution against depending on `latest` since this could cause your application to break in the future if I push breaking changes: https://github.com/ptrsghr/joint/blob/master/package.json#L5...

It's a better idea to do:

    "dnode" : "~0.9.11",
    "browserify" : "~1.10.17"

since that way you'll get patch fixes automatically but your library won't break when I push out an update that bumps the minor version, which could including backwards-incompatible changes.

Sorry about that. We booted up a ton more free servers but the queues are still rather large. On days when we're not getting a traffic spike you can usually use the service right away.

This is a nifty feature and npm can do something very similar:

    npm install git://github.com/substack/node-optimist.git

Check out tap, it has a very simple api that works well for testing asynchronous code: https://github.com/isaacs/node-tap

Here's a tap example that sets up a server and client for dnode: https://github.com/substack/dnode/blob/master/test/single.js

Timers usually aren't necessary with test harnesses like tap or nodeunit since you need to call `t.end()` explicitly or else `t.plan()` the number of tests that are supposed to be run. If a different number of tests actually run or assertions fire after `t.end()` is called, those are reported as errors.

For (4), to run a bunch of test files in a directory you can use the `tap` command. You can even add something like `tap test/*.js` to the scripts.test field of a package.json file and then to run all your tests you can just do `npm test`.

For which there is a massive amount of selection bias going on. I would want to see actual figures and a proper linear regression model before jumping to any conclusions here.

Part of my point was that "self-selecting out the gene pool" does nothing to dispel harmful beliefs. That is a culture and education problem.

    > And, for the record, I'm all in for homeopathy and faith
    > cures - they may help remove some undesirable genetic
    > traits from the gene pool. OTOH, the populations presenting
    > such traits can evolve to have better immune systems. Life
    > has a way to perpetuate itself.

Susceptibility to harmful ideologies really doesn't work like that. Being raised within a religion or cultural practice is an amazingly better predictor for continuing that belief in the next generation than what genes were passed along. Faith cures and placebos operate at the level of belief and culture, not the gene level.

Further, look no further than the anti-vaccination movement to see how harmful medical ideas can put the general population at a greater risk for entirely preventable diseases.

That seems like a massively inefficient way of doing things. Tests are very inexpensive since they can run without human intervention. Code review requires another human to sift through changes. If the automated tests pick something up first then the code reviewer wouldn't need to sink any time into a review in the first place.

I mean why does `module` pull down resources? Shouldn't that be import's job?

Thanks for this. I'm glad that using a single export function will at least be possible. I'm still pessimistic about the amount of syntax being introduced here.

In particular, I still really dislike the special import "local renaming" syntax since it seems so unnecessary compared to just having an import keyword that returns an object and letting the programmer extract and manipulate the relevant entries. You would still get the static analysis benefits of having static imports without all the awkward complexity of the current proposal. Wouldn't it just be the same thing to Object.freeze() the export object but without any syntax magic necessary?

Plus, overloading `module` to do loading AND defining with the `module Bar at "uri"` form seems really wrong. Why can't it JUST do defining and just let import do all the loading?

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function?

In ES.next, you've got to use pythonesque `import y from Bar` statements which introduce a frustrating correspondence between the lexicals of your own program and the export names of the module you're trying to use which is really terrible if you're using as many modules as I typically do. I presume ES.next will invent even more specific syntax for some sort of `as` like keyword to side-step this but it seems so unnecessary when javascript already has a module system that is so very good as is exploding in popularity and use (>7000 modules now on http://search.npmjs.org/).

I understand what they're trying to do with static analysis too but you can already pretty much do that and I've done it. It's not hard at all, just ignore require() statements that don't contain strings when you walk the AST, like this: https://github.com/substack/node-detective

Inventing more syntax instead of just adopting a far better module system that has seen actual use in practical situations is such a shame and ES.next is rife with this kind of prescriptivism. It irritates me to no end and I sometimes want ES.next to die a quiet death in obscurity because of it.

http://wiki.ecmascript.org/doku.php?id=harmony:modules

> JavaScript has very little support for any of those nice things: it doesn't even have namespaces, for chrissakes. Why would I want to repeat these same mistakes over and over again in a new language?

Javascript doesn't have this (by itself) but node has a very nice require() system that is really excellent for long-term maintainability. When you bump a dependency in a node project that change will only affect the code near it because of how node_modules are resolved to the most local copy. You can bump dependencies without worrying how this will affect other packages.

Plus, require() just returns an object. It doesn't puke a bunch of objects into the current scope. This is massively useful for readability. I've sunk a lot of time on other systems tracking down unqualified exports to figure out which package's documentation to consult.

I've got nothing against scala and am sure it's a useful language but I wonder if the author has even used node.

At the civic level, check out some of the projects that the Code for America folks are up to: http://codeforamerica.org/projects/

As a hacker/founder who has also taken up the art/design role, I disagree and think that developers who can draw reasonably well should try designing the art assets for their startups.

When you design your own art assets, you can iterate on the design in a much more incremental way because the transaction cost of going out and finding a designer is quite high. When you can design your own assets in-house, the art can work its way into the core of the product better and ends up in more places. For instance, many of the modules my startup has released have silly cartoons that I drew: http://www.catonmat.net/blog/browserling-open-sources-90-nod...

When there are external barriers to art, you're probably going to use it less. Contracting out for all of those silly readme cartoons would be wildly uneconomical but for me it provides a nice refuge from coding all day that happens to help us establish credibility with potential customers and expand our product exposure.

If you are a developer who is going to try your hand at doing the art yourself, I wouldn't be too concerned if your initial attempts look amateurish. Our earliest prototype looked really bad:

http://substack.net/images/screenshots/browserling-1.png

but we iterated and made it a little better:

http://substack.net/images/screenshots/browserling-3.png

and then did a redesign recently:

http://browserling.com/

Make some art!

Thanks for posting this! I just updating my own silly shuffle module (https://github.com/substack/node-deck) to work using the last in-place algorithm for uniform shuffling and I saw a huge speedup.

> "normals" have absolutely zero clue about what it is

I was surprised to hear my relatively non-technical father ask me back in December if SOPA was as bad as he had heard. Discussion of this legislation seems to be making it out into the mainstream press in bits and pieces. NPR has done several segments on it that I know of for instance.

I discussed this with isaacs in one of the nodeup episodes and we concluded that a pagerank implementation for authors and projects that reads in the npm stars and dependency graph might work. It would also be useful to consider the github watchers, elapsed time since the last update, and the presence and status of tests, perhaps by ingesting data from travis-ci.

Edit: turns out what I have in mind nearly already exists at http://eirikb.github.com/nipster

Perhaps you could just be more narrow in your searches with `npm search`? Perhaps instead of searching for "asset management" you could just search for a tool that does browser javascript bundling and then search for another tool that does css bundling. There are fewer of each of those and you can refine your search further by looking for specific things like bundlers that do node-style require()s versus AMD-style requires.

Plus, on http://search.npmjs.org you can see how many people have starred a project. You can star a project yourself with `npm star`. For a lot of projects you can click the home page or github links from the project page too. These are really useful to get a quick glance of what the API is like. If a project doesn't have either of these then it probably isn't worth using.

Knowing how semver works is pretty useful if you're doing node development and writing down package dependencies in package.json. semver is also for negotiating protocol version ranges between network services.

Nor should it. semver is just about versions. npm does know about tests with scripts.test in package.json and there are some projects in the works to run tests automatically from npm like CPANTS but it's still early.

Node is catching up pretty fast, although its modules might not be as mature yet:

    102257  perl    http://www.cpan.org/
     33270  java    http://search.maven.org/#stats
     31921  ruby    https://rubygems.org/
     18068  python  http://pypi.python.org/pypi
      5732  node    http://search.npmjs.org/

I could just as easily make up a story about how males are intrinsically attracted to pink and red, the color of animal flesh from a recent hunt and how females are attracted to blue waters since in many pre-agrarian societies women had to carry water back to camp.

Without empirical studies with solid controls these are just stories. Evolutionary psychology theories are especially guilty of these kinds of story-making explanations that aren't held up to evidence.

I really love how this project copies how the node require resolution works. That is by far my favorite thing about node and it lets programmers do version management and reusability really well.

> Let's go ahead and compare with Twisted, shall we?

Oh goodness, yes.

How about an echo server. This one is from the twisted home page, so I am not knocking down a strawman.

    from twisted.internet import protocol, reactor
    
    class Echo(protocol.Protocol):
        def dataReceived(self, data):
            self.transport.write(data)
    
    class EchoFactory(protocol.Factory):
        def buildProtocol(self, addr):
            return Echo()
    
    reactor.listenTCP(1234, EchoFactory())
    reactor.run()

Versus in node you can do:

    var net = require('net');
    net.createServer(function (stream) {
        stream.pipe(stream)
    }).listen(5000)

This is what I mean by limited surface area. I shouldn't need to define 2 classes to write an echo server. An Echo class AND an EchoFactory? And on top of that I need to mess with a reactor? How does that pass for good API design?

The asynchronous aspects were a very small piece of the article for a reason. Node is doing a lot of very interesting, important, and novel things that aren't related to asynchronous events at all. Twisted in particular suffers from too much exposed surface area and having to manage the reactor yourself, which hurts reusability a lot.

> But still, having dealt with library version issues sometimes, I think "concurrent library versioning" and "sophisticated package management" sound awfully nightmarishly black-magic to me. I guess I would be more on the "let's understand the most of what happens and not change what don't need to" kind.

Concurrent versioning lets you do the "not change what don't need to" part really, really, well. Versions of packages that have been proven to work well with one another can continue to do so because if you need a newer version of some library then both the old and the new version can live harmoniously in the same codebase. You don't need to be paranoid about upgrading modules anymore because node and npm are already paranoid on your behalf.

Doing probability backwards like this is not useful and leads to fallacious conclusions and magical thinking. How is this any different from people running around misapplying quantum terminology for feel-good conclusions?