理论正确不代表实践正确

在IT圈里面,尤其在blog盛行的IT圈里面,对风云变幻的市场,每个人都尝试做些解释,从而产生很多理论正确的表述。这种指点江山,看起来无比聪明的“理论正确”,或者说是“战略层面正确”的观点,却远不能保证“实践正确”。举个例子,我的blog,还有keso的blog,以及很多的创业者,或评论者的blog,就经常看到理论正确的表述。

还用一个以前打过的比方,这些文章对于创业者的指导作用,就像如下这几篇文章对于股民的作用一样:

论点一:

炒股成功,一定要低价买进,高价卖出。如果能够做到这一点,一定能赚钱。

论点二:

买股票的时间,一定要在低点。你看某家公司(youtube),就是在低点买入的,经过一年以后,成功的卖给了另一家公司(google),赚取利润颇多。

论点三:

找准股票的买进价格很重要,如果买的时候,它的价格已经在高点了,那么就很难赚钱。比如说这家公司,它买入的时候就是高点。。。

这些论点,绝不能说不对,因为这就是大实话,说出来,没有一个人能站出来反驳。但一个实际操作过程中的股民所面临的问题,不是要高价买进还是低价买进的问题(这个问题的答案显而易见),而他们要做的决定是:

今天(就在现在这个点儿)我应该买还是应该卖?

或者说,

这只股票,这个价格到底是高点还是低点?

这个问题,在上述文章中并不能找到答案。

到底这个点是高点还是低点,“理论正确”的文章中不做表述的,而正是这个实践上的问题,反映了一个股民的实战经验,决定了他能不能赚钱。

在互联网行业,有很多文章说:以用户为中心很重要。这话没错。但创业者遇到的问题是,有的用户说要加上这个功能,有的说不要这个功能。那么到底加上还不是不加上,哪个才是叫做“以用户为中心呢”

理论上的正确,说的是一种自然规律,如何适应这个自然规律,要的不仅仅是理论,更多是知识,经验,技巧,和能力。一个月以后,是个人都能告诉你一个月以前的股票当时是这一个月里面的高点还是低点,马后炮没什么了不起的,而我们毕竟不能看着后视镜来开车呀!

那天和李钟伟同学聊天,他就提到,在战略和成功之间,有一个重要的实际操作的问题。就是在细节上面,在具体的判断上面的一个一个决定综合起来导致了差距。打仗不但要有正确的方向,还要有每一个小的战斗都能打赢的部队。。。

所以说,如何从众说纷纭中找到什么是真正代表用户的声音,或者如何在每一件决定上面判断好这是冒进还是保守,就好似如何从历史红红绿绿的数字中间判断现在是高点还是低点一样,是执行的能力。这一点,就落入了专业人员探讨的范畴,也是需要学习的。高估了战略的力量而低估执行,和仅仅关注执行而不关心战略一样有失偏颇。

注:本文和众多的理论正确的文章一样,也是一篇没有什么实践指导意义的文章。最后一句话,就算是知道了,也要面临一个如何提高执行力的问题。这也就解释了,为什么很多很有道理的文章,看完了以后,除了点头称道以外好像还跟没看一样的原因了。。。

晚归

晚上8点,美中关系全国委员组织的美国国会代表团的来访。大约14个人在锦江饭店附近一直聊到11点,刚刚回来,有些累。

之后,老朋友白莉娟女士(Jan Berris)送了我本书,名叫:Collapse, How Societies Choose to Fail or Succeed。扉页上用花体英文写着:

July 6, 2007
To Wang Jian Shuo,
Who is always so helpful and who has so many interesting things to share.
US-China Working Group,
National Committee on US-China Relations.

这是我第三次和Jan一起来接待来自美国政府的官员,上一次是市长代表团,就在上个月,还有一次是去年六月,是美国知识分子代表团。。。

我们家宝宝叫王逸凡

上周给宝宝报了户口,名字就叫王逸凡。从众多的名字里面选出来,感谢大家的关心。

现在来解释一下这个名字和原来想的的几个名字。

其一:王乐凡

这是宝宝出生以前和他妈妈一起起的名字。孩子的名字多数反映了父母的期望。我们老实说不想给他太大的压力。我门对他的人生没有我们自己的规划,而希望由他自己的兴趣和好奇心引领,去自己发现。我们唯一的希望,就是希望他能够智慧和快乐。(其实快乐需要极高的智慧才可以获得。)只要他能快快乐乐,我们就非常开心。

