让Apache支持Python的过程很简单，只要3步。

1. 下载mod_python模块安装程序（注意文件名后面Python和Apache的版本号要与自己已经安装的版本一致；文件名前面的版本号则是mod_python的，文件名示例：mod_python-3.3.1.win32-py2.5-Apache2.2.exe），然后安装，安装向导会自动找到Python路径，但可能需要我们手工指定Apache路径，安装到最后，向导还会提示你如何修改Apache配置文件（参见下一步）并给出了后续步骤的英文说明。
2. 让Apache加载mod_python模块。在Apache安装目录下找到其配置文件apache\conf\httpd.conf，打开，搜“LoadModule”，找到加载模块的地方，然后添加一条语句：LoadModule python_module modules/mod_python.so，重新启动Apache。
3. 在htdocs目录下新建一个目录，如：“py”。进入py目录，新建一个文本文件，并命名为“.htaccess”，加入下列3条指令：

   
   AddHandler mod_python .py
   PythonHandler mptest
   PythonDebug On
   

   这里第一条指令是将所有URL末尾为.py的请求转发给mod_python处理程序，mod_python接收到请求之后再寻找适当的PythonHandler处理程序。第二条指令只定义了一个mptest处理程序。最后一条是启用Python代码调试功能，以便在代码运行出错时输出Python解释器返回的错误。

完成以上3步之后，就可以编写Python文件并进行测试了。在py目录下新建 mptest.py 文件，打开后添加如下代码：

from mod_python import apache

def handler(req):
	req.content_type = 'text/plain'
	req.write("Hello World!")
	return apache.OK

保存。打开浏览器，输入http://localhost/py/mptest.py，回车。看到“Hello World！”了吗？

实际上，由于前面只明确将mptest设置为处理程序，所以无论浏览器URL中的.py文件名是什么（如：login.py、default.py），都将被转发给mptest.py文件来处理，都会返回“Hello World！”。怎么办呢？长话短说，可以将上面第3步中的代码替换成如下所示：

AddHandler mod_python .py
PythonHandler mod_python.publisher
PythonDebug On

更多内容，参见Mod_python Manual和Introducing mod_python。

作者：Rachel Lovinger，美国最大的互动广告公司Razorfish（睿域营销咨询公司）的内容策略领导人。

不知道什么是“内容策略”？这很正常。我在公司的头衔里就有这个词组。每当有人问起我靠什么过活时，我心里都十分纠结。许多人对这个词组没有什么概念，但在谈话间，我发现多数人对它的理解都是错误的。这些人觉得“内容策略”就是写文案的意思。虽然不能说完全不着边，但总归还是没说到点子上。

近来，我经常使用一个类比，我认为内容策略之于写稿，就像信息架构之于设计。我为自已能想到这个类比感到很满意，毕竟在6年前，当Web发展的第一波开始退潮时，“信息架构”到底是什么意思也没有几个人知道。

当前的问题在于，必须想办法向不理解内容策略的人解释清楚：内容策略的主要目标是使用文字和数据，创造出没有歧义的内容，从而为有意义的交互体验提供支持。为此，我们必须成为善于跟形形色色的人有效沟通的专家。

然而，到底是什么原因导致了我们的工作那么难于跟别人解释呢？

问题或许在于，内容是无处不在的，所以任何人都认为自己很明白。只要你能读会写，就可以制造内容，对吧？（近6000个博客可以证明这一点。）但事实上，随着交互体验变得日益复杂，内容的本质也变得越来越复杂了。这时候，只从表面上来理解内容已经远远不够了。数字时代的内容策略专家必须成为数据方面的哲学家，努力探寻有关内容的抽象理论，而这一切就要从回答“什么是内容”这个问题开始。

一切皆内容

在我们为一家国际娱乐杂志的网站开发复杂的元数据系统时，我的同事也是好朋友Chris Sizemore说：“一切皆内容。”我还比较认同这个观点。

一切皆内容吗？设计是吗？是。结构呢？也是。元数据呢？当然也是了。你可能觉得对这句话还应该有更深刻的解释。好吧，那就只能说：“准确地讲，一切皆内容。”

你可能会问，在崇尚视觉效果的Web设计领域，着意关注内容的需求源自何处呢？随着网站功能的日益丰富，Web用户的品味也越来越高。要想吸引人，你的站点就必须提供到位的交互体验，以及更多配套的内容。但简单地增加内容是不行的，你必须让内容有的放矢、言之有物，而且还要有意义。

提到决定事物是否有意义的因素，我可以罗列出一大串，但就Web应用而言，我认为最主要的一个因素是联系。Z文章与点击的主题有关系吗？给我看看。B图片与我已经见过的一样吗？拜托，我可不想再看到同一张图片了！诸如此类微妙、动态而又复杂的关系，都需要找到一种计算机能够遵照执行的方式精确地表达出来。那我们就举个看起来似乎很直观的例子，比如说“相同”：你怎么确定两段内容是相同的？

你可能会说任何数据记录都是唯一的，因此是否相同一看便知。但这对于找出两段无论从哪方面说都完全一样的文字之间的关系却毫无帮助。噢，大概在内存中的字节相同可以说明两段内容相同罢。那么一篇文章与它的翻译版呢？一张图片与它的缩放版呢？从读者角度说，它们是相同的，只不过有一张小一些。还是那张图片，它与它的裁切版相同吗？

问到这，“相同意味着什么？”这个命题合乎有点像推理了。然而，在构建CMS（内容管理系统）的时候，这个问题却有着非常实际的含义。你怎样取得一篇文章及其翻译版，会对文章的编排、发表以及最终在站点上使用的方式造成巨大差异。而一张图片与它的缩放版、裁切版在CMS中保存的方式，则很可能会对呈现及访问它们产生意想不到的影响。

临界量

如果你只想展示非常短的一条信息，那（也许）可以随便把它一放，然后让用户自己去理解就行了。

图1 极其简单的网站用不着IA或内容策略

随着要展示的信息不断增多，用不了多久，就需要运用某些结构来组织这些信息，以方便用户找到它们。而这正是信息架构要解决的问题，即通过应用组织原则和视觉提示，让用户一打开站点就能迅速定位目标，而不必多费脑筋。如果碰巧赶上信息架构师（IA，Information Architect）对文字有兴趣，那么他可能会仔细地考虑按钮上的文本到底用什么语言最有利于传达信息。如果信息架构师没有这份心思或者经验，那么这时候就可以轮到内容策略专家（CS，Content Strategist）上场了。CS此时也要与IA密切协作，以确保站点的组织井然有序，同时还要确保相应的内容各就各位。

图2 复杂一些的站点就需要组织了

在设计和构建内容量极大的网站时，我们发现单靠手工组织这些内容是不现实的。在这种情况下，就需要用到自动化的、复杂的算法来解放人类了。为此，内容中必须包含机器能够识别的固有信息，例如通过搜索、浏览和相关链接来维系数据驱动的应用。内容策略专家的责任就是专注于怎么才能让内容有意义，同时也让站点的设计最恰当地利用内容。

实战演练

在经过了一番哲学思辨之后，我们终于搞清楚了谁要为内容负责了。那么，到底怎样才能让内容有意义呢？

为了让人们感觉内容与他们有关，必须选择那些对实现沟通目标效果最好的词汇和句子结构。至于表达方式，应该在深刻理解内容创作者的意图和内容消费者的需求的基础上来确定。为此，可以借助类似于编辑指南的手册来提供指导，或者提供一些让别人能够按照相同表达方式组织内容和消息的示例。

为了让机器更好地处理内容，需要将内容结构化并定义标准的元素，从而方便内容的使用和重用。需要对内容分门别类，为不同类别添加相应的元数据，以便于识别。需要在内容之间建立关联，使得它们的背景丰富，不显得单薄，同时也能支持各种复杂的功能。

为了保证创建内容的效率，需要评估和推荐一些解决方案，用于创建、增强、组织和使用内容，包括内容管理系统、元数据相关的工具、搜索引擎及方便的导航应用程序。需要创立业务规则及工作流，进一步优化这些工具和系统的使用。

为了保证内容面面俱到，需要确定站点的内容需求，清查已有的内容，发现缺口，落实新增内容的补给渠道，并控制将这些内容融合到产品中去的整个过程。在既定的背景和参考资料支持下，可能还要编写标签、概述，甚至更长的内容。

在做以上这些事并创造相应成果的过程中，不要因为过时的哲学问题而让实际上简单的问题复杂化。试试这个脑筋急转弯：“具备什么样品质的内容才能历经三个月都不会磨灭其价值，而又是什么样的品质会导致内容甫一问世就面临过时的危险？”（提示：没有唯一的答案。）

内容策略专家的策略

如果你是一名内容策略专家。

• 问自己或同事一些有关内容的难题（例如：“内容是什么？”“什么因素会提升内容的价值？”）。
• 头脑风暴，探讨怎样生成更有意义的内容，如何确定质量好与坏的标准。落实到一个投入/产出分析模型上。
• 比较不同的内容模型并确定各自适合的用途。
• 关注一些新出现的能够有效解决内容问题的工具。创造性地使用这些工具，包括发现新用途和新用法，然后把这些创意告诉工具的开发人员，以促进工具改进。

如果你与内容策略专家合作。

• 花点时间认真严肃地思考一下内容。在讨论内容问题，而内容又似乎不是问题的直接诱因时，请保持几分耐心——有时候，只有这种态度才能拿出理想的内容方案。
• 在开始规划站点之初，就在项目中考虑内容。千万不要在站点已经构建和设计完成后，才意识到需要找些内容来填充页面。

如果你没有与内容策略专家协作，但有这个意愿。

• 向组织的负责人说明内容策略专家扮演的角色，以及他们为什么可以节省时间和精力，可以帮助避免问题，可以提升最终产品的品质。在项目收尾时，可以举出一些能够说明“如果早点想到这一点就好了”的例子。根据这些与内容相关的例子，你会发现自己可能成功了一半了。
• 如果不行，再了解组织中哪个人对内容理论更感兴趣，鼓励他们多做一些相关的研究。过一段时间后，再给他们摆事实，讲道理，然后你的心愿就可以达成 了。

内容策略并没有一个放之四海而皆准的定义，不同的人对它的理解也不怎么一致，但这可不是对内容策略视而不见的理由。只有深刻认识到内容的重要性，像个哲学家一样思考问题，你才能够做到随机应变。

这些勘误信息主要来自@凌空一叶同学，特此致谢！

需要特别说明的是，图灵公司自今年以来，面向广大读者推出了“图灵5周年系列活动之‘有奖DEBUG’活动”。只要读者针对图灵公司新近出版的图书提交勘误，经过确认，每个错误向读者赠送价值5元的“购书码洋”，待累积到一定数额，就可以换取等值图书。此举旨在鼓励读者反馈勘误，提升图书质量。活动详情请参见：http://www.turingbook.com/Newswires/ShowNewswire-174.aspx。

欢迎广大读者朋友踊跃迅速地反馈勘误信息，以便在后续印次及时更正，惠及更多读者。反馈勘误之前，请务必注意：

1. 为了确保您的反馈得到积分奖励，请统一到图灵公司网站本书页面（附后）提交勘误；
2. 请不要重复提交已经确认的勘误，在提交勘误前，请先查阅已经确认的勘误；
3. 已经确认的勘误不再积分，未确认的勘误，只给先提交的读者计算积分。

提交勘误，请到如下页面：

• 到图灵公司本书页面提交勘误（点击右下方蓝色“提交勘误”链接）

查看勘误，请到如下页面：

• 图灵公司的勘误页面
• 译者整理的勘误页面（http://tinyurl.com/js2nd-errata）

loop、iterate、traversal和recursion这几个词是计算机技术书中经常会出现的几个词汇。众所周知，这几个词分别翻译为：循环、迭代、遍历和递归。乍一看，这几个词好像都与重复（repeat）有关，但有的又好像不完全是重复的意思。那么这几个词到底各是什么含义，有什么区别和联系呢？下面就试着解释一下。

• 循环（loop），指的是在满足条件的情况下，重复执行同一段代码。比如，while语句。
• 迭代（iterate），指的是按照某种顺序逐个访问列表中的每一项。比如，for语句。
• 遍历（traversal），指的是按照一定的规则访问树形结构中的每个节点，而且每个节点都只访问一次。
• 递归（recursion），指的是一个函数不断调用自身的行为。比如，以编程方式输出著名的斐波纳契数列。

有了以上定义，这几个概念之间的区别其实就比较清楚了。至于它们之间的联系，严格来讲，它们似乎都属于算法的范畴。换句话说，它们只不过是解决问题的不同手段和方式，而本质上则都是计算机编程中达成特定目标的途径。

一个星期前，由于网站崩溃，我需要学习备份数据库和站点文件。一位朋友主动向我伸出援手，把他自己编写的Shell脚本共享给我，并通过聊天工具耐心地指导我配置脚本选项。由于我把数据库编码一项误写成了“utf-8”，而系统又轻易不返回错误消息，导致了我们俩从晚上8:44一直Debug到23:28。（严格来讲，是他在不停地查手册、重写脚本，而我不停地用他给我的脚本覆盖服务器上的脚本并重新运行）。最后，他终于“想到把那个错误问题输出”了。根据错误信息，我们查了一下，原来MySQL默认的字符集是“utf8”而不是“utf-8”——去掉中间的短划线，问题就解决了。

说起这位朋友，其实我们早在2005年就认识了，当时我们都在翻译正则表达式方面的书。想一想那天晚上Debug的情景，心里不禁涌起丝丝暖流。

两个月前，由于种种原因，我需要学习使用SSH。一位朋友主动向我伸出援手，通过聊天工具耐心地给我讲解SSH客户端软件以及相关浏览器插件的配置和使用方法，直至我终于入了门为止。刚才又翻了翻当时的聊天记录：两次聊天用时大约90分钟，你来我往的文字有200余行！更令人感动的是，由于担心我从头开始配置太烦琐，这位朋友还把他的配置文件共享给了我。

说起这位朋友，其实至今我还只知道他的英文名——JerryChoi。现在回忆起来当时聊天学习的情景，心里仍然会泛起阵阵感动。

老子《道德经》第七十七章是这样写的：“天之道，其犹张弓与？高者抑之，下者举之；有余者损之，不足者补之。天之道，损有余而补不足。人之道则不然，损不足以奉有余。孰能有余以奉天下？唯有道者。是以圣人为而不恃，功成而不处，其不欲见贤。”

