Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
nodejs
Home
+ new post
About this group
Join this group
Message from discussion peeves & current best practices?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ted Young  
View profile  
 More options Oct 11 2012, 5:14 pm
From: Ted Young <t...@radicaldesigns.org>
Date: Thu, 11 Oct 2012 14:14:10 -0700
Local: Thurs, Oct 11 2012 5:14 pm
Subject: Re: [nodejs] peeves & current best practices?
Print | View thread | Show original | Report this message | Find messages by this author

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 <atcrabt...@gmail.com> 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 <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
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google