我需要坦白承认的一点是，我看小说的目的并不单纯，我并不是将其作为一部单纯的娱乐作品去看，就像我在看 Inception 的时候（我看了至少 3 遍 Inception），我想我更多的是将其看作一个已经到达了某个阶段的项目去看待。

是的，一个项目。从种子一样的 idea，找到适合的土壤，空气，水和照料的人（可能不只一个），然后终于长成了什么。

能够在很长的历史长河中，被视作鸿篇巨著的作品不多，正因其珍贵，而成为众多古往今来作家所追求的，可以说是终极目标。

是否能够实现这样的终极目标，做的人在做的时候其实并不十足的把握。因为似乎人心这样的东西，到了一定的阶段，就没有什么事情对于他而言，是真的非做不可的了。理论上来说，这个世界上最宝贵的事物，是那些不会重复自身的。你可能在做一件事，可后果却不一样——要么将一件可以在一个月内完成的事情重复十二遍，要么，每天都是全新的。

作为小说来说，1Q84 有几乎可以说是显而易见的中心论点和已经在过去作品中被反复咀嚼的论据（当然，前提是对于之前作品的熟悉），也有了一些或许细微却依然可以被察觉到的对以往论点的怀疑——比如对于 ideology 的态度，如果说之前的作品中就像热刀切下牛油，可是到了 1Q84 中却变成了「我们以往已熟知的那个世界已经不复存在了」。而作者并不满足于此，于是他同时也说了「真相只有一个」。只是究竟是哪个，却不见黄油也不见热刀了。

这一年删掉的邮件和代码，及吃到肚子里的话和思索，比以往任何一年都要更多。我的中心论点没变。一切不过是在帮助提炼这个论点。

What it lies in our power to do, it lies in our power not to do.

In next version, we'll have all new Vietnam weapons.

从 2007 年初见到 OpenDNS 那刻起，我就一直对这个东西非常着迷。互联网上有很多的协议，最普遍的协议是 HTTP，于是针对这个协议的各种开发框架和应用也就非常多。但是 HTTP 不是唯一的协议，还有其他很多好玩的协议，比如 IMAP，比如 DNS。所以我一直在想，能不能在 DNS 协议上做一些什么。

于是就有了 V2EX DNS，在 2010 年 11 月 10 日早上上线。这是一个面向公众的 DNS 解析服务，除了高速解决最普遍的解析问题之外，V2EX DNS 还提供了：

• 对一些顶级域名常见的拼写错误进行纠错，比如输入 google.cmo 会自动跳到 google.com。
• 有的网站由于各种原因，没有配置 @ 解析，那么当用户使用裸域访问时，就会出错。典型的例子如 gov.cn 和 weibo.com。当使用 V2EX DNS 时，可以自动为用户尝试加上 www 进行访问（通常这也是用户的本意）。
• 当输入了一个确实不存在的域名时，会导向至 Google 搜索帮助用户找到正确的网站。
• 此外，我还有一些安全方面的功能在开发计划中。

开始使用 V2EX DNS 非常简单，只需将你的电脑上的 DNS 主服务器地址设置为：

178.79.131.110

即可开始使用。

目前 V2EX DNS 在上线 48 小时后，已经服务了超过 140 万次查询。大家在 V2EX DNS 网站首页底部看到的那根灰色的线，即时目前的实时查询流量，每 10 分钟更新一次。

而第二件事，就是 2010 年 11 月 12 日，Project Babel 2 的第一个正式版本 2.4.0-RC1 发布，大家可以从下面这个地址下载：

PB2 是一个开源社区软件，运行在 Google App Engine 上。V2EX 社区即是使用此程序搭建。

以上，是两件我坚信有价值的事情。坚持下去，一定会发生更有趣的事。

并不是什么火，才去做什么。那样的人生起码不是我想要的。我赞同亦舒的话，对于活着而言，最紧要的是姿态好看，倘若一件事情费力争来，那么即使赢了也是输了。而我很早就明白的一个道理是，你没有必要去说服任何人，实际上你也办不到。所以对于别人能够说服我这件事，我觉得也是一个伪命题，这个世界上所有的决定，到头来，都是自己一个人在清晨时分睡不着而决定的。

当然，我感激每一次的会面，那是缘分。而人生到了某个阶段之后，就变成是每天去接触甚至融化不同的气场了。然后，越来越明白，究竟自己要的是什么。

The latest update brings full Retina Display support as well as enhanced Next Events: now you can get a more accurate level up path from BC2Stats.

As BC2: Vietnam is coming soon, we'll update the app once the expansion is released. Thank you very much for your support.

但是大部分人在目前恐怕是没有信心和能力做出一家 NASDAQ 上市公司的。那么怎么办呢？列出你可能加入的所有公司，逐一分析他们的盈利模式，然后找出离上市最近的那家，如果：

• 他们的商业模式确实可行。
• 你认同这个商业模式。
• 你有办法帮助他们的生意做得更大或者更稳。

那么就加入这家公司，要成为最优秀的人就应该去最优秀的地方，然后至少做到他们上市两三年后，再思考下一步吧。那个时候，或许看待整个人生的方式和眼光都不一样了。

在过去的几年时间里，作为一个网站开发者同时也是 iOS 开发者，我研究了无数国内国外的好看好用的应用，他们中的很多无疑在设计理念和实现上非常科幻。作为一个设计者，我可以在自己的作品中将设计做到一个让自己满意的程度，可是自己的应用和网站毕竟能够影响到的，只是很少的一部分人。

我真的希望在某个时候，当我访问一个银行或航空公司的网站时，他们的设计也能够让我发出由衷的赞叹。而我相信，在未来，当很多基本问题都被解决得足够好的时候，设计会成为很多用户选择一个服务的重要考虑因素。我希望那一天能够早点到来，我更希望能够参与。

• 无限的计算能力
• 无限的存储能力
• 无限的传输能力
• 接近 100% 的 uptime
• 按照实际使用量进行收费

从以上的每一点，你可以用自己以前的 IT 架构与之对比，就可以感觉到不同。

而对于最终用户而言，云计算意味着：

