初识饭否

很早以前就听说了twitter，不以为然。四月我刚刚加入海词的时候，刘勇又大力给我宣传了twitter，介绍了twitter和facebook在美国的火爆，而我仍然不以为然。facebook是SNS，SNS我有我独立的想法，看了一下并不相同，自然就放弃关注，任它火爆我自不动。twitter我也没应用，自然不能理解它的意义所在，单纯的从一句句看似的废话中感觉挺无聊的。以至于后来模仿者饭否在国内上线并迅速刮起一阵旋风，而我仍然站得远远的，只听风声却无视。

两天前我偶然用上了饭否。注册的动机是这样的，杨磊给我说在饭否上嗷嗷和彭毅说到了我还有出书，他转述得模糊却勾起了我的好奇心，于是决定注册饭否看看到底说些什么。注册好了，搜索嗷嗷，加为好友，屏幕显示嗷嗷也加我为好友了，真奇怪，屏幕继续显示，杨磊和怿飞立刻把我加为好友了，他们怎么知道我注册了？当然，很快我就反应过来，嗷嗷、杨磊、怿飞互为好友，而好友的操作是能被即时看见的，所以嗷嗷加我这一动作瞬间，就传给了他的每一个好友。原来如此……这种传播方式……真有点病毒……

最初的使用过程并没有让我觉得多么的与众不同，我绑定了MSN/GTalk。是的，信息的发布和接受通过最常用最习惯的即时通讯软件完成，非常便利，又怎么样呢？这种模式的意义，和即时通讯相比好像没太大进步，整个下午一直迷惑的我在当天下午下班前绑定了手机，而当我坐在的士上拿出手机饭否的时候，我对饭否的态度来了一个5255B向后翻腾两周半转体两周半屈体。

理解饭否

下面这段话是当时通过手机短信记录到饭否上的：

坐在的上，带着产品详细设计文档正赶往西湖天地一茶一坐，海词第二次聚会。当我写下上面的话，一下理解了为什么twitter会那么火，这是我第一次在离开电脑离开有线无线网络情况下，又如此方便的使用互联网记录我的生活，感谢饭否感谢杨磊。好了到了，沿湖漫步过去，夕阳很美我很帅。2007-08-07 18:41 通过短信 分享 删除

是的，当我使用手机坐在的上，通过最常用的发短信方式记录自己的心态、感受已经正在做的事情，并且能够第一时间的分享给我的好友，我才真正理解了twitter这个创意的精妙和价值。剩下的就是拍手叫绝，强烈地感受到互联网离我很远却又很近，朋友离我很远却又很近。互联网终于开始离开有线离开无线离开电脑开始逐步渗透进日常生活中。从台式机的网线进化到笔记本的无线再进化到手机的GPRS，现在普通的短信也融进互联网了。合网的威力真不一般。曾经的三网合一，如今第一次从日常应用中开始感受到。

我们需要记录吗？

使用饭否的第二天我就当了一次饭否推广者，在大学班群里大力推广，但因为只有我一个人在互联网里，所以大家都不为所动不能理解，争论的中心是这些无聊的话为什么要记录，说完就完了呗，记录毫无意义。直到最后我说出记录的目的之一是分享，他们说为什么要分享？我发现互联网外的人们对分享二字真的缺乏理解，分享的理念非常单薄，其实这点我早早就有很强烈的感受。常常听到的就是“这些多无聊”，“我没什么可分享的”，“这是我的隐私”等等。很多人低估了自己的力量，不知道自己是可以给身边的人带去很多的欢乐的，是可以为身边的人分担很多的烦恼的。

说到这里我想起我的中学时代，那个疯狂追星的时代，四大天王红遍整个大陆的时代，当年有一部电影用夸张的手法描述，一个蜂拥的人群中几个人高高站着，摇着手中的商品：“卖刘德华的内裤啊”，“张学友穿过的拖鞋，谁要啊？”，“黎明的头发！”，“郭富城擦过鼻涕的手纸，抢啊！”。明星是被关注的，一言一行都被追捧。过去是这样，十多年过去了，现在仍是这样，韩寒博客敲上一个点，都上万的人蜂拥而入，成千的评论产生。这很正常，但是很多人忽略了一点，忘记了一点，那就是不是只有明星才会被关注才会被追捧，实际上每一个人，每一个个体都是明星，都在关注和被关注中，都在追捧和被追捧中，只是程度不一样而已。你难道不关注你父母的一言一行？难道你的一言一行不被你的父母所关注？难道你不关注你的家人而又不被你的家人所关注？难道你不关注你的朋友而又不被你的朋友所关注？难道你不关注你的身边而又不被你的身边所关注？

当然，顺手抨击一下现在金钱至上的社会，很多人关心的重心最终还是落在金钱上，哪怕是对父母的关注，这种已经变态的心态我不想多说了，口头禅：钱是TMD王八蛋。还是回题。我们常常关注也被关注着，问题来了，我们不是明星，我们身边的人也不是明星，没有传媒为我们传播，又常常的，亲人好友，我们眼中平凡的“明星们”散落五湖四海，那么如何关注又如何被关注？答案是：记录。于是，博客来了，使得人们能够方便的记录自己，让朋友更方便的关注自己，让自己更方便的关注朋友。但是博客的弊端也很明显，博客是以文章为记录和分享单位，而文章这两个字就具备很高的门槛，于是善于写文的人疯狂的爱上了博客成为被关注者，而不善于写文的人则远离成为一名关注者。很显然大部分的人并不善于写文，于是博客本来想完成的任务，人人记录，人人都被关注如落花流水，最终变成了精英记录，大众关注。