至于凡字,其实就是平凡。我希望他懂得,快乐在平凡之中,获得也在平凡之中。至于名或着利,还有所谓的成功,其实都是过眼烟云,而只有每天用心的过的日子,才是人生最真实的部分。我们希望他懂得平衡的道理。小说里的,回忆录里的精彩的人生,在经历的时候,同样的东西就是是酸甜苦辣,甚至有时是百无聊赖。我希望他理解,平凡是人生的本质,而其他的喧嚣仅仅是装饰而已。

最后,因为乐是一个多音字,无论如何,只好不做考虑。

其一:王天哲

在我看来,这个世界上最美好的无外乎两者:其一曰自然,其二曰人文。自然是万物,所有我们看到的部分,给人美好的感觉的树,山,还有水。人文是人的内心世界,从几千年前的岩石壁画到现在的文学,艺术,科学等等。这个世界的美妙之处,逃不出自然(物的世界)和人文(精神的世界)两者。

自然界最大,最广博的,无外乎为“天”;(它比海更大,更深邃)
人文中至精华,智慧者,称之为“哲”。(它比文学更智慧,更恒久)

所以天哲希望小宝宝能够集自然和人文的最精华部分。

后来,我们还是放弃了。看着小宝宝熟睡的脸,以及睡梦中挥舞的小胳膊小腿儿,觉得不想给这个小蚕豆一样的精灵这么大的压力,起超过它能承受的名字。于是,后来还是回到了乐和凡的道路上。(还有的原因就是我们不喜欢这个名字的发音)

其一:王逸凡

逸也有快乐的意思在里面。同时,希望小宝宝对于很多的事情,不要那么在乎,只要自己快乐,并且知道自己要的东西,就好了。最后,我们觉得我们喜欢这个名字的读音,还有那种达观的生活态度。大家都说我和文峰都是那种挺上进的名字,为什么宝宝的名字不够上进。还有人说“男取《论语》,女取《诗经》”,应该有点论语里的那种感觉。我恰恰不喜欢孔子的思想,而更喜欢老子。来自的是大的道理。所谓“大道虐行”,而人自己的君君臣臣,父父子子的,仅仅是小道。在起名字的时候,我手里面一直拿的是老子-庄子的书。我总觉得老子和庄子是有大智慧的人。

注:还偶然间看到嘉庆年间,乾隆年间,还有1993年的王氏族谱的影印件。按照族谱规定,最近的王氏几代名字中的第二个字应该是:思 – 重 – 源 – 本。也就是我的名字按族谱应该叫王重硕(王氏第二十世),而宝宝应该叫王源凡(王氏第二十一世),而他的孩子在明朝的时候都已经规定了叫王本x(王氏第二是十二世)。。。而代数是从明太祖朱元璋时期的洪武二十三年(1380年)从山西洪洞大槐树迁徙至洛阳的那一代作为族谱的第一代。不由感叹历史的“源远流长”。不过后来放弃了按照族谱起名字的想法。

社会责任和慈善是两个概念

Jack经过一番沉寂,再次推出惊人之作:ppdai.com,一个基于P2P的小额贷款社区。

今天在信里,Jack提到:

这种情况下,该不该借钱? [真实]
我昨天接到一个电话:

母亲住院,需要一笔钱(不多,几k),贫困,还款能力差(月收入800);
我让他带尽可能多的信息过来公司:身份证,户口本,工作合同等;
在网上找到我们的;

我很为难:
1. 是不是骗子?
2. 不是骗子的话,还款能力太差?还不出怎么办?
3. 如果不借的话,是不是将来会后悔?

请帮助一下同样无助的我。这种情况下,我应该怎么做?

我的一点拙见:

这个很难办。我觉得一个金融促进机构(就像ppdai)不应该把过多的社会义务揽在自己身上。是不是借钱,最主要的依据是有没有偿还能力,而不是这笔钱做什么。所以我认为不借。

至于如果有实力建立一些风险基金,就是给偿还能力很低的,但是的确需要钱的如是群体,同时预测这种贷款的坏账率会非常高,并做相应处理,也是不错的举动。但把商业和慈善混起来做,不是什么好主意。

