Great, I agree, especially on the basic CI since travis makes it so simple.
It amazes me how long some projects sit with failing travis tests… when failure is the norm it reduces the benefit of having CI in the first place. Time constraints are probably the issue here, though perhaps the solution is "if you can't get your changes passing, push them onto a separate branch and restore the main branch to a passing state". Again, the primary benefit here is inspiring confidence in contributors and module consumers. - Tim On Friday, 12 October 2012 07:14:26 UTC+10, tedsuo wrote: > > All good points! I would add: > > *When in doubt, use callbacks* > One gotcha that only occurs once you are well into a project is having a > synchronous operation that returns a value turn into an asynchronous > operation that requires a callback or event notification. This can create > an untold amount of refactoring, as any code that depended on this > operation may have to change *it's* api to use a callback, and so on up > the chain. That can add major drag to your development. So, when in > doubt, use a callback as your api. > > *Basic CI is too easy, there's no excuse not to use it* > You can get your module tests up and running on travis-ci in like, 5 > minutes. If it takes longer than that, there's probably some kind of > deployment issue you need to deal with. So at minimum you should be using > travis-ci or something similar for all production-ready modules. I feel a > lot better about modules and services if I see them running on CI > successfully. > > Ted > > On Oct 11, 2012, at 1:36 PM, Adam Crabtree <[email protected]<javascript:>> > 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 > > 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]<javascript:> > > 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 >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> 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 [email protected] <javascript:> > To unsubscribe from this group, send email to > [email protected] <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 [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