大众仍然没有被关注。我常常写博，我的亲人朋友能够很方便的了解我的情况，我的动向，我的心态。但我，我想了解他们的时候，想知道他们近况的时候，我找不到办法，因为他们都不写博，都不记录。我最好的兄弟生了一个女儿，他兴高采烈的群发短信告知每个好友，并且后来在QQ空间上记录下每一天他整个心情波动，我非常高兴的分享了他的快乐，他通过记录把快乐传递给了我。但是不是只有大事才值得记录，小事也是值得记录的。所以在2005年底我开始构思我自己的SNS，是的，我第一份整体规划文档仍保留在，时间是2005年12月31日。一年后，2006-12-03 21:27，我又给数个远远近近的好友详细的描绘了我的伟大SNS。摘其中和本文主题相关的一段：

然后说说关于流水帐，流水帐有价值和意义吗？还是举个例子吧，一句典型的流水帐：“今天，我摔了一跤。”这句话有价值嘛？有意义嘛？如果写下它的人和你毫不相干，你肯定也毫不在意。但如果是你的朋友，我想或许你会留言关心一下“没摔伤吧”，又或者调侃一下“爽不爽”“活该你倒霉”之类。而如果是你的父母写下这么一句流水帐，恐怕就惊天动地了，你会马上抓起电话。流水帐和作文不一样，它的价值不在于文章本身是否写的够精彩、文笔是否够华丽，而在于首先对于作者，它留住了时间，见证了成长的历程。而对于有心的读者，它是一次闲聊式的交流。想想看，朋友之间的闲聊什么时候文绉绉的精彩和华丽？还不都是口水话，还不都是嘻笑打骂，还不都是各自的生活流水帐，一起分享和分担。

是的，我觉得记录另一个更重要的作用是让时间停止。你知道去年的此时此刻在做什么吗？当然会有人说没意义，我们应该向前看。是是是，我们应该向前看，但如果我告诉你我有你六年前你的生活记录，你想不想看看六、七年前的自己呢？你现在有办法看见六、七年前的自己吗？我有！我能看见六七年前的自己和我的朋友！

从2000开始我就一个QQ文件夹随身带，升级也只是覆盖，于是我几乎完整的保存了从那时开始我的所有聊天记录，我不但能从我和每个人的聊天内容中看见过去的自己，还能看见过去的朋友。我QQ上的朋友如果愿意可以向我索取过去，如果我们曾经聊过，有关生活的，有关情感的，有关生活的滴滴点点。或许还是有人觉得没意义，比如我的一些大学同学，那么如果我能把十多年前我们在寝室里彻夜疯聊的记录还原出来，你还觉得没意义吗？但是我做不到，那个时候记录的手段太单一太刻意，但是我现在至少可以去为明天的温馨回忆而刻下今天的记录！

所以，饭否，哦不，应该是twitter，它成功的做出来了，甚至在这点上比我所构思的做得更好，更极致，我很高兴。如果有人纳闷：“MD，自己搞不出来还高兴。”我笑着对你说：“学会欣赏，不要心中只存嫉妒。”我一直有点拿捏不准自己的构思是否会如我想像的那样，现在我了解了twitter，它给我打了一针定心剂，甚至让我相信自己设计的的传播模式比他更进一步，更病毒，并由点及面更加强了我其他方面构思的信心。入口一样，但是大方向和目标及终点目前看来并不一样，即便一样，我仍然要为twitter鼓掌！也为饭否鼓掌！

不是QQ群

QQ群是腾讯的成功也是失败，成功的是让我们脱离了即时通讯单调的1V1模式，有了疯狂NVN的选择。失败的是它站在它的辉煌上，多年以来一直停滞不前。

交流是一切和SNS沾边应用的核心，可以说没有交流就没有SNS，交流的方式两种：聊天和分享记录。已经长篇大论了，详细的不展开了，还是回题。QQ群是以主题聚集人，比如班群，旅游群，泡吧等，以主题为中心就意味着个人的埋没，因为在个人之上是主题，主题凌驾于个人，一个不泡吧的人肯定不会进入吧群中。而twitter模式的聚集是以个人为中心展开，我不认识你？对不起，你不属于我的“群”。在twitter模式中，每个人都有一个属于自己的群，由自己建立也由自己管理。

为了写完，长话短说，点到为止了。

不是聊天室

QQ群是建立在即时通讯上的聊天室。和遍地都是的网页聊天室以及QQ自身的聊天室系统相比，QQ群依靠客户端对个人有所绑定。但是……QQ群火爆的背后是什么？

你加入了多少群？来来往往，你留下了什么？我加入的所有群都设置成“消息来时之显示消息数目”，连离我最近的，每个人都认识的班群都如此，剩下乱七八糟的群更不说了。和我一样的人有多少？我想，遍地都是。当然我不否认仍有一大群闲人们就泡在里面疯聊。为什么要设置？

不是论坛

