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

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

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

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

--EOF--

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

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

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

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

--EOF--

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

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

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

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

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

--EOF--

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

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

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

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

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

--EOF--

真是一种嘲讽，就在刚才，收到一封广告信，标题是 "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)

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

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

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

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

--EOF--

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

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

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

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

--EOF--

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

传闻 Google 从 Intel 订购芯片，要求更具耐热性，要求 CPU 能在超出标准工作温度 5 摄氏度情况下运行。这样可以大量节省空调制冷带来的电力费用。

最近的另一个消息是 Google 在号召厂商采用 12V 电源的主板。节省功耗。

空间和电力是 IDC 头疼的两个地方，对于节省空间，Google 的服务器设计趋势是在一块主板上设两个服务器 ，有些类似硬件上的虚拟化。

Google 的这些举措其实也是其他上了规模的公司要走的路，肯定也会对 IDC 产生及其深远的影响。昨天和朋友在聊省电的事情，我当时能想到的也就是低功耗硬件, 比如低功耗 CPU、采用SSD、硬盘自动降速等几个有限的方式，倒是没想到更耐热的 CPU 这一点，而面向 IDC 的硬件集成这也是个很好的参考。

参考资料：

• Google's Will Power and Data Center Efficiency

--EOF--