其实,我觉得任何一个商业公司都要有社会责任感,就是商业的活动本身应该有益于社会的进步和发展,对环境友好,对员工,顾客和股东有价值。这是不容置疑的。但社会责任不等同于慈善。两者都是应该做的,但是目标不一致。一个是已持续发展为目标,而另外一个是以付出和回报为目标的。

互联网应用平台的关口

我们现在的编程工具就处在一个关口

在这关口之前的二十年里,竖立着一个成功的编程工具:Microsoft Visual Studio(以及它的最初原型 – Visual Basic)。这个可视的集成化的编程工具把一代的程序员吸引到这个平台上面并且帮助微软确立了PC机世界的霸主地位。

而在今天的这个关口出现的时候,眼花缭乱的新工具冒泡一样的出现,但就剩最后一步,仅仅一步,就到了这个关口了。

比方说,我们看到了YUI (Yahoo! User Interface),它提供一些简单的控件 – 比如按钮, DataTable菜单。。。。

如果大家还有印象的话,当年的Visual Basic就是拉着程序员们的小手,从画第一个窗体,第一个按钮开始,一步步引领他们进入Windows的世界的。Java Applet最初不也就是这么几个控件吗?这个基础已经在那里了。Yahoo! 下一步需要的,就是一套更加简单的,图像界面的编程工具

在这个关口前,我们也看到了Google Web Toolkit。看看这个Hello World,看看这个完整的,再看看这个复杂些的,你会发现,基于Web的一个新的平台已经呈现,Google下一步需要的,就是一套更加简单的,图像界面的编程工具

再看看百花齐放的各种各样的Framework,比如这个script.aculo.us还有这些AJAX的,这些所有的创新,基本上已经把一个新的世界的样子描画出来了,他们作为一个整体需要的,就是一套更加简单的,图形界面的编程工具

如果还要我举出更多的征兆,就是Facebook的F8开发平台,Amazon的AWS开发平台,以及几乎所有Portal都有的Widget开发平台(微软的Google的…)就明白无误的告诉我们,一个新的以互联网为平台的已经逐步形成,给应用程序铺设的舞台已经开场,但是缺的,还是一个更加简单,图形界面的编程工具

所以,在这个关口,我相信在不久的将来(应该就在3个月以内),各大厂商一定会推出自己的类似Visual Studio的开发平台,或者成为集成开发环境(IDE),这个IDE会有以下特征:

  • 运行于互联网之上(就像它生成的其他任何程序一样)
  • 基于拖拽的控件(你可以把一个Button拖到网页正中间,并且双击它就可以编代码)
  • 所有的互联网服务都以控件的形式出现在IDE里面(比如搜索或者Fackebook, Flickr)
  • 最终生成的应用程序可以直接保存,运行在IDE厂商的平台上。(或者就是由IDE的厂商提供hosting 平台,大家可以通过URL来运行这个应用程序)
  • IDE市场的争夺战会异常激烈

谁赢得了这场IDE的争夺战,谁就有了下一代互联网霸主之争的入场券。

其实我很为微软扼腕痛惜。群雄纷起,都虎视眈眈的盯着微软最牢固的平台还有开发工具生意的时候,微软还没有做出像样的动作来。ASP.NET和C#真的是早出来7年,出来的太早了。当最近这些基于AJAX的控件把客户端和服务器端彻底连接成了一个密不可分的整体的时候,微软的开发工具就显得风韵犹存,又老态初现。风韵犹存的意思是,在7年前就已经把一个控件(比如button, Textbox, DataGrid)既当作客户端控件,又当作服务器端控件,在所有的编程思想中明显的处于有前瞻性,即便在今天也是了不起的思想,但我又说它老态初现的原因是,毕竟每一次客户端的操作,都需要HTTP的Post-Back一次,与异步的JavaScript+XML的架构相比,就显得如此的笨拙和不合时宜了。一个刚刚出现7年,还没有普及的产品就这样过时了,真的让人惋惜。

好久没有正儿八经的写程序了(最近都是sample code级别的)。最近也没有太多时间(想象一个刚刚当爸爸的我会有多么忙碌),但是我打算这个周末,花上两个小时,写一个这样的雏形出来,尝试一下这个互联网的IDE的想法。仅仅因为我相信,这样的产品,在三个月以内一定会隆重推出,至于是微软,还是Google,或是刚刚换了CEO的Yahoo!就不得而知了。

读《胡适留学日记》

门口有一家沐风书店,办了卡可以一次借两本书来读。