• 无限的存储能力：比如，如果照片都存在云里，那么就不用担心手机上存储空间不够。你可以通过手机访问你个人云存储中的几千甚至几万张照片。
• 可靠的，易于访问的数据存储：因为所有的数据都存储在一个可靠的云计算数据中心，因此，比如不小心丢失了手机，那么也不用感觉困扰，因为手机中的所有的联系人，依然可以从云中同步下来存储到新的手机上。并且，甚至可以通过云，将原来手机中的数据锁定并清除。
• 更低廉的使用费用：因为数据都存储在云中，因此用于访问的设备并不需要特别巨大的存储和计算能力，会更省钱。

目前针对企业应用，已经有了一些很成熟的云方案，尤其是存储类方案，如 Amazon S3，Rackspace CloudFiles 和 Google Storage for Developers。不过存储类方案各家都做得大同小异，主要的比拼点是品牌，规模和价格。而更有趣的，是计算类的解决方案。

IaaS and PaaS

计算类的解决方案目前主要有种：

• IaaS - Infrastructure as a Service：这种方案的核心是服务器虚拟化及高度自动化的管理，通过部署大规模的虚拟化宿主，配合集群式的高性能存储，可以非常方便地在瞬间根据用户需要提供无限量的 virtual server（虚拟服务器），用户拥有这些服务器的全部权限（比如 *nix 的 root 权限），可以在上面运行任何自己的应用。但是 IaaS 依然需要用户去自己解决架构上的一些问题，比如安全，比如数据库服务器的数据复制，及应用服务器的容错处理等等。因为可以瞬间提供新的 virtual server，所以理论上来说，如果应用架构本身有成熟的 scale out 设计，那么 IaaS 也就提供了无限的计算能力。
  
  这类方案的典型例子就是 Rackspace Cloud，Joyent SmartMachines 和 Amazon EC2。
  
  
• PaaS - Platform as a Service：这是最创新的方案，技术上比 IaaS 更加先进。你可以把 PaaS 方案理解成一台具有无限计算，存储和传输能力的 application server，你会需要使用新的编程技术来实现应用，但是这样将使得你的代码可以同时运行在平台的数千甚至数万台服务器上。你的应用从上线第一天起，就为每天上亿的访问量做好了准备。当流量不断增长时，不需要担心架构升级带来的可能的 downtime，至于更基础的如安全和存储冗余等问题，就更是无需担心。目前这类平台里最成熟的实现就是 Google App Engine，而 Joyent SmartPlatform 现在也进入了 beta 期，同时由 NASA 和 Rackspace 在合作进行中的 OpenStack 项目也非常有潜力。

关于未来

我相信 PaaS 会是未来的主流，因为它可以为用户节约很多的时间和麻烦。当 PaaS 在未来更加成熟的时候，那时用户可以将更多时间用于思考如何快速实现业务逻辑，而不是纠结于技术细节。

而作为云平台上的开发者，我看到的机会就是，目前各种 PaaS 平台上都非常缺乏真正可用的应用。

大公司对于 PaaS 的投入，就好像在搭建一个大型的购物商城，但是最终决定这个商城业绩的，不是这个商城的基础设施完善程度（当然这很重要），而在于其中的商家。而商家中最有价值的，就是那类连锁的大品牌。

这些凶猛的流量来自 Twitter 上 @Fenng 的推荐，及豆瓣上和菜头的一篇日记。并且终于在大约晚上 10 点左右时，让 V2EX，这个跑在 Google App Engine 上的云社区，达到了 CPU Free Quota 的最大限制。

而在 Google App Engine 上通过 Google Checkout 付费购买 CPU Quota 却是一件有些奇怪的事情，因为支持的国家中并无中国。而我试了好多次都遇到了各种莫名其妙的错误。于是最后，原本我以为可以在 20 分钟内解决的危机，变成了大约一个半小时。最后，莫名其妙的 Enable Billing 成功。于是可以有足够多的 CPU Quota 使用了。

而这一切是怎么发生的呢？

在过去的几个月时间里，Olivia 翻译完了 Rework 一书，当然，不是得到出版社支持的正规翻译，只是纯粹出于爱好，并且想从中学到东西。这些翻译稿陆陆续续地发在了我从 5 月起恢复的 V2EX 上。而在 9 月 8 日这天，这本书的初译完成。

然后发生的事情你就知道了。

感谢 Fenng，和菜头两位前辈及众多网友的认可。我们以后会继续完成更多有意义的事情。

而这件事情让我得到的另外几点教训：

• 云计算在理论上来说意味着无限的计算能力和带宽，但是实际上当你遇到这样的突发流量时，云产品可能会因为一些非技术原因而让你尴尬。你需要提前做好准备，包括但不限于充分熟悉你所在使用和依赖的云平台。而经历了这次的流量事件之后，我对于这些问题也确实加深了理解。
• 这个世界上很多有质量的，惊人的事情，在前期或许是几个月甚至几年的沉默。而这其中的风险在于，你如何能够预知在经历了这些沉默之后，自己所做的是一个不会感到后悔的选择？

我订了本周五中午的机票，下午到北京。期望这次能够见到很多老朋友。

这是我关于 Project Babel 目前正在做和接下来打算做的具体内容，都写在这个 wiki 条目里。

Project Babel 是一个用 Python 语言写成的，运行在 Google App Engine 上的社区软件。我希望能够通过这个项目，产生一个对于创意工作者，中小公司及各种兴趣组而言足够好用的社区软件。同时通过将基础架构搭建于 Google App Engine 的云计算环境中，最大程度减少网站的维护工作量及安全担忧。

V2EX 社区即是使用最新开发版本的 Project Babel 搭建。

而那个时候，如果桌面 Mac 的分辨率还没有革命性的突破的话，或许开发者最好的选择就是外接第二个 Cinema Display 27 进行测试吧。

