博客园_飞林沙

virtualenv搭建虚拟环境

2011-12-29T09:11:00Z

Python的背后有着庞大的开源社区支持，但是有一个缺点就是每个包的质量都参差不齐，如果我们在工作服务器上去测试安装每个包，就会造成整个的服务器形成庞大复杂的第三方包依赖。

virtualenv就是为了解决这个问题而生，他可以在我们的目录上生成若干个独立的虚拟环境，这些虚拟环境和正式环境一样。

安装virtualenv非常简单：

首先安装virtualenv：

然后我们就可以创建一个虚拟的环境了：

mytest就是我们所创建的虚拟环境目录了，我们可以发现，该目录中已经安装了和我们本机相同的python版本：

我们接下来需要激活这个虚拟环境：

我们就可以看到在命令行的前面已经加上了“mytest”，这个时候我们看看python所指向的路径：

OK ，这个时候我们就可以在这个虚拟环境中安装我们所需要的包了：

本文链接

《浪潮之巅》读书笔记汇总

2011-11-10T09:51:00Z

其实我是没有做读书笔记的习惯的，但是这本书只是借来看的，而且这种杂谈性的书，也比较容易扯开去，就随便写了一些东西，大多是自己的一些乱七八糟的想法。现在给汇总一下发出来把。。

1. 第一章

AT&T的兴起感谢于美国的反垄断法不断地强迫公司做着技术革新，帮助公司修枝剪叶以删除掉那些无用的业务，而衰败同样是由于反垄断法使公司不得不做着不理智的拆分从而使一个巨型帝国迅速的滑落。

当一个公司到后期被投行以及他人所大量持股，而创始人逐渐丧失公司的决策权时，公司就必将不在有着理智的长远的发展眼光，而越来越侧重短线投资和大量套现，从而使公司走向灭亡。

2. 第二章

从IBM看腾讯，IBM的成功之道在于保守，他不会盲目地对技术做大步的革新，因为任何一个失败都可能会影响到公司的股价，发展，战略等。所以很多大公司，比如IBM该做的不是盲目的创新，而是在其他公司创新后做出快速反映即使跟进。
而小公司，比如曾经的苹果，一直没有被IBM所击败，而现在太多的中国公司纷纷职责腾讯在抄袭，是因为苹果公司不是满足于当前的用户群体，而是即使地把握到用户的更大的需求和动态，从而持续创新，用反映速度来摆脱大公司的纠缠，然后让自己步入一个灵活变动的大公司的行列。
另外一点让我感触最深的是，IBM在金融危机前后，并没有受到特别大的打击，与他的公司定位“服务型公司”是密切相关的。所以我对XaaS这种概念炒作一直嗤之以鼻，却很赞成“软件即服务”这种理念，在我看来，无论是行业软件，还是互联网，都是一种变相的服务行业，只有遵循了这一点，才能让一个公司，或者一个网站一直立于不败之地。
然后，多说一句，豆瓣的改版，显然不是以服务为核心导向的，所以我TM也想注销了。

3. 第三章
水果公司的成功在于始终把任何一个产品做到完美，做到极致。他们和大多数互联网公司不一样，很多互联网为了扩大用户群体，一直信仰的一点是，我们要把用户当成傻子去看待，但是水果公司是把每个他的用户都当成艺术家，然后让这部分人再带动更多的人.....其实也不失一个好战略。
此外，很多PM在苹果兴起后，在做很多产品时都多了一个冠冕堂皇的理由，“用户不知道自己要什么”，需要我们来引领，可是不要忘记：
1. 苹果本身是第一个创造出"Windows"的，这本就为他们积累了不少的用户口碑
2. 苹果所说的不知道用户要什么，只是说“用户想象不到原来还有如此美妙的展现方式”，而并非“用户不知道自己想要他已知的A还是B”

4. 第四章

1. 摩尔定律是有实效期的，摩尔原本认为实效期是10年，可是只今已经过去了近50年，随着技术的发展遇到瓶颈，集成度不可能再像原来一样指数型的提高，我们目前能期待的只是纳米技术的飞速发展来让整个计算机世界发生一个质的飞跃，而如今，摩尔定律的失效只能让我们越来越多地寄望于多核程序设计了。
2. 反摩尔定律：一个IT公司如果今天和18个月前卖出同样多的，同样的产品，那么他的营业额就要降一半。
这个翻译成反摩尔定律好奇怪....其实这个应该说是摩尔定律的一个推论更合适一些。于是这就强迫着IT公司进行技术革新.....

5. 第五章
在PC时代，Intel的统治地位无须多说，他彻底击垮了Moto，然后为了反垄断留下了一个不足以成为竞争对手的AMD。
但是Intel已经占据了PC市场的之后，从外界看来却有些忽略了移动端的市场，所以未来若干年的发展，如果不及时凭借自己的规模口碑和影响力去抢占这一块，前景堪忧...

6. 第六章
MSRA是我一直的梦想，所以我把所有的用户名后都加上了ms的后缀，对微软的历史已经再熟悉不过了。
从微软利用MS-DOS起家，到雇佣阿尔钦和卡特勒研发Windows(《观止》)，再到之后的x-box。一直关注着C#的我，更是深刻体会到.NET的强大和微软一统天下的野心。
只是微软在互联网的表现一直让人失望，无论是Bing，还是微软之前力推的Silverlight，在我看来，微软不是由于过于庞大而丧失灵活性，当然，这也是其中的一个原因。而是微软的基因中从来都缺少创新的灵魂，一直都是靠着Windows打天下，而再互联网行业，微软便没有了Windows的优势可利用，而追在别人后面，只能说是别人的市场已经成熟了，微软就很难侵占了。
在这个问题上，我认为吴军博士的分析可能还是有些不到位把......


7. 第八章
Yahoo最大的贡献应该在于他开创了一种免费，开源的互联网商业模式。而Yahoo也相当于一手创造了当年的互联网泡沫。
Yahoo最大的失败一点：
Yahoo在我看来一直都是一个人力密集型公司，而不是一个技术型公司，因为他的排名，乃至聚类都是人来完成。而在互联网行业，这样的模式是很容易被复制的。

但是这也怪不得Yahoo，因为Yahoo一直都是以一个传统媒体的思路来经营互联网，甚至包括之后的几位CEO，这就决定了在互联网的浪潮中，对Google战斗的完败。

8. 第九章，第十章
惠普和Moto一样，都是属于一个以硬件为主要盈利模式的公司，也包括如今的Dell。
但是从目前来看，随着硬件的价格越来越低，也包括无数的“中国制造”的冲击，硬件的利润已经越来越小。
惠普越来越多的市场都是投在了打印机上，丰富打印机的生产线，但是从长远角度来看这个仍然很难维持惠普一个大公司的兴起。而Moto作为无线通信的主要生产商，也已经成为了没落的贵族。
如今看来，如果这两个公司，甚至包括其他的硬件厂商，如果不及时地扩展业务模式，或者是与软件，与服务相结合，必然衰败甚至倒闭。

9. 第十一章
创业几乎是每个IT人的梦想，至少我身边的人都是这样，没有人甘心为人打工一辈子。
但是每当他们跟我说出想法时，我给他们的打击总是多于鼓励和支持，他们给我的理由无外乎某某人做了一个什么什么样的东西，然后这个人就成功了。我往往都会说，那是因为剩下99%没有成功的人你不知道而已。
书上给出了一个小公司想成功的理由： 1. 创始人不仅仅是梦想家，而要是一个实干家。 2. 仅仅有一个好的团队和技术远远不够，更重要的是商业头脑，以及可以找到盈利的商业模型。此外除了领导力，判断力之外，也许更重要的是运气了。我读过茅侃侃的关于创业的一本书，虽然书写的不怎么样，但是有的观点我还是很认同，创业的路是异常坚信的，很多人都看到了成功的结果，而忽略了成功的过程。硅谷每天上千的公司成立，但是同时也有上千的公司关门，血本无归。
此外，我身边的好多人除了创业之外，更多的就是和我说，你看谁谁谁每个月多少多少钱，你看看哪个哪个方向（比如移动开发）每个月多少多少钱，你看某某行业（最多的是金融和销售）每个月多少多少钱。 
我总是说的观点有几个，每个公司都不是傻子（当然我现在越来越感觉傻子还真不少），能给他比你多的工资，必然有他的辛劳之处，太多人看到百度的人工资翻着番的数，可是我更多看到的是百度人日益稀少的头发和大量的情侣分手数。
某个方向的工资很高，无外乎几个可能，第一，这个方向门槛很高，第二，这个方向是个泡沫。比如web开发，世纪初随便会写个html都能拿到高额的年薪，而现在web开发却成为了低端的代名词，以至于前公司大家见面都会说，“靠，你丫的是套页面的把？”“滚！你们去安全家都是套页面的！” 。 而这种现状完全可以应用于当今的移动（Android和IOS开发），泡沫而已，何必耗费心思呢。
某个行业工资很高，我能说的只是，那是你看到出来炫耀的都是成功人士，殊不知那些每个月只有几百块底薪的销售，和“四大”公司里每天累得快吐血的白领人士呢.......
硅谷的“硅”——半导体制造业已经随着时代的发展越来越少，取而代之的是生物科技和高新技术，而这些终有一天也会随着时代而消亡，而硅谷之所以长盛不衰，留下的，只有他的创新精神，而这个，正是中国没有硅谷的最大原因之所在把。

