﻿<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.9.2" -->
<rss version="0.92">
<channel>
	<title>为之漫笔</title>
	<link>http://www.cn-cuckoo.com</link>
	<description>本博客专注于Web前后端技术和技术翻译。目前正在翻译《JavaScript高级程序设计（第2版）》。新浪微博（t.sina.com.cn/lisf），Twitter（@cncuckoo，仅仅用于跟踪国外牛人；我翻不了墙，无法接受各位朋友的follow，抱歉！）</description>
	<lastBuildDate>Sun, 28 Feb 2010 03:16:54 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>转载《翻译的艺术——致译者的一封信》</title>
		<description><![CDATA[原文作者：刘江（CSDN&#38;《程序员》总编）
原文链接：http://blog.csdn.net/turingbook/archive/2009/10/13/4665015.aspx
翻译无小事：要有使命感
当你录入每一个字的时候，无论正确或者错误，优雅或者蹩脚，它都有可能（如果没有在你自己日后的审查或者出版社的编审环节中被发现和解决的话）变成历史，保存在大大小小的图书馆里，被成千上万的（纸书和网络连载、电子版的）读者看到并对他们产生影响。
很多技术书，首印以后可能不会重印，所以，错误可能永远留在那里。勘误表当然能起到一定作用，但是请注意，我们没有办法将勘误表送到每个读者手里。而且，想想拿着勘误表在书上改正，该是一件多么痛苦的事情。
翻译无易事：不要过于自信
著名翻译家傅雷当年全职在家里专事翻译，呕心沥血，不过“日译千字 ”。（当然，我们毕竟翻译的是技术文档，难度和要求都小得多，我见过有经验的译者全职翻译每日万字左右的。）
有的译者会说：“这本书我读起来很轻松啊，翻译没问题！” 其实，翻译和阅读不同，能差不多看懂，和逐字逐句转变成地道流畅的中文，让读者（可能包括基础稍差的）在不接触原文的情况下容易地理解原作者所说的意思，基本上不是一回事。
有的译者会说：“这本书里的技术我很精通，翻译起来很容易。” 其实，翻译书的时候，所面临的技术问题相对较少（因为书往往是自成一体的，凡事多有来龙去脉。但是注意，只是相对！你很可能遇到自己不熟悉甚至根本不懂的技术领域），除了有些原书代码、叙述等等本身就有错，一般不难解决。毕竟你把开发环境架起来，试一下，基本上都可以搞定。 常见的错误，反而更多是因为英文本身不理解或者误解造成的。往往一个小小的复数、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. 翻译中，遇到自己不懂、不好解决的问题，首先要多查多问。如果在交稿前仍然没有解决，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。千万不要掩饰、隐藏起来，铸成大错。
另外，特别推荐思果先生的翻译原则 ，请反复体会：

一、翻译切不可不守纪律，没有尺寸，乱添乱减。虽然佳译像盐化在水里，看不出痕迹，但盐总在那里，没有添，没有减。有的翻译是“演义派”，补出很多情节，全是原文没有的。有的随意删削，好像在编辑。（双关语、俏皮话等有的却不可翻者例外。）
二、切不可译字，要译意，译情，译气势，译作者用心处。记住，译者最大的敌人是英文字。
三、切不可抱定一个英文字只有一个中文译文解释，以不变应万变。如果你译一个英文字把认定的一个意思写下，再和上下文一同看，觉得不大象话，你可能错解了那字的意思，赶快细查字典。
四、切不可抱死一两本英汉字典做翻译工作。不论编得多好的英汉字典都不很可靠，这种字典有先天的缺陷，有人谋的不臧；并非无用，而绝不完全可靠。多备几本好英文字典，不怕辛苦多翻翻。
五、不要以为译好就十全十美。整段、整句会漏译，数目字会看错（这一点最不能得到别人原谅），英文会看错，中文会不通顺，至少逐字逐句对一两次，过些时再看一两次（单看译文是否可以过得去）。你多找出一个错，别人就少发见一个。
六、不懂的题材，千万不要率尔翻译。至少也要找一两本有关的书或大一些的百科全书查一查。如能找到专家请教一下更好。西方的学问分门别类，每一门都极高深，得到各科通俗的常识都不容易，不用说全部的知识了。
七、没有绝对把握的中文字词或成语不要用。成语用得贴切，不啻锦上添花；但失之毫厘，谬以千里，用得不对，反而贻人笑柄。用时也许觉得是神来之笔，其实仔细一查，似是而非，或意思正正相反。

]]></description>
		<link>http://www.cn-cuckoo.com/2010/02/28/a-letter-to-translaters-from-liujiangce-1427.html</link>
			</item>
	<item>
		<title>经典名著，精选样章</title>
		<description><![CDATA[在一年一度的新春佳节即将到来之际，应热心读者的要求，为满足大家先睹为快的愿望，也为了答谢朋友们对本博客长期以来的支持，即日起到春节前夕，本站将发布尚未出版的《JavaScript高级程序设计（第2版）》一书的样章（暂定为3章，约115页）。
申请办法
1、发邮件到：lisf@turingbook.com。
2、邮件主题：《JavaScript高级程序设计（第2版）》样章；邮件内容：您的Email地址。
3、24小时内收到样章，先睹为快！
备注：样章格式为PDF，托管在“Google文件”，可以在线查看（无须登录），也可以下载和打印。希望在线查看PDF的朋友，请在邮件正文中注明“希望接收Google文件”字样，即可收到样章的链接（也可以下载）；否则，将收到PDF文件（*请确保有5M以上的空余邮箱空间）。
样章列表（详细目录）
第3章 基本概念
第4章 变量、作用域及内存问题
第5章 引用类型
《JavaScript高级程序设计（第2版）》简介
本书是人民邮电出版社图灵公司引进出版的大畅销书、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
]]></description>
		<link>http://www.cn-cuckoo.com/2010/02/06/professional-javascript-developers-wrox-programmer-sample-chapter-1411.html</link>
			</item>
	<item>
		<title>评判浏览器API好坏的标准是什么</title>
		<description><![CDATA[Original Post：What makes a good browser API?
Nicholas C. Zakas，2009年11月24日
翻译完成：2010年1月22日，最后更新：2010年1月22日
上个月，我又参加了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 = &#34;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(&#34;get&#34;, &#34;/somexml&#34;, true);xhr.onreadystatechange = function(){&#160;&#160; &#160;if (xhr.readyState == 4){&#160;&#160; &#160; &#160; &#160;if (xhr.status == 200){&#160;&#160; &#160; &#160; &#160; &#160; &#160;process(xhr.responseXML.getElementsByTagName(&#34;item&#34;));&#160;&#160; &#160; &#160; &#160;}&#160;&#160; &#160;}};xhr.send(null);
虽然有人会说onreadystatechange这个事件处理程序看起来有点麻烦，但实际上，你要做的不过是检查一点信息，以确定是否接收到了正确的数据。可是，所有必需的信息都已经各就各位了，而且也已经转换成了方便访问的格式：HTTP状态就在那摆着，而XML也已经转换成了DOM格式。为了给你提供这些数据，API已经做了不少的工作了。
另一种不太常见的用法就是在URL中包含提交的表单数据。虽然代码难看点，但仍然可以接受：
var xhr = new [...]]]></description>
		<link>http://www.cn-cuckoo.com/2010/01/22/what-makes-a-good-browser-api-1391.html</link>
			</item>
	<item>
		<title>《JavaScript高级程序设计（第2版）》序</title>
		<description><![CDATA[
从诞生至今的大部分时间里，焦虑、抨击、蔑视和误解一直与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高级技术经理 哲学博士
于加利福尼亚州森尼维耳市

Nicholas C. Zakas，Yahoo!主页首席前端工程师，个人网站www.nczonline.net。《Professional JavaScript for Web developers, 2nd Edition》作者。最新专著《High Performance JavaScript》（O&#8217;Reilly Media; 1 edition,March 15, 2010）。

本站相关译文

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



]]></description>
		<link>http://www.cn-cuckoo.com/2010/01/17/professional-javascript-for-web-developers-2nd-edition-foreword-1373.html</link>
			</item>
	<item>
		<title>Nicholas C. Zakas谈怎样才能成为优秀的前端工程师</title>
		<description><![CDATA[Original Post：What makes a good front end engineer?
Nicholas C. Zakas，2007年8月15日
翻译完成：2010年1月10日，最后更新：2010年1月10日
昨天，我负责了Yahoo!公司组织的一次面试活动，感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo！工作充满激情的问题。在昨天的应聘者中，只有一个人的问题是我认为最好的，那个人问我：“你觉得怎么才能成为优秀的前端工程师？”我觉得很有必要把这个问题从面试房间里拿出来讨论一下。
首先，前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行，你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通，但你至少要能够运用它们完成大多数任务，而无需地频繁地寻求别人的帮助。
优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的，没错吧？我甚至可以说这些技术几乎每天都在变化，如果没有快速学习能力，你就跟不上Web发展的步伐。你必须不断提升自己，不断学习新技术、新模式；仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别，而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。
计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是，我们所说的前端不是什么科学，而是艺术。艺术家不仅要掌握谋生的技术，还要懂得如何运用。对同一个问题的解决方案在这种情况适用，在另一种情况下可能就不适用。对Web应用程序的前端而言，解决同一问题的方案经常会有很多。没有哪个方案是错的，但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适，而在什么情况下应该重新选择。
优秀的前端工程师需要具备良好的沟通能力，因为你的工作与很多人的工作息息相关。在任何情况下，前端工程师至少都要满足下列四类客户的需求。

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

那么，前端工程师应该最关注哪些人的意见呢？答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期，然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上，因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能，必须删繁就简，你怎么跟产品经理解释？再比如，假设某个设计如果不改回原方案可能会给应用程序造成负面影响，你怎么才能说服UI设计师？作为前端工程师，你必须了解每一类人的想法从何而来，必须能拿出所有各方都能接受的解决方案。从某种意义上说，优秀的前端工程师就像是一位大使，需要时刻抱着外交官的心态来应对每一天的工作。
我告诫新来的前端工程师最多的一句话，就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住，一定先搞清楚别人到底想让你干什么，不能简单地接受“这个功能有问题”之类的大概其的说法。而且，你还要确切地知道这个功能或设计的真正意图何在。“加一个按钮”之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理，问一问这个按钮有什么用处，然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师，这种沟通至关重要。
无论从哪个方面讲，我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了，为了在多种平台中使用，多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术，涉及到广阔而复杂的领域，这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门，但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力，才会真正让你变得优秀。
延伸阅读

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


Nicholas C. Zakas的书











]]></description>
		<link>http://www.cn-cuckoo.com/2010/01/10/nicholas-c-zakas-talk-about-what-makes-a-good-front-end-engineer-1356.html</link>
			</item>
	<item>
		<title>如何通过Nicholas C. Zakas的面试</title>
		<description><![CDATA[Original Post：Surviving an interview with me
Nicholas C. Zakas，2007年3月27日
翻译完成：2010年1月9日，最后更新：2010年1月10日
早就打算写这篇文章了，但时至今日才决定动笔。如果你投了简历，那么应该会在面试你的人名单里找到我的名字。你现在就有点紧张了，（好啦，别不好意思）面试总会让人感觉有点不舒服。作为面试官，我其实并不算难对付，但如果你想在我们谈话之后让我放你过关，你确实得做一些必要的准备。

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


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


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


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


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


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


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


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

没错，我确实希望将来有可能被我面试的所有人都看到这篇文章。我希望你能在我面试你时表现得非常好，真的，确实如此。说来也简单，只要你留意上述这些常见的问题，并且原原本本地展示你自己就足够了。说不定哪一天，你就会跟我坐到同一间办公室里了。
注意，My Yahoo!团队正在招聘呢。如果你是一位有才华的软件工程师，又对创造价值和Yahoo!公司充满激情，请跟我联系，咱们谈谈。
延伸阅读

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


Nicholas C. Zakas的书











]]></description>
		<link>http://www.cn-cuckoo.com/2010/01/09/surviving-an-interview-with-nicholas-c-zakas-1346.html</link>
			</item>
	<item>
		<title>Nicholas C. Zakas如何面试前端工程师</title>
		<description><![CDATA[Original Post：Interviewing the front-end engineer
Nicholas C. Zakas，2010年1月5日
翻译完成：2010年1月7日，最后更新：2010年1月10日
面试前端工程师对我来说是一件非常有意思的事，因为面试过程很大程度上也是自我提升的过程。无论大公司还是小公司，之所以在如何招聘到真正有能力的前端工程师方面会遇到同样的问题，就是因为负责招聘的那些人不知道自己公司需要什么样的人，结果问问题时也问不到点子上。经过这几年在行业里的摸索，我总结出了自己的一套很有效的面试前端工程的方法。
有的应聘者说我不好对付，但留给他们这样的印象也并非我所愿。我觉得之所以他们说我不好对付，主要是因为我问他们问题时问得太细了。以前我曾专门写过一些东西，告诉应聘者怎么才能通过我的面试以及怎样才能成为优秀的前端工程师应该具备什么样的素质，而我的面试可以说完全是按照那两篇文章的标准进行的。我不会问一些特别偏门的问题，也不认为出几道逻辑题就能考出人的真实水平。我唯一的想法就是确定你能否胜任我们要招的这个职位。为此，我需要简单地考察如下几个方面。
基本知识
我们生活在互联网时代，你想知道的任何事情几乎都能在15分钟内找到相关信息。可是，能找到信息并不等于你会使用它。我认为所有前端工程师至少都应该掌握某些基本的知识，才能有效地完成自己的工作。如果一遇到问题，就停下工作上网四处搜索解决方案，怎么可能保证按期完成工作呢？听听，还有谁在说“我不知道，但我可以上网搜到。”请这些同学把手举起来，让大家认识一下（immediately raises a flag for me.）。下面我列出一些基本的知识点，这些都是我认为一名前端工程师（无论工作年头长短）在没有任何外来帮助的情况下就应该知道的。

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

重申一下，上述这些知识点都应该是你“想都不用想”就知道的东西。我一开始问的所有问题都是想摸清你对所有这些领域知识的掌握程度。虽然上面列出的这些知识点并没有面面俱到，但我觉得你至少应该掌握这些，才有可能跟我坐到一间办公室里来。
少量提问
我非常赞同面试者问的问题越少越好。反复问应聘者各种问题既不公平，也很无聊。我在任何一次面试中，通常只问三个大问题，但每个问题又会涉及我所能想到的多个方面。回答每个大问题一般要经过几个步骤，这样我就可以在每个步骤中穿插着问一些小问题。比如说：
现在有一个正显示着Yahoo!股票价格的页面。页面上有一个按钮，你可以单击它来刷新价格，但不会重新加载页面。请你描述一下实现这个功能的过程，假设服务器会负责准备好正确的股票价格数据。
这个问题牵扯到一组我想要考察的基本知识点：DOM结构、DOM操作、事件处理、XHR和JSON。如果我要求你换一种处理股票价格的方式，或者让你在页面中显示其他信息，就可以把更多的知识点包括进来。对于经验比较丰富的应聘者，我也可以自如地扩展要考察的知识范围，最简单像JOSN与XML的区别、安全问题、容量问题，等等。
我还希望应聘者给出的任何解决方案中都不要使用库。我想看到最原生态的代码，你就当页面中没有包含任何库。你说你对哪个库了解多少多少，但我不能把关于库的知识作为评判能力的因素，因为库是会随时间变化的。我需要的是真正理解库背后的机制，特别是能够徒手写出一个自己的库的人。
解决问题
做为一名前端工程师，最值得高兴的事莫过于解决同一个问题会有很多种不同的方法，而你要做的就是找出最合适的方法来。我在提问的时候，经常会在应聘者解释完一种方法后问他们还有没有第二种方法。此时我会跟他们说，假设你的这个方法由于种种原因被否决了，那么你还能不能给出另一种方法。这样做可以达到两个目的。
首先，可以测试出他们是否在毫无意义地复述书本中的东西。不能不承认，某些人确实有过目不忘的天赋，听他们在那里滔滔不绝地讲，你会觉得他们什么都明白。可是，只要一跟这些人谈到怎么查找方案无效的原因，以及能否拿出一个新方案来，他们往往就傻眼了。这时候，如果我听到“我不明白这个方案为什么不够好”之类的反问，心里立刻就明白我的问题已经超出了他们的能力范围，而他们只是想拿自己死记硬背的结论来蒙混过关。
其次，可以测试出他们已经掌握的（还是那句话，“想都不用想”就知道的）浏览器技术知识。如果他们对浏览器平台的核心知识有较好的理解，想出解决同一问题的不同方案根本没有那么难。
对一名前端工程师来说，这绝对是最重要的能力。前端工程师在工作中遇到本该如此却并未如此的难题（说你啦，IE6），应该说是一件很平常的事。一个方案无效就无计可施的人，做不了前端工程师。
考核应聘者解决问题能力的另一层原因，与我的个人喜好有关。在搞清楚应聘者知道什么不知道什么之后，我就会想着问一个他们知识领域之外的问题。这样做的目的，就是想看看他们怎样运用已有的知识解决新问题。在解决问题的每一步，我也准备了一些提示，以防有人会卡壳打艮（在我面前15分钟一言不发，对我评价这个人毫无帮助）。我真正感兴趣的，是他们能够从上一步前进到下一步。我希望看到一个人就在我眼前学到新知识。
注意：所有问题都与浏览器技术相关。我不相信出几道抽象的逻辑题，就能够考出某人解决Web技术问题的能力。在我看来，这无异于让素描大师画肖像（或者让刘翔跟博尔特同场竞技），没有意义，也得不到任何有价值的信息。
有激情
要成为一名优秀的前端工程师，最重要的莫过于对自己做的事要有激情。我们的技能都不是从学校中或者研讨会上学来的，因此前端工程师必须具备自学能力。浏览器技术的变化可谓日新月异，所以也只有不断提升自己的技能才做得到与时俱进。我虽然不能强迫谁必须多看博客、不断学习，但想应聘前端工程师的人恐怕还是必须得这么做。
你怎么知道谁对这种工作有没有激情？实际上非常简单。我只问一个简单的问题：“目前你对什么Web技术最感兴趣？”这个问题永远不会过期，而且也几乎不可能出错……除非你答不上来。就眼下来说，我希望你对这个问题给出的技术中包括WebSocket、HTML、WebGL、客户端数据库，等等。只有对Web开发充满激情的人，才会坚持不懈地学习新知识、掌握新技能；这些人才是我真正想要的。当然，我会让他们详细解释自己提到的技术，以保证他们不是随口念叨了几个时髦的新词汇。
最后一点
计算机科学或者Web设计方面的知识当然也有用，但那都是基本知识之外的东西。只要基本知识在那儿了，一切就都有了基础，想扩充知识面也不难。可是，如果等到正式上班以后，还得从头学习基本技能，那种难度是不可同日而语的。另外，高级前端工程师与一般工程师相比，肯定需要掌握更多的技能。而面试几乎没有经验的大学毕业生，我也会有一套完全不同的程序。我在这篇文章里列出来的都是一些最基本的东西。
对于那些还没有多少面试经验的人，我总是喜欢告诉他们，面试完了只要问自己一个问题就行：你想以后跟这个人在一起共事吗？如果不管为什么，回答是不，那就是不。
免责声明：本文的任何观点与意见都只跟Nicholas C. Zakas有关，与Yahoo!公司、Wrox出版公司、O&#8217;Reilly出版公司乃至其他任何人无关。我在这里说的话，仅代表我自己，不代表上述公司。
你可以在这里留言，也可以在你自己的站点上发送一个引用通告。

延伸阅读

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


Nicholas C. Zakas的书











]]></description>
		<link>http://www.cn-cuckoo.com/2010/01/08/how-nicholas-c-zakas-interviewing-the-front-end-engineer-1332.html</link>
			</item>
	<item>
		<title>命名函数表达式探秘</title>
		<description><![CDATA[函数声明与函数表达式的有什么区别？
命名函数表达式的语义及其适用场景有哪些？
JScript、WebKit在实现命名函数表达式时“创造”了哪些bug？
SpiderMonkey在实现命名函数表达式是如何对规范“言听计从”的？
请看
命名函数表达式探秘
原文链接：http://yura.thinkweb2.com/named-function-expressions/
本文链接：http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html
Table of Contents

前言
函数表达式与函数声明
函数语句
命名函数表达式
调试器中的函数名
JScript的bug
JScript的内存管理
测试
Safari中存在的bug
SpiderMonkey的怪癖
解决方案
替代方案
WebKit的displayName
对未来的思考
致谢

]]></description>
		<link>http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html</link>
			</item>
	<item>
		<title>仿真器和模拟器辨析</title>
		<description><![CDATA[今天抽时间专门研究了一番仿真器（emulator）和模拟器（simulator），分析过程就不写了，下面直接给出结论；有不明白的地方，可以再看参考文献和网络词典及维基的释义。
仿真器，指的是几乎能够百分之百地模拟某硬件或软件系统的全部特性、行为的装置或程序。
 模拟器，指的是仿照真实的硬件、软件、环境、条件，能够在某种程度上再现这些硬件、软件、环境、条件的装置或程序。
仿真是尽可能做到全方位的模拟，而且力求逼真，有点欲将原型或模仿对象取而代之的味道。仿真更具体，接近实物（也有说接近硬件的，但肯定不局限于硬件）。
模拟只是表面上做做样子，不会有真实的过程发生；但能够给出反馈，多用于研究和培训。模拟更抽象，侧重建模。
当然，也会存在模拟器与原型的近似程度堪与仿真器媲美的情况，但它们的区别还是十分明显的，那就是模拟不够“真实”，而仿真非常接近“真实”。
在参考文献中“记性不好，所以写写”的原话基础上稍作修改，可以说：
如果原型是一个人，那么仿真就是克隆一个新人（这个人的言行举止与原型几乎一模一样），模拟就是把这个人生活中的某一段录成视频（能够据以建模）。
参考文献
1.海之雁 《仿真专业词义辨析之一——模拟与仿真》
2.记性不好，所以写写《Simulation &#38; Emulation》
3. 丁刚 《详述软件开发中模拟器与仿真器的区别》
词典及维基
《韦伯斯特在线词典》
Emulate
Verb
1. Strive to equal or match, especially by imitating; &#8220;He is emulating the skating skills of his older sister&#8221;.
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; &#8220;This artists&#8217;s drawings cannot emulate [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/12/08/emulator-and-simulator-1300.html</link>
			</item>
	<item>
		<title>布兰登·艾奇谈JavaScript的流行</title>
		<description><![CDATA[原文地址：http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html
看来（根据一位专家的说法是这样，不过还是感觉有点言不由衷），JavaScript最后真的流行起来了。
[此处是youtub.com中一段视频，可惜被"墙"了]
对我这个从小就呆头呆脑的人来说，这段视频像是咒语又像是玩笑。（这要看你是否跟我站在了相同的立场上：绿壳鸡蛋不就流行过吗？）
布兰登·艾奇深得他那尖脑壳老板的信任，Navigator浏览器应该有自己的脚本语言，只有开发一门新语言才可行，必须在短时间内设计和实现这门语言，现有的任何语言都不能充当该角色。
我搞不清楚为什么道格（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”：
&#60;script src=&#8221;http://my.edge.cached.startup.com/dojo-1.0.0.js&#8221;
        shared=&#8221;http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js&#8221;&#62;
&#60;/script&#62;
如果浏览器首先下载了共享的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好像也会流行的， 它的空间与时间性能测试预示了这一点。相关内容呢，我以后还会陆续地谈到。
]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/29/brendan-eich-talk-the-popularity-o-javascript-1294.html</link>
			</item>
	<item>
		<title>觉道庄</title>
		<description><![CDATA[青云观位于河北青县城东觉道庄村，距天津市七十五公里，观内有15座殿堂，供奉十尊神像，总占地面积一方平万米，是华北平原上历史最悠久的道观。相传春秋战国时期，老子李耳弃周守藏室史官而走，云游四方至此地隐居，德高望重的老子传经布道，救苦救难，民众相聚而居，逐渐形成村落，起名为道德庄。沧桑变迁，元初．老子分神化气，重降此庄，名为张核，道号觉道，村更名为觉道庄，觉道大师积功德，四处化缘，在原老者君讲经道场营造起一座颇有影响的道观青云观，从此,觉道庄就成了道教圣地，村周围先后建起了碧霞庵、五龙圣母庙等道观，历史上曾在此涌现出颇有道诣的道师和法师。
]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/27/jue-dao-zhuang-1284.html</link>
			</item>
	<item>
		<title>反劫持：格杀1188.com</title>
		<description><![CDATA[昨天，儿子下载了一款名叫“主题医院”的游戏，在安装了该游戏之后，电脑中的Chrome和IE就被1188.com劫持了：
1、桌面上多出来两个IE快捷方式图标，无法删除；
2、快速启动区IE和Chrome快捷方式的目标被篡改，追加了http://www.1188.com/?8后缀（见下图），无法修改；
3、注册表中多了一些带有1188.com的键值。
经过搜索并试验广大受害网友克敌方法，我总结出了比较简单易行的“反劫持”作战方案：
1、“开始&#62;运行”，输入regedit，打开注册表编辑器，Ctrl+F，搜索“1188.com”，对搜索到的键一律格杀勿论——全都删掉；
2、由于无法修改快速启动区被篡改的IE和Chrome快捷方式，因此需要把它们先拖到桌面上，然后删除；
3、桌面上多出来的IE快捷方式也不能删除，但可以通过Windows自带的“桌面清理”工具将它们删掉，具体步骤如下：
在桌面上右键单击，然后“属性&#62;桌面&#62;自定义桌面&#62;现在清理桌面”，在打开的“清理桌面向导”中点“下一步”，然后在“快捷方式”区域选中桌面上多出来的那两个IE快捷方式，然后“下一步&#62;完成”（见下图）。
4、由于删除了快速启动区的浏览器快捷方式，所以需要自己找到浏览器的安装目录，重新创建——这个不用说都会吧。
事实上，如果这个1188.com只是劫持浏览器，建俩快捷方式，那除了恶心恶心人，让自己臭名远扬以外，也没有什么大不了的，顶多用上述方法“反劫持”罢了。但令人担心的是，如果除此之外，1188.com还会做一些不为人知的事，比如给电脑植入木马病毒，盗窃账号密码等信息，那么用户就会面临着巨大的危险——在网上也看到有人说这个网站不能访问，更能不从中下载任何东西。
昨天，儿子下载了一款名叫“主题医院”的游戏，在安装了该游戏之后，电脑中的Chrome和IE就被1188.com劫持了：
1、桌面上多出来两个IE快捷方式图标，无法删除；
2、快速启动区IE和Chrome快捷方式的目标被篡改，追加了http://www.1188.com/?8后缀（见下图），无法修改；

3、注册表中多了一些带有1188.com的键值。
经过搜索并试验广大受害网友克敌方法，我总结出了比较简单易行的“反劫持”作战方案：
1、“开始&#62;运行”，输入regedit，打开注册表编辑器，Ctrl+F，搜索“1188.com”，对搜索到的键一律格杀勿论——全都删掉；
2、由于无法修改快速启动区被篡改的IE和Chrome快捷方式，因此需要把它们先拖到桌面上，然后删除；
3、桌面上多出来的IE快捷方式也不能删除，但可以通过Windows自带的“桌面清理”工具将它们删掉，具体步骤如下：
在桌面上右键单击，然后“属性&#62;桌面&#62;自定义桌面&#62;现在清理桌面”，在打开的“清理桌面向导”中点“下一步”，然后在“快捷方式”区域选中桌面上多出来的那两个IE快捷方式，然后“下一步&#62;完成”（见下图）。

4、由于删除了快速启动区的浏览器快捷方式，所以需要自己找到浏览器的安装目录，重新创建——这个不用说都会吧。
事实上，如果这个1188.com只是劫持浏览器，建俩快捷方式，那除了恶心恶心人，让自己臭名远扬以外，也没有什么大不了的，顶多用上述方法“反劫持”罢了。但令人担心的是，如果除此之外，1188.com还会做一些不为人知的事，比如给电脑植入木马病毒，盗窃账号密码等信息，那么用户就会面临着巨大的危险——在网上也看到有人说这个网站不能访问，更能不从中下载任何东西。
]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/25/anti-hijacking-kill-1188-com-1281.html</link>
			</item>
	<item>
		<title>翻译CSS之父论文《层叠样式表》</title>
		<description><![CDATA[提示：由于目前正在抓紧时间翻译Professional JavaScript, 2nd，预计春节之前没有时间翻译这份论文了。对自己，也对大家，更对“CSS之父”说声抱歉吧！
中文链接：www.cn-cuckoo.com/css/thesis-of-Hakon-Wium-Lie/
原文链接：people.opera.com/howcome/2006/phd/

翻译进度列表：

2009-1-7，“灵感”
2009-11-1，“第1章 导言”


Håkon Wium Lie出生于1965年7月26日，是土生土长的挪威人。现为Opera Software的CTO（Chief Technology Officer，首席技术官）。他的个人页面、维基百科词条。
1994年，Håkon Wium Lie提出了层叠样式表的概念，并于当年10月提交了他的样式表建议——Cascading HTML style sheets。1996年12月，他亲自主持并以他的建议为基础创建的Cascading Style Sheets, level 1，正式成为W3C的推荐标准。后来，几乎所有主要浏览器都实现了CSS。CSS的普及，结束了长达数年之久的“表现性HTML”的历史，开创了标准Web开发中结构、表现、行为分离的新时代。
1995年， Håkon Wium Lie针对测试Web浏览器在呈现HTML标记、CSS2.1样式、PNG图像及数据URI方面的支持情况，提出了Acid2建议。该建议后来由Web标准组织开发并发布，成为判定新（版）浏览器对Web标准支持情况的一个重要依据。
另外，Håkon Wium Lie与另一位CSS标准的制定者Bert Bos合著的Cascading Style Sheets: Designing for the Web, 3rd Edition 2005年5月由Addison-Wesley Professional出版。也是学习CSS的一本优秀图书。这里还有一篇发表于A List Apart的他们合写的文章：Printing a Book with CSS: Boom!
总而言之，翻译这篇论文的想法由来已久了。原因很简单，这篇论文是Håkon Wium Lie在他提出CSS的建议10年后写就的，其中全面翔实地包含了大量与CSS及Web发展有关的珍贵资料，是研究和学习CSS不可多得的重要参考文献。翻译这篇论文的过程，也是学习和研究的过程。希望自己在翻译完这篇论文后，对CSS和Web的理解能上升到一个新的层次。
]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/16/translating-thesis-of-hakon-wium-lie-1270.html</link>
			</item>
	<item>
		<title>现代CG动画生产流程</title>
		<description><![CDATA[来自“首届中国动漫艺术大展”（中国美术馆2009.10.26～11.18）
《中国原创漫画产业化创作流程》
总体流程
剧本创作
美术设计
模型塑造
镜头设计
动画创作
特效渲染
后期输出
总体流程

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


]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/14/modern-computer-graphic-cartoon-production-flow-1250.html</link>
			</item>
	<item>
		<title>中国原创漫画产业化创作流程</title>
		<description><![CDATA[来自“首届中国动漫艺术大展”（中国美术馆2009.10.26～11.18）
《现代CG动画生产流程》

]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/14/china-orignal-cartoon-creation-process-1246.html</link>
			</item>
	<item>
		<title>《Web界面设计》读者评论</title>
		<description><![CDATA[
想知道怎样在今天的Web上创造伟大的用户体验吗？UI专家Bill Scott和Theresa Neil通过本书向读者展示了超过75种基于富交互构建Web界面的模式。作者以自己在Sabre、Yahoo!和Netflix多年的工作经验为依托，把精挑细选的各种最佳实践归结为6个重要原理，深入浅出地向读者阐释了如何有效利用当前的Web技术。本书每一部分都围绕一个设计原理展开讨论，通过学习本书，读者可以掌握以下原理。
直截了当：通过页内编辑、拖放和直接选择等模式实现基于上下文的内容编辑。
简化交互：借助“轻量级”上下文工具，有效减少用户与站点的不必要交互。
足不出户：采用覆盖层、嵌入层、动态内容和页内流程模式保证访问者不离开当前页面。
提供邀请：向用户发出进入下一级交互的邀请，帮助用户发现站点的功能。
巧用变换：学习何时、何地、以何种方式使用动画、电影转场效果及其他变换手段。
即时反应：以实时搜索、实时建议、实时预览及更多模式，为用户提供丰富的交互式体验。
本书以当前最流行的Web站点为例，介绍了大量行之有效的Web界面设计模式。如果你想构建或重构站点，并希望站点以丰富的交互为特色，那本书就是你出奇制胜的宝典。
“本书提供了富因特网应用程序（RIA）设计人员和开发人员（或开发团队）作出明智选择时必须知道的一切。对于当今主流的Web设计师而言，（本书）应该人手一册。”
——Erin Malone，Tangible UX负责人
当当网读者评论
读者：Drek
来自：广州市
标题：很多新的，流行的理念
评分：4星
发表于 2009-10-11 23:53
我是个程序员，可惜在的公司太小，美工，前台，后台，设计，样式都要一手包办。其实挺郁闷的，为了在点脱离这情况，学多点广博的知识，早日飞翔，成就梦想。
而涉及到的知识都要去看，去学。
界面也要自己去处理。所以看到了本书，站在一个程序员的角度考虑，里面的设计思想其实很潮的。没有你想不到，只有你做不到的。书是针对界面设计，没有任何提及程序，代码如何实现的，也没有提及美工方面如何处理的。
可以说同一个设计相思，可以用不同东西去实现，只要你会的。
所以感觉如果作为程序员，又要考虑界面设计的朋友，本书值得一看。如果就美工和单纯是界面设计的，也给予了你不同的设计思想。
当然，世事没有完美的，程序，界面或者流行一时，2，3年间也许变化很大，为了适应自己的工作，或者适应这个时代，可以得到的资源都不要放过哦
读者：斯泰普斯
来自：上海
标题：赏心悦目
评分：5星
发表于 2009-09-11 09:16
书不错，材质也不错，很有手感。
价格比china-pub贵几块，但我还是等待当当出来才买的。
是一本值得收藏的借鉴的书。
个人推荐。
注：可结合另一本《网站优化》一同阅读。
http://product.dangdang.com/product.aspx?product_id=9345032
卓越亚马逊读者评论
读者：微微
来自：
标题：设计手段与模式
评分：5星
发表于2009-09-08 10:31:23
大凡设计师都是这样来的：先学会对付细节问题，然后尝试系统解决，最后学会总结问题与应对手段。
这本书讲述了6个界面设计原理，对应14种设计模式，以及提供了超过70种具体设计手段。
书中的实例来自flickr, yahoo, google等国外比较大型的网站，部分细节已经不复存在。刚好，你可以通过观察现在的设计，对比书中留存的旧时实例，去思考背后的设计思路。
模式和具体手法都是在不停变化的。
读完这本书，希望大家可以总结出自己网站适用的新的手段、模式。
目录
序
前言
原理一：直截了当
第1章：页内编辑
1.1 单字段行内编辑
1.2 多字段行内编辑
1.3 覆盖层编辑
1.4 表格编辑
1.5 群组编辑
1.6 模块配置
1.7 选择编辑模式的原则
第2章：利用拖放
2.1 趣味瞬间
2.2 拖放的用途
2.3 拖放模块
2.4 拖放列表
2.5 拖放对象
2.6 拖放操作
2.7 拖放集合
2.8 实现拖放的挑战
第3章：直接选择
3.1 切换选择
3.2 集合选择
3.3 对象选择
3.4 混合选择
原理二：简化交互
第4章：上下文工具
4.1 上下文交互
4.2 费茨定律
4.3 上下文工具
4.4 实时可见工具
4.5 悬停即现工具
4.6 开关显示工具
4.7 级联递进工具
4.8 二级菜单
原理三：足不出户
第5章：覆盖层
5.1 对话框覆盖层
5.2 详情覆盖层
5.3 输入覆盖层
第6章：嵌入层
6.1 对话框嵌入层
6.2 列表嵌入层
6.3 详情嵌入层
6.4 标签页
6.5 嵌入层与覆盖层
第7章：虚拟页面
7.1 虚拟滚动
7.2 内置分页
7.3 滚动分页：传送带
7.4 虚拟摇摄
7.5 伸缩式用户界面
7.6 分页与滚动
第8章：流程处理
8.1 Google Blogger
8.2 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/09/reviews-for-designing-web-interfaces-1238.html</link>
			</item>
	<item>
		<title>MySQL数据类型</title>
		<description><![CDATA[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 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/07/mysql-data-type-1230.html</link>
			</item>
	<item>
		<title>欢迎Goolge Clouse Tools开源</title>
		<description><![CDATA[今天（最早在Solidot.com看到，据这里说是今天），Google开发Gmail、Google Docs、Google Maps使用的前端开发工具开源了！
Google Code没有提供Clouse Library（JavaScript库）的打包下载，因此需要使用subversion客户端工具取出（check out）所有文件。我使用的是slik subversion，Google还给用户提供了一大堆subversion客户端工具。取出速度快得有点令人惊讶，几分钟就下载了126M。
svn checkout http://closure-library.googlecode.com/svn/trunk/ closure-library-read-only
Web applications have evolved from simple HTML pages into rich, interactive applications that provide a great user experience. Today&#8217;s web apps pose a challenge for developers, however: how do you create and maintain efficient JavaScript code that downloads quickly and works across different browsers?
The Closure tools [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/06/welcome-google-clouse-tools-opened-1218.html</link>
			</item>
	<item>
		<title>《jQuery基础教程（第2版）》也出版了</title>
		<description><![CDATA[
本书作为《jQuery基础教程》的升级版，涵盖了 jQuery 1.3的全部新特性，特别是新增了介绍 jQuery UI（jQuery官方用户界面插件库）的内容。本书前 6章以通俗易懂的方式介绍了 jQuery的基本概念，主要包括 jQuery的选择符、事件、效果、DOM操作、AJAX支持等。随后 3章从理论到实践，通过表格操作、构建功能型表单、实现滑移和翻转效果等实例，深入浅出地讲解了如何创造性地运用 jQuery提供的丰富而强大的 API。本书最后两章专门介绍了如何使用和编写 jQuery插件。值得一提的是，本版新增的附录 D分门别类地列出了所有 jQuery API，为高效使用 jQuery提供了方便。
本书内容
第1章将带领读者对jQuery有个大概的了解。这一章先简单介绍jQuery及其用途，然后的内容主要涉及如何下载和设置jQuery库，同时也会指导你使用jQuery编写第一个脚本。
第2章讲述如何通过jQuery中的选择符表达式及DOM遍历方法，在页面中的任何地方找到想要的元素。这一章将展示如何使用各种选择符表达式为页面中的不同元素添加样式，其中一些是通过纯CSS方式做不到的。
第3章介绍如何通过jQuery的事件处理机制，在浏览器发生事件时触发行为。同时，还会介绍如何以不唐突的方式添加事件（甚至在页面加载完成之前）。此外，这一章还将深入更高级的主题，例如事件冒泡、委托和命名空间。
第4章介绍通过jQuery实现动画的技术，从中我们能够体会到隐藏、显示和移动页面元素时那种轻松自如的感觉。
第5章讲述如何通过命令改变页面。本章讲述的是动态修改HTML文档结构及其内容的技术。
第6章讨论通过jQuery轻松地访问服务器端功能的各种方法，而且不用像过去那样刷新页面。
接下来3章（第7、8、9章）主要以实例为主，即在前几章学习的基础上，创建常见问题的稳健jQuery解决方案。
第7章“表格操作”，讲述排序、筛选和为信息添加样式并创建优美实用的数据布局。
第8章“创建功能性表单”以客户端数据验证为主题。届时，将设计一个具有适应能力的表单布局，还会实现基于客户端与服务器通信的交互式表单功能，例如自动完成。
第9章“滑移和翻转”介绍如何在显示页面元素时增强它们的美感和实用性。其中，动态显示和隐藏信息的方式既可以是自动的，也可以是用户控制的。
第10和11章的主题是jQuery库的第三方扩展，将向读者展示扩展这个库的各种方式。
第10章“使用插件”介绍Form插件和官方用户界面插件集合jQuery UI。同时，还将介绍到哪里寻找其他流行的jQuery插件并了解它们的功能。
第11章“开发插件”将讨论如何利用jQuery强大的扩展能力，从头开发自己的插件。不仅包括创建自己的实用函数，还有添加jQuery对象方法、添加自定义选择符表达式，等等。
附录A“在线资源”提供了很多与jQuery、JavaScript以及通常的Web开发有关的内容丰富的网站信息。
附录B“开发工具”推荐了一些有用的第三方程序和实用工具，用于在个人的开发环境中编辑和调试jQuery代码。
附录C“JavaScript闭包”将帮助读者理解闭包——什么是闭包，怎么利用闭包。
附录D“快速参考”提供了jQuery的简明参考，包括所有方法和选择符表达式。在实际开发中，在明确自己目标的情况下，通过这个简单明了的附录，能够方便快捷地找到正确的方法和选择符。
本书内容
第1章将带领读者对jQuery有个大概的了解。这一章先简单介绍jQuery及其用途，然后的内容主要涉及如何下载和设置jQuery库，同时也会指导你使用jQuery编写第一个脚本。
第2章讲述如何通过jQuery中的选择符表达式及DOM遍历方法，在页面中的任何地方找到想要的元素。这一章将展示如何使用各种选择符表达式为页面中的不同元素添加样式，其中一些是通过纯CSS方式做不到的。
第3章介绍如何通过jQuery的事件处理机制，在浏览器发生事件时触发行为。同时，还会介绍如何以不唐突的方式添加事件（甚至在页面加载完成之前）。此外，这一章还将深入更高级的主题，例如事件冒泡、委托和命名空间。
第4章介绍通过jQuery实现动画的技术，从中我们能够体会到隐藏、显示和移动页面元素时那种轻松自如的感觉。
第5章讲述如何通过命令改变页面。本章讲述的是动态修改HTML文档结构及其内容的技术。
第6章讨论通过jQuery轻松地访问服务器端功能的各种方法，而且不用像过去那样刷新页面。
接下来3章（第7、8、9章）主要以实例为主，即在前几章学习的基础上，创建常见问题的稳健jQuery解决方案。
第7章“表格操作”，讲述排序、筛选和为信息添加样式并创建优美实用的数据布局。
第8章“创建功能性表单”以客户端数据验证为主题。届时，将设计一个具有适应能力的表单布局，还会实现基于客户端与服务器通信的交互式表单功能，例如自动完成。
第9章“滑移和翻转”介绍如何在显示页面元素时增强它们的美感和实用性。其中，动态显示和隐藏信息的方式既可以是自动的，也可以是用户控制的。
第10和11章的主题是jQuery库的第三方扩展，将向读者展示扩展这个库的各种方式。
第10章“使用插件”介绍Form插件和官方用户界面插件集合jQuery UI。同时，还将介绍到哪里寻找其他流行的jQuery插件并了解它们的功能。
第11章“开发插件”将讨论如何利用jQuery强大的扩展能力，从头开发自己的插件。不仅包括创建自己的实用函数，还有添加jQuery对象方法、添加自定义选择符表达式，等等。
附录A“在线资源”提供了很多与jQuery、JavaScript以及通常的Web开发有关的内容丰富的网站信息。
附录B“开发工具”推荐了一些有用的第三方程序和实用工具，用于在个人的开发环境中编辑和调试jQuery代码。
附录C“JavaScript闭包”将帮助读者理解闭包——什么是闭包，怎么利用闭包。
附录D“快速参考”提供了jQuery的简明参考，包括所有方法和选择符表达式。在实际开发中，在明确自己目标的情况下，通过这个简单明了的附录，能够方便快捷地找到正确的方法和选择符。
]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/04/learning-jquery-1-3-has-published-1212.html</link>
			</item>
	<item>
		<title>《PHP经典实例（第2版）》出版了</title>
		<description><![CDATA[
本书能够为您节省宝贵的Web开发时间。有了这些针对真实问题的解决方案放在手边，大多数编程难题都会迎刃而解。
今天，用PHP开发的2000万个网站充分表明，PHP已经成为一门最流行的脚本语言。本书将PHP的特性与经典实例丛书的独特形式组合到一起，足以帮您成功地构建跨浏览器的web应用程序。在这个修订版中，您可以更加方便地找到各种编程问题的解决方案，本书中内容涵盖了：

表单处理
session管理
数据库交互
使用Web 服务

从初学者常见的问题到高级Web编程技术，这本问题指南中包含了丰富的、具有实际应用价值的实例，可以满足使用PHP生成动态Web内容的任何人的需要。书中的每个实例都细致地讨论了所提供解决方案背后的逻辑和思想，用源自PHP专家的洞察力帮你轻松地掌握这门语言。书中更新了PHP5的有关内容，并详细地解释了如何使用新增的语言特性，比如面向对象能力的巨大改进和新的PDO数据访问扩展等。书中特别增加了有关类和对象的部分，包含了以下基本内容：

处理XML
与JavaScript交互
用PHP构建Web 服务
使用SOAP和REST架构

《PHP经典实例（第二版）》中超过250个实例，为你每天都要面对的诸多问题提供了足够丰富的解决方案。而且，每个实例的讨论部分都浸透着对每个PHP开发人员极为有益的理念。
David Sklar 是Ning的一名软件开发人员。在1996年发现PHP能够满足他编写web编程需要的时候，他创建了PX（http://px.sklar.com），这是一个可以让PHP用户交换程序的场所。此外，他还是《Learning PHP5》（O’Reilly）和《Essential PHP Tools》（Apress）的作者。
Adam Trachtenberg 是eBay的一名技术讲师，也是《Upgrading to PHP5》（O’Reilly）的作者。他经常会在O’Reilly Conference和LinuxWorld上发表演讲。他还拥有科伦比亚大学商学院的MBA学位。
前言
第1章字符串
第2章数字
第3章日期和时间
第4章数组
第5章变量
第6章函数
第7章类和对象
第8章Web基础
第9章表单
第10章访问数据库
第11章Session和数据保持
第12章XML
第13章Web自动化
第14章消费Web服务
第15章建立Web服务
第16章互联网服务
第17章图形
第18章安全和加密
第19章国际化和本地化
第20章错误处理，故障排除和测试
第21章性能调谐和负载测试
第22章正则表达式
第23章文件
第24章目录
第25章命令行PHP
第26章PEAR和PECL
]]></description>
		<link>http://www.cn-cuckoo.com/2009/11/04/php-cookbook-2n-has-published-1201.html</link>
			</item>
	<item>
		<title>庄绎传漫谈翻译（十二）翻译意思</title>
		<description><![CDATA[翻译意思，而不要翻译字，这在原则上，大家都会同意的。但在实际工作中却不尽然。有时我们会把注意力过多地集中在原文的字面上，并不深入思考原作者要表达的是什么意思，翻译起来就参照原文的说法，把英文词换上汉字，稍微调整一下顺序就完事了。这样的译文，不是歪曲原意，就是词不达意，或者听着别扭，不像中文。
我在高教自考《英汉翻译教程》一书中推荐过一位英国学者，名叫西奥多•萨沃里（Theodore Savory）。他在1957年发表的The Act of Translation 一书中写道：
A fair conclusion from these ideas is that the translator’s work may be analysed into the answering of three questions. Faced with a passage in its original language, he must ask himself:
(ⅰ) What does the author say?
(ⅱ) What does he mean?
(ⅲ) How does he say it?
This method of analysis may [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/10/28/zhuangyichuan-on-transloation-12-1192.html</link>
			</item>
	<item>
		<title>庄绎传漫谈翻译（十一）直译与意译</title>
		<description><![CDATA[直译与意译这两种不同的译法，自古有之。然而自五四以来，人们围绕着这两种译法进行了激烈的争论。
1922年，茅盾在“‘直译’与‘死译’”一文中写道：“近来颇有人诟病‘直译’；他们不是说‘看不懂’，就是说‘看起来很吃力’。我们以为直译的东西看起来较为吃力，或者有之，却决不会看不懂。看不懂的译文是‘死译’的文字，不是直译的。
1934年，茅盾在“直译•顺译•歪译’一文中写道：“‘直译’这名词，在‘五四’以后方成为权威。这是反抗林琴南氏的‘歪译’而起的。我们说林译是‘歪译’，可丝毫没有糟蹋他的意思；我们是觉得‘意译’这名词用在林译身上并不妥当，所以称它为‘歪译’。”
1980年，茅盾在《茅盾译文选集》序中回忆这一段往事，他写道：“后来有的译者随意增删原著，不讲究忠实原文的‘意译’，甚至‘歪译’，那就比林译更不如了。”
从以上情况看，在二三十年代，反对直译的人所反对的是看不懂或看起来吃力的译文；反对意译的人所反对的是随意增删原著、不讲究忠实原文的译文。
鲁迅也是积极主张直译的。
后来有人提出直译和意译是一回事，是无法区分的。
1946年，朱光潜在“谈翻译”一文中写道：“所谓‘直译’是指依原文的字面翻译，有一字一句就译一字一句，而且字句的次第也不更动。所谓‘意译’是指把原文的意思用中文表达出来，不必完全依原文的字面和次第。‘直译’偏重对于原文的忠实，‘意译’偏重译文语气的顺畅。哪一种是最妥当的译法，人们争执得很厉害。依我看，直译和意译的分别根本不应存在。……想尽量表达原文的意思，必须尽量保存原文的语句组织。因此直译不能不是意译，而意译也不能不是直译。”
1953年，林汉达在“翻译的原则”一文中写道：“正确的翻译是直译，也就是意译。死译和胡译不同，呆译和曲译不同，这是可以划分的，它们都是错误的翻译。正确的翻译是分不出直译或意译的。”
1959年，周建人为《外语教学与翻译》写了一篇文章，题目是“关于‘直译”’。他在文中写道：“直译既不是‘字典译法’，也不是死译、硬译，它是要求真正的意译，要求不失原文的语气与文情，确切地翻译过来的译法。换一句话说，当时所谓直译是指真正的意译。”
如果说四五十年代人们认为直译也就是意译，二者无法区分，那么到了七八十年代人们又对直译和意译分别作了分析。
1982年，周煦良在“翻译三论”一文中写道：直译可以分为三类：第一类是译音而不译意。如democracy译为“德谟克拉西”，而不译为“民主”。第二类是照字面译。如crocodile tears译作“鳄鱼的眼泪”，而不译作“虚伪的眼泪”。第三类是不按照中国语言习惯和词序而按照原文的结构或词序的翻译。如“‘你来了，’她说”。最后，他指出“这样一些直译好像为数不少，但就一篇文章，一部书来看，直译的成分毕竟是少数。”
1978年，许渊冲在“翻译中的几对矛盾”一文中也谈到直译与意译的问题，他说：“直译是把忠实于原文内容放在第一位，把忠实于原文形式放在第二位，把通顺的译文形式放在第三位的翻译方法。意译却是把忠实于原文的内容放在第一位，把通顺的译文形式放在第二位，而不拘泥于原文形式的翻译方法。”最后他得出五点结论，归纳成两点就是：一．译文和原文相同的形式能表达和原文相同的内容时，可以直译，不能表达时就意译；二．原文的表达形式比译文精确、有力时，可以直译，译文的表达形式比原文精确、有力时，可以意译。
1979年，王佐良在“词义•文体•翻译”一文中写道：“要根据原作语言的不同情况，来决定其中该直译的就直译。该意译的就意译。一个出色的译者总是能全局在胸而又紧扣局部，既忠实于原作的灵魂。又便利于读者的理解与接受的。一部好的译作总是既有直译又有意译的：凡能直译处坚持直译，必须意译处则放手意译。”
从以上情况看，七八十年代的译者对直译和意译作了分析和比较，采取了兼容并蓄的态度。这说明当代的译者比二三十年代乃至四五十年代的译者在理论上都更加成熟了。
在国外，译界的同行也同样在这一方面进行探讨。英国剑桥大学乔治•斯坦纳教授主张意译。他在1975年发表的After Babel一书中发挥了17世纪英国学者约翰•德莱顿关于意译的主张。他写道：“翻译的正确道路，既不应是直译，也不应是模仿，而应是意译(paraphrase)。所谓意译，就是‘译者有一定限度的自由，他要时刻看到作者，这样就不至于迷失方向，但他主要是紧跟作者的意思而不死扣字眼，他可以对作者的意思加以引伸，但不能改变。’据德莱顿说，这就是埃德蒙•沃勒和西德尼•戈多尔芬1658年翻译维吉尔的史诗《伊尼德》(Aeneid)第四卷时采取的方法。更重要的是，德莱顿本人翻译维古尔、贺拉斯、奥维德、朱文纳尔、乔叟等人的著作时，也采用了这种方法，在他评论 别人的译作时(如1685年出版的Sylvae一书的序言)所阐述的也是这种方法。通过意译，‘作者的精神可以得到传播，而不会遭受损失。’好的翻译好比是‘一种写生’。最理想的情况是，译作不剥夺原作的权威，而能向我们表明假如原作本来就是用我们的语言创作的，它会是个什么样子。”
国外还有一些学者表达了类似的看法。你同意他们这种看法吗？
]]></description>
		<link>http://www.cn-cuckoo.com/2009/10/21/zhuangyichuan-on-transloation-11-1187.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（十）怎样对待风格</title>
		<description><![CDATA[说起风格，也许有一种看不见、摸不着、虚无缥缈的感觉。“风格”究竟是什么呢？《现代汉语词典》的解释是：一个时代、一个民族、一个流派或一个人的文艺作品所表现的主要的思想特点和艺术特点。是不是只有文艺作品才有风格呢？
一
许多人写文章讨论翻译中的风格问题，倒也的确大都涉及文学作品的翻译。风格能不能译，大体上有两种意见。
一种意见认为风格是能译的。早在1922年茅盾就曾写道：“直译的意义若就浅处说，只是‘不妄改原文的字句’；就深处说，还求‘能保留原文的情调与风格’。”
1954年茅盾在全国文学翻译工作会议上的报告中说道：“文学的翻译是用另一种语言，把原作的艺术意境传达出来，使读者在读译文的时候能够像读原作时一样得到启发、感动和美的感受’。这样的翻译，自然不是单纯技术性的语言外形的变易，而是要求译者通过原作的语言外形，深刻地体会了原作者的艺术创造的过程，把握住原作的精神，在自己的思想、感情、生活体验中找到最适合的印证，然后运用适合于原作风格的文学语言，把原作的内容与形式正确无遗地再现出来。”
1980年茅盾在“《茅盾译文选集》序”中写道：“很重要的一点是能将他的风格翻译出来。譬如果戈理的作品与高尔基的作品风格就不同，肖伯纳的作品与同样是英国大作家的高尔斯华绥的作品的风格也不同。需将一个作家的风格翻译出来，这当然是相当困难的，需要运用适合于原作风格的文学语言，把原作的内容与形式正确无遗地再现出来。除信、达外，还要又文采。这样的翻译既需要译者的创造性，而又要完全忠实于原作的面貌。这是对文学翻译的最高要求。”
这个意见是有人支持的。1961年刘隆惠在“谈谈文艺作品风格的翻译问题”一文中写道：“对于文学翻译，不仅要求通顺流畅，而且要求表达原作的风格。”他还说：“我认为风格并不是不能译，而是难译。其所以难是在于译者必须具备两个条件。其一是要有认识风格的水平；其二是要有表现风格的能力。”

另一种意见认为风格是不能译的。1959年周熙良在“翻译与理论”一文中写道：“有人自诩翻译哪一个作家就能还出这个作家的面目或风格，我看这只是英雄欺人语；据我所知，就有翻译家对本文还不大能弄懂得，就大吹自己的翻译是旨在表现原作诗一般美丽的风格。依我看，对一个作家或者风格的认识也还是根据对作品本文的理解而来的，否则便是空话。教外国文学的人最喜欢谈风格，但是，对于一个搞实际翻译的人来说，风格却是一个最难谈得清楚的东西。我觉得，在通常情形下，它好像只是在无形中使译者受到感染，而且译者也是无形中把这种风格通过他的译文去感染读者的，所以既然是这样情形，我看就让风格自己去照顾自己好了，翻译工作者大可不必为它多伤脑筋。……我觉得翻译工作者如果要花许多功夫去钻研作品的风格，还不如花点功夫去培养自己的外语感受能力好些，因为翻译工作究竟是和语言文字打交道的工作，而语言却不止是数字符号那样抽象而无情的东西。”
二十多年以后，周熙良依然坚持自己的这一看法。1982年他在“翻译三论”一文中写道：“严复只提雅，而不提原文风格，我们现在提文学翻译要有风格，也不宜要求译出原文风格：原文风格是无法转译的。……我仍旧认为风格是无法翻译的，风格离不开语言，不同的语言无法表达同样的风格。”
这一种意见也是有人支持的。1961年张中楹在“关于翻译中的风格问题”一文中写道：“在同一语言的领域里，尚且不宜摹访一个作者的风格；在翻译方面，把原作译成另一种语言而要保持同一风格，这是更不易做到的工作。……我是极为赞同周熙良同志的‘不必多伤脑筋’的说法的。”
总起来看，持第一种意见的人较多，持第二种意见的人较少。我的看法是，第一种意见恐怕只是一种理想，未必能够达到，或者说很难实现；第二种意见又未免过于极端。
1979年罗新璋在“读傅雷作品随感”一文中说过这样一句话：“服尔德的机警尖刻，巴尔扎克的健拔雄快，梅里美的俊爽简括，罗曼罗兰的朴质流动，在原文上色彩鲜明，各具面貌，译文固然对各家的特色和韵味有相当体现，拿《老实人》的译文和《约翰•克利斯朵夫》一比，就能看出文风上的差异，但贯穿于这些译作的，不免有一种傅雷风格。”可见即使是名家的译作也难免既有原作的风格，又有译者的风格，而不可能是单纯的原作的风格。
二
翻译非文学作品，是否也有一个如何对待风格的问题呢？有的。
1979年，王佐良在“词义•文体•翻译”一文中说道：“一篇文章的风格只是作者为表达特定的内容而运用语言的个人方式，它与内容是血肉一体的，而不是外加的、美化的成分。”我的理解，这里所谓“一篇文章”泛指任何用文字写成的东西，非文学作品也不例外。在同一篇文章里，他还写道：“在翻译工作里，也必须注意语言与社会场合的关系。译文同样有一个适合社会场合的问题。译者同样必须能根据原文的要求，写出各种不同的语类、文体。例如翻译请贴、通知、布告、规章、病历与病情公告之类的“应用文体”，译者应该知道在译文里怎样寻到相等的内行的格式和说法。”
1982年，周熙良在“翻译三论”一文中写道：“实际上，许许多多的翻译只要文字通顺，就达到要求了，并不需要译成文学，也不可能译成文学。社会科学文章、报纸社论、科技文章、调查报告、都属这一类。”他还说：“美既不能用，雅又不能照严复当时提出的那样去理解，那么究竟应当怎样理解呢？我认为应当作为‘得体’来理解。得体不仅仅指文笔，而是指文笔基本上必须根据内容来定；文笔必须具有与其内容相适应的风格。”
我觉得，文学作品的风格可能因人而异，每个作家都有自己的风格。而非文学作品则往往是某种类型的文章具有一些共同的特点，形成这类文章的共同风格。无论是谁写作，都会采用这种风格。比如科学论文和法律文件，在用词方面力求准确，在表达方面力求清楚易懂，着重客观叙述，不带感情色彩，好像一个人在板起面孔来说话。而科普文章或普法读物则要使用生动的语言，灵活的句子，让读者觉着你在微笑着向他传授知识，或说明道理。用中文写文章是这样，用英文写文章也是这样，这两种语言是相通的。例如《世界版权公约》第二条第二款：
Unpublished works of nationals of each Contracting State shall enjoy in each other Contracting State the same protection as that other State accords to unpublished works of its own nationals, as well as the Protection specially granted by this Convention.
任何成员国国民未出版的作品，在其他各成员国中均享有后者给予其国民之未出版的作品同等的保护，并享有本公约所专门授予的保护。
这段译文既符合原文的风格，也符合中文法律条文共同的风格。如此说来，你看到文字如此谨严的原文时，只要译成同样谨严的文字就行了。所以，在风格问题上，翻译非文学作品比翻译文学作品简单多了。风格也不是那么虚无缥缈、不可捉摸了。你说是不是？
“对于我们并非专门从事文学翻译的初学者来说，在表达方面只要做到两点就够了。第一，能区别口语与书面语，该文的时候文，该白的时候白，翻译对话像对话，翻译叙述像叙述；第二，能根据不同的文体使用不同的语言，翻译新闻像新闻，翻译文件像文件，翻译故事像故事，翻译诗歌像诗歌。如果在正确理解原文的基础上，能使译文做到这两点，这就很不错了。”这段话是我在《英汉翻译教程》一书中提出的目标。你同意吗？
]]></description>
		<link>http://www.cn-cuckoo.com/2009/10/19/zhuangyichuan-on-transloation-10-1179.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（九）25点体会</title>
		<description><![CDATA[我在1984年出版的《英汉翻译练习集》前言中归纳了我在英译汉实践中的25点体会。其中绝大多数是我对英汉两种语言各自特点的认识。这些认识对我后来的工作，无论是英译汉，还是汉译英，都是有帮助的。现在我就把这25点体会连同有关的译例说一说。
⒈一词多义。弄清原文的意思，在汉语中选用适当的词语。例如：
Born in 1879 in Ulm, Germany, Albert Einstein was two years old when his parents moved to Munich, where his father opened a business in electrical supplies.
阿尔伯特·爱因斯坦于1879年出生在德国的乌尔姆城。在他两岁的时候，父母移居慕尼黑。他的父亲在慕尼黑开了一家工厂，生产电气器材。（句中business一词，据有关资料介绍是指factory，而不是store，故译作“工厂”。
⒉英语名词和介词用得多，汉语动词用得多。
Psychologically there are two dangers to be guarded against in old age. One of these is undue absorption in the past.
从心理方面来说，到了老年，有两种危险倾向需要注意防止。一是过分地怀念过去。（如译作“对过去的过分怀念”，则不顺。
⒊英语代词用得多，汉语实词用得多。在一个句子里，英语可以先出代词，后出实词；汉语则先出实词，后出代词。
One day, while I was playing with my new [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/21/zhuangyichuan-on-transloation-9-1070.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（八）英译汉：巧译定语</title>
		<description><![CDATA[我在审订译稿的时候发现，许多句子的译文不顺，究其原因，往往是定语没有处理好。在英语里，可以用作定语的成分很多。单词、从句、分词短语、介词短语、动词不定式，都可用作定语。单词作定语一般放在被修饰语前面，其他定语一般放在后面。汉语里，定语一般放在被修饰语前面。因此翻译时若把定语仍译成定语，而且仍放在前面，译文当然就不顺了。
定语如果不译成定语，又能译成什么呢？
关于定语从句的译法，已经看到不少文章。各种教程和专著中也有专门的章节加以论述。这里只举两个例子。
例1 The police are concerned for the safety of the 12-year-old boy who has been missing for three days.
那个12岁的男孩失踪三天了，警方对他的安全感到担忧。
例2 Each of London’s districts had a distinct character that marked it off from its neighbours.
伦敦的每个区都有鲜明的特征，与邻近地区不同。
例1的译文用了两个主谓结构，也可以说是两个并列短句。若译作“警方对那个已失踪三天的12岁男孩的安全感到担忧”，异文就因定语太长而不顺了。例2的译文用了一个主语带两个并列的谓语。总之，这两个例子，原文都是主从结构，而译文都是并列结构。这也正是英汉两种语言在句子结构方面最大的区别。
例3 Police investigating the train derailment have not ruled out sabotage.
警方调查火车出轨事件，没有排除人为破坏的可能。

例4 Any event attended by the actor received widespread media coverage.
这位演员参加任何一项活动，媒体都作了广泛报道。
例3和例4，原文各有一个分词短语*作定语：investigating&#8230;和attended by [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/20/zhuangyichuan-on-transloation-8-1068.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（七）英译汉：理解是关键</title>
		<description><![CDATA[英译汉，首先遇到的一个问题就是透彻地理解原文。
看一篇东西，可以有不同的目的。若为获取信息，抓住大意就可以了。
若是为了消遣，那就可以看懂多少算多少。若是为了翻译，那就非透彻理解原文不可。
有时似乎觉得懂了，但翻译起来还是不知如何下手，究其原因，可能仍是未能真正理解原文。在这种情况下，若勉强去译，便会采取机械的办法，逐字翻译，许多误译就是这样产生的。
例1  We want to get all the parties back to the negotiating table.
例2  Their differences have been thrown into sharp relief by the present crisis.
虽然party一词可以指“政党”，但此处与negotiating table相联系，便指“谈判的一方”了。所以，例1的意思是：我们想把有关各方拉回到谈判桌上来。Differences一词本身是有“差别”的意思，但在这个上下文里，它却指“意见分歧”。例2的意思是：目前的危机使得他们的分歧更加引人注目。
例3  He was found guilty of murder.
例4  There is no right of appeal against the decision.
涉及法律时，find不一定表示“发现”，而可以指“裁决”、“判决”。Appeal也不一定表示“呼吁”，而可以指“上诉”。因此，例3的意思是：经裁决，他犯有谋杀罪。例4的意思是：关于这项判决，没有上诉权。
例5  The end result of her hard work was a place at medical school.
例6  To [...]]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/19/zhuangyichuan-on-transloation-7-1066.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（六）信与达</title>
		<description><![CDATA[做事情都有个要求，希望达到什么样的标准。翻译也不例外。那么什么样的译文算是好的译文呢？我们应以什么样的标准作为努力的目标呢？
1980年出版了张培基等四位学者编著的《英汉翻译教程》。作者在“翻译的标准”一节中写道：“我们主张把翻译标准概括为‘忠实、通顺’四个字。”“所谓忠实，首先指忠实于原作的内容。”“忠实还指保持原作的风格。”“所谓通顺，即指译文语言必须通顺易懂，符合规范。”
1983年出版了吕瑞昌等五位学者编著的《汉英翻译教程》。关于翻译标准的论述，与第一本书是一致的。书中写道：“我们不妨用‘信、顺’两字来概括我们今天汉英翻译的标准。所谓‘信’是指忠实于原文的内容，包括思想、感情、风格等，即把原文完整而准确地表达于译文中，对原文内容尽可能不增不减。所谓‘顺’，是指用词正确得体，行文流畅通顺，符合英语习惯;避免逐字死译、生搬硬套，使不懂汉语的英语读者也能看懂。”
这两本书是受教育部委托编写的高校通用教材，一本讲英译汉，一本讲汉译英，二十多年来，一直在我国高校广泛使用。
我基本上同意这两本书关于翻译标准的提法，但我不赞成把风格放在忠实里面来谈。我们不必因为严复提出了“信、达、雅”，谈翻译标准就一定要谈风格。因为风格是一个比较复杂的问题。把原文的风格完全翻译过来，这恐怕是不大可能的，但也不是说风格就完全不能翻。译者只能尽力而为。译文的风格除了包含一部分与原文一致的风格，必然还包含其他因素。而且翻译不同类型的作品，对风格的要求也不尽相同。英译汉还比较好办，汉译英就更难把握了。

我在99年为全国高等教育自学考试编写了一套教材，题为《英汉翻译教程》。关于翻译标准，我是这样写的：“对我们初学翻译的人来说，我想可以提出两条要求：（一）忠实；（二）通顺。‘忠实’主要是指内容……要力求准确地表达原作者的意思。‘通顺’指的是语言。如果原文是通顺易懂的，那么译文也要尽量做到通顺、易懂。”我认为，真正做到上述两条，也并不容易。风格在翻译过程中是个不可回避的问题，但可以慢慢展开讨论，而不必写在翻译标准之中。
十多年前，我对外国译者关于翻译标准的看法作过一些探讨，写过一篇文章，题为“外国译者追求什么样的译文？”， 发表在《中国翻译》1992年第4期上。现将其中的部分引文介绍如下。
K. J. Maidment 在其所译Minor Attic Orators写的序言（1940）中说道：“关于译文本身，我只需要说我的目标一直是既确切（accurate）,又通顺(readable),但我充分意识到往往二者都没有做到。”
G. P. Goold 在为其所译Propertius的Elegies一书写的序言（1990）中说道：“我在本书中主要是力图以可靠的拉丁文本和优美、确切的（graceful and accurate）英译本把普洛佩提乌斯介绍给尽可能多的读者：当然首先是介绍给古典文学学者和研究人员，但也同样介绍给一般的文学爱好者。”（这个版本是拉丁文和英文对照本。）
Michael R. Katz and William G. Wagner 在为车尔尼雪夫斯基的《怎么办？》英译本写的前言（1989）中说道：“出版这个新译本，是为了提供方便，使英国和美国读者第一次看到车尔尼雪夫斯基的《怎么办》一书的完整译本……我们希望这个完整、确切、通顺的（complete, accurate and readable）译本能使英美读者不仅了解车尔尼雪夫斯基这本小说对人类生活产生了多大的影响，而且了解它推动历史前进的动力是从哪里来的。”
Ronald Hingley  在为其所译《契珂夫全集》写的序言（1964）中说道：“主要目的是为舞台演出提供脚本。译本一向以高度确切（strict accuracy）为宗旨，但希望避免学究气。译本从未有意识地为了字面上的忠实而使得台词不能上口，或违背原作的精神。”
Michael Grant在为其所译《西塞罗选集》写的前言（1960）中说道：“译者的主要任务之一是使译文通顺 (readable )，否则就没有人看，也就不能达到介绍原作者的目的。在今天如果译者使用修辞色彩很浓的英语，他的译文就不会通顺，也就没有人看。……西塞罗的修辞手段是他所受的语言训练的产物，是他的风格中不可分割的一部分。如果丢掉它，你就丢掉了人们最赞赏他的一个方面，损失还不止于此。如果保留它，我在前面已经指出，你就丢掉了另外一样东西－当代通顺的英语。这种进退两难的困境是没有折中办法可以解决的。因此，我既然不准备放弃努力，要尽可能地接近真正的现代英语，就不得不放弃西塞罗的修辞手段。至于读者遭受的损失，我是非常清楚的。”
Horace C. P. McGregor翻译了西塞罗所著《论神性》一书。他在“译者的话”（1970）中说道：任何一篇文章都包含着妥协的成分。一个句子在这种语言里通顺流畅，在另一种语言里就会拖沓累赘。一个精彩的短语如果按字面译成另外一种语言里就可能不像样子。一个单词在另一种语言里也可能难以找到相应的词。……我的目标是真正的翻译，然而是低标准的，我有一定程度的自由，可以改变原来的语言形式，但决不有意识地脱离原作的意思和语气。最主要的是我力图使西赛罗的英文译本和拉丁文原文一样通顺（readable）。
Edward G. Seidensticker翻译了紫式部的《源氏物语》。他在前言 (1976)中指出：此前Arthur Waley翻译的《源氏物语》是很自由的，他作了大胆删节，也作了大量的增补与美化。他说：“新译本可以称得上是个全译本，但其字数比Waley大加删节的译本还要少。这就说明无论Waley取得了多么精彩的效果。……他的节奏(rhythms)是与原作迥然不同的，原作较为明快、凝练，用词节省，不罗嗦。如果说翻译的目标应该在一切重要方面包括节奏在内模仿原作的话，那么这里提供的译文规定要达到的目标，可以说比Waley的译文所要达到的目标多得多。”
George Gihiam 在美国康奈尔大学任职，参加了Norton Critical Edition这套丛书的编辑工作。他在为陀思妥耶夫斯基的《罪与罚》英译本写的序言（1989）中写道：“我们选择《罪与罚》一书的英译本，标准是这个译本能用当代英语确切地(accurately)体现陀思妥耶夫斯基的十九世纪俄语原作，能用今天的英语表现出和原作相一致的风格(style)，不以现代词语或维多利亚时代的词语歪曲原作，而且译文本身是通顺的(readable)。根据这些原则，我们认为Jessie Coulson的译本似乎是最好的译本，经与牛津大学出版社接洽，在这里重印出版。”
从以上几段引文来看，accuracy和readability 是译者追求的共同目标。其他方面，各位译者的侧重点是不同的，风格、精神、修辞手段、语气、节奏，不一而足，有时甚至故意反其道而行之，可见问题之复杂。
鉴于以上情况，我们在开始时不妨就以信（忠实）和达（通顺）为目标吧。你觉得这两条会很容易做到吗？
]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/18/zhuangyichuan-on-transloation-6-1056.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（五）你做过语言对比吗？</title>
		<description><![CDATA[回忆我们学习汉语和英语的经历，就会发现我们是孤立地来学的。学汉语时，老师没有必要也从未鼓励我们去与英语做比较。学英语时，老师更是劝我们不要去与汉语比较，免得受汉语的影响而学不好英语。若让我们说一说汉语和英语有什么相同之处和不同之处，我们也许会感到茫然，因为我们从未对这两种语言加以比较。
翻译界有一个提法：翻译理论与实践。有人写书，以此为书名。有的学校开课，以此为课程名称。这个提法甚至进入了国家教育部门制定的学科目录。仿佛这个提法概括了翻译领域的全部内容。
其实，在翻译理论与实践之间，还有一个层次，那就是语言对比。所谓语言对比，就是研究英汉两种语言的异同，从而看出英语和汉语各自的特点。相比之下，各自的特点就清楚了。
二十世纪中期，王力先生在《中国语法理论》第六章“欧化的语法”中花了很大的篇幅进行语言对比，指出各自的特点，探讨英语对汉语的影响。八十年代以后，从事这方面研究的人多了起来，出版了专著，还成立了专门的机构。
我个人进行语言对比，是从对照着原文研究《毛选》的译文开始的。我在研究了大量的译例之后，得出了若干规律性的认识，分二十个题目，写成了《汉英翻译五百例》，于1980年出版。
例如，许多译例表明：“在一个汉语句子里或相连的几个句子里，往往有些词或词组重复出现。”“英语和汉语相反，在一般情况下是避免重复的。”“汉语重复，英语不重复，这是两种语言的一个明显的不同之处。”有了这点认识，汉译英时就多用代称，英译汉时就多用实称，不必拘泥于原文了。
语言对比主要是注意句子结构，或者说注意翻译过程中各个成分在句中的变化。译文之所以有时会因过于机械而不顺，就是因为迁就原文的结构，而没有考虑译文的结构应有哪些变化。好的译文之所以好，就是因为句内各成分都放在了应放的位置，符合译入语行文的习惯。美国翻译理论家奈达说过：
To preserve the content of the message the form must be changed .说的大概也是这个意思。
是不是看几本书就行了？诚然,这方面的书也是有的。但只看别人得出的结论往往印象不深，时间久了，也许就忘了。因此最好亲自动手进行比较，或者至少把别人结论拿来验证一番。其实，语言对比是很有趣的，通过对比，你会发现许多过去未曾注意的东西。而且你的注意力也不会完全局限于译例。每当你有所发现的时候，你就会去查阅关于英语的权威性著作，也会去查阅关于汉语的权威性著作，看看他们对这个问题是怎么说的。比如，在我研究前面提到的“实称”与“代称”的问题时，就参考了Randolph Quirk等四位学者所著的A Grammar of Contemporary English。书中有一节专门论述substitution，我看到不仅名词有替代的说法，动词、形容词、副词等也都有替代的说法，他们把所有这些替代的说法统一称为“pro-forms”。看到这里我感到一阵惊喜，顿时觉得自己对这个问题的了解深入了一步。一个人要是学问有长进，就会感到欣慰，要是日有所进，就会觉得其乐无穷。
对比两种语言，认识其各自的特点，主要是通过研究译例来进行的，是与翻译实践紧密相连的。若用这方面的研究成果来指导翻译实践，翻译起来就会得心应手，认识越深刻，就越得心应手。不信你试试。
]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/17/zhuangyichuan-on-transloation-5-1053.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（四）语言的魅力</title>
		<description><![CDATA[语言是一个神奇的东西，运用得当，可以产生强大的力量，译者也就是借助于这种力量，重新创造出感人的作品。可以说，译者对语言的掌握是做好翻译的先决条件。
严复就是用他那优雅的古文把进化论的思想介绍到中国，感动了一大批有识之士，包括当朝皇帝，推动他们变法维新。他翻译的《天演论》，虽未尽“信”尽“达”，一个“雅”字却表现的淋漓尽致。
林纾虽不懂外语，却在别人帮助之下，用他那精美的文言文将184种外国文学作品介绍到中国。《林译小说丛书》曾使十一二岁的钱钟书“增加学习外国语文的兴趣”。数十年后，大学问家钱钟书“偶尔翻开一本林译小说”，发现“它居然还没有丧失吸引力”。
周熙良教授就很强调研究语言。他写过一篇文章，题目是“翻译三论”，发表在《翻译通讯》1982年第六期。他在“翻译与语言”一节中指出，初搞翻译的人要看点汉语语法，注意到一些语言现象，这有助于摆脱原文的束缚。他说：“一个搞翻译的人对语言不感兴趣，翻译水平是不大会提高的。”
近年来，研究翻译的人多了起来，各种出版物也多了起来，介绍翻译理论、翻译技巧、翻译方法、翻译经验，吸引着初上译途的人的眼球。这些出版物既然都是研究的成果，都会给人以启迪。但对一个译者来说，最重要的不是通晓多少种翻译理论，掌握多少条翻译技巧，而是不断提高自己的语言水平。最后决定译文质量高低的是译者使用语言的能力。一位有经验的译者，可能说不出多少翻译理论和技巧，他靠的是自己在语言方面的造诣，他能告诉你的是怎样学好语言。
单其昌写了一本《汉英翻译技巧》，请杨宪益作序。杨先生在肯定了作者的研究方法之后指出，要避免翻译工作中出现错误，“主要还是要多读一些好的英美文学作品，逐步理解这种外国语言的内在规律。”接下去，他还介绍了自己的学习经历，“在我掌握了基本语法之后……到了我上高中时，我就完全丢开了语法书，只去广泛阅读文学作品了。”
我的老师王佐良教授译过一本《彭斯诗选》，其中有一首题为“一朵红红的玫瑰。”他在题为“答客问：关于文学翻译”的广播稿中提到，自己对这首诗的译文并不满意。接下去，他说，“作为一个译者，我总是感到需要不断锻炼，要使自己的汉语炼得纯净而又锐利。”老先生这样孜孜不倦，精益求精，是非常值得我们学习的。
英国剑桥大学George Steiner 教授写过一本书，名叫After Babel。在第一章的末尾，他说了这样一句话：A study of translation is a study of language。这也许是对翻译研究最好的概括。你不想在语言上下点功夫吗？
]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/16/zhuangyichuan-on-transloation-4-1050.html</link>
			</item>
	<item>
		<title>庄绎传翻译漫谈（三）翻译重在实践</title>
		<description><![CDATA[我国著名翻译家傅雷先生留学法国,攻读法国文学和绘画,回国后将大量法国文学作品译成中文,介绍给国人。他在1957年给《文学报》写的一篇题为“翻译经验点滴”的文章里就曾说过:“翻译重在实践。”
要想提高自己的翻译能力,一定要通过实践。实践可以分为两类,直接的实践和间接的实践。
所谓直接的实践,就是自己亲身参加的实践,也就是自己动手翻译。一回生,二回熟,日积月累,第一手经验多了,做起来得心应手,翻译能力有所提高。所谓“熟能生巧”,就是这个道理。但自己能译的东西是有限的，从这种实践中得出的经验也是有限的。因此，还需要借助于间接的实践。
所谓间接的实践,就是研究别人的译文。比如,一篇文章在手,准备翻译,这时先找一些有关的资料或同类文章的译文看一看,在词语和风格方面定会有所借鉴。常作翻译的人都会这样做。别人的译文是别人直接实践的产物,你看了别人的译文,就是从事间接实践。从总结经验的角度来看,直接实践和间接实践具有同等的价值。因此,有空的时候,找一些译文来,尤其是好的译文,加以研究,总结出一些规律性的东西,对于提高自己的翻译能力是大有好处的。
不过我还是要强调,只看别人怎样翻译,自己并不动手译,是不行的。我为高等教育自学考试编过一套翻译教程,有些学校办了辅导班。有一次,一位老师告诉我,他的学生只看我的书,并不作练习。我听了大为惊讶,连忙写了一片短文,登在《英语学习》杂志上。我说,学翻译犹如学游泳。只在岸边看别人游,或只听教练讲解,是学不会的。你说是不是这么个理儿?
]]></description>
		<link>http://www.cn-cuckoo.com/2009/08/15/zhuangyichuan-on-transloation-3-1048.html</link>
			</item>
</channel>
</rss>