• 程序能够充分使用各种用户觉得自然的手势，甚至发明出让用户觉得自然的手势。或者，当看到别人的 app 中有实现一个很好的手势时，能够迅速恰当地应用到自己的 app 中。
• 精致但是不繁琐的设计，把握其中的度是最大的难点。争取只用图标就能抓住潜在用户的心。
• 适当地集成一些 social media，但是绝对不能未经用户同意就以用户的名义发消息，更不能扰民。
• 检查 deployment target 是否设置得足够低同时又可以满足程序运行要求，提交之前找至少 5 个不同国家的人进行充分测试，否则上线之后一个未发现未解决的 crash 会让你至少难受 7 天。如果一连几次提交都是为了解决悲剧的 crash，那么就应该停下来反省一下开发流程了。
• 如果是新项目，那么从一开始就要为 Retina Display 的设计考虑，而不是先完成低清版本再补充高清。高清的支持可能需要低清 2 倍以上的设计时间。一个小提示：不要在放大状态调整 Photoshop 里矢量图形的边缘，会出现恶心的，同时难以修复的锯齿，应该在 100% 的视图里去做这件事。
• 每天至少在 Xcode 里运行一次 CMD+SHIFT+A，确保一定要消除蓝色图标后的那个数字。

根据我之前的计划，2.4.0 将是 Project Babel 的第一个稳定版本，将提供完整的安装文档及 ZIP 格式的下载包。而目前 2.3.0 的源代码已经在 GitHub 公布，如果你希望尝鲜的话，现在已经可以 git clone。如果你希望用 Project Babel 在云计算平台上搭建自己的社区网站，而不是花费太多时间去折腾代码，那么我推荐你等待 2.4.0 正式版的发布。

所有的开发讨论可以在 V2EX 的 Babel 节点找到，欢迎在那里反馈问题，讨论未来。

一套软件一旦开源，就不再属于特定的某个人了。特定的人或许可以在特定的历史时期推进软件的发展，而长远看来，却是靠原则，理念，环境和用户来驱动一切，我希望 Project Babel 也是如此。

虽然都不是什么激动人心的酷功能，但是这类小功能，尤其是通过电子邮件找回密码，对于用户是非常有价值的。我用过很多个人编程爱好者做的网站，很多都没有这个功能。可以理解，因为完整的业务逻辑要实现起来很繁琐，同时要考虑到不能留有被滥用的漏洞。目前 V2EX 的限制是，用户不能在 24 小时内执行超过 2 次密码重设。

You probably already know that when you achieved certain amount of kills you can get a star for a weapon, and a bronze star gives you 500 points, silver 1000 points, gold 5000 points and platinum 10000 points. So Next Events can show you the least kills required for a weapon to get a star, and that's really fast way to rank up.

Several days after the release, we began to receive crash reports regarding this feature and we've figured out why: our upstream API BFBCS.com recently added a new weapon in their API outputs, and our app is not ready for that weapon because it lacks stars stats. That newly added weapon in API is called DEMOLITION, we guess it should mean the kills you achieved when you destroyed a building with C4, grenade or rockets. Since it lacks some necessary data for our app to calculate, then crashes happen. We'll support that weapon in future release, but for now, we're submitting an update to Apple for fixing the crashes caused by this unexpected change in API.

Thank you very much for your support and patience. The update should arrive in your iPhone in 5-7 days or even longer, because Apple has their mystery review process. If you can't wait, you can become our beta tester to get the update now.

For existing beta testers, you can download our latest fix from below links:

http://commondatastorage.googleapis.com/bc2stats/OLIVIDA_DEV.mobileprovision
http://commondatastorage.googleapis.com/bc2stats/BC2Stats.ipa

How to use: Please download the 2 files, drag them into iTunes and sync. If your iPhone/iPod says error regarding provisioning profile, you can safely delete all provisioning profiles on your iPhone/iPod (It can be found under Settings › General › Profiles), and install the app again from iTunes.

不过，MobileMe 的 iDisk 组件，其实是可以作为一个类似 S3 的云存储来使用的，并且很容易通过简单的编程来进行文件增删——iDisk 支持完整的 WebDAV。

最近，我将 V2EX 的头像系统，改用了 MobileMe 来提供服务。实践证明，在 App Engine 上，通过 WebDAV 来向 iDisk 上传数据是完全可行的，而且性能极好。但是有一些限制——App Engine 不支持 WebDAV 的 OPTIONS，PROPFIND 和 MKCOL 请求方法，唯一支持的有意义的是 PUT 和 DELETE，也就是说，你无法通过 App Engine 在 iDisk 上创建目录。因此目录必须提前用其他方式创建好。但是除此而外，一切都非常好用。

欢迎注册 V2EX 并试试我们的新的头像上传功能。

而我相信在未来，这些平台将会取代目前的传统 hosting。因为这些平台可以带来：

• 更高的可靠性，单一应用由数千台服务器支持。
• 更简单的部署，用户不需要关心哪些文件是更改了的，也不需要去服务器上胆战心惊地执行 SQL ALTER。在 Google App Engine Launcher 里，部署已经简化到单击那个蓝色的 Deploy 按钮，然后等待至多几分钟，所有的新业务逻辑就上线了，包括新的数据存储结构。
• 更合理但是有可能利润率更高的收费，对于简单应用，用户可能会比以前付更少的钱甚至不付钱，而对于复杂应用，一个应用消耗过多的资源却不会影响到云里的其他应用的性能。并且这些额外的复杂度也成为了云服务提供商的利润来源。

小企业和个人会首先成为这样的新平台的用户和受益者，因为对于他们来说，这个新平台更可靠，更简单，甚至更省钱。而为了让应用能够在这个新平台上运行，以往在 LAMP 世界里已经实现过的应用将会需要全部重新实现一次，于是就会有全新的云博客，云记事本，云论坛，云相册……我相信这个其中会蕴含无数的好机会，而这也是 Project Babel 2 和 Project Picky 的意义。

目前这个页面还没有能够 100% 覆盖所有的 Twitter API，不过接下来我会每天更新的。

目前一部分代码已经可以从 Launchpad 上下载到，不过根据文档，目前如果想要在自己的机器上安装这个东西，步骤还是不简单的。

从目前所透露出的信息来看，这个东西应该是在 Ubuntu 或 Debian 上进行主要开发和测试，目前主要支持的编程语言是 Python，用到了 Tornado 框架，一个由 FriendFeed 和 Facebook 贡献的开源 web 框架，某些方面非常类似 Google App Engine。而在数据存储方面，OpenStack 应该会提供一个类似 datastore 的对象数据库。