今天又去还书,把育儿的和金融的换掉(Wendy坐月子,出不得门,总托我帮她带写书回去,我就像信使一样,在书店和家之间跑)。

这次拿了本《胡适留学日记》。颇为惊奇。从一九一一年到一九一七年的时间,记日记的时候天天一篇,还有很多篇幅挺长,思想很深刻的。想来如果当时立刻公布,他算是最早的blogger了。里面还没有读,最主要是想看一下这位blogger前辈写些什么,想些什么。

在一九三六年日记出版的序言里面,胡适先生提到:

Expression is the most effective means of appropriating impressions

。这和我用写blog来逼迫自己每天都思考些东西有一样的初衷。

后记:看到在1911年胡适在康奈尔大学读书时的几乎每一篇日记都以“上课。”开篇,读给Wendy听。她说:如果小宝宝现在写日记,每天一定以:“吃奶。”开篇。

技术培训纲要

粗略的记录一下上一个月的技术培训纲要,以免过几年自己忘了。

本文档面向的读者:仅仅我自己。

技术的世界:

  • 代码基础层,就是PHP基础,面向对象基础
  • 数据层,就是封装数据访问对象,数据访问对象层等
  • 页面层,就是控件设计,Data-Aware Control,安全控制等等
  • 规则层,就是事件机制设计,异步处理机制设计,以及任务调度层
  • 表现层,主要包括CSS初步,JavaScript以及AJAX等
  • 架构层,就是高性能,高可用性网站架构及微调
  • 开发流程和团队协作,包括每日编译,代码控制,早例会,功能规格书,实现文档,Code Review等
  • 运营层,主要是运营的框架和流程。

其中代码层,主要参考MovableType的数据层的架构和众多OOP的思想。客齐集的核心数据层代码,用PHP写在200行以内。

页面层,最主要是对于页面的所有逻辑进行封装,比如URL,Page等。其中的控件层的设计可以参考ASP.NET。但是ASP.NET的Framework在它出来的时候,众多新的客户端,尤其是异步JavaScript调用还没有成为主流,所以postback的方式现在显得有些过时。所以我们写的Framework要改进ASP.NET的很多做法。但是,借鉴了ASP.NET team原来的一些思想。这一部分也控制在200行代码左右

还有CSS借鉴了YUI的reset->font->grid->control的四层架构。JavaScript层会借鉴Prototype和YUI的一些设计,但是会更加轻盈一些。

架构层主要是以LiveJournal.com的架构为框架,并且付诸于Flickr.com对于分布式文件系统的想法,在前层假设分布在6台机器上的分布式内存缓存,用统一的一个上G的内存当作主要数据存储区,降低数据服务器压力(理论上会降低到5%-10%左右)

开发流程最主要是采用简化版的MDMF(Microsoft Development Management Framework)(这个名字还是在2001年高鹏和我一起起的名字,前几天居然在很多资料上面看到大家提及这个框架)。这可能是我带过的第五个开发团队,这个流程已经很熟了。

运营层最主要借鉴Microsoft Operation Frakework (MOF)之事前文档,事后文档的架构。

最近看的一些文档在这里

坐月子的规矩

Wendy在做月子。中国的规矩中,坐月子的规矩算是比较多的。传统的不可见风,不可出门,不可下地,到南方的不可洗澡甚至不可喝水(只能喝粥),随便谁都可以列出一大堆。在这些即便本身都相互冲突的规矩中,何去何从是个棘手的问题。思前想后,对比研究,得出以下结论。

传统坐月子方法不能说错,但过于笼统

就拿不可碰水为例。准确的说,产妇身体虚弱,不可见风的确是事实。无论中医说的“血不足,气亦虚”到西医说的“身体毛孔张开,温度调节功能不好”,都印证了的确不可以碰冷水。但是如果说绝对不可以碰水,不可以洗澡就过于笼统。准确的说,应该是不可碰冷水,而不是都不能碰水。

不过在这里打住,不可以碰冷水这句看似更准确一些的说法,也过于简单。就算可以碰热水,也有很多不同。我猜测不同的体质,对于水的要求也会有些不同,同样的体质,或许时间不同,要求也不同。总之,需要按照个案对待,而笼统地说一概不能碰水,就太“通用”话了。

口口相传的传统

