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属性，例如：

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

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

之所以把这种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数据。实现这个过程的代码不多：

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

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

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

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

总结

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

昨天，我负责了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的书

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

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

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

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

参考文献

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

昨天，儿子下载了一款名叫“主题医院”的游戏，在安装了该游戏之后，电脑中的Chrome和IE就被1188.com劫持了：

1、桌面上多出来两个IE快捷方式图标，无法删除；

2、快速启动区IE和Chrome快捷方式的目标被篡改，追加了http://www.1188.com/?8后缀（见下图），无法修改；

3、注册表中多了一些带有1188.com的键值。

经过搜索并试验广大受害网友克敌方法，我总结出了比较简单易行的“反劫持”作战方案：

1、“开始>运行”，输入regedit，打开注册表编辑器，Ctrl+F，搜索“1188.com”，对搜索到的键一律格杀勿论——全都删掉；

2、由于无法修改快速启动区被篡改的IE和Chrome快捷方式，因此需要把它们先拖到桌面上，然后删除；

3、桌面上多出来的IE快捷方式也不能删除，但可以通过Windows自带的“桌面清理”工具将它们删掉，具体步骤如下：

在桌面上右键单击，然后“属性>桌面>自定义桌面>现在清理桌面”，在打开的“清理桌面向导”中点“下一步”，然后在“快捷方式”区域选中桌面上多出来的那两个IE快捷方式，然后“下一步>完成”（见下图）。

4、由于删除了快速启动区的浏览器快捷方式，所以需要自己找到浏览器的安装目录，重新创建——这个不用说都会吧。

事实上，如果这个1188.com只是劫持浏览器，建俩快捷方式，那除了恶心恶心人，让自己臭名远扬以外，也没有什么大不了的，顶多用上述方法“反劫持”罢了。但令人担心的是，如果除此之外，1188.com还会做一些不为人知的事，比如给电脑植入木马病毒，盗窃账号密码等信息，那么用户就会面临着巨大的危险——在网上也看到有人说这个网站不能访问，更能不从中下载任何东西。

《中国原创漫画产业化创作流程》

总体流程

1. 剧本创作
2. 美术设计：进行造型设计和制作。通过场景、道具、角色等的设计，来创建富有感染力的画面造型和动画形象，是动画创意的重要组成部分。
3. 模型塑造：(1)三维建模——使用特定软件制作数学的、线框表示的三维物体的过程。根据美术设计原画手工建立几何体数据模型，其过程类似于造型艺术中的雕塑；(2)场景建模——是指对环境、道具等模型的塑造，当前潮流是追求场景的高度仿真；(3)骨骼蒙皮——在三维动画中添加骨骼和蒙皮，使模型可以按照设计要求进行运动。运用运动生物力学对人或动物模型的骨骼进行控制，可以为人或动物模型产生各种符合物理特性、真实可信的动作效果；(4)肌肉系统——应用生物运动仿生力学，在三维角色模型上建造运行协调机构，实现三维模型肌肉质感的协调联动。
4. 镜头设计：是将文学剧本转化为二维或三维图像表现的分镜头脚本，用以说明叙事顺序和镜头运用。
5. 动画创作：(1)表情口形——通过对角色面部表情和口形动画的调制，刻画角色的内心感情以及与对白相吻合的口形变化。最新的表情捕捉技术和口形自动生成系统，进一步提高了表情、口形动画调制的效果和准确性；(2)动作表演——动作表演是对于角色动作的关键帧进行调制，使其产生连续性的动作，角色的动作表演既要协调流畅，又要符合动画运动规律。
6. 特效渲染：(1)刚体和柔体——在三维动画中对刚体和柔体进行物理特性的精确模拟，达成重力、碰撞、弹力的效果，模拟出衣料、毛发等的逼真质感；(2)粒子与流体——在三维动画中对流体和粒子的运动规律和状态进行物理模拟，表现出逼真的水、火、雨雪、烟雾等自然效果；(3)群体和变形——在三维动画中模拟出大规模角色群体运行和物体形变效果的过程；(4)灯光和材质——在三维动画中通过对灯光和物体材质的调节，营造不同物体在各种环境氛围下的特殊效果，以达到逼真的视觉效果。
7. 后期输出：包括合成、校色、音乐、音效、配音、剪辑及最终的成片输出。至此，一部完整的三维动画作品就诞生了。

现代CG动画生产流程

美术设计——进行造型设计和制作。通过场景、道具、角色等的设计，来创建富有感染力的画面造型和动画形象，是动画创意的重要组成部分。

美术设计——进行造型设计设计和制作。通过场景、道具、角色等的设计，来创建富有感染力的画面造型和动画形象，是动画创意的重要组成部分。

美术设计——进行造型设计设计和制作。通过场景、道具、角色等的设计，来创建富有感染力的画面造型和动画形象，是动画创意的重要组成部分。

美术设计——进行造型设计设计和制作。通过场景、道具、角色等的设计，来创建富有感染力的画面造型和动画形象，是动画创意的重要组成部分。

三维建模——使用特定软件制作数学的、线框表示的三维物体的过程。根据美术设计原画手工建立几何体数据模型，其过程类似于造型艺术中的雕塑。

三维建模——使用特定软件制作数学的、线框表示的三维物体的过程。根据美术设计原画手工建立几何体数据模型，其过程类似于造型艺术中的雕塑。

场景建模——是指对环境、道具等模型的塑造，当前潮流是追求场景的高度仿真。

