派・索尼客

Mozilla 前几天刚发布最新的 Firefox 3.5 正式版。主要的新功能有

• 启用 TraceMonkey JavaScript 引擎
• 新增隐私浏览模式
• 改进了拖拉标签新建窗口功能
• 支持 HTML5 标准
• 支持用户的地理位置

发布的当天，Gentoo 就把 Firefox 3.5 纳入了 Portage 当中。因为有被 hard masked，Gentoo 下安装的时候，需要运行

$ sudo autounmask =www-client/mozilla-firefox-3.5
$ sudo emerge =www-client/mozilla-firefox-3.5

Emerge 完了以后，启动 Firefox，发现一个问题：系统的语言设定（Locale）虽然是 en_US.UTF-8，可 Firefox 的界面却变成中文的了。看了下 Firefox 3.5 的包信息，不知道为什么少了 en 和 en_US 的 LINGUAS。解决方法有：

打开 about:config，找到 general.useragent.locale 一项，把 zh-CN 改成 en-US 就好了。

或者是直接修改 ebuild，把被遗失的 “en en-US” 添加到 LANGS 一项，然后安装一下。

$ diff ~/mozilla-firefox-3.5.ebuild.old mozilla-firefox-3.5.ebuild 9c9
< LANGS="af ar as be bg bn-BD bn-IN ca cs cy da de el es-AR es-CL es-ES
---
> LANGS="af ar as be bg bn-BD bn-IN ca cs cy da de el en en-US en-GB eo es-AR es-CL es-ES

BTW，禁用中文的语言包（Language Pack）也可以把 Firefox 的界面恢复成原来的语言，但是对扩展没有用，算是不完全的。

Firefox 3.5 最吸引我的两点。一是使用了号称速度上不输 Chrome V8 （太多）的 TraceMonkey
JavaScript 引擎。在测评当中，Firefox 3.5 要比 3.0 快了2倍有余，尽管没有 Chrome 和 Safari 快，但差距已经不大。

二是，Firefox 3.5 最重要的更新，对 HTML5 的支持。最好的演示就是无需像 Flash 这样的插件，就可以在页面上直接观看 Theora/OGG 格式的视频了。写了一个简单的视频播放 Demo HTML。

<video width="640" height="360" src="test.ogv" autobuffer>
    <div class="video-fallback">
        <br />You must have an HTML5 capable browser.
    </div>
</video>

截屏的效果如下。

播放视频中。还有 Play 按钮、进度条、时间和音量等控件。

暂停播放时。单击右键弹出菜单，可以像保存图片一样保存视频了。

升级到 git 1.6.3 以后，每次 git push 的时候都会出现这样“吓人”的警告。

warning: You did not specify any refspecs to push, and the current remote
warning: has not configured any push refspecs. The default action in this
warning: case is to push all matching refspecs, that is, all branches
warning: that exist both locally and remotely will be updated.  This may
warning: not necessarily be what you want to happen.
warning:
warning: You can specify what action you want to take in this case, and
warning: avoid seeing this message again, by configuring 'push.default' to:
warning:   'nothing'  : Do not push anything
warning:   'matching' : Push all matching branches (default)
warning:   'tracking' : Push the current branch to whatever it is tracking
warning:   'current'  : Push the current branch

通常，这是很多 Linux 或者说开源社区贴心的地方，主动告诉你，“注意了，我们发布了一个新版本，有些地方和之前的不太一样，需要你自己动手改一下”。。。只是，为什么不直接给出一条简单明了的指令呢？比如，

$ git config push.default matching

因为 Blogger 后台被封锁的关系，原本用 Blogger FTP 发布的 Blog， 现在改成用 WordPress 架设了。不过，不管是 FTP 还是 WordPress 发布，都在同一台主机上，其实也算不上搬家了。

