单纯从规模上讲，目前拥有至少 七家文学站点的盛大 ，推出 BamBook 阅读器 丝毫让人感觉不到意外。

这款目前称为 BamBook 的阅读器外形与我期前接触的内部版并无多大的改变。当时由于是内测版本没有印上 Logo，给人第一眼的印象就是国内 Kindle 的山寨板。

都知道 BamBooke 面对的对手不是 iPad，而是 Amazon 的 Kindle。在面对已经历经三代的 Kindle 面前，新生的 Bambook 就好比是孩子对比成年人一样，没有任何的对比性可言。

一开始将 BamBook 的目标定位为 Kindle 未免有些不太现实，其实我们能理解， BamBook 主要面对的是国内中低端阅读器市场 。

然而，国内的「特殊环境」可能是制约此类产品发展的因素之一。这就好比国外卖手机其实卖的是服务而非硬件，国内此 类产品永远大多都是在做「产品」而非「服务」。

盛大当然也考虑过这个道理，因此考虑这款产品如何生存下去的条件之一，就是如何降低成本降低售价。BamBook 那 1k 不到的卖价，自然也就在情理之内（同时 我有理由相信以后的价格只会更低 ）。

相对价格，时隔几个月不知此时发布的版本稳定性和速度对比那时体验的内测版是否有所提升。如果还是老样子，那么即便是如此低廉的价格，恐怕还是很难打动挑剔的消费者。

随着 iPad 等平板电脑的持续发力（虽然两类产品无法共同比较）、Kindle 的第三代版本目前最低售价也才一百多美元、同时国内现有的例如 汉王 等传统电子书厂商也有降价的趋势。

光控制成本和售价并不能说明 Bambook 有多少的竞争力。如果想在这堵墙中拉开道口子，BamBook 必须在其它的地方寻找突破口。

首先能想到的就是盛大目前掌握的资源 ，「搅局的人永远在后面出现」，不要忘记盛大的掌中已经有几家国内规模较大文学站点。如果盛大能将这些资源充分的利用 对接起来，那么原本风平浪静的国内阅读器市场将会变得复杂。

我们可以想象下此时盛大的心态，这个在大部分人眼中还是家依靠游戏外包发家的公司，对比腾讯没有其影响力和用户基础、对比百度其没有技术。如果其想要转型，那么除了大肆收购的手段之外，剩下事情就是组建自己的核心生态圈－－回头看其实这个局早在 2006 年就已经开始布置。

我们回看 BamBook 产品本身，那外形类似 Kindle、平台 UI （ 甚至产品页面 ）类似 Apple 的 Bambook，它首先需要做的就是摆脱那模仿的影子， 同时避免那些拙劣的推广手段 。

那么这样，才有它的未来。

-- EOF --

现状

无论各方面如何评论，在 Apple 平台下开发越来越丰富。回想几年前如果想要招聘专业在 Mac/iPhone 平台下的开发人员，那几乎是不可能的事情。

Apple 平台下开发的那种狂热，让我觉得很是意外但想想却又是情理之中。Apple 的总市值已经超过微软，同时 ObjC 已经挺进了编程语言的前十 。

这种情况让我总不免对比当年的 C# 和 Java -- Apple 平台下的开发，又将会是新的一轮的淘金热。

成本

与其他平台不同，想要在 Apple 平台下开发，需要有一定的硬件成本。首先，最好必须要有苹果的产品（用「黑苹果」使用不是「那么回事」）。同时如果想要 iPhone 下的开发并想要在 App Store 中卖的话，那么又得交份「保护费」。

然后就是其他的软成本。 具体这里有篇文章写的很详细 ，这里主要列出的可能会碰到的技术问题：

• ObjC 语言本身 19%
• 我不了解 ANSI C 12%
• Cocoa 实在太大了 11%
• 内存管理 10%
• 界面 UI 设计和开发 10%
• 我习惯使用 Java 和 C 了 10%
• 如何设计委托模式 8%
• Cocoa 模型等 8%
• 我不了解面向对象编程（OOP） 8%
• 我不清楚文档如何建立 5%
• Cocoa 的（库）绑定等 5%
• Xcode 工具使用 3%

国内开发者还有个必须逾越的鸿沟，就是语言和社区问题。目前，国内 Apple 平台下的开发相关的中文书籍和文档几乎是缺失；国内的专业苹果开发论坛也屈指可数。

值不值得？

那么，该不该花那么多的时间在新平台上。这对于在有其他平台中有相关经验的人而言，这是个博弈的过程。

