There is a technical solution to NIH. I have a new project scaffolding tool which I give a project name & description.
I'm sure I can get it to auto generate a README saying "I SUFFER FROM NIH" if it finds a module that already matches the description. On Sun, Oct 14, 2012 at 2:20 PM, Dominic Tarr <[email protected]>wrote: > 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 > -- 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