根据计划，OpenStack 会在今年 10 月中旬提供第一个发布版本。国内是否会有公司第一时间跟进并在国内提供这样的基于开源软件的云计算服务呢？

上线时的初代样式本是为移动设备所设计，因此现在若是使用 iPhone 或 Android 访问时，将依然可以看到 mobile 样式。

另外，V2EX 现在有了一个小小的新功能——Notes，这是一个简单可靠的云端记事本。

当选择要做一件什么事情的时候，或许应该想想接下来可能会遇到的困难。只是你年轻的时候缺乏经验，于是你想不到接下来如此之多的天灾人祸。不过那么多年过去了，你也算是多少有些经验——知道什么路可以走，什么路走不通了。于是可以再想想，当下一个五年过去之后，有什么东西是一直属于自己，并且在不断发展壮大的。

This is just a beginning, we'll bring more awesomeness in 1.6.0. Stay tuned. You can subscribe to our blog updates via this links.

If you're willing to help us testing 1.6.0 and future beta releases, welcome to sign up our beta program.

defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions '{"ORGANIZATIONNAME"="OLIVIDA";}'

然后下次启动 Xcode 时，创建的新代码中就是 OLIVIDA 而不是 __MyCompanyName__ 了。

于是如果到那个时候，iMac 没有升级到更高的分辨率的话（比如 5120x2880），将无法完整显示 iPad 的模拟器。

对于很多 Photoshop 使用者来说，无法看清楚屏幕上的像素将是一种挑战。比如我就经常依靠屏幕上的某个像素来确定某条线是否对齐。

经过我验证，ETag 部分确实用的是文件的 MD5 checksum。

需要使用最新版本的 Chrome 或 Safari 观看。

如果 Is Page 设置为 Yes，则文章不会出现在首页，也不会出现在 index.xml 中。但是可以通过指定 URL 访问到。

如果 Is for Sidebar 设置为 Yes，则该文章的标题会出现在首页左边的导航栏中。

这些设置的引入，及 Parent URL 和 Set 功能的加入，可以让你用 Picky 搭建出非常灵活的内容组织结构来。

Twitter:

结论是：要用 CALayer 可以，但是在写到屏幕上之前一定要先将这个 layer 的内容变成一坨简单的 bitmap，否则就等着看幻灯片吧。

我在 2004 年末的时候用 Python + dictd 完成了第一个版本的 Lividict，可惜那个网站无法逃脱一个致命的问题——就是它只运行在一台服务器上。所以当后来那台同时也运行着 V2EX 的服务器被拔线之后，这个需要独立 dictd 的 Python CGI 程序也就下线了。

当 2008 年 Google App Engine 问世时，我在第一时间注册了 lividict.appspot.com，不过那个时候对于如何在 App Engine 上做词典服务，确实没有太多的想法。不过似乎是一种巧合，App Engine 在一开始时，所唯一支持的语言，也是我在 2004 年时用来做 Lividict 的 Python。

两年之后，我终于把自己的这个项目开始着手实现，现在 Lividict 运行在 Google App Engine 上的第一个简单版本已经上线，并且可以通过 define.io 这个域名访问到。

为什么选择 define.io 这个域名，或许首先是因为运气，让我还能够注册到。其次就是 define 是 Google 一直以来的一个好用功能，比如你想查 livid 这个词是什么意思，那么只要在 Google 里输入 define livid 即可。所以用 define.io 来作为词典服务，实在是很妙的一件事情。

目前 define.io 能够提供的三类查询：

• 简明英汉释义（词条和音标还相当不完整，我正在补充中）
• 同义词词典（也就是 Thesaurus 查询。词条相当完整。同义词查询在构思产品名称或是代号时尤其有用）
• 任何英文句子的中文翻译

这只是一个小小开始。define.io 运行在 Google App Engine 上的一个意义就是，我不用担心这个网站会因为什么物理原因消失。因此我可以将我的全部精力投入到功能的完善和增强中。这很幸福。

http://github.com/facebook/tornado

如果你无法访问 tornadoweb.org，那么可以从我备份的这个地方下载最新的 0.2 版本：

http://web.me.com/v2ex.livid/tornado/tornado-0.2.tar.gz

安装方法：

tar xvzf tornado-0.2.tar.gz
cd tornado-0.2
python setup.py build
sudo python setup.py install

Hello World 例子：

import tornado.httpserver
import tornado.ioloop
import tornado.web

class MainHandler(tornado.web.RequestHandler):
    def get(self):
        self.write("Hello, world")

application = tornado.web.Application([
    (r"/", MainHandler),
])

if __name__ == "__main__":
    http_server = tornado.httpserver.HTTPServer(application)
    http_server.listen(8888)
    tornado.ioloop.IOLoop.instance().start()

这是 FriendFeed 已经在生产环境中使用的技术，本身的实现和用法也很棒。总之是一个非常值得学习的框架。

1. 下载 SocksiPy，提取出其中的 socks.py，放入 /usr/local/google_appengine。
2. 在 appcfg.py 的 import sys 一行的下面加上这 4 行：
   

   import socks
   import socket
   socket.socket = socks.socksocket
   socks.setdefaultproxy(socks.PROXY_TYPE_SOCKS5, "127.0.0.1", 7777)

其中最后一行中的 127.0.0.1:7777 即为 SOCKS 代理的地址和端口号，你可以换成自己的。至于如何获得这样的 SOCKS 代理，最简单的方式就是通过 SSH Tunnel 或 Tor。详细的我就不在这里展开了，你可以在网上搜索到很多这类文章。

我认为，人数应当越大越好。并且应该考虑的是，用户使用这个产品的频度，最好是那种每天都用的。

然后，应该通过技术和市场的手段，能够让最多的用户很容易就接触到产品，用上产品。这样才会有成功的可能。

每隔一段时间，在一个已经成熟的领域，就会出现一款简洁好用的软件来打破平衡。就像当年的 Firefox。可是那么多年过去之后，当 Firefox 发展到 4.0，于是也就不简洁了。而这个过程中，Chrome 出来了，一开始的时候也非常简洁，但是这个玩意从简洁到复杂的速度比 Firefox 还快。