10. 第十八章
如果说微软一直是我的梦想的话，那么Google从来都是我可望不可及的一个神圣的地方。
1. Google至于Yahoo等公司固然有技术上的巨大优势，而从财政上讲，他的成功很大一部分是因为他们没有着急上市，也在融资时注意自己手中的股份，避免被过度稀释，这样就保证了公司创始人的决策权，而不是受华尔街影响。
2. Google和微软之争好多人评价说是技术的胜利，或者决策的胜利等等，可是在我看来，更大因素还是因为微软没找到一个合理的办法把操作系统和互联网捆绑这个关键因素，否则Google的失败也是无可避免。
3. Google的人才政策，Google信仰个人英雄主义。那天吃饭我问女朋友说，你说历史是人民创造的，还是英雄创造的。成绩优异的她果不其然地说人民。可是我却对于尖端行业的“团队主义”一直抱有质疑，举个最粗俗的例子，一万个女人生一个孩子一样需要十个月。那么说如果是装配行业，外包行业，10000个人的产量大于10个人没问题。可是对于一些技术性行业来说，我却从来都对“三个臭皮匠，赛过诸葛亮”的说法嗤之以鼻。在我看来，与其让我和三个“臭皮匠”工作，还不如让我一个人安安心心地工作来得更合适，所以我喜欢精英主义的公司，而对某些大规模不分青红皂白扩招的公司躲得远远的，宁缺勿滥是我一向的格言。所以每次和别人聊天谈起某某公司多少多少人的时候，我都说，三个人足够了把......
4. 关于研究部门。我一直觉得把研究部门和开发部门分开是不太合理的，比如传说中的MSRA不写代码，每天负责的只是研究，结果导致的是很难让研究部门真正开发出真正的产品，如果我组建一个公司，研究部门可以研究某一个具体方向，但是研究区间不得超过一个月，而一个月后他需要的是，进行研究报告，然后如果通过接下来需要申请一个工程团队将这个研究迅速转变成产品，哪怕是实验室项目.....这样才能不会让研究成为单纯的研究。
5. “杀鸡也用牛刀”，这个在我看来是一把双刃剑。一方面，这样会损耗掉大量的人才，也会让大量的人才逐渐趋于平庸，而且牛刀杀鸡是不是更好还有待考证。另外，这样非常不利于控制公司的成本。
6. Android。Android无非是近年来智能手机的一个创举，超过多年的老品牌Symbian，更是将IOS和WP远远甩在身后，但是在我看来，如果Android不解决以下几个问题，必然成为迅速陨落的流星。
A. 版本更新过快的问题。十天的时间，九天都在讨论要不要刷系统明显是个很不成熟的情况。
B. 亟需一个行业约定标准。这个是Android和IOS最大的差距之所在。Google一向的做事风格就是联合各大厂商然后来狙击一个巨头，以前是联合电脑制作商，互联网公司来狙击微软，今天是联合各大手机制造商来狙击Apple，但是这一套明显在手机操作系统时代行不通。各大手机都有着不同的硬件标准，这样每个公司都需要对Android做一个定制，而各大n公司的水平更是参差不平，这就导致了整个系统的混乱，尤其是对手机应用开发者更是痛苦，缺乏了应用的智能手机更是鸡肋了。
C. 效率问题。太多Android粉都辩解着Android的手机不慢，可是从技术的角度说，Android这种基于虚拟机的效率低于IOS是毋容置疑的，而打开性能监视器更是可以看到GC回收个没完没了.....
7. Google的商业竞争这句话我最喜欢，进攻就是最好的防守，不要怕失败，努力地去向那些所谓的权威质疑把！

11. 第二十章
1. 在我看来，web2.0应该是无干涉的，公司只需要打造一个平台任由用户自由发挥，从这个意义来说，由于天朝独有的审核制度，使国内不存在真正意义上的web2.0。作者在书中给出了这样几个web2.0必备的特征。
A. 必须有平台可以接受并管理用户的内容，并且这些内容是网站的主体。
B. 这个必须是个平台，允许用户开发自己的程序。
C. 交互性。交互通信和信息共享。
D. 非竞争性和自足性。
2. 关于web2.0的盈利。我一直对web2.0不足够看好，如果说web1.0是单对多，web2.0是多对多，那我更愿意相信web3.0是一种基于语义，基于上下文等等的完全个性化定制，那么如果从这个意义上来说，web2.0只是web3.0的一个过度，就如Vista一样，只是一个过度产品而已。
评价一个网站，一个公司的好坏只有一个标准，是否盈利，财务报表是否足够漂亮，那么web2.0明显是雷声大雨点小的，我曾经帮别人修改一个商业计划书里写，这个网站我只能制定一个最终的目标，但是不能确定其产品表现形式，我更不会为了做社区而去做社区，因为在我看来，包括Facebook和Twitter在内，都是一个失败的产品，因为他们直到现在都没有找到足够好的盈利模式，尤其是Twitter。
曾经有人问我新浪微博怎么样，我的回答是，微博这样的产品代表了当今社会的浮躁，在宣扬一种快餐文化，但是微博直到现在都没有办法找到一个成熟的盈利模式，唯一可能进行的也不过是一些热门账号的软广告，以及广告精准投放而已，而我们知道，靠广告生存的公司的空间越来越小。 所以我对国内各大互联网公司盲目追随Twitter, 投资微博感觉非常不理解，更对点点这类还宣扬“轻微博”的网站感到好笑，由此也是对开复老师创新工厂的投资眼光表示质疑。 而新浪微博的前景，我更愿意相信这只是新浪想用来拆分上市然后大佬一笔的中间产品而已。
如果说web2.0的盈利渠道，只能个性化，再个性化，然后通过个性化进一步做广告精准投放以及商品推荐，以及打造一个更加开放的平台，然后收取中间费用（在这一点上人人做的应该是很好的）。但是这个已经是偏向于web3.0的概念了。
此外，好多人跟我聊天时候说创业的点子，我说，从前，我们做网站是努力把线下生活搬到互联网上，让人们能在网上真实模拟日常生活，造成这个的原因是互联网行业的不成熟。而随着互联网的日益成熟，我们该想的是，如何把线上生活搬到线下，打造这样一个实体店，让用户在日常生活中像在网上一样。如此往复循环，线上线下彼此促进，才是未来互联网的趋势。
曾经的年代线下依赖于线上的广告，那么在下一个年代，让线上的网站基于线下的实体体验，是不是也可以看成未来web3.0乃至web4.0的一个卖点所在呢....


最后，顺路给自己豆瓣打个广告把，http://www.douban.com/people/lovekym/。

本文链接

R对MongoDB的性能测试——RMongo

2011-09-26T03:35:00Z

在九月初的时候，RMongoDB正式发布了修订版本，这也就意味着，从事数值计算的语言也可以于Nosql产品相接轨了，但是鉴于我身边并没有公司真的在使用R和MongoDB的结合，所以在效率问题上，我们也不敢掉以轻心，所以就做了一个这样的测试。

测试环境是8核，64位机。用于测试的库是一个未经Sharding，大概30G左右的Collection。用于存储用户的喜好信息，标签信息等数据。

1 library(rmongodb)

