Wasn't the motto and the whole idea about Node.JS: Microseconds matter?
On Fri, Oct 12, 2012 at 2:34 PM, Tristan Slominski
tristan.slomin...@gmail.com wrote:
On Thursday, October 11, 2012 1:24:12 AM UTC-5, Tim Oxley wrote:
Great writeup! Most these points are right on.
Thanks Tim! Positive
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
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
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
we should also build tools to enable collaboration. I'm not sure what those
would look like.
Solving the its hard to discover modules problem is a lot easier in
comparison.
On Fri, Oct 12, 2012 at 12:39 PM, Dominic Tarr dominic.t...@gmail.comwrote:
It's really about collaboration. The answer
My problem is not with using Travis, it is a warning. Travis does sometimes
fail, and we have had situations where commits cause tests to fail
according to travis while all local tests run on all machines we test. The
cause of this has generally been the problems mentioned.
On Friday, October
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
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
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
On Thursday, October 11, 2012 1:24:12 AM UTC-5, Tim Oxley wrote:
Great writeup! Most these points are right on.
Thanks Tim! Positive feedback is welcome.
But I've also been severely bitten by
the performance and race-condition implications of this.
...
I've seen many cases where
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
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 waldron.r...@gmail.comwrote:
On
Great writeup! Most these points are right on.
Thanks Tim! Positive feedback is welcome.
But I've also been severely bitten by
the performance and race-condition implications of this.
...
I've seen many cases where it's better and simpler to
just call right away.
Can you give
Probably true especially regarding code complexity, but disk space is
cheap. Though, the time to install all that stuff is a real bummer. If `npm
install` was faster, would this be less of an issue?
Disk is cheap, but if you actually do end up loading all the libraries at
once you can
Inconsistent sync/async
When functions are sometimes sync and sometimes async lead to hard to use
apis, subtle bugs and more error handling wrapper code. Always wrap
callbacks in process.nextTick if they're not behind an async operation.
Simple.
As others have written, if you have to have to
I think what the OP means, is that library authors should wrap
*synchronous* callback calls in process.nextTick, which is a best practice.
If you're saying (possibly) that it's not, then I disagree.
Library code should be predictable, not synchronous in some cases and
asynchronous in others.
I think what the OP means, is that library authors should wrap
*synchronous* callback calls in process.nextTick
…yep, I mean wrap synchronous callbacks if there's any possibility the
function might execute asynchronously… though Tim Caswell suggests
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
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
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
Just beware of Travis CI failing for situations that are beyond your
control. Missing C libraries, OS issues, and external resource needs can
all be problematic. Also I have noted at least in the past sometimes travis
fails to provision VMs appropriately. Running tests in your environment is
So, here's part of a totally subjective, non-comprehensive list of
frustrations and best practices I've been collecting. Some are based on
personal experience and others are ideals from the node community that I'm
trying to incorporate.
I'm looking for more tips like this. Please share your
That's pretty awesome. There's a couple of items I'd like to discuss, the
first one being ...
Always wrap callbacks in process.nextTick if they're not behind an async
operation. Simple.
This doesn't seem necessary to me and it seems inefficient and dangerous.
I make sure to write in a style
Always wrap callbacks in process.nextTick if they're not behind an async
operation. Simple.
Oh, of course… to clarify:
If a module is possibly going to execute an async operation, ensure any
otherwise synchronous callbacks are inside in process.nextTick. i.e. If
it's sync it should always
OK, I realize now that all your points were about writing good modules. I
took your point from the view of the module user, not the author. I really
should read more carefully.
On Wed, Oct 10, 2012 at 12:14 PM, Tim Oxley sec...@gmail.com wrote:
Always wrap callbacks in process.nextTick if
Great writeup! Most these points are right on. I take issue with a
couple of them and have a different opinion. (That's right, this is
my opinion, not saying you're wrong)
## Inconsistent sync/async
When functions are sometimes sync and sometimes async lead to hard to
use apis, subtle bugs
26 matches
Mail list logo
