Chrome Dev 27.x 版本吗？似乎和 Function.binding 有关

Skype 世界通，可以打国内，10000分钟/月，3个月 120元

Kindle 3G 以前确实是不限流量，现在好像是限制为50M／月了

Amazon Kindle 的 3G 是通过 AT&T，成本相对本地流量高很多，Amazon 官方价格是 传送文档1M/0.99$。后来确实有人研究出通过 Kindle 共享上网，然后国内用户挺踊跃，不知道和 Amazon 后来修改政策是否有关。其实任何服务都有一个公平使用原则，有人滥用，最后是所有用户买单

朋友总结说：有些人，为了自己便宜哪怕几块钱也不在乎让别人多花费几百块钱

@lin 如果只是要第一眼看到 footer，可以用 position:fixed

例如：

.footer {
position:fixed;
bottom:0px;
width: 100%;
}

不过这样会一直固定在底部，你可以加上事件处理或setTimeout，修改 footer 的 position 属性

可以在 domready 后，调整 scrollTop

例如：document.body.scrollTop = 100000;

去这边看看吧，国内 E-INK 爱好者比较集中的地方：

http://www.hi-pda.com/forum/forumdisplay.php?fid=59

你问的问题之前在上边有看见过，不知道最后解决没有。

@yyfearth @yyfearth iCloud 或许可以同步一本书之类的，但不能处理数据的记录级比较更新

@Harp 输出的还是JSON格式，只不过这个是 Google Reader 的 API，能保证可以下载下来

@sobigfish “为什么不能是本地化的client 啊”

在 http://www.v2ex.com/t/63135 7 楼有解释过，拷贝这里并补充 4,5 点

如果没有 Google Reader 这种提供 API 服务的中心：
1, 标星，已读 等状态在不同应用，甚至相同应用相同帐号在不同设备之间同步都会成为问题。用户的迁移成本也提高

2, 有较多订阅源的用户来说本地直接抓取效率很低
如果订阅源不支持根据上次抓取时间来返回结果的话（比如通过 header 中的 ETag），对订阅源和客户端都是负担，尤其全文 feed

3, 客户端要处理 rss 和 atom 两种格式，许多 feed 的输出并不规范，需要不少错误处理

4, 客户端并发请求数量有限，一些订阅源的请求时延可能会导致客户端等待很久

5, 越来越多用户通过移动设备阅读，对流量与等待时间有更高要求


比如，获得最新更新，从 Google 服务器只要一个请求，GET 0/stream/contents/?n=请求数量&ot=上次更新时间&xt=user/-/state/com.google/read，通常可以在几秒内完成更新

而如果完全在客户端实现，需要逐一向各个订阅源请求，并且每个订阅源可能都会返回最新的 n 篇文章


不知道 Digg 最后能否以应用开发商能负担的起的成本提供得起这种 API

@chrisyipw
@yyfearth

如果没有 Google Reader 这种提供 API 服务的中心：
1, 标星，已读 等状态在不同应用，甚至相同应用相同帐号在不同设备之间同步都会成为问题。用户的迁移成本也提高

2, 有较多订阅源的用户来说本地直接抓取效率很低
如果订阅源不支持根据上次抓取时间来返回结果的话（比如通过 header 中的 ETag），对订阅源和客户端都是负担，尤其全文 feed

3, 客户端要处理 rss 和 atom 两种格式，许多 feed 的输出并不规范，需要不少错误处理


比如，获得最新更新，从 Google 服务器只要一个请求，GET 0/stream/contents/?n=请求数量&ot=上次更新时间&xt=user/-/state/com.google/read，通常可以在几秒内完成更新

而如果在客户端，需要逐一向各个订阅源请求，并且每个订阅源可能都会返回最新的 n 篇文章


不知道 Digg 最后能否以应用开发商能负担的起的成本提供得起这种 API

Reeder 在 Twitter 上说不会和 Google Reader 一起 Over。许多 客户端应该都还在犹豫中。

最差情况下就是从客户端抓阅读源，退回到八年前的技术。

@Harp "N多加了星的文章不知道怎么办"

登录 Google Reader 后，直接在浏览器输入这个地址看看：http://www.google.com/reader/api/0/stream/contents/user/-/state/com.google/starred?n=1000&ot=0&likes=false&comments=false&client=reader

输出是 JSON 格式，如果没抓全，可以加上 c＝#continuation# 参数

Google Reader 也不是实时抓取，更新频繁的 feed 抓取会更及时些

听说 Digg 要重新实现 Reader 并提供 API ： http://blog.digg.com/post/45355701332/were-building-a-reader

Google Reader 相比其他“社会化”，“个性化”阅读形式来说，读者更容易控制“噪音”，期待好的替代方案出现

没听说过 “环保基本靠风” 这句话吗？

有一天大约半夜两点，北京的 PM2.5 = 4，之前刮风了

Chrome 扩展 API 可以截取当前 tab 可视区域的内容，然后通过滚动可以多次截取，再把多个截图拼接起来，拼接可以通过 Canvas

Titanium 实际上是把不同平台的 API 重新封装一遍 （http://docs.appcelerator.com/titanium/latest/#!/api），用 JavaScript 作为编程语言。具有跨平台的潜力，但实际开发时还是得为不同平台调整匹配。

Titanium 已经非常 Native，UI 都是对应平台的，封装的 API 都有源码（对应平台语言），必要时可以自己修改；少数 API 不支持的功能，或者用 JavaScript 性能不够理想时（比如图像处理），可以用其它语言实现扩展模块来达到 (http://docs.appcelerator.com/titanium/latest/#!/guide/Titanium_Module_Concepts)。有些语言的限制也可以通过扩展模块达到，例如，Titanium 不支持多线程，可以用模块实现 worker。也就是说，Titanium 受 API 和 语言的限制比较小，基本可以设法绕过。

Titanium 在模拟器下调试比较方便，不支持在实际机器上断点调试（后来可能支持了）

Titanium 一直在发展中，差不多每 3 个月有个大的版本更新（http://developer.appcelerator.com/blog/ ）

Titanium 目前支持 iOS, Android, BlackBerry, 预计 2013 下半年支持 Windows Phone

我当时选择用 Titanium 主要是因为不想重新有折腾一种新的编程语言，对 JavaScript 也还比较熟悉，实际使用下来也遇到不少问题，基本都能 Google 到解决方案


真正同时了解 Titanium 和 PhoneGap 的开发者恐怕并不多，你所听到的往往都是片面的，我也仅仅是对 Titanium 熟悉一点。

不过 ProxyDNS 的目的是为了“Surf Internet with no geographic restrictions.” 从而可以方便的访问 有地区限制的服务，例如 Hulu, Netflix 等

http://proxydns.co/ 用的可能也是相同的技术

=====

How does ProxyDNS works?

ProxyDNS works mostly like a normal DNS, not altering your normal browsing in any way, but only for those sites that are blocked for you. It all happens so transparently that you just notice the fact that there is no blocking anymore.
Reliable: The Cloud guarantees high bandwith.
Secure: Only the traffic to blocked sites get proxyed.
Simple: Designed to be completely transparent.
Smart: ProxyDNS takes care of everything for you.
Easy: Just a DNS config, that's all.

Google App Engine 支持文档转换，能够把 HTML 转成 PDF，可以在 GAE 上写一段小程序来处理