2
3 mongo <- mongo.create()
4
5 if(mongo.is.connected(mongo))
6 {
7     ns <- 'rivendell.user'
8     print('查询一个没有索引的字段，查询一条')
9     print(system.time(p <- mongo.find.one(mongo,ns,list(Friend=600))))
10     print('查询一个没有索引的字段，多条,without buffer')
11     print(system.time(p <- mongo.find(mongo,ns,list(Friend=600))))
12     print('看看是否有缓存策略')
13     print(system.time(p <- mongo.find(mongo,ns,list(Friend=600))))
14
15     print('查询一个没有索引的字段，多条,has buffer')
16     buf <- mongo.bson.buffer.create()
17     mongo.bson.buffer.append(buf,'Friend',600L)
18     query <- mongo.bson.from.buffer(buf)
19     print(system.time(p <- mongo.find(mongo,ns,query)))
20     print('看看是否有缓存策略')
21     buf <- mongo.bson.buffer.create()
22     mongo.bson.buffer.append(buf,'Friend',600L)
23     query <- mongo.bson.from.buffer(buf)
24     print(system.time(p <- mongo.find(mongo,ns,query)))
25
26     print('大于的查询，查询一条记录')
27     print(system.time(p <- mongo.find.one(mongo,ns,list(Friend=list('$gt'=600L)))))
28     print('大于的记录，查询多条记录')
29     print(system.time(cursor <- mongo.find(mongo,ns,list(Friend=list('$gt'=600L)))))
30     mongo.cursor.destroy(cursor)
31
32     print('查询一条有索引的记录')
33     print(system.time(p <- mongo.find.one(mongo,ns,list('_id'=3831809L))))
34     print('查询索引的记录')
35     print(system.time(p <- mongo.find(mongo,ns,list('_id'=3831809L))))
36
37     print('插入一条记录')
38     buf <- mongo.bson.buffer.create()
39     mongo.bson.buffer.append(buf,'name',"huangxin")
40     mongo.bson.buffer.append(buf,'age',22L)
41     p <- mongo.bson.from.buffer(buf)
42     print(system.time(mongo.insert(mongo,ns,p)))
43
44     print('找到刚刚插入的记录')
45     print(system.time(p <- mongo.find.one(mongo,ns,list('name'='huangxin'))))
46     if(!is.null(p))
47     {
48         print('success')
49     }
50
51     print('批量插入')
52
53     buf <- mongo.bson.buffer.create()
54     mongo.bson.buffer.append(buf,'name','huangxin')
55     mongo.bson.buffer.append(buf,'age',22L)
56     p1 <- mongo.bson.from.buffer(buf)
57
58     buf <- mongo.bson.buffer.create()
59     mongo.bson.buffer.append(buf,'name','huangxin')
60     mongo.bson.buffer.append(buf,'age',22L)
61     p2 <- mongo.bson.from.buffer(buf)
62
63     buf <- mongo.bson.buffer.create()
64     mongo.bson.buffer.append(buf,'name','huangxin')
65     mongo.bson.buffer.append(buf,'age',22L)
66     p3 <- mongo.bson.from.buffer(buf)
67
68     print(system.time(mongo.insert.batch(mongo,ns,list(p1,p2,p3))))
69
70     print('找到刚刚批量插入的记录')
71     print(system.time(cursor <- mongo.find(mongo,ns,list('name'='huangxin'))))
72
73     i <- 0
74     while(mongo.cursor.next(cursor))
75     {
76         i <- i + 1
77     }
78     print(i)
79
80     print('批量更新')
81     print(system.time(mongo.update(mongo,ns,list(name='huangxin'),list('name'= 'kym'))))
82
83     print('查看更新是否成功')
84     print(system.time(p <- mongo.find.one(mongo,ns,list('name'='kym'))))
85     if(!is.null(p))
86     {
87         print('success')
88     }
89
90     print('批量删除')
91     print(system.time(mongo.remove(mongo,ns,list(name='kym'))))
92 }
93
94     print(system.time(p <- mongo.find.one(mongo,ns,list('name'='kym'))))
95     if(!is.null(p))
96     {
97         print('success')
98     }

[1] "查询一个没有索引的字段，查询一条"
user system elapsed
0.000 0.000 0.115
[1] "查询一个没有索引的字段，多条,without buffer"
user system elapsed
0.000 0.000 32.513
[1] "看看是否有缓存策略"
user system elapsed
0.000 0.000 32.528
[1] "查询一个没有索引的字段，多条,has buffer"
user system elapsed
0.000 0.000 32.685
[1] "看看是否有缓存策略"
user system elapsed
0.000 0.000 33.172
[1] "大于的查询，查询一条记录"
user system elapsed
0.000 0.000 0.001
[1] "大于的记录，查询多条记录"
user system elapsed
0.000 0.000 0.014
[1] "查询一条有索引的记录"
user system elapsed
0 0 0
[1] "查询索引的记录"
user system elapsed
0 0 0
[1] "插入一条记录"
user system elapsed
0 0 0
[1] "找到刚刚插入的记录"
user system elapsed
0.00 0.00 35.42
[1] "success"
[1] "批量插入"
user system elapsed
0 0 0
[1] "找到刚刚批量插入的记录"
user system elapsed
0.004 0.000 35.934
[1] 7
[1] "批量更新"
user system elapsed
0.000 0.004 0.000
[1] "查看更新是否成功"
user system elapsed
0.000 0.000 67.773
[1] "success"
[1] "批量删除"
user system elapsed
0 0 0
user system elapsed
0.000 0.000 91.396

之前我一直不太理解的就是为什么大于和等于，差距会差这么多。后来当我在用Python去做同样的测试的时候发现，Python两者的效率其实是相同的，所以这就证明了这个不是MongoDB的问题，而我不相信在数据库层面，一个语言的Driver会有这么大的差别。

后来我发现了Python和R的关于MongoDB Driver的一个区别。首先，Python find的时候，不是将查询到的数据集整体拉回，而是返回一个cursor，也就是说，他在执行find命令的时候并不消耗时间，而如果加上while cursor.next()的时候，才会真正地去执行这个查询。

但是R不一样，R会首先考虑数据集的大小（或者其他情况），然后视情况而定地返回cursor还是将整个数据集整体拉回。如果我们将之前的while mongo.cursor.next(cursor)也算在计算时间的时候，那么我们就会发现，其实大于和等于的操作，效率相差并不明显了.......

在实际操作中，批量插入是一个非常常见的应用场景，但是对于R或者Matlab语言来说，循环的效率一直是硬伤，所以接下来，我会尝试着用apply系列来解决R语言的循环问题，如果实际操作发现可行，那么接下来使用mutilab等R的并行计算库来充分发挥多核的效率也值得尝试了！

本文链接

Euler第三题

2011-07-31T15:55:00Z

帮同学做道题....其实真没什么好的做法....

1 def getList(n):
2     result = []
3     count = 3
4     max = n
5     while max%2 == 0:
6         max /= 2
7         result.append(2)
8
9     while count <= max:
10         if max%count == 0:
11             result.append(count)
12             max /= count
13         else:
14             count += 2
15     return result
16

17 print getList(600851475143)

本文链接

谈谈开放平台

2011-05-31T18:56:00Z

不知道从什么时候起，开放平台越来越多地走近了我们的视线，从最初的开心开放平台，人人开放平台，新浪开放平台，再到即将发布的飞信开放平台，腾讯Q+开放平台，似乎在这么一瞬间，开放平台成了各个互联网的一个标配。如果你没有这么一个开放平台，你都不好意思说我是一个互联网公司。

那么这里，我们就来谈谈这个所谓的开放平台。

1. 什么是开放平台

首先，让我们来了解下什么是开放平台。

也许对于程序员来说，有一个概念一定不陌生，Open API，对，就是开放的应用程序接口。那么开放平台呢？我们不要把他想的那么神秘，简单来说就是Open API + Platform，那么什么是Platform，简单来说，就是一个系统，让别的系统可以接进来。

那让我来总结一下什么是开放平台？我个人认为就是一个软件系统（互联网）开放自己内部的API，允许外部的程序通过调用自己的API接入自己的系统，从而来靠第三方的资源来增加自己软件系统的功能。

那么这么一说也许就很简单了？开放平台这个概念其实很早就有了？是什么呢？操作系统！开放自己的API，然后为用户提供各种各样的功能。我们今天所说的开放平台，其实不过类似于操作系统的内核，而第三方的系统类似于其他的应用程序开发商，只此而已。

2. 开放平台和内容聚合

其实在之前，我一直没有弄清楚开放平台和内容聚合一直有什么区别？

最初我问同事，开放台到底是个什么东西？他能为我带来什么？

同事告诉我，你有腾讯微博，新浪微博，饭否，Twitter，那么你只需要登陆开放平台，就可以看到这四个微博的最新动态了！

