for i in irange(0, 0xffffffff):
__if i & 0xa000000 or i & 0xac100000 or i & 0xc0a80000: continue
__print i

其实没什么，这很正常的
只是deadline还没到罢了

先不考虑REST是一种风格而不是一个标准
GET是允许cache的，那这时候不+1是不是与需求相悖？

这还真不一定，取决于你用的是tornado哪部分功能了。
但是一般来说，以tornado的卖点来说，是单进程模型

同时用着HHKB和cherry的普通键位，在公司ctrl在下面，在家ctrl在A旁边感觉还好。。
第一次按的时候会错，第二次就好了

@ffts 我倒是知道那些新歌喜欢，想去听（比如新番OP/ED）。但是自己一首首搜，然后加歌单太麻烦了。但是推荐又推不出来

@ffts 是这样的，xiami听推荐歌单来来回回就是那么几首，没有新的

@arthurhuang 别傻了，65.49.2.178这哥们根本开不了机了

@ayanamist 我记得javascript的 string+ 没有多余的性能代价吧。

@ry_wang http://jsbin.com/aSelozi/1
很慢吗？根本没有啊，10w个div毫无压力啊，当然js执行是要很久，谁让数据量那么大
不能分页吗，或者分开部分加载
你确定是div的问题而不是模板引擎的问题，或者是reflow次数太多的问题？

@ry_wang 先将html写到一个string里，然后一次添加到页面中去

让我猜猜，你是不是一个div一个div追加到页面里面去的？

@ritksm 人家不也是说“优先考虑”吗

@ritksm 如果必须用跳板机登录呢？跳板机还是动态口令，允许在跳板机映射端口呢？

RSS是一根线，串接了各种可能性，但归根到底是需求。
你是要新闻阅读，深度阅读，小说臭百，图站，还是bt资源订阅。各种各样的使用场景有各种各样的APP，而它们往往还做得比RSS好。

但是，归根到底是需求，如果APP能满足需求，那么APP就是你的菜，但如果不能，RSS就是串接你需求的法宝。
从上游的资源，亦或者各种xx转RSS，中间的全文引擎，转烧，到下游的Reader，资源订阅器，脚本。RSS串接起了整个系统。
那，这样的需求真的存在吗？当然存在了，你没发现那么多人把RSS做成APP了吗。

纸条不是天然自带签名的吗。人肉伪造签名多难啊
而且传递过程可监控，不要想那么多好不好

试用了下foxmail，exchange还算流畅，不像airmail各种bug
新标只有一种，不重视归档，使用习惯不同，留着备用吧

你想多了，就单纯一个商业行为
对于市民来说，收费公园除了带孩子，一般是不会去的，即使是假日
那么，这部分人就赚不到钱了不是
通过差异定价，搞一个年票，收一部分钱，而这部分人并不真的会经常去公园，即使去也大都会在淡季（特殊假日会停用年票的），也不需要多付出多少成本，何乐不为