场景建模——是指对环境、道具等模型的塑造，当前潮流是追求场景的高度仿真。

骨骼蒙皮——在三维动画中添加骨骼和蒙皮，使模型可以按照设计要求进行运动。运用运动生物力学对人或动物模型的骨骼进行控制，可以为人或动物模型产生各种符合物理特性、真实可信的动作效果。

骨骼蒙皮——在三维动画中添加骨骼和蒙皮，使模型可以按照设计要求进行运动。运用运动生物力学对人或动物模型的骨骼进行控制，可以为人或动物模型产生各种符合物理特性、真实可信的动作效果。

骨骼蒙皮——在三维动画中添加骨骼和蒙皮，使模型可以按照设计要求进行运动。运用运动生物力学对人或动物模型的骨骼进行控制，可以为人或动物模型产生各种符合物理特性、真实可信的动作效果。

肌肉系统——应用生物运动仿生力学，在三维角色模型上建造运行协调机构，实现三维模型肌肉质感的协调联动。

分镜设计——是将文学剧本转化为二维或三维图像表现的分镜头脚本，用以说明叙事顺序和镜头运用。

表情口形——通过对角色面部表情和口形动画的调制，刻画角色的内心感情以及与对白相吻合的口形变化。最新的表情捕捉技术和口形自动生成系统，进一步提高了表情、口形动画调制的效果和准确性。

表情口形——通过对角色面部表情和口形动画的调制，刻画角色的内心感情以及与对白相吻合的口形变化。最新的表情捕捉技术和口形自动生成系统，进一步提高了表情、口形动画调制的效果和准确性。

表情口形——通过对角色面部表情和口形动画的调制，刻画角色的内心感情以及与对白相吻合的口形变化。最新的表情捕捉技术和口形自动生成系统，进一步提高了表情、口形动画调制的效果和准确性。

动作表演——动作表演是对于角色动作的关键帧进行调制，使其产生连续性的动作，角色的动作表演既要协调流畅，又要符合动画运动规律。

动作表演——动作表演是对于角色动作的关键帧进行调制，使其产生连续性的动作，角色的动作表演既要协调流畅，又要符合动画运动规律。

刚体和柔体——在三维动画中对刚体和柔体进行物理特性的精确模拟，达成重力、碰撞、弹力的效果，模拟出衣料、毛发等的逼真质感。

刚体和柔体——在三维动画中对刚体和柔体进行物理特性的精确模拟，达成重力、碰撞、弹力的效果，模拟出衣料、毛发等的逼真质感。

刚体和柔体——在三维动画中对刚体和柔体进行物理特性的精确模拟，达成重力、碰撞、弹力的效果，模拟出衣料、毛发等的逼真质感。

粒子与流体——在三维动画中对流体和粒子的运动规律和状态进行物理模拟，表现出逼真的水、火、雨雪、烟雾等自然效果。

群体和变形——在三维动画中模拟出大规模角色群体运行和物体形变效果的过程。

灯光和材质——在三维动画中通过对灯光和物体材质的调节，营造不同物体在各种环境氛围下的特殊效果，以达到逼真的视觉效果。

后期输出——包括合成、校色、音乐、音效、配音、剪辑及最终的成片输出。至此，一部完整的三维动画作品就诞生了。

《现代CG动画生产流程》

第一步 漫画编创

第二步 漫画编绘

第三步 流程监管

第四步 脸部绘制

第五步 人物绘制

第六步 背景绘制

第七步 墨线绘制

第八步 黑白网点绘制

第九步 平色绘制

第十步 效果绘制

第十一步 后期编辑

第十二步 授权推广

MySQL

MySQL跟其他主流数据库一样，能够存储任何类型的数据，比如字符、数值和日期。而且，大多数应用程序中只会用到这3种数据。

1. 字符数据

1.1 字符数据分为字符型和文本型。字符型又分为两种，一是固定长度字符型（char），存储空间为255字节，不足空间以空格填充；另一种是可变长度字符型（varchar），存储空间为65 535字节，不足空间不用空格填充。在为表列定义字符类型时，必须指定最大字符数（英文每个字母占一个字节，汉字每个字占两个字节），不能超过相应类型的字节上限，例如：

char(40) /* 固定长度字符列，最多可以保存40个英文字母或20个汉字 */
char(280) /* 无效，超过了255字节 */
varchar(280) /* 可变长度字符列，最多可以保存280个英文字母或140个汉字 */

1.2 另外，在为表列指定数据类型的同时，可以同时指定列的字符集，例如：

varchar(20) character set utf8 /* UTF-8字符集，可以用于保存汉字等多字节字符 */

甚至，在创建数据库时也可以直接指定默认的字符集，例如：

create database myblog character set utf8;

1.3 对于要求存储空间大于64KB（64×1024=65 535字节）的列，就需要声明为文本型了。文本型又分为四种：短文本型（tinytext/255）、文本型（text/65 535）、中长文本型（mediumtext/16 777 215）和长文本型（longtext/4 294 967 295）。

由于MySQL提供了65 535字节长的可变长度字符型（varchar），因此短文本型（tinytext）和文本型（text）并不常用。

关于文本型数据，有以下说明：
（1）如果实际文本超出相应类型指定的最大长度，则多余文本将被截掉；
（2）如果实际文本不足相应类型指定的最大长度，则不会删除后面空格；

2. 数值数据