顺带也把域名换了。新的 Blog 域名为 PY.THONIC.ORG，来自于单词 pythonic，意思是简单、清晰，不要过分强调技巧，一般论的话。于是，Blog 的名字也从“陆离斑「博」”改成“派・索尼客”，简单的音译，感觉不错就写上去了，结果反而有些不知所云呢。本人不是 Sony、Somy or Pony 的粉丝这一点倒是肯定的。

Feed方面。FeedSky 被收购以后抓取的龟速，所以不打算在 FeedSky 烧制 feed 了，现在的 feed 就是默认的 http://py.thonic.org/feed/ 或 http://feeds2.feedburner.com/pythonic。原来绑定在 FeedSky 上的 feed，如 feed.luliban.com，feed.feedsky.com/luliban 等，会自动被重定向到 http://py.thonic.org/feed/。所以继续订阅也没差，至少在域名到期之前是这样子。

和开拓者的系列赛开始前一样，我也列出了三个关键点。

首先，火箭能不能防住 Gasol 是最重要的。去年总决赛中 Gasol 被 Perkins 和 Kevin Garnett 彻底遏制是 Celtics 的取胜的关键之一，当 Gasol 被遏制的时候，湖人就回到了那支 05 年被太阳翻盘的只有 Kobe 一个人战斗的湖人。这一点今天火箭做得最好，在最后时刻的几次补篮前，Gasol 似乎只有 13 投 3 中。

其次，保护住防守篮板，尤其是第二阵容。湖人是常规赛中进攻篮板效率第三好的球队，前两名是波特兰和费城。火箭第一轮让开拓者场均拿到了 9.8 个进攻篮板，虽然比他们的赛季平均要少了 3 个，但光 Przybilla 和 Oden 两个人就贡献 5.0 个前板。而湖人在季后赛的表现也不比开拓者差，Gasol 和 Odom 合起来也能在爵士头上拿到 5.1 个进攻篮板。从这场比赛中，我们也可以看到火箭的第二阵容 Hayes + Landry 在高度上相差很多，光 Odom 一个人就拿到了 4 个前板，整场比赛湖人拿到了 12 个前场篮板。

第三，和开拓者的时候一样，当火箭在防守端做到最好的时候，Aaron Brooks 或 Artest 能不能在进攻端拿到足够取胜的分数。而且，这一点比对开拓者的时候更重要，因为湖人是全联盟攻守转换速度最快的几支球队之一，当他们能够保证自己的后场篮板的时候，快攻会非常之多。

也许你会奇怪三条里面，没有一条是关于 Kobe 的。但绝对不是对 Kobe 的防守不重要，而是说这个地球上没有一支球队可以完全限制住 Kobe Bryant，你所能做的就是在比赛开始前为他准备好 30 分，在他投篮的时候遮住他的双眼，在他突破的路线上让姚明挡在他的身前，当他起跳的时候往他身上扔三四个人，接下来就只有看上帝更爱谁了。。。话说回来，当姚明能够顶防 Kobe 的挡拆的时候，火箭似乎又变回了 Van Gundy 时代的那支“即使 Kobe 拿到50分我还是能赢球”的火箭队。

最后说一句，裁判也是人。凡是看到一个人血流满面的站在面前的时候，难免会动恻隐之心；凡是看到一个7尺6的巨人痛苦倒地后坚持完比赛的时候，难免会心生敬佩。于是，湖人的犯规以 26 比 14，火箭的罚球以 29 比 19 远远领先于对手，最后几次的吹罚也不像是在斯坦普斯中心了。

最后的最后，希望姚明的膝盖没事。

更新一下：看起来姚明的膝盖没事。这是不是有点像去年总决赛的第一场 Paul Pierce 被人抬出球场的情景？

火箭 4 – 2 开拓者。恭喜姚明7年职业生涯第一次进入西区半决赛。恭喜火箭12年来第一次进入第二轮。

今天 Batum 用另类的方式证明了自己的价值。之前的五场比赛中，Artest 场均 13.4 分，命中率 37.7％，三分球命中率 28.0%，惨不忍睹情何以堪。但是第六场比赛中，之前场均 1.8 分的 Batum 被开拓者主教练 McMillan 摁在了板凳上，整场比赛用 Roy 或 Outlaw 对位，让 Artest 一口气轰下职业生涯的季后赛新高 27 分。结果论而说，McMillan 这一变招相当的失败。

