淘宝开放平台( Taobao Open Platform, TOP ) ，面向第三方的开放式电子商务服务基础服务框架，重装上阵。前一段时间提前接触了一点这个项目，真是个非常有想象空间的事情。

可以肯定的是，这是"大淘宝"战略的一个重要环节。从最初的 Taobao.com 一个站点，现在是一个平台，将来再到一个更大的商业生态系统。

(上图出处)

去年下半年淘宝有过一次尝试("淘园"项目)，与上次的初步尝试截然不同的是，这次已经不再通过阿里软件这一层进行接入，从开发者使用角度上看，减少了交互环节,更加直接方便。此外，可供使用的应用程序接口愈加丰富，更贴近用户使用习惯。随着开发者社区的成熟和开发者规模的扩大，淘宝提供平台化的支持也是可以想见的事情。

对于所有的开放平台开发者来说，最关心的问题莫过于盈利模式。现在 TOP 关于盈利模式主要有两种形式：一是淘宝客佣金模式，再一个是淘宝插件分成模式。还是比较清晰的。就我个人而言，更倾向于前者的模式。也期待淘宝运营人员能够根据实际情况制定更加有利于开发者的策略，积极促进与开发者之间的互动。胜，在于人。

与其在一些 SNS 网站捣鼓那些游戏插件，还不如来开发电子商务第三方应用呢。你说呢?

以上仅为个人看法。所用信息均为公开资料。请勿跨公司抓捕 :) 

--EOF--

Posted by Fenng at 3:04 PM | Permalink | Comments (14)

技术团队小的时候，似乎只有人手不够才是最大的问题。而随着队伍壮大之后，管理者会最终发现除了徒增更多的沟通交流成本之外似乎并没有带来额外的生产力。

一个庞大的技术团队就好比那艘叫做 瓦沙 (refer 2) 的大船，看似将来可以横行海上，其实自身恰恰最为危险。

大野心

这是大技术团队中最容易发生的一个问题。兵强马壮，高手云集，那就造一艘大船！逐一制定看似切合实际而实际超出团队能力的目标，要做就做大的，颠覆性的、革命性的、划时代的....项目，而对小项目根本不屑于一顾。历史给我们的经验教训是，凡是过于庞大的东西迟早要毁灭。

对于大项目，我最喜欢讲的一个故事是"大山临盆"：

大山临盆，天为之崩，地为之裂，日月星辰，为之无光，
房屋倒塌，烟尘滚滚，天下生灵，死伤无数
--最后生下一只耗子

大一统

团队一大，管理者喜欢制定一些条条框框的东西，"规范化"是一把双刃剑，这事情本身没错，但不可采取"拿来主义"照搬别人的做法，也别听一些厂家的蛊惑而购买"停不下来的红舞鞋"。切记不可抹杀团队成员个性，不要降低团队成员生产力，不能以浪费团队成员激情为代价。不然的话，大团队也必然暮气沉沉。团队成员能动性发挥不出来，再加多少人力也于事无补，只能陷入焦油坑，越挣扎越难摆脱困境。

乱想录@BetaCafe

--EOF--

Posted by Fenng at 7:07 PM | Permalink | Comments (15)

上半年好像我写了不少推荐序。《Apache源代码全景分析第1卷》已经面市一段时间了。读过这本书的电子稿，先睹为快之后写下推荐序。

如果说没有 Apache 就没有 Internet 可能有些夸张，但至少可以说没有 Apache ，互联网不会发展这么快。根据互联网研究公司 NetCraft 的统计，多年来 Apache 一直是稳居 Web 服务器市场头把交椅，至今仍占据超过 50% 的市场份额。就整个互联网来说，Apache 仍然是最重要的软件之一。

尽管近几年来涌现出不少以"高性能"为卖点的新的 Web 服务器软件，比如 Lighttpd 、Nginx 等，吸引了不少用户注意力，不过 Apache 因其功能广泛，有些仍具有不可替代性，在技术领域仍然是 Web 服务器风向标。话说回来，"重剑无锋，大巧不工"，有的时候软件性能表现不佳，更多原因可能是对其了解不够、使用不当造成，并非软件自身有多大缺陷。 对 Apache 来说，更是如此。所以，通过分析源代码了解 Apache 软件架构体系，熟知其本质，方能更有效的使用 Apache Web 服务器，从而发挥出最大效能。为网站节省资源，为企业节省资金，也能为用户提供更好的访问体验，好处多多。

