作者文章: Fenng

上海两天之行参加技术沙龙

上周六去了上海，参加博客大巴 CTO 车东组织的 Startup 技术沙龙。

杭州这几天很热，我的 ForecastFox 插件上显示的是根~~小火柴~~温度计(?)：。下午 4 点多的时候和同事 Ningoo 一起出发，到了杭州火车站发现人真叫一个多啊。让我稍感到安慰的是和谐号车内空气质量似乎比以前好多了。一路顺利到了上海，居然都没晕车。

要出行，找携程

出于节约成本的考虑，星级酒店不能住啦。出发之前，给汉庭打了订房电话，为保险起见，给另外一家快捷酒店的”旗舰店”也打了电话。出火车站后电话询问汉庭的位置，如论如何也听不清楚电话里那个家伙说的话，只好先去另一家”旗舰店”，手续敲定，进了房间，一股霉味扑鼻而来，二话不说，下楼退房跑路，再给汉庭打电话，这次终于弄明白具体的位置了，赶过去，前台告诉我，房间取消了。”因为你是散客订的房，所以，时间到了就取消了”，接待人员牛气的不得了，爱理不理的样子。

只好重新订房。Ningoo 说自己是携程金卡会员，给携程打了个电话，等，不一会儿电话回来，房间定好了，上航假日酒店，价格也不贵，到了一看，性价比很高。我不由得赞不绝口。这里严重表扬一下携程，想方设法给用户省钱的公司就该赚钱，携程的价值或许低估了许多。

当天晚上，昔日的魔岩三杰也在上海开演唱会。

参会感受

BlogBus 位于 2577 创意大院，很休闲，都有些不太像 IT 公司，还养了一只狗，后来我临走的时候差点咬我 :)

参加讨论的朋友们陆陆续续到场，没有什么偏商务的宣传，话题都是大家平时遇到的一些技术点，现场气氛很好。参会的朋友来自 Blogbus、51、安居客、CDN Union、豆瓣、虾米、5173 等众多网站的朋友，我和另外一位周日上午赶到的同事（搜索引擎专家)代表支付宝，Ningoo 则来自淘宝。

信息不对称还是比较严重的，尽管有些技术问题可能是类似，但解决的办法和思路还是能互相带来很好的参考和借鉴。记得马云说过，”技术只有分享才有进步”，的确如此。会上主要议题包括：LifeStream 产品设计思路、数据库备份策略、日志处理、防 DDos 攻击等。因为还有些东西也涉及到业务数据，不多说了。

我在会上的一个技术论点：关于 Cache 服务器数量的问题，当时的说法：尽量保持为 2 的 N 次方。回来仔细想了一下，多少有些武断了。这个问题我回头仔细思考一下。这个思路用在 Sharding 上似乎没问题，但是是否能扩展开来? 未必站得住脚。

又看到老朋友，结识了新朋友。这也是大老远跑来才能收获到的吧。

归程

回来的路上挺有意思，三个人一路赶到上海南站才发现车票……居然是上海站的，三个人一口差点一起晕倒。匆忙坐地铁过去，地铁上发现一件有趣的事儿，所有的液晶屏终端都是 Linux 操作系统，而且在不停的重启动…

128M 内存，Linux 2.4 Kernel 的 :)

–EOF–

《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 页面测试一下。