我说，那么，这和市面上已有的微博聚合工具有什么区别呢？不就是验证一下，然后调用几个API而已么？

然后同事也说不出个所以然来了。

再到之后我看过了开放平台的一些资料和定义，大致明白了他们之间的区别。从技术上说，开放平台是推的过程，是从内容产生处向开放平台来推送。而聚合是一个拉的过程，是从内容聚合软件（网站）去内容产生处来抓取。

那为什么同事没办法说出个所以然来，是因为，站在用户的角度来说，内容聚合和开放平台并无本质区别，对他们来说，都是一个聚合的过程。那么我们抛开技术，开放平台和聚合软件的差别究竟在哪儿？在于第三方应用厂商的利益。

3. 开放平台的商业价值

越来越多的互联网公司都逐渐地走向了开放平台这一条路。网易，百度，人人，腾讯，飞信，他们为什么要开放？他们都是商业公司，相信每个人都不会相信他们所说的希望来通过自己的开放来改变中国的互联网这样的鬼话。做任何事情，无外乎就一个目的，盈利！

网易，新浪已经不满足于传统的Web1.0所带来的广告收益。而人人，开心也深刻地理解SNS本身其实是没有盈利价值的，而他们能做的只是通过SNS这个平台保证用户粘度，然后向其他的方向去发展赚钱渠道，于是开放平台应运而生。

如果人人网变成一个收费的SNS网站，你还会去么？我想不会，这样人人网必然会失去很多用户，无论是新用户还是老用户。那么既然不能从用户这来赚钱，好把！那我就从第三方厂商处赚钱，利用我的平台为你带来流量，然后我来收取分红。

其实这种商业模式并不新鲜，就是一个高级的广告位罢了。只不过最初的广告是图片，然后接下来换成了会动的Flash，再到今天换成了能和用户对话的应用程序。

4. 开放平台仍然是互联网

无论我们给开放平台起怎样一个冠冕堂皇的词，我们都必须要承认一个事实，开放平台还是一个互联网，是一个上面挂着各种各样高级广告的互联网。既然是互联网，那么有一个核心就永远都不会改变——“用户至上”。

做互联网企业，不说这么大，做一个网站，永远需要想到的第一点都是，我们能给用户带来什么？这一点不想清楚，我们就不要动手。某产品经理的一句话对我影响很大，做一个网站，产品形态可以不断调整，但是最终目标一定不能变。其实这句话再延伸一下，一个公司产品形态可以不断改变，而战略形态必须要明确，什么是战略形态，就是给用户带来的最终价值一定不能改变。

那么我们就站在用户的角度来考虑这个问题？用户为什么来我们费尽心思所搭建的开放平台？

如果如之前同事所说，为了在同一个地方看到不同地方的微博，那我们不用费这么大的力气搭建开放平台，花上2人天做个内容聚合软件就可以满足用户的需求！

如果是为了让用户来你这玩游戏？那更没必要了……用户干吗费这么大的劲儿先登陆你的网站，然后再添加应用，然后看着一个IFrame在屏幕上闪来闪去？我直接登陆那个官网去玩游戏好不好！

还有什么？还有什么？反正我是想不到了！你能想到么？我也可以找到一个取代的产品来代替开放平台！为什么这样？还是之前我说的，开放平台就是高级广告位，对用户来说没有丝毫的价值！

5. 开放平台健康的发展模式

我们都不能免俗，没有公司是为了服务世界而不考虑赚钱的，那么对于当前的SNS站点来说，说更宽一点来说，对于社会化网络媒体来说，开放平台是个很好的盈利途径，甚至说，任何想赚钱的网站都会有“开放平台”这么个东西。但是何时开放，这才是问题的关键。

我们来考虑这样几个问题：

A. 第三方厂商为什么要用额外的人力来接入开放平台？是因为他们希望能够利用开放平台的影响力为他们带来流量，带来利益。为什么好多游戏厂商只做Windows下的软件，而不会去做Linux下的？道理很简单，因为Windows下的用户多，这样的投入回报比是值得的。那么道理一样，如果你的开放平台本身就没有用户，那么我们自然就没有必要去为这个开放平台来浪费我的人力资源。

B. 用户为何来开放平台？这个问题又回到了上一节，不多做解释。

问题到底出在哪？这么一来，开放平台没用户，没用户就没接入，没接入这个开放平台就真的只剩一个平台了。这个就是我在全文想表达的一个中心，真正的开放平台，不是孤立存在的，而应该是作为一个成熟软件系统的盈利附属品而存在。

用户为什么来开放平台？因为用户不是想来开放平台，用户是想来新浪微博，是想来腾讯微博，是想来百度搜索，只是既然都来了，旁边还有应用，有游戏，我就顺带着玩了！用户不是为了广告而来到某一个网站，而是因为我喜欢这个网站的内容，而这个网站上有某个广告正好也是我感兴趣的，那么我就顺带着点一下，道理是相同的。

6. 开放平台何时开

一个打算长期发展的网站什么时候挂广告？建站之初么？不是。这个时候第一，广告商不会在你这打广告；第二，用户会因为满屏的广告而对网站产生方案。开放平台也是一样。

既然在前一节已经说过，开放平台只是附属品，那么附属品存在的前提条件是，主要的网站已经做的很好了，用户有很好的忠诚度了，这个时候，嗯，该盈利了！当然，开放平台不会像广告一样惹人厌烦，但是一个公司的人力成本是有限的，何必不把有限的精力放在更应该去做的事儿上去呢？

在这个开放成风的年代，那些呼吁开放的高层领导是不是盲目的跟风意识呢？那些跟着叫好的中层领导是不是想要通过这个开放平台来给自己的人生增加一次跳槽的光辉履历呢？

在这个开放成风的年代，除了腾讯，人人等一些有着扎实用户基础的网站，其余的开放平台是不是也会随着热潮的过去而被人渐渐淡忘，成了一个从未被应用过的产品呢？

7. 开放平台的未来

个性化，已经成为Web2.0中后期最重要的概念了，个性化推荐，个性化布局，个性化服务，把以人为本的精神发挥到了极致。

那么一个成熟的开放平台也必然会走向这样的道路，对不同的内容源产生的Feed流做进一步的过滤，为用户推荐个性化的内容。看到这里也许有人会说，我们的开放平台也支持这个功能，我只能说，这是一个个性化的广告，挖掘用户的喜好，给用户推荐他可能感兴趣的广告而已，但是这仍然是个广告。

再往后，第三方的应用厂商不再需要自己部署服务器，不再需要考虑性能问题，分布式问题，而都是将这些接入到开放平台上，而这一天，开放平台这个概念就显得太小了，我们还是说这是一个“云操作系统”好了。

本文链接

参数对象究竟要不要？

2011-04-26T03:18:00Z

首先，这篇文章只是我临时写的，之前没有给文章个整体思路，所以文章可能思路会显得有些乱，连我到现在都不知道我要写到什么时候终止。

这篇文章的产生是因为看过了横刀天笑的这篇文章，在这篇文章中，作者给出了一个很好的关于代码重构的步骤，以及我们要如何重构代码，提高抽象层次，但是我对其中一点，是对Martin Fowler在《重构》一书中所提出的关于参数对象的观点一直抱有质疑。先别急着反对，也别急着回复，先继续向下看。

1. 先想想Python , F#之类的函数式语言

让我们先想想Python , F#之类的函数式语言（让我们暂时先把Python称之为函数式语言吧），这些函数式语言，也包括C#(从4.0开始)，都有一个概念叫做Tuple，我们看看Python如何来声明一个Tuple。

1 t = ("kym",22,"developer")

不知道您看到这段代码是不是感到眼熟呢？我们来写一个方法，就是横刀天笑在文章中用到的一段近似的代码：

1 private bool Validate(string userName,int age,string email)
2 {
3 //....Validate
4 return true;
5 }

恩，那我们怎么来调用这个方法：

1 public static void Main(string[] args)
2 {
3     bool isValid = Validate("kym",22,"developer");
4     if(isValid)
5         Console.WriteLine("Success");
6     else
7         Console.WriteLine("Failure");
8 }

其实方法的参数调用是不是和Tuple很类似呢？想想我们把方法改成这样的形式：

1 def Validate(userInfo):
2     bool nameIsValid = userInfo[0]==''
3     // and so on
4     return isValid

然后我们就可以把最之前的Tuple传入了：

