[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5},"routes/user.$name.collections",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20},"topics",[36,37],"user",{"_21":22,"_13":14,"_23":24,"_25":26,"_27":28,"_29":30,"_31":32,"_33":16,"_34":35},"loginname","nicolazj","page",1,"limit",20,"total",2,"id","4480","avatar_url","http://www.gravatar.com/avatar/0a778adf111306cc8ab17f118d0f1d5d?size=48","githubUsername","","create_at","2012-07-29 14:51:51.093","score",5,"topic_count",0,"reply_count","is_star",false,{"_21":58,"_39":59,"_41":-5,"_42":60,"_44":61,"_46":62,"_48":35,"_49":35,"_33":63,"_51":64,"_27":65,"_54":66},{"_21":38,"_39":40,"_41":-5,"_42":43,"_44":45,"_46":47,"_48":35,"_49":35,"_33":50,"_51":52,"_27":53,"_54":55},"112","author_id","12","tab","content","node.js是基于Google V8的，而Google V8有一个Eclipse的调试插件，这个插件同样也支持node.js。\r\n

1、安装Eclipse debugger for V8

\r\n
这个，用过Eclipse的应该都知道，不过还是简单说下吧：\r\n
\r\n
$\"wps_clip_image-13545\"$ \r\n
\r\n
选择“Install New Software”\r\n
\r\n
$\"wps_clip_image-13957\"$ \r\n
\r\n
点“Add”\r\n
\r\n
$\"wps_clip_image-14038\"$ \r\n
\r\n
Location为： http://chromedevtools.googlecode.com/svn/update/dev/\r\n
Name你喜欢，整一个方便你记忆的就好。\r\n
\r\n
点击确定后，在“Work with“选择你刚才添加的站点：\r\n
\r\n
$\"wps_clip_image-14557\"$ \r\n
\r\n
然后选择“Chromium JavaScript Remote Debugger”，然后一直下一步，安装完后会提示重启Eclipse，重启Eclipse后就可以开始调试了。\r\n

2、怎样调试Nodejs？

\r\n
从插件名称中的“Remote”可以预想到这是一个远程调试的工具，大概的流程就是node开一个tcp的调试端口，然后这个调试工具通过这个tcp端口来和node通讯实现调试。\r\n
\r\n
要启用node的调试端口，在执行node脚本的时候需要添加 –-debug 参数：\r\n

\r\n

node --debug[=port] NodeApp.js\r\n
\r\n
or\r\n
\r\n
node --debug-brk[=port] NodeApp.js

\r\n