数值数据分为整数和浮点数（带小数点的数，有符号），而整数又分有符号数和无符号数（用于区分正负数）。MySQL中有5种整数数值类型：

较小整数（tinyint/-128~127或0~255）；
小整数（smallint/-32 768~32 767或0~65 535）；
中长整数（mediumint/-8 388 608~8 388 607或0~16 777 215）；
整数（int/-2 147 483 648~2 147 483 647或0~4 294 967 295）；
大整数（bigint/-9 223 372 036 854 775 808~9 223 372 036 854 775 807或0~18 446 744 073 709 551 615）。

声明整数类型列时，必须指定该列是有符号（signed）还是无符号（unsigned），例如：

smallint unsigned  /* 表示只保存正整数 */

有两种浮点数值类型：单精度浮点数，float(p,s)和双精度浮点数，double(p,s)。其中，p表示精度（小数点左右两侧的数字位数和），s表示至少保留几位小数。

3.时间数据

时间数据可以是日期、时间、日期加时间。MySQL有5种时间数据类型：

日期型：date YYYY-MM-DD 1000-01-01~9999-12-31
日期时间型：datetime YYYY-MM-DD HH:MI:SS 1000-01-01 00:00:00~9999-12-31 23:59:59
时间戳型：timestamp YYYY-MM-DD HH:MI:SS 1970-01-01 00:00:00 to 2037-12-31 23:59:59
年型：year YYYY 1901 to 2155
时间型：time HHH:MI:SS -838:59:59 to 838:59:59

其中，HHH:MI:SS中的HHH表示已经过去的小时数，而其他日期时间组件YYYY（年）、MM（月）、DD（日）的含义是可以一目了然的。

如果只想在某列中保存日期（年月日），则date即可满足需要；如果想保存日期和时间（年月日时分秒），则要使用datetime。timestamp与datatime的区别除表示的时间范围不同之外，是它的值可以在记录增加或被更新时自动生成。

事件的前因后果是这样的：

最近，总部位于挪威奥斯陆的、国际领先的浏览器制造商Opera公司，因为预见Opera Mini（为手机用户节省流量的服务）、Opera Turbo（提供全网加速功能的服务）以及Opera Link（支持用户数据实时同步的服务）的访问量将会激增，批准了一项价值百万克朗（100克朗兑换106元人民币）的服务器采购计划。

于是，众多知名服务器厂商应邀把服务器样机发到Opera公司参加竞标测试。然而，来自一家国际一流厂商的服务器把包括CSS之父、Opera公司首席技术官Håkon Wium Lie博士在内的所有测试人员全部当场雷倒，造成了几乎到手的百万元大单顷刻间付之东流。

到底是为什么呢？原来，当测试人员启动这家厂商的服务器，并使用Opera浏览器打开管理页面时，却被直接重定向到了错误页面。当然，这只是问题的表面而已。重定向嘛，不是服务器端脚本所为，就是客户端脚本的杰作。经过简单查找，现场人员发现管理页面的源代码中赫然写着如下一行JavaScript代码：

if (is.opera) { window.location.href=”config/error.htm”; }

把这行代码翻译成人类语言就是：如果查看当前页面的是Opera浏览器，就在窗口地址栏中打开config目录下的error.htm页面！

呵呵，居然胆敢如此歧视Opera浏览器，就算制造商再牛，服务器再好，搁谁那里都没有通过“测试”的道理呀。就因为这一行代码，丢掉百万元大单，称其为史上最贵的JavaScript代码，应该不为过了。

（据说，这行代码是经销商所为；而这家国际一流服务器厂商也未公开，待查中。消息来源cnBeta.com）

所谓LiveCD，就是一张位于光盘上的完整的操作系统。Google提供的LiveAndroid是一个ISO文件，下载以后可以将其虚拟到一个光驱中，然后在虚拟计算机里选择该光驱为启动盘，就可以启动Google Android OS了；或者，如果有刻录机，也不嫌麻烦，当然也可以将这个ISO文件刻录成光盘，放在光驱里，然后重新启动计算机，选择从该光驱启动，也可以进入Google Android OS。很简单——这就是LiveCD！

我使用的是前几天下载的VirtualBox 3.0.2（http://www.virtualbox.org/wiki/Downloads），这是一款开源的虚拟机软件，只有67.8MB。安装、设置、启动，都非常简单，不用说了。我为Android新建的“电脑”配置为内存256MB，硬盘2.0G，呵呵，对于一款手机操作系统而言，这算不算奢侈啊？

然后，从LiveAndroid的站点（http://code.google.com/p/live-android/）下载torrent文件（BT种子）。使用迅雷下载这个liveandroidv0.2.iso，文件大小为174MB，我家是1M的ADSL，用时大约40分钟——这段时间里，我安装VirtualBox并新建了虚拟电脑，而且还在Google Translator Toolkit中简单翻译了一下LiveAndroid的README（自述文件——附后）。

好了，上截图吧。第一张，启动VirtualBox后

第二张，启动虚拟电脑


第三张，加载Android OS文件

第四张，Live Android

第五张，Android OS启动

第六张，刚启动就提示电池电量不足

第七张，应用界面

第八张，待机界面

第九张，应用面板

第十张，拔号器

第十一张，启动浏览器

第十二张，Google搜索

第十三张，扩大后的地址输入框

第十四张，在浏览器中打开俺这个博客

第十五张，开发设置（这个最牛！）

返回页面顶部