此外，随着互联网业务的复杂化，很多网站使用 Apache 的过程中也遇到了新的挑战，常常要在业务的驱动下对 Apache 进行扩展性的开发(例如扩展日志模块以便于更复杂的日志统计)。这个时候，源代码分析是绕不过去的一件事儿，尽管源代码获取是轻而易举之事，但 Apache 代码毕竟凝聚了开源软件界的群体智慧，要想高效分析却是并非易事，相信这本书能让有此需求的读者少走弯路，剥丝抽茧，获得更多启发与借鉴。

说起源代码分析，其实几年前市面上出现过一些此类话题的图书，不过基本上是印上大段源代码加上几句注释了事，读者可能会有吃到注水猪肉的感觉。而本书的读者对这一点大可放心，书中代码只是点到即止，相对环保多了。

后记：此书编辑够用心的，这里这个案例可见一斑。

--EOF--

Posted by Fenng at 11:55 PM | Permalink | Comments (6)

搜狐推出了白社会，这几天好几个朋友都在热情的进行义务测试。现在有新 SNS 出现的话，基本上也就是去测试一下，看看设计上有没有新的特点，盲人摸象琢磨一下技术实现的事情。

根据了解到的反馈结果，多数网友认为搜狐这个 SNS 做得相对不错。但我觉得没什么值得表扬的，毕竟是后发者，能够对已有的产品特点进行吸收，也能够添加新的元素。此外，校友录仍然是搜狐没有用好的一块资源。校友录本该成为中国的 Facebook，只不过因为时代的局限性这个结果大家都看不到了吧。

淘宝的"淘江湖"已经开放，听闻新浪 SNS 服务"朋友"也已经开始内部测试，看来 SNS 要成为各大网站标配已经是不争的事实。按照这个思路的话，盛大、网易的 SNS 也是很有"必要"的嘛。问题是，真的 需要这么多 SNS 麽? 感觉这就是重复建设(这和各地政府上马政绩工程真有异曲同工之妙，起码能拉动本地 GDP 嘛)。每家大网站都怕被落下，怕什么被落下，当然是 PV，没有 PV 怎么有广告? 没有 SNS 怎么带来会员活跃度呢? 用 SNS 拉动 PV ，还是挺有效的办法。至于里面能玩出什么花样，除了游戏能给运营商带来利润，其它怕是没什么价值。

如果你登录某个 SNS 网站大部分操作不过是处理好友请求，那么需要反思这个 SNS 到底能给你带来什么? 功能再好的网站如果对你没有什么真的用途，还不如没有呢。所以，别玩什么劳什子 SNS 了，洗洗睡吧

--EOF--

Posted by Fenng at 9:49 PM | Permalink | Comments (29)

这本《Linux Networking Cookbook 》(中文版) 是译者冯亮(aka, hutuworm)的赠书。 600 多页的书一个人5个多月搞定，翻译本是一份儿苦差事，没有足够的功力和定力做不下来，而其细致从译者终校可见一斑。

搭建Linux防火墙、使用Linux路由、使用Nagios监控网络、和自动网络安装服务等章节，对于一个系统管理员来说是绕不过去的话题，或许有人觉得我用搜索引擎直接找这些不就成了，不过，恕我直言，现在能搜到的技术信息多半零零散散，缺乏准确性。而其它一些看似生僻的章节也或许什么时候也能遇到，比如搭建 VoIP 服务器这一章就是个绝佳的教程。很多时候，我们最欠缺的是把Linux 用到刀刃上。有这样的一本书放在案头，"手中有粮，心中不慌"，想到的时候就读几页，慢慢的也就啃完了。

经常有人问我类似"我从现在开始学习某技术还来得及麽?" ，其实我哪里知道。我们的确有句俗语叫做"三十不学艺"，可看看这本书的原作者 Carla Schroder 到了37 岁才第一次接触计算机，现在是一名技术顾问。国内也有王江民老师 38 岁自学电脑，进而开发出 KV 系列杀毒软件。可见，学艺并不怕晚，只要有信心，有毅力，终有所成。

在贝塔咖啡馆的读书笔记一则。不求读遍架上藏书，但求读一本书有所思，有所得。

--EOF--

Posted by Fenng at 6:23 PM | Permalink | Comments (11)

这本《程序员的自我修养》比较有趣，真的没想到会有技术书籍这样命名的。与其中一位作者聊过一次，得知他为写这本书下了很多功夫。至少他自己的实践和提炼过程就体现了一个程序员的自我修养吧。

此书我能看明白的是《Linux共享库的组织》这一章，这和我过去的技术背景有一点点关系。如果折腾数据库软件，那么几乎不能回避 Unix 操作系统共享库的知识。但这部分东西又很少有专门文章说明。网络上搜集资料又零零散散。看完了这一章倒是补充了一下这个知识点。建议 DB 相关的技术人员不妨找来这本书读一下这一章节。