温习一遍后，发现最终还是没写完。回头温习了一下我的饭否，2007年8月7日开始，一共废了757条话，很长一段时间，只绑定了手机的弟弟给我说他要疯了，每天要收到我十多条饭否废话短信。现在很少饭否了，饭否不能导出记录让我这个记录收藏者很不爽，缺乏安全感，而且我觉得一年多来，饭否停滞了，没有质变，缺乏深入的挖掘和发展，所以还是回到blog。博客园能够导出所有文章，保存在本地备份，对我来说，倍儿安全，这是我四年如一日留在博客园的原因之一。

     四年了，我在博客园里认识了很多朋友，自己也有幸成为了2006年度的MVP，接着也就是在2006年走上了漫漫创业之路。而博客园从一个默默无闻的技术小站到现在成为国内极具影响力的技术博客，我们可敬的园主dudu这一路走来，也颇为不易。我想，dudu一直都在为自己的理想而奋斗着，园里很多创业的朋友也都胸怀做一番事业的理想。那么，如何实现自己的理想，如何让自己的事业能够沿着理想的路径前进呢？这应该都是你我每天都在思考的问题吧。在过去的两年里，我经历了“离开世界500强企业 -> 创业 -> 创业失败 -> 再创业”，没啥经验，只有教训，就写下来博各位一哂了。

    我想说的第一点就是放下理想。作为一个昔日的IT人（将来还会回归IT），我很清楚IT人最大的优点就是充满激情，充满理想。而这个优点往往又是一个劣势，我想这都是互联网犯的美丽错误，让我们都错误地认为自己的产品所面对的消费群体就是全世界。当想象着自己的杰作能够被世人所欣赏，这种成就感是不可比拟的。但是，这只是一个理想，或者说一个由idea构造起来的理想。IT人是充满想象力了，因为我们通过网络了解到很多身边不存在的事物，这开拓了视野，也增长了的见识，让我们敢于去想象。想象并不是坏事，如果想象的东西都不着边际，不停地喊口号，那就糟糕了。曹操作为一代枭雄，他也只是喊出了“宁可我负天下人，不可天下人负我”的口号，也没见他怎么提过要一统天下。所以，每当为自己的idea、自己的理想激动不已的时候，请保持冷静，因为那可能只是镜花水月而已，甚至连自己都不知道通向成功的第一步该如何去走。荀子老子告诉我们说：“千里之行，始于足下。”，这句话是什么意思呢？说白了就是通向成功第一步的可行性。连第一步都不知道怎么走，想着遥远的未来又有何用？我们每个人都应该有理想，但是最需要考虑的还是所迈出的第一步吧。毕竟路漫漫其修远兮，看看咱们园子里最早的老朋友Teddy、Allen Lee、善友、老燕、THIN、张逸、TerryLee、lovecherry、吕震宇，还有后起之秀Dflying Chen、老赵、anytao、伍迷，直到现在的1-2-3、逖靖寒等等（还有很多很多朋友，无法一一细数了），我想各位就应该明白这坚实的第一步的意义在哪里了。

     我想说的第二点就是抛弃所谓的英雄主义。IT业界充斥着太多英雄主义的故事了，从刚刚退休的Bill Gates到Apple的Steve Jobs，哪位不是咱们崇拜的英雄呢？但是，你是否听过Bill Gates被反垄断诉讼搞得焦头烂额的时候，是Steve Ballmer为他主持大局的故事呢？也是否听过Bill Gates为了挖来C#之父Anders Hejlsberg，亲自与他共进晚餐，许诺让他带领开发团队才“抱得牛人归”的故事呢？每一位实现理想的人都不会是光棍司令，而是能够用命三军的首领。刘备是三分天下得其一的英雄，他自己根本比不上曹操那么牛，但是他的手下呢？都是我们玩游戏时候最喜欢用的五虎将，还有像神一样的诸葛亮。成就理想是不能靠单打独斗的，是需要团队的。我们不能够只笼络能够谈得来的伙计，而排斥那些提出不同意见的诤友。要开拓事业，我们需要的是团队精神，而不是英雄主义。

     我想说的最后一点就是热爱自己手头上的工作。IT界同样流传着很多牛人为了创业而辍学的故事，而且他们大学专业大多学的不是计算机。Bill Gates学的是法律，Michael Dell学的是医学，Steve Jobs学的甚至是属于艺术范畴的字体设计。他们为了自己热爱的IT事业选择了放弃学业。这看起来，放弃似乎也是成就理想的必备条件之一了。让我们再看看现在的IT行业，流动性是何其之高，就连我自己都在短短三年内换了两家公司，然后从公司出来和朋友创建了一家IT公司，最后创业失败，接着暂时离开IT行业。这些英雄们的故事给了我们太多放弃的理由，但是，他们之前所学的专业都为日后的成就起到了不可磨灭的作用。Bill Gates如愿逃过了反垄断的诉讼、Michael Dell最早把自己组装的电脑卖给了医生、Steve Jobs让Apple的产品在设计上无人能敌，这些事实都说明了学到的东西总会有派上用场的时候。一项工作哪怕再枯燥乏味都有它的内涵和外延，就看你是否热爱它。对待手头上的工作，我们还是得学习雷锋的精神——干一行，爱一行，在工作中积累足够的经验，为将来的事业打好基础。

     夜已深了，想想又到了凤凰花开时，回想五年前，自己踌躇满志走出校园的时候，我也曾告诉同窗好友说：“等着吧，我也要成为MVP，我也要到微软去工作。”而现在，我只实现了第一句话。至于第二句话，不仅我与机会失之交臂，没能实现之，同时这也不再成为自己的理想了。再多的理想都要付诸行动，“少谈些理想，多做些实事”是我现在的座右铭，希望与各位园友共勉之。

每一个程序员都希望工具能够更进步，能够更好的服务自己，好让自己少加一些班，但是一旦它真的变好，好到自己已经感觉不可控，那么一种恐惧感便油然而生，随之而来的是不屑、挑刺、贬低、迷茫、无所适从，甚至恶意攻击、无端谩骂等等……

就像当年Java初入世，那些C/C++的元老们一样：Java只能用来在页面上用applet作一些可笑的小动画，Java只能对对火柴棍排序，Java慢得像牛车，Java有内存泄露，Java狂耗内存，Java愚蠢的弱类型容器可以把鲸鱼装进一个笔筒，Java居然没有指针，Java做不了系统程序设计，Java写不了操作系统，Java解决不了我手头的超超级复杂的巨牛无比的难题(孟岩)云云，当然亦如如今Java/.Net元老们对待动态语言态度一样。

没有什么一出世就是完美的，但也没有什么可以一直完美下去，抵制，只因为习惯，只因为恐惧，习惯于写N长的代码去解决一个问题，恐惧于别人两行代码代替了自己2000行的功能，习惯于自己是公司的元老是大牛，恐惧于一个初生牛犊解决了自己长久以来难以解决的问题…… 因为抵制，由此产生的攻击，如此说来，这也算是一种进步，一个新兴的东西，有这些抵制者来发现问题，才会更好的在下一步解决问题，以更好的替代。

