博客园_lulu Studio

用OpenCv来做人脸识别

2012-02-08T14:10:00Z

参考这篇文章： http://tech.idv2.com/2012/01/20/face-detection-with-python-opencv/

python比较简单，只需安装 python-opencv 就行：

$ sudo apt-get install python-opencv

python的实现也很简单，参考：http://opencv.willowgarage.com/documentation/python/objdetect_cascade_classification.html

代码：

#!/usr/bin/python
# -*- coding: UTF-8 -*-

# face_detect.py

# Face Detection using OpenCV. Based on sample code from:
# http://python.pastebin.com/m76db1d6b

# Usage: python face_detect.py <image_file>

import sys, os
import cv
from PIL import Image, ImageDraw

def detectObjects(image):
"""Converts an image to grayscale and prints the locations of any faces found"""
storage = cv.CreateMemStorage()

cascade = cv.Load('haarcascade_frontalface_alt.xml')
faces = cv.HaarDetectObjects(image, cascade, storage)

result = []
for (x,y,w,h),n in faces:
result.append((x, y, x+w, y+h))

return result

def process(infile, outfile):

image = cv.LoadImage(infile);
if image:
faces = detectObjects(image)

im = Image.open(infile)

if faces:
draw = ImageDraw.Draw(im)
for f in faces:
draw.rectangle(f, outline=(255, 0, 255))

im.save(outfile, "JPEG", quality=100)
else:
print "Error: cannot detect faces on %s" % infile

if __name__ == "__main__":
process('input.jpg', 'output.jpg')

注：haarcascade_frontalface_alt.xml 可以在 https://github.com/talvarez/Face.js/tree/master/cascades 找到

Node.js的话，有一个叫Face.js的项目，对OpenCv做了简单封装，地址是： https://github.com/talvarez/Face.js
这个需要先安装OpenCv库，目前版本是2.3.1，按照可以参考： UBUNTU 下编译安装opencv 2.3.1

Face.js的具体的示例代码可以在Face.js里面的example里面找到，这里贴个简单的：

var Face = require('../build/default/face.node'),
detector = new Face.init();

detector.img = './samples/frame1.png';
detector.maxsize = 20;
detector.pathto = '../cascades/'

detector.oncomplete = function(faces){
console.log("I found " + faces.length + " faces");
for(var i = 0; i < faces.length; i++) {
console.log(faces[i].x, faces[i].y, faces[i].width, faces[i].height);
}
};

detector.run();

最后贴张识别后的图：

本文链接

linux下SublimeText的中文输入法问题之解决方案

2011-12-30T14:31:00Z

推荐使用dev版： http://www.sublimetext.com/dev

先说说中文显示的问题：

找一个支持中文显示的字体，然后修改配置 Preference - File Settings - user:

{
"font_face": "DejaVu Sans YuanTi Mono"
}

注：只能改user的，改Default的没效的。

Sublime Text的中文输入问题，困扰了我好久，今天终于在Zoom.Quiet周大妈的提点下，无意间搞掂了。

装scim什么的就不说了，推荐安装 scim-googlepinyin 。

装好了配置是关键，在“系统－语言支持”里面选上“scim-bridge”就可以了（选scim是不行的）。
或者命令“ sudo im-switch -s scim-bridge -z default ”也可以？(没测试)

就这样，哦了！！

附scim输入框不能跟随问题解决办法：

将默认的 GTK_IM_MODULE=scim 修改为 GTK_IM_MODULE="scim-bridge"。保存退出.

在scim输入法中进行了如下设定：

scim设置－>全局设置－>将预编辑字符串嵌入到客户端中前的勾去掉

scim设置->gtk->嵌入式候选词标的勾去掉

重启scim

打开终端,输入 pkill scim

然后输入 scim -d

不行的话注销一下试试。（在sublimetext中还是不能跟随光标）

OK。

本文链接

golang与node.js的http对比测试

2011-09-07T11:46:00Z

听说Go是很不错的语言，了解了一下，一些特性确实很不错。

顺便测试了一下http与node.js的性能对比。

go的代码：

（注：是用8g, 8l编译的）

node.js的代码：

ab测试结果：

==** GO **==

