最近 Apple 和 Adobe 之间因为 Flash 的支持与否，口水仗打的比较热闹。个人愚见，苹果公司做出当前的选择应该不是因为乔布斯要逞一时口舌之快，相信是内部自有 iPhone 以来的长期评估后做出的选择，苹果公司从战略层面甚至会把 Adobe 看作竞争对手而不再是重要的合作伙伴，而谢绝 Flash 入内，是一个非常精明的借口。

之所以说二者是竞争关系，关键字还是在于"平台"。Adobe Flash 是当前业界占有率最广泛的一个技术平台，甚至超过大家想当然的 Java 。根据 Adobe 的统计，Flash Player 占领了 99% 可上网电脑设备，有超过 200 万专业用户在使用，这里的专业用户应该指具备一定开发能力的用户，依托于 Flash 的应用程序数量已经相当的惊人。所以，是否在 iPhone 、iPad 上引入 Flash 的支持，从苹果的角度看，这是平台之战，谁也不想引狼入室。我们设想一下假定 Flash 已经得到了苹果公司的支持，那么 Adobe 可以一转身也建立一个 "Flash App Store" 或者类似的东西，开发者可以用上传的小应用，任何平台的用户都可以下载使用。想想对苹果的冲击会有多大? Adobe 或许还没想好如何也建立一个 App Store ，但不排除将来会染指这一块业务。

苹果公司长久以来不太有"开放"的态度，或者说是"封闭的开放"，最希望通过自己封闭的环境，让用户通过圈下来的地建立一个生态圈子，不想和其它公司一起合作。乔布斯回归后，通过激发用户对 iPod 喜爱与信赖，进而购买使用 iPhone ；通过 iPhone ，进而使用 iPad ；通过 iPad ，再回去使用 Mac 。这是个非常好的封闭循环过程。开放，会丢掉利润，而封闭，才会让苹果公司有更大收益。当然，我也想说的是，对 Flash 的支持友好也的确有可能让 iPad 在某些方面导致平庸，比如性能。与之类比的是 Firefox ，现在速度问题广为用户诟病，而这问题基本由插件导致的，现在 Chrome 尽管足够快，但随着扩展日益增多，必然重蹈覆辙。

现在乔布斯游说内容提供商加入他的 iPad 阵营，而他之所以敢批评 Flash 的不足，也是因为还有另外的技术路线可选，那就是 HTML5 。但是有多少内容提供商会舍弃 Flash 而加入 HTML 5 的阵营，这个还需假以时日才能看清楚。换做另外一家公司，来自用户的呼声可能都会受不了，对于苹果来说，我行我素是一贯的风格，乔布斯一直是个精明的商人。

是否会在 iPad 上看到 Flash ? 将来或许会，但是这要在乔布斯开给 Adobe 的条件都得到满足的情况下才会出现(没错，这两家现在或许已经在谈判桌上了)，这些条件当中，除了解决当前的性能和稳定性问题(这个问题并非原则上的问题)，最重要的是 Adobe 不要与苹果有商业利益上的冲突，苹果一定要得到某种承诺，而这，对于 Adobe 来说，也会是艰难的选择。

--EOF--

注：春节期间构思此文，一直没发出来，后来发现有不少人也持类似观点，澄清一下，并非拾人牙慧。

说起平台，国内 360 安全卫士尽管已经取得了惊人的装机量，进而推的浏览器和网址导航也都立竿见影，但是还难脱"工具" 的影子，还是不能形成技术生态环境，我相信不会有类似 "360 平台" 的产品出来的，不是不想，而是做不到。

Sun(Oracle)公布的 Java 在桌面机有 8 亿。

春节前已经看了一遍这本 《苹果往事》，假期又看了一遍。对于这段苹果公司并不鲜为人知的历史来说，这本书从一个亲历者的视角给 Mac 的诞生加了一大段注解。这也是苹果拥趸者最喜欢看的内容。

彼时的乔布斯，恰似刚受封齐天大圣，自信无所不能，被排挤到 Lisa 项目之外意味着他将来没有权利说这是他设计的产品，所以最想做的事情就是找个项目来证明自己。他对于 "自己参与设计" 的项目无疑是寄予厚望的，也给予了足够的支持，否则这个从概念项目起步的团队也不可能发展起来。对于这个团队的多数人，他们要研发的这个产品，不为名不为利(实际上也只有少数几个人得到了名利)，更多的是创造性工作给自己带来的成就感，什么是激情，或许这就是。

对于 1984 年苹果推出的 Macintosh ，现在来看，或许是那个寓意深刻的广告更为令人津津乐道。当时的 Macintosh 只能算是杰出的电子艺术品，是否是成功的产品很难定论。毕竟从市场表现来看，没有给苹果带来像 Apple II 那样的辉煌。这个产品的推出从某种程度上也间接促成了乔布斯被赶出苹果。 是苹果公司发展历史上的一道分水岭。如果没有当初，或许也不会成就现在的乔布斯。现在的 Mac，其实无法让人等同于 1984 年的 Macintosh...我相信只是有些精神会延续下来...或许这样就已经足够了。

