--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Great writeup! Most these points are right on.
But I've also been severely bitten by
the performance and race-condition implications of this.
...
I've seen many cases where it's better and simpler to
just call right away.
I've seen many cases where pulling in just one library causes my `npm ls`
output to be completely useless.
And stuff I know I'm not using like 5 different kinds of option parsers, Ansi color libraries,
logging frameworks, and sometimes even testing frameworks.
I shouldn't have to install 5MB of javascript code in
dependencies just to use your simple library.
Probably true especially regarding code complexity, but disk space is cheap. Though, the time to install all that stuff is a real bummer. If `npm install` was faster, would this be less of an issue?
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
I think what the OP means, is that library authors should wrap *synchronous* callback calls in process.nextTick
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Just beware of Travis CI failing for situations that are beyond your control. Missing C libraries, OS issues, and external resource needs can all be problematic. Also I have noted at least in the past sometimes travis fails to provision VMs appropriately. Running tests in your environment is the best way to test a module.
Great writeup! Most these points are right on.Thanks Tim! Positive feedback is welcome.But I've also been severely bitten by
the performance and race-condition implications of this....
I've seen many cases where it's better and simpler to
just call right away.Can you give me an example?
On Friday, October 12, 2012 at 6:15 AM, Dominic Tarr wrote:
I was worried for a second that this post was gonna be about punctuation.Pleasantly Surprised!The hardest part is the bit about NIH. This isn't really something we understand properly yet. It can be a struggle just to find other modules that do the think you want. Sometimes you've written a module before you even discover that other solutions exist.If you do find someone has a module that is close to what you need,but not quite, in some important way, then you need to communicate with them. The best way to do this is on IRC. Unfortunately not everyone uses IRC.Please use IRC.