demeter很有趣，去年新年夜就揣了两瓶给老婆惊喜。喜欢体验的话可以买小包装的。北京的三里屯也有他们的店。

越狱后可以在iphone4里面将STHeiti替换为“Hiragino Sans GB”的，效果就可以接近mockup了。BTW: Hiragino Sans GB的w6粗体真的很粗 :D

忘记说了，1pt是1个point。1point是1/72英尺，这个css unit一般用在印刷样式上面。
see: http://www.w3schools.com/css/css_units.asp

retina display下的iDevice的device-pixel-ratio是2，也就是说1px会显示成2个设备像素宽。所以理论上来说在没有缩放（scale）的情况下，1px的点是4个像素。
这样，在不缩放时1px在iphone4和iphone3上显示的效果一致。
比较讨巧的是如何对于不同设备使用不同密度的图片。此时可以使用media query，-webkit-min-device-pixel-ratio: 2)来link不同的css。
如果想保证1px不被缩放，可以使用viewport的meta固定scale，V2EX就在使用“initial-scale=1.0; maximum-scale=1.0;”。

diamondtin

给咨询师定价是很难的事情，且独立咨询需要双方合拍才有意义。所以有点怀疑如果你给自己定了价，别人真的点了你，你会有什么感觉。双方能够通过这么简单的介绍达成默契，最后相互满意么？

linode的ticket反应神速，非常对得起价格，是真正的VPS。
slicehost也不错，它的wiki是SA的好帮手，而且来自Rackspace。

前两天做了一个分析：

联通 iPhone4
16G
96 (96 - 82) * 24 + 5880 = 6216
126 (126 - 95) * 24 + 5880 = 6624
156 (156 - 128) * 24 + 5880 = 6552
186 (186 - 145) * 24 + 5880 = 6864
226 (226 - 170) * 24 + 5880 = 7224
286 (286 - 245) * 24 + 5880 = 6864
386 (386 - 245) * 24 + 5880 = 9264
586 (586 - 245) * 24 + 5880 = 14064
886 (886 - 245) * 24 + 5880 = 21264

32G
96 (96 - 91) * 24 + 6999 = 7119
126 (126 - 104) * 24 + 6999 = 7527
156 (156 - 137) * 24 + 6999 = 7455
186 (186 - 154) * 24 + 6999 = 7767
226 (226 - 179) * 24 + 6999 = 8127
286 (286 - 212) * 24 + 6999 = 8775
386 (386 - 291) * 24 + 6999 = 9279
586 (586 - 291) * 24 + 6999 = 14079
886 (886 - 291) * 24 + 6999 = 21279


16G合约相比港版裸机
4988 -> RMB 4311 * 1.015 = 4375
96 (240电话， 340MB，短信80） 6216 （每月76.7）
156 (420电话，570MB，短信150）6552（每月90.7）

16G合约相比国行裸机
4999
96 (240电话， 340MB，短信80） 6216 （每月50.7）
156 (420电话，570MB，短信150）6552（每月64.7）

每行字数是阅读心理学问题，限制字数是为了提高Readability。英语国家有很多人有阅读障碍，所以现在行内字数可以帮助这些人断句，在一定程度上提高可读性。中文用户好像出现这种问题没有那么多吧？平面设计里面的排版基本上都是分栏的布局，通过增加留白、行高提高可读性，网页设计里面也是一样。

国外平面排版（印刷）规矩一般是一行10个word，不超过15个word。那么中文相应的应该是25个字左右。不过这要求你的网站正文区域在不同分辨率适配单栏和分栏的布局，目前CSS3中的Column layout部分在力求解决它，但是目前看还不完美吧？

MongoDB很容易替换Mysql，支持Map-Reduce，所以是一种可以平滑切换的解决方案。
其实Key-Value store中的Big table分之这里没有提到，在大数据量的情况下使用这种面向列的数据库是靠谱的解决方案。典型代表是：
HBase
http://hbase.apache.org/

Hypertable
http://hypertable.org/

CouchDB是一个Restful DB，它是未来的实现Open Web的一种关键技术。通过Restful的接口暴露的持久化数据源，可以说这就是Web。

@Kymair Cassandra我们做过一个月的Spike。发现有两个麻烦的问题，一个是读一致性，另外一个是稳定性。Cassandra的Quorum不能保证一致性（Ramdom partition时），All的性能和稳定性有问题（一个Node挂了所有读都会失败）。Cassandra在多机集群的时候写压力大非常容易Crash（我们测试是4台24G内存的机器），内存管理有问题然后就自己退掉了。Cassandra的社区反馈比较慢，而且Facebook没有持续贡献代码，其中的很多bug不知道什么时候才会修复。
所以我们放弃了Cassandra作为分布式的key-value store。

印度不同地区吃的饼是不一样的。我去过孟买和普内没见过这种飞饼，那些地方（印度西部）一般吃paratha或者naan。不过飞饼的确来自印度，是另外一些地区的食物，飞饼一般叫roti，又细分为很多种。
区别大概是：
- paratha/prata/plata：多层，烤制，油比较少。http://en.wikipedia.org/wiki/Paratha
- nann:就是馕，印度的馕一般比较薄，层少，烤制。http://en.wikipedia.org/wiki/Naan
- roti:很薄，分层，在比较薄的锅上面煎。http://en.wikipedia.org/wiki/Roti

我了解也不多，参考wikipedia比较靠谱。

Local-branch和以前集中的scm的branch完全不是一个概念。hg也支持用hard link的本地branch，但不好用，可以用queue的插件。而git的local branch我觉得是它的精髓，spike dev bug-fix都可以并行了。它让分布式scm的优势完全发挥出来了。

Eclipse + Pydev，可以使用其中的重构功能，自动提示+实时pylint。
JetBrains的PyCharm应该有更好的重构支持和更好的快捷键，可惜比较贵。

最好的办法就是用SuperDuper!做一个全盘镜像，然后再恢复回去（此时一定不会出现分区问题）。我试验过，整理整个硬盘的时间（我当时是250G硬盘，95%使用）比做SuperDuper!要慢一倍。而且整理过并不能保证BootCamp分区成功。

好像上面这样会更口语化一些，后面的翻译我觉得挺好的。