为什么要推荐Eric Meyer的书呢？因为本身是技术专家，同时写书又能写得很浅显易懂的人并不多见（相反，技术高手，写书写不好的倒是常见得很），而Eric Meyer正是这样一位兼具技术和写作天才的人物。说了半天，Eric Meyer是谁呢？他是最负盛名的世界级HTML和CSS专家，W3C CSS&FP工作组成员，W3C CSS测试套件的负责人，拥有10多年Web开发和设计经验。简单地说，他就是CSS标准的制定者之一。如果你知道CSS，但没有看过Eric Meyer写的CSS书，那么你的CSS知识结构一定是不完整的，或者说基础一定是不扎实的——夸张一点讲，就像你自认为掌握了一门技术，但实际上并没有得到真传一样！

如前所述，推荐Eric Meyer的书主要有两点理由：首先，他是CSS的制定者之一，对CSS的各方面细节以及所有属性的来龙去脉都了如指掌，因此他讲起CSS来，可以说是如数家珍、透彻明白。其次，他的写作水平绝对一流，各种复杂、难懂的CSS技术细节，甚至大部分CSS书根本不会涉及到的属性，在他的笔下都被描述得栩栩如生、异常清晰。

但是，Eric Meyer的书也有一个“缺点”，那就是行文不加丝毫粉饰的同时，给自己的书配备的插图却非常简单朴素，没有那么光鲜漂亮。无论是他的权威经典著作CSS： The Definitive Guide（中文版《CSS权威指南（第三版）》），还是以理论与实战结合见长的Eric on CSS（中文版《Eric谈CSS卷一》）及More Eric on CSS（中文版《Eric谈CSS卷二》），亦或他唯一一本面向CSS初学者的CSS Web Site Design（中文版《CSS站点设计手册》），概莫能外，全都是简单、直观的插图——虽然这些插图足以、也能够非常典型地说明、演示上下文所要讲解的技术细节，然而，跟其他年轻CSS技术书作者精心设计的插图相比，确实不那么容易吸引那些喜欢蜻蜓点水、拂光掠影的年轻CSS学习者的眼球。

想想也在情理之中，毕竟CSS是讲表现、外观和样式的，如果CSS书的插图不漂亮、不吸引人，怎么让人相信你讲的技术能做出漂亮的网页来呢？然而，不是有那么句话嘛——真理都是赤祼裸的，Eric Meyer书中那些丝毫没有粉饰的插图，似乎就在那里无言地宣称：喜欢真理的人，请走过来；害怕真理的人，请你走开！

事实上，我翻译过CSS： The Definitive Guide的全书（第2版），看过他的Eric on CSS系列，给我的感觉是，他的书只能用“权威”两个字来形容。换句话说，你所有关于CSS的疑问，都可以在他的书中找到完美的，或者不完美但却很合理的答案。最后，我想对CSS初学者，甚至中、高级水平的CSS技术人员说，如果你还没有看过Eric Meyer的书，我相信你早晚都需要补上这一课；因为即使市面上的CSS书再多，即便网上各类CSS免费教程再丰富，也找不出一本书、一个站点的资源能够与他的书相媲美！

因此，我推荐Eric Meyer的CSS权威著作。

• CSS: The Definitive Guide, Third Edition (O’Reilly & Associates, November 2006; first edition, 2000)
• Cascading Style Sheets 2.0 Programmer’s Reference (Osborne/McGraw-Hill, March 2001)
• CSS Pocket Reference (O’Reilly & Associates, May 2001)
• Eric Meyer On CSS (New Riders, June 2002)
• More Eric Meyer on CSS (New Riders, April 2004)
• CSS Web Site Design (Peachpit, November 2006)

第3次印刷译者附注

本书自出版以来，受到了广大读者的热烈欢迎。本次印刷对第1次印刷中发现的错误和不妥之处进行了修订。同时，针对读者反馈中比较有代表性的问题，特作如下说明。

1. jQuery版本变化对本书的影响

本书英文原版在写作时，jQuery的最新版本是1.1。到了中文版出版时，jQuery 1.2已经发布了。由于新版本中的一些特性发生了变化，导致本书少量内容与新版本不一致，而且个别示例在新版本下不能运行。其中，主要是jQuery 1.2取消了对XPath选择符的支持（原因是XPath选择符可能会导致性能问题）。为确保使用新版本jQuery的读者能正常运行本书相关示例，现给出两种解决方案：第一种是继续使用XPath选择符，但必须下载Basic XPath插件，下载地址是http://plugins.jquery.com/project/xpath。插件实际上也是一段jQuery脚本，使用时把它贴到你自己编写的jQuery代码前面即可。这样，你的jQuery代码就可以支持XPath选择符了。第二种就是避免使用XPath选择符。对于本书个别示例中使用的XPath选择符，可以尝试把它们修改为其他等效的选择符——例如，把$(‘tr:not([th])’)修改为$(‘tr:not(:has(th))’)。

2. 阅读本书的背景知识

本书作为介绍流行JavaScript库——jQuery的全球第一部著作，内容丰富、通俗易懂，深受广大读者的喜爱，是学习jQuery的必读图书。但是，由于少数读者对HTML、CSS、JavaScript以及DOM的相关知识掌握还不十分全面，造成了在理解本书个别示例时的困难。如果读者感觉自身还缺少某方面的基础知识，可以结合相关技术书籍和本书共同学习，互为参考，以达到齐头并进的学习效果。在此，推荐人民邮电出版社出版的下列图书。

