《Python源码剖析》推荐序

看了博文视点编辑的这篇《让我们做的更好》》，我也把之前给这本《Python源码剖析》写的序翻了出来，贴一下。也希望对关注 Python 的朋友能多多支持支持原创，有的时候多几分欣赏，少一点点苛求，软件书籍的出版环境就会更好一些。

非常高兴看到又一本原创 Python 图书的出版。

说起来，我和 Python 还算有一点缘分。在 2000 年的时候，非常偶然的一次机会接触到Python，当时网上资料非常之少，不知天高地厚的我竟冒失地接手了国内第一本引进 Python 图书的合作翻译工作，往事不堪回首。记得当时经常有人问我 Python 能用来做什么…而能举出来的例子的确寥寥可数。

历经数年的发展，Python 已今非昔比，各领域都不乏 Python 成功案例。就拿 Web 方面来说，正如 PHP 给 Yahoo! 带来的巨大动力，Python 在新一代互联网霸主 Google 内部早就充当着重要角色，是排名第三的”官方语言”。而就在几天前，Google 革命性的 App Engine 产品一经推出即引起莫大关注，其首选开发语言就是 Python。

纵观国内技术环境，Python 语言仍处于慢热的状态，应用仍然不算广泛。不过我们也已经有称得上比较成功的实现案例，比如著名的 Web 2.0 的代表站点豆瓣网即是用 Python 开发，创始人杨勃对 Python 的效率、优雅赞誉有加。(Refer)

Python 也是权威机构 TIOBE 评出的 2007 年度编程语言，这些”利好”消息也将进而带动新一轮的技术走向，预示着 Python 更大规模流行时代即将到来。

话说回来，”开放平台”在未来几年一定是个不可避免的技术趋势，而跟着大厂商的平台亦步亦趋，照猫画虎，想必也能开发出来繁多的周边应用，但开放未必对所有人都是个好事情，久而久之开发者难免有盲人摸象之感，很难掌握全局、关键架构技术，故深入研究 Python 基础技术仍不可少。这本《Python源码剖析》的出版恰是好时机，弥补了国内图书在这方面的空白，此外，作者在 Python 领域的精耕细作研究精神亦值得学习。

研读、分析源代码乃是提高编程技能的一条捷径，庖丁解牛方能游刃有余，夯实基础，方可构建坚实大厦。

读这本书《Python源码剖析》就像一次探险之旅，祝愿朋友们能够获得一次愉悦的阅读体验。

–EOF–

Ratproxy — Google 的 XSS 检测工具

跨站脚本攻击(XSS, Cross Site Scripting) 可能是目前所有网站都比较头疼的问题，Google 也不例外。这次 Google 又做了一次雷锋，把内部用来审计 XSS 的工具开源了：ratproxy。

Ratproxy 工作流程：

1) 运行脚本后，会在本地启动一个代理服务器，默认端口是 8080 ；
2) 浏览器设置这个地址 (http://localhost:8080)为代理地址；
3) 浏览要测试的 Web 页面，进行实际登录，填写表单等操作(这些动作会被代理服务器捕捉并做点”手脚”发给待检测的页面)，ratproxy 会在后台记录相关的 Log ；
4) 用 ratproxy 提供的工具解析 Log 并输出 HTML 进行分析；
5) 修正比较严重的问题后，跳回到第一步，直到评估通过为止。

在我的 Ubuntu 下测试了一下，需要说一下的是，本地系统需要安装 libssl-dev 与 openssl 。

$ sudo apt-get install libssl-dev openssl 
$ cd ratproxy ;  make

然后就可以提交类似:

$ ./ratproxy -v . -w foo.log -d foo.com -lfscm

然后，人肉点击相关的页面进行测试了。这个工具的设计思路还是很值得借鉴的，推荐对安全感兴趣的同学读一下源代码。

ratproxy 的作者是 MIchal Zalewski，一个波兰的白帽子黑客。他的个人主页上能找到更多有趣的工具。

–EOF–

另参见另一份试用报告

Updated：Google的另一个工具：Skipfish 尤其值得关注。

Jiffy — 端到端的 Web 性能评测框架

前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词：YSlow。简单的说，YSlow 是以最佳实践得到的规则为基础，进行 Web 页面的性能评估，并给出指导建议。

而 Velocity 2008 上发布的 Jiffy ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似”望闻问切”的诊断方式，那么 Jiffy 就是 CT 检查了。

下图揭示了 Jiffy 的工作机制：

通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库，相信不久就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。

–EOF–

更新：有得朋友说，安装了，点击了，没反应。这是因为页面中没有嵌入 jiffy.js 脚本。可以到我的 egosurf 页面测试一下。

BASE — 高可用架构的基石之一

在讨论 eBay 的Scalability最佳实践的时候，结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然，我不是说 ACID 就不重要了)

BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义：

Basically Available –基本可用
Soft-state –软状态/柔性事务
Eventual Consistency –最终一致性

“Soft state” (SS) 是与 “Hard state”(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的，这样就清晰多了。

最终一致性，也是是 ACID 的最终目的。对于 eBay 这样的大架构，是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构，另请参考 eBay 的 Dan Pritchett 在最近的技术的散文：BASE: An ACID Alternative，注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年，BASE 将成为一个技术热词。ACID 当然没过时，只是各自需要合适的应用场景而已。随着互联网技术的开放性，更多的时候，一个架构师需要反复的衡量合适的应用场景。

BTW: “ACID” 英文里面有”酸”的意思，而 “BASE” 有”碱”的意思. 酸碱在一起才能中和啊，哈

–EOF–