山西古籍出版社卫广来译著的《老子》，对这一章是这样解释的：“天的道，不就像拉开弓射箭吗？目标高了，就把它压低一点；目标低了，就把它抬高一点；弓弦过满了，就把它减少一点；弓弦不够满，就给它补充一些。天的道，减少有余的，用来补给不足。人的‘道’却不是这样，减少不足的，用来供养有余的。谁能拿出多余的财物来供给天下呢？只有‘有道’的人。因此圣人，为万物尽了力而不恃其能，办事成功而不自居功，他不愿意表现自己的贤能。”

这是老子在2500年以前说过的话，到了今天改变了吗？没有。前面说到的两位朋友在某些方面强过我，其实他们就是“能有余以奉天下”的人，而相对于他们我就是“不足”的人。他们对我的帮助，可以说是“损有余而补不足”，是顺应了“天道”，而他们自然也就是“有道者”了。

说到“不足”，我这个站点的域名跟这两个字其实大有渊源。早在2007年注册域名的时候，之所以想到cuckoo这个词，就是因为“布谷”和“不足”是谐音。当时的想法其实比较“自私”，我认为自己应该永远是“不足”的。这就相当于一个杯子只盛了少半杯水，这样才会有更多空间接受“替天行道”的“有余者”倾倒过来的“水”，才能让自己越来越“足”起来。

今年以来，我越来越多地联想到杯子和水的比喻。人生世间，每个人都可以决定自己是一杯水，还是半杯水；如果是半杯水，还可以进一步决定自己的杯子举得比别人的高，还是比别人的低。道理显而易见，只有没盛满水的杯子才能从别人的杯子中获得补充，而且更重要的是，只有自己的杯子举得比别人的低，别人杯子里的水才有可能流注到你的杯子里面来。

感谢上述两位朋友，也感谢曾经以这样或那样的方式帮助过我的更多朋友。

俗话说，“覆巢之下无完卵”。主机服务器硬盘损坏了，数据全都丢了，作为一颗“蛋”保存在坏掉的硬盘这个“巢”里的本站能幸免于难吗？当然不能。这正是本站自7月25日（左右）以来无法正常访问的原因——它跟着那块服务器硬盘一块牺牲了。

然而，掉到地上的“蛋”在“粉身碎骨”之后，不仅能够“破壳重圆”，而且还变得更加“完美”，这不禁令我对“祸兮福之所倚，福兮祸之所伏。”这句话有了身临其境并且更加深刻的体会。

自从网站无法访问后，不少朋友通过聊天工具、邮件、微博问我：你的网站怎么了？开始我还以为是服务器重启这类的操作造成的，没当回事儿。这也跟我最近很少写博客有关。又过了几天，发现网站还是打不开。于是，不得不在“所有程序”里找到几乎被埋没了的“××的”聊天软件——QQ2010。原来是这样啊——主机提供商已经在群里作出承诺了：24小时恢复数据。

事实上，给博客换个洋家也不是现在才有的想法。某某部出台了限制.com域名注册的规定（只有企业才能注册，个人不能注册了），后来又传出站长必须亲自到主机商那里照相备案的消息（后来据说只要把带脑袋的照片传过去，就有人用PS负责把你的头像放到官方的背景上），已经让人忍无可忍了！不行，得出国，得让我的这颗“宝贝蛋”出国。也就是说，兴搬家这个念头少说也有小半年光景了。

幸好，原来的那个“窝”完蛋了。24小时恢复数据，没问题。三下五除二，我就从淘宝上买了一个国外空间。登录后台CPanel面板一试，这才觉得自己以前太“恋家”了。这个新“窝”不限制子域名（支持泛域名解析）、不限数据库数量、可在线解压缩、有后台邮件通知，……。相比之下，原来那个“窝”的租金又贵限制又多还不怎么好用。跟现在这个窝比一比，一个银窝，一个金窝吧。换句话说，原来的银窝也不太差，差就差在它的价值与价格背离得太远了。

话说“银窝”的东家说到做到，数据库的数据居然恢复到了7月25日（但这已经不重要了，因为我最新的一篇博客写于6月24日）。再话说，由于我没怎么深入鼓捣地过“银窝”的后台，不怎么熟悉备份导出数据的操作，不得不一边探索一边向人家求救。结果，几乎在我自己鼓捣出备份的同时，人家也通过QQ把10M大小的.sql文件传给了我。在此道一声谢！（我预测，他一准会听到的。）

拿到数据后我就吃了一颗定心丸。先把WordPress版本升级到3.0（支持多站点），然后在本地XAMPP环境下先尝试恢复了一下数据，一切顺利。然后，临时叫停了老婆那吃掉我大量带宽的游戏，正式恢复站点数据，破镜重圆。

结果大家都看到了，表面上跟7月25日以前没有什么区别。但是，经历了这次搬家和数据恢复之后，我突然发现以前写过的那些东西并不像我一开始想象得那么不值一提。在老东家恢复数据期间，我用自己备份的数据（WRS格式的XML文件，通过WordPress导出的）恢复过几次，虽然是5月份才导出的，按理说也就只会丢失几篇文章而已，但几次恢复居然都只能恢复到2008年10月；从2008年11月到2010年5月，居然有18个月的数据断档。我因此作了最坏打算，如果主机商的数据也不能恢复，那就卷土重来，给自己的站点重新定位、重新设计、重新开博。

然而，眼瞅着后台那些十根手指头都数不过来的Ping链接，我清醒地意识到还有不少站点在引用和转载我以前的文章。如果这些引用都变成了空链接，不仅我面子上不好看，也会给不知道有多少读者学习深造带来极大不便。毕竟，在这个网络时代，作为其中的一个结点，我和这个站点都已经不再孤立存在了，而是与千千万万的其他结点建立并保持了千丝万缕的联系。如果数据真的丢了，可让我怎么面对那些素未谋面，而将来又有可能谋面但因此又可能永远也不会再谋面的花朵一样灿烂的脸孔呢？想到这里，我原来如释重负的感觉一下子无影无踪了，一种因失职而难逃其咎的负罪感油然而生。

当然，在老东家的指点和帮助下，数据都完整无缺地找回来了，灾难并没有真的发生。站点恢复如常了，我又可以做一个负责的结点了。与此同时，我发现由于“年久失修”，过去的一些文章有的图片打不开了，有的代码格式变得不好看了。看来有必要把这些年来的文章好好地捋一捋，修补一下，让站点更“完美”一些。这正是我接下来几天一段时间内的一个工作计划。

除了修补过往旧文，我还计划挑选整理一个《精华文章汇总》的页面，把那些价值相对较大的文章从“垃圾”堆里挑出来，摆在明面上。这样就不会过多地浪费读者诸君的宝贵时间了。现在，这个页面的链接已经有了，今后还将不断充实：2007－2010年精华文章汇总。

最后，也是最重要的：从今以后一定坚持做备份，每周至少一次，雷打不动。还有，真心感谢在我站点无法访问期间纷纷提醒、慰问我的朋友，感谢在我测试新“窝”期间，奋不顾身地在测试文章下留言，最后留言又被我忍痛割爱而没有留下任何痕迹的朋友，感谢那些热心转载推介我的文章，让我从一个孤立的结点跟千千万万结点发生了关系的朋友！

草原

天光

起伏

奶牛

风车

路漫漫……

]]> http://www.cn-cuckoo.com/2010/06/19/test-1677.html/feed 4 http://www.cn-cuckoo.com/2010/06/17/are-dynamic-languages-going-to-replace-static-languages-1658.html http://www.cn-cuckoo.com/2010/06/17/are-dynamic-languages-going-to-replace-static-languages-1658.html#comments Thu, 17 Jun 2010 07:25:37 +0000 为之漫笔 http://www.cn-cuckoo.com/?p=1658 罗伯特·C·马丁
2003年4月26日
原文地址：http://www.artima.com/weblogs/viewpost.jsp?thread=4639

显示摘要

隐藏摘要

我曾经是一个静态类型的偏执狂，而且偏执了很多年。我在使用C的过程中饱经磨难，得到很多教训。愚蠢的类型错误曾经导致了不计其数次的系统崩溃。因此，在C++问世的时候，我马上就成为强类型的积极拥护者和推动者。听到Smalltalk程序员抱怨缺少灵活性，我还嘲笑过他们。毕竟，安全性与灵活性相比，前者要重要得多——况且，只要遵循良好的依赖关系管理原则，就能够保证软件具有灵活性，同时还是基于静态类型的。

4年前，我接触到了XP（eXtreme Programming，极限编程）。我很认同其中关于软件开发的实用性观点，也很认同其中关于测试的观点。于是，我又迷上了测试，以至于不使用测试驱动的开发，我都不觉得自己是在写软件。我不敢想象如果没有一套完整的单元测试套件来支持开发，后果将会怎样。

大约在两年前，我发现了一些问题。我越来越少地依赖类型系统所提供的安全性，因为单元测试可以帮我避免类型错误。对单元测试的依赖越多，对Java或C++（这是我选择的语言）类型安全的依赖就越少。

我觉得应该做一个实验。我先后尝试用Python和Ruby（都是以动态类型著称的语言）编写了一些程序，在发现并没有出现什么类型问题时也没觉得特别不可思议。因为单元测试确保了我目标清晰、范围明确，过去那么多年一直对静态类型检查的依赖也被我抛到了九霄云外。

而且，我认识到动态类型语言的灵活性也让编写代码变得异常轻松。模块容易编写，也容易修改。根本就不存在构建时间的问题。动态类型世界的生活让我感到无比轻松自释。

现在，由于项目需要我又改回了使用Java编写代码。但动态类型语言给我的轻松感觉每时每刻都在诱惑着我。我真希望自己是在使用Ruby、Python，甚至是使用Smalltalk在编程序。

还有谁有我这种感觉吗？随着越来越多的人接受测试驱动的开发（我觉得这是一个大趋势），他们一定能体会到我所说的这种感觉。到了2010年，是不是我们都应该换成使用动态类型的语言来编程了？

寻人启示

lyongde 同学，请尽快将你的名字发到我的邮箱里面（lsf.email[at]gmail.com），以便在第二次印刷时加到译者序中以表感谢。

儒家经典《大学》将“格物致知”奉为做学问、养身性的最高境界。

尼古拉斯•扎卡斯重新修订的这个最新版本，为各层次的JavaScript爱好者和Web前端开发人员提供了一条“格物致知”的捷径。

新版本的原书不仅篇幅由原来的600多页增加到800页，而且几乎全部更新、重写了上一版的内容，删除了上一版中与今天的职业需求无关的主题，新增了大量比上一版更有价值、更能反映JavaScript最新发展成果的内容。从颇具深度的JavaScript语言基础到作用域（链），从JavaScript引用类型到面向对象编程，从极其灵活的匿名函数到闭包的内部机制，从浏览器对象模型（BOM）到客户端检测，从文档对象模型（DOM）到基于事件的Web脚本编程，从错误处理到前端调试，从XML（E4X）到Ajax及JSON，从高级前端开发技术到前沿的客户端存储，从最佳编程实践到展望即将成为现实的API，直至JavaScript未来的发展。全书基本上囊括了JavaScript技术的各个方面，几乎涉及到了Web前端开发的所有热门话题。值得一提的是，本书还涵盖了当前最受开发人员关注的HTML5和移动设备（如iPhone）开发的内容。可以预见，本书一定会成为Web前端开发人员不可多得的经典之作。

需要提请读者注意的是，本书第22章讲到了JavaScript未来的变化，里面大部分讲的是ECMAScript 4/JavaScript 2，而ECMAScript 4已经被放弃了，新标准是ECMAScript 5。请读者参考http://www.ecmascript.org/。感谢周涛（Snandy）指出此问题。

本书文前和第1章至第17章由李松峰翻译，第18章至第22章及附录由曹力翻译。武卫东老师审读斧正了序的翻译，责任编辑朱巍为本书早日出版多方协调，执行编辑毛倩倩发现了译稿中多处错译和漏译，排校负责人董秋霞、谢凌老师严把三道排校质量关、谢廷晟全面审校了第1章至第17章，吴玺喆（George Wing）、吴生辉（千年一梦）、周裕波、梁超（LC）、张树恒(shuzai)、罗永德（lyongde）也审校了前17章的部分内容，为确保本书翻译质量起到了重要作用，在此对上述老师和同学致以深深的谢意。

译者
2010年5月

第5章中有这样一句话：“this是函数在执行时所处的作用域”（《JavaScript高级程序设计（第2版）》第5章5.5.4节正文倒数第3段中）。我觉得作者的这种说法大有问题。对JavaScript不熟悉的读者会越看越糊涂。这里首先需要明确两个概念：函数执行时所处的作用域、在哪个作用域中调用函数函数调用发生的作用域，否则讨论就无法继续深入。把后一概念明确为“函数调用语句所处的那个作用域”应该没有问题。而前一个概念，实际上就是函数的定义所处的那个作用域。以下面的代码为例：

function a() {
// …
}

function b() {
/// …

return function c() {
// …
};
}

var d = b();
a();
d();

在这里，函数a、b和d（实际上就是c）都是在全局作用域中调用的。a和b执行时所处的作用域都是全局作用域。但是d执行时所处的作用域并不是全局作用域，而是函数b的局部作用域。说到这里，就可以看到“this是函数在执行时所处的作用域”这一说法的不妥了。假如函数c中引用到了this（在本例中，d是直接调用的，所以this指向的是全局对象），那么按作者的说法，c 岂不是直接运行在全局作用域中而不是b的局部作用域中了？再看下述例子：

var greeting = ‘Hello from global scope!’;

function e() {
alert(greeting);
alert(this.greeting);
}

var tom = {
greeting:’Hello from Tom!’
};
tom.f = e;
tom.f();

这个例子中的this指向的是什么？显然是tom。那么f（即e）执行时所处的作用域是什么？显然是全局作用域。假如f执行时所处的作用域如作者所说为this所指对象的话，那就意味着在本例中f执行时所处的作用域为tom，也就是说在f执行过程中，与其作用域链相对应的那个变量对象链的最前端那个对象是tom，而这就意味着在此时函数体内对名称greeting进行解析时首先遇到的是tom中定义的greeting，于是两条输出语句的结果都应该是“Hello from Tom!”，这不符合事实，所以按作者的说法所做的那个假设是错误的。