由此想来，为什么程序员总是很累？虽然加班经常，但还不至于天天都晚上十点还要搬砖垒墙，虽然压力偏大，也还不至于头一天陪客户蹦迪到凌晨4点，早晨8点还得西装领带满脸笑容神采奕奕去见另一个客户，虽然挣钱无多，怕也不至于到过年回家时还要追着老板要路费。可是依然感觉累，周末睡了两天，周一早晨依然没有精神，于是，要找个替罪羊，总不能就这样不明不白的累了吧？怪老板，老板天天给我们N多任务，压得我们喘不过气，可是老板发我们钱，万一他不爽我们就惨了，所以想想，还是忍了吧；怪PM，他总看我不顺眼，啥事儿都让我干，还处处给我小鞋儿，不行，如果他在老板面前说我坏话……还是算了；Java！.Net！可恶，天天出新东西，搞得我天天跟着跑还跑不过来，不跟？老板拿隔壁公司说事儿：看人家可以XXX，看人家的系统XXX，人家都能XXX你们为什么不能？！

程序写的累，天天为解决这些问题想破脑袋，于是天天盯着MS的网站看是不是又出什么好东西可以让我少加会儿班？咦？果然有新东西，下载，安装，启动，嗯……似乎有点摸不着头脑，这是什么？怎么用？算了，还是先不看了，今天的任务要先完成。过了两天，发现有人在用这个，第一反应：小儿科，我就是没时间，要不然……可是当别人真的拿那东西来做事情了，自己拿来看两眼：这东西似乎不太好学，会不会大家都开始用这个？如果我现在学不会，会不会影响我在团队中的地位？老板会不会给他加钱不给我加？

恐惧，又见恐惧，恐惧新事物，恐惧自己的经验贬值，于是乎，不屑，挑刺，贬低……恐惧的表现…………但不能让人看出来………………

↓↓↓↓↓↓↓↓↓↓ 人说发牢骚可以长寿，给大家提供个地方 ↓↓↓↓↓↓↓↓↓↓

我眼中的C# 3.0

Written by Allen Lee

缘起

每次有新技术发布时，我们总能感受到两种截然不同的情绪：一种是恐惧和抵抗，伴随着这种情绪的还有诸如"C# 2.0用的挺好的，为什么要在C# 3.0搞到那么复杂？"或者"我还在使用C# 1.0呢？"等言辞；另一种则是兴奋和拥抱，伴随着这种情绪的还有诸如"原来这个问题在C# 3.0里可以这么简单！"等言辞。

最近我在公司内部做一个LINQ的系列讲座，在我为其中C# 3.0新特性这一讲准备演示文稿时，突然萌生了写下这篇文章的念头。语言的特性乃至其本身并没有对错之分，是否接受在很大程度上是一个感性问题，即你是否喜欢这样的做事方式，我并没有打算说服任何人接受C# 3.0和LINQ，写这篇文章也只是想和大家分享一下我自己的感受。

有一次我观看一个关于Expression Blend的培训视频，里面说了一句让我印象非常深刻的话：

I know how it works because I know why it works.

细细品味这句话，你会感受到它所要传达的信息：理解为何需要这个功能可以帮助你更好地理解如何使用这个功能，而这也正是我要在这篇文章里采用的表达方式。

你是如何创建属性的？

如果你长期使用C#，相信你不会对属性这个东西感到陌生。一般地，属性是对私有字段的一个简单包装，就像这样：

代码 1

使用属性而不是直接公开私有字段的一个好处就是在属性的获取访问器或设置访问器里加入额外的逻辑并不会为客户端代码带来麻烦，例如你想在设置标题的时候做一些额外的检查。但如果你只是简单地包装一下，像上面的代码那样，就会发现你其实多写了不少可以省略的代码。既然Title属性和m_Title私有字段对应，获取访问器就肯定是返回m_Title的值，而设置访问器也肯定是把值设到m_Title。再者，如果你只通过Title属性来访问这个数据，那么m_Title私有字段就会变得无足轻重，这样的话，为什么不交给编译器代劳呢？这个时候，C# 3.0的自动属性就可以派上用场了：

代码 2

编译器会为你创建一个私有字段，并让获取访问器和设置访问器指向这个私有字段。当然，如果有需要，例如要在获取访问器或设置访问器里加入额外的逻辑时，你随时可以对获取访问器和设置访问器进行展开。

你是如何初始化对象的？

现在，假设我们有这样一个类：

代码 3

你会怎样初始化它？一种做法是用Book的默认构造函数创建对象实例，然后分别为每个属性赋值：

代码 4

另一种做法是使用C# 3.0对象初始化器：

代码 5

乍看一下，C# 3.0的做法似乎没有让人感到任何优越感，现在，请你仔细观察一下，这两份代码分别包含多少个";"？代码4有5个";"，意味着它用了5个语句进行初始化；而代码5只有1个";"，意味着它只用了1个语句进行初始化。从词法的角度来看，如果此刻我只能接受一个表达式，那么代码4的做法就帮不上忙了。一个变通的方法是为Book类提供带参的构造函数，但这种方法也有弊端，用户可能只想在初始化时为部分属性提供数据，而我们又无法确切预知用户会提供哪些属性的组合，于是，我们可能要为用户提供足够多的构造函数重载，嗯，有点无聊，也有点多余。另一个变通的方法是提供接受最多参数的构造函数，如果用户为某个参数传递null，那么就忽略与之对应的属性，这个方法比较接近代码5的做法，不同的是，如果你的属性很多，而用户关心的只是很少一部分，就可能不得不输入很多null了。

现在，假设你要实例化一组Book对象，并把它们储存在一个集合里，你会怎么做？下面是通常的做法：

代码 6

如果结合使用C# 3.0的对象初始化器和集合初始化器，你就可以把代码简化为：

代码 7

集合里的每个元素通过","分割，结合对象初始化器使用，整个集合的结构显得比较明晰。字典的初始化也可以同样简单：

代码 8

说到这里，我相信你也能感觉到，C#似乎正在表达式化，以前需要很多条语句才能做到的事情，现在却可以用单个表达式描述出来，而这种理念也渗透在整个C# 3.0的氛围里。

你是如何把运算逻辑外包出去的？