相对其他「传统的平台」，可以看到即将从事 iPhone 开发的开发者们都是看到 App Store 的直接利益而去。而传统的 8/2 原则在任何时候都会适用。

在即将饱和的市场中打开道口子，并不是件很容易的事情，这往往并不是技术上的问题。

相对在 Apple 平台下开发优势：

1. 开发 iPhone 软件能直接带给开发者收益
2. Apple 的用户群有相较高的消费能力
3. Mac 下的软件相对较少，所以无竞争压力比较小
4. Mac OS X 其实就是个 BSD（via）

那么劣势也是相对比较的明显：

1. iPhone 其实是个半封闭的系统
2. 学习 ObjC 有很大的成本

因此我的观点，如果你想在 Apple 平台下开发

1. 你要熟悉 Apple 的产品，也就是首先么成为它的用户
2. 做好打「持久战」的准备，学习任何技术切忌浮躁
3. 改变目前开发平台下固有的观点，对于而言一切都是新的
4. 有必要的时间和精力

再次需要提及的就是切忌浮躁，毕竟做好技术并不是件非常容易的事情，尤其是对于个全新的平台而言。短期内的收益平衡或许会很难做到，但相信一旦坚持下来终究会有回报。

PS，不喜欢 iSSH 占用一个 Dock 图标的用户，可以考虑试试我的修改版本，增加了重新链接、链接通知等功能： http://code.google.com/p/issh-improved/

-- EOF --

「会议拉锯战」是每个人都头痛的。如何高效的进行会议，相信每个人都希望了解。那么或许 这篇文章 可能给大家有所启发。

-- Split --

没有人因任何的因素喜欢开会。其实很多情况下，大部分的人都认为一些的会议都是在浪费时间。

那么，如何剔除会议中那些浪费时间的方面，留下精华部分？

让我们尝试下将会议时间压缩到 22 分钟，Nicole 首先提出了这个想法，我个人认为这是目前所能看到的最容易做到而且有效的办法。

这里是他提及的一些方面：

请原谅我可能没有完全清楚得阐述他的核心观点，因为这些内容我是从他的想法中部分摘记而来。其中每条详细的观点如下：

制定 22 分钟时间的会议

谁规定所有的会议时间需要花半个小时甚至一个小时？这有何数据依据？当然没有。

其实，这点时间留给人们去阐述、辩论自己的观点显然不足够。因此反过来讲，也不可能所有的会议在 22 分钟之内搞定。

但你可以尝试尽可能将会议时间控制得越来越短，而不是越来越长。

有个共同的议程

有个明确目标的议程将会使会议锦上添花、有的放矢。

可以考虑在白板上写出议程的内容，同时加粗相应的关键点，由此不断提醒大家我们这个会议需要达到什么样的目标。

提前 3 天发送邀请和相关必读内容

虽然这可能是会议组织者的负担，但这能为组员降低尽可能小的成本。

千万不要让会议变成「大家尽可能得先了解文档中的内容，然后必须提交相应的作业」等这种情况。

准时开始

会议准时开始的这种情况发生的几率有多少？该死，实际情况是几乎没有。

你可能会说，部分的情况可能是由于 Outlook 等程序可能没有设置足够的提醒时间的问题。当然纯粹依靠软件是不靠谱的，甚至我建议你可以使用便签等「土办法」。

同时 22 分钟的时间对于个人而言，也可以当作是做个缓冲休息时间。

站着开会

舒适的椅子会让人「变懒」，而同时站着开会能提醒大家目标是不是需要说明或者补充（参见 「混乱的站立会议」 ）。

同时，你需要保持你的观点，如有必要请保持沉默，将它留到会议外去单独处理。

不要带笔记本，但记得带纸笔

如果你承诺会议会在 22 中之内搞定，那么就没有必要带其他无关的物品。

我甚至认为带上这些东西你将重复你中学时的覆辙 -- 看起来你在开会，而其实你的心已经飞往他处。

纸和笔会让你的头脑清醒，也有利于分工：一个人讨论问题，另外一个人记录。

同时禁止带手机

理由同上

注意！记录所有的话题相关的反馈

如果是个会议，那必定有个人会担当组织者的角色，记录所有应该注意的点。

同时，反馈中可能会有支线等情况发生，你应该避免这些话题不会离会议本身的议题太远。

尽可能快的发送会议记录

22 分钟并不长，但你应该尽可能快的发送相关的会议记录，组织并计划下个会议。

好了，我想你有更多补充这个话题的观点，那么也请你不吝的提出。如果你愿意，你完全可以和其他人分享这个话题。

-- EOF --