对于this这个关键字，我认为不应该扯什么作用域的事儿，只要向读者说明以下几项这样一句话就够了：函数作为哪个对象的方法调用，函数体内的this（不包括嵌套定义在其中的函数中的this）指向的就是那个对象。直接调用一个函数，相当于把它当作全局对象的方法调用。JavaScript 中没有类作用域的概念，因此方法内部要访问据以调用此方法的那个对象的属性，必须使用this关键字，按‘this.属性名’的语法来访问

1. 函数作为哪个对象的方法调用，函数体内的this（不包括嵌套定义在其中的函数中的this）指向的就是那个对象。
2. 结合new运算符调用一个构造函数时，系统会先自动生成一个对象，然后在该对象上调用构造函数。此时在构造函数体内，this指向的就是这个对象。
3. 直接调用一个函数，相当于把它当作全局对象的方法调用。
4. JavaScript中没有类作用域的概念，因此方法内部要访问据以调用此方法的那个对象的属性，必须使用this关键字，按“this.属性名”的语法来访问。

与这个问题相关的还有一个函数体内的名称解析的问题。我看过的JavaScript教材上都说得不太全面。实际上，那种直接引用的名称，其名称解析是在作用域链上进行的；而那种按“obj.属性名”方式引用的名称，其名称解析是在obj的原型对象链上进行的（首先检查obj是否直接定义了同名属性，如果没有，则在其原型对象链上逐层查找）。理解了这一点，就更能搞清前面的this与作用域的瓜葛。

谢廷晟，《JavaScript设计模式》和《深入浅出HTML》的译者。

    

1. 启动 Eclipse，然后选择 Help > Software Updates…。在出现的对话框中，单击 Available Software 选项卡。
2. 单击 Add Site…
3. 在 Add Site 对话框的 Location 字段中输入下面的 URL：https://dl-ssl.google.com/android/eclipse/ 注意：如果访问该插件时遇到问题，可以将 URL 中的 https 改成 http（使用https会更安全一些）。单击 OK。
4. 回到 Available Software 界面，应该可以看到 URL 中包含的插件列表，其中有 Developer Tools 一项。选择 Developer Tools 旁边的复选框，单击 Install…。
5. 在接来下出现的安装窗口中，应该会出现被选中的 Android DDMS 和 Android Development Tools。单击 Next。
6. 阅读并接受许可协议，然后单击 Finish。
7. 重新启动 Eclipse。

1. 启动 Eclipse，然后选择 Help > Install New Software。
2. 在 Available Software 对话框中，单击 Add…。
3. 在 Add Site 对话框的 Name 字段中，输入远程站点的名称（例如“Android Plugin”）。在 Location 字段中，输入下面的 URL：https://dl-ssl.google.com/android/eclipse/注意：如果访 问该插件时遇到问题，可以将 URL 中的 https 改成 http（使用https会更安全一些）。单击 OK。
4. 回到 Available Software 界面，应该可以看到列表中的 Developer Tools 选项。选择 Developer Tools 旁边的复选框，会同时选中 Android DDMS 和 Android Development Tools。单击 Next。
5. 在最后的 Install Details 对话框中，会列出 Android DDMS 和 Android Development Tools 等特性。单击 Next 阅读并接受许可协议，同时安装所有依赖组件，然后单击 Finish。
6. 重新启动 Eclipse。

* 译自http://developer.android.com/sdk/eclipse-adt.html。

之所以想到公开征寻技术审稿人，一是上一本书的样章吸引了120多位朋友的热情参与（“经典名著，精选样章”），几位热心的朋友在出版前也为我指出了一些问题，而这些问题在出版前都得到了妥善解决，保证了最终出书的质量；二是在今天这个开放的环境下，如果还延续那种一个人关起门来翻译的模式，不仅会显得译者自己缺乏公开的勇气，更会拖延译稿中问题的解决（译者无法解决书中全部问题很正常），影响出书进度。况且，样章早晚都是要放出来给潜在读者先睹为快的，后放不如早放，这样也有利于潜在读者提前了解这本书的价值所在和翻译质量——“先尝后买”嘛。

当然，征寻技术审稿人的主要目的，还是为了请领域专家来给译稿把关，尽最大努力来消除翻译中存在的错误或问题，确保最终出书的质量。下面就说一说对技术审稿人的要求：

1、对Android开发有浓厚的兴趣和一定的开发经验；
2、愿意花时间“先睹为快”并有能力指出错误和问题；
3、有一定的中文文字表达能力，能够看懂英文原文。

有意参与这本书技术审校的朋友，请给我发邮件（lsf.email[at]gmail.com）吧，邮件标题请填“Beginning Android 2审校”（以便过滤归类）。

声明一下：对所有参与审校的朋友，我会在译者序中具名致谢。对参与审校而且指出问题较多的朋友，届时将赠送样书（样书可以是本书中文版，或者我翻译过的其他图书，或者图灵公司出版的其他图书——届时我们可以再商量）。

另外，对于只是想“先睹为快”的朋友，也可以给我发邮件，邮件标题请填“Beginning Android 2试读”，我会给大家共享部分样章。

期待Android开发专家、高手、大牛、爱好者，伸出援手、不吝赐教！让我们共同携手，为Android开发社区和爱好者又快又好地奉献一本优秀的引进版图书。

Beginning Android 2

原文链接：http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/
迈克·泰勒（Mike Taylor），2010年4月19日
翻译完成：2010年4月20日

有一些讲编程的图书，我会从头到尾、一字不落地反复研读；还有一些讲编程的图书，我已经看过好几遍了，但每次差不多都是只看其中的一章。乔恩·本特利（Jon Bentley）1986年的经典名著《编程珠玑》（Programming Pearls）则是少数几本能同时归入上述两类的编程图书之一，我手里这本书的封面已经严重磨损，下图可以为证（点击看大图，注意左下角。——译者注）。

（我有这本书的第1版[amazon.com，amazon.co.uk]，上面就是扫描的这一版的封面，好像我该买一本又新又便宜的第2版了[amazon.com，amazon.co.uk]，第2版比第1版多了3章内容。）

我打算最近再专门写一篇关于这本书的文章（我已经为Coders at Work、The Elements of Programming Style、Programming the Commodore 64 和The C Programming Language专门写了几篇书评），但今天我只想就这本书中的几段话谈谈自己的想法。这几段内容有点骇人听闻。

只有10%的程序员可以写出二分查找

每次翻开《编程珠玑》，我都会先看一看下面这几段文字：

几个小时！90%！老兄，严肃点！难道这还不够骇人听闻吗？

之所以想看这本书的第2版，原因之一就是想看看这几段文字有没有修订过，看看从1986年到1999年出第2版，这个数字有没有变化。直觉告诉我，这个数字一定向好的方向变化了，事物都是向好的方向发展的嘛。但理性却告诉我，在一个程序员把更多的时间都花在摆弄库上，而不是编写实际代码的时代，重现核心算法的能力即使有也一定会弱化。别忘了，本特利提到的那些家伙可都不是等闲之辈，他们都是贝尔实验室和IBM的专业人员。所以，我们有理由相信他们的成绩实际上已经是最好的了。

好，下面就做一个二分查找的测验

我跟你一样（如果你是这么想的），想马上就试一试。（好啦，不是马上。先看完这篇文章！）我相信看这篇文章的人都知道什么是二分查找算法，即使你不知道，上面引用的本特利的描述也应该够了。请你打开编辑器，编写一个二分查找例程。什么时候觉得没有任何问题了，保留那个版本。然后测试，然后通过在下面留言的方式告诉我你是不是第一次就做对了。我们肯定能打破本特利10%的纪录吗？

规则如下。

1. 使用你喜欢的任何编程语言。
2. 不要剪切粘贴或以任何方式复制别人的代码。甚至在你写完之前，都不要参考其他的二分查找代码。
3. 甚至于我不得不强调，别调用bsearch()，或使用其他瞒天过海的手法
4. 时间自己来定：5分钟不短——只要你能保证写完写对；8小时不长——只要你愿意（而且有那么多闲工夫）。
5. 可以使用编译器消除一些无意识的错误，如语法错误或变量初始化失败，但……
6. 在确定程序正确之前不要测试。
7. 最后，也是最重要的：如果决定参与这次测验，就必须报告。成功也好，失败也罢，甚至半途而废也要给我个话儿。否则，就无法保证测验结果的准确性了。

（考虑到这只是一次测验，可以忽略计算索引时导致的数值溢出。这里描述了相应的情形，但打算参加这次测验的人在编完程序之前不要看，因为那篇文章里包含一个正确的二分查找的实现，想洁身自好的朋友一定是不屑为之的。）

如果你的代码经验证确实正确，那么如果你愿意的话，欢迎你在留言里贴出自己的代码。不过，假如你这样做了，而后来的留言给你挑出了bug，请你一定想好怎样为维护自己的形象而自圆其说

更酷的玩法：对于那些信心十足的人，如果你真敢肯定自己的程序没有问题，可以先把代码贴在留言里，然后再测试。当然，你必须要在留言里说明这一点，以便大家发现你的bug时，会考虑多少给你留些情面。

我会在某个时间总结一下这次测试的结果——比如说，一周以后。

行动吧！

第一次更新（一个半小时后）

感谢朋友们的积极响应，这么快就有那么多留言！我得提醒大家，WordPress的留言系统会解释HTML，因此会吞掉类似下面的代码段

if a[mid] < value

最好的办法就是把源代码放在{source}…{source}标签之间，注意用方括号代替这里的花括号。（我第一次想告诉大家这一点时，使用的是方括号，结果我写的规避标记的说明，反而被当成了标记——悲哀呀！）这样做还可以保留缩进，否则我还不知道有什么办法可以做到这一点。

替WordPress向大家致歉：我真的希望这个平台允许留言者预览留言和/或在发表后还能编辑留言，这样就可以避免出现乱七八糟的代码了。我也想了办法自己动手解决这个问题，但WordPress不仅会错误地显示带有<符号的代码，它实际上会丢弃该符号后面的所有内容，唉，我想我是没折了。

第二次更新（在原文章发表4个小时后）

哈哈，你们这些家伙太出人意料了。仅仅4个小时，这篇文章的留言数就超过了以前的一篇文章保持的纪录（Whatever Happened to Programming此时的留言有206条）。

如果想看到相关的更多讨论，Hacker News中有不少不错的留言，另外Reddit的留言质量虽然差一点，但也值得一看。这些讨论把实际地编写代码看成只有精英程序员才会干的事。

先说非技术问题。

很简单，启动Android模拟器（需要先创建AVD）时，先看到的是一个文本界面，我一开始以为自己的配置出了什么问题。迷惑了大半天，晚上从外面吃饭回来，突然想起来《Android基础教程》（人民邮电出版社，2009年11月）中有一段提示：“启动模拟器需要花较长时间。可以这样想象一下——首次开机时，手机也需要启动，就像任何计算机系统一样。关闭模拟器就像是关闭手机或取出手机电池一样。”会不会是我太着急了？应该有点耐心才好。于是，我重新启动模拟器，耐心等待……大约3分钟后，终于看到Android的图形用户界面，OK。

正好《Beginning Android 2》这本书中也有一段相关的话：NOTE: The first time you use an AVD with the emulator, it will take substantially longer to start than it will subsequent times.（注意：第一次使用AVD来启动模拟器的时间会比较长，后续的启动速度会有所提升。）

再说技术问题。

前面只是解决了启动模拟器的问题，接下来就是要在模拟器中实际地加载新应用程序并进行测试。但是，我新创建了FirstApp应用程序，在通过Eclipse运行该项目时（也可以在命令行中使用ant构建项目，然后运行android命令，再启动模拟器；不过，这需要再下载其他软件包），提示出错，错误信息如下：

1. Project “FirstApp” is missing required source folder: ‘gen’
2. The project could not be built until buid path errors are resolved.

在网上搜索到几个解决方案（列在下面，供朋友们参考）。但奇怪的是，在刚搜索到第一个方案时，还没等到采取任何措施，Eclipse中的错误居然自动消失了（FirstApp项目下方的红叉也不见了），再Run as Android Application，一切正常了。我想，也许正如第三个方案中某人所说的，Eclipse并不能实时检测到OS文件系统的变化（编译项目时，会生成新文件），这也许就是导致这个技术问题的原因——至于是不是这个原因，还有待于进一步求证。

一、右击项目，选择preferences->builder，在右边的configure一栏中将Android Packege Builder一项提到Java Builer之前
出处：http://www.androidin.net/bbs/thread-708-11-1.html

二、将Eclipse自动生成的R.java删掉，刷新项目，R.java便会重新生成
出处：http://www.blogjava.net/crazycoding/archive/2010/03/27/316701.html

三、在项目文件夹中新创建一个Java类或者直接修改自动生成的类文件
出处：http://www.coderanch.com/t/466092/Android/Mobile/android-eclipse

以下是几个人的回复，感觉这种讨论的技术氛围很不错。今天太晚了，明天天亮还要去平谷，回来再翻译。

James Dixon的回复
Hi Divya
I’ve had the same problem as well. I think the issue is that the project creation does not initiate a build when it finishes, so you need to make a change, and save for it to generate the gen folder.
For me creating a new java class seemed to do the trick, but I’d imagine just making a change to a file and saving should work too.

Robert F. Howard的回复
I just ran into this, too. I am following the example in Hello Android, which I assume is what the others in this thread were doing. James’s solution (editing the source file) worked for me, so thank you for that.
So your solution is good, but I don’t think I totally believe the diagnosis. The thing is, the directory actually did exist before I edited the file and rebuilt. This is my first time using Eclipse, and it’s very disappointing. The error message should specify the full path of the directory it wants, and then it should be possible to create the directory and re-build, but it doesn’t work until the source file is edited. It makes me wonder what is really going on inside Eclipse.

Tim Holloway的回复
This seems to be a small glitch courtesy of Eclipse’s distancing itself from the OS filesystem (which is why Eclipse has an explicit Refresh command).
The gen folder and the “R.java” file are built by one of the Android utilities. The Eclipse Android plugin invokes this app, but it doesn’t always know when it needs to. I have similar problems when I want to define a new resource ID. Since I can’t seem to get the GUI resource ID definer to enable itself, I just create new IDs in the resource files themselves. But unless I trigger the android resource generator, they don’t get inserted into “R.java”.
And you don’t want to manually insert into “R.java”, because when the resource compiler does fire off, your code mods will be overwritten.
One way to force the issue is to select the Project/Clean menu command. If you have the automatic build switched off, you’ll then have to initiate a build. Otherwise the clean will fire off the auto-build process.