假设我现在得到了一组Book的实例对象，你要对它们进行排序，那么你如何告诉它你要按价格来排序呢？

代码 9

在C# 1.0里，我们需要特意为它提供一个独立的方法：

代码 10

然后向Sort()方法传入所需委托的实例：

代码 11

这在C# 2.0里可以进一步简化为：

代码 12

如果使用C# 2.0的匿名方法，我们可以省去很多不必要的代码：

代码 13

此外，使用匿名方法，Sort()方法和你希望它用来比较两个Book实例对象的逻辑可以放在同一个地方；而使用独立的命名方法，包含这个逻辑的方法可能会由于整理代码而被挪到别的地方。这样，当你看到代码12时，为了了解它内部的实现，就不得不花一些精力去寻找Compare()方法了。当然，你可以争辩说，我们可以制定一个编码规范，使得Compare()方法必须紧贴在Sort()方法的下方。是的，你可以，但如果这个逻辑并不需要重用，那么使用匿名方法还是具有明显的优势的。如果这个逻辑需要重用，那么匿名方法就无能为力了。

现在，让我们来考察一下代码13，有没有发现匿名方法的表达方式还不够简练？我们知道，books集合里面只有Book的实例对象，所以Sort()方法传给我们两个参数的类型必定是Book，而Sort()方法期待的结果正是x.Price.CompareTo(y.Price)这个表达式的运算结果，至于delegate和return这样的字眼可以说在这里完全是多余的，那么为什么我们不直接这样表达呢：

代码 14

这就是C# 3.0引入的Lambda表达式语法。我见过一些人，他们通常强调尽可能简单，但若事情突然变得比他们预期的还要简单很多，他们就开始感到不适，甚至拒绝接受这种简单，其实即使事物的发展方向和你的前进方向相一致，但如果发展速度大大超越了你，仍然有可能引发你内心对失控的恐惧。我希望Lambda表达式语法不会让你感到太大的不适，当然我更希望你会喜欢上它。

Lambda表达式的理解其实可以很简单，就是"=>"左边的参数参与右边的表达式运算，而运算结果将会返回，这有点像化合反应，即两种或两种以上的物质（左边的参数）生成一种新物质（右边的表达式的运算结果），不同的是，Lambda可以不接收任何参数，也可以不返回任何结果。

"=>"右边除了可以放表达式之外，还可以放语句，像这样：

代码 15

我们把它称为Lambda语句（Lambda Statement），或许你已经发现，它和匿名方法相比只是不需要写delegate关键字和参数类型。

你是如何为对象扩展与之相关的功能的？

我一直在想，为什么String类没有提供一个Reverse()方法，把字符串翻转呢？我猜可能是因为这种操作没有什么现实意思，除非你要做一个文字游戏。实现Reverse()方法并不难，下面是其中一种做法：

代码 16

使用方法也非常简单：

代码 17

你甚至可以把Reverse()方法放到某个静态类里，例如Utils，这样，代码17就可以变成：

代码 18

在C# 3.0之前，你最多只能走到这里，而到了C# 3.0，你还可以使用扩展方法对它做进一步调整，使代码18变成：

代码 19

怎么样，看上去就像Reverse()方法是属于String的，而你所需要做的仅仅是在Reverse()方法的target参数前面加上"this"关键字：

代码 20

我们知道，计算机的底层世界并不知道什么是面向对象，而我们在对象里定义的实例方法都包含一个隐藏参数，这个参数就是指向当前对象实例的指针，C# 3.0的扩展方法在形式上模仿了这种做法，但由于扩展方法本质上并不属于与之相关的类，所以你无法在扩展方法里访问类内部的私有成员。

就上面的讨论来说，你可能认为，和代码18相比，代码19并没有太大的优势，那么为什么需要扩展方法呢？假设我们手头上有一堆书，我想找到最便宜的LINQ的书，使用标准查询运算符的话可以这样写：

代码 21

我们知道，Where()、OrderBy()和First()等都是扩展方法，如果C# 3.0不支持扩展方法，那么代码21就不得不写成这样了：

代码 22

代码21的可读性明显比代码22的高，也显得更自然，而此时我们只是使用了3个标准查询运算符，你可以想象一下，在没有扩展方法的支持下要表达更复杂的查询会是怎样一番情景？

你是如何表达你想要的东西的？

现在，假设我想找到最便宜的LINQ的书，使用C# 2.0的语法，我可能需要这样：

代码 23

虽然我已经使用了Array.IndexOf()方法、List<T>.Sort()方法和匿名函数来简化代码，但仍然无法掩盖一个事实，那就是我在讲述如何获取我想要的东西，而这也正是命令式编程（Imperative Programming）的核心思想。

如果使用C# 3.0的语法，情况将会大不一样：

代码 24

在这里，你表达了你想要的东西，而不是获取这些东西的具体步骤，这是声明式编程（Declarative Programming）的核心思想，这样做的好处是明显的，你的需求可以被重新解析并执行，必要时还可以对底层的实现进行优化，但由于你并不关心和牵扯到具体的实现上，所以那些优化并不会导致你修改代码。

命令式编程就像过程管理，你深入执行的细节，继而对整个过程的执行实施控制；而声明式编程则像目标管理（MBO），你制定目标，并把任务分配下去执行。代码23给人的感觉就是整个执行过程都非常的清楚，你可以对任何一个步骤进行修改或者调优；而代码24给人的感觉就是你除了说出你想要什么，你什么也不能做，这对于那些过程管理拥戴者来说可能是不可接受的，他们感到对事物失去了控制，无法建立安全感，因而产生了焦虑。曾经有人向我抱怨：如果你使用了LINQ，你就只能迫使自己相信它的实现是很好的。想想看，如果你的公司把饭堂业务承包给一个餐饮公司，你的公司可以插手别人如何招聘厨师、如何采购食物、如何烧菜烧饭吗？选择LINQ意味着你愿意把执行细节交给别人去处理，从而脱离这些细节，如果你根本无法放下对这些细节的控制，那么LINQ可能并不适合你。