似乎大公司的软件开发者们，就是很难抵住那种那种做更多功能的诱惑。而从投入产出比来说，其实在后期花大量时间做出来的新功能，其吸引新用户的速度未必能够和初期简洁时相比。于是有的人就选择离开，然后去做新东西了。

新东西肯定都是很简洁的。而能够一直让产品保持简洁，是一种立场，一种眼光和一种功力。比如 37signals 在此方面就功力十分深厚。

商业公司的商业项目当然可以追求利润，但是如果做出一个不符合大多数玩家期望值和常识的决定，就太可惜了——EA DICE 好不容易建立起了一个可以和 MW 系列分庭抗礼的多人 FPS 品牌，可是现在却因为短视在消耗这个品牌的好感度。

这一切让人感觉就像是，现在他们最关心的就是钱，而非持续提高游戏的质量。

• Leaderboard: check the top 50 people playing on PS3, Xbox 360 and PC.
• Watch List: add your friends or anyone to a watch list.
• Versus: you can compare with anyone now.
• No more crashes in Kits and Vehicles.
• Weapon Leveling Details: now you can see how many kills needed for next star.
• Force Refresh: if you think your stats is not most recent, you can always force refresh as many times as you want for getting latest stats.
• And many more refinements.

For celebrating the launch of 1.5.0, BC2Stats will be on sale for a limited time for only $0.99, from JUN-9 to JUN-11. Grab your copy now: http://itunes.com/app/bc2stats

The best part of the veteran system is that you can get an extra weapon: M1 Garand. The semi-automatic rifle used by American soldiers in World War II.

Although you can't mount Red Dot Sight on it, M1 Garand is powerful and accurate in short/medium range.

And if you don't know how to get Veteran 1, here is a quick and easy method you can follow:

• Log in to https://www.battlefieldheroes.com/playnow with the same EA account you're using for BFBC2. Battlefield: Heroes is a free multiplayer FPS developed/operating by DICE.
• Create a character in Battlefield: Heroes and play several rounds.
• Log in to http://www.battlefieldbadcompany2.com/ and click My Soldier > Veteran, and choose Battlefield: Heroes to add. Then you'll get Veteran 1 and being able to use M1 Garand in BFBC2.

So, veteran system is a really cool idea. Do you know that the 1st in PS3 Leaderboard, id lfenec is Veteran 10! That's pretty impressive, isn't it?

p.s. You can also get to veteran by playing Battlefield: 1943 demo, that is a free demo you can download from PSN/XBL.

[Thanks, Paul]

这是一个叫做“文章集”的新功能，通过给文章赋予同样的 article_set 值，你可以将一类文章归类起来。那么这样做的好处是？

1. 每篇文章下方显示的 related article 相关文章。比如这篇 Concentration 的下方。

2. hg 中的一个最新功能，可以将某个 set 的所有文章以 Atom Feed 格式输出。比如你希望将你的某个 Project Picky 安装实例中的一部分文章用到其他地方，那么这个接口就会很方便。比如这是 set=essay 的所有文章：

http://picky.olivida.com/set.xml?set=essay

值得注意的是，在部署了这些新功能之后，你可能需要花一些时间等待 GAE 为这些新功能用到的新查询类型构建索引。构建时间根据你的文章数量而定，所需时间可能不短。

另外就是，hg 中的 Project Picky 为大部分页面实现了 head 方法，这样的话，如果遇到像 Digg 这样通过 head 检查 URL 可用性的网站，就不会再出现错误提示了。

不过，或许是出于某种考虑，这些演示中并没有涉及那些“高深”的 WebSocket 和 Local DB Storage。

所谓的主线是：

• 从服务用户，到从用户那里收到钱，中间的层级应该尽可能少。
• 在全球，尤其是美国和欧洲，有超过 100 万的潜在付费用户。
• 潜在用户中，有相当部分愿意为了好的设计和用户体验付费。

如果你之前没有用过这类软件，那么用之前要慎重——因为你可能会从里面了解到太多你还没有准备好去了解的残酷现实。

并且，最神奇的是，退出 MobileSafari 之后，音乐也依然在继续。

FACT: Since Transmit 4, 11 days ago, Les/Tim/Mike and I have replied to 4,442 support emails. 644 left in the queue. Thanks for patience! -C

自从 Transmit 4 上线以来，他们平均每天要回复 500 封支持邮件。也就是说，如果一刻都不停歇的话，差不多 3 分钟一封。

我现在每天差不多要回 2 到 5 封，已经感觉这个世界是如此的多样化。如果以后这个数字也变成 3 位数，希望那个时候能够有足够专业的人来一起帮我吧。

每一段需要咬牙坚持的经历，都是后来自己会去感激的。

• Rush 模式的成绩及胜率，并且分别包括 Attacker 及 Defender 时候的情况。
• 武器和載具的星级。
• 在 Kits 页面显示 Best Weapon。这样的话，比如你想知道某世界高手用来杀敌最多的武器的什么的话，用 BC2Stats 查他的 soldier tag 就可以了。
• 自动更新时会显示进度了。

iTunes 下载链接：http://itunes.apple.com/app/bc2stats/id367328974

如果只是增加新功能的版本发布，那么等上 7 到 10 天也是可以接受的事情。但是如果是修复错误的发布，那么等上 7 到 10 天就会很要命。因为在这个过程中，1.0 版本中的错误可能就会带来 App Store 里的一堆 1 星评价。

为了避免出现这样的状况，有些问题真的要在提交之前想清楚。

• 每个开发者都可以用 Ad Hoc 方式在最多 100 台设备上发布 beta 版应用。我觉得这个资源应该好好利用，并且争取能够有几十个热心用户在 submit 之前帮忙测试 1 到 2 天。这样的话，很多正式上线之后猛然发现的 show stopper 都可以用这样的方式测出来。
• 不要在提交的 app 里包含自己不确定的东西。这样的东西可能会带来一堆愤怒的一星评价，而错误的修正从发现到到达最终用户可能会需要 7 到 10 天。
• 和愤怒的用户沟通很重要。但是用何种方式沟通呢？Twitter 或许是一种很性感的方式，但是基本上很难覆盖到你的所有用户。著名的 Doodle Jump 游戏在全世界卖了超过 100 万份，可是他们的开发商 @LimaSky 的 Twitter 帐号上的 followers 却只有 4000 不到。而这种时候，一个简单的 CGI 表单可能会更有用。