之前也说过，Artest 在面对身高臂长跑跳出色的防守者的时候，效率非常一般。所以，即使 McMillan 不希望再看到 Batum 出现在轮转阵容中，也应该把 Outlaw 放到先发。McMillan 把 Rudy Fernandez提拔，只得用 Roy 去防守 Artest。但 Roy 整场比赛都无法限制 Artest 和姚明的挡拆。有意思的是，昨天 Artest 莫名的大夸 Roy 更胜 Kobe 和 LeBron 之余，也说了 Roy 在防守端还不是精英级别的，马上就被验证了。

火箭接下来的对手是湖人。湖人从各种角度来说，都是开拓者的加强版——这也是人们看好开拓者的未来的理由之一。相对应的是，火箭偶尔也会被人叫做山寨版的凯尔特人。除了“伪三巨头”之外，火箭的防守体系，和去年在总决赛中将 Kobe 困于牢笼的凯尔特人的一样，师承防守大师 Tom Thibodeau 之手是一个很重要的原因。

在凯尔特的体系中，Allen，Pierce 和 Posey 负责对 Kobe 贴身紧逼；Kevin Garnett 的活动范围非常大，他从进入三分线的那一刻起就开始夹击 Kobe；KG 身后的 Perkin 是最后一堵墙。相比之下，由 Battier 和 Artest 组成的火箭的侧翼防守不会输给任何一只球队；但是姚明以往在三秒区内更有威慑力，但中距离的挡拆防守和 KG 不能相提并论；而一旦姚明扑出去，身后的 Scola 能不能像 Perkins 一样保护好篮下也是一个问号。这也是湖人本赛季能横扫火箭的一个因素之一。

但是，今天的姚明在防守端拿出了一个赛季以来的最高水准。他的活动范围直到 FIBA 的三分线，像一把大锁一样卡在了火箭的油漆区外，上一场被 Blake 和 Rudy 们频频利用的中距离空间，这一场消失殆尽。有那么一瞬间让人以为那是去年季后赛中的 Kevin
Garnett。像凯尔特人那样打出总决赛级别的防守，这是火箭和湖人对抗唯一的选择。

上场比赛后说了，火箭的破绕前战术分为三部曲：弱侧突破，罚球线跳投，以及把球给到姚明。今天火箭终于做到了最后一条，姚明的14次出手比前两场总数还要多。三场比赛一场一个台阶，Adelman 展现出了季后赛大师级的调整能力，这是我在 Van Gundy 时代的火箭身上所没有看到的。

接下来的比赛中，火箭还要继续加强对开拓绕前战术的解读能力。如果有弱侧的队员来协防，后卫就要把球从强侧快速的移动到弱侧；如果是由 Aldridge 沉底补防，对位的 Scola 或 Landry 就应该上提到罚球线来策应，或者直接跳投。如果只有 Przybilla 或 Oden 一个人在绕前，姚明可以从强侧横要到弱侧，球也要随之转移。因为开拓者肯定会混合是用这三种不同的绕前战术，而回到玫瑰花园的时候，Przybilla 不可能再开场两分钟就被吹下去，Oden 的大动作拉扯也多少会被无视一些。

再说说 Roy 的改变，前两场比赛中 Roy 在挡拆中的选择无非是跳投和突破。今天 Roy 在挡拆后，不再一味的利用速度冲击火箭的内线，而是适时的收步，吸引火箭其他球员收缩防守后，再把球传到三分线外。沉寂了三场的 Travis Outlaw 和 Steve Blake 由此得到解放，两人联手在三分线外 9投4中。总的来说，这支开拓者已经越来越像那支在常规赛两次击败湖人的开拓者了。

