惊闻 Pocket 关站

今天用 Pocket 的 Chrome 插件把两篇文章收藏了起来。收藏过程比较慢，引起了我的一点点注意。想起已经很久没去整理过里面的文章，于是打开了网站，才惊讶地发现一个月前它已经宣布要关闭了。

图片来自网络

还好留了三个月给用户导出数据，10 月 8 日截止。赶紧去申请，收到邮件一看，一个不到 700 行的 csv，压缩了还没有 50KB。说我数据少吧，600 多篇文章也不算少了。但下载附件的时候我就心里一惊：估计只有标题和 URL，那些爬下来的内容，怕是都没了。

我当初用 Pocket 不用 Delicious（顺便说一句，Maciej Cegłowski 现在连更新 Let's Encrypt 的 SSL 证书的 acme.sh 脚本也懒得去放一个了）的原因，其实就是因为 Delicious 只保存链接，不存内容。「社交」是我并不需要的功能，「推荐」也是。Pocket 后来渐渐地也很多页面都爬不下来内容了，所以我也渐渐远离了它，只是通过 Chrome 插件往里面扔那种「将来可能会有用」的东西，但再也不去看。一个网站若是用户都是我这种样子，关闭也是必然的，我应该早有心理准备才对。

当今「互联网」的一个很大的问题，就是许多网页已经消失了，不见了。有伏地魔的原因，有赵公明的原因，也有乔布斯的原因。不管怎么说，事实就是如此。我试了我导出的数据里面比较古早的几个 URL，都打不开了。有的虽然页面没了，网站还在，还有的甚至连网站都没有了。我现在甚至开始有点怀念 Evernote，但它其实也没有多好用。Web 不管几点零的时代，好像都已经过去了。

我现在转到了 Instapaper 下面，刚开始用，还没什么心得。尝试导入 Pocket 的数据，Instapaper 告诉我还要等几个小时。从早上到现在也还没动静，我觉得这是好事。花的时间多，意味着它真的会去爬内容，否则只是 URL 应该几个毫秒就结束了。

Instapaper 的 Premium 会员 不便宜（$5.99/Mo，$59.99/Yr），比 Pinboard 的含永久存档和全文检索功能的会员（$39/Yr）还要贵。总之对于我而言都有点肉疼，因为我还买了 Medium 和 Dropbox，而且普通中国人都比较穷。

让 AI 对比了一下，我最后如果要成为付费用户，可能还是会去考虑 Pinboard 吧。我的核心需求是永久存档，全文检索也是羡慕的，笔记并不是必须的。毕竟 Instapaper 免费也不是不能用。

而且，见鬼，我对 Maciej Cegłowski 的不少理念还挺认同的。

GAE 的 Frontend Instance Hours 高居不下咋办？

架设 GAE 用了 GoAgent 之后，对于 Dashborad 中的 Frontend Instance Hours 一项数字如此之高有些不解。查了 Google，发现有同样疑问的还有很多人。于是翻了翻 Google 的文档，做了做实验，基本上弄明白了。

其实这个数字高也不代表什么。不信你可以架一个 Hello world 上去，先不要急着访问，只是打开 Dashboard 看看。Number of Instances 应该是 0，Frontend Instance Hours 也是 0。然后再打开 WebBrowser 访问一下你的 Hello world，再看 Dashboard。现在 Number of Instances 是 1 了，而 Frontend Instance Hours 就开始了渐渐的增长，哪怕你把 WebBrowser 马上关掉也是如此。
说白了，Frontend Instance Hours 就是 GAE 记录的服务实例运行所用掉的时间配额。没访问过的话，实例数是 0。而一旦有 HTTP 请求，GAE 就得启动一个实例来响应这个请求。运行这个实例需要耗费相应的 CPU 和内存资源，于是 GAE 就开始计费了。实例不停，Frontend Instance Hours 就会一直长。而 GAE 为了能在短时间内响应下一个请求，通常是不会很快把实例给停掉的。（至于到底会等多久才停实例，据说是 15 分钟无新请求就不再增长 Frontend Instance Hours，但实例数还在，估计挂起了。不过你可以手动停掉它。）
既然叫做「Hours」，增长的速度当然就是指的实例实际运行的时间。实例跑了一个小时，那么 Frontend Instance Hours 就会增加 1.00。我没测过 Google 会不会在计费上面耍点小手段，大抵是不会的，个人感觉也基本上差不多。
所以看着 Frontend Instance Hours 一点一点地增长，也完全不必心慌。一天 24 小时，GAE 给了 28 的免费配额，如果你只跑一个实例，是不可能用完的。用到 23.99，下一分钟就第二天，重新计算，清零了。对于只跑 GoAgent 的用户，实在不放心的话，我觉得用两个 AppID 来跑也完全足够了。当然，流量超了的情况另算。

