原文链接:http://www.boxesandarrows.com/view/content-strategy-the

作者: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 复杂一些的站点就需要组织了

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

实战演练

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

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

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

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

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

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

内容策略专家的策略

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

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

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

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

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

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

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

出处:RegExLib.com Regular Expression Cheat Sheet (.NET)

元字符 说明
^ 匹配字符串的开始位置
$ 匹配字符串的结束位置
. 匹配任意单个字符(换行符 \n 除外)
| 交替
{…} 指定要限定的数量
[...] 指定要匹配的字符集
(…) 对表达式进行逻辑分组
* 匹配零或多个前面的表达式
+ 匹配一或多个前面的表达式
? 匹配零或一个前面的表达式
\ 放在上面任何一个字符之前,表示匹配该字符本身。放在其他特殊字符后面,表示字符转义(见下面)
字符转义 说明
原始字符 除 . $ ^ { [ ( | ) ] } * + ? \ 之外的字符均匹配自身
\a 匹配铃声(闹铃)\u0007
\b 在[]中匹配一个空格 \u0008,在其他情况下匹配字边界(位于 \w 和 \W 字符之间)
\t 匹配制表符 \u0009
\r 匹制回车符 \u000D
\v 匹配垂直制表符 \u000B
\f 匹配换页符 \u000C
\n 匹配换行符 \u000A
\e 匹配退出键(符) \u001B
\040 匹配以八进制表示的 ASCII 字符(最多三位数);在没有前导零的情况下,如果只有一位数字或者相应数字与某个捕获组的编号对应,那就是反向引用(backreference)。字符 \040 表示一个空格。
\x20 匹配以十六进制表示的 ASCII 字符(两位数)
\cC 匹配 ASCII 控制符,例如 \cC 匹配 Ctrl+C
\u0020 匹配以十六进制表示的 Unicode 字符
\* 反斜杠后面如果不是一个可转义的字符,则匹配该字符本身。例如,\* 就相当于\x2A
字符类 说明
. 匹配除 \n 之外的任意字符。
[aeiou] 匹配特定字符集中包含的任意一个字符
[^aeiou] 匹配特定字符集中不包含的任意一个字符
[0-9a-fA-F] 连字符(-)用来指定连续的字符范围
\p{name} 匹配由{name}指定的命名字符类中的任意字符
\P{name} 匹配不包含在{name}指定的组或块范围中的文本
\w 匹配英文数字字母字符,在指定兼容ECMAScript的情况下,等价于[a-zA-Z0-9]
\W 匹配非英文数字字母字符,在指定兼容ECMAScript的情况下,等价于[^a-zA-Z0-9]
\s 匹配任意空白字符,在指定兼容ECMAScript的情况下,等价于[\f\n\r\t\v]
\S 匹配任意非空白字符,在指定兼容ECMAScript的情况下,等价于[^\f\n\r\t\v]
\d 匹配数字字符,在指定兼容ECMAScript的情况下,等价于[0-9]
\D 匹配非数字字符,在指定兼容ECMAScript的情况下,等价于[^0-9]

《JavaScript高级程序设计(第2版)》上市将近一个月了。这期间,为了制作勘误,我在重读这本书。与此同时,几位热心读者也将发现的一些错误迅速通过邮件发给了我,或者在出版社(图灵公司,http://www.turingbook.com)网站本书页面中提交了勘误。经过确认,目前有11处需要修改的地方(详见后面列出的查看勘误的页面)。

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

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

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

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

提交勘误,请到如下页面:

查看勘误,请到如下页面:

本想先找本算法和数据结构的书参考一下,但转念一想:不如考考自己的总结和逻辑表达能力。

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年精华文章汇总

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

《JavaScript高级程序设计(第2版)》

锡林郭勒草原

2010年06月19日 原创

草原

天光

起伏

奶牛

风车

路漫漫……

罗伯特·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月