4 ms·

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 expec

by felixge 16y ago

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.

alnayyir 16y ago
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-wlan:480f4dd5-50a0-40c6-aa60-4afccbdd56cb 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.
- felixge 16y ago
  Why are you trying to discredit everything I have done in the last ~5 years?
  - thomasdavis 16y ago
    haters gonna hate keep it up!
  - alnayyir 16y ago
    >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.
- mkrecny 16y ago
  Incredibly harsh and unnecessary. Check yourself.
mononcqc 16y ago
''' 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 :)
- mkrecny 16y ago
  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 https://github.com/indexzero/forever

by felixge 16y ago

alnayyir 16y ago

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-wlan:480f4dd5-50a0-40c6-aa60-4afccbdd56cb 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.

felixge 16y ago
Why are you trying to discredit everything I have done in the last ~5 years?
- thomasdavis 16y ago
  haters gonna hate keep it up!
- alnayyir 16y ago
  >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.
mkrecny 16y ago
Incredibly harsh and unnecessary. Check yourself.

mononcqc 16y ago

''' 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 :)

mkrecny 16y ago
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 https://github.com/indexzero/forever