再说一个细节，Lowry 连续两场比赛在最后关头被 Rudy Fernandez 颜射进了大号三分，Lowry 的身高更适合去防守 Blake，也许 Adelman 会在下一场做出调整。

解说的时候，苏群说了一句话，“火箭就像是开拓者的陪练，不管赢没赢下这个系列赛，这都成为开拓者成长道路上的一个磨练”。其实反过来说也合适，火箭这赛季的两个阿喀琉斯之踵——姚明的挡拆防守和为姚明破绕前——通过和开拓者的系列赛，你可以清楚的看到火箭这两个最大的漏洞正在逐渐的被补上。

当 Brandon Roy 挡拆进攻时，姚明不会再像常规赛一样 Shadow Post 沉在三秒区，而是和 Roy 面对面攻防，直到防守 Roy 的 Artest 或 Battier 回到他的防守位置为止。这也是今天火箭能把 Roy 18 次出手仅命中 6 球的两个主要原因之一。另一个就是火箭的主场哨保护了姚明，不像在玫瑰花园第二场比赛的时候一样，很容易被 Roy 的突破来制造犯规。相信在接下来的系列赛当中，Roy 恐怕很难再像第二场一样彪到 42 分的高分了。

再说说绕前战术，这是一种赌博性的战术。当一个大个子对姚明执行绕前的时候，身后必然会留下很大的空位，这需要其他球员来填补身后的空位。你可以把绕前战术想象成一颗洋葱头，开拓者的防守球员就像一层一层的洋葱皮，而姚明就被围困在其中心。

火箭的破绕前战术可以分为三种。第一种是利用弱侧的空档进行突破，这在第二场比赛中火箭已经做到了极致，Von Wafer 的坚决突破拿到了 20 分，以及 Aaron Brooks 或 Luis Scola 的弱侧挡拆在第三节也为火箭拉开7分的领先优势。虽然火箭第二场输了，但开拓者的主教练 McMillan 还是意识到了问题并作出了调整，在第三场比赛中让弱侧的球员更注意盯防火箭的外线球员。所以，火箭在第三场比赛中，也有几次成功的在弱侧给到了姚明皮球。火箭的弱侧进攻已经剥去了洋葱头的第一层皮。

既然弱侧必须兼顾，McMillan 只有让大前锋 Aldridge 来做补防的工作。火箭的第二种破绕前战术正是针对这一点，Luis Scola 和 Carl Landry 的罚球线上提，在中距离让开拓者付出代价。今天比赛的上半场就是一个经典案例，Scola 上半场连投带突12投6中13分全队最高，这种表现甚至让 McMillan 一度放弃了绕前战术，因此下半场的前三次进攻中姚明都在强侧很轻松的拿到了皮球。火箭的大前锋为姚明剥去了洋葱头的第二层皮。

但是 Scola 的第四次犯规下场改变了整个比赛的进程。虽然 Landry 上半场中距离发炮5投5中效率惊人，但他不像 Scola 一样有杀伤能力，所以 McMillan 又恢复了绕前防守，甚至既不让弱侧进行补防，也不让大前锋协防。洋葱头就剩下最后一层皮——Przybilla 和 Oden 的独力绕前，这时候开拓者的绕前战术就变成一种纯赌博性的战术，就赌火箭的外线不能够抓住那 0.5 秒的机会，把球给到内线的姚明。

最后的结果不必多说，虽然比赛赢了，但看看姚明的出手数（7次，只比上一场多了1次而已）就知道火箭的破绕前战术并没有成功。但也不能说完全失败，因为现在这颗洋葱头就只剩下一层皮，火箭也不是没有剥皮成功的经验——常规赛对开拓者的那一场大胜就是例子。

如果火箭破得了绕前，防得了挡拆，那么火箭基本上就可以战胜开拓者了。而第二轮的对手湖人是一支和开拓者结构非常类似的球队，Kobe 之于 Roy，Bynum 之于 Oden，Gasol 之于 Aldridge，第一轮的宝贵经验会成为火箭对抗湖人的筹码。

