雷柏 RATV 体验

TL;DR

鉴于 RATV 糟糕的播放能力,强烈建议不要购买:在线视频不管是标清还是高清都一直会出现失帧、跳帧现象,播放本地 4.3GB 1080P Eva 新剧场版 Q 虽然比在线视频情况要好很多,但仍有声画不同步的情况


RATV 是雷柏在 2012 年 9 月 4 日公布的家庭影音娱乐产品,目的是「山寨」和成为中国的 Apple TV。

设计上非常简洁有爱,和 Apple TV 风格非常相近,其他内容可以看评测,我就不复述了,只是说说它的致命缺点。

RATV 使用了 1GHz 的单核心 Cortex-A8,虽然这颗心能满足 Android 4.0 和 RA.UI 的使用需求,操作流畅度也不错,但是在播放视频上,却非常的糟糕。

播放在线视频(优酷、迅雷等官方 app)会出现失帧、跳帧的情况,并且不是短暂,而是每几秒就一次,标清和高清都一样,即使把输出设置为最高 720P 也没有改善。

而本地视频,我使用了之前流出的 4.3GB 1080P mkv 格式的 Eva 新剧场版 Q 作为测试。播放时整体效果比在线视频要好不少,失帧、跳帧现象并不明显,但仍会有声画不同步的情况,并且内置字幕显示有问题,漏了部分字幕,显示的字幕会不停闪烁,外置的 srt 字幕无法识别编码,出来是乱码的。

卖点之一的触控遥控器操作起来灵敏度有问题,经常会误操作,比如滑动会识别成点击等等;右侧和下方的滚动条灵敏度不足,很难用。此外,因为可以兼容 Android apps,所以在一些 apps 界面上是和 RATV 不一样的,比如启动后的功能简介,用遥控器跳过实在麻烦,估计还是外接键鼠比较省事。

BTW,RATV 遥控器接收器是独立的,并不是内置在机子里,所以预设的两个 USB 口实际只有一个能用在外部存储。如果要接键鼠,呵呵。

RATV 在各大搜索引擎里,几乎清一色是是发布新闻、评测软文,有提到不足之处的文章极少,真是一款宣传做得很好的产品。

结论:论播放能力,RATV 还不如 ¥399 的 GIEC HD-330(不推荐购买),实在不值得买,¥500 以下价位的网络播放器,目前就只有 TP-LINK TPmini 比较值得买吧。

为什么耐克会被评为 2013 年最具创新力公司?

知乎上有人提了一个问题:「为什么耐克能够排在 Fast Company 最具创新力公司榜的第一位?」。

杨半仙的回答简单明了,归纳起来就是 Nike 敢于

  1. 重塑生产流程来满足产品的需求;
  2. 独立推广数字化非鞋类运动产品。

杨半仙结尾的两段话点出了这种行为在大型企业里是有多难得:

创业公司经常是光脚不怕穿鞋的,所以能够出其不意地做出一些创新,但是大公司所面临的确实另一种情况。对于耐克这样一家身处传统行业,一年营收 230 亿美元,员工超过 4 万的公司来说,任何伤筋动骨的改革都是不容易的。但是耐克做到了,Flyknit 是对上游供应链的一次革命,Fuelband 则是对耐克最擅长的鞋服业务的一次颠覆。耐克这家老牌的运动巨头正在跳脱出曾经所属的服装行业,转型为一家运动概念的科技公司。

相对于众多互联网创业者的白手起家,能够以革自己命的激进方式完成的创新不是更值得敬佩吗?不是每家大公司都有这样的勇气和魄力的。

PS:Nike 数字化过程可以看看「数字耐克重生记」。

《航天飞机设计定律》摘录