• 为什么 Apple 会要求所有的应用必须能够支持所有的 orientation，因为 iPad 实在是很重，如果用户拿在手上，已经习惯了一种 orientation 的话，这个时候如果一个新启动的应用要求用户变换 orientation，那么确实会有点累和不爽。
• 目前的 App Store 里的 iPad 专区，可以用广阔天地，大有作为来形容。
• iPad 屏幕的像素密度很高，因此不要假设一些很小的字体会在上面有很好的显示效果，同时也是因为像素密度的原因，图片的显示效果会特别好。而游戏类应用，得益于像素密度，物件的边缘感觉就像是已经有了抗锯齿效果一样。
• 如果程序中设计有让用户滚动的主区域，那么一定要让这个区域可以很容易地被右手大拇指触碰到。
• 和 iPhone 时代一样，Apple 自己的应用中有一些非常好看的组件，但是显然这些组件不是位于公开的 API 中的，比如 App Store 里用于放置截图的那个框。这个时候就需要各位的山寨功力和眼力了。
• 大部分情况下，UISplitViewController 可以解决很多情况，但是自己构建更复杂的界面也不是不可以，比如内置的 iPod 应用就没有用标准的 UISplitViewController。

以上是玩了一个小时之后的感觉，以后有新的发现再发上来。

另外就是，关于前段时间 Twitter 收购 Tweetie，我觉得这是一件 100% 的好事：

• Loren Britcher 向全世界的 iPhone App 开发者演示了一次现实版的美国梦。
• iPhone OS 在全世界的活跃用户有几千万，而 Twitter 的也有几千万。但是 iPhone OS 用户为 Apple 及相关公司创造的 ARPU 是一个巨大的数字，而 Twitter 用户的 ARPU 呢？因此，这次收购若是能促成 iPhone OS 用户向 Twitter 用户的转化，那么必然也能提高整个 Twitter 生态系统的价值。
• 最后，我觉得这件事情未必对于其他第三方开发者和用户而言是坏事。首先，免费版本的 Tweetie 会干掉很多垃圾应用。但是再往后，公司中各种意见妥协的结果真的会战胜 Loren 单打独斗时的高效和创意么？

• 这是我们有史以来玩过的对大陆的网络状况兼容得最好的多人 FPS，居然在 PSN 上对战时一点都不卡。
• 多人部分有 4 个兵种可选——突击，工程，医疗，侦查。这 4 个兵种的可用武器和玩法差别都相当大。
• 游戏中提供了非常深邃的升级系统，没有那么几十个钟头是不可能升满的。而等你到达高等级之后，和同样高级别的其他玩家对战的感觉又完全不同。
• 游戏的大部分地图都是室外，非常开阔，让人不得不佩服 Frostbite 1.5 引擎的表现力。并且游戏中的所有建筑，只要被手雷砸到或是被火箭轰到，都会崩然倒塌，物理效果十分真实。整个游戏的环境都是可破坏的。比如看到敌人躲在墙后，那么一发火箭弹也可以让他毙命。

经过差不多一个月的厮杀，FPS 菜鸟如我们也终于到了 25 级。所有武器解锁。于是可以根据战况自由地选择任何武器。于是在 4 月 8 日这天，我们在想，既然这款游戏这么好玩，为什么我们不为它做一款 iPhone App 呢？

然后经过 4 天时间，BC2Stats.app 1.0 提交到了 App Store。这是一款用于在 iPhone 或 iPod Touch 上查看 BFBC2 多人游戏的状态，包括：军衔，杀敌数，爆头数，子弹发射数，命中率，狗牌（Dogtags），各种武器的详细状态，各种载具的详细状态，徽章（Insignias/Pins），奖杯等等。由于我住的地方 3G 覆盖不是很好，所以我们在代码中针对各种可能下载失败的情况做了充分处理，因此哪怕是使用巨慢的 GPRS 网络也可以在一分钟之内获得所有的状态信息。

比如上图是我最喜欢的武器 M95 的具体信息，而更多的截图可以到 BC2Stats.app 的网站查看。

这是我第一次喜欢一个游戏喜欢到为它做一个 companion app 的程度。这个过程实在是太刺激了。如果你还没有开始玩 BFBC2，那么我强烈推荐你试试：

http://store.steampowered.com/app/24960/

从 App Store 下载 BC2Stats.app：

http://itunes.apple.com/app/bc2stats/id367328974

First ordering property must be the same as inequality filter property, if specified for this query; received hits, expected __key__

并且，对于比较操作，也有巨大限制：

BadFilterError: invalid filter: Only one property per query may have inequality filters (<=, >=, <, >)..

另外就是，当你部署了一个需要新的 index 类型的功能时，很可能 GAE 上一时半会还没法构建出新的 index，于是为了不使得服务中断，那么最好是在新功能的 GQL 处用上 try: except:，当然，前提是新功能不是一个必须功能。

或许我应该在 approved 之后，拍一段 HD 质量的视频然后传到 Vimeo，有些使用时候的感觉，只靠静态图片是远远不能充分传达的。

最近发现的一个有意思的站点 http://cssiphone.com/ ，里面收录了大量专为 iPhone 设计的精美网站，很有参考价值。

“在移动设备上，当人们有了什么问题时，并不会去到搜索引擎搜索，而是打开解决特定问题的 App。比如想找吃饭的地方，就会去打开 Yelp。”

这个观点想要传达的信息是，任何一类特定问题，在 iPhone 上都有一个 App 来解决。而驱动每个 App 的，就是背后的 API。