很难说这两种编程方式孰优孰劣，因为在某些场合下，善于过程管理的管理者确实更能让事态朝正确的方向发展；而在另一些场合下，目标管理为实现者提供足够的自由度，更能激励他们积极地进行思考。管理界对于过程管理和目标管理孰优孰劣之争论似乎从来没有停过，更何况编程界对于命令式编程和声明式编程孰优孰劣之争论，我个人倒是更倾向于把这看成是找出更适合你自己的风格，而不是盲目听信别人的说法。语言到底是发挥积极作用还是消极作用在很大程度上是取决于使用者的，我们应该使用语言有利的一面来协助我们的工作，而不是使用其有害的一面来伤害自己和别人。

回到代码24，它把满足条件的书的所有信息都返回给我，如果我只需要书名和作者名字呢？我们知道，在面向对象的世界里，信息储存在对象里，于是我们不得不走到一个尴尬的境地，那就是我们要为此创建一个临时类：

代码 25

噩梦正式开始了，如果我需要书名和价格呢？如果我需要书名、作者和价格呢？……（读者可以自行补全这个列表）这个时候就轮到C# 3.0的匿名类型和隐式类型化变量出场了：

代码 26

因为匿名类型是由编译器自动生成的，而在你写代码的时候它还没有名字，所以你无法用这个类型来声明这个变量，此时"var"关键字就派上用场了。这个是"var"关键字的最初目的，但得益于类型推断系统，我们还可以使用"var"关键字声明任何本地变量，只要我们在声明的同时给予它初始化，否则编译器无法进行推断。曾经有人问我：如果我想返回代码26里的wanted7怎么办？我们知道，方法的返回值需要明确给出类型，而在我们写下代码26时，编译器还没有给查询表达式里的匿名类型取名。如果你真的要把它返回，你只能把方法的返回值类型定为IEnumerable<object>，因为我们只能确定匿名类型是object的后代，但这样一来，客户端代码的日子就不太好过了，因为除了通过反射来访问你的对象，它别无他选。如果你真的要把它返回，那就意味着你和客户端代码有共享这个对象的需求，此时恰当的做法应该是使用命名类型。另外，代码26里构建匿名类型时的"book.Title"是"Title = book.Title"的简写，当你省略"Title ="时，编译器会假定你希望匿名类型的这个属性的名字和Book.Title的一样。

匿名类型还有一个有趣的地方，它曾经是可变的（mutable），后来却变成不可变的（immutable），Sree在《Immutable is, the new Anonymous Type》一文中给出了这个转变的解释。我们知道，在面向对象的世界里，对象封装并维护自身的状态，我们通过调用对象的方法所产生的副作用来影响对象的状态，而不可变则是函数式编程（Functional Programming）的核心特征，或许你已经感受到了，C# 3.0引入了大量函数式编程的东西，而函数式编程语言似乎也要风生水起，这究竟意味着什么呢？

前路在何方？

无论你是否承认，C# 3.0在表达上比它之前的版本要来的简单，但要获得这种简单，你必须先用很多东西武装自己的脑袋，这使我想起曾经在一本书里看到的一句话：

简单是由复杂来支撑的。

不同语言之间的相互渗透已经不再是什么新奇之事了，引入其它语言的功能有时候甚至可以看作是在战略上入侵对手的市场，这在某种程度上有点像金融业的混业经营。下一个版本的C#将会是怎样的呢？或许这个问题令你兴奋不已，你甚至希望现在就让C# Team看看你的创造力；或许这个问题令你痛心不已，你害怕自己无法适应下一波的变革，因为变革可能导致动荡，动荡可能带来失控，失控可能引发焦虑。不管怎样，该来的是无法回避的，或许现在先让我们看看Matthew Podwysocki的《What Is the Future of C# Anyways?》是否有一些启示……

附：如果你有兴趣看看我的演示文稿，可以点击这里下载。

2、今天收到了一封邮件说是要追加控件，和上面的情况看上去好像不一样，但实质就是同一回事。

原因：

其实网上有很多帖子都不约而同地解释了这个问题，这里我还是不厌其烦地解释一下：

首先，要提到大家所熟知很多人一知半解的页面生命周期，以至于很多居然还停留在将ASP.NET和Winform一样处理的层次上，因此就会有人试图将变量存在实例字段中，然后一如既往地指望它能够用来共享数据，结果总是无功而返，以我所知这样的人居然还不在少数，当然了，咱博客园的素质相对偏高，这种问题一般不在话下。事实上每次页面PostBack都会从Aspnet线程池中返回一个空闲的用户线程，用于处理用户本次的请求。摆弄一下那种浏览器进度条会动的控件基本也都算是回发事件了。两次回发之间可以当作没有什么关联的。但是你总能看到很多控件等在回发之后还能保持状态比如文本框边上有个按钮。你填写完了文本后狂点那个按钮，你会发现文本框中的文字还是你填写的那些而不会被清空。这就不得不说到ViewState这种神奇的双刃剑了。它的原理在MSDN上讲的很清楚，找不到的留言或发邮件给我我再慢慢给你找……

然后呢？还是查MSDN,关键字“TemplateControl.LoadControl ”我们在用PlaceHolder中动态添加控件的时候就会用到这个方法了。我们注意到这里有一句：“在将控件加载到容器控件时，该容器引发所添加控件的所有事件，直到所添加控件参与当前事件为止。但是，所添加控件不参与回发数据处理。”因为所添加的控件是不参与回发数据处理的，因此就会出现问题1中所遇到的按另一个按钮就消失的现象了。问题2其实也是一样的问题，因为事实上它们遇到的现象是一样的，只不过它的需求有所不同罢了。（可以理解成一个是i=1;另一个是i+=1;）