1 if __name__ == '__main__':
2 print Validate(t)

相信这个时候，也许很多人知道我想表达什么概念了。

2. Tuple and Class

是的，其实我想表达的就是方法参数从本质上来说就一个Tuple而已，那么接下来让我们想想Tuple和Class的区别所在吧？

从语法分类上来讲，Tuple我们把他叫做序列，和List被划分到同一分类下。而Class即使在那些弱面向对象（让我们暂且这么叫吧），比如Javascript来说，也充其量与Dictionary , Hashtable划分到同一类下，完全不同。

一个Tuple，如果不考虑思维意义的话，我们也完全可以将之用List取代。

t = ('kym',22,'developer') 和 l = ['kym',22,'developer'] 在使用上是没有什么区别的。而同样，我们将之封装成一个User对象也无可厚非：

1 class User(Object):
2    def __init__(name,age,work):
3        self.name = name
4        self.age = age
5        self.work = work

但是从思维意义上来说，这几者是完全不同的：

其实在C#之类的强类型语言来说表现的更明显，List<T>只能用来用来容纳同一类型的元素，换句话说，List<T>只能用来容纳同一种意义的元素，我们可以称之为兄弟元素。

而Tuple和Class的区别则取决于元素之间的关系如何，让我们想想单一职责原则(SRP), 一个类下应该只有一个能够引起他变化的原因，也就是说，这些元素高内聚的关系，我们才能够把他们塞到一起。而Tuple相对来说，则是更弱的内聚关系。

3. 要不要重构

看完了上面的内容，那就让我们想想，究竟要不要重构。或者说要不要参数对象究竟取决于什么？

我们首先，不要把方法参数当成方法参数，而要把他们当成一个Tuple，也就是说我们把要不要重构的问题转换成了是Tuple还是Class的问题。

那么Tuple还是Class取决于什么，不是取决于参数的个数，而是完全取决于参数之间的内聚关系。

4. 一些小引申

相信很多人都见过这样的代码：

1 public void Insert(string userName, string password, bool isValid)
2 {
3     //是否需要验证
4     if(isValid)
5     {
6         bool userNameValid = userName != '';
7         bool passwordValid = IsStrongPassword(password);
8         if(userNameValid && passwordValid)
9         {
10             this.StoreIntoDatabase(username,password);
11         }
12     }
13     else
14     {
15          this.StoreIntoDatabase(username,password);
16     }
17 }

先说这个参数是不是很长，如果你觉得还不够长，那么就把什么Address,Job之类通通塞进去吧！够长了吧！可是我们是不是应该把这些参数封装成一个参数对象？如果是？那么这个类要怎么写？

1 class UserArgsForValidation
2 {
3     string userName;
4     string password;
5     bool isValid;
6 }

这样真的就面向对象了么？明显不是，可是这个问题到底出在哪？是方法重载的过分滥用。

如果我没有记错，Martin Fowler在书中提到过这一点，如果在方法中出现了对参数的if判断或者switch等条件选择语句，那么就让我们把这个方法拆成InsertWithValid(string userName , string password)和InsertWithoutValid(string userName, string password)这两个方法吧。

所以，在大多数情况下，如果一个方法带有了很多的参数，其实在一般的意义上，这些参数一定是有一个相对高的内聚性，如果没有，诸如上面的情况，就先想想是不是该用用其他的重构原则，如果没有，那么就想想是Tuple还是Class，而不是这个参数有四个，还有八个。

其实有个很好的区分原则，记得在设计模式的圈子有这样一个说法，说如果你设计的类名带有了这个模式的名称，比如ProductFactory, AccessAdapter,那么你就是设计模式滥用了，当然这个说法有些极端。但是我们不妨也试试把这个原则迁移到方法重构上，如果你的类名上带有了Args这样的参数，那么你也是重构的滥用了。

本文链接

Haskell——模式匹配和Guard的区别

2011-03-21T17:34:00Z

sayMe :: (Integral a) => a -> String
sayMe 1 = "One"
sayMe 2 = "Two"
sayMe 3 = "Three"
sayMe 4 = "Four"
sayMe x = "Others"

sayMe :: (Integral a) => a -> String
sayMe x
    | x < 3 = "less than 3"
    | x == 3 = "equals with 3"
    | x > 3 = "larger than 3"

区别就在于一个对比的是对象，一个对比的是布尔值。

本文链接

由扩展方法引申出的编程思维

2011-03-16T22:45:00Z

1. Helper大爆炸

.NET Framework为我们提供了丰富的类库，但是这并不是万能地，在大部分的时间，我们都需要为我们的项目特殊定制我们的通用类库。

常常，我们都可以构造一个类，类里封装一些方法。但是对于很多时候，我们并没有办法提取出这样一个类，举一个小例子，我们在很多时候，需要把url给保存到数据库里，作为一个唯一标识，但是我们知道url所占空间很大，如果用url来建立索引的话是非常耗费空间，而且影响效率的，那么我们最常用的办法就是把url做一个Hash来作为索引的替代品。

这个时候，我们根本就没有办法说我们来怎么样提取一个类，然后在类里写这样一个方法，这个时候，我们通常就只能这样：

public static class HashHelper
{
    public static string GetHashCode(string s)
    {
        //GetHashCode........
        return String.Empty
    }
}

然后我们会这样使用：

public static void Main(string[] args)
{
    string url = "www.fandongxi.com"
    string sql = "insert into Test values('"+HashHelper.GetHashCode(url)+"')"
    //执行SQL
}

这里，只是一个例子，并不是说我们要这个样子拼接字符串。

很快，肯定又会出现一个情况，说，我们要保存网页的内容，但是网页的内容直接存储到数据库里太大了，那么我们就需要对网页文本做一个Base64的编码然后压缩。//之前这里些的是错的，被很多人挑了错误.....

那么，我们就又得继续写：

public static class Base64Helper
{
    public static string GetBase64Text(string text)
    {
        //Base64........
        return String.Empty
    }
}

接下来我们在使用的地方就又多出来一个Base64Helper。那么过几天，还会出现SHA1Helper , MD5Helper等等各种各样的Helper。

渐渐地，我们会不会发现，Helper的数量已经让我们难以忍受了呢？

2. 扩展方法的提出

接下来的事情，我们都知道了，在.NET Framework 3.5中，也就是在C#3.0中，引入了扩展方法这个概念。

那就让我们扩展方法来解决上面的难题。

各位现在一定知道，无论是做UrlHashCode，还是Base64压缩，还是SHA1加密，还是MD5加密，这些都是针对字符串，或者说是一段文本的处理，那么很自然地，我们就需要把这些全部写入String类的扩展方法中。

public static class ExtensionClass
{
    public static string GetHashCode(this string s)
    {
        //........
    }
    public static string GetBase64Text(this string text)
    {
        //.......
    }
}

public static void Main(string[] args)
{
    string url = "www.fandongxi.com"
    string sql = "insert into Test values('"+url.GetHashCode()+"')"
        //执行SQL
}

在这里，我不想剖析去读扩展方法的实现本质，这里我们只谈编程思维和扩展方法所带来的意义。

3. 扩展方法让C#更加面向对象

从面向对象的角度来看，世间万物皆为对象，所有属性，所有方法都是属于某一个对象的，那么再从这个角度看开去，本就不应该存在静态类，也不应该存在静态方法，所谓的静态，不过是面向对象语言对并不成熟的语法实现的一种屈从罢了。

我们要求Base64加密后的文本，其实是文本调用自身的一个方法，之所以我们在之前的方法中需要一个Base64Helper，而不能这样子"http://www.fandongxi.com%22.replace(%22com%22,%22cn/")直接调用，只是因为.NET Framework无法预计到我们所有的业务场景，所以把只能把最通用的方法封装到已有的类库中。

4. 从扩展方法向外谈一些

让我们从扩展方法逐渐地向外围来探讨一些关于编码规范，以及一些代码优雅的问题。我们先不妨假设我们并不存在“+”运算符，或者说，我们禁止在程序中使用+运算符，那么也就是说，我们需要对“+”这个操作来做一个简单的封装，那么我们常规意义上会怎么做？

public int Add(int a,int b)
{
return a+b;
}

public static void Main(string[] args)
{
int result = Add(3,4)
Console.WriteLine(result)
}

让我们来看这个函数，我们顺着代码的意思向下读，加，3，4。这明显是不符合我们常规的数学思维的，如果用了扩展方法之后，我们一定是应该这样来写。