我想，或许最终这个世界上每一个有用的 API，都会被用来驱动某个有用的 iPhone App。目前最成功的例子是 Twitter，全世界已经有了数百个靠谱的 Twitter API 应用 并且还在不停增长中。我觉得，在未来，个人开发者如果想要获得最大的成功，就应该去盯住那些潜在受众群最广泛的 API，并在移动设备上实现一个优雅的 UI。或者，自己去创造一个这样的 API 源。

国内的网站中豆瓣拥有最完整也最开放的 API 支持，但是我对豆瓣的 API 一直感到遗憾的是：对于需要读写用户信息的 API，他们要求必须使用 OAuth 验证，但是却不提供对 HTTP 验证的支持。我了解 OAuth 的一堆优点，但是：

• OAuth 的签名算法在移动设备上没有成熟好用的库（如果现在已经有了的话，欢迎告诉我，至少在 2008 年我开始时是没有的），而且那个签名规则确实一开始不容易理解。
• 豆瓣的 OAuth 认证过程不是 iPhone Friendly 的，而是一个面向桌面浏览器设计的页面。
• OAuth 在 iPhone 上的开销会很大，因为要完成这个过程，无论如何需要启动一个浏览器。
• OAuth 不能用一些简单工具进行调试或者 play，支持 HTTP 验证的 API 就可以用 curl 这样的简单工具进行调试。至少是降低了 API 的使用门槛。

或许也是因为这些无论技术或用户体验上的原因，目前 iPhone 上最靠谱的 Twitter 客户端无一使用的是 OAuth，全都是 HTTP 基础验证。

Figure 1. Twitter clients on my iPod Touch 3rd Generation

HTTP 基础验证存在一些安全问题，比如用户名和密码其实是用 BASE64 加密之后传输，这样的话这些敏感信息很容易在中途被截获。但是如果使用的是 HTTP 基础验证的升级版 HTTP 摘要验证，并配合上 SSL 的话，安全性就会大大提高。如果觉得大部分摘要验证实现中的 MD5 算法不够安全，服务器端也可以指定要求客户端使用 SHA256 或者是其他更安全的摘要算法。

在我看来，我对一个 API 源的期望值包括：

• 同时支持 HTTP 基础验证和 OAuth，并且 SSL 可选。
• 对于读取操作，不要设每小时限制（这也是 Twitter API 中目前最讨厌的）。
• 如果还能提供一组像 Google App Engine 那样的漂亮详尽的性能图表就更好了。
  
  

成为一个 API 猎人是一种很好玩的体验，就像是在核爆炸之后的世界，拿着一支捡来的外星武器在废墟里游荡的感觉。而作为探索的出发点，我会推荐 GitHub，hg.io 还有 ProgrammableWeb。

用一半的时间完成 80% 的用户会用到的功能。并且需要保证这个部分的完成足够稳定。这个部分进行再多的测试都是不够的。所以我会拉上周围的所有人来帮我测试。基本的 look-n-feel 和底层的数据访问方面的代码也在这 80% 的范畴中。而最后会直接面向用户的介绍网站和网站上所用的文案，自然也是在这 80% 中。

用另外一半的时间完成 20% 的用户会用到的功能。这些功能在实现难度上比上一部分高，但是最后只能满足可能还不到 20% 的用户。但是这部分用户的评价对软件的销售或是网站的访问量有重大影响，所以用一半的整体资源来做让他们高兴的东西，也是应该的。

而 1.0 阶段完成，站稳脚跟之后，自然会有下一阶段的做事方式。不过在下一个阶段中，诱惑变多，有的时候可能会花大量的时间去完成只有不到 1% 的用户会用到的功能，这在一方面来说是种乐趣，可是也意味着巨大的机会成本。

这是 2.0 分支的第一次更新，除了例行的 AI 修正和增强之外，还增加了两块棋盘。其中一块是超级有爱的 Bangumi 主题。

或许你会觉得从实用性来说，Bangumi Tan 主题不太容易看清楚——可是，为什么不可以有一块专为萌倒小朋友而设计的棋盘呢？♥

这里是 Gomoku 的完整更新记录。

不过最近效率不高倒是真的。似乎人随着年龄增长，于是每天吃掉的话比说出来的话就越来越多了。曾经国内有很多喜欢做网站的年轻人，他们每天看着自己的秘密花园里的草木越长越茂盛是一件非常开心的事情。而现在，我觉得，对于他们而言，最好的路似乎，要么加入一家大公司继续做自己想做的事情。或者，彻底转变自己的兴趣？去和横在自己面前的那道墙纠结看起来很壮烈，但是无论如何都不是本来的意愿。总之，我觉得自己现在每天呼吸的空气都挺变态的。而自己的兴趣，其实也正在一个砍掉重练的阶段。这个阶段无论如何努力都无法让其变得更加舒适自然。

Gomoku 是我在 2008 年中开始的项目，那是 iPhone 官方 SDK 刚刚宣布的时候。一开始在申请 iPhone Developer Program 时遇到颇多挫折，不过最后还是在 2008 年 10 月时拿到了 iDP，应该是当时中国的第一批。过程中得到了苹果公司的夏鹏先生和张碧仿先生的巨大帮助，在这里再次感谢他们。在拿到 iDP 后我就提交了 Gomoku V1 并很快得到了通过。根据我当时的搜索结果，Gomoku 应该是当时 App Store 里第三款五子棋游戏。

Gomoku V1 上线时我正在杭州，而自己那时候的工作并非是和 iPhone 有关的。在杭州的不到一年时间我想明白的事情是，我到底还是要做一件自己真正感兴趣的事情，才会在遇到挫折和不快时，能够持续保持斗志。于是我最终在 2009 年 8 月离开了杭州，然后让自己进入到了一种彻底自由的状态，去做自己想做的事情。

于是这半年来，我的几乎所有时间都在 iPhone OS 和 App Engine 上。而 Gomoku V2，我的第一个 iPhone App 作品 Gomoku 的 2.0 升级版本，在今年 3 月 29 日首先上线。

我在这个版本中重写了 AI 引擎，增加了 7 种不同的棋盘样式，增加了显示棋盘坐标（根据国际比赛标准）及上一步的功能，并且还增加了非常详尽的帮助页面及游戏胜负统计。

