PageSpeed Outgoing Bandwidth $0.39/ GByte, App Engine 中可以直接启用

不仅仅是 CDN，还能优化，比如合并 js, css，甚至可以优化外站的资源

@clww 请教一下，现在 Feedly 哪些部分在用自己的 后台？Web 版貌似是通过 后台插件 与 Google Reader 同步

@SharkIng 不是 GAE。

https://cloud.google.com/products/compute-engine

@wwqgtxx 只要国内用户大量使用，迟早都得被墙。
GCE 也不算便宜，流量费用另计，估计会稍稍好一点。GAE 被墙是很大部分原因是因为免费额度而吸引许多翻墙用户。

@DH 还没测试。问问 @ericFork 看

奇怪，之前 Feedly 不是说 要在 GAE 上重建 Google Reader API 吗？

@est 我也期待支持 nodejs，不过据说 1.7.8 python sdk 中已经发现 PHP runtime 的踪迹了

另外，GAE 的 instance 方式是否适合 nodejs 事件驱动模型 ？

@Muninn @oldcai 可能是为了方便移植现有 PHP 应用到 GAE，GAE/PHP 配合 Cloud SQL 可以让许多现有 CMS 应用在 GAE 上运行

Cloud SQL 在 6月3日 要推出一个 D0 的套餐，$0.36/天，不知道和这个有没关系：https://developers.google.com/cloud-sql/docs/billing

＝＝＝＝＝

GAE 已经支持 Sockets (preview)，可以访问 Redis 等外部服务，如果在 Google Compute Engine 上部署自己的 NoSQL 服务应该可以大大降低 GAE Datastore 成本：http://www.xhroot.com/blog/2013/04/12/accessing-redis-from-google-app-engine/

@hzlzh Godaddy 也可以签发 Starfield 证书，准备切换成 Starfield 看看

另外，这个承认度是怎么评估的？用户端？我用其它工具测试没发现问题，浏览器打开也正常

我直接 Google "Godaddy SSL 证书" 得到的是 http://www.godaddy.com/compare/gdcompare3_ssl.aspx?gclid=CPfmp8_S7LYCFWXZQgodMC0AiQ&isc=zssl211a&ef_id=UPiyFQAAR7ESbHBh:20130428053729:s

怕误以为是推广，我去掉后边的参数了，你用这个 url 看看，或者直接到 Google 搜索


不过，比较奇怪，我的证书是128位，Godaddy 自己的网址我打开也是 128，而 https://www.v2ex.com 是256 (也是 Godaddy 签发的证书)

你可以自己搭服务，网上到处是 readability 之类的开源实现，并发请求不多的话，对服务器要求很低

只不过这些代码没有对中文网页特别优化，可能会有少许问题

@aisin 每种算法具体到不同网页表现不同，不好用个别网站的网页来推断一个算法的好坏

Readability 不是简单取页面的 head->title，而是首先设法从正文中获得标题，然后再在正文中的扣除标题，避免重复。这样的好处是可以获得更准确的标题，比如 许多网站在 head->title 中加了许多网站信息。不过按理说，最坏情况下，至少可以用 head->title，不至于提取不到标题

这些算法在提取不到的时候，会用整个网页的内容然后根据一些规则做一下过滤，获得的结果也勉强可以接受

Readability 新版改为后台处理，有可能后台无法抓取到你的网页，所以导致抓取失败。我对他的新版本不了解

以前比较过几个算法，总的来说 Readability 相对 Instapaper 和 Pocket 还是要更好一些，后来 Pocket 扩大规模了，可能有人手专门对提取算法做了改进了

大部分网页正文提取算法都是根据开源的 Readability 算法修改的，主要是计算文本密度，以及 link 密度，评估最可能的节点，然后在扣除 评论之类的内容。算法依赖经验参数，不容易改进。这种算法确实如 lookhi 说的，“猜”测的。

后来 Readability 改为闭源，算法在后台运行，应该有一些网页是根据数据来改进。

Chrome 插件 Send to Kindle (by Klip.me) 的正文提取算法是另一种方法，模仿人眼的对焦过程，先在页面的可视区域找到 “种子”，然后在扩大/收缩。并且能够根据用户的高亮选择自动训练出对焦数据。但是这种方法需要网页加载渲染完毕，适合作为插件，不适合在 Server 端运行。相对来说，对焦算法算是 “推”测的

还有一种方法，通过“同构分析”反推出网页的“生成”结构，diffbot 可能用的是这种方法。这种方法我之前做过试验，能获得结果的情况下准确度高。不过当时算法没做完，许多网站没有反推出结构。

好像思路分裂过，抓的是哪个？

http://www.quora.com/What-are-the-alternatives-for-google-reader

大部分现有的GR移动客户端都是基于 Google Reader，如greader,press,reeder，这类应用除非开发自己的后台服务或者有替代服务出现，否则到时无法正常工作

应该有些开发在进行中，不过维持运行这么个后台服务有相当成本，可能大部分新的服务会采取收费订阅方式

AppScale，GAE 的开源版本

https://github.com/AppScale/appscale

从国内访问很慢，从 GAE 访问 Linode Fremont 正常

@Miaoz 岛外未来海岸那边的玛琪亚朵咖啡不错，挨着海边，白天人少，很清静。岛内可以直接从第一码头做船到嵩屿。

我很久没去了，不知道现在如何。

看看有线电视的线能不能拽动。我之前也遇到这个问题，后来光纤线是通过有线电视线进来，再把有线电视线拉回来就可以。

@arg0 是的，之前好像 Hacker News 就对 GAE 不友好，现在不知道如何

@sohoer 爬完了不用存储？

GAE Datastore 的收费是高的离谱，100 万次写入 1$。问题是一个索引字段的更新按2次写入来算，创建一个正常设计的对象结构可能都会导致几十次的写入，创建，更新，删除都计算费用

Google Group 上看见一个家伙把 Datastore 清除，还没清除完，几千美元出去了