最近看了一篇文章,叫《航天飞机设计定律》,其中有些也适用于学习和工作,特摘录于此:

  1. 工程设计的实现依赖数据。没有数据的分析只是一种观点。
  2. 正确的设计出航天飞机需要你付出无限的努力。这就是为什么最好要考虑当遇到故障时的处理办法。
  3. 设计是一种迭代的过程。必要的迭代次数是在你目前正在做的次数上加一。在任何时候都是这样。
  4. 你付出最大努力做出的最好设计不可避免的会在最终的设计中变得毫无用处。要学会在失望中生存。
  5. 自然界中,最好的通常会在中部。对那些出现在极端点的最好的东西持怀疑态度。
  6. 没有足够的需要的信息永远不能成为令人信服的不开始分析的借口。
  7. 有怀疑,进行判断。情况紧急,那就猜测。但一定要在真实数据出来后重新进行整理,清理错误。
  8. 有时,最快的得到结果的方法是丢掉所有的东西,重新开始。
  9. 问题永远不会只有一种解决方案。尽管有很多是错误的。
  10. 设计要基于需求。不会有任何的理由可以让设计出的东西要比需求要求的“更好”。
  11. (Edison 定律)“更好”是”好”的敌人。
  12. (Shea 定律)改进一个设计切入点主要是体现在接口上。这也是主要的把事情搞砸的地方。
  13. 之前做过相似分析的人并没有一个直接的途径将他的智慧穿越岁月传递。因此没有理由相信他们的分析而不相信你的。更没有理由把他们的分析用在你的分析中。
  14. 出现在打印刊物中的分析事实上跟它们的正确性很可能没有关系。
  15. 过往经历是一种极好的判断设计是否现实的能力。但过于现实同样会毁了一个在其它方面有价值的设计。
  16. 机遇会严重的阻挡你成为比同领域里其它人聪明万倍的人。如果你的分析说你的最大速度是光速的两倍,你很可能发明了曲速引擎(warp drive),但更有可能的是你被怀疑有精神病。
  17. 一个坏的设计但有好的表现形式,它最终会被判死刑。一个好的设计但表现形式糟糕,它会被判死刑立即执行。
  18. (Larrabee 定律)你在课堂里听到的东西有一半都是垃圾。教育的目的是来让你知道哪一半是垃圾。
  19. 有疑问,写下来。
  20. 给开发定计划总像是在虚构一个小说,直到当你的客户因为你没有按计划完成而炒了你时你才知道它的意义。
  21. (Bowden 定律)寻找测试失败的可能,永远可能改进你的分析设计,这显示了你真的进行了边界分析。
  22. (Montemerlo 定律)不要做哑巴。
  23. (Varsi 定律)日程表只会向一个方向进行。
  24. (Tiesenhausen 定律)为了能精确的估计出最终开发程序需要的投入,你需要把最初估计时间乘以 π,把估计出的成本上的小数点向右移一位。
  25. (Tiesenhausen 定律)如果你愿意往一个新设计的系统中投入最大的精力,那就学习绘画。工程师设计出的飞行器最终会看起来有些艺术概念。
  26. (Mo 定律)你不可能通过爬到更高的树上来到达月亮。
  27. 太空是一个绝对无情的环境。如果你工程出了问题,有人会死(而且尽管你的分析大部分都是对的,也不会有任何的功劳…)

Google 和 Mozilla 宣布开发新的浏览器引擎,后 IE 时代来临?

在昨天(2013 年 4 月 3 日),Google 和 Mozilla 分别宣布要开发新的浏览器引擎,分别命名为 BlinkServo

Chromium 开发新引擎属于意料之中的事,毕竟 Google 的野心是称霸桌面(Chrome OS)和移动端(Android),不够强劲的引擎是不能满足他们的需求的。

Mozilla 开发新引擎就属于被迫无奈,好不容易在 IE 6 时代成功推广了 CSS3 等概念,让市场份额慢慢赶了上来,却被 WebKit 系列渔翁得利,Apple 和 Google 都是要资源有资源、要平台有平台的主,乔大爷一说 iOS 只能有 WebKit,Mozilla 奈何得了么?接着又因 Chrome 的快速启动、安装插件无需重启、强制静默更新等等措施而使 Firefox 从藐视 IE 的地位变成被藐视的处境(joking :P)。Opera 也是处于这样的窘境,最后妥协换用 WebKit 引擎