• 《HTML XHTML CSS基础教程》
• 《写给大家看的CSS书》
• 《JavaScript基础教程》
• 《JavaScript DOM编程艺术》

3. 推荐两个实用的小技巧

（1）有读者反映，在将示例中的提示换成中文时，在某些浏览器中显示不正常——显示乱码。这是一个在学习外版书时普遍存在的问题。由于国外作者保存示例代码文件（.js）或网页文件（.html）时，通常默认采用ANSI编码，而这种编码只支持西方字符。因此，如果要在代码或示例中使用中文，一定要记住把这个文件另存为UTF-8编码格式。

（2）从jQuery 1.2开始，Google为jQuery提供了CDN（Content Delivery Network，内容分发网络）支持，以便用户的浏览器从位于全球各地的Google服务器上就近加载jQuery。这是目前使用JavaScript库的一种最流行、最方便、最快捷的方式。如果读者在试验本书示例时不想把jQuery库下载到本地，也可以使用这种远程加载方式——只要把本书示例页面中的下面这行代码：<script src=”jquery.js”></script>

替换成以下代码即可：

<script src=”http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js” type=”text/javascript”></script>

当然，还有个前提，就是你的电脑必须连接到了互联网。

你在阅读和学习过程中，有任何问题，欢迎致信contact@turingbook.com。

最后，祝你阅读愉快！

其次，“相邻”是从位置这个“次要”属性上对sibling给出的定义，如果遇有同一句中其他描述位置关系的词，将发生冲突，无法处理。例如下面这句话：

.next([selector])——The sibling imediately following each selected element（Learning jQuery 1.3, Appendix D, DOM traversal methods）

在将sibling译为“同辈”的情况下，很好处理：

.next([selector])——每个选中元素紧邻的下一个同辈元素

否则，如果将sibling译为“相邻”，就不好处理（至少不好理解）：

.next([selector])——每个选中元素紧邻的下一个相邻元素

朗诵：丁建华、方明、许还山、肖雄、吴京安、严晓频、凯丽、剧雪、康庄、薛飞

伴奏：爱乐女室内乐团
篇 目（以演出现场为准） 作 者 朗 诵

序 《有一个字，与生俱来，排山倒海》画外音 丁建华

1.《孩子眼中的爱》佚 名 童声朗诵
2.《孩子，请听我说》 佚 名 王建新
3.《父爱》 佚 名 吴京安
4.《致橡树》 舒 婷 丁建华
5.《雨巷》 戴望舒 康 庄
6.《我喜欢你是寂静的》 聂鲁达[智利] 严晓频
7.《当你老了》 叶 芝[爱尔兰] 肖 雄
8.《选择》 邓康延 剧 雪
9.《祖国啊，我亲爱的祖国》 舒 婷 凯 丽
10.《大堰河，我的媬姆》 艾 青 薛 飞
11.《生活是美好的》 契诃夫[俄] 许还山
12.《爱心创造的奇迹》 伊丽莎白•恩斯[美] 丁建华

结束语：《爱是不能忘记的》
主持：方 明 解说词撰写：邓康延
演奏： 北京驱动管弦乐团

界面，不仅是现代Web应用程序与传统Web应用程序的分水岭，曾经也是横亘于传统Web应用程序与桌面应用程序之间的一道难以逾越的“鸿沟”。然而，Ajax及其框架技术突飞猛进的发展，不仅让一个或者少数几个HTML页面中容纳整个Web应用程序（或复杂功能组件）成为可能，而且也让现代Web应用程序的界面，展示出了堪与桌面应用程序媲美的耀眼风姿。

读者手中拿着的这本书，是两位出色的UI设计专家Bill Scott和Theresa Neil，在他们多年潜心研究、深入实践的基础上，结合现代认知心理学的最新发展成果和流行Web应用程序的界面设计实例，以六大设计原理为依托，以最佳设计实践为着眼点，奉献给我们的一本精彩绝伦的现代Web界面设计权威指南。

从译者的角度来看，本书既是一本Web界面设计手册，又是一本Web界面实例参考，它基本上涵盖了现代Web界面设计的普遍规则和最佳实践。Web界面设计人员通过阅读本书，可以迅速在当前或将来的项目中发现最合适的应用场景；开发人员通过阅读本书，能够轻松地将丰富的示例映射为自己头脑中的编码要点；Web项目的管理人员通过阅读本书，就有了在与客户商讨界面设计方案时的“共同语言”。哪怕你购买本书只是出于对其中漂亮Web界面的好奇，甚或只是想通过本书了解目前最流行的Web站点，相信在阅读本书之后，你会发现本书为你揭开了现代Web应用程序为什么如此令人着迷的奥秘。

感谢金照林、柳安意在对本书中耕时付出的努力，感谢徐定翔为译者翻译本书提供支持，感谢本书编辑陈元玉指出或纠正本书译稿中存在的问题。翻译本书的过程中，译者尽最大努力确保术语统一、准确，也尽最大努力以简洁、地道的中文为读者重现原书的意境和风貌。但是，囿于个人的水平，书中的问题和疏漏之处在所难免，敬请读者朋友给予批评指正。译者邮箱是lsf.email[at]gmail.com，个人网站是http://www.cn-cuckoo.com。

译者 2009年6月14日于北京

豆瓣上的《Web界面设计》

言归正传。对一些表示虚义的词，应该利用“意会”来“翻译”，如果非要“言传”这些词，即非要直译其字面意思，结果不是啰里啰嗦，就是不伦不类；举两个小例子：