豆瓣的认证码：doubanclaim5ca247f8bb42286e

今天比赛之前，给火箭列出了三个问题。

姚明和火箭如何应对 Przybilla + Oden + Aldridge 的绕前防守？
开拓者不会整场比赛都进行绕前，但在关键时刻适当的战术变化却是秃子头上的虱子——明摆的事。应该说，McMillan 今天的绕前来得有点晚，直到第三节的前六分钟开拓者才开始对姚明进行绕前，而这个时候开拓者已经落后20分。不过效果也是立竿见影，Artest 和 Brooks 接连几次不合理的出手，但之后裁判的主场哨反而帮了倒忙。把姚明四次犯规吹下去之后，火箭把防守端的一个大窟窿给补上了。在领先20分的情况下，防守比进攻更显重要，只要不让对手打出高潮，一场胜利基本跑不掉。

但火箭不可能场场比赛都在第三节领先20分，如果在比分焦灼的情况下，开拓者绕前的话，火箭的执行情况会怎样呢？

Roy 能不能像 Kobe 一样利用姚明挡拆的弱点？
McMillian 从第一节开始就让 Roy 打击姚明的挡拆，并早早的让姚明背上一次犯规。但如果看了 Kobe 对火箭的录像，Kobe 在上半场总是会让队友充分的热身，直到第三节或第四节才开始打挡拆。因为挡拆很难让其他球员融入到整体进攻中来，过早的使用就会陷入今天开拓者的窘境。今天的 Roy，比起 Kobe 来更像前几天和大败给火箭的 Chris Paul。

另外和常规赛不同，姚明在防守挡拆时会出来顶防，而让两个底角的防守者收缩禁区。但开拓者是联盟第一的进攻篮板球球队，如果姚明出去，身后的篮板球是不是会成为另外一个问题？

Artest 和 Brooks 的进攻效率？
说实话，比赛之前，我有点担心 Artest 和 Brooks 的进攻效率。因为本赛季面对跑跳素质出色的防守者的时候，Artest的效率相当糟糕。对湖人的 Ariza 只有 32.6% 的命中率，对开拓者的 Batum 和 Outlaw 也只有 36.4%。Brooks 在三月份虽然能以 44% 的命中率场均砍下 14.9 分，但四月份收官阶段的表现一般，得分和命中率分别只有 9.9 分和 36.1%。

但从今天的表现来看，我是想多了。Artest 的 17分和 AB 的 27分4板7助都是比赛的关键，但两个人唯一的瑕疵都来自于第三节前半段姚明被绕前的时候，也许下次 McMillan 会更早更坚决的执行绕前战术。

总的来说，火箭今天虽然大胜，但仍不足喜。

1. 这是开拓者第一场季后赛，这是他们应缴的学费，Aldridge 和其他开拓者球员不可能每一场系列赛都打出这种效率。
2. 即使在总篮板球数上落后（火箭投失的球少），开拓者还是抓到了 15 个进攻篮板，如果比分焦灼着进入第四节，这会是一个威胁。
3. 虽然只有短短六分钟，火箭在绕前问题上仍然没有很好的解决方案。

再说个开拓者的亮点，今天 Oden 算是小爆了大叔。不过，如果对比一下大叔对 O’Neal 的防守——双腿趴开，重心前压，两只手死顶在 O’Neal 背上——和对 Oden 的防守——双腿直立，两只手高举，就想着扇个帽摇手指——你就知道大叔多少有点轻敌了。

authdouban 是一个即插即用（pluggable）的 AppEngine 应用，可以让你的 web 应用支持豆瓣的 OAuth 认证和管理已授权的豆瓣帐户。authdouban 目前的版本是 0.1。欢迎大家的建议和意见，你可以 GitHub 的仓库中检出或下载。

视图 Views

authdouban 由下面五个 views 组成。

• list accounts : 列出用户已授权的豆瓣帐户
• authorize : 将用户被重定向到豆瓣的授权页面。用户同意（不同意）授权后，返回到授权成功（失败）页面
• authorization complete : 授权成功页面
• authorization failure : 授权失败页面
• delete account : 删除已授权的豆瓣帐户

