淘小杰
https://github.com/node-modules/cfork/pull/103
Hi, can you add some detail documentation for project `engine-builds` ? I'd like to build the latest version for debugging, thank you!
先是报这个错误 ``` Undefined symbols for architecture armv7: ``` 添加armv7支持后程序可以启动了但是找不到里面的方法 ``` Invalid argument(s): Failed to lookup symbol (dlsym(RTLD_DEFAULT, sign_data): symbol not found) #0 DynamicLibrary.lookup (dart:ffi-patch/ffi_dynamic_library_patch.dart:33) ```
# 上篇 Node.js 诞生之初就遭到不少这样的吐槽，当然这些都早已不是问题了。 > 1、可靠性低。 > 2、单进程，单线程，只支持单核 CPU，不能充分的利用多核 CPU 服务器。一旦这个进程崩掉，那么整个 web 服务就崩掉了。 回想以前用 php 开发 web 服务器的时候，每个 request 都在单独的线程中处理，即使某一个请求发生很严重的错误也不会影响到其它请求。Node.js 会在一个线程中处理大量请求，如果处理某个请求时产生一个没有被捕获到的异常将导致整个进程的退出，已经接收到的其它连接全部都无法处理，对一个 web 服务器来说，这绝对是致命的灾难。 应用部署到多核服务器时，为了充分利用多核 CPU 资源一般启动多个 Node.js 进程提供服务，这时就会使用到 Node.js 内置的...
```c #define _GNU_SOURCE 1 #include #include #include #include #include using std::cout; static void test() { cout
Node.js发展到今天如此的受欢迎，除了自身强劲的性能优势外，也离不开node社区热情的开发者们贡献的超过100,000个模块，基本涵盖了项目开发中的方方面面，npm也让模块的开发与使用变的非常的方便，几行命令便能代替以前使用其他人开发的模块时复制粘贴等繁琐的操作。 使用Node.js开发项目时，会把用到的所有第三方模块写进package.json文件中。 ``` json "dependencies": { "address": "0.0.3", "body-parser": "~1.3.0", "bookshelf": "^0.7.7", "cookie-parser": "~1.1.0", "es6-promise": "^1.0.0", "express": "~4.4.3", "graceful": "~0.1.0", "knex": "^0.6.22", "lodash": "^2.4.1", "midway": "~1.3.4", "module-unique": "^1.0.7", "moment": "^2.8.1",...
大家都知道用Node.js搭建一个简单的http服务器是多么easy的事情，打开记事本贴几句脚本，ctrl+s一下，node server.js 一个http服务器就这样跑起来了，别看它简单，但性能丝毫不差。 ``` javascript var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello Worldn'); }).listen(1337, '127.0.0.1'); console.log('Server running at http://127.0.0.1:1337/'); ``` Node.js搭建的服务器性能如此给力确实让我很好奇它的内部是如何设计的，忍不住翻了翻lib下的代码。 深入了解过Node.js http模块的同学应该知道Node.js采用一个纯c写的http_parser来实现对http报文的解析，暴露到Node.js上的是一个HTTPParser对象，在Node.js中用下面一句代码即可拿到 ``` javascript...
单元测试在 Node.js 项目开发中的重要性就不言而喻了，项目一旦稍微大起来了就经常出现拆东墙补西墙的情况。这边修复了一个 bug，那边又不知道什么时候产生了一个新的 bug，越到后面没有经过完整的测试都不敢随便发布。 ## 代码覆盖率 测试的时候，我们常常关心，是否所有代码都测试到了。这个指标就叫做“代码覆盖率”（code coverage），它有四个测量维度。 - 行覆盖率（line coverage）：是否每一行都执行了？ - 函数覆盖率（function coverage）：是否每个函数都调用了？ - 分支覆盖率（branch coverage）：是否每个 if 代码块都执行了？ - 语句覆盖率（statement coverage）：是否每个语句都执行了？ 目前在 Node.js 开发中比较流行的测试覆盖率工具是 Istanbul。 > Yet another...
进程通信
### linux进程通信 - 管道 [http://www.ibm.com/developerworks/cn/linux/l-ipc/part1/](http://www.ibm.com/developerworks/cn/linux/l-ipc/part1/) - 信号上 [http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html](http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index1.html) - 信号下[http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html](http://www.ibm.com/developerworks/cn/linux/l-ipc/part2/index2.html) - 消息队列 [http://www.ibm.com/developerworks/cn/linux/l-ipc/part3/](http://www.ibm.com/developerworks/cn/linux/l-ipc/part3/) - 信号灯 [http://www.ibm.com/developerworks/cn/linux/l-ipc/part4/](http://www.ibm.com/developerworks/cn/linux/l-ipc/part4/) - 共享内存上 [http://www.ibm.com/developerworks/cn/linux/l-ipc/part5/index1.html](http://www.ibm.com/developerworks/cn/linux/l-ipc/part5/index1.html) - 共享内存下 [http://www.ibm.com/developerworks/cn/linux/l-ipc/part5/index2.html](http://www.ibm.com/developerworks/cn/linux/l-ipc/part5/index2.html) ### 进程间如何传递fd [http://www.lst.de/~okir/blackhats/node121.html](http://www.lst.de/~okir/blackhats/node121.html) > Unix socket magic >...
不知道小伙伴们日常 Node.js 开发中使用什么方式来调试的，小编从开始接触 Node.js 起就一直使用 Node Inspector，并且在第一次使用它时就已经深深迷上它了，没想到 Node.js 还可以这么调试，简直就是太神奇了，对从前端开发过来的同学来说简直不要太友好，以至于短时间内该项目很快就在github上积累过万star。 一般的功能小编就不说了，亲们可以自行查看官方文档。比较 Cool 的几个feutre 不知道亲们有没有感受过。 - Node Inspector 使用 webSocket 与 调试服务器通信，能够做到实时断点。 - 支持远程调试，在本地调试远程 Node.js 服务器，这意味着你能够远程调试各种运行 Node.js 的嵌入式设备。 - 能够像前端一样实时编辑正在运行的代码，并且能选择性的保存到原文件中。 - 文件还未被加载到...