在这本书的最后， 作者 Andy Hertzfeld 感伤 "我所渴望的理想麦金托什团队模式已经消失了，融入了那种我们以前常常取笑的大型组织当中，内部充满官僚障碍及人际摩擦"。曲终人散，这个团队的大多数人都将不再服务于苹果公司。这也是那些非凡团队成员的普遍命运。

阅读这样一本书，对我们更有价值的事情从中学习那些经验和教训，关于人，关于事。让人欣喜，让人心酸。

--EOF--

虽说年底是 IT 事故多发的期间，不过这次民生银行系统瘫痪事故还是让人觉得有点严重。事发 2 月 3 号，从上午11:00到下午15:30，故障持续四个多小时，全行系统瘫痪。对外称是"核心系统维护"。

个人之所以比较关注这个事故，是因为新闻标题中的"数据库维护失误"。据说是"由于数据系统进行维护时出现了失误，造成宕机"。开始的时候，大家把关注的焦点放到灾备切换与否的问题上，据说是"没敢切换"。初看上去倒是有点像 DBA 误操作。有人说是和时间服务器有关，我错过了讨论现场。

也有朋友在 Twitter 上说：民生银行上周的系统宕机事故，源于IT部门某应用系统数据库（应该是 DB2 Informix，数据库版本老旧，且无正常维护服务），一个应该在夜间处理的长任务，运行到银行开门也未结束，该系统正常时的CPU使用率就已经到达70-80%，长任务从夜里一直跑到上午无法停止，把本来就不堪重负的业务系统拖慢到不能忍受，由于数据库版本 EOS (End of Service) ，无厂商实验室的工具支持无奈之下，要求重启相关系统，结果造成业务停止。事件的(后续)处理还在进行中。(via)

上述说法看起来比较可信，也足以解释为什么不切换到灾备上。如果因为计算能力的不足 (或是系统性能问题) 的话即使是切换也无济于事的。民生的旧系统是 SAP 核心，实施方是埃森哲(refer)。不过，"民生银行打造的新核心系统已经开发完毕，目前处于内部运用的阶段，今年上半年将会在全公司上线"，估计到时候能稳定点?

另外看到有网友说，2008 年初，民生银行的的小额支付系统也出过严重问题，由于操作失误或是程序内部控制原因，造成了几百万的重帐。

涉及到钱的问题总是让人如履薄冰。根据我个人亲身经历过的一些事情来看，事故发生后，更多的时间都会花在决策上，而一旦选择错误或者不是做出最优的决定，灾难才刚刚开始。

--EOF--

有朋友后续补充到：2010 年 2 月 12 日上午 10:25，民生银行的信用卡网银不可用，返回 HTTP 500 服务器内部错误，网站上并没有相关的维护计划，咨询客服，说是系统维护升级。整个民生的 eBank.cmbc.com.cn 都是无法登陆的状态，看来"维护升级"的不只是信用卡网银，自2月3日以来，不到10天又发生状况。

且说前一段时间听淘宝的黄裳讲解淘宝网站架构发展的时候，说起 2004 年底淘宝为何从 PHP 向 Java 转移的事情。为何转换，他阐述了几个理由，其中一个是非常有趣的：当时的 PHP 缺少一个 IDE。而合适的 IDE 能够有效提升规模化软件开发的效率。

我们知道 eBay 在 2002 年的时候也在 Sun 技术团队的帮助下，将整个应用架构从 C++ 迁移到 J2EE 。也就是 eBay 内部所说的 V3 版本(refer)。

最近一件有趣的事情是，据说腾讯的财付通在招聘 Java 方面的高手，"参与系统架构选型"，要把底层架构从 C/C++ 迁移到 Java 架构上来。另外，百付宝的后台技术据说也是基于 C++ 的(最开始的时候只是一两个人写核心代码）。我相信，现在百付宝或许规模还比较小，总有一天，也要面临向 Java 的迁移。这和阿姆达尔定律有点类似，要得到更大的计算能力，就要尽量减少整个系统中的非并行的环节。只是一两个人能搞定的地方，再加入更多的开发人员也是无济于事的，除非，改变协作的模式。

去年接触到的一些国内的电子商务公司，有些已经在进行技术架构上的变迁，当然，多数是从 Windows 平台迁移到 LAMP 平台，究其原因，也无非是成本与效率，而后者，更为大家所看重。当然，也有一些顽固派，比如京东，仍然固守原来的手工作坊技术模式。

如果单兵作战的话，很多程序高手会说，"用什么语言都是无所谓的"。但是如果是团队协作开发的话，用什么语言，影响则是不一样的。对于电子商务网站来说，语言的选择意味着不同的架构路线、不同的开发框架、不同的测试框架、不同的部署流程，最后更为主要的是不同的开发效率，意味着可以把更多的开发资源并入到当前的环节中。

事实上，对于一个高速发展中的网站，每隔18 或 36 个月，几乎总要有一次架构上变革的阵痛。没有这种变革的勇气，意味着以后也不会有人敢做这个尝试。没有这种阵痛，就不会有成长。

变化的节奏最后影响一切。编程语言的选择并非无关紧要，短期看来似乎影响不大，从长期来看，决定最终的竞争结果。这就是我要说的。

--EOF--