Hacker News Reader

Hi, I'm the author of the guide.

Thanks for your feedback. You made some great points about real time systems, I'll try to rework that section.

> Do not expect me to blindly follow your standards just because you said so.

This reminds me of school : ). The difference here however is that I don't expect anybody to do anything, and participation is entirely voluntary.

In this case I didn't explain my choice of style because most people in the JS community would consent with it, and there has been lots of discussion about this in the past.

> In the deployment part

That's still a work in progress. I didn't choose nohup because I feel screen is conceptually slightly simpler. However, a real deployment section is coming in the future.

> I'd also generally be interested in knowing how you'd avoid spaghetti callback hell from the approach used in node.js, but that doesn't seem to be part of the guide. This is a work in progress, and I am not holding this against the author.

That will be the subject of a guide by itself as well.

Why are you writing about "soft real time" when you don't seem to have done any work in RTOS/embedded?

Your listed project is transloadit, which is a file uploader that does some sort of magic I don't care about. (I'm provincial.)

You also appear to be available as a node.js consultant. That's a first for me. I figured the only "node.js consultants" were ryah and anybody you could catch awake on Freenode.

A burgeoning ecosystem is good. It's not good when virtually every proponent of Node.js I run into makes wild claims.

Checked your submissions, I see in this order from chronological proceeding towards the final entropic state of the universe:

1. jQuery >? *

2. Git

3. Node.js

4. Node.js

5. Node.js

6. Transloadit file jobber thingie (written in JS, on Node.js)

7. Javascript (This is what Node.js is written in, FYI)

8. TDD @ Transloadit (written in JS, on Node.js, Church of the GoF)

9. Realtime encoding - over 150x faster

As easily as I could outright crucify you for butchering the word "realtime" here, I'll simply spare you the trouble and do a text-replace that'll fix your solipsism simulator article (blog)

s/realtime/buffered/g

'Fraid that won't work for your video though. You'll have to fix that yourself. Also, please provide full transcripts (linked, in-line, doesn't matter) in future. Not all of us are hearing.

And to cap it:

http://debuggable.com/posts/hacking-a-commercial-airport-wla...

Illustrious real-time hacking, that.

This is why we programmers don't deserve to be called engineers, not yet.

Code is art, wondrously so, but we're lacking a rigor and consistency of competence that could be there.

Why are you trying to discredit everything I have done in the last ~5 years?

haters gonna hate

keep it up!

>Why are you trying to discredit everything I have done in the last ~5 years?

I'm not, I'm trying to instill caution and judgment in the use of terminology that has real meaning.

Don't claim something is real-time when it is not. You are misleading people.

By all means, keep hacking. I have nothing against you or your work.

Incredibly harsh and unnecessary. Check yourself.

''' In this case I didn't explain my choice of style because most people in the JS community would consent with it, and there has been lots of discussion about this in the past. '''

Then link to the discussions, explain why it is obviously right, etc. Some items like where to put braces can just be a community thing, but "don't use prototype-based features of a prototype language" might warrant more explanations, even if they are obvious.

''' That's still a work in progress. I didn't choose nohup because I feel screen is conceptually slightly simpler. However, a real deployment section is coming in the future. '''

I can understand choosing the conceptually simpler option. If it's not the right one, at least provide a resource pointing you towards the right one.

This might be a bit much to ask, but try to consider the cost of it to the people reading. Will they have to learn a better way on their own? Are you spreading misinformation or just incomplete one? The idea here is to save work to your readers, not you. Readers don't really care what is hard or not; most of the time, they just want great docs. This is a principle I try to apply in Learn You Some Erlang, and so far it has worked well to me. YMMV.

''' That will be the subject of a guide by itself as well. '''

Good to know :)

I'd suggest taking a look at the 'forever' module by indexzero for deployment. It has a bunch of node-specific neat features and keeps your process persistent... https://github.com/indexzero/forever

re: cutting down on callback nesting / spaghetti code.

It can be hard to avoid; and having the community put together a PEP-8 style "best practices" to avoid creating nested code is one of my fondest dreams.

That said, I've written my fair share of [spaghetti code](https://github.com/chrisdickinson/tempisfugit/blob/master/li...) in Node, mostly because JavaScript seems to lend itself to slapping together nested callbacks without slapping you on the wrist for writing unreadable code.

