無標題文檔

BamBook 的未来

http://farm5.static.flickr.com/4059/4331037201_edc89484ba.jpg

单纯从规模上讲,目前拥有至少 七家文学站点的盛大 ,推出 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 平台下开发的成本

现状

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

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

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

成本

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

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

https://gracecode.b0.upaiyun.com/2010_06_16/1276695984.png

国内开发者还有个必须逾越的鸿沟,就是语言和社区问题。目前,国内 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 --

控制 22 分钟的会议时间(翻译整理)

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

-- Split --

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

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

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

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

https://gracecode.b0.upaiyun.com/2010_03_31/1270028282.png

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

制定 22 分钟时间的会议

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

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

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

有个共同的议程

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

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

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

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

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

准时开始

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

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

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

站着开会

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

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

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

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

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

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

同时禁止带手机

理由同上

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

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

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

尽可能快的发送会议记录

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

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

-- EOF --

看不透 iPad

就如我期前所说的Apple 新的平板出来后 ,Google Reader 中有关 iPad 的消息铺天盖地的过来。

总体看来,发现负面的消息多于正面消息,既然已经有那么多有关 iPad 的文章了,那么我也跟个风来说说我对 iPad 的看法。

我们为何失望

发布会后的几个小时,就看到老外就很不客气的这样评价 iPad:

As always, Apple's posted a full video of the iPad event, 
so you can pretend you were right there as Steve Jobs 
unveiled the world's most incredible digital photo frame.

我几乎熬夜看完了苹果的发布会。上述用户的言论虽有偏激之处但也不无道理,我和此用户一样,心里也有点小小的遗憾。

https://gracecode.b0.upaiyun.com/2010_01_28/1264734559.jpg

对于 iPad 最多的抱怨大多都是在硬件上 ,有关硬件上的问题又集中在了扩展性、性能等方面 -- 对于用户来看说 iPad 是个大号的 iPod Touch 一点也不为过。

iPad 让用户失望的点太多,让我失望的是我期待的 Apple 平板电脑系统会是精简版的 Mac OS,而事实上 iPad 取而代之的是「增强版」的 iPhone OS,这无疑个人对于 iPad 而言诱惑程度降低了不少。

不过,采用了精简版的 Mac OS,那么可能硬件的改动会比目前的大得多,硬件成本(包括耗电量)可能不会是目前的售价。

另外个可能的可能,就是 iPad 会为 iPhone OS 4.0 开路,种种的现象说明 iPhone OS 的触手会越来越长。iPhone OS 上的应用一点也不比 Mac OS 少(甚至更多),Apple 当然不会放弃这张牌。

Apple 要和 Google 干,那么 iPhone OS 之于 Android 会是很好的竞争对手。iPad 的出现无疑会让 Apple 巩固 iPhone OS 的地位。但换个角度考虑,iPad 可能会成为这场仗中的陪嫁品。

因此总体而言,iPad 在 Apple 产品线中的位置在 Macbook 和 iPhone 之间。我期望 iPad 使用 Mac OS 只是更希望它能更靠近 MacBook 那边些。

不仅仅是硬件

回到 iPad 硬件的这个话题,这次改动最大的可能就是整体的系统架构。Apple 采用自家的 A4 处理器让开发人员们充满了好奇。

http://pic.yupoo.com/feelinglucky/960478c5cb18/medium.jpg

有关 A4 处理器的资料并不多,但值得肯定的是 iPad 肯定不会是简单地更换块处理器那么简单。如果正如 这篇文中所言 ,那么 A4 高达 1g 的处理的 可玩程度可比 iPod Touch 高得多 (这是肯定的)。

扩展性方面,iPad 在夹缝中也是非常的难受,它注定会和 iPhone 和 Mac 不同,因此它没有摄像头和语音输入,同时它也会没有 USB、火线等接口。

其实,我更愿意将 iPad 和 Macbook Air 归为同一条产品线。

iPad 屏幕方面的争议也相当得多,例如为何不用 OLED 以及 16:9 的宽屏等。可能苹果的对于 iPad 屏幕的搭配是出于成本方面的考虑。除此之外,我怎么也想不通 Apple 为何会这样干。

同时,iPad 的 9 寸触摸屏对于设计人员而言也是个挑战。iPhone 和 iPod Touch 的 3 寸「金莲」完全可以搬抄手机设备的设计,想象的空间也相对较小,但 iPad 的「大饼脸」则会不同。

硬件方面还有个可能, 就是 iPad 会不会如当年的 iPod Touch 2g 一样给用户个「惊喜」呢 ?相信我,其实 Apple 很擅长做这样的事情。

注定的,硬件方面从一开始 Apple 就满足的不了用户的 100% 需求。

好戏还在后头