依赖 Requirements

• gdata-python-client
• douban-python

设置 Settings

应用的设置保存在 settings.py，一共有五个选项。首先要填写应用的豆瓣 API key，如果没有的话，你可以到豆瓣的 API key 申请页面去填表获得。

DOUBAN_API_KEY = 'yourapikeyhere'
DOUBAN_API_SECRET = 'yourapisecrethere'

选择是否将豆瓣用户的档案信息（比如用户名，城市，头像 URL 等）保存在服务器上。如果是，应将 STORE_DOUBAN_PROFILE 设为 True，反之 False。如果不在服务器上保存，也可以在生成页面时通过 javascript 抓取，这样会比较即时。

STORE_DOUBAN_PROFILE = True

如果把用户资料保存在服务器上，不可避免会有一个资料过期的问题，不过 authdouban 支持自动更新用户档案的信息。你可以修改 MAX_CACHE_TIME 来设置一个缓存的有效时限（默认为 24 小时），也就是如果用户信息最近一次更新的时间超过了 24 小时，则自动从豆瓣抓取新的用户信息。如果将 MAX_CACHE_TIME 设为 0，就永远不会更新用户信息。不过，根据豆瓣 API 的使用条款，在服务器端缓存的用户信息，不能超过 24 小时就是了。

MAX_CACHE_TIME = 24

最后一个选项是 MAX_STORED_ACCOUNTS，你可以用它限定一个用户最多可以授权的豆瓣帐户的数量。设为 0 的话，即为没有限制，不过 AppEngine 最多只能返回 1000 条查询。如果超过了限定，authdouban 会自动删除一个最早授权的豆瓣帐户。

MAX_STORED_ACCOUNTS = 10

URL 映射

URL 映射保存在 urls.py 文件中，和上面的视图相对应。

• /account/douban/
• /account/douban/authorize/
• /account/douban/authorize/complete/
• /account/douban/authorize/failure/
• /account/douban/delete/<id>/

需要特别注意的是

如果你修改了 urls.py 中的映射，那你也要改一下 views.py 中相应的 URL（wyt：可以在文件中搜一下 “/account/douban/”）。我不知道 AppEngine 中怎样才能实现像 django.core.urlresolvers.reverse 一样的逆解析，所以只能手动改了。如果有同学知道怎么做，请一定要留言～

模板 Templates

模板在 templates/authdouban 文件夹下，你可以 copy 到你的应用的模板目录

• list_account.html : 列出已授权的豆瓣帐户
• delete_account.html : 删除豆瓣帐户的授权
• complete.html : 授权成功
• failure.html : 授权失败
• douban_user.html : 豆瓣用户档案的模板
• douban_user_no_delete.html : 也是豆瓣用户档案的模板，但是没有“删除帐户”的按钮

authdouban，是一个管理豆瓣授权帐户的即插即用（pluggable）的 AppEngine App，目前支持添加，删除和管理多个经授权的豆瓣帐户。authdouban 还在开发中，非常需要大家的参与和建议，欢迎留言。

买一送一，authdouban 中还包括一个豆瓣官方的 Python 客户端项目的分支版本。这个分支版本会跟着豆瓣官方的上游版本更新，但是会将用到 httplib 的代码替换成 urlfetch 方法（wyt: AppEngine SDK 1.1.9 已经支持 httplib 了，所以不需要再用 urlfetch 替换 httplib 了，不过还是有些地方需要修改），使之在 AppEngine 上可以顺利运行。

2009-02-21 更新：豆瓣接受了我提交的patch，所以如果从官方 SVN 中检出最新的（r47）的上游版本和 authdouban 中的分支版本是一样的。

你可以点击这里尝试一下用 authdouban 实现的简单界面。下面有几张截图。

授权成功后。

已授权的帐户列表。

删除已授权的豆瓣帐户。