Jake, it is tempting to think that the there is a technical solution to
every social problem.

In a way, git, and github is like this.

But there is so much more that, as coders, we are only starting to
discover.
Musicians probably have a lot of experience in this area.

On Sun, Oct 14, 2012 at 8:03 PM, Tim Oxley <[email protected]> wrote:

> Excellent. This is a far more positive angle. Point taken.
>
>
> On Saturday, 13 October 2012 05:40:17 UTC+10, Dominic wrote:
>
>> 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 <[email protected]>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 <[email protected]> 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/**understan**ding-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 <[email protected]>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 [email protected]
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> 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<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 [email protected]
>>> 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>
>>>
>>>
>>>  --
>>> 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 [email protected]
>>> 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>
>>>
>>>
>>>  --
>>> 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 [email protected]
>>> 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>
>>>
>>
>>  --
> 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to