V2 于 2010 年 3 月 25 日提交到 Apple，在 4 天之后审核通过。App Store 现在的审核效率实在是提高了很多。我计划在下个月的 15 号，及 5 月初，再提交两个应用。而 Gomoku，也将会持续改进下去，并且它的后续版本的升级都将是免费的。如果你喜欢五子棋，那么欢迎来试试我的版本。

下载地址：http://itunes.apple.com/us/app/gomoku/id294454696?mt=8

昨天把自己一直以来会在工作时候听的音乐整理了一下，列表在这里。虾米的精选辑有 50 首的上限。我改天再做 Part II 了。

最近一直十分感叹的事情就是，Apple 的保密工作实在是太厉害了。3 月都快结束了，我们还是丝毫不知道 iPad 的内存究竟会有多大。而这个数字决定了 iPad 上究竟会不会出像 Aperture 或者 Lightroom 这样的软件。我希望这个数字是 512。毕竟 PS3 也只有 512，但是足够做很多事情了。

一点关于 iPhone App 开发的小体会：不要把一堆计算任务压到启动的时候做，哪怕是看起来再小的部分——比如计算 cell 的高度。尽可能提前把这些东西都算好，用空间换时间是绝对值得的——启动更快则用户也更高兴。而且很多莫名其妙的和 WebCore 或者 icu 有关的启动即崩溃的问题也就一并解决了。

• Flash Catalyst - 很早就宣布了的技术，记得好像最初的名字是 Thermo，让设计师可以直接在 Photoshop 中，通过一些层规则，就直接输出可用的 UI。
• Flash Creative Suite 5 - 可以用来开发 iPhone 原生应用，并且所开发的应用可以提交至 App Store。目前 iPhone 开发平台上还没有任何强大的 content authoring 工具，如果 Flash CS5 能够实现承诺，那么冲击巨大。

似乎从小到大，这样的情况还是第一次遇到。而几天前看到新闻说，甚至连机场的跑道，都因为地下水干涸而下沉断裂，进而影响到飞机起降。虽然目前昆明城区内各种供水似乎还算正常，可是一切却像是正在朝越来越糟糕的方向发展。

如果这样的状况真的持续十年？那么这里的小河和池塘会慢慢的干涸，一切绿色的植物也将消亡。只是稍稍想像一下就觉得恐怖至极。

于是想到几个问题。

1. 一些极其浪费水的行业或许应该消失了，比如桑拿和澡堂。
2. 酒店或许应该为每个房间装上单独的水表，并且将房间内的所有用水算为额外的收费项目。
3. 石油是可以通过管道进行长距离输送的，那么水呢？我好奇这个世界上是否有跨省输水管这样的玩意？
4. 不知道政府是否有类似我们统计网站流量那样的精确系统，用于统计一个省份各个地区的水消耗，并且生成直观的图表甚至智能化的报警呢？（Google Analytics 就有这样的报警）精确的数据是做出正确决策的第一步。

在发生这次旱灾之前，昆明的民用水价和全国相比都不算便宜——4 元一吨。如果因为这次的旱灾将水价提到 8 元一吨，并且将额外征收到的水费用于人工降雨的尝试，那或许也不错。

在过去的两个月，也就是自 iPad 发布后，我一直在为一款 iPad 上的软件昼夜工作。现在两个月过去了，这款软件已经基本上在 Simulator 中成型了。接下来期待的就是尽快到真实设备上进行测试并最终登陆 App Store。

随着 Mac 屏幕的像素密度逐年提高，我个人感觉 Apple 从 2000 开始发展的一套 GUI 设计风格已经越来越需要一次巨大的更新，很多 Apple 自己的软件在 iMac 27 及 MacBook Pro 17 上显示时，字体及很多控件的尺寸已经显得太小，进而影响到可用性。而 iPad 会成为下一个 10 年 Apple 新的 GUI 设计风格的试验田。

目前 Mac OS X 的 Aqua 风格有很多细节，但是问题是这些细节一旦需要进行缩放时就会遇到问题——Apple 自己的很多设计优秀的软件，及第三方的优秀作品如 Things，界面上的元素基本上都是 PNG 图片构成的。而完全使用矢量图形构成的 GUI 目前在大规模使用的恐怕只有 Java 的 Nimbus。

iPad 这样的触屏设备天生就会需要尺寸较大的操作控件，于是很多 Mac OS X 现成的设计风格更是无法移植。于是在这样的上下文中，Windows Phone 7 的那种摒弃了很多细节强调 zoomable 的设计，就显得十分有趣而且 modern 了。

我的美服 PSN ID：OLIVIDA，欢迎 BFBC2 玩家来加。通常下午 2:00 到 3:30 在线。

http://start.io/livid

有多种布局和配色可以选择，另外还支持 OPML 导入。我之前自己做过一个类似的小东西自用，运行在 GAE 上：http://start.olivida.com/，源代码在这里。

我从 06 年开始使用 Steam 时就在期盼这一天。这是我的 Steam Community 主页：

http://steamcommunity.com/id/v2ex

相信 Mac 的市场占有率将因此获益。

而现在已经过去 8 个小时，故障依然持续。全球数百万玩家受到影响。在早些时候，PSN 一词甚至成为了 Twitter 的 Trending Topic。SCEA 的官方 Twitter 帐户 @SonyPlayStation 在 7 个小时前对此的回应：

We're aware that many of you are having problems connecting to PSN, and yes, we're looking into it. Stay tuned for updates.

在我印象中，这是最近几年所有云概念服务中时间最长，影响用户最多的一次 down 机。于是，在这个本来属于 RE5:AE 的下午，我搬出了已经蒙了一层灰的 PS2，玩了一个小时的各种老游戏。

[paths]
default = https://hg.io/livid/olivida-start/
default-push = https://hg.io/livid/olivida-start/

你需要把上面的 URL 换成你自己的项目的。之后你每次 hg pull/push 时，就不需要输入 URL 了。

start.olivida.com，我上面提到的那个小项目，是我目前自用的浏览器默认首页，运行于 GAE 上，收录了我最常访问的网站，及一些在安装新电脑时有用的网址。

不过，我得提醒你，这个软件目前的版本号是 1.0。