先期需要下载的软件包如下：

1、JDK 1.6+
2、Android SDK 1.6
3、Android SDK Setup
4、Eclipse IDE for Java Developers

看到这些，可能心急的朋友会禁不住问：“不是要构建Android 2.1开发环境吗？怎么还要下载Android SDK 1.6而不是2.1呢？”

没错，是要讲怎么构建Android 2.1开发环境。但是，经过几次尝试，我发现直接下载安装Android SDK 2.0和2.1有问题。什么问题？简单地说，就是这两个最新版本的SDK包中都不包含adb.exe文件，无法在Eclipse中指定Android SDK的位置（也就意味着没法使用Eclipse来开发）。因此，这才走了一条曲线救国的道路；也许，正如我自己的尝试所证实的：Android SDK 2.0和2.1实际上都是升级包，而不是完整的开发包。我比较了一下，Android SDK 2.0和2.1的大小分别是76.6MB和77.3MB，而Android SDK 1.6的大小则是248MB，相差还是很悬殊的，这一点似乎也佐证了我的判断。但是，不管怎样，先下载Android SDK 1.6，然后再通过ADT（Android Developer Tools，Android开发人员工具）和Android SDK Setup程序来下载和更新Android SDK 2.0和2.1，是成功了。

闲话少说，言归正传。

首先，访问http://java.sun.com/javase/downloads/widget/jdk6.jsp
下载Java SE Development Kit 6u20（jdk-6u20-windows-i586.exe）
文件大小76.67 MB。

其次，访问http://dl.google.com/android/archives/android-sdk-windows-1.6_r1.zip
下载Android SDK 1.6（android-sdk-windows-1.6_r1.zip）
文件大小248M。

然后，访问http://dl.google.com/android/android-sdk_r04-windows.zip
下载Android SDK Setup（android-sdk_r04-windows.zip）
文件大小22MB。

最后，访问http://www.eclipse.org/downloads/
下载Eclipse IDE for Java Developers（eclipse-java-galileo-SR2-win32.zip）
文件大小92.7MB。

下载完成后，开始安装和配置。

第一步，安装和配置JDK。

下载后，双击运行jdk-6u20-windows-i586.exe，假设选择安装到C:\Java\jdk1.6.0_20目录下（当然，安装到默认路径下也没有问题）。安装完毕后，就是配置环境变量。步骤如下：

(1)设置JAVA路径

在“我的电脑”上点右键，选“属性”，打开“系统属性”对话框，点“高级”选项卡，再点“环境变量”按钮，在打开的对话框中的“系统变量”下方，点“新建”，然后在对话框中的“变量名”中填JAVA_HOME，在“变量值”中填C:\Java\jdk1.6.0_20，点“确定”。

(2)设置CLASS路径

再“新建”一个系统变量，在“变量名”中填CLASSPATH，在“变量值”中填.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar。
说明：最开始的.;中的.（点）表示当前路径，;（分号）是路径分隔符。接下来的%JAVA_HOME%引用的是前面刚创建的JAVA安装路径。

(3)设置PATH路径

PATH变量一般都有了，因此选中点“编辑”，然后在“变量值”后面加上;%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin，注意前面的分号。

这样，JDK就安装好。“开始->运行”，输入cmd，然后在命令行提示符中输入：java -version，应该能够看到java version “1.6.0_20″信息；JDK安装成功。

第二步，解压和配置Android SDK 1.6

将下载到的android-sdk-windows-1.6_r1.zip解压缩到C:\android-sdk-windows-1.6_r1目录中（解压到哪个目录都没有问题）。然后，配置环境变量。步骤如下：

(1)设置Android路径

重复第一步的(1)，新建一个“系统变量”，在“变量名”中填Android_Home（大小写没有问题），在“变量值”加填C:\android-sdk-windows-1.6_r1。

(2)设置PATH路径

“编辑”PATH变量，在“变量值”后面加上;%Android_Home%\tools，注意前面的分号。

这样，Android SDK 1.6就安装好了。“开始->运行”，输入cmd，然后在命令行提示符中输入：android -help，应该能够看到帮助信息；Android SDK 1.6安装成功。

第三步，解压Eclipse，关联Android SDK，安装ADT

将下载到的eclipse-java-galileo-SR2-win32.zip解压缩到C:\eclipse，然后进入这个文件夹，双击eclipse.exe，启动Eclipse。

安装ADT：菜单“Help -> Install New Software…”，打开Install对话框，点击Add…按钮，添加站点（Add Site），在Name中填ADT，在Location中填https://dl-ssl.google.com/android/eclipse/。然后，下载安装ADT。

关联Adnroid SDK：菜单“Windows->Preferences”，打开Preferences对话框，点击Android，在右侧的Android Reference中，点SDK Location文本框右侧的Browse…按钮，找到C:\android-sdk-windows-1.6_r1，“确定”。

第四步，解压Android SDK Setup，下载更新Android SDK 2.0和2.1

将下载到的android-sdk_r04-windows.zip解压缩到C:\android-sdk-windows，然后进入这个文件夹，双击SDK Setup.exe，启动Android SDK and AVD Manager，选中左侧Settings项，然后在右侧面板选中Force https://… sources to be fetched using http://，然后选择Save & Apply。然后，参见这里的图解：

如何使用Android SDK Setup? http://www.android123.com.cn/zhongwensdk/366.html

我选择了所有需要更新的内容，包括：

• Android SDK Tools, revision 5
• Documentation for Android SDK, API 7, revision 1
• SDK Platform Android 2.1, API 7 revision 1
• Sapmles for SDK API 7, revision 1
• SDK Platform Android 2.0.1, API 6, revision 1

耐心等待吧——注意，如果更新过程有提示，可能是因为你正在使用C:\android-sdk-windows-1.6_r1目录，或者杀毒软件不允许改写其中的文件，此时需要退出所有程序或暂时关闭杀毒软件。

一切顺利的话，到此Android 2.1开发环境（或者说，Android 1.6、2.0和2.1的开发环境）就构建好了。

附录：

Android开发包及相关软件下载地址
http://www.android123.com.cn/android_kit.html

鸣谢：http://www.android123.com.cn/

原文链接：http://carsonified.com/blog/dev/john-resig-on-advanced-javascript-to-improve-your-web-app/
录音整理：http://carsonified.com/blog/author/keir-whitaker/
在线演示：http://ejohn.org/apps/workshop/adv-talk/index2.html

谢谢。感谢邀请我来这里的所有人。真的非常感谢。今天，我想谈两个话题，基本上是围绕jQuery展开的，但我会尽量照顾到那些没有使用jQuery的朋友，希望这两个话题对你们开发Web应用也会有所帮助。

在座的所有朋友在开发Web应用时，可能都要用到几种技术。我们总想提升JavaScript代码的性能，总想增强易访问性，让代码更简单一点。最后，我们还想让设计过程再容易一些。

说到性能，在JavaScript中有很多技术可以运用，其中有三个比较容易，而通过jQuery来实现则会更容易。一个就是事件委托。事件委托是一种绕过传统方法的事件绑定技术。我的意思是说，通常在为某个元素添加单击处理程序时，你都是为每个需要绑定单击事件的元素，分别绑定单击处理程序。这样做真的很浪费。如果有一个包含上千个单元格的表格，那么你就要添加大量的单击处理程序。

事件委托，就是在你添加处理程序时，要添加到DOM树上层的某个父元素上。比如，添加到表格上，而不是添加到每个单元格上。这样就可以利用浏览器原生的事件冒泡机制。也就是说，用户在单击某个单元格时，事件会沿DOM树向上冒泡，冒泡到表格，而你可以在这个时候再处理它。这就是事件委托。

这样一来，你只要为文档添加一个事件就行，根本用不着添加几千个。而且速度又快，灵活性又高。为此，jQuery提供了两个方法；一个是“dotlive”（.live()）。另一个则是我们前几天刚刚添加的方法，即“delegate”（.delegate()）。关于委托，除了它的速度快之外，我认为真正有价值的地方在于，它对所有当前乃至未来的元素都有效。即便现在文档中只有一千个单元格，而你又添加了一千个，它照样还是有效。你不用为处理新增的单元格而添加新处理程序。

委托方法（.delegate()）是这几天我们刚刚加进来的。这个方法的本质就是将委托的概念具体化了。下面我想讲一个实际的例子。假如你想为某个核心元素，例如表格，添加单击事件。然后你还要监视（这个表格中）任意单元格上的悬停事件。那么，只要编写短短几行代码，很快就可以实现你的意图。

$(“table”).delegate(“td”, “hover”, function(){
$(this).toggleClass(“active”);
});

实时事件（.live()）则是另外一种编写和实现委托的方式，但关键是它能起作用，并且看上去与事件绑定的效果还完全一样。你可以使用相同的语法，可以使用选择符，然后可以直接给它添加事件，或者至少看起来是直接的。而在后台，jQuery会帮你周旋并确保一切都各就各位。

举个例子，我们这里在鼠标悬停时会显示一些菜单，子菜单在消失时带一个小动画。有意思的是，如果我们又添加了新菜单，这个新添加的菜单也会带有相同的动画。这时候，动画效果的添加就是实时的。而且，不管是对页面中当前还是将来的元素，也都会持续有效。（点击这里查看交互演示。）
$(“a.menu”).live(“hover”, function(){
$(this).next().toggle(200);
return false;
});

[未完待续……]

前不久，杰夫、我，还有埃里克一块参加Stack Overflow Podcast的在线聊天。哥几个针对版本控制问题，狠狠地发了一通牢骚。特别是大批特批了以Mercurial和Git为代表的、新潮的DVCS（Distributed Version Control System，分布式版本控制系统）。

聊天中，我说：“我觉得，用它们来做分支和合并更简单，恰恰说明了你的同事可能会做更多的分支和合并。结果呢，就是你会把自己绕进去，最后非晕菜不可。”

说实话，你们也猜得到，参加那种聊天活动，不需要事先准备什么，不过是几个人东拉西扯地闲聊天而已。既然是闲聊天嘛，就免不了说错话，或者用技术术语来说就是——犯错误。要么哪句话里有错误，要么出发点有错误，要么就是出发点和话里都有错误。但这一次，我犯了一个低级错误。就像草莓配比萨、辣椒配面包，属于那种低级得不能再低级的错误。

在这次聊天之前，我们团队已经切换到Mercurial很长时间了，但这次切换真的把我搞晕了，我不得不花钱请人替我check in代码（开个玩笑）。不过，有一段日子我确实不好过，因为我得记住几个关键的命令，想象着自己是在Subversion中使用它们，期待能看到熟悉的结果。可是，一旦碰到结果跟我想象得不一样，我就会大惑不解。为此，我经常得颠儿颠儿地跑到楼下大房间里，请教本杰明或者雅各布。

你猜我的团队怎么说，“哎，乔总，这‘水银果汁’^[注1]太神了，我们打算用实际的产品代码来测试一下它。另外，还有，这一点更重要，我们发现了一个大市场，我们可以为它提供有偿技术支持和托管服务。”（Mercurial是基于GPL的自由软件，但有不少公司在决定使用什么之前，总会需要某种支持。）

我心里想，你们问我，我问谁？你们都知道，我在公司并不真正作主，因为“管理的职能就是提供支持”嘛。然后，他们就把所有6名实习生都组织起来，动手开发基于Mercurial的产品。

真不能再拖下去了，我必须得尽快弄明白，所谓的“分布式版本控制”到底咋回事。免得我们公司的产品都上市开卖了，人家让我介绍产品，我自己都说不出个子丑寅卯来。那样的话，博客圈里又会有人跳出来，对我指手画脚，说我糟蹋好东西了（junking the sharp）。

于是，我学呀，学呀，最后终于闹明白了。今天，我想跟大家在这里分享一下。

在分布式版本控制系统中，所谓的“分布式”其实不是最关键的。

最关键的是在使用这些系统时，你时刻要想着“更改”，而不是“版本”。

我明白，这里边其实有几分“道可道，非常道”的意味。在使用传统的版本控制系统时，你会想：嗯，这是版本1，这是版本2，这是版本3。

而在使用分布式版本控制系统时，其实我不用想版本。我只要想，我做了这些更改，我又做了另一些更改。

“程序模型”变了，“用户模型”也得跟着变。

在Subversion中，你可能会想，“要保证我的版本跟主版本随时一致”，或者“恢复到前一个版本”。

在Mercurial中，你会这样想，“看看雅各布的更改”，或者“我们先不用考虑那些更改”。

如果你在使用Mercurial时，心里想的是Subversion，多数情况下倒也问题不大；但是，万一出了问题，你就会找不着北、会不高兴，最后因为无计可施而恨上Mercurial。

可是，如果你能够解放思想，换一个角度来看版本控制，就能悟出管理“版本”与管理“变更”的差异所在。你会觉得豁然开朗，由衷地感叹这才是控制版本的最佳方式。

没错，是有点异样的感觉——从1972年至今，所有人关注的都是怎么管理版本，而今天，人们突然要去关注更改本身了，能不感觉异样吗？而且，关注更改解决了一个非常重要的问题：合并分支代码。

这一点最重要了。没错，在长达10年的时间里，我们深刻地体会到，这一点对提高开发效率最为重要。重要到了什么程度呢？重要到在我今天最后一次谈软件时，必须要反复强调它。好了，如果你只想记住一句话，那就记住下面这句：

在管理更改而非管理版本时，合并很容易做到，你可以根据工作需要随时创建分支，因为合并已经是小菜一碟了。

记不清有多少个使用Subversion的用户，曾对我说过下面这番话：“用它创建分支代码的时候，没什么问题。但是，等到要把分支合并到一块时，那个费劲啊，我们不得不手工重新应用每一次更改。我们发誓，这种蠢事一辈子也不会再干了。结果，我们想出了一个开发软件的新主意，就是用if语句，不用分支。”

有时候，他们在提到自己发明的这种一个主干的做法时，甚至还有几分得意。好像弥补了自己版本控制工具的不足，就可以流芳百世了。