[例1]The most significant change reflected in this thenth edition is a new chapter on computer graphics(Chapter 10).

如果把这句话里的reflected in翻译出来，效果并不好。如：“第10版中反映出的最大变化是关于计算机图形学的新的一章（第10章）”

仔细咂吧咂吧滋味，好像是不会说中国话的人翻译的。没错，这种多此一举的翻译，恰好应了中国的一个成语，即“画蛇添足”。你看，要是去其两“足”，只剩下“第10版最大的变化是新增了关于计算机图形学的一章（第10章）”，岂不更简练、更明确？

[例2]Most of this chapter focuses on the discipline of 3D graphics in which abstract models of three-dimensional worlds are encoded and then used to produce two-dimensional images.

没错，引导定语从句的in which是万万不可“言传”的。你猜自怎么着，硬是有“敢为天下先”的，看人家翻译的：“这一章的大部分内容集中在3D图形学科，其中对三维现实世界的抽象模型被编码，然后用来生成二维图像”。

in which引导的定语从句，如果相对较短，可以让它直接“修饰中心词”（即此处的宾语discipline of 3D graphics）；如果像这里比较长，就要郑重其事一点，给人家一套独立的谓语结构，不要舍不得。比如：“这一章的大部内容集中在3D图形学方面，也就是如何对三维现实世界的抽象模型进行编码，然后再据以生成二维图像的技术”。

类似地，in that、in ways都不能“言传”，而是要“意会”。归根到底，还是那句话：翻译要翻译意思，不是翻译字面。

Ryan Dewsbury，一介技术人员，关注非技术性的用户体验——软件应该带给用户流畅、无障碍的感觉——由来已久。溯本求源，概肇始于他本人曾受到C++模板技术生成代码的强烈震撼。那种如饮甘醴、如沐春风的感觉，让这位C++程序员久久不能释怀。然而，离开工作单位，面对作为软件用户的非技术人员（家人、朋友）却又无法言传那种美妙的“用户体验”。这让他很不爽！——“我决定抽时间编写一个客户端应用程序，让它带给用户的优雅体验，就如同开发者看到写得漂亮的代码一般”。

于是，他用C++开发了一款体积小巧、界面简洁，类似今天Google Talk的即时通信软件。结果受到用户追捧，达到百万级的下载量——简洁作为一种价值观，与full-function（全功能）相对；这与Google对用户体验的理解不谋而合。但是，C++做界面似乎笨拙了点，因此简单的HTML+CSS时常令他心驰神往。

2005年，Ajax被人发现了。虽然基于Ajax技术的Google Maps让Ryan Dewsbury惊呼：桌面级用户体验现身于Web了！然而，在了解“事实真相”后，又不免“怅然若失”——“我知道使用JavaScript存在着很多的局限性。由于这些局限性，几乎不可能用它来构建一个大型复杂的客户端应用程序”——潜台词：“浴火重生”的JavaScript虽然强大，但浏览器不兼容性问题太严重，学起来简直烦人透顶，哪有丝毫“用户体验”可言？简直令人失望至极。更何况，一人之力怎与Goolge的Maps团队相比呢？看来是没有希望开发出具有Google Maps般用户体验的Web应用程序了，唉！

但是，峰回路转，在Ryan Dewsbury熟悉的Java语言与能带给用户更好体验的Ajax应用程之间架起一座“彩虹桥”的Google Web Toolkit（GWT）发布了。真的吗？可以用Java开发Ajax应用程序——不用学习JavaScript、不必面对复杂的浏览器兼容性问题？呵呵——当然要“抢鲜”试一试喽。

结果，仅用3周时间，Ajax应用程序Gpokr诞生了，而且全Java开发；这是一个在线游戏应用程序。发布以后，引得GWT开发团队的高人纷纷赶来试用。在感谢这些GWT“之父”们之后，Ryan Dewsbury没忘提一句“最让我激动不已的，就是GWT编译器能够把优美的Java代码转换成JavaScript”——这不正是自己魂牵梦萦、上下求索的代码生成技术的翻版吗？对Java技术人员及至本书作者而言，GWT相当于提供了C++中的模板技术。GWT编译器就是代码生成器，能把Java代码转换成JavaScript——简直重现了作者当年的那种如饮甘醴、如沐春风的感觉，很有点天作之合的味道，不是吗？接着，作者又发感慨“于是，任何人都可以创建向用户交付美好体验的应用程序，而可靠的GWT则给我留下了深刻的印象”，这不是如获至宝的感觉是什么？

分享分享分享，强烈的“共产主义”精神，反复地刺激着从未写过书的Ryan Dewsbury的思想深处，他的灵魂所在地。对呀，要是写本书就好了，这么一个“令人惊叹的工具”哪能没本书来宣传宣传呢？当时市面上还没有出GWT的书，不过Ryan Dewsbury也没有写书经验。没写过怎么了，反正“当时可以说也没有什么人对GWT很在行”。不会写，先做例子呀！通过做例子，既能搞通GWT，又能掌握相关的Web技术。来他个博观约取、厚积薄发……总之，先埋头编上几个月的程序再说。

Ryan Dewsbury

