作者文章: Fenng

编程语言的选择并非无关紧要

且说前一段时间听淘宝的黄裳讲解淘宝网站架构发展的时候,说起 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

此文作者:, 位于 Review 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

大象跳舞

最近看了不少以前不愿意看的书,《谁说大象不能跳舞?》是其中之一。这是一本教科书,讲述的是如何挽救一家走向衰败的大公司。

所处的位置不同,不同的人阅读这本书会有不一样的体会。给我印象最深的是郭士纳初入 IBM 所采取的策略,”我们只有很少的时间用来找出问题,大部分时间、精力和关注点都将用于解决问题和采取行动上。”

问题本质

新的 CEO 上任之前从众多人的建议中就已经抓住了问题的本质(收到众多建议的时候如何过滤重点?):IBM 不缺乏能人和天才,公司也不缺致胜战略,新领导人要从”战略”和”文化”等方面推行改革入手。这个改革,体现在具体行动上,是后面的”热烈拥抱”计划,说白了,也就是”拥抱用户”,倾听用户的声音,解决用户的问题,赢取客户信任。然后才是财务方面的止血,最后才涉及到远景规划。能从千万重关系中抓住这些关键点,这是核心能力的提现。

对待人才的策略,也就是如何对待现有管理层,郭士纳也是自有一套。在第一次会晤管理人员的时候就主动传递了这样的信号: “IBM 历来是个人才济济的地方…只有如果有必要的时候,才会从外部引入人才”。但是我相信,这样的策略恐怕只有针对 IBM 等少数公司才会有效。多数公司不能照搬–如果问题的本质抓不住的话。(实际上,郭士纳后来还是招聘了不少曾经和他合作过的管理人员进来。)

对于这只管理团队,也不是真的没有问题 ,当时的 IBM 比较严重的官僚气是存在更多关心公司内部部门之间利益争夺而不是关注竞争对手的情况。任何一家大公司都会有既得利益者,这一点大家都会有共鸣吧。

“大象跳舞”

这本书的书名有多重隐喻。其命名或许和 TIME 杂志的这篇 Can This Elephant Dance? 有关。”大象跳舞”是什么意思? 对于 IBM 这样的庞然大物来说,跳舞意味着优雅、协调,意味着摆脱笨拙。而一旦大象能够做到以这一点,那么竞争对手自然不足为惧,因为问题来自自身而不是外界。

“Elephant Dance” 应该是个证券行业常用语,大致是”大盘股活跃,反复上涨”之意,从这个角度上来说,郭士纳也做到了,IBM 股价在他的任内也是一路上涨。

EOF

乱翻书,不求速进,但求有所得。

从 7-Zip 的预设格式说起

在 Twitter 上看到笑来和几个推友说起关于提供下载为何不用更通用的 ZIP 文件格式而用 7z 的格式(refer)。这个倒是挺有趣的话题,刚好我也是 7-Zip 的用户,对这个不习惯也由来已久了,也一直不喜欢这个方式。

7-Zip 的默认压缩文件格式为”7z” (扩展名是 .7z) ,就是这个微小的差异给用户添加了很大的麻烦。设想一下,你用 7-Zip 压缩了一个文件,扩展名为 foo.7z ,传给了你的朋友(非IT人士),而你的朋友用的是 WinRAR,这是压缩软件市场上的主流,他看到这个格式之后,他会如何反应? 换个应用场景,如果一个普通用户,从网络上下载一个软件,下载完毕之后发现默认没有软件能打开这个 .7z 为扩展名的文件,他会如何做?

必须要承认,7z 压缩格式有很多优点,而 7-Zip 是个很好的压缩工具软件,但在预设格式上的这个事儿,不折不扣的是在挑战用户习惯。或许有人支持这样的做法,一个支持观点是 7z 格式压缩比更高。这是个很好的理由,不过,那么一点点的压缩比收益,考虑到当前个人用户所用设备的存储能力以及网络支撑能力等,对于单个用户来说,无法抵消使用习惯带来的麻烦。除非全世界都是 7-Zip 的用户,很可惜,现在的 WinRAR 仍然是市场绝对的主流,而 Zip 与 RAR 格式也是事实上的标准。另一种支持观点是现在所有主流压缩软件都支持 7z 格式了,所以使用是合理的。的确,主流压缩软件可能支持了 ,但是,绝大多数计算机用户不知道这个事实,和他们不知道没什么本质区别。或许,会有人认为这是 7-Zip 发展用户的一种独特的手段,如果是的话,那恐怕这是最拙劣的营销方式,形同绑架用户一样。

如果不是市场的绝对主导者,任何挑战用户习惯的的行为无疑是危险的。相比 WinRAR 和 WinZip 来说,作为开源软件的 7-Zip ,只需要使用习惯和前两者一样,而功能甚至都未必那么强,就会赢取大量用户。但是给用户习惯設置障碍的做法无疑是不可取的。如果有人不同意,那么还记得”兼容机”这个词汇吧 ?

开源软件应该多考虑使用习惯上的”兼容性”,做网站也是一样,有多少人在设计网站的过程中真的尊重用户的遗留习惯? 而你是如何做的呢?

EOF

信息过载

先说一下我的结论:信息过载(Information Overload)是个伪命题。只要经过足够的训练,人应该可以接受更多的信息,多到无法想像。尽管这样,我还是相信,对信息的处理还是会让很多人困扰。

如果要减少信息对自己带来的困扰,有哪些可取的途径呢?

克服信息贪婪

你想得到更多,实际上恰恰相反,越想得到更多,真正得到的有质量的内容就会更少。尝试克服对信息的贪婪,有些信息不去主动获取对你影响也会很大。

适度使用工具

工具有的时候时候只是为了减轻个人的负担而存在。不能因为有了工具而变本加利的陷入更多的信息当中。比如,Google Reader 是个不错的 RSS 阅读工具,合理使用会减轻阅读过程中的交互。可如果订阅了过多的 RSS ,反而会使信息泛滥。

现在从 Google Reader 的数据趋势看起来,”推荐”要远比”过滤”有效。通过用户的人工推荐形成的信息流要好过人工设置的过滤方法。说起”社会化推荐”,国内 玩聚 的团队也在做着不错的尝试。

远离信息噪音

离开门户新闻频道,对比一下:一天看 1000 条新闻与一天不看任何新闻,都不会影响你的生活。所以,远离新浪这样的新闻门户对自己是最大的解脱。当然终极手段是远离网络。我相信看我 Blog 的人都是网虫,而网虫的信息过载都是网络带来的。

另外,我以前很少点击 IM/eMail 里面传来的连接(最近一年倒是对这方面有所放松)。很多话题帖其实没什么看头。不过是满足以下好奇心而已。

远离社会网络

现在可以说满大街都是 SNS 。登录任何一个类似站点 ,都是满屏幕的状态信息,实际有价值的信息比例非常少。我也尝试了不少网络服务,唯一一个坚持在用的就是 LinkedIn 了。

到现在为止,还没有说到 Twitter ,对于 Twitter,现在说什么都为时尚早,或许不应该说,因为国内不能正常访问这个也许不存在的网站…

其实对于有价值的信息,多少算是过载? 是信息过载还是获取信息的途径超载? 恐怕很难界定,在互联网时代,你一个月接触的信息量要比没有网络时候一年的还要多。但是这所谓的负载是否真的带来了严重问题?

这是 2 年前没写完的一个帖子,今天捡起来发现还有参考价值,做了一点补充,发布出来吧。

EOF