使用分布式版本控制系统，合并简单，还不会出错。所以，你可以创建一个稳定的分支、一个开发分支，还可以为QA团队创建一个长期使用的分支，以便在实际部署之前进行测试。当然，还可以创建一个临时分支，用它来验证各种想法，观察结果。

这一点太重要了，怎么强调它都不算过分。自从我10年前开始写博客以来，这恐怕是我笔下的软件开发技术领域中最大的进步了。

或者，可以换一种说法，如果我要放弃Mercurial，除非是我想再使用C++。

如果你还在使用Subversion，停止使用。马上停止使用。Subversion＝水蛭。Mercurial＝抗生素。我们现在有更好的技术了。

很多人在没有完全理解这种新程序模型的情况下，往往会盲目地使用Mercurial，而这容易让人觉得它有问题，不可靠。为此，我专门写了一套Mercurial教程，叫做HgInit^[注2]。

如今，要是有人问我那次聊DVCS时为什么要贬低DVCS，我会告诉他们那是我精心设计一个圈套，我是在放烟雾弹，目的是要迷惑我的老朋友和老竞争对手埃里克——他在开发一个非分布式的版本控制系统。就像上一次他要卖bug追踪软件一样。那一次，为了惩罚他，我们用一个特制的信封寄给他一个非常值钱的Fog Creek双肩背包。让他觉得我们会在圣诞节的时候，也会把这么值钱的背包作为圣诞礼物，送给所有FogBugz软件的客户。

我的博客写到今天，时间已经够长了。10年来，大家能够坚持阅读我写的文章，是我莫大的荣幸。这个博客的读者群能达到今天这个规模，是我当初做梦也想不到的。无论你是谁，是花自己的时间把我的文章翻译成40多种语言的那几百位志愿者中的一员，是给我写过电子邮件的22 894位朋友中的一位，是订阅了我的邮件简报的50 838名订阅者之一，还是每年2 262 384位访问这个站点并阅读了我写的1 067篇文章中哪怕只言片语的读者中的一位，我都要由衷地感谢你，感谢你对我的关注。

翻译无小事：要有使命感

当你录入每一个字的时候，无论正确或者错误，优雅或者蹩脚，它都有可能（如果没有在你自己日后的审查或者出版社的编审环节中被发现和解决的话）变成历史，保存在大大小小的图书馆里，被成千上万的（纸书和网络连载、电子版的）读者看到并对他们产生影响。

很多技术书，首印以后可能不会重印，所以，错误可能永远留在那里。勘误表当然能起到一定作用，但是请注意，我们没有办法将勘误表送到每个读者手里。而且，想想拿着勘误表在书上改正，该是一件多么痛苦的事情。

翻译无易事：不要过于自信

著名翻译家傅雷当年全职在家里专事翻译，呕心沥血，不过“日译千字 ”。（当然，我们毕竟翻译的是技术文档，难度和要求都小得多，我见过有经验的译者全职翻译每日万字左右的。）

有的译者会说：“这本书我读起来很轻松啊，翻译没问题！” 其实，翻译和阅读不同，能差不多看懂，和逐字逐句转变成地道流畅的中文，让读者（可能包括基础稍差的）在不接触原文的情况下容易地理解原作者所说的意思，基本上不是一回事。

有的译者会说：“这本书里的技术我很精通，翻译起来很容易。” 其实，翻译书的时候，所面临的技术问题相对较少（因为书往往是自成一体的，凡事多有来龙去脉。但是注意，只是相对！你很可能遇到自己不熟悉甚至根本不懂的技术领域），除了有些原书代码、叙述等等本身就有错，一般不难解决。毕竟你把开发环境架起来，试一下，基本上都可以搞定。 常见的错误，反而更多是因为英文本身不理解或者误解造成的。往往一个小小的复数、this、the、被动语态、and等连词的翻译或者理解错误，会造成整句、整段甚至多段的译文难以理解，或者逻辑错误。

翻译之难在于，它不仅考验你的：

1. 技术能力 。一本书涉及的技术内容可能很丰富，一个译者不见得能够全部精通。
2. 英文水平 。我们这一代的人所受的英文教育，基本上是不能轻松应付翻译这种工作的。
3. 中文水平 。理工科出身的我们，语文最多只是中学水平，而且教法学法很畸形。大家应该都有同感。

更考验你的：

4. 研究能力 。翻译中肯定会遇到技术或者非技术的词和短语你没见过、不知道的，而且有不少词和短语字典里也没有现成答案。
5. 逻辑思考能力 。英语很多句子里的代词和其他意义不那么明显的表达，需要通过上下文的逻辑思考进行推断。
6. 知识面 。原作者会追溯历史，讲很多老的技术，也会纵横开阖地进行横向比较，涉及很多其他平台或者技术（有些还很冷僻）。原书里还会有很多仅限于欧美文化 （名人名言、历史、地理、游戏、影视、歌曲……）的比喻、闲话等等。比如计算机书里常常出现的Yogi Berra。
7. 耐力 。翻译往往要持续数月，而且大部分同学肯定都是业余工作，深夜孤灯，而且一本书里肯定有你不喜欢或者没感觉的部分，但是还是得翻译出来，其辛苦程度可知……
8. 细心 。毛糙的译者交出的稿子，错别字、标点符号、术语一致性都会是大问题，更令编辑头疼的，还可能存在大量零散的漏译、英文拼写错误，以及最严重的，因为 粗心而造成的严重漏译（有时候单复数没有看清楚，指示代词没有理解对，会造成整句的误译；有时候连词的误译，会弄反整段话的逻辑）。
9. 沟通能力 。翻译往往不是一个人完成的，而且所有译者都要和编辑打交道。不及时沟通，可能造成整个项目的失败——因为交稿延期或者稿件不符合出版社要求、编辑工作时间很长，最终出版进度一拖再拖，出书的时候已经过时或者没有市场了。
10. 交际圈 。遇到自己无法解决的问题，尤其是特定领域的问题，需要相关的专家支援。

翻译无难事：也没什么大不了的

翻译毕竟只是一种转换别人现成文字的工作，并没有什么完全无法克服的困难，何况我们面对的知识技术文献而已，含义基本准确固定，对艺术性没有太多要求。

只要做到以下这几点，翻译就没什么大不了的。

1. 多想：带着逻辑思考去翻译。

翻译本身大多时候是在词、短语和子句的层次工作，但是思考层次必须提高。一本书都是从总到分逐层细化的树状结构，翻译时脑子里要有更大范围的上下文。

和 阅读时应该在脑子里读出作者的逻辑脉络（这一章先讲了什么，又讲了什么，这一点又分为几部分、几个步骤……，对于这个问题，先说了Solution A，然后又说了Solution B，C，A的问题是……，B的问题是……，C克服了这些毛病……作者对这些选择的态度是A不好，B不好，C好……）一样，翻译时也要有类似的脑图。

翻译一个词时，要考虑全句、全段、上下几段甚至全节、全章和全书的整体思路和作者倾向。

另 外，原书是肯定会有错的，像Effective Java那样的名著，曾经被日文版译者找出大量错误。我们所出的《SQL解惑》一书，作者虽然是世界级权威，但是我们的译者也发现了大量错误。按照逻辑， 根据自己的技术基础，可以发现各种错误。整理勘误表，提供给编辑，反馈给原作者。

2. 多查：善于利用工具。

傅雷当年“日译千字 ”，有论者说，是因为没有那么方便的工具。的确如此。今天，任何问题在没有充分查找的情况下，就说无法解决，都是不负责任的。

图灵公司的论坛 （实名制，需要提供自己的个人信息进行申请）上有一个网上的词汇表 ，收集了很多常见的不容易处理、有歧义的术语、习语以及其他词语的译法，请优先参考。

我们不仅有很好的英语字典、够用的中文字典，而且有方便的网上内容，Wikipedia、FreeDictionary。当然，还有Google等等搜索引擎。有了Google、有道这样的语料库，基本上没有什么问题是无法解决的。请参考：图灵推荐工具 。

高效查询的关键在于，该查的时候一定要查！其次，要知道上哪里查比较权威。直接Google的结果，往往会误导你，迷糊你。

专有名词（人名、公司名、电影名……）不知道一定要查，否则你很可能连他说的是什么都没有搞清楚！这种笑话非常常见，我见过一个稿子，把某乐队的专辑翻译成什么纪念册的……

当然，知道这是个专有名词，有时候也是需要智慧的。

不熟悉的术语、领域名词一定要查，否则就会翻译得牛头不对马嘴，轻者也是外行话。

译文里想用成语、典故或者比较少见的自己不太有把握的词，也请查中文字典。这些少见词往往不能望文生义，往往感情色彩比较特别（贬义多）。对自己的中文水平要有正确认识。比如“明日黄花”而不是“昨日黄花”。再比如“望其项背”只能用否定。

3. 多问：善于利用别人。

谁也不是全知全能，百科专家。有时候，问对了人，比自己查找、研究半天，效果好得多。

请记住，你不是一个人在战斗。

图灵公司有经验丰富的编辑，他们看过无数类似或者相关的稿件，很可能你的问题早已经被解决了。遇到问题，请多多与编辑沟通，不要企图隐藏或者糊弄过去 。对编辑的修改意见，不要轻易否定，尤其是标准、规章、规矩性的要求，请尽量遵守。
如果在稿件中对原文有比较特殊的处理（原文有错，对原文的句序、句式、说法等等有较大改变，原文某句不宜翻译，或者翻译出来对中国读者无用、无效、无意义，等等），没有按照原文翻译，请在稿中用批注说明，不要让编辑再浪费时间琢磨 。
请一定加入图灵俱乐部论坛 ，有许多和你一样在翻译和曾经翻译过书的译者以及行业内的专家，会为你分忧，和你讨论。

4. 开放：多一双眼睛总是好的。

我们要求译者将序、前言、致谢和前三章内容翻译完毕之后，尽快贴到图灵俱乐部论坛 上，接受内部审读。

我们也要求编辑将修改意见更多地开放，接受更多人的检查。

我们鼓励译者在个人网站、blog、论坛等等场合在征得编辑的同意后，公开少量章节的翻译草稿，听取广大读者的意见。一般章节开放数量不能超过原书的四分之一。而且必须在最前面写上：
“本文节选自即将由人民邮电出版社图灵公司出版的《XXX》（英文版XXXXXX）一书，已经过图灵公司授权，如需转载，请与contact@turingbook.com联系。”

5. 翻译完了自己再看一遍

这一点虽然容易，但是一般都做不到。许多错误被编辑发现之后，译者第一个反应会是，啊，这个怎么都错了！为了防止自己犯被读者痛骂、被啐一脸口水、被扔一身鸡蛋的错误，谨记。

最后两点重要的说明

1. 翻译中，发现任何涉及意识形态（说到中国、共产主义、共产党、社会主义、马克思主义等等）、政治、民族（尤其是藏族、维吾尔族、回族）和宗教以及其他敏感话题，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。

2. 翻译中，遇到自己不懂、不好解决的问题，首先要多查多问。如果在交稿前仍然没有解决，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。千万不要掩饰、隐藏起来，铸成大错。

另外，特别推荐思果先生的翻译原则 ，请反复体会：

1、发邮件到：lisf@turingbook.com。
2、邮件主题：《JavaScript高级程序设计（第2版）》样章；邮件内容：您的Email地址。
3、24小时内收到样章，先睹为快！

第3章 基本概念
第4章 变量、作用域及内存问题
第5章 引用类型

本书是人民邮电出版社图灵公司引进出版的大畅销书、JavaScript权威著作《JavaScript高级程序设计》的最新升级版。《JavaScript高级程序设计》自2006年11月出版以来，已经累计销售逾30000册，而且至今仍然十分畅销。这一点可以通过北京新华文化发展有限公司（新华书店）近期的店面销售数据看出来（大家可以自行比较一下其他畅销书的销量）。应该说，在Web 2.0革命爆发的同时，人民邮电出版社图灵公司引进出版的本书成就了计算机图书市场上难得一见的奇迹。

本书作者尼古拉斯·扎卡斯（Nicholas C. Zakas）现为Yahoo!公司首席前端工程师，世界顶级Web技术专家。原书第1版曾被选为Yahoo!公司YUI（Yahoo! User Interface Library，Yahoo!用户界面库）团队的内部培训教材。

2009年初，本书第2版面世（《Professional JavaScript for Web developers, 2nd Edition》）。新版本不仅篇幅由原来的600多页增加到800页，而且几乎全部更新、重写了上一版的内容，删除了上一版中与今天的职业需求无关的主题，新增了大量比上一版更有价值、更能反映JavaScript最新发展成果的内容。从颇具深度的JavaScript语言基础到作用域（链），从JavaScript引用类型到面向对象编程的最佳实践，从极其灵活的匿名函数到闭包的内部机制，从浏览器对象模型（BOM）到客户端检测，从文档对象模型（DOM）到基于事件的Web脚本编程，从错误处理到前端调试，从XML（E4X）到Ajax及JSON，从高级前端开发技术到前沿的客户端存储，从最佳编程实践到展望即将成为现实的API，直至JavaScript未来的发展。全书彻底涵盖了JavaScript技术的各个方面，几乎涉及到了Web前端开发的每一处细节。可以预见，这部著作一定会成为Web前端开发人员不可多得的又一部经典。

目前，《JavaScript高级程序设计（第2版）》的翻译工作已经进入后期阶段（全书22章，所剩不到5章）。而且，为确保新版及时上市与读者见面，出版社采取了与译者同步翻译、同步编辑审校的特别措施。新版本预计2010年上半年可以上市；当然，在确保出版品质的前提下一定会尽量往前赶！

第3章 基本概念 1
3.1 语法 1
3.1.1 区分大小写 1
3.1.2 标识符 1
3.1.3 注释 2
3.1.4 语句 2
3.2 关键字和保留字 3
3.3 变量 4
3.4 数据类型 5
3.4.1 typeof操作符 5
3.4.2 Undefined类型 6
3.4.3 Null类型 7
3.4.4 Boolean类型 7
3.4.5 Number类型 8
3.4.6 String类型 14
3.4.7 Object类型 16
3.5 操作符 17
3.5.1 一元操作符 17
3.5.2 位操作符 20
3.5.3 布尔操作符 26
3.5.4 乘性操作符 29
3.5.5 加性操作符 30
3.5.6 关系操作符 32
3.5.7 相等操作符 34
3.5.8 条件操作符 35
3.5.9 赋值操作符 36
3.5.10 逗号操作符 36
3.6 语句 37
3.6.1 if语句 37
3.6.2 do-while语句 38
3.6.3 while语句 38
3.6.4 for语句 38
3.6.5 for-in语句 40
3.6.6 label语句 40
3.6.7 break和continue语句 41
3.6.8 with语句 42
3.6.9 switch语句 43
3.7 函数 45
3.7.1 理解参数 47
3.7.2 没有重载 48
3.8 小结 49