当然，最好是找几个流行的Ajax应用程序参考着做。比如：Google Start Page（http://www.google.com/ig）、基于Ajax的多搜索引擎集成、Blog文章编辑器、即时通信系统（这个简单，以前用C++就做过，呵呵。不过，这次要基于开发网页了）。最后，来个更牛的基于网页编辑数据库的程序（这个好像跟那个管理MySql的phpAdmin类似，不过那是管理本地数据库文件，而这个管理的则是远程数据库，厉害吧）。嘿，还别说，几个例子做下来，对GWT简直门清了，以前那些似是而非的Web概念也都清晰了。嗯，写书这个想法还真不错哩。

又经过几个月的日夜奋战，本书就新鲜出炉了。

10点前，设在里间的会场布置好了；撤掉了3张台子。我挑了第一排的座位，一是没带眼镜，二是怕没话筒听不清。9点50左右，一位身材稍胖，年逾六旬的高个子老者走进俱乐部。他上身穿黄色半袖乒乓球衣，下身穿深蓝色运动长裤，肩挎一个大运动包，身边还跟着一位小伙子。进入会场后，距离近了，我才看清，确实是王吉生老师。不过，跟《乒乓球探秘》封底的照片相比，大约差了有10岁。

10点整，讲座正式开始。王老师开门见山，一上来就给出了讲座的主题和提纲。他说，今天主要讲一讲弧圈球，分三个方面展开，首先讲弧圈球的起源和发展变化，然后讲讲弧圈球的动作要领，最后再讲一下怎样拉出更有威力的弧圈球。以下就是我通过回忆，记录的王老师讲课的内容要点。

一、乒乓球的起源及发展变化

乒乓球由日本人发明，后来传入欧洲。欧洲人将弧圈球发扬光大，不像日本人只会正手拉，而是创造了正反手两面拉的打法。但是，第一代弧圈球打法，不能将打和拉分开，是两个动作，影响协调，不利于连续击球。到了瓦尔德内尔和佩尔森时代，才真正解决打拉结合的问题——即通过将球拍立起来，用手腕调节其前倾/后仰角度，实现打和拉的无缝结合。比如，在触球瞬间，拍形前倾，摩擦多一些，就是拉；拍形后仰，撞击多一些，就是打。

然而，纵观世界乒坛，对弧圈球（或者说乒乓球）理解最深、最到位的，还要数中国人。例如，韩国人认为乒乓球致胜的要素，一是发球接发球，二是步伐灵活（能追上球），三是发力。但只有中国人抓住了要害，即中国人把现代乒乓球致胜的要素归结为：速度、力量、旋转、落点和弧线，一共5个因素。这5个因素在实战中可以有无数种组合，都可以构成致胜要素。例如，力量小但落在了对方空档区域的球，同样可以致胜。不过，在这5个因素中，挑战人类极限的只有速度。因为人反应需要一定的时间，只有速度才能挑战人的极限，所以也就成为这5个因素中的核心。也就是说，不管什么球，无论其力量大小、旋转强弱、落点优劣、弧线高低，只要速度够快，对方没时间反应，就能致胜。

但是，外国人认为我们理解得太复杂了；或者说，他们理解不了中国人的思想。

二、弧圈球的动作要领

拉弧圈球，最重要的是协调和发力。力量当然要源自身体，但最重要的是要知道，只有以支撑腿为轴（右手就是右腿）的旋转，才是关键。通过旋转身体，带动胳膊旋转向前，然后力量再通过小臂、通过手指（直拍背后的中指，横拍背后的食指）尖，传递给球面的有效击球区域。

三、哪种弧圈球最有威力

弧圈球有3种，取决于击球点。第一种击球高点，球在对方台面弹出后，弧线同样高；第二种击球下降前期，球在对方台面弹起后，弧线低平；第三种击球下降后期，此时摩擦较多，球在对方台面弹起后，会有变速，即向下沉。

总而言之，第一种和第三种弧圈球给对方造成的困难较大，不易回接。因为，第一种球向前拱，对方不易发力；第三种球，变速后下沉，要求对方在很短时间内反应，并抢到其上升期击球。

谢谢王老师！

附王老师简介

王吉生，1946年生 籍贯：浙江。 

60年代是北京乒乓球队运动员，70年代开始担任练习员以来曾先后培训出阎桂丽、魏力婕、杨燕群、赵晓云等多名世界级优秀国手和全国冠军，曾被中国乒协评为优秀教练员。 

80年代曾先后应邀担任索马里、巴基斯坦等国家乒乓球队主教练，多次获得重大国际比赛冠军。是我国第一批高级教练员。 

90年代以后，投入乒乓球器材的研制开发，先后创造了“四拓”“郗恩庭”“世奥得”等多个知名品牌。并多次在“乒乓世界”上发表文章。

如果这种扩展代码会逐渐多起来，Dojo推荐将扩展代码保存在模块中。创建模块也非常简单——在说明创建模块的步骤之前，需要先声明一个概念，即假设示例页面（前面的dojo_ori.html）所在目录为“当前目录”——步骤是：在当前目录创建一个文件夹名叫ext-dojo（这个名字是《Dojo权威指南》中推荐的），然后把扩展代码转移到一个独立的.js文件中（假设该文件名为foo.js——名称随意，最好遵循语义化原则，让人能够对该模块的作用一目了然），把这个文件保存在ext-dojo目录下，再在其第一行添加

dojo.provide(“ext-dojo.foo”);

这样，模块文件（即foo.js）就大功告成了！

最后，怎么调用上面创建的模块并使用其中的扩展功能（方法）呢？打开这个页面（dojo.html）看一下就明白了。比较一下dojo_ori.html和dojo.html，就会发现 dojo.html包含的如下几处不同。