然后顺着书中提及的几个参考信息又找到了几篇文章。平面印刷因为无法像 HTML 那样提供超链接，所以作者如果多提供一些参考信息或者参考文章则是最好的了。这一点上，这本《修养》做得不错的。看完这一章的另外一个感想是做技术的，的确需要多加一些软修炼，对一些常见的东西能做点刨根问底的傻事情。慢慢慢慢，也算有些修养了吧。

书名总让人想起《喜剧之王》里面一些喜剧情节，和那本不得不提的《一个演员的自我修养》(这可能也是中国知名度相当高的一本但是没几个人看过的书)。周星驰有过一段话，"《演员的自我修养》这本书，我以前就看过，但一点都看不懂！有人告诉我，如果五年之后再看，可能会看懂一点，十年后会更懂一点，不同的阶段、不同的层次会有不同的理解。"，对有些事情，大致如此。另外，也期待作者5年，10年后能够对此书进行修订更新，不知作者到时对这本书又是怎样的一个看法。

在贝塔咖啡馆的读书笔记一则。不求读遍架上藏书，但求读一本书有所思，有所得。

--EOF--

Posted by Fenng at 11:11 PM | Permalink | Comments (1)

读隽辰的译作《应需而变--设计的力量》，第二章的一个小节《新奇的陷阱》很有意思。书中举的例子是某个银行在个人业务服务网站提供天气信息(这当然是业务领导的异想天开)。如果你没看过这本书，你认为银行提供这个服务有价值麽?

答案是这是个糟糕的产品设计。尽管这东西看起来应该有价值，用户怎么能不需要天气预报呢? 是的，用户需要天气预报，但是银行业务和天气有什么关系呢? 没有关系。所以这个服务其实就是个奇怪的混搭。一个新奇的服务或者功能看起来似乎应该能起到该领导预想的作用。但实际上，用户很难体会您的"用心良苦"。做新奇的而无用的东西简单，而对用户更有用的东西做起来反而更难。

这让我想起昨天看到的一篇李宁公司销售专家的一处细节，"放弃了大批量采购大黄、大紫服装的打算，其选择的颜色几乎无一例外都是蓝黑白三种颜色。什么样的颜色最终会进入减价区？──所有那些古怪的颜色。"。什么产品会最终被用户抛弃? 所有那些自作聪明的"创新"。这或许会对我们有点启发吧。

处处讲究创新的公司，各个都挖空了心思研究新产品，而不改进已有产品、不提升既有产品对用户的亲和力、不提升已有产品的价值，就变成了熊瞎子掰苞米。如果是遵循战略的创新，那可能算作真正的创新。否则的话，所谓的创新不过是一种炫技和自我满足罢了。写到这里，似乎和标题没什么关系嘛。其实我要说的是，如果不犯这些错误，那可能需要把用户的真正体验作为一种战略。而不是把所谓的创新作为战略--毕竟这么做的人和公司太多了。

在贝塔咖啡馆的读书笔记一则。不求读遍架上藏书，但求读一本书有所思，有所得。

--EOF--

Posted by Fenng at 10:45 PM | Permalink | Comments (5)

真是一种嘲讽，就在刚才，收到一封广告信，标题是 "Sun为企业发展提供更多动力"

对于 IT 产业来说，这是最好的时代，这是最坏的时代。Sun 要做 Web 2.0 中的这个 Dot 没做成，74 亿美金把自己卖掉了。

尽管我不是 Sun 的粉丝，还是感觉不太痛快。这次收购意味着又有若干产品有可能被打入冷宫。而大家比较关心的 MySQL 可谓命运不济，被 Sun 折腾一年多，在开源社区里面一点好没讨到，这回在 Oracle 新的产品线里面如何定位呢? will be an addition to Oracle's existing suite of database products... 当然，InnoDB 这回和 MySQL 算是破镜重圆了。是否有其它变数，比如被原 MySQL 团队赎身出来? 难!

对于 Oracle 来说，这次自己终于有了硬件(SPARC)和操作系统(Solaris)这两块王牌，其实 Oracle 和 Sun 算是多年的合作伙伴了(超过 25 年)，相信整合起来可能问题不大。这次收购比较失败的可能就是 IBM 了，Oracle 这次给了竞争对手 IBM 以更大的压力。难道蓝色巨人出不起这个价格麽? 还是觉得足够鸡肋? Sun 手里的 Java 技术对于 IBM 的小型机是个很好的补充，想不通。再过几年，这可能就是 IBM 犯过的最大错误。

不痛快的除了 IBM ，恐怕还有 RedHat。不过别着急，没准儿哪天 Oracle 也把 RedHat 也一并收了，我相信 RedHat 手里的 JBoss 至少让 Oracle 眼馋不已。有 JBoss 在，其他中间件就不可能赚到更多。