第4章 变量、作用域和内存问题 1
4.1 基本类型和引用类型的值 1
4.1.1 动态属性 2
4.1.2 复制变量值 3
4.1.3 传递参数 4
4.1.4 检测类型 6
4.2 执行环境及作用域 6
4.2.1 延长作用域链 9
4.2.2 没有块级作用域 10
4.2.3 声明变量 10
4.2.4 查询标识符 11
4.3 垃圾收集 12
4.3.1 标记清除 12
4.3.2 引用计数 13
4.3.3 性能问题 14
4.3.4 管理内存 15
4.4 小结 15

第5章 引用类型 1
5.1 Object类型 1
5.2 Array类型 3
5.2.1 转换方法 6
5.2.2 栈方法 7
5.2.3 队列方法 8
5.2.4 重排序方法 9
5.2.5 操作方法 11
5.3 Date类型 12
5.3.1 继承的方法 14
5.3.2 日期格式化方法 15
5.3.3 日期/时间组件方法 15
5.4 RegExp类型 17
5.4.1 RegExp实例属性 19
5.4.2 RegExp实例方法 19
5.4.3 RegExp构造函数属性 21
5.4.4 模式的局限性 23
5.5 Function类型 23
5.5.1 没有重载（深入理解） 25
5.5.2 函数声明与函数表达式 25
5.5.3 作为值的函数 26
5.5.4 函数内部属性 27
5.5.5 函数属性和方法 29
5.6 基本包装类型 31
5.6.1 Boolean类型 32
5.6.2 Number类型 33
5.6.3 String类型 35
5.7 内置对象 42
5.7.1 Global对象 43
5.7.2 Math对象 46
5.8 小结 49

上个月，我又参加了Mozilla公司组织的一次研讨会，这一次讨论的是Web数据库。虽然研讨会的议题很有意思，但我觉得会议期间大家对另一个问题的争论似乎更值得关注。争论中，与会者针对浏览器到底应该为JavaScript提供什么样的API分成两派。一派坚持认为原生的JavaScript API应该尽量保持低级化，然后由库开发者在低级API基础上再去构建更好用的接口。另外一派，也是我所在的阵营，则认为中级API才是大势所趋。没有人认为浏览器应该向开发人员提供高级API。所谓低级、中级、高级到底都是什么意思呢？

低级API

低级API仅为提供基本功能而设计。由于只要能实现相应功能即可，因此这种API不需要很直观或者很好理解。有时候，低级API确实会给初级甚至中级开发人员造成理解上的困难。这样一来，借由人们频繁使用来发现相应API问题的机会就大为减少了。大家都会指望库开发者在这些低级API基础上实现直观、好用的API，以便于普通开发人员使用。doument.cookie就是说明低级API最好的一个例子。

作为JavaScript开发人员操作cookie的唯一接口，document.cookie可谓有史以来最难使用的一个API。关于cookie，我专门写过一篇文章，还探讨过它的安全性问题，其中都涉及到如何在JavaScript中使用它们；因此，这里只能算是一个简单的介绍了。要设置cookie，必须以正确的cookie格式来设置document.cookie属性，例如：

document.cookie = “name=Nicholas; domain=nczonline.net; path=/; expires=Sat, 02 May 2009 23:38:25 GMT

要取得cookie，则需要读取document.cookie，返回的字符串是如下列所示的名值对格式：

name1=value1; name2=value2; name3=value3; name4=value4

而为了得到想要的值，必须先从这个字符串中查找相应的名字，然后再解析出相应的值。

之所以把这种API归类为低级API，是因为其实现要求你必须先了解cookie的内部格式，然后才能使用它。实际上，document.cookie属性只是在简单地模仿Set-Cookie和Cookie这两个对开发人员不可见的HTTP首部。为了写cookie，必须要理解字符串的确切格式，这涉及到其中的名和值必须采用URI编码形式，而其他片段之间必须以一个分号和一个空格来分隔，此外还必须知道设置过期日期的正确日期格式。反过来也一样，在读cookie时，你同样需要知道返回的字符串是什么格式，然后才能从中解析出想要的数据。这就是所谓的“遇繁不简，遇简也不简”。一句话，这种API对于不了解cookie的人根本没有用。

如果大多数开发人员都不会直接使用某个API，你就可以说它是低级API。不用，是因为使用它们所需的知识储备（Cognitive Overhead）太多了。绝大多数开发人员在使用JavaScript读写cookie时，最终都会求诸于一个JavaScript库例如YUI中的Cookie工具（YUI2和YUI3），这些工具把那些令人讨厌的实现细节都隐藏起来了。

这正是那些低级API的支持者所愿意看到的：浏览器应该只提供基本功能，而基于这些功能开发易用API的任务应该交给开发人员社区。这些人支持低级API有一个主要的理由，即围绕基本功能可以实现任何层次的抽象，开发人员也会因此获得更多选择，从而更好地利用基本功能。

低级API的问题在于浪费时间。如果你创建了低级API，那结果就是潜在用户的数量会很少。至于什么时候能够出现好用的抽象工具，只能指望某一天这些用户中有（一个或几个）人会意识到确实有必要去做这件事，以便其他社区人员更好地利用该API。如果你想让新API尽快地被别人使用，你就会明白应该怎样去改进它，低级API根本不合适。

提示：大多数服务器端语言（如 ASP.NET、JSP、PHP）都提供了读写cookie的原生抽象，但JavaScript始终都没有。

高级API

这一争论的另一个极端是高级API。高级API设计出来就是为了让开发人员直接使用的，并且一般都非常直观。这种API不仅要考虑提供某种功能，而且还要提供使用相应功能的友好、易用的接口。高级API设计首先考虑的是开发人员的方便，因而通常需要对开发人员使用API的方式从理论上作出归纳。显然，这又是一个问题：谁能确切地知道某个人希望怎么去使用一个API呢？因此，在浏览器中提供原生的高级API几乎就是一个不可能完成的任务。

各式各样的JavaScript库就是高级API的典型例子。这些库都面向相同的浏览器，但为实现相同功能而提供的接口却差别很大。使用jQuery的方式与使用YUI截然不同；这是件好事，因为开发人员可以选择。可是，如果你告诉YUI开发人员必须使用jQuery语法写代码——因为只能使用一种语法；或者相反，会怎么样呢？相信对此提出抗议的开发人员一定会成群结队。强迫人们必须以某种方式开发是不幸之源。只有抽象，或者说只有随时都可以提高和降低抽象级别，才会让开发充满乐趣，也才能激励开发人员不断地创新。

高级API要求的知识储备非常低，因此开发人员无需了解太多就可以直接使用。但值得高兴的是，没有人认为浏览器应该提供高级AIP。大家都希望有所选择，都希望不同程度的抽象。

中级API

折衷方案是中级API。以我的观点来看，中级API是浏览器所应该研究和实现的。顾名思义，中级API处于低级和高级之间，兼具二者之长。所谓中级API，（我的定义）就是针对最常见的应用提供简单的接口，同时能够通过扩展实现更强大的操作和对不常见应用的支持。第一部分，常用的接口，是非常简单、无需抽象即可直接使用的。而不常用接口可以更复杂一些，甚至可以“让人摸不着头脑”，因为很少会有人用。

XMLHttpRequest是不错的中级API中最出色的例子。使用它最常见的情形就是发送一次GET请求，然后取得XML数据。实现这个过程的代码不多：

var xhr = new XMLHttpRequest();
xhr.open(“get”, “/somexml”, true);
xhr.onreadystatechange = function(){
if (xhr.readyState == 4){
if (xhr.status == 200){
process(xhr.responseXML.getElementsByTagName(“item”));
}
}
};
xhr.send(null);

虽然有人会说onreadystatechange这个事件处理程序看起来有点麻烦，但实际上，你要做的不过是检查一点信息，以确定是否接收到了正确的数据。可是，所有必需的信息都已经各就各位了，而且也已经转换成了方便访问的格式：HTTP状态就在那摆着，而XML也已经转换成了DOM格式。为了给你提供这些数据，API已经做了不少的工作了。

另一种不太常见的用法就是在URL中包含提交的表单数据。虽然代码难看点，但仍然可以接受：

var xhr = new XMLHttpRequest();
xhr.open(“post”, “/add”, true);
xhr.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);
xhr.onreadystatechange = function(){
if (xhr.readyState == 4){
if (xhr.status == 200){
signalComplete();
}
}
};
xhr.send(encodeURIComponent(name) + “=” + encodeURIComponent(value));

除此之外，你当然还可以把XMLHttpRequest对象用于更复杂的处理中，例如Comet。问题的关键在于，它在常用情形下很简单，而且还能轻易地支持更复杂、更不常见的用例。这样一来，JavaScript库也容易在后台构建一个比较好用的接口，帮我们处理那些复杂应用下的琐碎细节。尽管每个JavaScript库在如何发起Ajax通信方面各有各的方式，但XMLHttpRequest接口的设计能够很好地适应所有方式。

注意：有些人认为XMLHttpRequest也属于低级API。我承认它不是最清晰的API，但在常见用例中它确实非常简便易行。不要忘了，最初在设计这个对象的时候，常见用例就是从服务器上取得XML数据。从那个时候到现在，常见用例已经变了，但人们照样还在使用同一个API。在我看来，这恰恰表明了它是一个不可多得的中级API。

总结

我主张浏览器应该原生提供中级API，这样才能自如地应对常见用例，同时还可以为不常见的用例留下扩展的空间。API的抽象程度太低，不利于广泛流传，更不容易引起开发社区的重视；API的抽象程度太高，由于限制的用例太专，人们要么能用，要么根本就用不了。目前来看，较新的API似乎有低级化的倾向，如此一来，开发人员在实际使用它们之前，往往需要有第三方来实现一些必要的抽象。我希望能够阻止这种趋势，好让常见用例实现起来更简单，以便人们能够立即使用它们，同时还可以对它们加以扩展。而中级API能够同时满足这两个条件。

从诞生至今的大部分时间里，焦虑、抨击、蔑视和误解一直与JavaScript如影随形。JavaScript刚刚问世那几年，很多“严肃的程序员”都认为它不够严肃。

相比之下，.COM泡沫时期加入Web开发行列的许多文科生，则普遍觉得JavaScript深不可测、晦涩难懂。就算那些耐力和韧性俱佳者能够把JavaScript琢磨得很透，但仍然摆脱不掉竞争性浏览器提供的不同实现给他们带来的麻烦。凡此种种，最终导致粗制滥造的脚本越来越多。另一方面，拜Web前端代码的无比开放性所赐，各种坏习惯不断从一个站点被粘贴进另一个站点的源代码中。那些实现活该臭名昭著，可是，JavaScript这门语言也因此被严重拖累，背上了不该有的坏名声了。

2001年前后（随着Internet Explorer 6的发布），浏览器实现已经大为改进，Web开发实践也开始得到改善，呈现出了二者水乳交融的局面。作为Ajax核心的XMLHttpRequest对象正慢慢地为人们所发现，一种新的桌面风格的用户交互模式出现在浏览器中。允许JavaScript操作Web文档结构和内容的DOM API已经定型。而CSS，不管人们如何曲解或者无视它，也无论浏览器开发商怎样丧心病狂地实现它，都已经成长得足够茁壮，它的美妙和反应敏捷令它能够与新的Web交互能力配合无间。最终，JavaScript一扫颓势，变得令人惊诧、让人兴奋、使人敬畏。想想2004年第一次使用Google Maps时的情景吧，那种感觉你或许还记忆犹新。

Google Maps是新兴应用程序的典型代表。这类浏览器编程与后端编程并重的应用程序，不禁令人对Web浏览器窗口中那块“画布”的未来浮想联翩。（除Google Maps之外，早在2003年就基于网页邮件客户端提供类似Outlook功能的Oddpost，也是这类应用程序的一个了不起的先驱。）随着这类应用程序如雨后春笋般大量涌现，以及支持它们的浏览器的市场份额不断攀升，一个Web应用全面复兴的时代真的到来了。“Web 2.0”诞生了，Ajax也成了“IT”技术。Web似乎在一夜之间脱胎换骨，重新激发起了人们的兴趣。而JavaScript作为唯一的Web编程语言，也变得更有意思了。

有意思，但用好它却不简单。JavaScript以及在DOM和BOM中为其定义的API不一致的实现，给跨浏览器编程造成了比原本大得多的困难。前端设计行业还远未成熟。大学教学计划并没有（至今仍没有）做出相应的调整，以满足相关的培训要求。

到2004年底，JavaScript无疑已经成为最重要的编程语言。但从学术角度看，它依然不具备进入一类学科的资格。Web虽然已经翻开了新的一页，但在培养足够的知识全面、训练有素的人才方面，我们依然面临着严峻的挑战。

为此，很多技术作者挺身而出，撰写了不少有关JavaScript的图书。几年来，这类书虽然也出了不下几十本，但总体来说仍然不尽如人意。其中有的在推销与落伍的浏览器有关的技术，有的则在卖弄容易剪贴但却不好扩展和维护的技术。让人想不通的是，许多JavaScript图书让人觉得作者好象并不真正喜欢JavaScript，或者他们不认为读者应该喜欢它，再或者他们根本不相信读者能够完全理解JavaScript。

2005年，Nicholas C. Zakas这本书的第一版面世，为前端工程领域奉献了一本真正的好书。当时，我和雅虎的同事们正在创建YUI（Yahoo! User Interface Library，Yahoo!用户界面库），打算将其作为公司前端工程的基础，同时也借以推广我们这门新学问的最佳实践。每到周五，我们就聚到一间教室里讨论前端工程，也向大家讲解JavaScript、CSS以及在浏览器中创建Web应用程序的知识。我们从已出版的高级JavaScript及DOM脚本编程方面的图书中认真挑选了几本，想让新工程师通过它们掌握如何构建耐用、基于标准且容易维护的Web应用程序。Zakas的书一出版，马上就被选为我们的JavaScript内部培训课本。

