我是在最开始插入这段代码：
<script>if (top !== self) top.location = self.location;</script>

Azure价格是稳定，不过比GAE贵＝＝

@sohoer 影响不大。马上会支持Python 2.7（从billing history看估计是November 20th, 2011），到时候一个instance可以同时响应多个请求。

另外发现这几天的数据库读取次数都刚好超过50k，看来得优化了＝。＝

看到几个抱怨的，大应用还是果断撤离吧：

I am one of them. Monthly charge: $900 -> $2850 (310%)

Our costs went up 2800% under the new pricing.

We are going from $5,400/month to $26,500/month (Python) - and this is
only one of our apps.

I am not in the same league as those who pay thousands of dollars per
month but rather the average small developer who sees what was a 31 $
monthly bill jump to over 500 $.

这个价格几个月前就定下了，曾经向Google提议把24 Instance Hours增加到25，他们回复说可以考虑考虑，但是就没下文了…

数据库操作收费的原因是：现在不按API CPU时间收费了，只看API调用次数。

以我的blog为例，今天19小时数据库调用29350次，使用0.17 CPU时间。按之前的方法计算为$0.10 * 0.17 = $0.017，按新方法计算为29350 / 10k * 0.01 = $0.029。

虽然也贵不了多少，但免费配额确实太少了，只有50k次。
仍以我的blog为例，19小时用了5％ CPU，理论上免费配额可以支持20倍访问量。但调用次数已经达到50k的60%，基本上没多少扩展空间了。

然后是如果收费，至少每个月$9，哪怕你原本只需要支付$0.01。

每个月剩90％流量没用的路过…看来是太宅了

不知道为什么都推荐Reeder，真正用起来就一堆恼火的问题。例如排版经常出现滚动条（而且经常滚着滚着就到右边了），直接显示全部条目而非分页（导致无法只将一部分条目标记为已读）。

MobileRSS的离线缓存功能是渣，谁用谁知道。

目前感觉iReadG是唯一没啥大毛病的，虽然也存在各种不爽，例如标记已读时阻塞主线程。

@wickila 不知道你看的是什么文档。

如果你是用Windows的话，Python的Doc文件夹下会有个pythonxxx(版本号).chm。打开以后选择index，输入Element，第一条就是“Element() (in module xml.etree.ElementTree)”，进去后翻到最上面或最下面，也会显示模块名。

就算没有文档的话，也可以在命令行里显示出来：
>>> Element('a').__class__
<class xml.etree.ElementTree._ElementInterface at 0x00E014B0>
_ElementInterface就是类名，前面的就是模块名。

@codeplay 要说明它的原理有点复杂，总的来说是这样的：os.walk()生成了一个generator对象，for循环会调用这个对象的next()方法，这个next方法返回了一个含3个元素的tuple，分别对应到root,dirs,files变量。

我的感觉是你似乎不太清楚for的这种用法，举个例子来说吧：
for x, y in [(1, 2), (3, 4)]:...
它实际上是这样的缩写：
for (x, y) in [(1, 2), (3, 4)]:...
于是第一次循环中，(x, y)就被带入了(1, 2)，即
(x, y) = (1, 2)
而它又相当于
x = 1
y = 2

至于generator嘛，我就拿个简单的例子来说：
def f():
yield 1, 2
yield 3, 4

g = f()
print g.next()
print g.next()
print g.next()

输出结果是：
(1, 2)
(3, 4)
Traceback (most recent call last):
print g.next()
StopIteration

可以看到，每次next()方法都会返回yield表达式的结果，当没有更多的yield时，就会抛出StopIteration异常。

而用在for循环里的时候，Python runtime会自动捕捉StopIteration异常，并停止当前循环：
for x, y in f(): print x, y

总觉得你学的不是Python…

1.自带的文档是我见过所有语言中最好的了，其次是PHP。貌似只有这2门语言会带有例子，而且Python的文档还能当教程用。当然，你必须得懂英文。
2.系统自带的类基本上层次都很浅，包名也基本不会超过2层，文档中输入类名就能定位到，实在不知道你为什么会出现这种问题…有钱的话，IDE换PyCharm吧。
3.看文档，或者看源码。

@duoglas 用GTD应用吧，虽说本来是用来规划要做的事，不过也有视图可以查看已经完成的事。只是这类应用一般都超贵，免费的做得最好的应该算Doit.im了，不过iPad上老是莫名其妙地crash。

@wickila 你可以在lambda函数里调用函数的，比如check() && xxx

可以用db.ComputedProperty，用法可以参考这里：
https://bitbucket.org/keakon/doodle/src/7bd5fdb6acd2/zh-CN/model.py#cl-331

我想说的是Java就是骗钱的。用它的话内存开销会大几倍，需要买更好的服务器，所以自然受到这些卖服务器的厂商的青睐（IBM、HP、Oracle等）。它们花了大把的钱造势，然后就把很多人和公司忽悠进去了。

别和我提Java的性能啊移植性啊什么玩意，这些厂商就搞个噱头而已，一大批的服务器跑的都是1.4或更低版本，慢是肯定的，不升级的原因就是因为各种不兼容。语法方面连enum都没有，更别说什么动态性啊lambda函数啊。

当然，我最讨厌的不是因为它忽悠人，而是嫌它太啰嗦了。很简单的玩意也要多个类出来，把类都用滥了。而在读源码时，你虽然不会被其他语言中诡异的语法困惑，但却要花数倍的时间浪费在理解几个类之间错综复杂的联系上，然后才能体会出设计意图。
这自然不是设计模式的错，它本身是很好。可是Java的语言表达能力实在有限，得用一堆代码去阐述一个思路；而随着代码量的增多，就无法体现出设计的优雅之处了。

小红帽用不来，还是多点触摸板好用＝＝

启动15圈，关机不到3秒，10.6.8 with HDD路过…

看样子还是不装Lion的好…

你只能下到xcode with ios sdk，不能下个xcode，然后再去下个ios sdk装上…

感觉对比度太低了

我想说的是，做功为0和没做功是两回事，因为有无用功的存在。关键在于，前者针对受力体，后者针对施力体。

举例来说，你两手空空站着，和提着手提包站着，虽然做功都为0，但后者明显要消耗你更多能量。
再比如说，你用力推一栋楼，你肯定要消耗能量，但楼并不会动，做功仍然为0。

然而你把钉子钉入墙里，直接就能维持平衡了，难道钉子也从自然界中获取了能量？答案当然是否，因为重力和墙给它的反作用力达成了平衡，所以不需要能量来维持。

那么是不是只有人才会产生这种无用功呢？当然也不是。
考虑一下一辆悬崖边的汽车，它用绳子吊着一重物。汽车的静摩擦力并不能抵消重物的重力，为了避免掉下悬崖，汽车需要发动机提供动力以维持平衡。

可以看出，如果一个体系自然就处于平衡状态，那么维持它就不需要做功；而如果并不平衡，维持它就需要做无用功。


而针对这个问题，磁铁有没有做功，和它是否在动无关，我们能知道的只是磁力和重力达成了平衡。
至于产生磁力是否需要消耗能量，可以通过观测是否有热量产生来判定，因为任何能量的消耗和转移必将伴随热量的产生。
不过我倾向于认为它和重力（或者说万有引力）一样，并不消耗能量来维持。