一切皆有可能。其他事情不好确定，但有件事情还是能基本肯定，拉里·埃里森大叔这回又有机会体验一下世界首富的滋味了...

--EOF--

延伸阅读：

• 书写历史的甲骨文--ORACLE公司传奇(1)
• 书写历史的甲骨文--ORACLE公司传奇(2)
• 书写历史的甲骨文--ORACLE公司传奇(3)
• 书写历史的甲骨文--ORACLE公司传奇(4)

Posted by Fenng at 9:48 PM | Permalink | Comments (15)

当一家公司发展到一定规模的时候，可能就不如初创时那么有朝气了，初创时，没有包袱，轻装前进，高标准，严要求。而江山渐渐坐稳，"创新"渐渐就会成为一个熟悉而陌生的词汇。

如果整天喊着创新而实际上产品没有任何新意的时候，应该注意一下是否那些管理人员在其中起着阻碍者的作用。所谓创新，如果不能充分调动基层员工的积极性，那是不可能做到的事情，而无意识的妨碍基层员工进行创新，更多是出于管理者自身本位主义的考虑，管理者们应该知道"不破不立"的道理，但是"破"对他们来说，风险太大，远不如原地踏步，或是拿来主义，这样才稳妥，这样最不济犯错也是别人先犯。这个时候，很难去对他们奢求"用户第一"的自我要求。

回过头来，如果产品自身千疮百孔，被用户整天批得体无完肤。与其开发一些未必靠谱的产品，还不如埋下头来把当下的问题搞定。创新要在一定基础之上，缺乏叫座的产品做铺垫，所谓的"创新"只是空中楼阁。

创新还是撞墙，这是个问题。

--EOF--

Posted by Fenng at 10:45 PM | Permalink | Comments (10)

按：这其实是某一本书的推荐序(我这段时间没写 Blog 净帮着人忽悠了)。不过遇到了不靠谱的出版社不靠谱的编辑，据说整篇文章最后"只采用一两句行不行"? 当然不行。以后如果有出版社找我免费写推荐序或者书评，请自己考虑好再来浪费我的时间，多谢配合。

有的时候朋友们聚在一起聊天，会谈到国内国外技术人员的差异。我常喜欢说一句话"国内的 IT 公司基本上是劳动力密集型高科技企业"。比如就国外 Web 2.0 站点来说，Craigslist 、Wikipedia 等流量比较大的网站不过数十人的小团队而已，如果放在国内，这样规模的网站起码要几百人乃至更多人员才能足够支撑。国外程序员一个人做的事情，国内可能要一个团队来做，当然可能还做不好。这里面或许有企业管理效率低下的因素存在(宁愿相信是这样的原因)，不过大家都不愿意说的另一个因素是我们技术人员生产力效率低下。这种差异来自不是智力、体力上的差异，而是因为做事情的方式和方法，存在大量的重复劳动和人工劳动，对技术不能充分有效运用。如果不能对工作方式方法进行改进，我们永远都是技术流水线上的编码工人。

我们常说，重复的行为才能形成习惯，只有良好的习惯能导向成功。或许有人某些书籍或者聆听了某些"教诲"会逆反性的产生不以为然的想法，"这个我早就知道......" -- 我自己常常就是这样自以为是。问题是，只是"知道"而没有行动起来加以"运用"，这样即使知道再多的技巧也不会形成良好的习惯，自然无法产生实质的改进，这可能也是技术人员惰性的一方面吧。其实我们需要的是能有更多的技术人员真正的行动起来，利用这些经验/教训/技巧...提升自己，也去积极影响他人，形成更良性的互动，不要让"持续改进"成为一句空话。另外，必须要补充的是，如果技术人员持续从事低效率的工作，极有可能逐渐厌烦技术，疏远技术，乃至对技术绝望，而一个高效的技术人才能从技术中获得真正的快乐。

也想告诉那些所谓的管理人员，不提升每位技术人员的生产力而希翼增加人手来解决技术困境的想法是不切实际的。那样做除了给企业增加负担，使组织更加混乱低效，很难起到什么实质作用。好的管理者必须能够引导下属持续提升生产力，不能一味用死板的流程制度限制团队的整体节奏。彼德克鲁克这之类的管理大师的大腿人人都好抱，但那是屠龙之术，您暂时还可能用不上，来点痛快实在的才是王道。

--EOF--

文章有删节。出版社的名字我就不直接说了，不过类似的经历的人还有潘加宇。你猜这是哪一家?

Posted by Fenng at 2:50 PM | Permalink | Comments (22)