从那时起我们就一直使用他的书。我们一致认为这本书太有用了，于是就跟Zakas商量，让他加入雅虎帮我们建立公司的前端工程社区。

Zakas在书中传达的理念与众不同——JavaScript既需要严肃认真地对待，但也是完全可以理解和掌握的。如果你是个程序员，这本书会告诉你JavaScript与各种编程语言的关系，以及如何运用你已经习以为常的各种编程模式。你可以理解JavaScript的继承机制及其固有的动态特性（虽不合传统，但却十分自由十分强大），可以从Zakas这位尊重和理解JavaScript的同道那里学会欣赏JavaScript这门语言。

如果你曾经是一名文科生，在网络泡沫时期步入了这个行业，至今也没有转行，而且想要弥补自己在JavaScript方面的不足，你会发现Zakas是一位难得的良师益友。他可以帮你实现从“会做”到“做好”的转变。他能让你认真地理解这门严肃的学问。最重要的是，他不会让你先入为主地产生对这门语言应该理解多深的想法。相反，通过他严肃、耐心、通俗易懂的讲解，你自然而然地会对这门语言有同样深刻的认识。

本书是经过扩展、更新和改进后的第二版，删除了上一版中与今天的职业需求无关的主题，并用我们在2005年至2008年学习的新知识更新了剩余的内容。这几年是JavaScript发展的重要时期，Zakas则始终位于最前沿孜孜不倦地学习这些新知识。他这些年一直在致力于建造新一代最流行的Web个人门户（My Yahoo!），以及开发Web上最受欢迎的站点（Yahoo!主页）的新版本。Zakas以他作为老师和作者的独特视角，筛选出由这些超复杂、超大型应用程序磨砺出的经验，并将这些经验融入到了本书的字里行间。

他给出的解决方案远远超出了一本好书的范畴，只有每天都与代码同呼吸共命运的人，才有可能与读者分享如此具有实用价值的知识。

说实话，本书新版的面世对我和各位读者而言真是个莫大的喜讯。因为它的内容比上一版更有价值、更能反映JavaScript最新的发展成果，因此也更加令人不可错过。

埃里克·米拉利亚（Eric Miraglia）
YUI高级技术经理 哲学博士
于加利福尼亚州森尼维耳市

昨天，我负责了Yahoo!公司组织的一次面试活动，感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo！工作充满激情的问题。在昨天的应聘者中，只有一个人的问题是我认为最好的，那个人问我：“你觉得怎么才能成为优秀的前端工程师？”我觉得很有必要把这个问题从面试房间里拿出来讨论一下。

首先，前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行，你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通，但你至少要能够运用它们完成大多数任务，而无需地频繁地寻求别人的帮助。

优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的，没错吧？我甚至可以说这些技术几乎每天都在变化，如果没有快速学习能力，你就跟不上Web发展的步伐。你必须不断提升自己，不断学习新技术、新模式；仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别，而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。

计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是，我们所说的前端不是什么科学，而是艺术。艺术家不仅要掌握谋生的技术，还要懂得如何运用。对同一个问题的解决方案在这种情况适用，在另一种情况下可能就不适用。对Web应用程序的前端而言，解决同一问题的方案经常会有很多。没有哪个方案是错的，但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适，而在什么情况下应该重新选择。

优秀的前端工程师需要具备良好的沟通能力，因为你的工作与很多人的工作息息相关。在任何情况下，前端工程师至少都要满足下列四类客户的需求。

1. 产品经理——这些是负责策划应用程序的一群人。他们能够想象出怎样通过应用程序来满足用户需求，以及怎样通过他们设计的模式赚到钱（但愿如此）。一般来说，这些人追求的是丰富的功能。
2. UI设计师——这些人负责应用程序的视觉设计和交互模拟。他们关心的是用户对什么敏感、交互的一贯性以及整体的好用性。他们热衷于流畅靓丽但并不容易实现的用户界面。
3. 项目经理——这些人负责实际地运行和维护应用程序。项目管理的主要关注点，无外乎正常运行时间（uptime）——应用程序始终正常可用的时间、性能和截止日期。项目经理追求的目标往往是尽量保持事情的简单化，以及不在升级更新时引入新问题。
4. 最终用户——当然是应用程序的主要消费者。尽管我们不会经常与最终用户打交道，但他们的反馈意见至关重要；没人想用的应用程序毫无价值。最终用户要求最多的就是对个人有用的功能，以及竞争性产品所具备的功能。

那么，前端工程师应该最关注哪些人的意见呢？答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期，然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上，因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能，必须删繁就简，你怎么跟产品经理解释？再比如，假设某个设计如果不改回原方案可能会给应用程序造成负面影响，你怎么才能说服UI设计师？作为前端工程师，你必须了解每一类人的想法从何而来，必须能拿出所有各方都能接受的解决方案。从某种意义上说，优秀的前端工程师就像是一位大使，需要时刻抱着外交官的心态来应对每一天的工作。

我告诫新来的前端工程师最多的一句话，就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住，一定先搞清楚别人到底想让你干什么，不能简单地接受“这个功能有问题”之类的大概其的说法。而且，你还要确切地知道这个功能或设计的真正意图何在。“加一个按钮”之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理，问一问这个按钮有什么用处，然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师，这种沟通至关重要。

无论从哪个方面讲，我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了，为了在多种平台中使用，多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术，涉及到广阔而复杂的领域，这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门，但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力，才会真正让你变得优秀。

延伸阅读

• Nicholas C. Zakas如何面试前端工程师
• 如何通过Nicholas C. Zakas的面试

Nicholas C. Zakas的书

早就打算写这篇文章了，但时至今日才决定动笔。如果你投了简历，那么应该会在面试你的人名单里找到我的名字。你现在就有点紧张了，（好啦，别不好意思）面试总会让人感觉有点不舒服。作为面试官，我其实并不算难对付，但如果你想在我们谈话之后让我放你过关，你确实得做一些必要的准备。

• 回答问题。我问你一个问题，你必须要回答它。我遇到应聘者在回答我问题时顾左右而言他的情况太多了。我知道你会有些紧张，说几句不着边际的话可能有助于缓解，但请你不要喋喋不休，要赶快回到正题上来。我不想知道你的宠物猫最近又出了什么新状况，我只想听到你的回答。假如你没有听明白我问的是什么，可以要求我再解释一下，重复几遍问题或者换一种问法，对我而言没有什么。

• 告诉我你不知道什么。如果我问到了你不知道的问题，一定要告诉我。我不认为你的大脑里可以装得下百科全书。在知道了你不知道什么以后，我对你的评估才会更加公平。问题仍然要回答，但我会给你一些提示，同时也可以考察一下你解决问题的能力。

• 不要放弃。在我面试你的过程中，不要总想着放弃。如果你被我前面的话不幸言中，那么你可能会面对一个让你不知所措的问题，而且你也告诉我你答不上来了。此时此刻，千万不要打退堂鼓！我会尽力提醒你，让你找到正确答案；因此不要随随便便打断我说：“我真的不知道。”在我们这个行业，你经常会遇到没有现成解决方案的挑战，到时候你会轻易放弃吗？我必须知道你具备解决问题的能力，而不是遇到一点挫折就轻言放弃。

• 不用担心怪问题。有些公司的确有吓唬应聘者的传统，他们会让你回答一些类似脑筋急转弯似的稀奇古怪的问题。对那种面试方式，我不敢苟同。我提的所有问题都有答案，而且绝大多数还不止有一个正确答案；我保证一个怪问题也不会问你。因为这样既会让你难堪，又对我毫无意义。你大可放心，我的每个问题都至少会有一个正确答案。

• 自圆其说。如果你提到了某个解决方案或者强调自己掌握了某方面知识，请做好进一步讨论它的准备。假设我问了一个问题，你在回答这个问题时提到：“对，因为IE不支持CSS3……”然后，你最好能够跟我讨论一下要是IE支持CSS3你会怎么办。

• 不要说自己是专家。大多数面试中可能都需要注意这一条，但我对这一条尤其敏感。我从来不会把应聘者划分为三六九等，因此你也不必告诉我你属于哪个等级。一旦你声明自己已经跻身“专家”的行列，我怕有些问题会让你下不来台。我确实见过自称专家而又确实是专家的人。但是，我认为真正的专家不会自己说出来，而是会做给你看。

• 不要靠卖弄赚取我的好印象。如果我想知道什么，我会问。我知道在面试时需要了解哪些信息，只要一听到有人说“想不想看一个绝妙的技巧？”或者其他类似的话，我都有一种立即中断面试的冲动。所以，请尽力回答好我的问题即可。

• 充满激情。如果你想得到跟我一起工作的机会，请给我一个愿意跟你共事的理由。最好的理由就是要有激情，把你主动、积极学习的热情展示出来。希望你能谈一谈产品、公司，以及为什么想得到这份工作。尤其要注意最后一点，我不想听你说你当前的工作如何如何讨厌。当然，可以解释一下为什么现在或者过去没有从事你喜欢的工作，但你一定要告诉我你对自己今后的成长有何打算，还有为什么你应聘的这个职位能够有助于你的成长。

没错，我确实希望将来有可能被我面试的所有人都看到这篇文章。我希望你能在我面试你时表现得非常好，真的，确实如此。说来也简单，只要你留意上述这些常见的问题，并且原原本本地展示你自己就足够了。说不定哪一天，你就会跟我坐到同一间办公室里了。

注意，My Yahoo!团队正在招聘呢。如果你是一位有才华的软件工程师，又对创造价值和Yahoo!公司充满激情，请跟我联系，咱们谈谈。

延伸阅读

• Nicholas C. Zakas如何面试前端工程师
• Nicholas C. Zakas谈怎样才能成为优秀的前端工程师

Nicholas C. Zakas的书

面试前端工程师对我来说是一件非常有意思的事，因为面试过程很大程度上也是自我提升的过程。无论大公司还是小公司，之所以在如何招聘到真正有能力的前端工程师方面会遇到同样的问题，就是因为负责招聘的那些人不知道自己公司需要什么样的人，结果问问题时也问不到点子上。经过这几年在行业里的摸索，我总结出了自己的一套很有效的面试前端工程的方法。

有的应聘者说我不好对付，但留给他们这样的印象也并非我所愿。我觉得之所以他们说我不好对付，主要是因为我问他们问题时问得太细了。以前我曾专门写过一些东西，告诉应聘者怎么才能通过我的面试以及怎样才能成为优秀的前端工程师应该具备什么样的素质，而我的面试可以说完全是按照那两篇文章的标准进行的。我不会问一些特别偏门的问题，也不认为出几道逻辑题就能考出人的真实水平。我唯一的想法就是确定你能否胜任我们要招的这个职位。为此，我需要简单地考察如下几个方面。

基本知识

我们生活在互联网时代，你想知道的任何事情几乎都能在15分钟内找到相关信息。可是，能找到信息并不等于你会使用它。我认为所有前端工程师至少都应该掌握某些基本的知识，才能有效地完成自己的工作。如果一遇到问题，就停下工作上网四处搜索解决方案，怎么可能保证按期完成工作呢？听听，还有谁在说“我不知道，但我可以上网搜到。”请这些同学把手举起来，让大家认识一下（immediately raises a flag for me.）。下面我列出一些基本的知识点，这些都是我认为一名前端工程师（无论工作年头长短）在没有任何外来帮助的情况下就应该知道的。

• DOM结构——两个节点之间可能存在哪些关系以及如何在节点之间任意移动。
• DOM操作——怎样添加、移除、移动、复制、创建和查找节点。
• 事件——怎样使用事件以及IE和DOM事件模型之间存在哪些主要差别。
• XMLHttpRequest——这是什么、怎样完整地执行一次GET请求、怎样检测错误。
• 严格模式与混杂模式——如何触发这两种模式，区分它们有何意义。
• 盒模型——外边距、内边距和边框之间的关系，IE < 8中的盒模型有什么不同。
• 块级元素与行内元素——怎么用CSS控制它们、它们怎样影响周围的元素以及你觉得应该如何定义它们的样式。
• 浮动元素——怎么使用它们、它们有什么问题以及怎么解决这些问题。
• HTML与XHTML——二者有什么区别，你觉得应该使用哪一个并说出理由。
• JSON——它是什么、为什么应该使用它、到底该怎么使用它，说出实现细节来。

重申一下，上述这些知识点都应该是你“想都不用想”就知道的东西。我一开始问的所有问题都是想摸清你对所有这些领域知识的掌握程度。虽然上面列出的这些知识点并没有面面俱到，但我觉得你至少应该掌握这些，才有可能跟我坐到一间办公室里来。

少量提问

我非常赞同面试者问的问题越少越好。反复问应聘者各种问题既不公平，也很无聊。我在任何一次面试中，通常只问三个大问题，但每个问题又会涉及我所能想到的多个方面。回答每个大问题一般要经过几个步骤，这样我就可以在每个步骤中穿插着问一些小问题。比如说：

这个问题牵扯到一组我想要考察的基本知识点：DOM结构、DOM操作、事件处理、XHR和JSON。如果我要求你换一种处理股票价格的方式，或者让你在页面中显示其他信息，就可以把更多的知识点包括进来。对于经验比较丰富的应聘者，我也可以自如地扩展要考察的知识范围，最简单像JOSN与XML的区别、安全问题、容量问题，等等。

我还希望应聘者给出的任何解决方案中都不要使用库。我想看到最原生态的代码，你就当页面中没有包含任何库。你说你对哪个库了解多少多少，但我不能把关于库的知识作为评判能力的因素，因为库是会随时间变化的。我需要的是真正理解库背后的机制，特别是能够徒手写出一个自己的库的人。

解决问题

做为一名前端工程师，最值得高兴的事莫过于解决同一个问题会有很多种不同的方法，而你要做的就是找出最合适的方法来。我在提问的时候，经常会在应聘者解释完一种方法后问他们还有没有第二种方法。此时我会跟他们说，假设你的这个方法由于种种原因被否决了，那么你还能不能给出另一种方法。这样做可以达到两个目的。