那么什么时候 Frontend Instance Hours 会超过 24 呢？据说一个请求如果在等待了超过 Min Pending Latency 的时间之后，仍然没有实例能来处理它，那么 GAE 就会开一个新实例来做这个事情。所以 GAE 给了免费用户 28 个 Frontend Instance Hours。Google 的解释是为了让用户能够应对一些紧急状况。
另外，这个「紧急情况」，除了指访问量大导致的多实例运行，也包括了一个功能，就是 GAE 允许用户调高 Frontend Instance Class。F2 级就比 F1 级多用一倍的计算资源，而 Frontend Instance Hours 也就增长得快一倍。这种情况下，多出来的 4 个小时就可以视为 GAE 给的「加力」之类的东西了。如果你只想在短期内进行一个高强度的计算，那么可以考虑用 F4 来跑一个 APP 看看。

CWebBrowser2 打开 PDF 后退出时崩溃问题的解决

用嵌入在对话框中的 CWebBrowser2 控件打开 PDF 文档后，主程序退出时抛了 Access Violation。扔异常的是 ACRORD32.DLL，ADOBE 自己的玩意儿，调用栈中也看不出什么，主程序看来都快退完了，显然和什么东西没关干净有关。

照例，国产没货。最后在这里找到了：

• http://forums.adobe.com/message/2373918（链接已失效）：贴子中的人也是一筹莫展了快一年，最后按下面的办法解决了；
• http://stackoverflow.com/questions/1359616/axacropdflib-at-closing-problem-c：简单地说，的确是没关干净。加上一句 CoFreeUnusedLibraries() 就万事大吉了。

以上方法，在 VC6 sp6 / WinXP 的 Debug 和 Release 编译上都试过。除此之外就不知道了。

据说，问题和 Adobe Reader 9 有关。V8 没有这个问题，因为 V8 是单一实例，而 V9 不是。照此一来，内存泄漏可能也是难免的。

关于表格内文字换行的再研究

通常，搞 Web 开发的都会遇到这个问题，就是苦心设计的表格被讨厌的一连串英文字符给撑破了。最常见的是自己开发的论坛或留言板，如果有一个情绪激动的家伙打了百来个英文的感叹号，那往往就会出现内容在这些感叹号上不换行，结果让表格撑破，页面变得乱七八糟。

解决这个问题的办法，相信很多朋友都知道了。通过 CSS 中指定几个样式，可以比较满意地解决这个问题。一个是 word-break:break-all，一个是 word-wrap:break-word，表格中的文字则还有一个是 table 标签的 table-layout:fixed 样式。这三个样式给定之后，就不会再遇到表格被文字顶破的问题了。

稍稍解释一下上面三个样式。word-break:break-all 是让英文单词中部的换行成为可能，比如

beautiful

word-break 样式还有另外两个取值。一个是 normal，就是通常默认的，对中文断字而对英文单词不断的情况。另一个是 keep-all，是对中文，准确地说是亚洲文字也不断字。然而，和字面上的理解意思不同，keep-all 并不能让一个英文句子不被换行。要做到这一点的方法，稍后我会谈到。

word-wrap:break-word 是让连续的符号（如 ! 号）之间进行断字成为可能。这是解决那种一大串感叹号造成的问题的一个关键。没有这个样式的话，对连续符号的断字不会发生。

另一个关键是 table-layout:fixed。它指明说表格不要去试图自己计算宽度，就按照 HTML 中定义的宽度来显示就好。只有当 table-layout:fixed 和 word-wrap:break-word 同时指定时，针对连续符号的断字才会正确发生。缺少 table-layout:fixed，断字不会发生，表格仍被撑大。缺少 word-wrap:break-word，则表格不会被撑大，但断字不会发生，超过显示区域的内容将被 hide。

好了，知道了如何让所有内容都断字换行之后，另一个问题来了：如何让所有内容都不断字换行？

我们知道，即使指定 word-break:keep-all 样式，也无法阻止一个英文句子在空格处不被换行。而且汉字中的某些标点符号，浏览器也会很「智能」地把它给换行掉（起码IE会，这就足够了）。然而，一个好消息是，虽然要求不断字的情况远比要求断字要少见，但它的实现方法却相当简单。你只要把内容用 <nobr></nobr> 标签对括起来就行。被 <nobr></nobr> 标签对括起来的内容，浏览器绝对不会对它进行换行。只要记住这一点就很好办了。

不过，想让内容不换行的同时，通常并不希望表格宽度因此而变得不确定。因此，常常也需要指定一个 table-layout:fixed 的样式。这样，就可以让表格宽度维持设计时的大小不变，或者通过指定相对宽度来维持一个固定的比率，而并不受单元格中内容的任何影响。在设计自适应屏幕宽度的标题列表表格时，这个技术也许会有些用处。

JS 在 URL 转码时遇到的加号问题

URL 参数中出现了半角的加号，因此需要转码。

相关 JS 函数有 encodeURI() 和 encodeURIComponent()。根据 MSDN 的说法，使用了 encodeURI()，无效，加号还是加号。

encodeURIComponent() 是对所有的字符进行转码。根据 MSDN 的说法，它只是额外对「/」、「?」等字符进行了处理，并没有提到「+」字符。然而实验对比的结果，encodeURI() 不处理半角加号，encodeURIComponent() 处理。

看来 MSDN 也有不少问题。也许是因为我的 MSDN 比较老的缘故？可能吧。