综上所述，问题的关键就是原本在页面加载的时候所有的控件初始化操作都应该完成，动态加载将加载的过程延迟到了事件被触发之后，因此在页面回发后，因为会有一次新的页面加载过程，显然这时候动态加载的控件是不存在的，但是用户预期的答案是显示已经加载的信息。这时候如果可能我们最好在加载的过程中进行控件的重新加载和数据绑定。常见的方法中我们呢通常通过LoadControl来动态加载控件，因此只要在页面输出之前的所有事件节点上我们都可以加载我们的控件。但是推荐的则是Init事件。在Load事件的时候进行数据绑定。

解决：

既然问题的原因找到了，我们就应该解决它，现在关键就是在回发后PlaceHolder.Controls的子集数量为0，也就是没有子控件，也就是很明显地控件跑没了。那么我们就应该在我们在他们还在的时候将其存放起来。在经典的回发模型中，ViewState通过将所有控件/其子控件的各个属性字段等都存放到ViewState中了，在最后Render的时候都一并丢给了用户。数据包括数据状态都一并发到了客户端，现在客户点击了一个能够引起回发的按钮或者下拉框按钮，所有这些数据状态以及客户修改（也许没有修改，但我们假定客户篡改过了）的数据都传回客户端。因为回发发生了，因此在加载数据的阶段IPostBackEventHandler和IPostBackDataHandler接口所定义的方法（通常由服务器控件实现）都将被调用，然后就是一系列的数据回填工作。用户的数据又被重新做成了新的ViewState放在页面里面又丢给了客户端。我曾经用一个比喻（相当拙劣的比喻，当时好像不是这样比喻的）是白衬衫（花花公子正版）被蓝笔画后，送去洗衣店，人家新拿了一件一样的白衬衫（花花公子高仿），然后用蓝笔划了一下还给你，事实上白衬衫不是你原来的那件了，但看上去还是无法分辨。因此我们这里也可以用类似的办法来解决。但是真的可以吗？用ViewState不仅有众所周知的性能问题，因为ViewState的存储介质（其实是指它的内容存储，可以理解成持久层）是页面，而页面是指接受文本的一种载体（正如网页事实上都是文本一样的道理）因此会有序列化的问题。这就给用户控件的开发带来了极大的不便。更关键的原因是不仅如此，因为UserControl压根没有支持序列化，因此你的控件即使精简到没有字段方法（就声明了个名字够精简了吧）再加上序列化特性，只要你继承自UserControl，就必然面临无法序列化的尴尬。况且它的性能问题确实也很值得关注。和ViewState有类似性质的常见的还有Session和HttpContext.Current.Cache等缓存，或者自己实现一个静态字典用于存储也是一个不错的选择。用它们是可以解决问题的，在下面的代码中将会用到。但这样的方案事实上是存在很多问题的。大家都知道Session是有超时时间的，默认长度也就是几十分钟，而且Session也有诸多其他方面的限制，因此用它来做容量如此之大的控件存储其实是非常不适合的。HttpContext.Current.Cache是一个高级的缓存对象，因为有完善的内部机制来限制其膨胀以及管理其内容，但也正因为这种管理比如大小限制等原因会导致在生产环境中可能会遭遇严重的性能问题。缓存应该用来存取较小的常用的数据，比如用户名/密码这样的常用数据，而不是这种大个头的东西。但是与ViewState相似的性质让它们有了承担这份责任的义务。（家里的大人都死光了，孩子也只好来当家了）这让我们想到了存储介质，事实上磁盘文件，数据库等都具有了同样的性质。另一条思路是来自简单地加载思路，因为对动态添加的控件来说，它有一个很明显的特征，它是动态添加的。因此既然可以在按钮事件处理程序中添加，同样也就可以在页面初始化事件处理程序中添加。按照页面的生命周期动态添加最好写在Init这时候理应做丰富的添加（不过不适合那种需要用按钮添加的用户需求了）[另外一点有点郁闷的是在MSDN中也是说应该在Init而不是Load中动态添加，但是同样是在MSDN的《如何：以编程方式创建 ASP.NET 用户控件的实例》居然就用了Load事件来处理，因此这种区分对页面开发人员事实上并不是那么严谨的，事实上也不会出现什么问题，因此也就没有人吹毛求疵了，而且Google出来的答案估计90%以上都是在Load中写的，一传十十传百的结果可能这个数值还在上升，所以就更没必要计较了]。刚刚打算帮发邮件的兄弟直接找一个答案发现了有网友说在每个页面都要做判断搞加载，很烦很烦……所以如果您的需求不是那种追求打开一个页面两天后再来点一下要追加或则重新加载控件的朋友，我的方案还是可以考虑的。当然如果你比较追求那种近乎变态的需求或者您的页面和淘宝有一样大的访问量的话，不凡试试我的方案，更好的解释是，我的方案可以当作理解控件动态加载原理解释的一个入口罢了。

我的例子，因为代码比较多，我就贴出如何调用的部分（也就是“如何用”的代码）源码可以在后面的链接中下载。