首先，可以测试出他们是否在毫无意义地复述书本中的东西。不能不承认，某些人确实有过目不忘的天赋，听他们在那里滔滔不绝地讲，你会觉得他们什么都明白。可是，只要一跟这些人谈到怎么查找方案无效的原因，以及能否拿出一个新方案来，他们往往就傻眼了。这时候，如果我听到“我不明白这个方案为什么不够好”之类的反问，心里立刻就明白我的问题已经超出了他们的能力范围，而他们只是想拿自己死记硬背的结论来蒙混过关。

其次，可以测试出他们已经掌握的（还是那句话，“想都不用想”就知道的）浏览器技术知识。如果他们对浏览器平台的核心知识有较好的理解，想出解决同一问题的不同方案根本没有那么难。

对一名前端工程师来说，这绝对是最重要的能力。前端工程师在工作中遇到本该如此却并未如此的难题（说你啦，IE6），应该说是一件很平常的事。一个方案无效就无计可施的人，做不了前端工程师。

考核应聘者解决问题能力的另一层原因，与我的个人喜好有关。在搞清楚应聘者知道什么不知道什么之后，我就会想着问一个他们知识领域之外的问题。这样做的目的，就是想看看他们怎样运用已有的知识解决新问题。在解决问题的每一步，我也准备了一些提示，以防有人会卡壳打艮（在我面前15分钟一言不发，对我评价这个人毫无帮助）。我真正感兴趣的，是他们能够从上一步前进到下一步。我希望看到一个人就在我眼前学到新知识。

注意：所有问题都与浏览器技术相关。我不相信出几道抽象的逻辑题，就能够考出某人解决Web技术问题的能力。在我看来，这无异于让素描大师画肖像（或者让刘翔跟博尔特同场竞技），没有意义，也得不到任何有价值的信息。

有激情

要成为一名优秀的前端工程师，最重要的莫过于对自己做的事要有激情。我们的技能都不是从学校中或者研讨会上学来的，因此前端工程师必须具备自学能力。浏览器技术的变化可谓日新月异，所以也只有不断提升自己的技能才做得到与时俱进。我虽然不能强迫谁必须多看博客、不断学习，但想应聘前端工程师的人恐怕还是必须得这么做。

你怎么知道谁对这种工作有没有激情？实际上非常简单。我只问一个简单的问题：“目前你对什么Web技术最感兴趣？”这个问题永远不会过期，而且也几乎不可能出错……除非你答不上来。就眼下来说，我希望你对这个问题给出的技术中包括WebSocket、HTML、WebGL、客户端数据库，等等。只有对Web开发充满激情的人，才会坚持不懈地学习新知识、掌握新技能；这些人才是我真正想要的。当然，我会让他们详细解释自己提到的技术，以保证他们不是随口念叨了几个时髦的新词汇。

最后一点

计算机科学或者Web设计方面的知识当然也有用，但那都是基本知识之外的东西。只要基本知识在那儿了，一切就都有了基础，想扩充知识面也不难。可是，如果等到正式上班以后，还得从头学习基本技能，那种难度是不可同日而语的。另外，高级前端工程师与一般工程师相比，肯定需要掌握更多的技能。而面试几乎没有经验的大学毕业生，我也会有一套完全不同的程序。我在这篇文章里列出来的都是一些最基本的东西。

对于那些还没有多少面试经验的人，我总是喜欢告诉他们，面试完了只要问自己一个问题就行：你想以后跟这个人在一起共事吗？如果不管为什么，回答是不，那就是不。

延伸阅读

• 如何通过Nicholas C. Zakas的面试
• Nicholas C. Zakas谈怎样才能成为优秀的前端工程师

Nicholas C. Zakas的书

请看
命名函数表达式探秘

原文链接：http://yura.thinkweb2.com/named-function-expressions/
本文链接：http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html

Table of Contents

1. 前言
2. 函数表达式与函数声明
3. 函数语句
4. 命名函数表达式
5. 调试器中的函数名
6. JScript的bug
7. JScript的内存管理
8. 测试
9. Safari中存在的bug
10. SpiderMonkey的怪癖
11. 解决方案
12. 替代方案
13. WebKit的displayName
14. 对未来的思考
15. 致谢

仿真器，指的是几乎能够百分之百地模拟某硬件或软件系统的全部特性、行为的装置或程序。
模拟器，指的是仿照真实的硬件、软件、环境、条件，能够在某种程度上再现这些硬件、软件、环境、条件的装置或程序。

仿真是尽可能做到全方位的模拟，而且力求逼真，有点欲将原型或模仿对象取而代之的味道。仿真更具体，接近实物（也有说接近硬件的，但肯定不局限于硬件）。
模拟只是表面上做做样子，不会有真实的过程发生；但能够给出反馈，多用于研究和培训。模拟更抽象，侧重建模。

当然，也会存在模拟器与原型的近似程度堪与仿真器媲美的情况，但它们的区别还是十分明显的，那就是模拟不够“真实”，而仿真非常接近“真实”。

在参考文献中“记性不好，所以写写”的原话基础上稍作修改，可以说：

参考文献

1.海之雁 《仿真专业词义辨析之一——模拟与仿真》
2.记性不好，所以写写《Simulation & Emulation》
3. 丁刚 《详述软件开发中模拟器与仿真器的区别》

词典及维基

《韦伯斯特在线词典》
Emulate
Verb
1. Strive to equal or match, especially by imitating; “He is emulating the skating skills of his older sister”.
2. Imitate the function of (another system), as by modifying the hardware or the software; in computer science.
3. Compete with successfully; approach or reach equality with; “This artists’s drawings cannot emulate his water colors”.

在计算机领域的特殊含义如下：
To imitate one system with another, primarily by hardware, so that the imitating system accepts the same data, executes the same computer programs, and achieves the same results as the imitated system

Simulator
Noun
1. A machine that simulates an environment for the purpose of training or research.
在计算机领域的特殊含义如下：
A device, data processing system, or computer program for representing features of the behavior of a physical or abstract system.

维基百科（英）
emulator
An emulator in computer sciences duplicates (provides an emulation of) the functions of one system using a different system, so that the second system behaves like (and appears to be) the first system. This focus on exact reproduction of external behavior is in contrast to some other forms of computer simulation, which can concern an abstract model of the system being simulated.

Computer simulator
In computer science, a simulator is a software program to model a real-life situation on a computer so that it can be studied to see how the system behaves. By changing variables, performance predictions may be made about the behaviour of the system. A computer simulator can be either an Instruction Set Simulator or a full system simulator

《牛津高阶（第6版）》
p.558
emulate 2(computing 计)（of a computer program, etc. 计算机程序等）to work in the same way as another computer, etc. and perform the same tasks 仿真；模仿 > emulation n.
emulator(computing 计) a device or piece of SOFTWARE that makes it possible to use programs, etc. on one type of computer even though they have been designed for a different type 仿真器；仿真程序

p.1631
simulate 2 to create particular conditions that exist in real life using computers, models, etc., usually for study or training purpose（用计算机或模型等）模拟
simulation 1 a situation in which a particular set of conditions is created artificially in order to study or experience sth that could exist in reality 模拟；仿真
simulator a piece of equipment that artificially creates a particular set of conditions in order to train sb to deal with a situation that they may experience in reality 模拟装置

看来（根据一位专家的说法是这样，不过还是感觉有点言不由衷），JavaScript最后真的流行起来了。

[此处是youtub.com中一段视频，可惜被"墙"了]

对我这个从小就呆头呆脑的人来说，这段视频像是咒语又像是玩笑。（这要看你是否跟我站在了相同的立场上：绿壳鸡蛋不就流行过吗？）

我搞不清楚为什么道格（Doug）要编故事。他并不在网景公司。他亲耳听到过我回忆JavaScript诞生的经过，我在Ajax大会的发言中也讲过了。难道是想混淆视听，想在Web开发人员中掀起一股提前讨论MicroHoo C#语言的风潮？

谁知道呢，要计较这些就没完了。不过，鉴于本周是我参与创立的mozilla.org 10周年，我打算讲一点历史。

正如我多次重申过的，而且Netscape的其他人也可以证明，我是因为Netscape要在浏览器中“实现Scheme”才被招聘进公司的。当时，至少负责客户端技术的汤姆·帕坎（Tom Paguin）、迈克尔·托伊（Michael Toy）和瑞克·谢尔（Rick Schell），以及一个叫马克·安德森（Marc Andreessen）的家伙认为Netscape应该在HTML中嵌入一种语言，一种源程序式的编程语言。而我这个新人要去说服“尖脑壳”的老板几乎是不可能的——实际上更多的则是他们在向我解释问题。

到底是不是要基于Scheme并没有定论，但Scheme确实是吸引我加入Netscape的一个原因。在此之前，我在SGI公司期间，尼克·汤普森（Nick Thompson）引导我学习了SICP（Structure and Interpretation of Computer Programs，《计算机程序的构造和解释》）。

当时真正需要的是一种有说服力的概念验证，也就是一个演示程序。在我交付演示程序之后，这个程序在极短的时间内就变为了既成事实。

没错，在加入Netscape后不久，我被调出服务器团队——由于人员不足，我在这个团队干了一段时间，在那里与麦库尔·吐温斯（McCool Twins）和阿瑞·卢奥托嫩（Ari Luotonen）有了一段时间不长但很快乐的合作；1995年下半年，阿瑞和我创建了PAC（Proxy Auto Config，代理自动配置）——的时候，Oak语言已经改名为Java，而Netscape正与Sun协商将该语言包含在Navigator中。

Netscape公司内部争论的最大焦点变成了：“为什么要包含两种语言？为什么不只用Java？”得到的回答是：必须有两种语言分别面向编程圣殿中的两类最不可能走到一块的开发人员：组件开发人员——这类人使用C++或（我们希望的）Java和脚本开发人员（爱好者或专业人员）——这类人编写直接嵌入在HTML中的代码。

至于是否使用已有的语言，而不发明一门新语言，也不是我说了算的。上峰的“军令”就是这门语言必须“看起来像Java”。这样，不仅排除了Perl、Python和Tcl，也排除了Scheme。后来，1996年，约翰·奥斯特豪特（John Ousterhout）前来推广TK时，还曾因Tcl错过机会而惋惜过。

谈不上自鸣得意，但我确实为自己吸收了Scheme式的一类函数和Self式的原型（尽管不那么主流）而感到高兴。至于Java的影响，特别是Date的Y2K bug和原始类型与对象类型（如string与String）差异的影响则是非常不幸的。

时光倒转回1995年春天：我记得在此期间见到了比尔·乔伊（Bill Joy），我和他讨论了垃圾收集的细节（card marking for efficient write barriers）。比尔一上来就完全理解了我们所说的一门易用的“脚本语言”与Java的关系，他还拿微软平台的VB与C++之间的关系作类比。据我所知，比尔是我们在Sun公司的支持者。

基普·希克曼（Kipp Hickman）和我在1995年4到5月间研究了Java，基普也开始写他自己的JVM。他和我编写了NSPR的第一个版本，作为他的JVM之下的可移植层。而我在5月中上旬创建Mocha的原型时，也将该版本用作了相同的目的。

比尔说服我们放弃基普的JVM，因为它会导致与Sun的JVM中的bug无法兼容（在那个时候可谓智慧的预言）。而此时此刻，Mocha已经通过在Netscapte Navigator 2.0（的初期测试版）中的快速原型和嵌入证明它自己。

除此之外，应该说都是对历史的歪曲和调侃。JS在客户端打败了Java，只有Flash能与其竞争，而Flash又支持JS的一个衍生品——ActionScript。

现在再回到流行的问题上。其实谈不谈这个问题都无所谓。然而，那些散布于互联网的流行的Ajax库，却经常以被掰碎了、压扁了，然后再以链接形式挑出来的纯文本的形式存在。难道不可以共享吗？

有一种想法——受到了不少人的质疑，最近一次发出质疑声音的人是道格——在可能将会非常长寿的script标签属性中嵌入“神秘的散列码”（crypto-hashes）。这是个好主意吗？

恐怕不是。一方面因为“神秘的散列码”理论上的完备性问题，另一方面则因为其广为人知的药饵攻击（poisoning attacks）。

还有一个主意倒是不错，这个主意我是先从罗布·塞尔（Rob Sayre）那里听说的：通过HTML5中script标签的share属性支持一种可选的“公认的URL”：
<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js”
shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”>
</script>

如果浏览器首先下载了共享的URL，而且根据HTTP的缓存规则它依然有效，那么就可以使用缓存（及预编译）的脚本，而不必从src属性指定的URL中下载。

这就避免了散列药饵的问题。这个方案只要求内容作者保证src属性指向的文件与share属性指定的这个库的公认（或流行）的版本相同即可。不过当然，我们必须信得过相应的DNS。（Ulp.）

这个方案可以避免在script标签属性值中嵌入不可预测的散列码。

欢迎大家就此问题给我留言。

好了，这次真的回到JavaScript流行的问题上了。我们都知道有些Ajax库的确流行。那JavaScript流行吗？很难说。有些Ajax开发人员表示（也证明）了对它的喜爱。但也有很多人骂它，也骂我。我依然认为JavaScript是C和Self草草结合的结果（或一个私生子）。我又想起了约翰逊博士（http://en.wikipedia.org/wiki/Dr._Samuel_Johnson）的那句话：“好的不是原创的，而原创的都不好。”

不过，这没什么。Web总要发展，否则只有死路一条。JS也一样，要不就不会有ES4了。说到ES4，很快将有下文。

Firefox 3好像也会流行的， 它的空间与时间性能测试预示了这一点。相关内容呢，我以后还会陆续地谈到。

觉道庄村北门

青云观位于河北青县城东觉道庄村，距天津市七十五公里，观内有15座殿堂，供奉十尊神像，总占地面积一方平万米，是华北平原上历史最悠久的道观。相传春秋战国时期，老子李耳弃周守藏室史官而走，云游四方至此地隐居，德高望重的老子传经布道，救苦救难，民众相聚而居，逐渐形成村落，起名为道德庄。沧桑变迁，元初．老子分神化气，重降此庄，名为张核，道号觉道，村更名为觉道庄，觉道大师积功德，四处化缘，在原老者君讲经道场营造起一座颇有影响的道观青云观，从此,觉道庄就成了道教圣地，村周围先后建起了碧霞庵、五龙圣母庙等道观，历史上曾在此涌现出颇有道诣的道师和法师。