犹如运动员在起跑之前都会将屁股翘起来一样,目前我们看到和听到的有关 iPad 的消息都是它的「屁股」。

我们对于 iPad 的了解也仅仅停留在 Apple 的发布会、几张产品图、网友的评论等。

结论应该在两三月后,看到 iPad 的真机并拆解、SDK 、iPhone OS 4.0 以及 App Store 的应用丰富程度等,再做定论。

论 Apple 功底,绝对不会让 iPad 那么简单,而我们现在能做的也只能是等待。

-- EOF --

第四届 D2 的些记录

第四届 D2 圆满的结束,不过对此的思考却并未停止。

嘉宾们的分享&感想

模板语言与大前端

随着前端技术发展日趋复杂,「传统」后端的建模等计数也逐渐尝试应用到前端脚本逻辑中。将我们熟悉的 MVC 应用到 Javascript (以及对应的 DOM 编程中),这两个「老朋友」的结合仍然能够给我们带来不同的思考。

可以预见的是在不远的将来,复杂的前端应用中随处都能看见模板引擎的应用。遗憾的是由于时间的关系,没有留给 大为 更多的时间讨论。环绕在脑中的思考,或许要等瞄下他的 lite template 后才会有个大致的消化和理解。

从 YUI2 到 YUI3 的前端演变

说实话一直没有深入研究过 YUI3,一来是因为时间、二来期前个人认为它目前不是很成熟。此前 玉伯 经常「推销」YUI2 至 YUI3 的「革命性转变」。今天,他的观点也从 克军 的分享上得到了印证。

克军 的分享现在回过头来对比看,是此次 D2 我收获最多的。通过他的分享,对于 YUI3 的印象也逐渐的清晰和「得到平反」。现在,急需要做的就是花点时间去真正了解这个框架(当然,我指的是不仅仅是它的源代码)。

Sliverlight QQ 项目实践

相比 甄炎鯤 (呃,还是叫他 Shadow 吧) 的分享内容,其实对我印象最深的还是在线下私聊的内容。

-- 这段内容就被「和谐」了吧 :^) --

前端性能优化和自动化

秦歌 的分享其实早先在内部已经听过,对他们在前端代码自动化方面的尝试让我赞叹不已。的确,代码自动压缩、Combo 其实是件非常机械和无聊的事情,完全可以交付机器去处理。

也如 玉伯 所言 ,将性能优化以及自动化两个那么「大」的话题放在一起,觉得有些泛同时也略显单薄。其实,我更期待 秦歌 能够再单独深入讲讲他们在自动化的方面的尝试。唉,众口难调呀 :^)

个人秀

个人秀环节 hax 与 army 的「PK」,让我再次见识到了技术人员对于各自专业领域的执着。同时,会后与 hax 交流分享各自的心得和经验,不禁感叹下 hax 在前端方面的深度和广度,我得努力。

前端&安全

回到我自己的分享,说实话其实这个话题并不好讲( 幻灯片下载 )。

一来,是因为会场要么就是已经了解我今天所要讲的话题内容的「技术人员」、要么就是就算我讲了散会了都没听懂的「设计人员」;二来,是因为某些方面的原因,安全这块原理以及案例也需要「点到即止」,深浅程度实在是过难于把握。

还有我个人,只不过是相比其他不了解前端安全的朋友多走了一小步而已。玉伯说前端安全「我们目前处于 65 分」,其实在我看来我们还仅仅是 59 分 -- 还需要继续努力。

似乎又回原先和朋友们争论的几个话题,「前端到底要不要触及安全领域,甚至前端要不要专门研究前端脚本攻击技术」。在我看来,这一切说实话还是个未知数,毕竟「前端开发工程师」这个职位还是刚刚被业界承认,而「前端安全工程师」这个职位自然还要有更多的路要摸索。

但有点可以确定,就是同比之下如果前端了解安全方面的常识,这将会给自己带来更强的竞争力。借用此届 D2 的口号,就是「让我们蜕变,成为安全力量的新生力量;让我们成长,成为整个研发团队乃至整个公司不可或缺的一部分」。

言论

记录下嘉宾们对我印象最深的一句话:

杂念

计划

OK,从现在开始,期待下届 D2 吧

-- EOF --

我的照片

嗨!我叫「明城」,八零后、技术男、伪苹果粉、微软无脑黑、宁波佬,现居杭州。

除了我的博客,同时也欢迎您访问我的 GitHubTwitterInstagram 主页。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,因为我曾经为这个名字伤透了脑筋。最后想到的这个名字都没啥特别的,说到 底是因为我实在给它不了个非常酷的名字。

如果您想联系我,可以发我邮件 echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d

注:本站点所持观点仅代表个人意见,不代表所服务公司的立场。

文章

项目

微信公众号