扩展性：虽然是为我那位邮友给出的答案，但是还是考虑了扩展性，我们可以尝试扩展用磁盘文件、网络、或者数据库的方式来作为存储介质，当然，您必须为此实现部分接口。局限性，因为有存储介质一说，因此不同容器托管方面不允许同时使用多种存储介质，否则将会出现两个集合，因此就带来了另一个扩展性，您可以自行实现扩展存储之间的数据同步，不过做此之前提醒您一下，不同的存储介质可能存在不同的存储能力，比如Session有大小限制，而数据库简直就是容量大王，这些数据之间的同步可能会引发新的问题，另者就是这样的同步除了看上去很酷之外并没有什么好处，将数据乱存的结果可能导致程序显得混乱，更尴尬的是数据同步所白白消耗掉的性能。当然如果您只是练练手的话您确实可以这么做，做完记得告诉我一下，哈哈，我也想不劳而获。哈哈。下面贴一下代码就不多做解释了，因为如果你理解了上面这些，看懂那些代码就不可能有问题了。

    public partial class _Default : System.Web.UI.Page
    {
        public ContainerManager.ContainerManager cm = new ContainerManager.ContainerManager();

        protected void Page_Load(object sender, EventArgs e)
        {
            //重载控件(HttpContext.Current.Cache作为存储介质)
            cm.ReloadControls(HttpContext.Current.Cache, "PlaceHolder_DynamicUserControlContainer", PlaceHolder_DynamicUserControlContainer.Controls);
        }

        protected void btnInsertDynamicUserControl_Click(object sender, EventArgs e)
        {
            //Control c1 = LoadControl("DynamicUserControl.ascx");
            //PlaceHolder_DynamicUserControlContainer.Controls.Add(c1);

            int displayCount;
            int.TryParse(txtNumber.Text, out displayCount);
            if (displayCount == 0)
            {
                //追加控件(Session作为存储介质)
                Control c1 = LoadControl("DynamicUserControl.ascx");
                cm.AppendControl(this.Session, "PlaceHolder_DynamicUserControlContainer", PlaceHolder_DynamicUserControlContainer.Controls, c1);
            }
            else if (displayCount == 1)
            {
                //追加控件(HttpContext.Current.Cache作为存储介质)
                Control c1 = LoadControl("DynamicUserControl.ascx");
                Control c2 = LoadControl("WebUserControl.ascx");
                cm.AppendControl(HttpContext.Current.Cache, "PlaceHolder_DynamicUserControlContainer", PlaceHolder_DynamicUserControlContainer.Controls, c1);
                cm.AppendControl(HttpContext.Current.Cache, "PlaceHolder_DynamicUserControlContainer", PlaceHolder_DynamicUserControlContainer.Controls, c2);
            }
            else
            {
                //常见的动态加载控件后点击其他回发事件就导致控件丢失
                PlaceHolder_DynamicUserControlContainer.Controls.Clear();
                Control c1 = LoadControl("DynamicUserControl.ascx");
                PlaceHolder_DynamicUserControlContainer.Controls.Add(c1);
                cm.CacheControls(HttpContext.Current.Cache, "PlaceHolder_DynamicUserControlContainer", PlaceHolder_DynamicUserControlContainer.Controls);
            }
        }

        protected void btnUnloadStorage_Click(object sender, EventArgs e)
        {
            cm.Remove(HttpContext.Current.Cache, "PlaceHolder_DynamicUserControlContainer");
        }
    }

     园子里大牛很多，很多都是搞管理的，但是很少有分享管理经验的，我觉得如果能把一些管理分享给我们，那么做技术的会理解做管理的，做管理也更有经验。

     从毕业到现在，从开始做技术到现在既做项目管理也做技术，虽然没什么经验，但是可以提供些经验给没有工作过的朋友，我这里只是想开过头，希望大牛们能出来分享分享经验。

     今天我想说的是客户比产品更重要：

     我想很多一看题目可能立马觉得这个还用讨论吗？有的可能是坚决反对，我用两个亲身经历来说这个问题

   一、销售人员天天吹牛，我们是在看不下去了

        我们可能有时候觉得销售人员说谎不脸红，明明我们没这个功能，我们实现不了这个功能，销售全部都说没问题，甚至销售人员说的都是错的，我们技术人员看不下去了，如果你和销售一起做售前顾问，你可能是在忍受不了。但是我想说的就是技术人员都比较单纯，意思就是都是好人，不想骗人。但是如果销售人员也像你这么单纯，那么客户就没有了，因为客户也不懂技术，两个不懂技术的人更有共同语言不是吗？（举个例子，上初中时，我在老家，我给一个没上个学的老人说地球一直都在自转，他到处说我读书读出毛病了），有时销售知道是瞎说，是吹牛，但是如果不吹，客户连理你的机会都没有，然后找别人做项目了，你可能奇怪别人比你还差，咋都能接单，因为别人的销售更能吹，再加上技术人员一起吹，那单子基本上是跑不掉了。而且即使你没拿到这个单子，你失去了这个产品，但是你赢得了客户，他可能会买你的别的产品，或者在另一家把项目做出问题是再来找你， 因为销售知道客户比产品本身更重要。

  二：产品好坏跟我没关系，我只关心用你的东西能不能让我赚到钱，能不能提高政绩

       我们很多项目的客户直接负责人一般都不是“皇帝”，而是“和绅”，我接触过一个客户就说，你们的产品能不能运行是次要的，重要的是能不能在我负责时让我赚到钱，让我提高政绩，哪怕是你们的系统只是个摆设。所以我们在做产品的功能是尤其要注意这点，比如这个项目里有财务部，财务部负责你的这个项目，财务部管里一种商品，这种商品商品卖得多，他们提成多，那么设计产品是这个就是重点，怎么让买这种商品方便，量大（这里例子有一定特殊性）。

三：过度设计开发会让客户丧失信任

       有时我们过分向客户推荐自己的想法，认为这样这样会更好，产品做得很完美，但是客户根本不在乎你的那个功能，比如客户说设计一个搜索功能，显示所有产品，我没的开发人员就想给他做个排序、做个Ajax效果，然后还给客户说加点时间。客户就会很烦感（当然懂技术，懂用户心理学除外，但是记住我们的客户一般比较关注成本，就像我们买衣服，别人说我给你价格帽子，只要1块钱，我想你可能也不买了吧）。

四：“你应该这样才是对的”会让客户很反感

       我们很多人员老觉得客户脑子有问题，他怎么能这样做了，这样做不好，但是客户要那样做，我们为何不那样做呢，你觉得好的地方，那只是你觉得，比如我们想去里个平头，往那一坐，理发师说给你来个卷发吧，你越想里平头，他就说你里平头咋不好看，你还会在这理发吗？我想理平头的想法肯能酝酿很久了吧。

当然，以上某些可能只会出现国内的客户，国外客户可能不适用，只是个人理解，欢迎提出不同意见。

总之一句话，盯住客户不要盯住产品，产品本身不会给你付费，客户才会给你付费

欢迎转载，转载请说明出处

作者：王德水  http://cnblogsfans.cnblogs.com