61–66 of 66 posts
Hm. I am just wondering if it wouldn't be better if Ryan could make living of Node and therefore could stay to work on it. How does one make living of Node ... em, charge for it, maybe? Is it so radical to suggest that Node could be a paid product.
Earlier quoted context omitted.
> You can open a file with O_EXCL if you pass in the open flags as a number. (You can find them on require("constants"), and they need to be binary-OR'ed together.) This isn't documented. It should be. It should probably also be exposed in a cleaner way. That's great to know. Obviously I'm just following the docs. > Most of the rest of what you describe is APIs that need to be polished and refined a bit My concern is…
O_EXCL is in for 0.8: https://github.com/bnoordhuis/node/compare/O_EXCL flock() is not trivial to do in a portable way. For a unix-only flock(), check out the fs-ext addon. Same for mktemp. I wouldn't be opposed to either being in core if it could be done in a clean way, but this is just adding another knob that can be done with an addon easily enough. If you care more about having flock() than about writing portable…
Perl, Python and Ruby manage it.
> For a unix-only flock(), check out the fs-ext addon
Which I wrote.
> Of course we'll be "dealing with Node.js security bugs for a VERY long time", because we'll be using Node.js for a very long time.
That's not quite what I meant - I mean that people right now are writing temp files in LOTS of Node.js applications in an insecure way. It's good that O_EXCL is available, I'll try and submit a patch to node-temp, but really temp file creation should be in core (amongst other things).
This isn't a vague suggestion. There are COUNTLESS security bugs created every day by insecure temp file creation. Let's see, from npm these packages have security bugs because they rely on the insecure node-temp: ShipItJS assetgraph-builder confy filerepl gracie joose js-loader muffin nerve redisfs.
Earlier quoted context omitted.
One of the better arguments I can think up against the npm coding style is probably found in the Matador framework, specifically its router: https://github.com/Obvious/matador/blob/master/src/router.js Note: I actually rather like Matador. I just find this particular style--high density, no semicolons--much harder on my eyes. I'm sure many others can read it better than I can, however.
Leaving aside the global variable, I think this example's biggest issue is the complete lack of whitespace and the big stack of chained calls (which I'm not personally a fan of, but your house, your rules :)) - this is it with a few reader-sympathetic newlines added: https://gist.github.com/1710254 Personally, I find using comma-first and omitting semicolons except where required for ASI reduces the amount of noise d…
Commas first cause more noise on the left side; they distract me because I'm used to reading English and I'm used to reading code that's written in English based programming languages where people generally agree that punctuation belongs on the right side.
Honestly though, I care more about comments than coding style, something that the Joyent guys don't seem too fond of despite the complexity of the Node.js code. I just don't get it.
Earlier quoted context omitted.
One of the better arguments I can think up against the npm coding style is probably found in the Matador framework, specifically its router: https://github.com/Obvious/matador/blob/master/src/router.js Note: I actually rather like Matador. I just find this particular style--high density, no semicolons--much harder on my eyes. I'm sure many others can read it better than I can, however.
Leaving aside the global variable, I think this example's biggest issue is the complete lack of whitespace and the big stack of chained calls (which I'm not personally a fan of, but your house, your rules :)) - this is it with a few reader-sympathetic newlines added: https://gist.github.com/1710254 Personally, I find using comma-first and omitting semicolons except where required for ASI reduces the amount of noise d…
IMO, the whitespace isn't so much an issue as the chained calls. Once you exceed about 5-8 lines of method chaining where your eyes now have some difficulty lining up the indentation (although Sublime really helps in this regard), the lack of visible line terminators can be somewhat obnoxious to someone who comes from a background of C/C-inspired languages.
I agree with Isaac's assertions that it's important to understand line terminating, and I also agree with his other statements regarding pants. I prefer to wear pants unless I'm hanging out in my Python room. It's just easier on my eyes.
Hm. I am just wondering if it wouldn't be better if Ryan could make living of Node and therefore could stay to work on it. How does one make living of Node ... em, charge for it, maybe? Is it so radical to suggest that Node could be a paid product.
Ryan and Isaac were both hired by Joyent after becoming established in the node community. Everyone seems happy with this being an open-source project.
I didn't say it should be closed-source. Paid doesn't preclude open source.
Earlier quoted context omitted.
> You can open a file with O_EXCL if you pass in the open flags as a number. (You can find them on require("constants"), and they need to be binary-OR'ed together.) This isn't documented. It should be. It should probably also be exposed in a cleaner way. That's great to know. Obviously I'm just following the docs. > Most of the rest of what you describe is APIs that need to be polished and refined a bit My concern is…
I disagree that it is "huge" that flock() is missing; if you are relying on advisory (emphasis on advisory) file and record locking to implement coherence, then your architecture is likely an accident waiting to happen -- it's a highly problematic interface for many reasons. Of course, if you really need it, use fs-ext as Isaac mentioned -- NS more generally, if you need some system functionality that isn't present i…
smf(5) can get you part of the way there, but not if you're (say) writing some system bits that you need to deploy on platforms in addition to SunOS. Plus, if you can avoid depending on any not-just-pure-JS modules then you can deploy one tree onto all of your platforms without additional build steps, C++ compile/ABI issues, etc.