$ ab -c 100 -n 1000 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Server Software:
Server Hostname: 127.0.0.1
Server Port: 8080

Document Path: /
Document Length: 1 bytes

Concurrency Level: 100
Time taken for tests: 0.322 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 97000 bytes
HTML transferred: 1000 bytes
Requests per second: 3105.62 [#/sec] (mean)
Time per request: 32.200 [ms] (mean)
Time per request: 0.322 [ms] (mean, across all concurrent requests)
Transfer rate: 294.18 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.7 0 3
Processing: 1 30 10.5 29 55
Waiting: 1 30 10.5 29 55
Total: 4 30 10.1 29 55

==** Node.js **==

$ ab -c 100 -n 1000 http://127.0.0.1:8080/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Server Software:
Server Hostname: 127.0.0.1
Server Port: 8080

Document Path: /
Document Length: 12 bytes

Concurrency Level: 100
Time taken for tests: 0.143 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 50000 bytes
HTML transferred: 12000 bytes
Requests per second: 6993.50 [#/sec] (mean)
Time per request: 14.299 [ms] (mean)
Time per request: 0.143 [ms] (mean, across all concurrent requests)
Transfer rate: 341.48 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.1 0 4
Processing: 2 13 6.6 13 30
Waiting: 2 13 6.6 13 30
Total: 2 14 6.4 14 30

webbench测试结果

==** GO **==

$ webbench -t 30 -c 100 http://127.0.0.1:8080/
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1:8080/
100 clients, running 30 sec.

Speed=146934 pages/min, 262032 bytes/sec.
Requests: 73467 susceed, 0 failed.

==** Node.js **==

$ webbench -t 30 -c 100 http://127.0.0.1:8080/
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1:8080/
100 clients, running 30 sec.

Speed=485128 pages/min, 404273 bytes/sec.
Requests: 242564 susceed, 0 failed.

从测试结果来看，node.js的HTTP SERVER性能是Go的两倍还多，而且让我比较郁闷的是，在用webbench进行测试的时候，可以看到go是用了我的笔记本上的四个核的CPU的，而node.js当然是只跑在一个核上，而Go居然还比node.js慢这么多。

然后我google，就看到：golang helloworld 45% slower than node.js

求真相！

本文链接

作为Web开发人员，我为什么喜欢Google Chrome浏览器

2011-08-28T13:17:00Z

【原文地址：http://www.cnblogs.com/QLeelulu/archive/2011/08/28/2156402.html 】

在Google Chrome浏览器出来之前，我一直使用FireFox，因为FireFox的插件非常丰富，更因为FireFox有强大的Firebug，对于前端开发可谓神器。

在Chrome出来的时候，我就喜欢上它的简洁、快速，无论是启动速度还是页面解析速度还是Javascript执行速度（现在的FireFox4也比之前的FireFox3有很大的进步）。不过当时由于Chrome的开发者工具还不是很完善，而我又不是很熟悉，加之对于Firebug的好感和依赖，当时还是用回FireFox作为我的主浏览器。

后来由于开发Chrome的插件(现在的FaWave)，就一直使用Google Chrom作为我的主浏览器，渐渐熟悉Chrome的开发者工具，而Chrome也一直在快速迭代，快速进步中，到现在，Chrome已经绝对成为我的主浏览器，Chrome的开发者工具，我也认为比Firebug更好用。

得益于Google V8的快速，和对HTML5和CSS3的支持也算比较完善，html类的富客户端应用Chrome上无论是流畅性还是呈现的效果，都是比较出色的，这对于开发者，特别是对于那些喜欢研究前沿技术的前端开发者来说，是很重要的。

对于本文，作为一个Web开发人员，除了上面的原因以外，与我们开发相关的，就是Chrome的开发者工具。而本文，就是要详细说说Chrome的开发者工具，说说我为什么认为它比Firebug要好用。

怎样打开Chrome的开发者工具？

你可以直接在页面上点击右键，然后选择审查元素：

或者在Chrome的工具中找到：

或者，你直接记住这个快捷方式： Ctrl+Shift+I (或者Ctrl+Shift+J直接打开控制台)，或者直接按F12。

打开的开发者工具就长下面的样子：

不过我一般习惯与点左下角的那个按钮，将开发者工具弹出作为一个独立的窗口：

下面来分别说下每个Tab的作用。

Elements标签页

这个就是查看、编辑页面上的元素，包括HTML和CSS：

左侧就是对页面HTML结构的查看与编辑，你可以直接在某个元素上双击修改元素的属性，或者你点右键选"Edit as Html"直接对元素的HTML进行编辑，或者删除某个元素，所有的修改都会即时在页面上得到呈现。（注：看到上面右键菜单的最后一个选项"审查元素"了么？这是不是说明这个开发者工具的页面也是HTML来的呢？你点一下就知道了哦，嘿嘿）
你还可以对某个元素进行监听，在JS对元素的属性或者HTML进行修改的时候，直接触发断点，跳转到对改元素进行修改的JS代码处：

Elements标签页的右侧可以对元素的CSS进行查看与编辑修改：

你还可以通过这里看到各CSS选择器设置的CSS值的覆盖情况。
下面的Metrics可以看到元素占的空间情况（宽、高、Padding、Margin神马的）：

注意到上面的Properties没有？这个很有用哦，可以让你看到元素具有的方法与属性，比查API手册要方便得多哦（要注意某些方法和属性在IE、FireFox等其他浏览器下面的支持情况哦）。

Resources标签页

Resources标签页可以查看到请求的资源情况，包括CSS、JS、图片等的内容，同时还可以查看到存储相关的如Cookies、HTML5的Database和LocalStore等，你可以对存储的内容编辑和删除。
这里的CSS文件有一个好玩的特性，你可以直接修改CSS文件，并且修改即时生效哦：

Network标签页

Network标签页对于分析网站请求的网络情况、查看某一请求的请求头和响应头还有响应内容很有用，特别是在查看Ajax类请求的时候，非常有帮助。注意是在你打开Chrome开发者工具后发起的请求，才会在这里显示的哦。
点击左侧某一个具体去请求URL，可以看到该请求的详细HTTP请求情况：

我们可以在这里看到HTTP请求头、HTTP响应头、HTTP返回的内容等信息，对于开发、调试，都是很有用的。

Scripts标签页

很明显，这个标签页就是查看JS文件、调试JS代码的，直接看下图的说明：

还有你可以打开Javascript控制台，做一些其他的查看或者修改：

你甚至还可以为某一XHR请求或者某一事件设置断点：

Timeline标签页

注意这个Timeline的标签页不是指网络请求的时间响应情况哦（这个在Network标签页里查看），这个Timeline指的JS执行时间、页面元素渲染时间：

点击底部的Record就可以开始录制页面上执行的内容。（这个不熟悉，请参考文末链接）

Profiles标签页

这个主要是做性能优化的，包括查看CPU执行时间与内存占用：

这个也不熟悉，不多说，还是请参考文末链接吧。

Audits标签页

这个对于优化前端页面、加速网页加载速度很有用哦（相当与Yslow）：

点击run按钮，就可以开始分析页面，分析完了就可以看到分析结果了：

它甚至可以分析出页面上样式表中有哪些CSS是没有被使用的哦：

Console标签页

就是Javascript控制台了：

这个除了查看错误信息、打印调试信息（console.log()）、写一些测试脚本以外，还可以当作Javascript API查看用。
例如我想查看console都有哪些方法和属性，我可以直接在Console中输入"console"并执行：

怎么样，一目了然了吧？再例如我想查看日期函数都有哪些方法：

（注：注意在这里看到的某些方法和属性是ES5新增的，记得兼容其他浏览器的支持情况哦）

结语

Google Chrome除了简洁、快速，现在的Chrome的插件也非常的丰富了。而对于web开发者来说，Chrome对于HTML5、CSS3等一些新标准的支持也是比较完善的，而且Chrome的开发者工具我个人认为真的非常好用，这就是为什么我向web开发者推荐使用Chrome的原因。

注1：本文截图的Chrome版本为：13.0.782.215 m
注2：Chrome开发者工具更详细的说明请参考：http://code.google.com/intl/zh-CN/chrome/devtools/docs/overview.html
注3：本文原来想定的标题是：给那些因为Firebug而舍不得FireFox的朋友

本文链接

sqlalchemy在web.py中的session使用

2011-08-10T13:24:00Z

按照sqlalchemy的文档中关于sqlalchemy的session在web应用上下文的生命周期应该是：

Web Server Web Framework User-defined Controller Call
-------------- -------------- ------------------------------
web request ->
call controller -> # call Session(). this establishes a new,
# contextual Session.
session = Session()

# load some objects, save some changes
objects = session.query(MyClass).all()

# some other code calls Session, it's the
# same contextual session as "sess"
session2 = Session()
session2.add(foo)
session2.commit()

# generate content to be returned
return generate_content()
Session.remove() <-
web response <-

见：http://www.sqlalchemy.org/docs/05/session.html#lifespan-of-a-contextual-session

不过web.py的cookbook中关于使用sqlalchemy的示例中，最后并没有释放sqlalchemy的session资源，正确的应该如下：

def load_sqla(handler):
web.ctx.orm = scoped_session(sessionmaker(bind=engine))
try:
return handler()
except web.HTTPError:
web.ctx.orm.commit()
raise
except:
web.ctx.orm.rollback()
raise
finally:
web.ctx.orm.commit()
# If the above alone doesn't work, uncomment
# the following line:
#web.ctx.orm.expunge_all()
web.ctx.orm.close() # <=- 关闭session，或者用 .remove()

本文链接

web.py大文件下载

2011-08-05T06:10:00Z

需要下载大文件的时候，如果先将文件直接读入内容再返回，那肯定就很浪费内存，甚至会崩溃。

所以我们需要读一些内容然后直接flush给客户端，但是web.py的文档里面却没有找到flush的方法。

不过在web.py的cookbook中的How to Stream Large Files中看到可以直接yield返回内容。所以，我们可以使用yield来做flush做的事情。

BUF_SIZE = 262144
class download:
def GET(self):
file_name = 'file_name'
file_path = os.path.join('file_path', file_name)
f = None
try:
f = open(file_path, "rb")
webpy.header('Content-Type','application/octet-stream')
webpy.header('Content-disposition', 'attachment; filename=%s.dat' % file_name)
while True:
c = f.read(BUF_SIZE)
if c:
yield c
else:
break
except Exception, e:
print e
yield 'Error'
finally:
if f:
f.close()

OK！

完鸟！

本文链接

Python和Node.js支持尾递归吗？

2011-07-30T17:52:00Z

什么是尾递归？简单来说就是最后返回的只是一个函数的调用，而不用保存多余的局部变量。
看一个简单的计算阶乘的例子(Lua代码)：

function fact(n)
return n==0 and 1 or n * fact(n-1)
end

改成尾递归的方式就是：

function tail_fact(n, p)
p = p or 1
if n==0 then
return p
end
return tail_fact(n-1, n*p)
end

关于尾递归的更详细说明请参考：
http://en.wikipedia.org/wiki/Tail_call

因为使用尾递归方式的时候，是不用保存局部变量的了，所以部分语言的解析器会对尾递归做优化，减少栈空间的占用。普通的递归方式则由于需要保存局部变量，栈空间则越占越多，最终导致栈溢出。

Lua是支持尾递归的，所以上面的尾递归的代码，是可以很好的工作的。

Python的尾递归支持

Python本身是不支持尾递归的(via)，并且对递归次数有限制的，当递归次数超过1000次的时候，就会抛出“RuntimeError: maximum recursion depth exceeded”异常。
有人对此为Python的尾递归写了一个优化版本，让Python突破递归调用1000次的限制：Tail Call Optimization Decorator (Python recipe) ，或者你可以看看以下两篇文章：

以上的Python尾递归优化可以突破1000次的递归限制，但是却对于尾递归应有的优化完全没有。以下为我的测试代码：

#recursion.py
@tail_call_optimized
def fact(n):
return 1 if n==0 else n * fact(n-1)

#tail_recursion.py
@tail_call_optimized
def tail_fact(n, p=1):
if n==0:
return p
return tail_fact(n-1, n*p)

测试环境是Python2.7.1，计算100000的阶乘。执行recursion.py的时候，内存占用约为100M，执行tail_recursion.py的时候，内存占用占到1G的时候，还是没有执行完，我只好杀掉进程。

不过我确实想不明白为什么Python这里写成尾递归的方式会比会比普通方式占用多那么多内存呢？

Node.js对尾递归的支持

我知道JavaScript是不支持尾递归的。ES4的时候曾经提过要加入尾递归的支持，不过后来被去掉了(via)。
周爱民的《Javascript语言精髓与编程实践》其中也提到：

“然而不幸的是。目前已知的javascript 的解释环境中并不支持这种特性（尾递归）。因此，我们在这里讨论函数室式时，可以说“能够通过函数递归来消灭循环语句”，但在不支持尾递归（及其优化技术）的javascript中，这种实现将以大量栈和内存消耗为代价”

Node.js是基于Google V8的，所以在Chrome的控制台测试了一下：

从结果看来，基本没戏了。但是还是在node.js写了代码验证一下。

// recursion.js
function fact(n){
if(n == 0){
console.log('fact: ');
console.dir(process.memoryUsage() );
}
return n==0 ? 1 : n * fact(n-1);
}

// tail_recursion.js
function tailFact(n, p){
p = p || 1;
if(n==0){
console.log('tail fact: ');
console.dir(process.memoryUsage() );
return p;
}else{
return tailFact(n-1, p*n);
}
}

以下为计算13000的阶乘时内存占用情况：

$ node recursion.js
fact:
{ rss: 7892992,
vsize: 55169024,
heapTotal: 2861216,
heapUsed: 1634612 }

$ node tail_recursion.js
tail fact:
{ rss: 7901184,
vsize: 55169024,
heapTotal: 2869376,
heapUsed: 1791520 }

从结果来看，尾递归的方式占用的内存还要多。

下面再来看看计算13000的阶乘，循环1000次，然后计算平均每次的执行时间：

var start = Date.now();
for(var i=0; i<1000; i++){
tailFact(13000);
}
console.log( (Date.now() - start)/1000 );

以下为执行结果：

$ node recursion.js
0.257

$ node tail_recursion.js
0.277

阿门，无论是内存占用还是执行效率，尾递归的方式都要比普通方式差。

看来V8是对于尾递归的方式完全没有做优化了，对于Node.js异步调用到处是的情况下，没有对尾调用做优化的话，栈空间浪费很严重啊！不知道我这样认为对不对？忘记一点是“异步”的，异步回调栈是清空的了，不存在该问题。

Enjoy!

本文链接

小文件、nginx、Redis、Moosefs

2011-07-13T12:38:00Z

现在有3KW的数据，单条数据都很小的，如果按key-value来看的话，key就是32位的MD5字符串，value按平均算大概是100字节左右。

现在需要将这些数据做缓存以在高并非的时候依然可以快速响应。
因为这些数据基本没有冷热数据之分，所以需要将全部数据都放到缓存中。

1、直接生成静态文件，利用nginx对静态文件的高效做静态缓存。

当时服务器硬件资源有限，所以就采用这种方式，一直源用至今。
服务器间通过NFS来共享
太多小文件，不方便管理
NFS不方便运维与扩展
文件内容很小(100字节左右)，3KW大概就是2.5G大小左右

不过文件存储的时候和硬盘分区的族大小有关，在这里磁盘分区的族大小为8K，所以尽管文件内容只有100字节，但是实际存储到磁盘上的时候单个文件其实是8K
所以3KW的文件世界占的磁盘空间大约为：200G左右（严重浪费空间啊）

2、Redis(V2.2.11)【KV数据库】

听同事说开启VM会使性能急剧下降，所以基本无视VM，数据全放内存。
key为32位MD5字符串
测试数据：10W数据大概占内存20M
测试数据：500W数据大概占内存1G，持久化的rdb数据文件大概350M
推算3KW数据：内存6G，持久化的rdb数据文件大概为2G(压缩了？)
因为Redis在持久化的时候内存会加倍，和考虑到数据的增长，所以需要1台20G内存的机器基本就没问题了（容灾啥的另算）。
Redis非常快，如果硬件条件没问题，基本选这个最好了。

3、Moosefs(MFS)【分布式文件存储系统】

mfs支持NFS的方式mount到本地直接操作（如使用mfs，则现在的架构基本不用改）
最基本的需要一台主控服务器(Master Server)、一台数据服务器(Chunk Server)
文件和目录的索引需要全部加载到主控服务器的内存中，所以对主控服务器的内存有一定的要求
写入30W文件，到20W的时候写入就开始下降得厉害了（我的5400转的笔记本硬盘）
30W文件，4W目录，主控服务器占用大概120M内存
文件存储方式貌似和普遍的文件一样单个存储的（不确定），30W文件大概占了2.4G的磁盘空间（同样是8K一个文件）。
小文件一样很多，不方便维护与迁移(不知是否我设置不对？)。
内存、硬盘都占用得比较多，而且性能相对来说不是很出众。
所以这个基本不考虑了。

本文链接

一道JavaScript面试题（setTimeout）

2011-06-13T10:13:00Z

下面的代码，多久之后会弹出'end'？为什么？

var t = true;

setTimeout(function(){ t = false; }, 1000);

while(t){ }

alert('end');

这是以前在想有没办法实现阻塞javascript线程的时候（即实现sleep方法），想过的一种实现。

很简单，是吧？

是吗？

本文链接

用Eclipse调试Node.js代码

2011-05-06T10:56:00Z

node.js是基于Google V8的，而Google V8有一个Eclipse的调试插件，这个插件同样也支持node.js。

1、安装Eclipse debugger for V8

这个，用过Eclipse的应该都知道，不过还是简单说下吧：

选择“Install New Software”

点“Add”

Location为： http://chromedevtools.googlecode.com/svn/update/dev/
Name你喜欢，整一个方便你记忆的就好。

点击确定后，在“Work with“选择你刚才添加的站点：

然后选择“Chromium JavaScript Remote Debugger”，然后一直下一步，安装完后会提示重启Eclipse，重启Eclipse后就可以开始调试了。

2、怎样调试Nodejs？

从插件名称中的“Remote”可以预想到这是一个远程调试的工具，大概的流程就是node开一个tcp的调试端口，然后这个调试工具通过这个tcp端口来和node通讯实现调试。

要启用node的调试端口，在执行node脚本的时候需要添加 –-debug 参数：

node --debug[=port] NodeApp.js

or

node --debug-brk[=port] NodeApp.js

其中port为开启的调试端口，默认为5858.
--debug和--debug-brk的区别在于，--debug执行脚本的时候会直接运行该脚本，而--debug-brk执行脚本的时候，并不会马上执行，而是等待调试器的连接，然后按调试器的指令来执行。

我们写个简单的代码来用于调试：

然后用 node –debug hello_world.js 来运行：

可以看到输出一行：debugger listening on port 5858
5858为默认端口，你也可以用 --debug=5859 来指定不同的端口

好，现在node的调试模式已经运行起来了，我们去配置Eclipse来连接到node并进行调试。

首先我们要到debug config里面去添加一个新的V8 VM的调试配置：

右键，选择“new”来新建一个配置项：

因为我们刚才node起的调试端口为默认的5858，所以这里我们的端口就是5858，名称我们定为“Node-5858”。

然后点debug开始调试，或者你使用下面的方式开始调试：

调试模式大概会是这样：

（注：这是调试视图，点击右上角的臭虫按钮。如果你的Eclipse上没有这个按钮，请点击上图右上角臭虫左边的添加按钮，找到debug然后添加就可以）

在调试模式连接成功后，你会在你的“Project Explorer”里面看到多了一个“Node-5858”（刚才debug config里面设置的名称）的项目，里面的文件都是调试的文件或者调试的文件require进来的文件。
打开这些文件，你就可以在里面加断点开始调试了。例如上图的第8行加了一个断点，则每次在浏览器访问的时候都会进入这个断点。

其他的调试和你平时用Eclipse调试其他代码是一样的。
Eclipse的调试快捷键是，F5单步进入，F6单步跳过。

最后说一下 --debug-brk 方式启动的调试模式：

可以看到仅仅是输出了一行“debugger listening on port 5858”而已，后面并没有继续输出“Server running at …..”。
这是因为用启动的调试模式并不会马上执行代码，而是会等待调试器的连接（可以理解为在hello_world.js的第一行加了断点），具体还是各位童鞋自己实践吧。

参考： https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-Debugger

本文链接