Mozilla 顺利勾搭上三星这个有平台没资源的主也就顺理成章了。三星很明白跟着 Google 和微软混很难保证前景,比如 Android 阵营被 Apple 控告 Google 就爱莫能助,比如 Google 也大肆推广自有的 Android 品牌并收紧自由度,比如 Nokia 刚和微软合作没多久微软就宣布 WP 7 不能升 8,各种卖队友啊,所以三星一直没放弃拥有自主的平台。OS 虽然易做,但整个生态构建就很难,你必须保证开发者容易进入才能让这个生态健康成长——像 Android 使用 Java 作为开发语言就备受诟病,另一方面,由于 HTML5 的强势发展,三星很有可能希望有一套引擎来作为底层,就像 WebOS 那样——虽然不知道为什么不使用 WebKit 和 V8 而选择自主开发,可能担心会受限吧。总而言之,Mozilla 迫切地需要平台和资源,三星迫切地需要找到除 Android 和 WP 之外的出路。

个人而言,我并不关心谁开发新引擎、为什么开发新引擎,就像我在 Twitter 上说的

其实哪个引擎我都不喜欢,搞一个强悍又标准的像 IE 6 那样垄断就好了(开发者心声

这真的是心声,我真的烦透了这样的事情:

div {
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
}
var matches = (function(){
  var m = document.body.webkitMatchesSelector ||
          document.body.mozMatchesSelector ||
          document.body.oMatchesSelector ||
          document.body.msMatchesSelector ||
          document.body.matchesSelector
  return function ( elem, sel ) {
    m.call( elem, sel )
  };
})()

未来就可能这样:

div {
  -webkit-user-select: none;
  -blink-user-select: none;
  -whatever-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
}
var matches = (function(){
  var m = document.body.webkitMatchesSelector ||
          document.body.mozMatchesSelector ||
          document.body.oMatchesSelector ||
          document.body.msMatchesSelector ||
          document.body.blinkMatchesSelector ||
          document.body.whateverMatchesSelector ||
          document.body.matchesSelector
  return function ( elem, sel ) {
    m.call( elem, sel )
  };
})()

是不是想起了 IE 6 时代?

function getXMLHttpRequestObject() {
  var ref = null;
  if (window.XMLHttpRequest) {
      ref = new XMLHttpRequest();
  } else if (window.ActiveXObject) { // Older IE.
      ref = new ActiveXObject("MSXML2.XMLHTTP.3.0");
  }
  return ref;
}

此外,@ikarienator 提到

WebKit 虽然名义上是 Apple 的项目,实际上代码量上 Google 的人是 Apple 的两倍多。所以如果 Google 的人离开 WebKit,那么 WebKit 的更新就必须依赖 Apple 投入更多人力了。总不能永远让他坐享其成。

我不认为 Apple 会把 Safari 迁移到新的引擎,至少会继续使用 WebKit 很长一段时间,那,缺少了 Google 的贡献,本来就比 Chrome 更新慢的 Safari 会变成怎样呢,也是一个未知问题。

Nimble Quest:贪食蛇版 RPG 游戏

最近发现一款好玩的小游戏——Nimble Quest。

Nimble Quest

玩的方式和 Nokia 手机经典游戏贪食蛇一样,通过滑动手指或方向键(OS X)来控制方向,规则也和贪食蛇一样,撞到障碍物人物会死亡,只不过由于融合了 RPG 要素,每个角色都有自己的血量,撞到障碍物或血量降到 0 就会死亡,而排头的队长死亡则 Game Over。

Nimble Quest 采用 IAP 收费,但是玩起来可以一分钱也不花,没有广告。游戏内类货币的物件分为两个,一个是宝石,一个为 token。宝石通过游戏内收集,用于升级角色和辅助道具;token 则可 IAP 购买,游戏过程中有极低机率掉落,主要用于 Game Over 时继续游戏或者购买队伍人员上限。

角色的解锁只要顺利推进进度即可,当然也可以 IAP 购买,而 Game Over 时如果不用 token 继续游戏就需要从头开始打,如果觉得进度不错,建议直接用 token 继续吧。

角色的升级有两个途径,杀怪和使用宝石。

作为一款悠闲小游,很适合无聊时玩玩;同时提供 iOS 和 Mac 版本:

iOS:https://itunes.apple.com/cn/app/id583638819?mt=8

Mac:https://itunes.apple.com/cn/app/id598685044?mt=12

HTML5 Storage APIs

因为太久没用这些东西,之前被人问起时只能勉强答出两个,并且连事件也不记得,只好把常用的列出来强化记忆了。

localStoragesessionStorage 的 APIs 在行为表现上是一致的,以下以 localStorage 为例,而 globalStorage 因为不是标准,所以略过。

函数和属性:

setItem(key, value)

valuekey 为名存入 localStorage

keyvalue 理论上可接受任何类型,但实际会通过 String(value) 转换为字符串,所以需慎用,比如 Object 会转换成 '[object Object]'null 会转换成 'null'

localStorage.setItem('hello', 'Chris')
localStorage.key(0) + ' ' + localStorage.getItem('hello') // 'hello Chris'

localStorage.clear()
var obj = { str: 'an object' }
localStorage.setItem(obj, { posts: [{}, {}] })
localStorage.key(0) // '[object Object]'
localStorage.getItem(obj) // '[object Object]'
var otherObj = { str: 'another object' }
localStorage.setItem(otherObj, true)
localStorage.getItem(obj) // 'true'

localStorage.clear()
localStorage.setItem(null, null)
localStorage.getItem(null) // 'null'

getItem(key)

要注意 String() 的问题。

key 不存在,getItem() 会返回 null,如果在 setItem() 时并没有进行严格验证的话,建议同时判断是否为 'null' 来确定是否存在。

访问 key/value 的其他方法

localStorage 可以像数组一样操作,而 key 也会作为普通对象的属性一样被访问。

localStorage['hello'] = 'world'
localStorage.hello // 'world'
localStorage.hello = 'Chris'
localStorage['hello'] // 'Chris'

removeItem()clear()

一个删除单个,一个删除全部,不返回任何值,key 不存在时也不会报错。

key(keyID)

返回指定 ID 的 key 名字。

keyID 只接受整数,因为会通过 Math.floor(keyID) 来转换,所以支持非整数,如 '1.1''1a'true 等等,只是结果为 NaN 时取 0;若不存在,返回 null

已知问题:

  • Chrome v25 和 Firefox v19 的行为不一样:Chrome 会将 keys 按照字符串大小进行正排序,而 Firefox 则几乎是乱序,不可预测 key 的位置。
localStorage.setItem('google', 'what the hell?')
localStorage.setItem('miscrosoft', 'not bad')
localStorage.setItem('apple', 'great')

localStorage.key(0) // Chrome: apple
localStorage.key(1) // Chrome: google

length

返回 key 的总数。

事件

目前只支持一个事件:storage

if (window.addEventListener) {
  window.addEventListener("storage", handle_storage, false);
} else {
  window.attachEvent("onstorage", handle_storage);
};

这段代码我偷懒从 Dive Into HTML5 搬过来的,专有的事件属性如下:

  • key:不解释
  • oldValue:旧值
  • newValue:新值
  • url:页面的 URL

url 有点特殊,原来是叫 uri 的,所以要兼容某些浏览器的话,最好两个都判断,较新的标准浏览器应该没有这个问题。

此事件不可终止,并且只有在 setItem()removeItem()clear() 确实影响了值才会触发:

localStorage.setItem('hello', 'world') // will fire
localStorage.clear() // will fire
localStorage.clear() // will not fire

另外,对触发页面的要求也很特别:会触发事件的页面并不是执行修改操作的页面,而是已打开的、共享同一个储存区的其他页面

最后,事件绑定只能绑定在 window 上。

以上仅在 Chrome v25 和 Firefox v19 上测试过。

→ 为什么 Google 要砍掉 Google Reader?

在 Google 宣布将会在 2013 年 7 月 1 日关闭 Google Reader 之后,Quora 就有了一个问题:「为什么 Google 要砍掉 Google Reader?」。

曾经担任过 Reader PM 的 Brian Shih 回答说:Google 会关闭 Reader,只是为了社交领域,比如 Google+,而在此之前,Google 已经三度尝试把 Reader 团队拉到社交产品的开发上:

  • 2008:OpenSocial
  • 2009:Buzz
  • 2010:Google+

因为 Facebook 一直在影响着互联网广告市场,以广告为主要收入的 Google 自然不会放弃这块蛋糕,会进入社交领域属于必然之举。

而声称「不作恶」的 Google,并没有声称「不赚钱」,没有直接盈利又无法和社交媒体抗衡(毕竟不是一回事)的 Reader 自然没有运营下去的价值。因此,Google 的广告策略也备受吐槽,比如 Google Glass 的恶搞视频(YouTube优酷)。

Reader 被砍掉确实让人难过,因为它不仅储存着很多不可访问的网站的文章,还有着成熟的第三方,不过天下无不散之筵席,所以并不需要太纠结于此,何况 Reeder、Feedly 甚至 Digg 都表示会做一些事情。

从某个角度来说,因 Reader 而停滞多年的 RSS 市场,可能会因此有难以想象的成长。

塞翁失马,焉知非福,不是吗?

→ Animate.css: CSS 动画懒人包

Animate.css 打包了常见的 CSS 动画代码,只要勾上然后按按钮就直接下载打包好的 CSS 文件,然后在 HTML 代码里加上对应的 class 就可以,相当便利。

→ Why I loved building Basecamp for iPhone in RubyMotion

37signals 在最近发布 Basecamp for iPhone,由于 37signals 是 Ruby 的坚定支持者,所以该 app 是由 RubyMotion 打造的,甚至开发工具也跳过了 Xcode。

在上架不久后,Nick 发了一篇文章来说明他们是为什么选择和怎样使用 RubyMotion 打造这款应用。

学习成本和 IDE 的缺陷

Nick 对使用 Objective-C 开发应用的看法时:「如果使用 Objective-C,就意味着我需要抛弃我现有的工具和工作流,然后学习新的 API、框架和更多的东西(如 IDE)」,并且提到他早年使用 Visual Basic 控件和 Visual Studio 时的不好经验,因此非常抗拒使用 Xcode 和 Interface Builder。

我相当同意 Nick 的观点,就像 CoffeeScriptBrython 和 JavaScript 的关系,对于 Ruby 或 Python 程序员来说,直接用前两者会少很多学习成本。

而 Xcode,说实话,稳定性还没 Visual Studio 好,在代码补全、文档、Interface Builder、应用发布等方面虽然会比一般编辑器要好,所以还能忍受缺陷,但如果有代替方案呢?

Auto Layout

Auto Layout 是 iOS 6 新加的 API,为马脸 iPhone 5 准备的:

# horizontal
"|-10-[switchButton]-10-|" 
"|-10-[helpButton]-10-|" 

# vertical
"|-15-[switchButton]-10-[helpButton(==switchButton)]-15-|"

第三方框架和类库

Nick 吐槽了 Objective-C 第三方框架和类库令人不满的现状:

  • (相对于 Ruby)没有令人满意的依赖管理工具,CocoaPods 做得很好,可是还不够
  • 大部分不在 CocoaPods 的框架或类库的 README 只是简单地使用「拖曳 .xcodeproj 文件到 Xcode」或「拖曳 .h.m 文件到你的项目」等等让人头痛的说明(谁叫你不用 Xcode :P)

CocoaPods 我也有在用,虽然它让使用第三方框架和类库变得简单了一些,但并不是很完美,如果能像 RubyGems 或 Node Packaged Modules 那样的话,就真的真的 save my ass 了。

调试

37signals 是使用 rakeTestFlight 来进行调试,而 RubyMotion 官方也提供了如何调试的指南

因为最近多了一些 iOS 的调试器,都很逆天的感觉,比如 SuperDB,所以在调试方面,可能脱离 Xcode 也不会造成很大的问题。

迁移到 Hexo

忙了两天,终于从 Octopress 迁移到 Hexo 了,订阅的朋友,如果收到了重复的更新请见谅。

迁移的过程中,最困难的是想要尽可能兼容原本在 Octopress 能用的东西,比如 linklog 的自定义样式。除此之外,真的深刻地感受到 Hexo 的优点,V8 引擎的快就不必说了,使用的 Stylus 和 EJS 都让人觉得舒服。Jekyll 抱着 Liquid 不放真是一大败笔。

接下来就是要为 Hexo 写一些插件,比如压缩 HTML,来达到最大的自定义。