In my experience, the best way to cut down on spaghetti code is to design your API around the [EventEmitter](http://nodejs.org/api/events.html#events.EventEmitter) object. Consider this adaptation of the linked spaghetti code: https://gist.github.com/f8533ff57844b1e54558

Note that in the application code, there are no nested callbacks -- they're merely concerned with validating the incoming data and passing the baton on to the next responder. Bonus points: the methods are in the order of their ideal execution. Clients using the code can just do the following:

    var validator = new RepoPathValidator(path);
    validator.on('data', function(repoData) {
        // do whatever needs to be done with the repo.
    });

    // redirect all errors to console.error
    validator.on('error', console.error.bind(console));

I'm very fond of using this method to destroy nested code -- I'm not sure how it's thought of in the community at large, though (part of the reason I'm so eager for the community to put together the aforementioned PEP-8 style "best practices" guide!)

I must be missing something, but how is EventEmitter helping you get rid of the nested code in your examples? It looks like changing all the anonymous callbacks to named functions, and then using the function names as the callbacks is what made the code more readable. EventEmitter wasn't necessary to do that, right?

Yes and no -- it's not absolutely necessary; I could've written it similarly without turning the callback-accepting functions into emitter-returning functions. It would have felt gross to do so, though. The downside I see with using straight callbacks that accept error and data arguments is that they conflate the logic of what that callback is actually attempting to do with the error-checking of the calling function. For example, my `baseDirOkay` method shouldn't care whether or not the calling `fs.stat` function succeeded or failed -- it should only care that the data it was passed is or isn't a directory. It shouldn't be called at all if the path was not valid. With an EventEmitter api, I can rely on the emitter itself to tell me whether or not to even call my `baseDirOkay` function, instead of having to conflate that logic with my method.

This seems like a tiny gain in readability, but it means that I don't have to make a decision between putting the error/success logic of `fs.readFile` in my method (where it does not go) and my calling function (where it probably does not go, and where it would incur unnecessary nesting -- and the finagling of the `this` variable that that incurs).

This may just be my taste -- but I find designing around (and reasoning about) EventEmitter-type API's much easier.

> ''' Another great aspect of node.js is the ease at which you can develop soft real time systems. By that I mean stuff like twitter, chat software, sport bets or interfaces to instant messaging networks. '''

Is there any evidence that this is actually true?

> ''' Combining this with node's radical model of non-blocking I/O, you have to try very hard to create a sluggish application. '''

NodeJS's model is hardly radical, it's several decades old. And it's very easy to create sluggish Node, just use a while loop.

EDIT: The relative instability of Node (as a codebase) is also left out it seems.

  > I'd also generally be interested in knowing how you'd avoid spaghetti callback hell

Here's a great article on this, especially the section on how to put your callbacks in sequence:

http://stella.laurenzo.org/2011/03/bulletproof-node-js-codin...

And here is the HN discussion: http://news.ycombinator.com/item?id=2368658

See esp.: http://news.ycombinator.com/item?id=2370303

"My understanding was that you actually have to be careful not to write code that runs for too long, in order to avoid messing up your request times by ruining the cooperative scheduling scheme used in the language."

That is my understanding as well - because a long running task will block everything, you have to be MORE careful in node.js than in a traditional threaded environment. I actually think that this model works really well in 10% of applications, and a threaded model is a better choice in 90% of applications.

I also believe 'less mature developers' see, 'wow, server side javascript', get excited by that, and don't put enough attention on the more important architectural differences of node.js

Are there any "traditional" server side JavaScript environments?

I did find this:

http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS...

which I will probably work through at some point, I'd really like to use JavaScript on the server but I'm not sure if node.js is a good fit.

Yes, this is a real pain point, because that's exactly why you need everything to be non-blocking in the libraries you are using with something like node.js (things like twisted in python have exactly the same issue).

Not only do you need non-blocking code for things like database access, but maybe more subtly, you need to be non-blocking for anything which is potentially CPU heavy. Case in point: encoding a payload in say xml or json. If you have a response which are big enough that they need say 20 ms to encode, all response whose processing have started but not yet finished will see a 20 ms additional delay. Now, you can incrementally encode into json by inserting new "scheduling points" at regular intervals, but doing this for say zlib compression, not so easy.

Not that I have a lot of experience, but IMO, async code should be reserved to the least amount of code possible, because everything becomes a bottleneck. And good luck trying to profile your async application with all those callbacks when you have performance issues...