public static class Extension
{
    public static int Add(this int a,int b)
    {
        return a+b;
    }
}

public static void Main(string[] args)
{
int a = 3;
a.Add(b)
}

可是这个"."运算符看上去还是那么有点别扭…..没办法，至少这样读上去让我们的代码顺畅了很多不是么？像写文章，说话一样写代码一直是我们程序员追求的最高境界，就像这样的代码总是好的。

Good：people.eat(food)

而不是Bad：Eat(people,food)

对把！

5. 前缀，中缀和后缀表达式

说到这，就不得不谈谈前缀，中缀和后缀表达式了。

学过数据结构的朋友们，一定都记得在数据结构中，有一道经典的习题，就是利用“栈”来实现前缀，中缀和后缀表达式的转换。在考试题中也经常会出现这样的习题。那现在让我们来复习一下，什么是前缀，中缀和后缀表达式。

前缀表达式就是不含括号的算术表达式，而且它是将运算符写在前面，操作数写在后面的表达式，也称为“波兰式”。

大名鼎鼎的Lisp就是前缀表达式的典型，让我们看一个最简单的小例子，还是那个经典的斐波那契数列：

(define (fib n)
(fib-iter 1 0 n))

(defile (fib-iter a b count)
    (if (= count 0)
        b
        (fib-iter (+ a b) a (- count 1))))

每次写Lisp的时候，都会被密密麻麻的括号所吓到，可是真的没什么太好的解决方案呢！

中缀表达式就很简单了，和我们常规所涉及到的代码是一样的，后缀也是一个道理，在此就不再一一赘述。鉴于后缀的应用不是很大，在此我们也只谈谈前缀和中缀的意义。

那么我们想想，为什么Lisp要采用这么蹩脚的前缀表达式语法呢？

记得在大二第一次学习C语言的时候，老师让我们写一个简单的计算器，当时每个同学都写出了+，-，*，/的操作，但是在当时大多数的我们都没有办法写出更为常用的混合运算，以及（）的操作，当时只有班上某鹤立鸡群的哥们写出了让我们当时完全无法看懂的代码。再直到大三学习数据结构，再反过来想他当时的代码，才恍然大悟。

废话说了一堆，那么其实前缀表达式最大的意义就是他更贴近计算机的思维，他只需要两种操作就能完成运算，就是入栈和出栈。让我们来看一个简单的小例子

3+(1-4)，首先这是一个中缀表达式，把他转换为前缀表达式就是+3 – 1 4，计算机会从右向左来扫描这个表达式，4入栈，1入栈，然后遇到 - ，1和4出栈，并且完成运算，(-3)入栈，3进栈，+入栈，(-3)和3出栈，完成运算。

也就是说，其实在计算机完成我们所编写的数学操作时，其实往往都是把我们的中缀表达式首先转换为前缀表达式，然后完成计算，而Lisp采用前缀表达式，则是省去了这一个步骤，从而提高解释器的效率。

那我们就来总结下前缀和中缀表达式的意义。

前缀表达式更加贴近计算机思维，方便计算。而中缀表达式更加贴近数学思维，容易被我们所理解。

那回顾下，我们之前写Add的代码，如果说我们去掉.运算符，而且方法不加括号，是否采用扩展方法，把C#的语法和Lisp的语法相结合，其实就成了这样的形式。

public int Add(int a,int b)
{
return a+b;
}

public static void Main(string[] args)
{
(set! result (Add a b))
}

public static class Extension
{
    public static int Add(this int a,int b)
    {
        return a+b;
    }
}

public static void Main(string[] args)
{
(set! result (a Add b))
}

还是后者更贴近我们的自然思维一些。

.NET Framework很强大，给我们提供了扩展方法这个概念，那么如果没有了扩展方法，其他语言给出了怎么样的解决方案呢？

那让我们来看看Haskell给出的方案。

5. 看看Haskell的方法

Haskell是一门函数式的语言，在FP大行其道的今天，Haskell这门久居深宫的语言也渐渐地浮出了水面。

废话不多说，我们只来看看Haskell是如何在没有扩展方法的情况下来解决语法和自然思维不相协调的问题的。

让我们先来编写一个简单的Haskell函数。

add x y = x + y

代码很简单，没什么值得多说，让我们来看看Haskell怎么调用。

这是我们传统的调用方式，可是Haskell为了更贴近我们的自然思维，为参数个数数量为2的方法提供了这样一个便捷的调用：

这就是Haskell为我们提供的“中缀表达式”的解决方案。

扩展方法很好，但是当我们的语言中没有扩展方法的时候，Haskell给我们提供了一个优秀的典范。

6. 语言和类库

说到这，我就想顺便谈谈关于语言扩展和类库扩展的问题。

在《Masterminds of Programmming》一书中，Python语言之父Guido在接受采访时，谈到PEP（Python增强处理）时，顺便说到了关于在编写编程语言时，如何来根据用户的意见来处理语言实现的问题。

他谈到：

如果某个用户提出一个新特性，它几乎不会成功。因为用户对实现没有全面的理解，他几乎不可能提出一个合理的新特性。

那么在我看来什么是用户？用户就是使用这门语言来完成工作任务的人，他们往往需要的都是增加一个新功能，换句话说，他们需要的仅仅是一个方法而已。

那么什么是增加语言特性，什么是增加类库方法，Guido也给出了比较合理的解释。

如果某个特性对于Web来说确实很棒，那么，对于加到语言中来说，就未必是优秀的特性了。如果它确实利于编写更短的函数，或者是有利于编写可维护更强的类，把它添加到语言中可能就是一件好事。

其实Guido的意思很简单，是否增加到语言中，关于在于这个特性是否是领域相关的，如果是领域相关的，也许它需要做的仅仅是扩展类库，无论是增加Python的类库，还是用C去扩展Python API，总之无需对语言做出改变。

那么对于C#来说，什么是类库的修改，什么是语言的修改，在我看来，每一个版本的修改都一定有着类库的修改，但是如果说到语言的修改，应该是仅仅当MSIL发生变动的时候，我们才可以说语言发生了修改。//仔细想了一下，这个观点有问题....但是我没找到更合适的语言来做比喻。也许应该说，只有当语法的编译规则发生改变的时候，我们才可以说语言发生了修改。

Python也是一样，增加了方法充其量是类库的修改，而仅仅是语言的解释过程都发生了修改才可以算得上是语言层面的修改，例如从Python 2.x到Python3.x的大版本变动。

7. 总结

在本文中，主要是从扩展方法说起，谈到我们该怎么样更好的编写更贴近自然语言的程序。

然后再到一些没有扩展方法语言给出的折衷实现。而对于Python，C等其他语言，我尚且没有找到合适的方法来解决问题。

如果各位有好的办法，尤其是对于Python，毕竟这是我的工作，希望各位补充给出解决方法。

谢谢。

本文链接

Python开发编码规范(转)

2011-03-16T21:42:00Z

这篇文档所给出的编码约定适用于在主要的Python发布版本中组成标准库的Python 代码，请查阅相关的关于在Python的C实现中C代码风格指南的描述。

这篇文档改编自Guido最初的《Python风格指南》一文，并从《Barry's style guide》中添加了部分内容。在有冲突的地方，Guide的风格规则应该是符合本PEP的意图(译注：指当有冲突时，应以Guido风格为准)。这篇PEP仍然尚未完成(实际上，它可能永远都不会完成)。

在这篇风格指导中的一致性是重要的。在一个项目内的一致性更重要。在一个模块或函数内的一致性最重要。但最重要的是：知道何时会不一致——有时只是没有实施风格指导。当出现疑惑时，运用你的最佳判断，看看别的例子，然后决定怎样看起来更好。并且要不耻下问！

打破一条既定规则的两个好理由：

(1) 当应用这个规则是将导致代码可读性下降，即便对某人来说，他已经习惯于按这条规则来阅读代码了。

(2) 为了和周围的代码保持一致而打破规则(也许是历史原因)，虽然这也是个清除其它混乱的好机会(真正的XP风格)。

代码的布局

缩进

使用Emacs的Python-mode的默认值：4个空格一个缩进层次。对于确实古老的代码，你不希望产生混乱，可以继续使用8空格的制表符(8-space tabs)。Emacs Python-mode自动发现文件中主要的缩进层次，依此设定缩进参数。

制表符还是空格

