> It's really about collaboration. The answer to the problem "too many
> modules" isn't Write Less Modules, it's Collaborate More!

> the ability to collaborate is a soft human skill, but a skill that you can
> develop.

> On Fri, Oct 12, 2012 at 3:34 PM, Rick Waldron <waldro...@gmail.com<javascript:>
> > wrote:

>> 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.

>> +9001

>> Code is a personal thing, and it's important to try and understand the
>> VIBE the author is going for. Issues aren't really a way to communicate
>> vibe.

>> If someone is posting issues, or telling you about stuff in irc, please
>> listen to them. Even if they are annoying. They will probably improve the
>> usability of your module quite a bit.

>> To really understand this though, I think we need anthropologists to live
>> with hackers, and write a whole book about it.

>> On Fri, Oct 12, 2012 at 9:52 AM, Tim Oxley <sec...@gmail.com<javascript:>
>> > wrote:

>> Yep, the idea of best practices is "do this unless you have a good reason
>> not to", which doesn't mean it's a blanket rule that must never be broken.
>> A guideline, not a rule.

>> The main issue with inconsistent sync/async functions is the behaviour
>> has low discoverability unless it's documented (unlikely), you read the
>> source, or you get gotcha'd by it.

>> -Tim

>> On Friday, 12 October 2012 08:46:52 UTC+10, Jimb Esser wrote:

>> Though process.nextTick() *itself* is fast, delaying calling the callback
>> until it gets through that queue can have large performance implications,
>> for example, in our case, we may have a tick of our physics simulation
>> queued up (which could take hundreds of ms), and if some logic has to go
>> through a few process.nextTicks, all interspersed with some other expensive
>> operations in between, this kind of API can lend itself to some poorly
>> performing side effects.

>> That being said, I do agree that it's generally "best practice" to do
>> this, but it's good to be aware that it's not always the best for
>> performance (in some of our own APIs, where we set them up to always call
>> the callbacks asynchronously, we have needed to add short-cuts in a couple
>> of cases where it had a significant impact on latency).

>> On Thursday, October 11, 2012 1:36:58 PM UTC-7, Adam Crabtree wrote:

>> It's a best practice because it helps those unfamiliar with the reasoning
>> to keep from shooting themselves or their users in the foot. There are
>> several ways that this may affect you, but a quick summary can be found
>> here:

>> http://howtonode.org/**understanding-process-next-**tick<http://howtonode.org/understanding-process-next-tick>

>> How slow is process.nextTick? A quick benchmark reveals it's not just
>> <1ms, but in fact is roughly 1µs (0.001ms for the lazy):

>> var i = 0, sum = 0
>> ;(function foo() {
>>   var t = process.hrtime()
>>   process.nextTick(function() {
>>     sum += process.hrtime(t)[1]
>>     if(++i<10000000) return foo()
>>     console.log('Average time: ', sum/i)
>>   })
>> })()

>> That being said, there are always exceptions to the rule, and if you
>> understand the tradeoffs and have a need to shave off µs, then go for it.
>> Chances are though, for the other 99.9% it's a micro-optimization (no pun
>> intended ;P). Again, this requires a special set of circumstances to be an
>> issue, but when it is, discovering that the cause was a cache hit and a
>> synchronous call to callback can be frustrating.

>> Cheers,
>> Adam Crabtree

>> On Thu, Oct 11, 2012 at 12:50 PM, Axel Kittenberger <axk...@gmail.com>wrote:

>> > I'd rather see client patterns that are immune to  callbacks being
>> called before the function returns sometimes.

>> Ditto!

>> We should encourage people to write callers that are good, rather than
>> libraries that deliberately waste performance and tell the callers
>> "its alright you wrote bad code, they have to put in a
>> process.nextTick anyway". And < 1ms can be a lot in some areas.

>> Document your function accordingly, if it guarantees a particular
>> callback/return order or not. In many situations, standard is,
>> callback immediately if you have all what is needed for the callback.
>> If the caller fucks up, that one should be fixed, instead of the
>> callee.

>> Or in other words, cure the problem, not the symptom.

>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines: https://github.com/joyent/**node/wiki/Mailing-List-**
>> 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<http://groups.google.com/group/nodejs?hl=en?hl=en>

>> --
>> Better a little with righteousness
>>        than much gain with injustice.
>> Proverbs 16:8

>>  --
>> 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<javascript:>
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en

>>  --
>> 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<javascript:>
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en

>>  --
>> 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<javascript:>
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en