传统就是传统。传统是口口相传的。口口相传的特点是,只有最简单,最笼统,最容易记住的才容易传播。我们常做的拷贝不走样的游戏就告诉我们,一句话从第一个人口里口耳相传到最后一个人耳朵里,一定走样。而且走样的方式,常常是丢掉其中的细节(比如条件了,形容词了),而仅仅留住最简单,最扩大话的那部分。

人们总想用简单的回答,比自然本身简单的多的回答,来应对复杂的自然。又要简单,又要正确,似乎唯一的答案就是扩大化。不能碰水绝不能说错,但是没有必要扩大化的给产妇增加了很多的限制和痛苦。

我们假设(仅仅是假设)自然规律是在中等的体质在产后23天里面不宜总计超过1分钟接触温度底于30摄氏度的水(仅仅是假设,实际上的公式和描述应该是有一本书来写),那么经过几百年流传下来,就一定会变成不可见水。所有的细节都丢失了,就变成“老规矩”了。

这好像我记得在100年前发现血有不同的类型之前,医生对人和人之间能不能输血的问题吵得不亦乐乎。有的输血可以救命,有的输血立刻死亡。如果不做更深度的分析研究的话,八成“决不可输血”就成了老规矩。而自然的真相是,血型相同可以输血,不同不可以输血。。。

大道虐行。自然界的规律,无论人认识还是不认识,都几万年不变的运行着。所有的人总结出来的规律,都是希望尽可能接近自然规律。而简单化是这种接近的天敌。

南浦大桥早上不是堵车

每天早上开车通过南浦大桥,要从杨高南路的转盘的引桥开始,到汇入龙阳路,直到进入南浦大桥得主桥面。这一路大约2公里,在过去的三年里面的每一个早上,几乎都是以10公里每小时的速度挪动。我和Wendy三年做了上千次梦,就是希望“南浦大桥今天不要堵车”,结果都是失望告终。

每天早上都没有任何交通事故,为什么就不能走得快一些呢?

这两天自己做了个简单的计算,得出结论,这不叫堵车。这个大桥就是这么设计的。

在主桥面上,有三根车道。而在浦东方向汇入主桥面的,有10根车道。分别是如下:

直走的,是三根龙阳路的车道(A)。从杨高南路南向北方向汇入一根车道(B)(实际早上一直是一条用作两条),从杨高南路北向南方向有两根车道(C)。C先和B汇成两条,再汇成一条,并且和A并入形成最后的三条。

之后,在前进不到一公里的主桥面上,从浦东南路北向南过来的两条车道先并成一条,浦东南路南向北方向的两条车道,也先并成一条,两条车道经过一个夸张的空中U字弯,在进入主桥面前再汇成一条车道(已经是4并一了)。

这时龙阳路上来的三条车道先并成两条,再和浦东大道过来的一条,一起成为南浦大桥桥面的三条车道。也就是说,来自龙阳路,浦东大道,杨高南路三条大道的10条车道,在主桥面变成3条车道。

再看一下主桥面的限速 – 60公里每小时。而在浦西方向的三个圈上面的限速是40公里每小时(当然,这个没有人遵守过)。我们以在主桥上面的60公里每小时的标准速度(多数时间还达不到)来计算,进来的10条车道的平均速度应该是 60*3/10 = 18公里每小时。再加上车辆汇聚时候的双发减速(这导致了南浦大桥上的车距明显过大,导致道路利用更加不足),在10条车道的速度,显然正常情况下还达不到18公里每小时。

在南浦大桥引桥方向压力不大的情况下,还可以保证有效通行(通行能力的要求随着车距增加而减少),但是一旦早高峰10条车道中的多数或全部开始有车辆积压(就是饱和情况),就会出现我们早上出现的“堵车”状况。其实,这不叫堵车,而仅仅是饱和状况的设计时速而已。

注:如果更加刨根问底一下,假设多车道交汇的时候平均分配通行能力,并且主桥面60公里每小时的话,浦东大道上来的引桥的设计时速是:60/4 = 15km/h,而龙阳路应该是 60*2/3*2/3 = 26.6km/h,而我过来的杨高南路南向北方向就应该是:60*2/3/3 = 13.3km/h。换言之,从设计角度,通行速度最快的应该是龙阳路方向,其次是浦东大道方向,最慢的就是我走的杨高南路方向了。这和实际情况大体相符。

注:本来还想翻一下MIT OCW的关于道路交通设计的资料,后来想了想,就自己一个外行瞎想一下,让大家来看看就算了。

《旅行的艺术》是本好书