永远不要混用制表符和空格。最流行的Python缩进方式是仅使用空格，其次是仅使用制表符，混合着制表符和空格缩进的代码将被转换成仅使用空格。(在Emacs中，选中整个缓冲区，按ESC-x去除制表符。)调用Python命令行解释器时使用-t选项，可对代码中不合法得混合制表符和空格发出警告，使用-tt时警告将变成错误。这些选项是被高度推荐的。

对于新的项目，强烈推荐仅使用空格而不是制表符。许多编辑器拥有使之易于实现的功能(在Emacs中，确认indent-tabs-mode是nil)。

行的最大长度

周围仍然有许多设备被限制在每行80字符：而且，窗口限制在80个字符。使将多个窗口并排放置成为可能。在这些设备上使用默认的折叠方式看起来有点丑陋。因此，请将所有行限制在最大79字符(Emacs准确得将行限制为长80字符)，对顺序排放的大块文本(文档字符串或注释)，推荐将长度限制在72字符。

折叠长行的首选方法是使用Pyhon支持的圆括号，方括号和花括号内的行延续。如果需要，你可以在表达式周围增加一对额外的圆括号，但是有时使用反斜杠看起来更好，确认恰当得缩进了延续的行。

Emacs的Python-mode正确得完成了这些。一些例子：

#!Python

class Rectangle(Blob)：

def __init__(self，width，height，color='black'，emphasis=None，highlight=0)：

if width == 0 and height == 0 and \

color == 'red' and emphasis == 'strong' or \

highlight > 100：

raise ValueError， "sorry， you lose"

if width == 0 and height == 0 and (color == 'red' or

emphasis is None)：

raise ValueError，"I don't think so"

Blob.__init__(self，width，height，color，emphasis，highlight)

空行

用两行空行分割顶层函数和类的定义，类内方法的定义用单个空行分割，额外的空行可被用于(保守的)分割相关函数组成的群，在一组相关的单句中间可以省略空行。(例如：一组哑元素)。

当空行用于分割方法的定义时，在‘class’行和第一个方法定义之间也要有一个空行。在函数中使用空行时，请谨慎的用于表示一个逻辑段落。Python接受contol-L(即^L)换页符作为空格：Emacs(和一些打印工具)，视这个字符为页面分割符，因此在你的文件中，可以用他们来为相关片段分页。

编码

Python核心发布中的代码必须始终使用ASCII或Latin-1编码(又名 ISO-8859-1)，使用ASCII的文件不必有编码cookie，Latin-1仅当注释或文档字符串涉及作者名字需要Latin-1时才被使用：

另外使用\x转义字符是在字符串中包含非ASCII(non-ASCII)数据的首选方法。

作为PEP 263实现代码的测试套件的部分文件是个例外。

导入

通常应该在单独的行中导入(Imports)，例如：

No：import sys， os

Yes：import sys

import os

但是这样也是可以的：

from types import StringType， ListType

Imports 通常被放置在文件的顶部，仅在模块注释和文档字符串之后，在模块的全局变量和常量之前。Imports应该有顺序地成组安放：

1、标准库的导入(Imports )

2、相关的主包(major package)的导入(即，所有的email包在随后导入)

3、特定应用的导入(imports)

你应该在每组导入之间放置一个空行，对于内部包的导入是不推荐使用相对导入的，对所有导入都要使用包的绝对路径。

从一个包含类的模块中导入类时，通常可以写成这样：

from MyClass import MyClass

from foo.bar.YourClass import YourClass

如果这样写导致了本地名字冲突，那么就这样写

import MyClass

import foo.bar.YourClass

即使用"MyClass.MyClass"和"foo.bar.YourClass.YourClass"

表达式和语句中的空格

Guido不喜欢在以下地方出现空格：

紧挨着圆括号，方括号和花括号的，如："spam( ham[ 1 ]，{ eggs：2 } )"。要始终将它写成"spam(ham[1]，{eggs： 2})"。

紧贴在逗号，分号或冒号前的，如：

"if x == 4：print x，y：x，y = y，x"。要始终将它写成

"if x == 4：print x，y：x，y = y，x"。

紧贴着函数调用的参数列表前开式括号(open parenthesis )的，如"spam (1)"。要始终将它写成"spam(1)"。

紧贴在索引或切片，开始的开式括号前的，如：

"dict ['key'] = list [index]"。要始终将它写成"dict['key'] = list[index]"。

在赋值(或其它)运算符周围的用于和其它并排的一个以上的空格，如：

#!Python

x= 1

y= 2

long_variable = 3

要始终将它写成

#!Python

x = 1

y = 2

long_variable = 3

(不要对以上任意一条和他争论——Guido 养成这样的风格超过20年了。)

其它建议

始终在这些二元运算符两边放置一个空格：赋值(=)，比较(==，<，>，!=，<>，<=， >=，in，not in，is，is not)，布尔运算 (and，or，not)。

按你的看法在算术运算符周围插入空格。始终保持二元运算符两边空格的一致。

一些例子：

#!Python

i = i+1

submitted = submitted + 1

x = x*2 - 1

hypot2 = x*x + y*y

c = (a+b) * (a-b)

c = (a + b) * (a - b)

不要在用于指定关键字参数或默认参数值的'='号周围使用空格，例如：

#!Python

def complex(real， imag=0。0)：

return magic(r=real， i=imag)

不要将多条语句写在同一行上：

No： if foo == 'blah'：do_blah_thing()

Yes：if foo == 'blah'：

do_blah_thing()

No：do_one()：do_two()：do_three()

Yes： do_one()

do_two()

do_three()

注释

同代码不一致的注释比没注释更差。当代码修改时，始终优先更新注释!注释应该是完整的句子，如果注释是一个短语或句子，首字母应该大写，除非他是一个以小写字母开头的标识符(永远不要修改标识符的大小写)。

如果注释很短，最好省略末尾的句号。注释块通常由一个或多个由完整句子构成的段落组成，每个句子应该以句号结尾。你应该在句末，句号后使用两个空格，以便使Emacs的断行和填充工作协调一致。

用英语书写时，断词和空格是可用的。非英语国家的Python程序员：请用英语书写你的注释，除非你120%的确信这些代码不会被不懂你的语言的人阅读。

注释块

注释块通常应用于跟随着一些(或者全部)代码并和这些代码有着相同的缩进层次。注释块中每行以‘#’和一个空格开始(除非他是注释内的缩进文本)。注释块内的段落以仅含单个‘#’的行分割。注释块上下方最好有一空行包围(或上方两行下方一行，对一个新函数定义段的注释)。

行内注释

一个行内注释是和语句在同一行的注释，行内注释应该谨慎适用，行内注释应该至少用两个空格和语句分开，它们应该以'#'和单个空格开始。

x = x+1 # Increment x

如果语意是很明了的，那么行内注释是不必要的，事实上是应该被移除的。不要这样写：

x = x+1 # Increment x

x = x+1 # Compensate for border

但是有时，这样是有益的：

x = x+1 # Compensate for border

文档字符串

应该一直遵守编写好的文档字符串的约定PEP 257 [3]。为所有公共模块，函数，类和方法编写文档字符串。文档字符串对非公开的方法不是必要的，但你应该有一个描述这个方法做什么的注释。这个注释应该在"def"这行后。

PEP 257 描述了好的文档字符串的约定。一定注意，多行文档字符串结尾的"""应该单独成行，例如：

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first。

"""