（1）djConfig配置项中多了baseUrl:’./’设置，顾名思义，baseUrl的作用就是设置“基准URL”，而“./”表示当前目录，意思就是让dojo.require()语句以当前目录为起点，查找要加载的模块。

（2）在调用代码中，多了如下代码：

dojo.registerModulePath(“ext-dojo”, “./ext-dojo”);
dojo.require(“ext-dojo.foo”); 

同样， dojo.registerModulePath()方法的作用也可以“顾名思义”；即，注册模块路径。通过该方法的两个参数可知，一个指定了dojo.require()语句加载模块文件使用的“限定名”，另一个则是模块文件所在的真实（相对）路径。

最后，dojo.require()方法基于前面的配置加载模块文件。不知道读者朋友注意到了没有，dojo.require()与dojo.provide()的参数是完全对应的。

Dynamics of Software Development
by Jim McCarthy (Author) 

Paperback: 224 pages
Publisher: Microsoft Press (August 9, 2006)
Language: English
ISBN-10: 0735623198
ISBN-13: 978-0735623194

中文书名：《微软软件研发致胜之道：来自Visual C++开发团队的经验结晶》

本书前一版（1995版）中文书名《微软团队：成功秘诀》，由机械工业出版社引进出版，受到读者的热烈欢迎。作者JimcMcCarthy，10年前即任微软VisualcC++事业部的总监。10年后，作者在上一版基础上，充实了10年来的心得和经验，新增“2006部分”，对上一版作了大幅修订和扩充。为传承世界一流软件研发团队的宝贵经验，人民邮电出版社引进了这本书的最新版本，并诚邀有志成为名著译者的朋友负责本书翻译。

联系人：傅志红  
电子邮件：fuzh[at]turingbook.com （注：须将[at]替换成@）
电话：010-51095181-610

虽然不是头一次见到Screencast，但毕竟也算个新词儿——类似的新词儿还有Webcast（网络视频、网络直播、网上节目）、Podcast（Ipod＋broadcasting，播客？行动数位广播？）。有人把这个“术语”翻译为“截屏视频”或“抓屏视频”。意思没有什么问题；可似乎还欠缺那么一点点味道，比如说发音上难以对应。抱着这种求全的心理，开始搜索。结果，不期而遇了一个在线制作Screencast的站点——ScreenToaster（Screencast吐司机？）。

这个站点好。可以在线录制屏幕操作，制作Screencast。而且，录制完毕后，可以直接上传到这个站点共享，也可以上传到YouTube；还可以直接点击相应图标，把视频发送到一大堆社区网络服务去共享（前提是必须拥有这些服务的账户；可以即时登录），有Twitter、Facebook、MySpace、FriendFeed、Google Bookmarks、Yahoo! Buzz、StumbleUpon、Digg和Delicious。还可以另存为.mov或flash格式，然后下载。

说到这，这篇文章的主题就已经发散了（由讨论Screencast的译法变成了讨论ScreenToaster）。既然如此，就把发散进行到底吧！

“五·一”节期间，抽空仿照译言的批眉功能做了一个小页面。由于一直比较忙，就做了个开头（前端部分），但还有待于完善；而且，后端还没着手做。看到ScreenToaster之后，忽然想到用它来制作一个“使用教程”，倒是蛮爽啊（以前用的都是Windows应用程序）。Action一番，得到如下视频：

下面简单分析一下：

译言使用MooTools框架实现交互，利用CSS定位“图钉”，通过Ajax与后端通信。这种解决方案思路虽然比较清晰，但过于简单，也缺乏灵活性。

比如，为了通过CSS定位正确反映眉批位置，页面布局必须“写死”，页面版式只能居中，两栏的宽度也不能再改了；一改，“图钉”的绝对位置就跟正文对不上号了。另外，被批注的文字在常规状态下也没有通过颜色变化来突出显示，只有在鼠标悬停于“图钉”上时，才知道批注的是哪句话；不够直观。

我在考虑另一种方案：把为了保存眉批内容而动态创建的图像和DOM元素，直接作为正文的内容写到数据库中。记得我翻译的《JavaScript DOM高级程序设计》中有个DOM生成器的案例，是把HTML转换为DOM结构；现在的问题恰好相反，即把DOM结构转换成HTML，然再通过Ajax传给后台。 有时间再考虑一下，眼下看来似乎还是可行的。

不知天下高手还有没有更好的解决方案；当然，最好的解决方案应该参考Google Docs，不过其JS好像是加了密的（可一点儿也不甜噢！:)）。

事实上，畅销书作者Ben Forta老师的家就安在Oak Park（橡树园），只不过是美国密歇根州的那个Oak Park，不是建筑大师弗兰克·赖特和文学家海明威的故乡，芝加哥城西10英里的伊利诺伊州奥克帕克（Oak Park）。

提到橡树，不禁忆起学生时代喜欢的一首诗——《致橡树》。舒婷老师在这首脍炙人口的诗作中，以橡树和木棉作喻，热情讴歌了女性的人格独立及崭新的爱情观。这首诗作优美、隽永，今日读来仍有沁人心脾、荡涤灵魂之感。现将中、英两个版本全文摘录如下，也给这次“探索之旅”画上一个颇有艺术性的句号。

最后，又查英文维基Christmas词条页面，见与上述解释相类，此番求证方才告一段落。

附：《希腊字母发音对照表》（希腊字母发音及含义）（希腊字母书写方法）