<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>为之漫笔</title>
	<link>http://www.cn-cuckoo.com</link>
	<description>为之漫笔（李松峰），本博客专注于Web前后端技术、移动平台开发技术、交互设计和技术翻译。声明一下，因为时常需要外出审稿，而且基本不带笔记本，所以有时可能会迟一点回复大家的留言。</description>
	<lastBuildDate>Mon, 12 Dec 2011 01:43:07 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.2.1" -->

	<item>
		<title>使用JavaScript和Canvas开发游戏（五）</title>
		<description><![CDATA[原文作者：Matthew Casperson • 编辑：Michele McDonough 原文链接: Game Development with JavaScript and the Canvas element 1、认识一下Canvas 2、在Canvas上绘图 3、通过Canvas元素实现高级图像操作 4、写一个游戏框架（一） 5、写一个游戏框架（二） 6、通过Canvas实现视差滚动 7、动画 8、JavaScript键盘输入 9、综合运用 10、定义级别 11、跳跃与坠落 12、添加道具 13、加载资源 14、添加主菜单 在Canvas元素上实现视差滚动 http://www.brighthub.com/internet/web-development/articles/40511.aspx 视差滚动是在2D应用中创造立体纵深感的一种技术。这篇文章就来看一看在我们刚刚创建的游戏框架基础上实现视差滚动有多容易。 视差滚动 有了游戏框架，就可以通过画布元素来做一些好玩的东西了。 视差滚动指的是屏幕上的几个图层发生相对位移的效果，换句话说，背景图层滚动得比它前面的那些图层要慢一些。这种创造视觉纵深感的技术在2D游戏中的应用极为普遍。 RepeatingGameObject.js /** 这个类可以重复显示纹理图像，支持纹理图像在x轴或y轴偏移 @class */ function RepeatingGameObject() { /** 最终图像占据的宽度 @type Number */ this.width = 0; /** 最终图像占据的高度 @type Number */ [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/08/17/game-development-with-javascript-and-the-canvas-element-5-2645.html</link>
			</item>
	<item>
		<title>使用JavaScript和Canvas开发游戏（四）</title>
		<description><![CDATA[原文作者：Matthew Casperson • 编辑：Michele McDonough 原文链接: Game Development with JavaScript and the Canvas element 1、认识一下Canvas 2、在Canvas上绘图 3、通过Canvas元素实现高级图像操作 4、写一个游戏框架（一） 5、写一个游戏框架（二） 6、通过Canvas实现视差滚动 7、动画 8、JavaScript键盘输入 9、综合运用 10、定义级别 11、跳跃与坠落 12、添加道具 13、加载资源 14、添加主菜单 4、写一个游戏框架（二） 在这篇文章里，我们继续介绍构成这个基本JavaScript游戏框架的其他必要的类。 前一篇文章介绍了GameObjectManager类，该类负责画布的渲染并允许GameObject类更新和删除它们自己。下面就来看一看GameObject类。 GameObject.js /** 游戏中出现的所有元素的基类 @class */ function GameObject() { /** 显示的深度次序。较小的zOrder值表示先渲染，因而会在背景中。 @type Number */ this.zOrder = 0; /** x轴的坐标 @type Number */ this.x = 0; [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/08/15/game-development-with-javascript-and-the-canvas-element-4-2639.html</link>
			</item>
	<item>
		<title>使用JavaScript和Canvas开发游戏（三）</title>
		<description><![CDATA[原文作者：Matthew Casperson • 编辑：Michele McDonough 原文链接: Game Development with JavaScript and the Canvas element 1、认识一下Canvas 2、在Canvas上绘图 3、通过Canvas元素实现高级图像操作 4、写一个游戏框架（一） 5、写一个游戏框架（二） 6、通过Canvas实现视差滚动 7、动画 8、JavaScript键盘输入 9、综合运用 10、定义级别 11、跳跃与坠落 12、添加道具 13、加载资源 14、添加主菜单 4、写一个游戏框架（一） http://www.brighthub.com/internet/web-development/articles/40512.aspx 在知道了如何使用画布元素之后，接下来我教大家写一个框架，有了这个框架，我们就可以把它作为基础来创建游戏。在这第一部分，我们会介绍前两个文件/类。 编写代码之前，我们先来看一看随后几篇文章将致力于创建的示例Demo。表面上看起来，这个Demo跟第二篇文章里的那个没啥区别，但如果你看看后台（查看网页源代码）就会发现，为了更方便地创建这个最终效果，一个凝聚不少心血的基础框架已经写好了。 下面我们要介绍的JavaScript代码使用面向对象的方式来编写。对于没有编写过多少JavaScript代码的人来说，恐怕第一眼看到它们会觉得有点奇怪。如果你真的不太熟悉JavaScript的面向对象编程，建议通过Mozilla Developer Network的这个教程https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript来补补课。这篇教程里解释了我们稍后会用到的一些编程技术。 从设计思想上来看，这个框架可以分成两部分：与底层的2D引擎交互的类（用于操作画布、控制渲染循环、处理输入等的代码）和用来创建对象以便构成游戏的类。前者可以归为引擎类，后者可以归为应用类。由于应用类要构建于引擎类之上，所以我们需要先来创建引擎类。 Main.js 如果你研究了前面例子中的代码，就会发现Main.js文件中包含了不少代码。 /** 每秒多少帧 @type Number */ var FPS = 30; /** 两帧间间隔的秒数 @type Number */ var SECONDS_BETWEEN_FRAMES = [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/08/14/game-development-with-javascript-and-the-canvas-element-3-2604.html</link>
			</item>
	<item>
		<title>使用JavaScript和Canvas开发游戏（二）</title>
		<description><![CDATA[原文作者：Matthew Casperson • 编辑：Michele McDonough 原文链接: Game Development with JavaScript and the Canvas element 1、认识一下Canvas 2、在Canvas上绘图 3、通过Canvas元素实现高级图像操作 4、通过Canvas实现视差滚动 5、写一个游戏框架（一） 6、写一个游戏框架（二） 7、动画 8、JavaScript键盘输入 9、综合运用 10、定义级别 11、跳跃与坠落 12、添加道具 13、加载资源 14、添加主菜单 3、通过Canvas元素实现高级图像操作 http://www.brighthub.com/internet/web-development/articles/39509.aspx 这篇文章将带领大家学习使用JavaScript和Canvas元素操作图像了几种不同的方式，这些方式在Canvas元素出现之前是不可能的事儿。 上一篇文章演示了如何利用Canvas实现一个基本的图像动画。那个例子很简单，同样的效果通过修改IMG或DIV等标准HTML元素的一些属性，照样也可以轻易实现。下面我们就来演示一下画布元素的高级应用，展示一下它的真正威力。 首先，还是准备一个HTML页面。 &#60;!DOCTYPE HTML PUBLIC &#34;-//W3C//DTD HTML 4.01//EN&#34;&#62; &#60;html lang=&#34;en&#34;&#62; &#60;head&#62; &#60;title&#62;JavaScript Platformer 2&#60;/title&#62; &#60;script type=&#34;text/javascript&#34; src=&#34;jsplatformer2.js&#34;&#62;&#60;/script&#62; &#60;style type=&#34;text/css&#34;&#62; body { font-family: Arial,Helvetica,sans-serif;} &#60;/style&#62; [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/08/11/game-development-with-javascript-and-the-canvas-element-2-2585.html</link>
			</item>
	<item>
		<title>使用JavaScript和Canvas开发游戏（一）</title>
		<description><![CDATA[原文作者：Matthew Casperson • 编辑：Michele McDonough 原文链接: Game Development with JavaScript and the Canvas element 1、认识一下Canvas 2、在Canvas上绘图 3、通过Canvas元素实现高级图像操作 4、通过Canvas实现视差滚动 5、写一个游戏框架（一） 6、写一个游戏框架（二） 7、动画 8、JavaScript键盘输入 9、综合运用 10、定义级别 11、跳跃与坠落 12、添加道具 13、加载资源 14、添加主菜单 1、认识一下Canvas http://www.brighthub.com/internet/web-development/articles/38364.aspx Canvas元素以及JavaScript引擎中新增的一些特性，让Web开发人员不必借助第三方插件，即可设计开发出精细且具有交互性的2D网页。这篇文章就向大家介绍一下Canvas元素，以及它的一些可能的用途。 JavaScript与Canvas元素 HTML是为创建静态页面而生的。HTML所能实现的动态效果，也仅限于显示GIF动画和闪烁的文本。JavaScript改变了这一切，通过它能够动态修改网页。今天，很多Web服务都利用AJAX来创建网页，为用户提供更加流畅的体验，也超越了标准HTML页面中常见的“点击－重新加载－点击”式的交互模式。 然而，JavaScript的某些功能会受到其宿主浏览器的制约。尽管可以在网页中创建和修改任何元素，但JavaScript不能（轻易地）让浏览器显示一种新对象。通过JavaScript修改文本、插入图像或者缩放表格都很容易，因为这些对象本来就是HTML所支持的。如果你想再玩得刺激一点，比如写一个网页游戏，怎么办？那恐怕就得苦心积虑地改变标准HTML元素的用途，克服种种不测才能达到目的。要么，你就得求助于Flash或Silverlight这样的插件。 Canvas元素登场了。这个新HTML元素为JavaScript开发者提供了一种无需插件即可在网页中直接绘图的机制。Canvas元素最早是由苹果公司在其WebKit框架中引入的，Safari浏览器和Dashboard微件都在使用。Canvas元素现在也被建议加入了HTML5规范，得到了最新的Chrome、Firefox、Opera以及Konqueror等浏览器的支持。Internet Explorer（至少在IE8之前）还不支持Canvas，但ExplorerCanvas项目倒是为IE提供了与Canvas元素类似的功能。 Canvas元素对做过2D图形编程的人是小菜一碟。可以在这个元素上画线、画各种形状、画渐变，甚至可以利用与其他2D API中类似的函数来修改其中的每一个像素。得益于Chrome的V8、Firefox的SpiderMonkey以及Safari的Nitro等最新JavaScript引擎的性能，创建精细且具有交互性的Web应用已经完全没有问题。 我们这一系列文章将教会大家使用JavaScript和Canvas元素创建一个简单的平台游戏。将要涉及的内容包括动画、加载资源、分层渲染、滚动和交互。通过一步一步地展示示例代码和实际效果，你可以很快学会如何驾驭强大的Canvas元素。 2、在Canvas上绘图 http://www.brighthub.com/internet/web-development/articles/38744.aspx 下面，我们就通过一个循序渐进的示例及实时演示，来介绍如何使用JavaScript在Canvas元素上绘图及实现动画。 准备工作 知道了什么是Canvas元素之后，该学习在屏幕上绘图了。首先，需要一个HTML页面来放置和显示Canvas元素。 &#60;!DOCTYPE HTML PUBLIC &#34;-//W3C//DTD HTML 4.01//EN&#34;&#62; &#60;html lang=&#34;en&#34;&#62; &#60;head&#62; &#60;title&#62;JavaScript Platformer [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/08/10/game-development-with-javascript-and-the-canvas-element-2554.html</link>
			</item>
	<item>
		<title>Martin Fowler谈软件专利</title>
		<description><![CDATA[原文地址：http://martinfowler.com/bliki/SoftwarePatent.html 在软件开发领域中，几乎所有我认识的人都对专利以及我们利用它的方式深恶痛绝。很长时间以来，我一直准备写篇文章，谈谈专利这玩艺儿，但一直迟迟没有动笔。最近，在收听了This American Life制作的一期特别棒的新闻观察节目（http://www.thisamericanlife.org/radio-archives/episode/441/when-patents-attack）之后，才决定把这篇文章写出来。我这篇文章的大致意思就是，虽然专利（包括软件专利）从原理上讲是个不错的想法，但在实践当中，各种专利已经给我们带来了无法容忍的灾难，取消这玩艺儿才是上策。 不过，首先还是来看一看为什么我说专利从原理上讲是个不错的主意，而且堪称人类历史上一个最有价值的“发明”。 关于专利在人类发展史中扮演的这个重要角色，Willian Rosen在他的书 The Most Powerful Idea in the World 中给出了很好的论述。Rosen在这本书里回顾了工业革命，而且他把工业革命刻画成了人类历史中最重要的事件，一个使人类财富得以向前迈进了一步的事件。 在17世纪的英格兰、法国，甚至中国，一名熟练的体力劳动者（比如纺织工或铁匠），每周工作的小时数大致相同，生产的布和钉子的数量也大致相同，而且跟他们奥古斯都时代（公元前63年至公元前14年。——译者注）的远祖也没有多大差别。他们能挣到相同数量的货币，能买到相同数量和种类的食物。他们的妻子，同样跟她的远祖一样，忙着准备一日三餐；她们也许会从本村面包师傅那儿买点面包，但除此之外，差不多什么都是自己亲自动手加工。她们甚至还要给全家人做衣服，天气变幻无常，衣服的样式也不尽相同。而且，这在很大程度上也让人无法把当时的家庭与10个世纪前的家庭区分开来，差不多清一色的自织土布，产麻区也会用亚麻布来做衣服。这样的劳动者和他的妻子，一般会生育八到十个后代，但能活到成年的差不多只有三个。如果这个劳动者要出门，那他只有靠步行；当然，如果他们家日子特别富裕的话，会花钱雇一辆两轮或四轮的马车。步行的话，每小时走三英里，坐马车则每小时走七英里。当然，时速跟他们的祖先也一样。而这就意味着，他的世界也就是他出生的地方加上方圆五、六英里远的范围这么大。 之后，历史上第一次，一切都发生了变化。这些劳动者的境况发生了最根本的变化。14世纪君士坦丁堡的一名熟练织工，只要工作三个小时就可以挣够买一磅面包的钱。到1800年，诺丁汉的一位织工为此则至少要工作两个小时。但到了1900年，买这块面包只要工作不到15分钟就够了。而到2000年，只要5分钟。这个已经是老生常谈的事实告诉我们，在发达的21世纪，一个中产阶级家庭所能享受到的奢华生活，在两个世纪以前，是连国王都很难承受得起的。 ——William Rosen 由工业革命导致的这个变化是不可思议的。我们都认为自己所处的是一个不断变化的时代，但前面的描述让我们想起了已经遗忘的过去。眼下，我们对变化已经习以为常，但在工业革命以前，人类生活的变化却极为缓慢。工业革命揭示出的最大变化就是变化本身。 我想研究人类历史的学生极少有人不会承认工业革命的极端重要性，但这也引出了两个重要的问题：为什么它会在那个时候、那个地方发生？18世纪末诞生蒸汽火车的英格兰有什么特殊之处？Rosen的观点是专利起到了重要作用，因为它为发明家和企业家提供了赚钱的刺激和平台。如果没有专利的话，那么就只有富人（或者获得了资助的人）才有条件去革新，而他们革新的动机其实是很弱的。 按照Rosen有说服力的论证，专利不仅仅是一件好事，更是我们人类迄今为止最伟大的一项创举。那为什么我还如此讨厌软件专利呢？ 这可以归结到一个事实：与工业革命时的专利相比，目前的专利保护总体上来讲已经严重地变质了。变质最严重的当数所谓的新颖性。专利保护的重中之重，无非就是由法律授予对某种新东西（有限期）的垄断权。《美国专利法》规定，如果“从总体上看，标的物在被发明的时候，对于一个拥有相应技艺领域普通技能的人来说显而易见”，则无法取得专利权。这一规定可以追溯到1623年制定的英国垄断条例[1]，这个条例首次提出只有具有新颖性和实用性的发明才能申请专利。 软件专利的核心问题就是这个关键的原则已经被扔到了一边。软件领域的每个人亲眼见证了，那么多专利摆在那除了声称对已经用了多少年的技术拥有垄断权之外，没有任何意义。更不用说那些尽管新，但对我等拥有普通编程技能的人而言却是显而易见的成果了。 虽然这种变质已经足以破坏软件专利的纯正性，但其他方面的变质也同样值得讨论。最初，专利都是有年限规定的——1623年的法律规定的是14年。当然，制定这个规定的年代其变化要比今天的变化慢得多，更不要说跟我们这个行业比了。正常的软件专利应该比这个年限更短才对。再一个变质的地方就是不明确——大多数软件专利都宽泛和含糊得不可思议，但专利的范围最早都很窄，也很明确。专利范围窄能够刺激人们思考解决同一问题的不同方法，从而达到鼓励创新的目的，而宽泛的专利则会扼杀创新。 这几方面的变质造成了专利不再激励和导向新发明，而是沦为了对簿公堂的武器。对于大公司来讲，专利诉讼既让人分心，又会带来经费负担，至少表面上看如此。但诉讼其实对小公司的伤害最大，因为他们没有时间和金钱为了专利去打官司。因而我们就看到了利用专利来敲诈，而这也抑制了创新。 灾难的是，专利已经演变成增强已有实力的途径。大公司可能会认为专利带来的是无尽的麻烦，但专利最终还是对保持当前公司的巨头地位十分有利，因为依靠专利可以强迫更小的对手出局。这正是难以改变现状的原因，那些具备强大实力的公司不可能有动力放弃专利。 最令我痛心疾首的是，我熟识的很多程序员都是这场灾难的同谋。程序员谈论自己正在申请某某专利，而自己又知道那有多么荒谬的事例并不少见。想让别人高看自己一眼很容易，但我真的认为参与取得那些子虚乌有的专利的程序员，应该为自己的所做所为感到耻辱。这暴露出了我们缺少责任感，我们应该被世人当作专业人士，但我们自己却在自毁长城。 理论上，假如专利能够回归到其核心的互利原则，而且能够得到适当的贯彻，我也不反对软件专利。这恐怕就意味着要有一个流程，能够确保只把专利授予那些真正新颖的思想。但除非这样一个流程能够很好地运作，否则我宁愿看到软件专利被彻底废除。一个没有软件专利的世界，总归要比我们现在所处的这个专利泛滥的世界要好得多。 延伸阅读 有关专利的文章资料可谓汗牛充栋。Tim Bray去年写的关于“放弃专利”的文章（http://www.tbray.org/ongoing/When/201x/2010/02/22/Patent-Fail）中给出了很多不错的参考资源。不少类似的观点也都证明了软件专利确实导致了创新的减少。 Planet Money对This American Life的相关话题做了一个语音跟踪报道（http://www.npr.org/blogs/money/2011/08/05/138934689/the-tuesday-podcast-the-patent-war），其中给出了他们自己总结的一些研究成果。 “在一个我们未来的财富如此依赖创新的时代，我们已经滑向了一种既不能实现其合理功能——激励创新，却又极力阻碍着创新的专利制度。”——WW.W. of The Economist（http://www.economist.com/blogs/democracyinamerica/2011/08/intellectual-property） [1] 我更喜欢这个条例最初的名字《Act concerning Monopolies and Dispensations with penall Lawes and the Forfeyture thereof》（关于垄断和特许以及相关刑法及罚没的法案）]]></description>
		<link>http://www.cn-cuckoo.com/2011/08/08/martin-fowler-on-software-patent-2560.html</link>
			</item>
	<item>
		<title>美国第二大连锁书店Borders CEO致会员的一封信</title>
		<description><![CDATA[原文地址：http://ebm.e.borders.com/c/tag/hBOKNiQAQfEXsB8cdgOAESqwkGW/doc.html 新爱的Borders Rewards会员， 相信你们已经听说了，Borders在经过40多年为几代读者点燃热爱阅读的薪火之后，将要全面关门停业了。宣布这个消息，我们也感到非常抱歉，因为在我们奋力拯救公司之际，你们始终与我们站在一起。我想以个人名义向你们表示感谢，感谢你们的忠实与支持，无论你是180万Borders Rewards Plus计划的注册会员之一，还是曾在我们的商店或Borders.com上买过东西，或者花时间通过邮件或电话方式向Borders表示过支持。 你可能会想，发生了什么事？Borders怎么就经营不下去了呢？简单地说，相关各方经过反复协商，也都尽了最大努力，没有出价人正式提议我们公司继续经营。因此，根据我们的债务持有人融资协议，我们向法院递交了申请，请求批准其他公司购买我们商店的资产，并执行清算程序。 为了避免这个结果发生，我们已经尽了很大努力。但事实上，很长时间以来，Borders一直面对不利的市场形势，包括图书业的迅速变化、电子阅读器的革命，以及动荡的经济。我们也曾奋力一搏，绝地反击，但令人遗憾的是，我们最终没有战胜这些外来的力量。 所有门店将于7月22日星期五开始停业甩卖。希望大家利用这次绝无仅有的机会，以意想不到的折扣买到自己心仪的图书或其他商品。清算销售期间，礼品卡可以继续使用，Borders Rewards Plus会员到8月5日之前仍将享受其会员折扣。此外，全部Borders Bucks在7月31日前仍然可以使用，过期作废。 几十年来，Borders商店一直是读者寻求知识、快乐和灵感，以及与那些充满激情的人交流思想的地方。我很荣幸，能够有机会领导Borders并在扩大阅读范围和传播阅读兴趣的伟大事业中扮演了一个角色。作为一家公司，对于你们能接受我们的服务，对于另外几百万客户数年来从我们商店购物，我们感激不尽。我衷心希望Borders永远活在读者的心中。 非常感谢， Mike Edwards Borders公司CEO]]></description>
		<link>http://www.cn-cuckoo.com/2011/07/26/to-borders-rewards-member-2545.html</link>
			</item>
	<item>
		<title>JavaScript是Web的汇编语言（二）：疯狂，亦或只是精神错乱？</title>
		<description><![CDATA[原文地址：JavaScript is Assembly Language for the Web: Part 2 &#8211; Madness or just Insanity? 有些人认为“JavaScript是Web的汇编语言”完全是精神病说的话。为此，我询问了几位JavaScript权威，比如Brendan Eich（JavaScript之父）、Douglas Crockford（JSON之父），还有Mike Shaver（Mozilla技术副总裁）。以下都是从个人邮件里摘过来的，得到了以上几位的许可。 Mike Shaver： 以前我就听说过这种比较，我认为很大程度上确实如此。但是，这种说法忽视了JS开发人员与机器之间的人机工程学方面的大量努力，因为汇编语法设计得没有那么人性化（特别是现代的汇编语言）。 Brendan Eich： 几年前，我曾说过“JS是Web的x86”（好像是在一次JSConf上），不过我不敢说我是第一个这么说的。（Nick Thompson今年也在Hacker News中这么说过。） 关键在于，JS确实在按照我们想的，越来越往低级方向发展了。但它也具备高级的特性。 Shaver说得没错，汇编缺少可靠的宏处理器，因此不适合程序员，也不够安全。但JS可不是这样。所以，这个比喻需要加点限制条件，不然就要闹出笑话来了。 无论从高级函数式编程还是内存安全角这个角度看，还是从低级特性，像类型化数组以及即将成为现实的ES中类型化数组的扩展、二进制数据，等等来说，JS都是一个比汇编更加强大的编程语言。当然了，内存安全是首要的区别。 Douglas Crockford： 就这个问题来说，我觉得说JavaScript是Web的虚拟机更接近一些。过去我们一直都把Java的JVM看成是Web的虚拟机，但结果呢，JavaScript才是。 从提供代码安全的角度说，JavaScript的解析器比JVM的字节码验证器更有效。就兑现“编写一次，到处运行”这个诺言来看，JavaScript更出色；这或许正是因为它是在较高层次上运行，才得以避免触及一些底层的棘手问题。因为它把剩下的事儿都交给图灵去解决了。 当然啦，也有不少人始终不肯承认JavaScript能把一切都处理好，我过去就是这样一个人。而现在我则不断地被眼前这种百花齐放的景象震撼着。 Brendan Eich，补充： Doug说源代码强过字节码，说得太好了。很早以前，我的朋友，加州大学欧文分校的Michael Franz教授就指出了Java验证器O(n^4)级别的复杂性（计算机时钟周期失控，拒绝服务）。精简之后的JS呢，确实传输更便捷，而且词法/语法分析也相当快。 （JS）源代码作为“字节码”同样也避免了Java字节码的一个很傻的问题：冻结设计不良的Java低级形式，导致高级形式的源代码也无法解决这个问题。换句话说，Java唯恐破坏其字节码的兼容性。而这严重影响了Java内部类及其泛型的设计。——不管怎么说，Sun最后还是破坏了字节码的兼容性。 以下是前一段时间Nick Thompson在YCombinator说过的话： 这只是我个人的看法：我花了自己两年时间，想尽可能让JVM能够与JavaScript互通。当时的Netscape有不少人认为字节码作为移动代码的基础比较好。但Sun从头搭建了自己大而全的软件体系，把问题搞得很复杂。他们没有想让Java与其他语言沟通，更别提让Java能嵌入其他软件中了。他们的字符串处理代码都是用一种解释型语言来写，而不肯用C来玷污自己！有什么我就说什么，Netscape，这个当时Java唯一的一个大客户，在Sun眼里无非就是一个用来实现他们取代Windows梦想的工具而已。所有想用Java的人都是自己给自己找罪受。 在此期间，Brendan一个人干了10个工程师，外加3个客户服务人员的活儿，同时还要关注Web作者在乎的一些事，比如把JS代码混合到HTML中、即时加载、与浏览器其他模块的集成等等，此外还要协调其他浏览器厂商，以便让JS成为一个开放标准。 因此，今天的JS作为Web的x86汇编程序，并没有像它本该的那样完美，但你通过它真能把事情稿定（GWT就是一个最明显的例子）。这可以说是一个经典的“更差就是更好”的例子，只不过Java也就是从下往上那么看起来更好罢了。而JS则在此期间取得了相当不错的成就。要想取代它的地位可没那么容易。 当然，这个比喻不一定准确。JavaScript代码无论从外观到行为，肯定不像ASM。但作为一个比喻，至少可以说明： JavaScript无所不在； 它速度快而且越来越快； JavaScript酷似低级的Web编程语言； 它可以通过手工编写，也可以从另一种语言编译而来。 诸如此类的话题也经常在Hacker News中出现： “现在的JavaScript其实就是客户端的汇编语言。想改它太难了，所以得想办法开发一些工具来解决这个问题。”—— jonnycat 好啦，能听到如此有见地、有深度，而又详尽的讨论，该满足了吧。亲爱的读者，你们太棒了。]]></description>
		<link>http://www.cn-cuckoo.com/2011/07/21/javascript-is-assembly-language-for-the-web-ii-2531.html</link>
			</item>
	<item>
		<title>JavaScript是Web的汇编语言（一）：语义Web已死！</title>
		<description><![CDATA[原文地址：JavaScript is Assembly Language for the Web: Sematic Markup is Dead! Clean vs. Machine-coded HTML （更新）有些人认为“JavaScript是Web的汇编语言”完全是精神病说的话。为此，我询问了几位JavaScript权威，比如Brendan Eich（JavaScript之父）、Douglas Crockford（JSON之父），还有Mike Shaver（Mozilla技术副总裁）。他们的评论发表在下一篇文章里。 昨天我跟Erik Meijer聊天，他说： JavaScript就是一个汇编语言。JavaScript加上生成的HTML就像是.NET汇编一样。浏览器可以执行这些代码，但没人真的关心里面到底写的是什么。 ——Erik Meijer 怎么会说起这件事儿呢？当时我正在试用Google+，就跟上大多数让我印象深刻的网站一样，我立即就查看它的源代码。不看不要紧，一看吓一跳： 咱就将就说吧，我看到了1300行代码，密密麻麻的，大约90KB。上面图片显示的只是最前面的一小部分，基本上都是“瘦身后”的JavaScript代码。再往下看，页面中间呢，全都是像下面这样的span、div以及生成的类和id： 我勒个去，满篇都是GUID（Globally Unique Identifier，全局唯一标识符）。 话又说回来了，http://msn.com、http://www.bing.com、http://.www.facebook.com，全都这样啊。就连http://www.twitter.com也都开始有点“瘦身”的迹象了。所有大点的网站好像都丝毫不在乎什么标记之美。这是为什么呢？ 这样有效率啊，性能高啊。Google很多最出色的网站背后都依赖GWT呢。在这种情况下，要是这一类网站的里头和外头全都一样漂亮，你反而会觉得不可思议了。 不能不说这可真有点讽刺的意味。曾几何时，ASP.NET的开发人员对ViewState可是怨声载道啊。“简直太笨了”的意思就是“我看不懂它都干什么了。”ViewState曾经（现在也）是一项让Web开发效率提高很多倍的技术。它跟Google Web Toolkit（GWT）不一样，但GWT与WebForms的出发点也并非完全没有相似之处。看看GWT网站自己怎么说： Google Web Toolkit（GWT）是一个开发工具包，用于构建和优化基于浏览器的复杂应用。GWT的目标是提高高性能Web应用开发的效率，而且无需开发人员熟悉浏览器的各种怪癖，以及XMLHttpRequest，还有JavaScript。 这个出发点可真是值得赞美，不对？难道不可以这样说（抱歉，开个玩笑而已）： “ASP.NET WebForms”是一个开发工具包，用于构建和优化基于浏览器的复杂应用。它的目标是提高高性能Web应用开发的效率，而且无需开发人员熟悉浏览器的各种怪癖，以及XMLHttpRequest，还有JavaScript。 本文的目的不是想夸奖WebForms，也不是给WebForms正名。WebForms对于某些应用是不二之选，正如GWT对其他一些应用那样。我真正想说的是，使用服务器端的工具包，没有办法像使用jQuery写出清晰的JavaScript，或者使用Razor或HAML写出清晰、清楚的标记一样，给Web开发带来真正的快乐。归根结底，其实就是你选择的抽象级别的问题。 所谓的语义标记在这种情况下仍然是被隐藏的，而诸如http://schema.org之类的站点也仍然非常重要，只不过可别指望你能在心仪的站点里看到缩进得像俳句一样整齐的源代码。 大家知道，精简和压缩属于正交优化。而我要说的是，一点也不在乎标记和脚本发送到客户端之后是否美观，确实太草率了。假如谁都不在乎发送到浏览器的标记，只在乎结果，那谁的标记和JS就那么不值钱啊，谁还愿意主动公开自己的源代码呢？反正，网站不是运行得挺好嘛，谁还在乎其他的？ 现在我要给亲爱的读者提个问题，你觉得自己为什么那么在乎点击“查看网页源代码”之后的结果呢？难道HTML5和JavaScript是Web的新汇编语言不成？ （更新）声明一下： 当然，这个比喻不一定准确。JavaScript代码无论从外观到行为，肯定不像ASM。但作为一个比喻，至少可以说明： JavaScript无所不在； 它速度快而且越来越快； JavaScript酷似低级的Web编程语言； 它可以通过手工编写，也可以从另一种语言编译而来。 作为开发人员或者设计人员，如果有工具提供了你需要的控制和你需要的结果，你最关心哪一个？我认为Rails、ASP.NET，甚至GWT，都没有100%做到这一点。它们都有自己的问题，但我认为将来的Web不会再专注于清晰的标记，而是夺目的用户体验和语言、工具的天下，开发人员会很享受，效率也会更高。 亲爱的读者，你愿意HTML和JavaScript再多抽象一点吗？还是希望它少抽象一点？ （再更新）为了让大家明白，我得再说一遍。本文讨论了两个独立的问题。一个当然就是源代码经过了精简和通常的混淆。但这只是第一个问题。真正的问题在于，JavaScript已经成了其他多种语言的目标语言。GWT是一个用JAVA来写Web应用的框架，它产生的字节码是“JavaScript”。GWT为原来天然的语言（HTML+JS）选择了一个设计好的高级语言，并将整个浏览器当成了一个VM。好，问题来了：我们是在写汇编呢，还是在写某种更高级点的代码？而且，我刚知道Google+是用Closure来写的，但这不影响前面的问题。]]></description>
		<link>http://www.cn-cuckoo.com/2011/07/20/javascript-is-assembly-language-for-the-web-i-2511.html</link>
			</item>
	<item>
		<title>松本行弘说：我想让Ruby更快地发展</title>
		<description><![CDATA[日文版：Mr Junichi Niino，Rubyの進歩がより速くなることを期待している 英文版：I am looking forward to accelerating Ruby&#8217;s progress 我在前一篇文章里已经提到过了，松本行弘（Yukihiro Matsumoto，或Matz）已经加入了Heroku，成为该公司的首席Ruby架构师。我通过电子邮件询问了Matz对自己未来的设想。 “让Ruby核心功能更丰富、品质更高是我的使命。” PublicKey（以下称Q）：能不能介绍一下你怎么就换工作了呢？ 松本行弘先生（以下称Matz）：上一次跟Marc Benioff先生（Salesforce.com的CEO）碰面时，他就问我，怎么才可以支持Ruby的开发。 于是，我就说了，我说我想要改变当前大多数Ruby核心开发人员面临的窘境：这些人有的是牺牲自己的闲暇时间来完成自己的工作，有的还在为自己的职业前途担心。 然后，他就说他可以为我们提供一些支持，而这也是我通过Heroku加入Salesforce.com的原因（注意：目前还有几位Ruby核心开发人员也正协商加入Heroku）。 也就是说，我们工作的核心内容没有变。我们的使命依旧还是开发Ruby核心，把它变得功能更丰富、品质更高。如此说来，我期待着我们提供的职业前景，以及来自包括Heroku在内的大量Ruby用户的反馈，能够加速Ruby开发的进程。要不然，我换这次工作就没有什么意义了。 不过，加入Heroku并担任他们的首席架构师，并不意味着我只关心Heroku和Salesforce.com的发展。我加入他们不会改变我与NaCI还有Rakuten的合作关系，后两者仍然会继续支持我，而且我还将继续担任Ruby协会的会长一职。 我为什么选这个头衔？因为我觉得“首席架构师”这个名字听起来显得最容易与业务撇清关系。我不打算将来在Heroku参与任何业务上的决策。 Q：你对自己在Heroku的角色有什么期许？ Matz：刚才不是已经说了嘛，我的工作没有什么变化，但我们的开发进度会加快。除此之外，我还能与Heroku进行更加密切的沟通，以便尽早解除Ruby对云计算平台的限制（如果有限制的话）。 而且，我还会继续与Engine Yard、VMWare等公司保持良好的关系，即使我加入了Heroku，我仍然还是那个“Ruby的Matz”，不会辜负他们的信任。 Q：此时此刻，你对Ruby和云计算有什么看法？ Matz：说实话，很多Ruby核心开发人员（包括我自己）都对Web没有多大的兴趣，但云计算会变得越来越重要，这一点是显而易见的。所以，我希望能从这些云计算运营商那里得到更多的需求，以便将其反映到未来的Ruby中。 Q：你会去硅谷上班吗，还是在松江远程工作？ Matz：我的生活方式不会变（但工作方式会变），所以多数时候我会在松江的家里远程参与开发。 就我自己而言，搬到硅谷去工作不一定会比现在这个环境更好。 不过，我想我每年都会跟旧金山/硅谷（包括Heroku）的那些人直接沟通几次。 （注意：大家别误会，Heroku的总部在旧金山，不在硅谷，但他们在新闻稿里自称是“硅谷公司”。） Q：还有别的要说的吗？ Matz：我听说很多（日本之外国家的）人并不知道，Ruby核心团队迄今还没有一个可持续的发展模式。我希望我这次换工作能为代表日本发布消息的日本软件开发人员树立一个榜样。 Q：谢谢你接受采访。]]></description>
		<link>http://www.cn-cuckoo.com/2011/07/13/matz-qa-after-joining-heroku-2504.html</link>
			</item>
	<item>
		<title>JavaScript，只有你想不到</title>
		<description><![CDATA[原文地址：http://radar.oreilly.com/2011/06/time-to-learn-javascript.html作者简介：Mike Loukides 很长时间以来，JavaScript在我眼里都是编程语言中的二等公民。早先，它经常是很多安全问题的发源地，就像是胶水一样，它能把HTML应用与样式粘到一块，可没有人拿它来正正规规地写程序；这样的情形太普遍了。而Java、Ruby、Python，这些才是真正能用来写程序的语言。 过去几年间，我对JavaScript的态度有了彻底的改变。JavaScript已经“长大成人”了。我敢保证很多JavaScript开发人员都不会认同我前面的说法，他们会说JavaScript一直都是一个十分强大、成熟、深得人心的语言。或许他们说得没错，事实上只要是一门完整的编程语言，就能拿来写程序，也包括BASIC这种滥东西。而一门语言真正有用，必须一方面自身具备很强的表达能力，另一方面还要有众多的库和开发工具。显然，JavaScript的表达能力早就没有问题了，即便是创建对象的方式有点不好让人接受，其实问题也不大。直到最近，一些极其重要的扭转局面的技术出现了：jQuery、JSON、Node.js和HTML5。或许JavaScript以前就是一门完善的语言了，但却是这些重要的相关技术（以及其他一些没有在这里提及的），让JavaScript成为了每一个开发人员都知道的语言。如果明年你要学一门新语言的话，那一定就是JavaScript。 潜力无限的Node.js 说Node.js潜力无限的意思，就是它有可能引发Web开发的革命。Node.js是一个框架，用于构建高性能Web应用——即使是巨量的请求也能应对如流。虽然Node本身作为一个底层框架，能够用于构建任何应用，但它还是最适合构建Web服务器。它的异步事件驱动模式与传统的请求-响应模式相比，无疑更适合Web应用。 有两方面因素更让人看好Node。首先，Google在提升JavaScript性能方面掀起了一场革命。这句话的意思并不是说你随时随地都可以用上最好的JavaScript引擎（尽管这也是我们一个美好的期望）。但可以肯定的是，Google在其他竞争对手还没有上心的情况下，真的把JavaScript性能当成了一回事儿。如此一来，就把Mozilla、Apple、Microsoft、Opera，还有其他浏览器开发商逼到了性能竞赛的跑道上。结果导致我们现在使用的JavaScript引擎较之几年前快了不知道有多少倍，完全有能力运行复杂的大型Web应用。 其次，Node有着庞大的开发人员基础。不管大家在服务器端使用的是什么语言，但在客户端却鲜有不使用JavaScript的。有的人可能是“剪刀加浆糊”式的东拼西凑，有的人则可能用JavaScript做出了高超的Ajax应用，而有的人甚至实现了全功能的应用程序，像Twitter或Gmail。可不管怎么说，JavaScript开发人员的数量无疑是非常庞大的。而Doug Crockford等作者更是极力宣传所有人都应该把JavaScript当成一门严肃正经的编程语言来看待——尽管它还有不少缺点。 当时当下，编写Node应用相对还是个“粗”活儿，毕竟它只是一个底层库。想象一下单纯使用JavaScript写代码，对，就是这种感觉，Node当前还是一个beta版的格局，与Rails或Django这样成熟的Web开发框架还没法比。这种状况无疑会改变。一些轻量级的框架，比如Express，已经出现了；我坚信更多基于Node的全功能框架将继续不断涌现。 前面提到过一些几乎完全在浏览器中运行的高级Web应用。那些都已经不算什么新鲜事儿了，Gmail多大了？Google Maps贵庚了？不过，用JavaScript编写在浏览器中运行的应用的客户端无疑是越来越有吸引力了。HTML5则继续推高了人们对这一趋势的期许。 HTML5就是JavaScript 我不知道已经说过多少次了，HTML5实际上并没有多少与HTML有关，它其实就是JavaScript。HTML本身有什么变化？不过一些新标签而已，况且哪个新标签都不难理解。HTML5的威力在于让你能用JavaScript来创建这些标签。假如没有后台代码通过Canvas来创建动画、游戏，或者通过它来实现一些数据的可视化，这个标签也没有大用处。从浏览器开始支持Canvas开始，我已经看到了Asteroids（行星游戏）的上百个实现，那都是开发人员为熟悉这个新特性所做的练习。有的比较粗糙一些，而有的则极其精美。这些完全都要归功于JavaScript。 由此可见，HTML5并不是以尖括号为特征的标签语言的一次大的改进，其实质是赋予了JavaScript更强大的能力。WebGL库（当前还羽翼未丰）支持在HTML5的画布中绘制实时的3D图形。HTML5的地理位置支持在浏览器中实现LBS（Location Based Service）应用——这都是手机的基本配置。而持久存储以及离线功能则为开发能与桌面应用媲美，但却在浏览器中运行的全功能应用奠定了基础。目前，就连增加多点触摸事件的实验性的库也已经出现了。凡此种种，无一不是实实在在的JavaScript特性。HTML5只是为这些高级功能的发挥提供了舞台。 退一步讲，不依赖于HTML5的浏览器端开发库也取得了长足的进步。长久以来，JavaScript一直都是在HTML中实现动态效果的不二之选。可两个问题迟迟得不到解决：一是浏览器兼容性问题，二是直接操作DOM太麻烦。jQuery让这两个问题霎那间消失得无影无踪，这个库已经成为现代基于浏览器的客户端开发的基本配置。不过，并非只有jQuery。Protovis、还有D3，都可以让你直接在浏览器中创建复杂的交互性数据可视化效果，有史以来第一次让浏览器成为了展示数据的一个重要媒介。 JavaScript与数据库，编译器与语言 就连数据库里都开始广泛使用JavaScript了！当前如火如荼的NoSQL运动的三只领头羊：CouchDB、MongoDB和Riak，都是“文档数据库”。它们保存的不是表，而是文档。这几个数据库所谓的“文档”，其实就是JSON文档，而不是Word或Excel。（Riak除了JSON文档，还支持XML和纯文本。）JSON已经成为一种被广泛采用的数据交换格式（所有现代的编程语言几乎全都有解析JSON的库），不过请注意，JSON实际上不就是一种序列化JavaScript对象的格式嘛！因此，虽然你可以在任何语言中使用JSON，但在JavaScript开发中使用它则是再自然不过的事了。况且，JSON 这个格式成为一种跨语言的标准，而不是Python、Ruby或Java等语言的序列化格式，这个事实本身足以说明JavaScript将在更加广阔的舞台上大显身手。还不仅仅如此，上述三个数据库都内置了支持JavaScript查询的能力。未来几年，更多的人都将会惊讶地发现，JavaScript和JSON还会内置到其他应用程序中！ JavaScript时代的大幕才刚刚拉开。在今年的JSConf上，一个核心主题就是“JavaScript到JavaScript的编译器”，也被人们看成是未来的一个主要趋势。Google在“编译生成JavaScript代码”方面是首开先河者。据我所知，GWT（Google Web Toolkit）应该是通过编译（从Java代码）生成JavaScript代码的第一个框架。以前我对GWT并没有太重视，只是觉得它是一个致力于拯救那些Java程序员的框架，好让他们不必因为（学习）编写JavaScript而浪费时间。可是，GWT在编译过程中对JavaScript做了那么多的优化，简直是太神了。Closure就是一个“JavaScript到JavaScript的编译器”，能够实现同样级别的优化。Traceur，这是几个星期前才冒出来的一个框架，通过它能够试验JavaScript的新特性，换句话说，它可以把带有实验性语言特性的JavaScript代码编译成可以在所有现代平台中运行的JavaScript代码。 最后，我们也开始看到了当初Java大旗下JVM语言的蓬勃景象：很多语言都在致力于编译成JavaScript！其中有一些语言比较有意思，像Coffeescript和Kaffeine，它们在风格上酷似JavaScript，但更关注弥补JavaScript的一些不够完善的地方。是不是觉得JavaScript的对象模型特有意思，可怎么看怎么有点笨笨滴，有木有？是不是一想到基于原型创建一个实际的对象都需要反反复复地定义这定义那，就望而却步了，有木有？Coffeescript对此作了明显的改进。除了完善对象模型，Coffeescript 还添加了类似列表解析（list comprehensions）的新特性，去掉了大部分花括号。就像在Python中一样，要使用缩进来区分代码块。 未来的Web服务器、取之不尽的客户端库、HTML5、数据库，乃至基于JavaScript的语言——我现在一睁眼看到的就是JavaScript！假如你曾经对JavaScript敬而远之，今年可是该学习它了。没有任何理由，真的，再不学，恐怕你就没机会跟上时代了！]]></description>
		<link>http://www.cn-cuckoo.com/2011/06/22/time-to-learn-javascript-2463.html</link>
			</item>
	<item>
		<title>MVC之父对“模型-视图-控制器”的最初定义</title>
		<description><![CDATA[出处：http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf 我创立的Model-View-Controller（MVC）模式作为一个直观的解决方案，针对的是一个一般性的问题，即让用户能够支配自己从多个角度看到的信息。MVC引起了的关注之多，让人有点始料不及。有些教材对MVC的改造甚至到了离经叛道的程度，企图达到让计算机来控制用户的悖谬目的。 而MVC的根本目的是在人类头脑中的心智模型和计算机中的数字模型之间架起一座桥梁。理想情况下，MVC的实现方案与用户直接查看和操作领域信息的直觉吻合。假如用户想在不同的上下文中以及/或者以不同的视角看到相同的模型要素，那MVC就有了它的用武之地。 模型 模型，表示知识。它既可能是一个对象（当然，如果仅一个对象就没多大意思了），也可能是由许多对象组成的结构。 模型及其组成部分是一方，而模型创建者意识中要表现的世界则是另一方，这两方应该一一对应。自然地，模型的每个节点都应该明确对应于问题的一个部分。 模型的所有节点都应该把问题解决到相同的程度，把面向问题的节点（例如，在日程中添加约会活动）与实现细节（例如，用段落展示）混在一起不容易理解，是应该避免的做法。 视图 视图是模型的（可见的）表现。视图通常会突出模型的某些属性，同时隐藏其他属性。从这个意义上讲，视图就像是一个展示过滤器。 视图依赖于模型（或模型的一部分），通过询问问题的方式从模型中获得用于展示的必要数据。视图通过发送适当的消息，也可以更新模型。这些问题和消息都要按照模型的术语来传达，由此视图必须得知道自己所要表现的模型，它的属性都有什么语义。（比如说，视图可能会询问模型的标识符，期待返回一个Text的实例，但它可能并不认为模型就是Text类。） 控制器 控制器是用户与系统之间的纽带。它为用户提供输入，即它会将相关的视图显示在屏幕适当的位置上（供用户浏览查看）。它为用户提供输出的手段，即它会向用户展示菜单以及其他能接受命令和数据的控件。控制器接收到上述的用户输出，将其转换为适当的消息，然后再将这些消息传递给一或多个视图。 控制器不应该当作视图来用，例如，不能用控制器来画箭头以连接视图的节点。 从另一方面讲，视图也不应该关心用户输入，比如鼠标操作或按键操作之类的。在任何情况下，都应该能够在控制器里编写一个方法，该方法将消息发送到视图，以便原原本本地再现用户的命令。 编辑器 控制器负责连接其所有的视图，这些视图是该控制器的组成部分。有的视图会提供一个特殊的控制器，叫编辑器（editor），以便用户通过它来修改由视图表现的信息。这种编辑器可以被挂接到控制器与其视图之间的路径上，类似于控制器的扩展。编辑完成之后，则从路径上将编辑器移除并丢弃。 注意，编辑器要通过相关视图的具体表现来与用户沟通，因此编辑器与视图是紧密相关的。控制器通过询问视图来获悉编辑器的存在，除此之外没有其他适当的信息来源。 参考 Trygve Reenskaug简介 什么是MVC模式？]]></description>
		<link>http://www.cn-cuckoo.com/2011/06/22/mvc-originals-2454.html</link>
			</item>
	<item>
		<title>编程语言教程书该怎么写: 向K&amp;R学习！</title>
		<description><![CDATA[原文地址：Lax Language Tutorials Andrew Binstock 每年在评审Jolt Awards图书的时候，我都会被一些语言教程类图书弄得心力交瘁。从这些年的评审经验来看，这些语言类教程的写得都不错，但除此之外，少有亮点。换句话来说，这些书都很严谨、很精密，如果读者有足够的定力，通过它们掌握一门语言的编程技术还是不成问题的。可是，即便对那些卖得最好的书，除此之外我都想不出来还能多说几句什么样的赞美的话了。 这些书普遍存在的一个缺点就是把简单的任务复杂化。最大的或者说最常见的一个问题，是作者们混淆了教程与一本面面俱到地介绍一门语言的专著的区别。由于种种原因，出版行业似乎特别热衷于后一种体裁，结果就导致了一些令人瞠目的大部头。我曾经看到过一本“介绍”Java语言的书，厚达1480页。如果说入门读物都得这么厚，显然是不合理的。不消说，这本书深入地讨论了一下AWT和Swing，然后笔锋一转，又给读者罗列出各种各样的第三方库，关于虚拟机的研究当然少不了，而最终则收尾于并行程序设计。谢天谢地，到这里终于全书完。鉴于这本书已经出到了眼前的第4版，有理由认为它体现了作者对它最终的心理预期。那就是，这实际上是教程兼参考书。而且，既然书的重量都达到了4.5磅（约2.04千克），我想多半也只能把它当作参考书来用了。Mark Lutz的《Learning Python》是Python语言图书中与此类似的一本。其他语言类图书中，像把Ruby介绍给西方读者的“鹤嘴锄书”（《Programming Ruby: The Pragmatic Programmers&#8217; Guide》），作为此类图书也是当之无愧。书的前一半是教程，后一半明说就是参考。这种方法就好多了。不用管其中的Ruby教程占了多少篇幅（418页），仅就其质量而言，就充分说明它大受欢迎是有理由的。 第二个常见的问题，就是作者忘了读者在打算学一门新语言的时候，最想做的是什么；当然，无非就是要写几个小程序，借以熟悉语法。然而，很多教程通篇都是只有一两行的微型代码示例，只够演示某个功能，但没有一个独立有用的程序。如果语言还有一个内置的shell（或解释器），比如像Ruby、Groovy、Scala，那这个倾向就越发地明显了。 比如说，Odersky、Spoon和Venners合著的Scala教程（《Programming in Scala》）就能清楚地反映出这个问题。在这本书的前200页里面，超过20行代码的示例只有一个；大部分都不会超过10行。[而在K&#038;R（Brian W. Kernighan和Dennis M. Ritchie）那本书（稍后会说到）里，第一个20行代码的示例出现在第26页。]结果呢，按照我自己的经验，就是看了半天书，也敲了不少代码，由此了解了不少功能，但却始终没有写出一个有点什么用的程序来。实话实说，这种现象简直太普遍了。现在，我眼前就摆着两本书，一本Clojure，一本Groovy，也都是这个套路。 最后一个问题在编辑不给力的书中经常会发现：一心只想展示一门语言的聪明技巧或者能做到的一些小hack。个人认为，读者是想来学语言的，不是来欣赏语言特技的。这个问题最常见于那些函数式语言，或者像Groovy一样有意设计得比竞争性语言（对Groovy来说就是Java）更好的语言的教程。 以上三个问题之所以让人感到难以理解，关键在于长期以来一直都有一本绝好的榜样：Kernighan和Ritchie的《C Programming Language》（K&#038;R）。拿这本书跟其他教程比一比，差异立现。先从最明显的地方开始，K&#038;R的教程部分只有177页，随后是40页的附录，附录是极其简明的参考。在这种篇幅适中的情况下，任何读者都能轻松看完，并且做完全部示例。其次，大多数程序都在20行代码以上，既有相应的用途，也不让人感到陌生，而且相对完整。即便是到了这本书的第125页左右，示例程序中都包含main()函数。这里说的可不是代码片段，而是虽短但却真实的程序。最后，书中对所有程序的解释分析十分透彻，而且前后相继，由浅入深。没有对功能漫无边际的简单罗列，所有示例都有一种内在的线索，让读者在任何时候都知道自己掌握了哪些基础知识，还需要探索哪些基础知识。 那在K&#038;R中看不到什么呢？最明显的是，书中没有解释标准库中每个函数功能的部分。Java图书也应该把这个部分删掉。（对Java知识体系介绍得最为全面的两本书，就是Horstmann和Comell合著的《Core Java》卷I和卷II。但在两卷合起来1800页的篇幅中，没有包含教程，也没有像书中所说的那样讲述。） K&#038;R也没有填鸭式的说教。看这本书必须边看边思考。所有信息都摆在那儿，但你必须动手去做每一个例子，才能理解这门语言。作者希望看这本书的读者很用心很专注，因此会在你迅速学会这门语言的过程中，随时为你提供帮助，但不会强迫你一页接一页地阅读那些对理解语言没用的东西。 恐怕有人会说，C只不过是一门小型语言，所以介绍它自然用不着大部头。要是你也这么认为，请睁开眼来看看别的C语言教程，看有哪一本书像K&#038;R这么薄，而且写得又那么好。要不然，再看看JavaScript，JavaScript也是一门小型语言，但还没有哪本书是篇幅又短，又容易理解的。 我想说明一下，前面提到的那几本书都是着意挑选出来的，因为这几本书在我看来都是相应语言领域的最佳教程。Odersky等写的Scala、Thomas写的Ruby，还有Lutz那本Python，这些都是学习相应语言的最佳起点。我只是希望这些书要是能更像K&#038;R那样就好了。 ——Andrew Binstock 《Dr. Dobb&#8217;s》主编]]></description>
		<link>http://www.cn-cuckoo.com/2011/06/05/lax-language-tutorials-2450.html</link>
			</item>
	<item>
		<title>犀牛书作者David Flanagan谈盗版</title>
		<description><![CDATA[原文链接：JavaScript: The Definitive Guide Sixth Edition pdf download ebook 每次，只要我的新书一出来，我准会因为盗版生一肚子气。为这事，我都在Twitter上发过消息了，但在Google搜索框里只有写长一点你才会发现微妙的差异。这篇文章题目是什么意思？就是Google对搜索我的书的人给出的建议。 要是有足够多的人把链接指向我这篇文章，没准搜索建议会把那些找盗版书的人都引到我这个页面，而不是盗版电子书网站 。[更新：太好了，到今天晚上为止，选择上面截图中的任何一条搜索建议，我的这篇文章都会排在那些电子书下载站点前面！庆祝一下这个象征性的胜利！] 好，下面我就想到哪说到哪，不过可不止140个字符啊，谈谈我对盗版图书的看法。 我认真看过Tim O&#8217;Reilly谈盗版的两篇文章：Tim O&#8217;Reilly on Piracy, Tinkering, and the Future of the Book和Piracy is Progressive Taxation, and Other Thoughts on the Evolution of Online Distribution。我也同意其中的一些观点。比如，默默无闻比盗版更糟糕。我知道有些作者一方面让读者免费（也是合法地）下载自己的书，一方面还能取得不错的销售业绩。我知道有些世俗小说作家搞自出版，一本书只卖99美分，同样取得了成功。（但我对那个世界知之甚少，没办法链接到其中任何一位作者。）然而，对大多数上述作者来说，“成功”的含义是“我的书卖99美分比卖3.99美元挣得还要多”。靠卖99美分一本书来养家糊口的幸运儿只是凤毛麟角。我不认为自出版定价99美分就是技术书的未来。 15年来，我完全依靠图书版税收入来维持自己和家庭的开支，也算是少数幸运作者之一了。但自从.COM泡沫破裂以后，随着出版业日益衰退，我的版税收入差不多也在稳步下降。我已经决定去找一份工作，去挣工资了。对我来说，这标志一个时代结束了。（听起来像是抱怨吗？别忘了这对我意味着什么。要是在自己的博客上都不能抱怨了，我还能到哪里去抱怨？:-)） 我不知道我的收入减少到底是不是因为盗版，或者说多大程度上因为盗版。我怀疑互联网以及从纸质书向电子书的过渡除了做到像盗版那样还能有什么可为的。但我也同样怀疑盗版的影响再大能大到哪里去。 不过，抛开无法统计的财务影响不谈，我想，我还是可以告诉大家，对我的书的盗版已经让我苦恼至极。2008年，我的Ruby书出版后一周左右，盗版就可以随便下载了，那时我就感到很悲哀。今年年初，我的jQuery参考手册上市，令我震惊的是Google居然把下载站点链接放得比这本书的评论链接还靠前。现在，JavaScript: The Definitive Guide出来了，我连样书都还没收到呢，违法的电子版就已经谁想下都能下了。而且，Google还向那些搜索这本书的人推荐那些违法的下载链接（见上面的屏幕截图）。为了写这本书，我花了不知道有多少心血，我想说，这种感觉不啻掏走了我的心肝一样。 我在Twitter上也试着挑衅过，我的那条微博写道：“难道Google支持盗版？”但我确实认为这是一个实实在在的问题。如果Google索引ebookee之类的直接包含下载链接的站点，为人们寻找盗版内容提供便利，甚至还建议人们去搜索下载链接，那么我认为就足以说明Google在鼓励盗版。而这里边最最关键的是，盗版内容那么轻易就能到手，人们就是想“做贼心虚”，恐怕都找不到理由了。Google会给恶意软件站点打上“这个站点可能伤害你的计算机”的标签，默认会把色情图书过滤掉。但对违法的电子书采取什么措施了？这些下载链接就堂而皇之地明摆在那——还不就是告诉人们，下载没错。 我知道盗版电子书无法消灭。而且，我不认为我们应该（或能够）通过严格DRM（Digital Rights Management，数字版权管理）来锁住一切。但我也认为对盗版放任自流的态度是错误的。即使出版商无法战胜盗版，他们至少应该能够据理相持，而不是甘认失败。 为此，我给出几个可能有用的小建议。 Google可以过滤自己的搜索建议项，不要积极地推荐盗版。我怀疑在有人输入某个艳星的名字时，Google会不会过滤掉建议的关键词？Google已经有了一个受版权保护图书的数据库了（Google Books），因此在有人搜索一本书时，过滤掉这些建议项应该很简单。 Google可以给那些可能链接到盗版内容的链接加上标签（不用过滤）。Google已经在给某些搜索结果加“this site may harm your [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/05/04/david-flanagan-on-piracy-2429.html</link>
			</item>
	<item>
		<title>华山论剑：世界顶尖程序员论语言及测试</title>
		<description><![CDATA[原文地址：Got Any Quotes from Coders At Work 最近，我看完了Peter Seibel的《编程人生》。哈，这是一本世界顶尖程序员和计算机科学家的访谈。看看都有谁，这些牛人在Wiki上都有自己的条目：Jamie Zawinski、Brad Fitzpatrick、Douglas Crockford、Brendan Eich、Josh Bloch、Joe Armstrong、Simon Peyton-Jones、Peter Norvig、Guy Steele、Dan Ingalls、Peter Deutsch、Ken Thompson、Fran Allen、Bernie Cosell和Don Knuth。 这本书固然非常棒，我非常喜欢，不过囿于访谈这种体裁，比较被采访人关于相同话题的观点也确实有点麻烦。但不管怎么说，作者Peter Seibel还是忠实地记录了他们的言论，所以我就想自己从这些智慧箴言中再提炼出一些真正有用的观点来。 经过一番努力，我按照自己的兴趣（静态类型和不变量）分别挑选出了一些重要的话。我这种分法未必合理，供大家参考吧。 大牛们谈“静态类型” Brad Fitzpatrick：“我也希望能够在编译时得到一些警示，希望它能提醒我‘你看看，你这都干了些什么呀’之类的。而有时候呢，我又觉得无所谓，希望在运行时再被曝光问题或者什么的。” Doug Crockford：“可是你在经典继承当中做不到这一点——你只能一味地按照抽象到实例的思维方式去想。在这个思想框架中，很难设计出合理的层次关系。等后来你真的理解了问题所在之后，你就不得不再回过头来对它进行重构。这时候再重构对代码的影响可就不是一星半点了，如果在你幡然醒悟的时候，原来的代码已经变得非常庞大了，你怎么办？” Doug Crockford：“在JavaScript中，我发现重构真是很简单的一件事。可是如果要对一个层层递进的类层次进行重构，那可就要多难有多难了。” Brendan Eich：“那些疯疯颠颠、几近白痴的话不能信，说什么动态语言终有一天会完全把Java还有静态语言取而代之，这不是混话吗？” Josh Bloch：“OO很有意思。可以从两方面看，首先就是模块化。模块化很了不起啊。不过，我倒不觉得这是OO的人的专利。……其次就是继承，而我对继承的看法跟现在很多人的看法一样，那就是继承有利也有弊。” Josh Bloch：“这个例子就说明，必须要有安全的语言。这个问题（栈溢出）本来就不是人应该考虑的事。” Josh Bloch：“我还是喜欢泛型。泛型可以帮我找出代码中的bug，可以让我把通常得写在注释里面的约定拿出来写在代码里面，然后通过编译器来保证它们得到强制遵守。” Joe Armstrong：“然后支持静态类型的人就说了，‘好，在封送数据结构的时候我们的的确确能感受到动态类型的好处。’如果你随便在网上发一段程序，如果你不知道数据类型，就没办法重建原来的数据。” Joe Armatrong：“我们缺少两类东西之间的一个协议：你发给我一个那种东西，我再发给一个这种东西，怎么办？数据包以及它们的类型有多种方式可以描述，但描述协议的方式却非常有限。” Simon Peyton-Jones：“其中一个不常提及的例子就是维护。当你面对一堆3年前写的不那么完美的代码，又想对它进行系统性地改进，怎么办？注意是系统性、全局性的改进，不是单单修改哪个例程。在这种情况下，类型系统的作用一下就显现出来了。” Simon Peyton-Jones：“只要静态类型合适，你就尽管放心地用，光从维护角度看，你就值了。” Dan Ingalls：“类型就相当于程序中的断言。我认为尽量保持事情简单很有价值，包括连类型都不必提。” Ken Thompson：“有bug就有bug呗。谁写代码都会有bug，那都是人的问题。如果说它是一种运行时安全的语言，那么遇到bug时，操作系统应该崩溃，用不着什么缓冲区溢出，也就不会被利用了。” 大牛们谈“不变量和断言” [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/04/28/got-any-quotes-from-coders-at-work-2416.html</link>
			</item>
	<item>
		<title>我的创业故事：从灵光一现到事业有成</title>
		<description><![CDATA[原文地址：My startup story: from big idea to thriving business in 8 short years 2003年夏天，我还在打理自己第一个小公司的时候，突然想到一个“好主意”：社交新闻阅读器。有点类似后来的Google阅读器加智能收件箱（Priority Inbox）和社会化推荐。我没日没夜地想着这件事，觉也睡不着了。每天人虽然躺在床上，脑子里一直在苦思冥想怎么把这个东西做出来。我可能是得了“痴心妄想症”了。“这个阅读器一定会大受欢迎！”，我想。这个想法太好了，要是你的话，恐怕你早就拿着它去招徕风险投资了。可我在温莎（Windsor），加拿大呀，硅谷对我来说太远了，再说我那时候还没听说过VC啊投资啊什么的。我只能靠自己，什么事都从头来。 2003年还没有Google阅读器，Fackbook还在娘胎里，RSS新闻源也少得可怜。找不着RSS源？不要紧，我自己来，我可以自己写一个程序，一个网站一个网站地分析，自动采集新闻或者新内容。没有Faccbook提供社交用户资料？这还真是个问题。没有这些用户，还做什么社交新闻阅读器呢。对，没有用户不行，不仅如此，用户太少也不行。看来我这个“好主意”一时半会是不太可能有结果了，为了吸引用户，我决定先做个简单的东西，免费供人们下载。我对计算机通话还有些经验，开发个小桌面应用，显示来电者的ID对我来说不过举手之劳。两个月后，PhoneTray Free呱呱坠地。 2003年我可真是熬过来的。我的第一家创业公司本来还小有成就，但很快就下滑到了破产的边缘。由于我签证上的身份，我也不能给别人做任何咨询。照直说吧，这一年我没挣多少钱，我差一点就把自己的公司扔掉，然后去找一份全职工作。幸好我妻子还有工作，我们也还有点存款，合计了一下，我们决心一块挺过去，我还接着做自己想做的事。 一方面是继续设法实现我的那个“好主意”，另一方面就是我第一家公司的一些琐事。我的PhoneTray Free也有人赏脸，肯下载了。后来，我就陆续收到PhoneTray用户的一些反馈邮件，看得出来，他们都很喜欢我这个小应用。“嘿，我们单位的头儿老给我打骚扰电话”，一封邮件里这么说，“你的程序能帮我把他屏蔽掉吗？”我想“这有什么难的？”于是就在程序里加了屏蔽特定号码的功能。没想到所有人都喜欢这个功能。PhoneTray Free一下子火了。到2004年年底那会儿，每天的下载量达到了几百次，反馈邮件也越来越多。 “我喜欢你的程序，”有一封邮件说，“可我们怎么办，我们是拔号上网用户？我们上网的时候有可能错过重要的电话！”“嗯，这是真的吗？”我想，“还有人拔号上网吗？”我用Google一搜，结果显示美国当时的互联网用户确实还有65%通过拔号的方式上网。等等，呼叫等待（modem-on-hold）和V.92标准不就是解决这个问题的吗？很明显，不是，因为我很快就找到了答案。V.92标准只是规定了如何在硬件上实现来电检测和呼叫等待，并没有对软件或者API作出规定。Windows操作系统也没有内置对呼叫等待的支持。虽然有几家调制解调器制造商也提供了支持呼叫等待的软件，但那些软件都只能在特定的调制解调器上使用。大多数调制解调器还是没有随机附送的呼叫等待软件。可不可以在PhoneTray中增加这个功能，让所有拔号用户都能在上网的时候接听电话？ 噢，这件事可不容易。要实现呼叫等待功能，没有任何标准可以参照。现有的几款软件都是使用内部API直接调用“猫”的驱动程序，当然也没有文档可查。而且不同调制解调器芯片提供商又各自有各自的API。更有甚者，某些提供商不愿自找麻烦，干脆连API都没有。这对我而言，不啻为一个挑战，但是谁不喜欢挑战呢？于是，我翻出了以前学过的讲x86汇编程序的旧书，打开自己一直不离不弃的IDA，开始从头研究调制解调器驱动程序的工作原理。我反汇编了几个驱动程序，弄明白了开发驱动程序的步骤，也知道了自己下一步该怎么做。下一步，我要自己开发一个核心驱动程序，以调制解调器的驱动程序为依托，来监控调制解调器驱动程序的行为。这样，PhoneTray就可以与我自己的驱动程序通信，进而控制调制解调器。 我说过我喜欢挑战，是吗？要是你曾经给哪个调制解调器开发过内核驱动程序，你就能体会到我要为自己这个爱好付出多大代价了。远程内核调试器、BSOD/重启、核心内存转储……，这些事儿忙得我是不亦乐乎，而我的那个“好主意”呢，早被我给抛到爪哇国里去了——至少暂时没时间想它了。为了让我的驱动程序兼容所有调制解调器，我花了5个月时间。但不管怎么说，2004年5月，PhoneTray Dialup的第一个版本终于整装待发了。这可是一个能真正解决人们问题的产品，我打算通过它收点钱。一开始，卖得并不好，而且PhoneTray Dialup本身还有一些bug，但到了2.10版，这个产品就已经非常完善了，销量也随之直线上升。 2004年底的时候，PhoneTray Dialup达到了每月几千的销量，而且还在增长。而我呢，也成了加拿大的永久居民，可以通过开展一些咨询业务挣钱了。我感觉到自己的前途真是一片光明！我接着思考自己那个“好主意”，给别人提供一些咨询，时不时地还升级一下PhoneTray Free和PhoneTray Dialup。就这样，突然有一天，一个小ISP所有人给我发了一封邮件，说是希望为他们的用户提供PhoneTray Dialup。“就是啊！为什么我就没有想到呢？”我心里暗自思忖，“这可是一个全新的市场啊！”很快，我就专门针对ISP定制开发了一个新版本，让他们可以把它当作自己的软件来提供给用户。同时，我也拉来了一个人，帮我一起推销这个新版本。两年后，这个新版本已经授权给了几十家ISP，其中最大一家是沙特阿拉伯的，有30万用户。 我们的生意越做越好，而我要处理的事也越来越多。为此，我妻子辞掉了自己的工作，加入Traysoft来帮我。我的那个好主意呢，我又忘了。眼瞅着拔号上网的经营模式渐渐日薄西山，我还得赶紧想点别的办法好继续赚钱。这些年来，我收到过不少公司发来的邮件，想请我帮他们开发PhoneTray Free的定制版。我没有打算那么做，我想让开发人员能够自己根据需求去自己开发。我把PhoneTray的核心电话功能拿出来，移植到C#上面，又添加了一些必要的东西，最后发布了一个基于.NET的电话功能库（AddTapi.NET）。这个新产品很成功，它的收入占到了我们公司收入的一半以上。PhoneTray呢，也越来越有声色，用不了多久，我们先进的电话管理软件PhoneTray Pro也要问世了。 这就是我8年以来的创业故事，现在我的小公司生机勃勃，养活我和我的家人已经没有问题了。而这个公司最早只不过是一个免费的小应用而已。什么，我的那个“好主意”怎么办？也许有一天我会实现那个梦想的，也许。]]></description>
		<link>http://www.cn-cuckoo.com/2011/04/23/a-startup-story-2409.html</link>
			</item>
	<item>
		<title>每一位想有所成就的程序员都必须知道的15件事</title>
		<description><![CDATA[原文地址：How to advance your career? Read the Passionate Programmer! 我刚看完Chad Fowler的Passionate Programmer（中文版《我编程，我快乐：程序员职业规划之道》），这本书讲的是如何在软件开发行业中取得非凡的成就。 以下是根据这本书总结的，作为程序员，要取得非凡成就需要记住的15件事。 1、走一条不一样的路 在有利于自己的市场中竞争，如果你满足于“泯然众人矣”，那恐怕就得跟那些低工资国家的程序员们同场竞技了。 2、了解自己的公司 以我在医院、咨询公司、物流企业以及大技术公司工作的经验来看，这一点所言不虚。 不同公司的运营模式差异极大。如果你理解企业的运营模式，那你就不一样了！在这家公司中（或者对客户而言），你是参与业务运营的资产，你的工作能直接产生效益！ 3、与最优秀的人为伍 很早以前，我喜欢打篮球，被分配到一个水平比较高的队里。一开始适应的确很困难，但环境的压力越大（重大比赛），我的长进也就越明显。 每个领域其实都一样：你周围人的水平（以及对你的期望）越高，你就会变得越优秀。 4、制造差异 每年学习一门新编程语言。为什么不呢？不断尝试新事物，你关注的技术种类越多，脚下的路就越宽广，你的职业生涯就会日新月异。不知道几年后Java的趋势如何？那就学习Clojure。学Ruby还是Python？这两种语言都可以试试啊。然后你才能知道哪种语言更适合某个特定的项目。看，掌握的语言多了，才能在需要的时候信手拈来吧。 5、畏惧，是最大的敌人 还是直接从书中摘一句吧：“在畏惧中做出的职业规划，很可能会让自己后半辈子就一直被‘圈禁’在小隔断里，永远不会有创造明天辉煌的时刻。没错，那样是安全，但有意思吗？” 6、要成为多面手 如果你掌握了所在领域的知识，那你只能是一名专业人士。用PHP编程？花点时间设置一台Apache服务器，让PHP和MySQL都跑起来。一直在用jQuery？试试Prototype。你懂了吧。 7、一个字：做 别指望别人过来教你该怎么做，出去，自己学着去做！ 8、找一位好老师 找一位好老师可以让你在学习技术的时候有的放矢。作者给我们讲述了别人是怎么指导他学习的（顺便说一句，作者在这本书里讲了很多个人经历的小故事，他居然从一位演奏家转行来做软件开发！）：“好好研究一下目录服务，熟悉一种UNIX变体，然后再掌握一门脚本语言。” 请记住这句禅宗谚语：“循路觅宗师，形影不相离，师知吾亦知，吾乃成宗师。” 9、主动教会别人 教会别人是一种最好的学习方式。写一篇博客能帮你搞清楚一个问题。为此，你必须先掌握很多材料，同时还要有条有理地讲给别人听（写作技能）。如书中所言：“要想知道自己是不是真的明白，你就讲给别人听听。” 10、实践，实践，再实践（训练） 只有进行大量实践（花大量的时间）才能掌握某种技术。看的很多，写的很少，遇到问题，改一改，又去读代码，……（这样下去是不行的）。 要特别警惕拖延症。其实，往往只要有了开头就好办了。 自我加压，效果会更好。我曾在一篇博客中提到帕金森定律：紧张的时限可以让你提高工作效率。为什么不把这个定律用到学习上呢，比如说在y时间内学会x？ 11、从小处入手 每天都取得一项小成果，每天都要坚持做（写在博客上？）。这样一来，你只能让自己比昨天更进步，而不能说自己比上星期进步了一点。 12、享受过程 关注当下，而不是目标，享受那些在追逐未来目标的途中可能无暇顾及的小胜利。人总要生活在当下。我享受编程的过程，就像享受编程的结果一样。 13、不要丧失危机感 越是成功，就越容易犯重大错误。永远不要忘了危机感，特别是要认识到你今天所知道的，到了明天可能就会一文不值。过去的荣耀不能保你永远无虞。 据书中所说，你最好是要让自己能够“通用”，而不要对哪种技术或哪个公司产生依赖。你所掌握的某些技能，甚至你的工作，到了明天都可能会变得毫无价值。因此要不断提高/丰富/扩展自己的技能。 14、推销自己 为某个项目贡献自己的一份力量，写一篇博客，共享自己的源代码，成为对某个社区有用的人。 当然，做这些事可能需要激情，要看你的爱好，但这些事也会间接地推广你的工作成果，证明你的实力，提高你的知名度。 15、关注市场 书中还提到了“预警极客”，也就是那些始终引领技术发展的人。这些人说过的话往往带有预见性，他们提到事物也许过几天就会成为头条新闻。关注这些人，常看他们的Twitter和博客。]]></description>
		<link>http://www.cn-cuckoo.com/2011/04/19/how-to-advance-your-career-read-the-passionate-programmer-2391.html</link>
			</item>
	<item>
		<title>NetBeans之父Jaroslav Tulach谈软件框架设计</title>
		<description><![CDATA[Interview: Jaroslav Tulach, Author of &#8220;Practical API Design&#8221; 2008-8-11 Jaroslav Tulach（见图），NetBeans之父、NetBeans API首席架构师，《软件框架设计的艺术》一书的作者。 此次访谈，Jaroslav Tulach会介绍他的这本书，并与大家分享关于设计API的一些独到见解。 你好，Jaroslav，你是不是先作个自我介绍啊？ 好，我懂。让我提到自己的是 NetBeans 之父，就是想吸引读者都来看一看这本书，对吧？ 。但是，如果一个人的名字让说英语的人完全看不懂，要想达到这个目的可不是那么简单的。我遇到这个问题可不止一次了，在设计这本书封面的时候就碰到了。想了解我的读者，下面就是我的一些背景资料。关于这本书，我想说：我在这本书里真的讲了很多有用的东西，而且我也尽了全力把枯燥的内容讲得更好玩一些。 亲爱的读者朋友， 也许你现在正在书店里，手里拿着这本书，问自己：“到底该不该买呢？”让我来告诉你：如果你写过很多代码，而且其他人要在你写的代码基础上编译他们的代码，那结论显而易见：“你早该想一想怎么设计API这个问题了，而本书就是你的得力助手。” 请注意，这可不是一本“5天掌握API设计”之类的书。而且你不可能“只用3天就能看完！”。假如你想找一本简单的参考手册，本书不属于那种类型。不过，要是你对深入了解API设计非常感兴趣，不仅仅满足于怎么设计，还想进一步搞清楚为什么那样设计，那在你把这本书放回书架之前，先听一听我的自我介绍，好吗？ 我叫Jaroslav Tulach，我是 NetBeans 的创建人和首任架构师，NetBeans不仅是一个广为人知的IDE，也是第一个用Java写的模块化的桌面应用程序框架。这本书是在我过去10年工作笔记的基础上写成的。10年来，我的工作就是设计和维护 NetBeans API，并把相关的知识传递给其他的开发人员。这本书是来自 NetBeans 核心开发一线的工作实录，其中描述了我们曾经面临的问题，对这些问题逐步深入的理解，以及我们的对策和实施结果。虽然我们的经验来自于 NetBeans 的开发，但这些经验对大多数软件项目都是非常有价值的。 掌握正确设计API的知识，是在21世纪成功实现软件项目的根本所在。希望本书能在你设计世界级API的过程中助你一臂之力！ Jaroslav Tulach http://wiki.apidesign.org/wiki/InvitationForReaders 介绍一下，为什么要写《软件框架设计的艺术》？ 原因很多。在动笔之前，我也时不时地会产生写本书的冲动。但真正促使我下决心写书，还是在一次家庭聚会上。我当时跟表弟谈到想写一本书，他问我：“既然你知道一些别人不知道的东西，也有那么多写书的素材，连出版社都是现成的……，那你还犹豫什么呢？这样不对啊，赶紧写吧！”于是，我决定联系一家合适的出版社，写作和出版这本书。 说说这本书吧。什么是API，准确地说？ “准确地说？”好吧，API就是沟通。你可能会感到意外，我说的沟通不是指开发人员与计算机之间的沟通，而是人与人之间的对话。正因为如此，“什么是API”这个问题才会有各种各样的答案。一切有助于开发人员之间沟通的东西，都可以或者说都应该称为API，比如数据库的结构、硬盘里保存文件的路径、文件的内容、应用程序监听的端口，以及服务器的URL，等等。 那这本书的读者对象就是那些设计API的人了？ 这本书适合所有希望跟其他人对话的开发人员。不用说，只要是编写代码并需要与团队其他成员共享代码的程序员，都有必要看一看这本书。我把这本书分成三在部分。第一部分介绍一些与API有关的面上的知识，包括API相关的术语及评价其质量的方法和标准。接下来的部分进入实战，讨论了不同的API设计模式。最后一部分更进一步，展示了前两部分的建议在实际中的应用、如何组织API设计团队的工作，以及需要在哪些问题前作出妥协。除了这三部分，书前书后的前言和后记为这三部分提供了背景和上下文。 读者看了这本书能学习到什么？ 我以前一位领导常说：“正确的决断源于经验，而经验源于错误的决断。”我相信，从这个意义上说，NetBeans 团队已经掌握了非常高的API设计技术。然而技术虽高明，却不是什么魔法。我们能对API设计有这样深刻的认识，完全是因为10年来犯过了许许多多的错误。读者通过看这本书，有可能会避免重犯我们犯过的错误，提高自己在设计API时的决断力。 能不能通过一个例子展示一两个建议？ 一两个建议还真是很难给，因为这样很容易让人觉得这两个建议比其他建议更重要，搞清楚这两个建议就万事大吉了。所以，我给不出两个这样的“魔法”建议。 不过，如果必须要找两个结论讲一讲，我可以推荐下面这两个： “API的第一个版本绝对不会完美” “不可能知道使用你的库的所有人” 这两个结论道出了构建带有API的库和构建内部系统之间的根本差异。API就像是星星， 一旦被人发现，就要永远悬挂在苍穹，发出永恒的光辉。星星不能突然无缘无故地从人们的视野中消失。如果一个库随便跟用户玩消失，你的信誉何在？这违背了正确设计的规则。库应该根据API设计领域的规则不断地改进。 你希望本书读者通过这本书获得哪些知识？ 各个方面的知识，我在书中讨论的都是广义的API设计命题。我相信，这些话题触及了任何API设计的本质，对开发现代软件至关重要。但大家对这个问题的重视程度还远远不够，对设计API与设计常规的内部系统有什么区别也没有认识到位。欢迎大家访问http://wiki.apidesign.org/，跟我和其他人分享自己的经验。 我注意到，越来越多的（主要的）开源库需要更多开发人员。我希望能够为所有这些框架的维护人员节省一点时间，让他们不要再重蹈我们的覆辙。希望大家积极地分享经验，而且都能使用切实有效的工作方法。这样，才能开发出更好的库，只有开发出更好的库，才能在它们基础上构建出更好的应用。 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/03/07/interview-jaroslav-tulach-2367.html</link>
			</item>
	<item>
		<title>2010年美国计算机图书市场报告五：完结篇及数字出版</title>
		<description><![CDATA[http://radar.oreilly.com/2011/02/2010-book-market-5.html Mike Hendrickson 2011-2-23 报告内容 第一部分：市场综述 第二部分：分类市场 第三部分：出版商 第四部分：编程语言 第五部分：完结篇及数字出版 下载完整版（PDF） 在最后这一部分中，我们将对前四部分作一番总结，深入了解一些畅销书作者，同时展示一些电子图书销售的数据，分析一下为什么部分电子图书的市场表现已经超过纸版图书。 首先来对本报告的前四部分作个简单的总结。 总体来看，2010年美国图书市场的总销量比2009年下降了4.54%。技术图书市场下降了6.46%，技术书出版商比其他同行承受了更多的压力。然而，与2009年技术图书市场下降13.05%相比，这已经是一个进步了。市场趋势的季节性特征仍然十分明显，2010年初的市场快速启动，到了6月份开始骤降，到了秋季又恢复正常。在Bookscan Top 3000中，2010年计算机类图书比2009年增加了268种（包括不同版权年份出版的图书），而2009年比2008年增加了260种，相当于年增长率为3.5%。单品平均销量从2009年的39.64册下降到2010年的37.92册。根据数据统计，2010年少出版图书104种，但单品平均销量增加了6册。注意，这些图书的出版年份都是2010年。 移动开发类图书成为市场主力军。Android编程和Android设备（面向用户）类图书都有极大的增长，而iOS和Objective-C的市场份额进一步扩大。Windows 7的表现也相当不俗，重现了原来Windows XP曾经达到过的市场份额（Vista从未达到过）。平板电脑异军突起，成为2010年底的一大亮点。在多款Android平板电脑即将上市的背景下，有理由相信平板电脑图书市场一定会继续高歌猛进。另一方面，网页制作、Web设计工具以及Web编程类图书都明显下滑。由于Snow Leopard的突破没有前几个版本的OS那么大，Mac OS图书市场多年来首次出现下滑。Flash和Silverlight的市场也有较大幅度的下滑，原因是HTML5能够提供类似的功能，导致了它们的市场关注度下降。 从出版商的角度看，O&#8217;Reilly在2010年底爬升至第二位，位居Wiley之后，以微弱优势领先于Pearson。O&#8217;Reilly和Dummies这两家出版公司涉足的出版门类最为多样，而它们在6大技术门类中的表现也非常令人瞩目。至于最受欢迎的图书，从码洋来看是PMP Exam Prep, Sixth Edition: Rita&#8217;s Course in a Book for Passing the PMP Exam，从销量来看是Windows 7 For Dummies。2009和2010年的最热门语言都是Java，JavaScript和VBA在2010年也增长了不少。简单的回顾到此为止。 下面我们把注意力转移到出版背后的最重要因素——作者上面。作者是实际创造各种内容的人。作者的类型也很多。有的实际上很像小型的出版工作室，让其他“合著者”完成大部分写书工作；有的则从头到尾大包大揽，从编辑、写作、测试到编写代码，全都自己干，等书出版之后，还会参与推广、活动和销售。后一类作者的活动决定了我们所说的“作者平台”。有些作者凭自己的名气或自己的全职工作，拥有一个稳定的平台。而另外一些作者则不得不苦心经营，不断培养自己的平台。在我们数据库中，最成功的作者都解决了前期内容生产和后期发行销售的问题。在对前15位作者的数据（实际上，他们书的销量和码洋还会更多）进行分析的基础上，可以得到下列两张柱形图，其中展示的是2004-2010年的图书总销量和总码洋情况。 总销量 总码洋 2010年，Paul McFedries的名字出现在了58本不同的图书上（出版日期从2001年到2010年），反映在我们的数据中，这些书的总销量为112,152册。他的书在2010年卖得最好，2010年他有12本新书出版，这是我们的数据。他的总销量比David Pogue多20,000册，后者在我们的数据中有13本书出版，总销量为92,000册。从单品平均销量看，Pogue是7,000册，而McFedries只有1,900册。销量前5名中的其他三位作者是：Andy Rathbone、Greg Harvey和Dan Gookin。如果从码洋的角度来看，前5名的作者从多到少分别是：Paul McFedries、David Pogue、Andy Rathbone、Rita Mulcahy和Scott Kelby。 电子书发行与销售 好了，说完了2010年纸质书的销售情况，接下来就看一看至少已经部分脱离传统发行渠道的电子书的发行情况。下面这张表显示的是2008年的电子书销售情况，数据来源于AAP（Association [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/02/26/2010-book-market-of-usa-5-2279.html</link>
			</item>
	<item>
		<title>2010年美国计算机图书市场报告四：编程语言</title>
		<description><![CDATA[http://radar.oreilly.com/2011/02/2010-book-market-4.html Mike Hendrickson 2011-2-21 报告内容 第一部分：市场综述 第二部分：分类市场 第三部分：出版商 第四部分：编程语言 第五部分：完结篇及数字出版 下载完整版（PDF） 这是《2010年计算机图书市场报告》的第四部分，我们来看一看编程语言市场，对各种编程语言作一备盘点。 与2009年相比，2010年编程语言市场总体下滑，幅度为-6.27%。从销售总量看，2009年图书共售出6,303,125册，而2010年共售出5,931,452册，减少了371,673册。其中，Java语言类图书销量增长最多，2010年比2009年多售出28,633册，而PHP语言类图书销量降低最多，比上一年减少了38,614册。 在盘点各种语言之前，有必要先明确一下“语言维度”这个概念。语言维度是我们对语言类图书进行分类的一个标准，这个标准就是看图书中的代码示例是使用什么语言编写的。比如，Flash Programming with Java这本书，它的基本分类是Flash，但按语言维度分，则属于Java类。同样，Head First Design Patterns中的示例是用Java写的，因此按语言维度分，这本书也属于Java类。 综合来看，2009和2010年编程语言类图书的市场表现是最糟糕的。下面这张图中不包括谈方法论的、项目管理的、消费者操作系统的，以及其他不涉及具体语言的图书。因此，我们现在对编程语言类图书的分析，与本报告第一部分的总体评价出发点是不一样的。这张图显示的是以周为单位的所有语言类图书的市场表现情况，其中2009年和2010年与其他年份比，依旧是最差的。 2008年，我们在报告中分析C#超过Java成为了最热门的语言。但时隔不久，Java图书就在2009年发力反弹，终于在2010年王者归来，重新登上编程语言图书第一位的宝座。通过下面这张2010年最畅销语言的柱状图可以看出，Java在这些语言里遥遥领先，而Objective-C则迅速攀升至第三位，仅次于C#。 2010年市场份额 再看看下面这张图，哪些语言的图书对2004年至2010年的码洋贡献最大可以一目了然。比较新的语言，或者说“时尚”的语言，由于时间太短，它们市场表现如何一时可能还看不出来。这张表基本上根据这些语言在相应时间段内的实际销量绘制的。其中，前10位的图书7年总共销售7,655,365册，后10位的图书7年总共销售1,919,691册。从份额来看，前10位大约占80%。从这些语言7年来的趋势看，C#在2009年之前一直是稳步增长的，Java则正好相反，2009年之前它的市场表现是越来越差的。2009到2010年，除了Java、VBA、VBScript、SAS、JavaScript、C++和C呈现上升态势，其他13门语言的销量都减少了。 编程语言类图书市场表现的Treemap 在上面这张Treemp图中，我们对比的是2010年第四季度和2009年第四季度，两年的同期相比，可以看到不少亮绿色区域、几块深绿色区域，黑色及红色区域也占相当面积。Objective-C之所以会下降12%，因为它在2009年的表现实在太好，很难维持。但由于它的在图中面积很可观，结果就让这张图显得有些压抑了。 深入数据分析之前，我们先了解一下这些语言的总体情况。首先，对它们进行了分组，分组依据是它们在2004-2010年间的总销量。通过下面这张表就可以看出来，只有Mid-Majo组的销量在2010年是增长的，其他组的销量都在减少。而Mid-Major组中销售增长幅度最大的是R。有意思的是，像R这样的统计分析语言基本上都在增长（和Strata大会的结论类似）。实际上，R、SAS、Matlab、Labview、Mathematica以及SPSS这些语言加在一起，总共增长了49,504册，增幅达到了102.87%。也许是因为Hal Varian关于统计将成为“最有前途的工作”的论调，刺激了开发人员都去学习这些语言。 Group Unit Range Y2010 Units Y2009 Units Y2010 # Y2009 # 10MketShar 9MketShar Large 50,000 &#151 200,000 1,051,945 1,069,762 1,590 1,433 75.96% 75.00% Major 10,000 &#151 49,000 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/02/25/2010-book-market-of-usa-4-2265.html</link>
			</item>
	<item>
		<title>2010年美国计算机图书市场报告三：出版商</title>
		<description><![CDATA[http://radar.oreilly.com/2011/02/2010-book-market-3.html Mike Hendrickson 2011-2-17 报告内容 第一部分：市场综述 第二部分：分类市场 第三部分：出版商 第四部分：编程语言 第五部分：完结篇及数字出版 下载完整版（PDF） 这一部分主要以2009年作为对比分析2010年出版商的经营情况。下面两张饼图展示了2009年和2010年各大出版商的经营业绩。最值得注意的是，Wiley继续稳坐最大出版商的位置（占图书销售量份额的32%），而Pearson和O&#8217;Reilly各掉了1%，分别被Cengage和McGraw Hill拿走。（后面将会分析收入份额。） 2009 Pub Share 2010 Pub Share 可能有人不太熟悉这些排名靠前的出版商，那是因为这些大型出版集团几年来收购、成立、拆分出了很多小出版公司。而往往这些小出版公司才是读者心目中最熟悉的品牌。比如说，你买了一本Peachpit或Sams出的书，书脊上印的都是Peachpit和Sams，而非Pearson，但后者拥有前两家出版公司。对O&#8217;Relly来说，任何不打“O&#8217;Reilly”标志的出版公司都是他们的发行合作伙伴，而不属于O&#8217;Reilly。至于构成各大出版商的小出版公司的市场份额，也会在本文后面以饼图的形式详细给出。 下面来看一下各大出版商两年的市场表现情况。以下表格中包含了几组有趣的对比性数据。 Publisher 2010 Units 2009 Units 2010 Title Count 2009 Title Count 2010 Efficiency 2009 Efficiency Wiley 1,887,493 1,904,859 1,538 1,468 1.65 1.61 O&#8217;Reilly 1,404,607 1,577,838 1,145 1,185 1.65 1.65 Pearson 1,386,301 1,511,855 1,934 1,936 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/02/23/2010-book-market-of-usa-3-2270.html</link>
			</item>
	<item>
		<title>2010年美国计算机图书市场报告二：分类市场</title>
		<description><![CDATA[http://radar.oreilly.com/2011/02/2010-book-market-2.html Mike Hendrickson 2011-2-14 报告内容 第一部分：市场综述 第二部分：分类市场 第三部分：出版商 第四部分：编程语言 第五部分：完结篇及数字出版 下载完整版（PDF） 在这一部分，我们按照技术门类来分析一下计算机图书的销售情况。 在上一部分，我们把数据分成六大“门类”：系统与程序设计、Web设计与开发、商业应用、数字媒体应用、消费者操作系统与设备、IT人文（Computer Topics）。 这六大门类下面，是一级分类、二级分类、三级分类、四级分类，一共5层。比如说，系统与程序设计门类下面的一级分类有编程语言、数据库、软件工程、通用程序设计、安全，等等。 本部分将对比2010年与2009年的第四季度，也会将2010年与2009年的情况进行对比。 为了方便起见，下面给出了上一部分中展示过的Treemap，其中包含各个门类与一级门类2010年与2009年第四季度的对比。 这张图中的红、绿、黑色方块基本上反映了市场的波动情况。其中，代表高度增长领域的浅绿色方块非常少。但不要忘了这是2010年第四季度与2009年第四季度的对比。两个最大、最亮的绿色区域是“Android编程”和“Android消费者应用”，这两类图书从2008年微不足道的小方块成长为2010年相当可观的大市场。 下面的两张图可以反映出各图书门类历年的增长情况。第一张图是历年构成Top 3000的图书品种，而第二张图是历年来的图书销量。从中可以看出，“商业应用/人文”和“系统与程序设计”类图书的品种在2010年都增加了，但这两类图书的销量却是双双下跌的。“消费者操作系统与设备”是唯一一个出书品种和销量在2010年双增的门类。“系统与程序设计”是最大的一个门类，但其销售业绩也更加不稳定，2010年经历了最大的一次整体下滑。“系统与程序设计”是计算机图书市场的风向标，计算机（纸质）图书市场整体也是下滑的。在随后关于数字发行的部分中，我们还会展示一些更积极的信息。 历年的图书品种 历年的图书销量 下面这张表格列出了各个门类2009年到2010年的增长情况（YoY）、2009和2010年的排名情况（09Rand/10Rank）以及2009、2010年的市场份额百分比（09Share/10Share）。 门类 YoY Growth 09Rank 10Rank 09Share 10Share 商业应用 -05.10% 2nd 2nd 20.60% 21.00% IT人文及其他 04.09% 6th 6th 02.82% 03.15% 消费者操作系统 04.22% 4th 3rd 15.44% 17.27% 数字媒体 -18.32% 5th 5th 10.66% 09.65% 系统与程序设计 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/02/22/2010-book-market-of-usa-2-2329.html</link>
			</item>
	<item>
		<title>2010年美国计算机图书市场报告一：市场综述</title>
		<description><![CDATA[http://radar.oreilly.com/2011/02/2010-book-market-1.html Mike Hendrickson 2011-2-10 报告内容 第一部分：市场综述 第二部分：分类市场 第三部分：出版商 第四部分：编程语言 第五部分：完结篇及数字出版 下载完整版（PDF） 自从上一次计算机图书市场报告发表之后的两年来，技术图书市场经历了一些重大的变化。恐怕不少读者根据图书市场日益疲软的征兆，已经看到未来发展的某些趋势了。实际上，我们早就断言过计算机图书销售情况预示着技术发展的趋势，大家也可以搜索一下有关计算机图书市场的其他文章。 本报告的数据来自Bookscan每周监控到的Top 3000图书的销售情况。Bookscan计量的是书店收银机的实际销售数据。换句话说，只要你在美国的书店里买过一本技术书，那么你购买这本书的信息十有八九已经进入了Bookscan的数据库里。Borders、Barnes &#038; Noble以及Amazon等零售商实现了绝大多数技术图书的销售。 图书市场业绩综述 在讨论细分的计算机图书市场之前，我们先来了解一下截止到2011年1月2日这个周末，整个图书市场的表现情况。下面这张表涵盖了从The Girl with the Dragon Tatoo and Eat, Pray, Love to Decision Points到The Ugly Truth的所有图书，只要是印刷、装订并以书的形式销售的，都包含在里面。 整体图书市场表现（所有图书，数据截止日期2011年1月2日） 所有图书，所有题材 青少年非虚构 -0.44% 青少年虚构 -3.46% 青少图书整体 -2.88% 成人非虚构 -1.91% &#160;&#160;&#160;&#160;计算机及互联网 -3.99% 成人虚构 -7.20% 其他 -13.12% 整体市场 -4.54% 从表中可以看出，计算机图书市场较上年下滑了4%。需要注意的是，计算机图书的销售量只占实体和在线书店所有图书总销量的1%。下面这张图展示的整体图书市场各门类的业绩增长情况。其中，幽默（Humor）类图书的增长在普遍低迷的市场背景下显得独树一帜（14.45%）。另一个增长的领域是青少年非虚构类中的教材/教辅类（21.55%）。我很奇怪，为什么教材/教辅类图书居然有这么高的增长率。 整体图书市场增长情况 下面言归正传，看看技术图书市场。下面这张柱形图展示的是各年份累计图书销量的对比情况。从图中可以看出，每年的总销量从2007年开始逐年递减。2007年的时候，不少人认为市场会中止2001年以来一路下跌的态势，开始进入恢复期，但2009年较上一年的跌幅达到了历年最大值。 而下面这张折线图展示的是自2004年以来计算机图书市场每周的市场表现情况（根据我们从Bookscan获得的第一手数据生成）。请注意，这个图反映的是所有出版商，而不仅仅是O&#8217;Reilly。图中稍粗一点的红线表示2010年的数据。 从图中可以看出，我们提到过的明显的季节性特征依然存在。换句话说，每年开始都会强势上扬，然后一直到夏季逐步走低，到了秋天“返校”的季节开始止跌回升，到了年底又强势收尾。图中每年的趋势线都与上一年的趋势线非常接近，甚至连每周的涨跌都十分一致。在24个月来乏善可陈的市场表现中，唯一能让人感到一点慰藉的是，2009年每周销量与上一年度比有10-15%是下降的，而这个比例在2010年减少到了3-6%。但这能说明市场已经见底了吗，还是说我们也像读者思考着怎样才能学到新技术一样处于观望状态？如今，销售图书的方式更多了（后面几部分中会介绍），不少出版商通过不同数字格式来销售相同的内容实现了码洋与销量的双增长。而有些出版商纸质书发行量的降低，也通过数字发行和销售得到了补偿。 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/02/21/2010-book-market-of-usa-1-2287.html</link>
			</item>
	<item>
		<title>现代浏览器揭秘（草）</title>
		<description><![CDATA[原文地址：How browsers work 简介 Web浏览器恐怕是用户最多的软件了。本文将介绍浏览器的工作原理。想知道从你在地址栏中输入“google.com”，到窗口中显示Google主页的过程中都发生了什么？本文会为你揭开这个秘密。 要讨论的浏览器 今天，人们主要使用5种浏览器：Internet Explorer、Firefox、Safari、Chrome和Opera。这篇文章的分析源自开源浏览器——Firefox、Chrome和Safari，Safari是部分开源的。根据W3C对浏览器使用情况的统计信息，当前（2009年10）Firefox、Safari和Chrome共同的市场占有率已接近60%。因此，可以说开源浏览器已经占据了浏览器市场的半壁江山。 浏览器的主要功能 浏览器的主要功能就是呈现你选择的网络资源，换句话说，就是你向服务器请求资源，然后浏览器把它们显示在自己的窗口中。资源的格式通常是HTML，当然也有PDF、图像等等。资源的位置是使用URI（Uniform Resource Indentifier，统一资源标识符）来指定的。与此相关的内容在后面讨论网络的时候还会详细介绍。 浏览器如何解释HTML文件是由HTML和CSS规范规定的。这些规范是由W3C（World Wide Web Consortium，万维网联盟）维护的，W3C是负责制定Web标准的组织。 HTML当前的版本号是4（http://www.w3.org/TR/html401/），HTML5还在制定中。CSS当前的版本号是2（http://www.w3.org/TR/CSS2/），CSS3也正在制定过程中。 多少年来，浏览器厂商各自为战，纷纷埋头开发自己的扩展，对规范的支持始终不给力。结果就给Web开发人员带来了生死攸关的兼容性问题。而今天，大多数浏览器对规范的支持程度仍然参差不齐。 浏览器的用户界面大同小异，其中相同的界面元素包括： 用于输入URI的地址栏 后退和前进按钮 书签选项 用于刷新和停止加载当前文档的刷新及停止按钮 返回主页的主页按钮 说来也怪，并没有哪个正式公布的规范对浏览器的用户界面作出规定，浏览器目前的外观是多年来浏览器厂商之间互相模仿和不断改进的结果。HTML5规范中没有定义浏览器必须具备的UI元素，但列出了一些公共元素，其中就包括地址栏、状态栏和工具栏。当然，有些浏览器还有自己专有的一些功能，如Firefox的下载管理器。相关的更多内容将在后面讨论用户界面时介绍。 浏览器的主要构成 以下是构成浏览器的主要组件（参考1.1）。 1、用户界面——包括地址栏、后退/前进按钮、书签菜单等等，也就是除了显示所请求页面的主窗口之外的其他所有部分。 2、浏览器引擎——用于查询和操作呈现（rendering）引擎的接口。 3、呈现引擎——负责显示请求的内容，例如请求的内容是HTML，它就负责解析HTML和CSS并将解析后的内容显示到屏幕上。 4、网络模块——用于完成网络调用，如HTTP请求。具有平台中立的接口和针对不同平台的底层实现。 5、UI后端——用于绘制基本的组合选择框及对话框之类的基本部件。具有不特定于某个平台的界面样式，在底层使用的是操作系统的用户界面方法。 6、JavaScript解释器——用户解释和执行JavaScript代码。 7、数据存储模块——属于持久层；浏览器需要在硬盘中保存各种数据，如Cookie。HTML5还为客户端存储定义了新的技术。 图1 浏览器的主要组件 需要特别指出的是，Chrome会为每个新建的标签页创建一个新的呈现引擎的实例，并且每个标签页也运行在独立的进程当中，这一点与其他浏览器不一样。对构成浏览器的这些组件，我们会逐一详细讨论。 组件之间的通信 Firefox和Chroem都具有联系各个组件的组件。后面也将讨论这些组件。 呈现引擎 呈现引擎主要负责……呈现，也就是把请求的内容显示到浏览器屏幕上。 默认情况下，呈现引擎可以显示HTML和XML文档以及图像。而借助插件（一种浏览器扩展）它还可以显示其他类型的内容，比如使用PDF阅读器插件可以显示PDF。后面我们还会专门讨论插件和扩展，但这里我们只讨论呈现引擎的主要用途——显示使用CSS格式化之后的HTML及图像。 呈现引擎 前面提到的浏览器（Firefox、Chrome和Safari）是构建在两个呈现引擎之上的。Firefox使用Gecko——Mozilla自己开发的一个呈现引擎；Safari和Chrome都使用Webkit。 Webkit是一个开源的呈现引擎，最早是为Linux平台开发的，后来由苹果公司移植到Mac和Windows平台。有关内容请参考http://webkit.org。 主流程 呈现引擎首先通过网络层取得被请求文档的内容。通常是以8K分块的方式完成。 取得内容之后，呈现引擎的基本工作流如下图所示： 图2 呈现引擎的基本工作流 呈现引擎会开始解析HTML文档，并将HTML标签转换成“内容树”中的DOM节点。然后，它开始解析样式数据，包括外部CSS文件和style元素中的样式。解析后的样式信息，再加上HTML中的视觉指令，将被用于创建另一个树——呈现器树。 呈现器树中包含着各种矩形，每个矩形都有颜色和大小等属性。这些矩形都按照显示在屏幕上的顺序排列好了。 在构建完呈现器树之后，呈现引擎要完成一个“布局”过程。在这个过程中，它会精确地确定每个节点在屏幕上出现时的坐标。紧接着的一个阶段就是绘制——遍历呈现器树，并使用UI后端层将所有节点逐个绘制出来。 上述过程是逐步完成的，认识到这一点很重要。为了获得更好的用户体验，呈现引擎会尽可能早地将内容呈示到屏幕上。换句话说，它不会等到把所有HTML标签都解析完毕之后再去构建和布局呈现器树，而是解析完一部分内容，就显示一部分内容；与此同时，剩余内容可能还在通过网络不断下载的过程中。 主流程示例 [...]]]></description>
		<link>http://www.cn-cuckoo.com/2011/02/18/how-broswers-work-2257.html</link>
			</item>
	<item>
		<title>解构JavaScript库：jQuery、Prototype、Mootools</title>
		<description><![CDATA[JavaScript库“解构”系列旨在以可视化和可交互的方式剖析JavaScript库的源代码，包括 jQuery、Prototype 和 MooTools。 通过将 JavaScript 源代码以可见块元素的方式标记出来，可以更方便查找和学习。点开每个块元素，即可查看相应的代码。点击代码中的链接，即可在程序流中纵情畅游。 ——Dave Stewart 这么好的东西，还用多说吗？你懂的。（见下图） 唯一需要说明的是，Dave Stewart原创的这个JavaScript库解构系列不知何故被挡在“墙”外头了，我只是把它搬到了“墙”里面来而已。换句话说，这个解构系列并非出自我手，我只是在自己的站点上提供了它的一个镜像，以方便“墙”内的JavaScript学习者参考。 现在就开始：解构JavaScript库!]]></description>
		<link>http://www.cn-cuckoo.com/2011/01/06/javascript-libraries-deconstructed-2231.html</link>
			</item>
	<item>
		<title>HTML5设计原理</title>
		<description><![CDATA[Jeremy Keith在 Fronteers 2010 上的主题演讲 特别感谢以下朋友指出翻译错误。 rukey67指出了一个翻译错误（另一个没有翻错）。 梁海指出了一个翻译错误。 小乐指出了一个错别字。 Rui指出了一个错别字。 Gavin指出译文少了一个“是”字。 下载PPT（PDF） 观看视频 今天我想跟大家谈一谈HTML5的设计。主要分两个方面：一方面，当然了，就是HTML5。我可以站在这儿只讲HTML5，但我并不打算这样做，因为如果你想了解HTML5的话，你可以Google，可以看书，甚至可以看规范。 实际上，确实有人会谈到规范的内容。史蒂夫·福克纳（Steve Faulkner）会讲HTML5与可访问性。而保罗·艾里什（Paul Irish）则会讲HTML5提供的各种API。因此，我今天站在这里，不会光讲一讲HTML5就算完事了。 说老实话，在正式开始之前，我想先交待清楚我所说的HTML5到底是什么意思。这话听起来有点搞笑：这会子你一直在说HTML5，难道我们还不知道什么是HTML5吗？大家知道，有一个规范，它的名字叫HTML5。我所说的HTML5，指的就是这个规范。但问题是，有些人所说的HTML5，指的不仅仅是这个规范，还有别的意思。比如说，用HTML5来代指CSS3就是一种常见的叫法。我可不是这样的。我所说的HTML5，不包含CSS3，就是HTML5。 类似的术语问题以前也有过。Ajax本来是一种含义明确的技术，但过了不久，它的含义就变成了“用JavaScript来做一切好玩的东西”。这就是Ajax，对不对？今天，HTML5也面临同样的问题，它本来指的是一个特定的规范，但如今含义却成了“在Web上做一切好玩的事。”我说的不是这种HTML5，不是这种涵盖了最近刚刚出现的各种新东东的HTML5。我说的仅仅是规范本身：HTML5。 刚才已经说了，我今天想要讲的内容不多，也没有打算介绍HTML5都包含什么。今天我要讲的是它的另一方面，即HTML5的设计。换句话说，我要讲的不是规范里都包含什么，而是规范里为什么会包含它们，以及在设计这个规范的时候，设计者们是怎么看待这些东西的。 设计原理 设计原理本质上是一种信念、一种想法、一个概念，是你行动的支柱。不管你是制定规范，还是制造一种有形的物品，或者编写软件，甚至发明编程语言。你都能找到背后的一个或者多个设计原理，多人协作的任何成果都是例证。不仅仅Web开发领域是这样。纵观人类历史，像国家和社会这样大规模的构建活动背后，同样也有设计原理。 就拿美国为例吧，美国的设计原理都写在了《独立宣言》中了。 我们认为这些真理是不言而喻的，人人生而平等，造物主赋予了每个人不可剥夺的权利，包括生存、自由和追求幸福。 这里有一句口号：生存、自由和追求幸福。这是被写进宪法中的核心理念，它关系到我们所有人的一切，也就是我们构建自己社会的原则。 还有一个例子，就是卡尔·马克思（Karl Marx），他的著作在20世纪曾被奉为建设社会主义的圭臬。其基本思想大致可以归结为下面这条设计原理： 各尽所能，各取所需。 这其实就是一种经济体系背后的设计原理。 还有一个例子，比前面两个的历史更久远一些，不过大同小异： 人人为我，我为人人。 这个极为简单的设计原理，是两千年前的拿撒勒犹太人耶稣基督提出来的。而这条原则成为了后来许多宗教的核心教义。原理与实践有时候并不是同步的。 下面是小说中的一个例子。英国小说家乔治·奥威尔（George Orwell）笔下的《动物庄园》，就是在一条设计原理的基础上构建起来的虚拟社会。这条设计原理是： 四条腿的都是好人，两条腿的都是坏蛋！ 《动物庄园》中有意思的是，随着社会的变迁——变得越来越坏，这条设计原理也跟着发生了改变，变成了“四条腿的都是好人，两条腿的就更好了。”最关键的是，即使是在虚构的作品里，设计原理都是存在的。 还有一套虚构的作品是以三条设计原理为基础构建起来的，那就是美国著名小说家艾萨克·阿西莫夫（Issac Asimov）的机器人经典系列。阿西莫夫发明了机器人学这个术语，并提出了机器人学三大法则，然后在这三个简单的设计原理基础上创作了一系列经典作品——大约有50本书。无论作品的情节如何变化，实际上都是从不同的角度来阐释这三大设计原理。我想，在座各位对机器人三大法则都不应该陌生。 机器人不得伤害人类，或袖手旁观人类受伤害。 机器人必须服从人类命令，除非命令违反第一法则。 机器人必须自卫，只要不违背第一和第二法则。 这些恐怕是第一次出现在小说中的针对软件的设计原理了。虽然基于这三个设计原理的软件运行在虚构的机器人的“正电子脑”中，但我想这应该是软件设计原理的事实开端。从此以后，我们才看到大量优秀软件背后的设计原理。 蒂姆·伯纳斯-李（Tim Berners-Lee），Web的发明者，在W3C的网站上发表过一份文档，其中有一个URL给出了他自己的一套设计原理。这些设计原理并不那么容易理解，不仅多，而且随着时时间推移，他还会不断补充、修改和删除。不过我还是觉得把自己认同的设计原理写出来放在某个地方真是个不错的主意。 实际上，CSS的发明人之一伯特·波斯（Bert Bos），也在W3C的网站上放着一份文档，其中讲的都是基本的设计原理，比如怎样设计并构建一种格式，无论是CSS还是其他格式。推荐大家看一看。 只要你在W3C的站点中随便找一找，就可以发现非常多的这种设计原理，包括蒂姆·伯纳斯-李个人的。当然，你还会看到他从软件工程学校里借用的一些口号：分权（decentalisation）、容忍（tolerance）、简易（simplicity）、模块化（modularity）。这些都是在他发明新格式的时候，头脑中无时无刻不在想的那些关键词。 在座各位对蒂姆·伯纳斯-李的贡献都是非常熟悉的，因为大家每天都在用。他发明了Web，与罗伯特·卡里奥（Robert Cailliau）共同发明了Web，而且在发明Web的同时，也发明了我们每天都在Web上使用的语言。当然，这门语言就是HTML：超文本标记语言。 HTML HTML最早是从2.0版开始的。从来就没有1.0版。如果有人告诉你说，他最早是从HTML 1.0开始使用HTML的，那他绝对是在忽悠你。从前确实有一个名叫HTML Tags的文档，其中的部分标签一直用到现在，但那个文档并非官方的规范。 使用标签、尖括号、p或h1，等等，并不是蒂姆·伯纳斯-李首创的想法。当时的SGML里就有了这些概念，而且当时的CERN（Conseil Europeen [...]]]></description>
		<link>http://www.cn-cuckoo.com/2010/10/21/the-design-of-html5-2151.html</link>
			</item>
	<item>
		<title>从HTML 2.0到HTML5</title>
		<description><![CDATA[原文链接：A Brief History of Markup 2010年9月23日校毕 HTML是World Wide Web上统一的语言。使用它所提供的标签，人类已经创建了令人惊奇、姿态万千的超链接的文档网络。看看Amazon、eBay和Wikipedia，再看看个人博客和专为猫咪建立的站点，无一不是HTML的杰作。 HTML5是这门通用语言的最新版。虽然这次升级的变化之大史无前例，但HTML更新换代已经不是第一次了。这门语言从诞生之日起一直在发展。 在发明Web的同时，Tim Berners-Lee先生创造了HTML（HyperText Markup Language，超文本标记语言）。1991年，他写了一篇名为“HTML Tags”的文档（另见更早的www-talk上的记录），其中建议人们使用20来个元素编写网页。 说到用尖括号包围文本的标签，并不是Tim先生的首创。更早的SGML（Standard Generalized Markup Language，标准通用标记语言）中就开始使用这种标签了。Tim先生当时并没有发明新语言，而是着眼于利用已经存在的技术——在HTML5的发展过程中，这个倾向依然得到了体现。 从IETF到W3C：HTML 4诞生记 HTML 1？这个版本实际上是不存在的。最早的HTML官方规范，是由IETF（Internet Engineering Task Force，因特网工程任务组）发布的HTML 2.0。这一规范中的许多特性，都是在已有实现的基础上归纳总结出来的。比如说，1994年居于市场领导地位的Mosaic浏览器提供了一个&#60;img&#62;标签，作者可以通过它在自己的文档中嵌入图像。后来，img元素就出现在了HTML 2.0中。 W3C（World Wide Web Consortium，万维网联盟）继IETF之后成为HTML后续标准的制定者，其官方网站是http://www.w3.org。20世纪90年代中期以后，W3C对HTML进行了几次升级，直至1999年发布HTML 4.01。 此时，HTML的发展走到了一个十字路口上。 XHTML 1：符合XML标准的HTML HMLT 4.01之后的一个修订版变成了XHTML 1.0。其中，X表示“eXtreme”（极端）。当时的Web开发人员在提到这个字母的时候，必须双臂交叉，作出一个X的形状来。 谁说的？纯属瞎掰。那个X表示的是“eXtensible”（可扩展），而且也没人要求你必须双臂交叉。 XHTML 1.0规范的内容与HTML 4.01完全相同，没有添加任何新元素或新属性。这两个规范唯一的差别就是对HTML的语法作出了不同的规定。HTML给予了作者最大的自由度，他们可以按照自己的意愿去写元素和属性，但XHTML要求作者遵从XML规则；XML是W3C大多数技术规范的基础，是一种更为严格的标记语言。 语法规则变得更严格了，这本身没有什么坏处。新规范的目的就是让作者按照统一的风格来编写标签。此前的标签和属性可以是大写、小写，或者任意大小写字母的组合，而有效的XHTML 1.0文档则要求所有标签和属性必须一律小写。 XHTML 1.0发布的时候恰逢浏览器普遍开始支持CSS。开发人员意识到了Web标准的出现，特别是在Web标准项目（The Web Standards Project）的倡导下，XHTML规定的这种更严格的语法被看成是写标记的“最佳实践”。 然后，W3C发布了XHTML 1.1。 虽然XHTML 1.0只不过是用XML来重新表示的HTML，但XHTML 1.1却是真正的、纯粹的XML。这意味着不能以text/html这样的MIME类型来提供XHTML [...]]]></description>
		<link>http://www.cn-cuckoo.com/2010/09/22/a-brief-history-of-markup-2079.html</link>
			</item>
	<item>
		<title>足够好的革命：便宜简单恰到好处</title>
		<description><![CDATA[原文：The Good Enough Revolution 2001年，Jonathan Kaplan和Ariel Braunstein注意到摄像机市场中一种奇怪的现象。高端数字相机市场增幅最大，但销量最大的仍然是便宜、一次性的胶卷相机。那一年，美国总共卖出了1.81亿台一次性相机，而数字相机只有大约7百万台。瞅准这个机会，Kaplan和Braunstein组建了一家名为Pure Digital Technologies的公司，尝试把昂贵的数字成像的“巧克力”，与走到哪拍到哪的这种大众市场的“花生奶油”混合起来，创造一种新产品。他们给自己第一款产品起的名字叫Single Use Digital Camera（单用途数字相机），然后通过零售商——主要是像CVS这样的大药房——来发售。 这个概念似乎很有前途，但终究还是有不少缺点。Pure Digital创业管理团队成员Simon Fleming-Wood表示，问题在于这个业务模型意味着人们为了得到照片或CD，必须要向商家再返还20美元。还要假设零售商会把二手相机返回给Pure Digital，然后翻新，从而减少生产新相机的数量。但用户不会很快把相机送回来。有人觉得在1.4英寸的小屏幕上浏览照片可以接受，因此就留着相机，打算过一段时间再去打印。还有人解决了把照片下载到PC的问题，这样就更不会送还相机了。 快速地销售却没有快速回笼作保证，导致公司利润急剧下滑，最终导致相机停产。但是，Kaplan和Braunstein因此认识到：为了经济实惠、方便好用，用户可以放弃很多功能。为了把价格降下来，Pure Digital不得不反复权衡：使用便宜的镜头和其他组件，减少图像处理芯片的数量。拍摄的照片可以接受，但画质并不好。不过，Pure Digital还是卖出去三百万台相机。 对于一般相机零售市场，Kaplan和Braunstein也有了全新的认识。这个市场分成两大块：自动对焦、曝光的消费类相机（包括一次性产品）和独立镜头的单反专业相机（SLR，Single-Lens Reflex），后者可以更换镜头，而且要使用其他高端配件。毋庸置疑，当时相机销售量中的主体都是消费类相机（现在也是）；SLR只对业余摄影爱好者和专业人士有吸引力。 然而，奇怪的是，数字摄像机市场却没有即点即拍的消费类产品——这正是他们看到的下一个机会。家用摄像机几乎清一色都是高价货，内置了防抖、夜视模式以及颜色校正之类的复杂功能。而且，即便使用Apple的iMovie，都很难从拍摄的视频中截取一段放到计算机上编辑和共享。在复杂性和价格方面，便携式摄像机市场类似SLR市场，没有低端即点即拍的摄像机。Kaplan和Braunstein预测更便宜、更简单的视频摄像机将是一个新的市场。因此，他们决定推出一款这种摄像机。 经过反复尝试，Pure Digital在2007年发布了Flip Ultra。这种精简版的摄像机——与Single Use Digital Camera类似——有很多缺点。它的拍摄分辨率比较低，单帧画面只有640×480像素。而Sony、Panasonic和Canon推出的摄像机能够达到1080线的高清晰度。Flip Ultra的观察屏幕很小，也没有颜色调整功能，只有最基本的控制装置。甚至连光学变焦功能都没有。但是，它的个头很小（比一包烟都小）、价格便宜（只卖150美元，Sony中端产品都要800美元），而且操作简单——从录像到上传——几乎所有人都能在6、7秒钟内搞定。 几个月里，Pure Digital开足马力生产也刚刚能够满足订单需求。消费者发现Flip是将自己拍摄的视频分享到骤然流行起来的YouTube上的绝佳方式，这款摄像机获得了极大成功，第一年的销量就超过了1百万台。今天，仅仅两年后，Flip Ultra及其后续改进版，已经登上了美国最受欢迎的数码摄像机榜首，占有便携摄像机市场17%的份额。Sony和Canon都在后面奋力追赶。 Flip的成功让业界为之震惊，但这其实又没有什么值得大惊小怪的。Flip只是我们可以称之为“足够好的”技术的一次成功预演。低价、便捷、简单的工具一夜之间就充斥于每个人的生活当中。我们通过博客获知爆炸性新闻、在Skype上进行长距离质量不一的通话、在小小的电脑屏幕而不是电视上看视频，越来越多的人使用纤小、低能耗、正好能满足其上网和收邮件需求的上网本。各种低端产品和服务的消费量与日俱增。 …… 对这一点，没有人比Pure Digital Technologies那些人理解得更透彻了。两年前，Flip Ultra秉赋着三大可访问性横空出世：一是比其他数码摄像机便宜很多，让人感觉买起来都是一种刺激；二是容易使用，不仅拍摄视频易如反掌，而且向Internet上传视频剪辑同样不费吹灰之力；三是便于携带和Web共享的能力，让用户能够随时随地分享视频。Flip完全符合恰到好处的标准。 在问到为什么Flip能够成功，而其他更强大的摄像机——包括Sony等公司对Flip的仿制产品——会失败时，Pure Digital的Fleming-Wood的回答很有意思：“我觉得是我们的产品更好吧。”奇怪的是，Sony和Canon的高管恐怕也会如是说。毕竟，他们的机型拥有更多功能，拍摄的画质也更好。但Fleming-Wood与他们对“更好”的定义不同。他的质量观的核心是容易使用——拍摄与分享视频更容易。“把自己的视频剪辑与别人分享，是每一个人都想要的。”他说。 即使如此也不难想见，有朝一日Flip也将被种种滋生的功能所困。事实上，该公司最新发布了能录制高清视频的HD机型。好了，既然如此，为什么不能期待防抖动、大LCD——甚至：嘿，换成触摸屏如何？“我们将始终优先考虑可访问性，然后考虑的才是功能。”Fleming-Wood强调。像素数提升只不过是关于芯片速度和存储容量提升的摩尔定律作用的结果，并不是Pure Digital要改弦更张的信号。在HD组件不会明显提高成本，也不会导致使用更复杂的情况下，“没有理由不推出HD，”Fleming-Wood说。他指出，Pure Digital还会加入光学变焦、防抖动等功能，他知道人们喜欢Flip就是因为通过它拍摄和分享视频非常简单。“这一点我们永远不会丢弃。” 在谋划Flip未来的产品时，Fleming-Wood打算加入能够使分享视频变得更容易的功能。“嗯，我们可以加上Wi-Fi或单元互联功能，这样在你拍摄孩子的足球比赛时，可以实时将视频上传到Web，而奶奶就可以在家里观战了。”言语间流露出一位幻想家的激情。要实现这么宏伟的目标，恐怕得选牺牲一点HD的品质。没问题，只要足够好就可以了。 附注：2009年3月19日，思科宣布收购数码摄像机制造商Pure Digital，拟加强该公司在消费电子市场的影响力，以使思科成为大众熟知的品牌。]]></description>
		<link>http://www.cn-cuckoo.com/2010/09/18/the-good-enough-revolution-2062.html</link>
			</item>
	<item>
		<title>Rich Stevens答读者问</title>
		<description><![CDATA[原文链接：http://www.kohala.com/start/rstevensfaq.html 校对时间：2010年9月19日 问题TOC 你怎么想到要写UNIX Network Programming？ 你为什么要写Advanced Programming in the UNIX Environment？ 你为什么要写TCP/IP Illustrated, Volume 1: The Protocols？ 你为什么要写TCP/IP Illustrated, Volume 2: The Implementation？ 你为什么要写TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the Unix Domain Protocols？ 我应该看其中哪本书？ 你跟Doug Comer合作写过书吗？ 写一本书要花多长时间？ 在写这些书的时候你是通过哪些方式来学习的？ 你会回复读者的邮件吗？ 我也想写一本书。我该从何做起呢？ 能谈一谈UNIX Network Programming是怎么出版的吗？ 你并没有使用troff写书，是吗？ 你使用哪种Unix系统？ 你喜欢哪些技术书？ 你名字中的W.表示什么？ 你为什么专门为MTS（Michigan Terminal System）写APUE呢？ [...]]]></description>
		<link>http://www.cn-cuckoo.com/2010/09/12/rich-stevens-faq-2007.html</link>
			</item>
	<item>
		<title>在Windows平台的Apache中配置Python</title>
		<description><![CDATA[要在Windows平台的Apache中使用Python，当然必须得先安装Apache和Python。Apache我使用的是XAMPP，而Python则随便一搜，就可以找到下载链接。由于这个解决方案要通过安装Apache模块mod_python来实现，而mod_python的当前版本3.3.1只支持Apache 2.2和Python 2.5，所以不得不先缷载已经装好的Python 3.0，重新下载安装了Python 2.5。mod_python是一个Apache模块，它可以将Python解释器嵌入到Apache服务器中（详情可以看这里）。 让Apache支持Python的过程很简单，只要3步。 下载mod_python模块安装程序（注意文件名后面Python和Apache的版本号要与自己已经安装的版本一致；文件名前面的版本号则是mod_python的，文件名示例：mod_python-3.3.1.win32-py2.5-Apache2.2.exe），然后安装，安装向导会自动找到Python路径，但可能需要我们手工指定Apache路径，安装到最后，向导还会提示你如何修改Apache配置文件（参见下一步）并给出了后续步骤的英文说明。 让Apache加载mod_python模块。在Apache安装目录下找到其配置文件apache\conf\httpd.conf，打开，搜“LoadModule”，找到加载模块的地方，然后添加一条语句：LoadModule python_module modules/mod_python.so，重新启动Apache。 在htdocs目录下新建一个目录，如：“py”。进入py目录，新建一个文本文件，并命名为“.htaccess”，加入下列3条指令： AddHandler mod_python .py PythonHandler mptest PythonDebug On 这里第一条指令是将所有URL末尾为.py的请求转发给mod_python处理程序，mod_python接收到请求之后再寻找适当的PythonHandler处理程序。第二条指令只定义了一个mptest处理程序。最后一条是启用Python代码调试功能，以便在代码运行出错时输出Python解释器返回的错误。 完成以上3步之后，就可以编写Python文件并进行测试了。在py目录下新建 mptest.py 文件，打开后添加如下代码： from mod_python import apache def handler(req): req.content_type = &#039;text/plain&#039; req.write(&#34;Hello World!&#34;) return apache.OK 保存。打开浏览器，输入http://localhost/py/mptest.py，回车。看到“Hello World！”了吗？ 实际上，由于前面只明确将mptest设置为处理程序，所以无论浏览器URL中的.py文件名是什么（如：login.py、default.py），都将被转发给mptest.py文件来处理，都会返回“Hello World！”。怎么办呢？长话短说，可以将上面第3步中的代码替换成如下所示： AddHandler mod_python .py PythonHandler mod_python.publisher PythonDebug On 更多内容，参见Mod_python Manual和Introducing mod_python。]]></description>
		<link>http://www.cn-cuckoo.com/2010/08/19/run-python-in-apache-by-use-mod_python-1960.html</link>
			</item>
</channel>
</rss>