\r\n
其中port为开启的调试端口，默认为5858.\r\n
--debug和--debug-brk的区别在于，--debug执行脚本的时候会直接运行该脚本，而--debug-brk执行脚本的时候，并不会马上执行，而是等待调试器的连接，然后按调试器的指令来执行。\r\n
\r\n
我们写个简单的代码来用于调试：\r\n
\r\n
$\"wps_clip_image-17441\"$ \r\n
\r\n
然后用 node –debug hello_world.js 来运行：\r\n
\r\n
$\"wps_clip_image-17588\"$ \r\n
\r\n
可以看到输出一行：debugger listening on port 5858\r\n
5858为默认端口，你也可以用 --debug=5859 来指定不同的端口\r\n
\r\n
好，现在node的调试模式已经运行起来了，我们去配置Eclipse来连接到node并进行调试。\r\n
\r\n
首先我们要到debug config里面去添加一个新的V8 VM的调试配置：\r\n
\r\n
$\"wps_clip_image-18682\"$ \r\n
\r\n
右键，选择“new”来新建一个配置项：\r\n
\r\n
$\"wps_clip_image-18917\"$ \r\n
\r\n
因为我们刚才node起的调试端口为默认的5858，所以这里我们的端口就是5858，名称我们定为“Node-5858”。\r\n
\r\n
然后点debug开始调试，或者你使用下面的方式开始调试：\r\n
\r\n
$\"wps_clip_image-20213\"$ \r\n
\r\n
调试模式大概会是这样：\r\n
\r\n
$\"wps_clip_image-20478\"$ \r\n
\r\n
（注：这是调试视图，点击右上角的臭虫按钮。如果你的Eclipse上没有这个按钮，请点击上图右上角臭虫左边的添加按钮，找到debug然后添加就可以）\r\n
\r\n
在调试模式连接成功后，你会在你的“Project Explorer”里面看到多了一个“Node-5858”（刚才debug config里面设置的名称）的项目，里面的文件都是调试的文件或者调试的文件require进来的文件。\r\n
打开这些文件，你就可以在里面加断点开始调试了。例如上图的第8行加了一个断点，则每次在浏览器访问的时候都会进入这个断点。\r\n
\r\n
$\"wps_clip_image-21004\"$ \r\n
\r\n
其他的调试和你平时用Eclipse调试其他代码是一样的。\r\n
Eclipse的调试快捷键是，F5单步进入，F6单步跳过。\r\n
\r\n
最后说一下 --debug-brk 方式启动的调试模式：\r\n
\r\n
$\"wps_clip_image-22682\"$ \r\n
\r\n
可以看到仅仅是输出了一行“debugger listening on port 5858”而已，后面并没有继续输出“Server running at …..”。\r\n
这是因为用启动的调试模式并不会马上执行代码，而是会等待调试器的连接（可以理解为在hello_world.js的第一行加了断点），具体还是各位童鞋自己实践吧。\r\n
\r\n
参考： https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-Debugger\r\n
\r\n
","title","用Eclipse调试Node.js代码","last_reply_at","2014-03-11 02:10:13.282","good","top",25,"visit_count",37218,"2011-05-06 11:13:54","author",{"_13":56,"_23":57},"qleelulu","http://www.gravatar.com/avatar/0bfd7fd3d47fe2a02375ab23ac978802?s=48","1114","4332","http://blog.factual.com/factuals-api-a-good-fit-for-node\r\n(作者：Jeff Su 译者：Forrest Cao)\r\n\r\n大家都听说过Node了。快、可扩展、并发性，这些都是它的特点。在Factual公司，让我们感到自豪的是，往往可以找到正确的工具来完成工作，从jquery到hadoop，postgresql到mongodb。更幸运的是，我们有种工程师文化，鼓励我们实验一些新的用法。但是，每种投入产品环境的技术，都必须经过严格的检验和衡量。我们考察的方面包括敏捷性、性能、稳定性和成本。\r\n\r\n关于Node，有很多开发者被误导，以为用上了node，你就马上拥有了并发性和性能。事实是，你得配合各种技术，才能解决一个非常特别的问题。那么，Node到底能解决什么问题？它是怎么解决的？必须付上什么代价？下面介绍的就是我们的一些简要的经验，以及我们是怎么使用Node的。\r\n\r\n我们产品的第一个迭代是一个可以互动的网格(grid)，用户可以上载、更新、重组我们的数据，并把数据表(dataset)展现为各种有用的表现形式(visualization)。那是一个复杂的web app，我们用了很多JavaScript。那时我做了一个Ruby库，给JavaScript加上了一点基本的面向对象编程的特性（现在，这个库叫做Mochiscript）。\r\n\r\n从那以后，我们的业务重心偏向提供更有质量的数据，并通过API快速传递这些数据。这个业务重心的转移带来了一系列新的需求。我们现在可以支持的相应速度是：200毫秒一个请求，包括用户认证，权限检查，实时统计和查询处理。我们必须用一个敏捷的语言实现它，因为需求会不断地增加变化。\r\n\r\n当时由于我们都擅长Ruby，我们的第一个原型是用轻量级的Sinatra实现的。那个版本的表现的还不错，可以支持同时120个连接，最小相应时间20毫秒。但是从我们所需要支持的流量来看，这个方案的扩展性还不够好。\r\n\r\n然后我们考虑了Java和Clojure（这两种语言都正应用在Factual的其他项目中），但是最后我们决定试试Node，因为敏捷的需要，也因为我们对JavaScript的熟悉。\r\n\r\n首先我们把Mochiscript从Ruby导到Node，看看Google的V8引擎有多快，然后，就决定写一个原型，让它来跟Ruby版本的原型竞争上岗。差距是明显的！Node版本的性能是，可以支持同时400个连接，最小相应时间10毫秒。在接下来的几个月里，原型变成了产品，Node的高性能和Mochiscript组织代码的优越性帮了我们大忙。我们又做了一些优化，现在的相应时间已经可以达到最小5毫秒。\r\n\r\n在尽情歌颂Node之前，先罗列一下我们付上的代价：\r\n\r\n 1. 这个框架还不够成熟（在他们的早期http库中，我们发现了一个socket泄露的bug）\r\n 2. 像意大利面一样杂乱的代码：到处都是callbacks。这个问题可以通过一些办法来解决，比如：一个好的设计，遵循一些编程规范，等等。但即便如此，还是不轻松。\r\n 3. 有时候调试程序会让人抓狂（大部分是因为上面两个原因）\r\n\r\n为什么Node适合我们的原因如下：\r\n\r\n 1. 我们以前的性能瓶颈在IO\r\n 2. 我们每个请求需要用到的CPU很少\r\n 3. 我们可以用事件驱动编程，来帮我们大量使用缓存\r\n\r\n前面两点理由并不新鲜，而这两点的结合正是Node的强项。这两点完美地适用于我们的情况。而第三点，是我们想着重介绍的。\r\n\r\n对于很多工程师习惯的方式来说，用Node写程序需要有点儿思路转换。那些Callbacks会失控的。然而，Javascript提供的闭包带来了新方法。对我们很有用的一个方法，可以用来减少多余的数据库访问。\r\n\r\n考虑一下下面这个例子──从数据库中获得用户数据：\r\n\r\n var connect = require('connect');\r\n var users = require('./lib/users');\r\n var app = connect.createServer();\r\n \r\n app.get('/users/:userId', function (req, res) {\r\n users.get(req.params.userId, function (err, user) {\r\n res.end(\"Welcome \" + user.name);\r\n });\r\n });\r\n \r\n app.get('/stats', function (req, res) {\r\n res.end(JSON.stringify(counts));\r\n });\r\n\r\n现在让我们加入一个缓存层：\r\n\r\n var connect = require('connect');\r\n var users = require('./lib/users');\r\n var app = connect.createServer();\r\n \r\n var userCache = {};\r\n function getUser(id, cb) {\r\n if (id in userCache) {\r\n cb(userCache[id]);\r\n } else {\r\n users.get(id, cb);\r\n }\r\n }\r\n \r\n app.get('/users/:userId', function (req, res) {\r\n getUser(req.params.userId, function (user) {\r\n res.end(\"Welcome \" + user.name);\r\n });\r\n });\r\n既然我们用到了缓存，就得考虑怎么清除它。Redis的pubsub功能绝对适用这种用法，我们用它来实时更新缓存：\r\n\r\n var connect = require('connect');\r\n var users = require('./lib/users');\r\n var app = connect.createServer();\r\n var redis = require('redis').createClient();\r\n \r\n var userCache = {};\r\n function getUser(id, cb) {\r\n if (id in userCache) {\r\n cb(userCache[id]);\r\n } else {\r\n users.get(id, cb);\r\n }\r\n }\r\n \r\n redis.subscribe('update-user', function (id) { delete userCache[id] });\r\n \r\n app.get('/users/:userId', function (req, res) {\r\n getUser(req.params.userId, function (user) {\r\n res.end(\"Welcome \" + user.name);\r\n });\r\n });\r\n\r\n再来加点儿好玩的东西──访问统计：\r\n\r\n var connect = require('connect');\r\n var users = require('./lib/users');\r\n var app = connect.createServer();\r\n \r\n var userCache = {};\r\n var counts = {};\r\n function getUser(id, cb) {\r\n if (id in userCache) {\r\n cb(userCache[id]);\r\n } else {\r\n users.get(id, cb);\r\n }\r\n }\r\n \r\n app.get('/users/:userId', function (req, res) {\r\n getUser(req.params.userId, function (user) {\r\n if (req.url in counts) {\r\n counts[req.url]++;\r\n } else {\r\n counts[req.url] = 1;\r\n }\r\n \r\n res.end(\"Welcome \" + user.name);\r\n });\r\n });\r\n\r\n这样的模式是Node或者JavaScript这样事件驱动模型的一个副产品，还真是给了我们不少灵活度，我们可以方便地加入缓存、实时统计、还有实时配置等等。根据我们的经验，用redis或者memcache来做缓存也是很不错的，但是我们的目标是榨干Node服务器的最后一滴性能，所以我们要限制任何多余的操作（甚至尽量不去parse json）。\r\n\r\n我们理解Node不是所有问题的解决方案。但在我们的应用里，Node是一个绝配。我们大概从一年前开始适用Node，这一年来Node获得了长足的长进，而我们也从Joyent和开源社区获得了很多帮助。我们开始在其他各种内部项目中适用Node，渐渐地这成为一种通用解决方案而不再小众。我鼓励各位开发者来探索Node，看看它是否适合你的问题。至少，它会让你思考IO，以及你要花多少时间等待IO。","Factual API：Node的绝配应用","2012-07-27 07:23:58.048",9,7998,"2012-07-13 08:33:32.727",{"_13":67,"_23":68},"forrestc","http://www.gravatar.com/avatar/d63f8101c0c85dd2472eff0300e45312?size=48"]