2009年03月30日

返老还童,是一部沉闷的艺术电影。

这种电影,可能也只有美国人拍的出来,在探究人性的同时不忘了科幻。

和“返老还童”相比,这部电影的英文名字实在是乏善可陈,The Curious Case of Benjamin Button。

故事讲的是,一个人生下来,其外貌就已经七老八十,随着岁月的增长,这个人反而越来越年轻。

其实,看完这个电影反而让我更纠结:

1、通常,一个人的智力和一个人的生命力成正比,但如果成反比,会是什么情况?真像电影描述的那样吗?

2、无论是智力和生命力成正比还是成反比,30-35岁是一个黄金年龄,在这个时段,一个人的生命力和智力得到了最佳配比

正是这个电影没有回答我的疑问,所以再多的文艺青年说这是一部好电影我也无法认同,尽管从概念上,这部电影似乎在解释一个叫做轮回的概念。但归根结底,这部电影能够解释的只是外貌,没有回答心灵。

这部电影其实讲的是,一个人生命力垂老,但心智年轻,一个人心智成熟,但生命力垂老。当然无论是开始和结束,最后两者一起归零。我在想其实不应该这么编剧,正常情况下,当你生命力增长的同时,你的心智同样成熟,当你生命力下降的时候,你的心智应该越发成熟。所以,故事的意义在于如果有机会提前体验人生的话,其实没有必要犯下如此多的错误。

所以,这部电影仅仅是科幻而已。非要找到什么答案的话,只能从换位思考的角度切入。让你还年轻的心灵,体验一下生命力沧桑的感觉,让你已经生命力衰竭的身体,看一看是否能注入生命延续的心智力量。

2009年03月17日

看了《生死朗读》,太郁闷了。我是个泪点比较低的人,看《集结号》、《兄弟》上都能哭的人,如果你的泪点也比较低,最好自己独自一人看。

很多人忽悠这部片子让我以为是部三级片,说实话,上半部确实像。但到了上半部结尾左右在法庭上Machael听到henna的声音的时候,就需要准备纸巾度过下半场了。

从人生经历而言,我这一辈,虽然也有一九八九的成人礼,但基本上没有沟沟坎坎。我的父辈,也侥幸逃过了上山下乡,作为文革前的大学毕业生,他们经历的残酷远远小于我的叔叔、舅舅、姨父。能够和《生死朗读》相比的年代,是我们的爷爷辈了,也就是8年抗战的日子。老舍先生的《四世同堂》是一个经典,我这个年龄的人很多只是看过电视连续剧,我强烈推荐你们看一看原著。

《四世同堂》有一个经典的背景,老舍借祁老爷子表达的:没有想到我们要挺过8年,没有想到我们要付出如此的代价。以前,英法联军怎样、庚子年八国联军怎样,北平还是那个北平。

同样,就是能写出这样潜台词的老舍,运动一来,就投了湖。

anyway,《the reader》最后想表达的是什么,一千人恐怕有一千种解释,这才是艺术的魅力。我想表达的其实也很简单,看一看,哭一哭,想一想,你的人生可以不识文断字,但要follow my heart;你的人生已经识文断字了,更要对得起基本的道德价值观。虽千万人,吾往矣。

2009年03月12日

虽然在donews blog里的回复不太踊跃,但在5gme.com的交互更直接。总体上看,saas对很多人仍然是一个很奇妙的东西。

上一篇blog已经定义,saas的本质不在于拥有,而是享受。具体就软件来说,是从以往的许可证买断模式过渡到按需购买的服务模式。

延展的话题是我最近遇到一个相当smart的老板,他的逻辑其实很简单:

1、这件事情是否是你的核心竞争力,如果是,你砸锅卖铁,都要自己上,历经千辛万苦在所不辞。

2、这件事情不是你的核心竞争力,你没有必要自己做,但如果市场上的供应商,不能提供靠谱的服务,你还要DIY。

对企业管理软件而言,MRP、MRP II、ERP、CRM,这些术语定义了一些标准的管理办法,几乎每个企业都要面对。当然你可以选择标准的软件,有钱的可以考虑SAP或Oracle,没钱的或者希望本地化的可以选择用友或金蝶、但本质上,你得到的是一样的工具,除非你比别人用得更好。从这个角度上说,所谓最佳业务实践是最不靠谱的事(好像SAP最喜欢谈这个概念),但凡出得起钱买软件也出得起钱雇顾问公司的人都最佳实践了,哪里来的最佳?

换句话说, 你想干什么决定了你的选择,如果你只想和你的用户搞好关系,建个社区,架一个Discuz!的社区足以,如果你把你和用户的关系看做生意的核心,你不仅要有能力做一个类似facebook的SNS,还要开放API弄成一个平台,然后让比你更弱小的人帮你做应用,为你打工。

所以,能够saas的一定是鸡肋,真正核心的东西,一定要自己掌握。当然,如果我们假设IT、互联网、管理软件的价值等同于几十年前的电力、基本通讯,那么,就没必要庸人自扰之,直接拿来主义就可以了。就像今天再小的一个社区超市,也会购买一个别人的pos系统,因为他们的核心竞争力在于社区、在于服务而不是在于系统。

2009年03月05日

感谢开两会,让外地和政府的车都歇了。晚上7、8点的四环,稀疏的车距支持不并线就可以踩到120。一来一往节省了20分钟,用来写几句blog.

最近工作需要,找了一些国内计算机媒体上关于saas(软件即服务:software as a service)模式的评论,发现很多人的讨论基础和水平仍然停留在10年前,言必谈安全性和服务水平。其实,这是一个伪命题。

saas本身是对十年前的ASP(Application service provider)概念的继承扩展,其本质上说用户不必要购买软件包,而是直接使用互联网服务。当然,今天的saas又被加进去SOA、云计算等光环。Saas的好处显而易见,所以,一说saas,尤其是想说saas的缺点,总是谈安全性、服务水平、网络传输,但其实,这是一个伪命题。

很多人,倾向于认为这个东西如果掌握在自己手里,必然比掌握在别人手里靠谱。原则上,没错,但判断到底应该怎么做,还是要用数据说话而不是搞出身论。如果说到安全和服务水平,就看看平均无故障时间好了。前几天google gmail故障了4个小时,大家显得很兴奋。其实,想一想,如果公司自己运营mailserver,要花多少线?每年会发生几个故障4小时。原来我在一家软件公司,即便有庞大专业的维护队伍,每年工作KPI制定的指标,在邮件这一项,允许的故障时数也是按天计算的。

这个世界总是有极端事件,比如地震、比如海底光缆故障,这些都是小概率事件,所以总体上看,如果世界上存在靠谱的供应商,对大多数人和企业,采用购买服务的方式总会比DIY更有效率。

而且,系统崩溃就是系统崩溃,这是客观现实,我知道就是google或者amazon、salesforce也避免不了。同理,难道自己运维就不会系统崩溃了?在目前看来,差别只是在于,自家运维的系统崩溃了,你可以惩罚或fire一些人,而google或salesforce崩溃了,你没什么地方可以出气。但无论是对系统而言还是对业务而言,崩溃的结果是一样的。