对单行的文档字符串，结尾的"""在同一行也可以。

版本注记

如果你要将RCS或CVS的杂项(crud)包含在你的源文件中，按如下做。

#!Python

__version__ = "$Revision： 1。4 $"

# $Source： E：/cvsroot/Python_doc/pep8。txt，v $

这个行应该包含在模块的文档字符串之后，所有代码之前，上下用一个空行分割。

命名约定

Python库的命名约定有点混乱，所以我们将永远不能使之变得完全一致，不过还是有公认的命名规范的。新的模块和包(包括第三方的框架)必须符合这些标准，但对已有的库存在不同风格的，保持内部的一致性是首选的。

描述：命名风格

有许多不同的命名风格。以下的有助于辨认正在使用的命名风格，独立于它们的作用。以下的命名风格是众所周知的：

b (单个小写字母)

B (单个大写字母)

Lowercase（小写）

lower_case_with_underscores（有下划线的小写）

UPPERCASE（大写）

UPPER_CASE_WITH_UNDERSCORES（有下划线的大写）

CapitalizedWords (或 CapWords，CamelCase这样命名是因为可从字母的大小写分出单词。这有时也被当作StudlyCaps。

mixedCase (与CapitalizedWords的不同在于首字母小写!)

Capitalized_Words_With_Underscores（有下划线的首字母大写） (丑陋!)

还有用短的特别前缀将相关的名字聚合在一起的风格。这在Python中不常用，但是出于完整性要提一下，例如，os.stat()函数返回一个元组，他的元素传统上说名如st_mode， st_size，st_mtime等等。

X11库的所有公开函数以X开头。(在Python中，这个风格通常认为是不必要的，因为属性和方法名以对象作前缀，而函数名以模块名作前缀。)

另外，以下用下划线作前导或结尾的特殊形式是被公认的(这些通常可以和任何习惯组合)：

_single_leading_underscore(单个下划线作前导)：弱的“内部使用(internal use)”标志。 (例如，“from M import *”不会导入以下划线开头的对象)。

single_trailing_underscore_(单个下划线结尾)：用于避免与Python关键词的冲突，例如：“Tkinter.Toplevel(master，class_='ClassName')”。

_double_leading_underscore(双下划线)：从Python 1.4起为类私有名。

_double_leading_and_trailing_underscore_：“magic”对象或属性，存在于用户控制的(user-controlled)名字空间，例如：_init_， _import_ 或_file_。有时它们被用户定义用于触发某个魔法行为(例如：运算符重载)：有时被构造器插入，以便自己使用或为了调试。因此，在未来的版本中，构造器(松散得定义为Python解释器和标准库)可能打算建立自己的魔法属性列表，用户代码通常应该限制将这种约定作为己用。欲成为构造器的一部分的用户代码可以在下滑线中结合使用短前缀，例如：

_bobo_magic_attr__。

说明：命名约定

应避免的名字。永远不要用字符‘l’(小写字母el(就是读音，下同))，‘O’(大写字母oh)，或‘I’(大写字母eye)作为单字符的变量名。在某些字体中这些字符不能与数字1和0分辨。试着在使用‘l’时用‘L’代替。

模块名

模块应该是不含下划线的，简短的，小写的名字。因为模块名被映射到文件名，有些文件系统大小写不敏感并且截短长名字，模块名被选为相当短是重要的，这在Unix上不是问题，但当代码传到Mac或Windows上就可能是个问题了。

当用C或C++编写的扩展模块有一个伴随Python模块提供高层(例如进一步的面向对象)接口时，C/C++模块有下划线前导(如：_socket)。Python包应该是不含下划线的，简短的，全小写的名字。

类名

几乎不出意料，类名使用CapWords约定。内部使用的类外加一个前导下划线。

异常名

如果模块对所有情况定义了单个异常，它通常被叫做“error”或“Error”。似乎内建(扩展)的模块使用“error”(例如：os.error)，而Python模块通常用“Error” (例如：xdrlib.Error)。趋势似乎是倾向使用CapWords异常名。

全局变量名

(让我们祈祷这些变量仅在一个模块的内部有意义)

这些约定和在函数中的一样。模块是被设计为通过“from M import *”来使用的，必须用一个下划线作全局变量(及内部函数和类)的前缀防止其被导出(exporting)。

函数名

函数名应该为小写，可能用下划线风格单词以增加可读性。mixedCase仅被允许用于这种风格已经占优势的上下文(如：threading.py)，以便保持向后兼容。

方法名和实例变量

这段大体上和函数相同：通常使用小写单词，必要时用下划线分隔增加可读性。仅为不打算作为类的公共界面的内部方法和实例使用一个前导下划线，Python不强制要求这样：它取决于程序员是否遵守这个约定。

使用两个前导下划线以表示类私有的名字，Python将这些名字和类名连接在一起：

如果类Foo有一个属性名为_a，它不能以Foo._a访问。(固执的用户还是可以通过Foo._Foo__a得到访问权。)

通常双前导下划线仅被用于避免含子类的类中的属性名的名字冲突。

继承的设计

始终要确定一个类中的方法和实例变量是否要被公开。通常，永远不要将数据变量公开，除非你实现的本质上只是记录，人们几乎总是更喜欢代之给出一个函数作为类的界面(Python 2.2 的一些开发者在这点上做得非常漂亮)。

同样，确定你的属性是否应为私有的。私有和非私有的区别在于模板将永远不会对原有的类(导出类)有效，而后者可以。你应该在大脑中就用继承设计好了你的类，私有属性必须有两个前导下划线，无后置下划线，非公有属性必须有一个前导下划线，无后置下划线，公共属性没有前导和后置下划线，除非它们与保留字冲突，在此情况下，单个后置下划线比前置或混乱的拼写要好，例如：class_优于klass。

最后一点有些争议：如果相比class_你更喜欢klass，那么这只是一致性问题。

设计建议

单个元素(singletons)的比较，如None 应该永远用：‘is’或‘is not’来做。当你本意是“if x is not None”时，对写成“if x”要小心。例如当你测试一个默认为None的变量或参数是否被设置为其它值时，这个值也许在布尔上下文(Boolean context)中是false！

基于类的异常总是好过基于字符串的异常。模块和包应该定义它们自己的域内特定的基异常类，基类应该是内建的Exception类的子类。还始终包含一个类的文档字符串。例如：

#!Python

class MessageError(Exception)：

"""Base class for errors in the email package。"""

使用字符串方法(methods)代替字符串模块，除非必须向后兼容Python 2.0以前的版本。字符串方法总是非常快，而且和unicode字符串共用同样的API(应用程序接口)在检查前缀或后缀时避免对字符串进行切片。用startswith()和endswith()代替，因为它们是明确的并且错误更少。例如：

No： if foo[：3] == 'bar'：

Yes： if foo。startswith('bar')：

例外是如果你的代码必须工作在Python 1.5.2 (但是我们希望它不会发生！)，对象类型的比较应该始终用isinstance()代替直接比较类型，例如：

No： if type(obj) is type(1)：

Yes： if isinstance(obj， int)：

检查一个对象是否是字符串时，紧记它也可能是unicode字符串！在Python 2.3，str和unicode有公共的基类，basestring，所以你可以这样做：

if isinstance(obj， basestring)：

在Python 2.2类型模块为此定义了StringTypes类型，例如：

#!Python

from types import StringTypes

if isinstance(obj， StringTypes)：

在Python 2.0和2.1，你应该这样做：

#!Python

from types import StringType， UnicodeType

if isinstance(obj， StringType) or \

isinstance(obj， UnicodeType) ：

对序列，(字符串，列表，元组)，使用空列表是false这个事实，因此“if not seq”或“if seq”比“if len(seq)”或“if not len(seq)”好。书写字符串文字时不要依赖于有意义的后置空格。这种后置空格在视觉上是不可辨别的，并且有些编辑器(特别是近来，reindent.py)会将它们修整掉。不要用==来比较布尔型的值以确定是True或False(布尔型是Pythn 2.3中新增的)

No： if greeting == True：

Yes： if greeting：

No： if greeting == True：

Yes： if greeting：

本文链接

List操作——Haskell

2011-03-15T19:11:00Z

1. 在Haskell中，字符串的的确确成了字符数组的语法糖。

2. 合并List

在Haskell中，合并List是用++运算符来实现：

在这里，我们也可以看到字符串和字符数组的关系。

但是++操作符，会遍历左侧的List，这样List越长，访问起来越慢，这个时候使用：会是更好的选择：

但是，：运算符只能连接一个元素和一个List：

那么从上面，为什么不能成为[[1,2,3],4,5,6]，而却报了一个错呢？这是因为Haskell的List只能容纳同一种类型的元素：

还有，既然我们都说了字符串其实就是字符数组，那么一样可以把这些操作放到字符串中去：

3. List的索引

我们在常规语言中，一般都是习惯用中括号，然后下标来取List中的某个元素，但是Haskell的这个语法很诡异！

4. List比较大小

这个其实很容易想象了，无非是从第一个元素开始比较这样一直来：

但是比较只能基于同一类型，否则就报错了！

5. 常用函数

把List当初一个栈，一个队列，也就随之产生了这样的函数：

一些很常用的：

6. Range

区间是个很有用的东西，现在我每次看到for循环对数组赋值就有些头疼了。

这是个聪明的家伙

但是还不足够聪明，我想输出2，4，8，16，他就无能为力了。

7. 惰性求值

在以前的文章里说过惰性求值

cycle 和 repeat都是生成无限长的List，但是……………..

Haskell不会执著地全都求完再计算，而是根据计算而求值，这就叫做惰性求值。

本文链接