突然体会到，iPad 放在 dock 上看，无比登对。 7 hours 49 minutes ago
无法回到过去，因而有志。志和博客不同，一个是历史记录，一个是个人出版。志和 twitter 相近，但如今 twitter 多为社交，包含但不限于志。自己的志，或琐碎，或隐私，没必要也不该公布。曾记过一纸本日志，猎猎回翻，仿佛穿梭时空观望过去的自己。很有意思。纸上涂画很有快意，但终归有所不便，无法想到就记，不免疏漏，也无索引。
现在，我决定按照这样的方式继续。mac 上用 tweeite 写志到另外的 twitter 帐号。因为 tweetie 实在是太方便了，cmd+i 调出窗口写，完了 cmd+enter 发布。完全不用鼠标。没有 mac 就用 iphone，官方的 twitter for iphone 最顺手，设好 api 无需翻墙，直接发推。数据都在云端，剩下的无非重构显示形式，这个不着急。
这个 timeline 才是最干净，最符合其意义的 timeline。所谓日志。
新发 blog 用 FriendFeed 订阅再推送到 Twitter 有两个缺点：时延和墙。既然我的主机在墙外，为什么不直接用插件发呢？试试看 WordPress Tweeter，走 Twitter API，很好很强大。此文顺做测试。
最近继续关注了下，发现下面三个网站不错：
UI 上 shelfari 更接近我的想法，但另外两个还提供 API。总体上来说 goodreads 更细致些。特别是 goodreads 上允许用户标注是否拥有，是否愿意交换，甚至允许加注 BookCrossing 的编号，追踪书籍传递历史。但 goodreads 的学究气重了些，并不直观。
很有意思，刚才发了关于 IRC 聊天工具 Colloquy 的 blog，洗完奶瓶回来发现 Gmail 里收到 Twitter 发来的通知，一个叫做 chatonic_room 的人 follow 了我。当然一眼就知道是个机器人，上面只有一条 tweet，一个连接，指向一个在线聊天工具网站，还有 for adults，呵呵。所以利用 Twitter 做营销应该也是不错的。
实际上的信息流有点复杂：
重构代码的过程中，发现原来可以工作的代码返回了错误。错误是 Google API 返回的：Abstract keyValue without superclass.
因为要更新一组 Criterion ，在重构的过程中，阅读文档，去掉了文档中没有提到的必要元素：criterionType。然后在极慢的网速中等待不断的 API 交互后，总还是报错。阅读了邮件组中的两个相关会话，尝试了各种可能性后，还是未果。
终于，在分析别人的 xml 交互文档后，注意到 criterionType 这个字段。这才恍然大悟 — Criterion 是抽象类，有两个派生类 Keyword 和 Website。Abstract keyValue without superclass 所要说的就是它不知道你这个 Criterion 到底是哪一个子类（我被 KeyValue 吸引过去了，没有仔细考虑 superclass）。我觉得这点有些弱智，既然提供了 Criterion 的 id 不就什么都清楚了么，何苦同时提交 CriterionType 呢。（没有测试过如果提交错误的 Type 值会发生什么。应该会报错，既然会报错，必定经过了检验，必定取出过原始数据，那又何必再次提交？）正是这个看起来不该是这样的问题却恰恰成为了问题。
或许 Google 处于性能优化的考虑，不过也该在文档中说明清楚啊，害得我浪费了 2 个多小时。
看起来是个很简单的功能，Google 今天才宣称要在 5 月份开始逐步的邀请新老用户去设定自己所在的时区。事实上这并不简单。投放广告的统计数据原本是所有账号都在同一时刻计算而得的，不同的账户设定不同的时区之后，就会在不同的“当地时间”计算统计数据。当然，这里所说的是根据设定的时区作为计算数据段的边界。这是继 Google Analytics 推出设定时区之后的又一类似举措。
Google 真得很勤奋。对于 AdWords 来说，这段时间以来做了不小优化和改进。比较显著的就是界面上的变化，看源代码也会发现，比原来更加简洁和清晰。值得注意的是，AdWords 的 html 源代码并不符合 XHTML 的标准。其中充斥了大量的 table ，当然它也使用了一些基于 css 的布局定义。对于圆弧的边角，Google 并没有使用那些技巧性很强的 js 库，只是在 table 里面加了两个 div 来赋予不同的背景图。所以，像 alistapart.com 所追求的纯粹的 xhtml 技术和技巧之外，Google 的做法更加务实些：兼容性更好，更直观，开发成本更低。按照 Agile 的原则，能用就行，然后，也就是现在和将来，不断的逐步通过重构来抽象，完善。
Google 真的很不容易。
客户看到他的广告组中所有的关键字产生的费用的总和与在广告系列中看到的总计相比，出入达 50%，于是提出质疑。
我相信有果必有因，所以不用着急，我一定可以找到产生这个问题的根源。首先我认为不是我的计算错误。我的数据直接来自 API 。于是第一反应就是统计的时间范围不同，很快这个假设被排除。进而我仔细察看了 Google 界面中的数据，终于发现，从一个广告组的所有关键字取回的 StatsRecord 数据累加后等于“内容网站广告总计”，加上“搜索网站广告总计”中的数字，就完美等于广告组的 StatsRecord 返回的数据。也就是说：
AdGroup->StatsRecord = AdGroup->Criterions->StatsRecord + AdGroup->search_total_stats_record
问题是，API 不提供直接的操作取得搜索网站的统计数据。翻阅了它的讨论组，直到可以通过 Report 服务来提交一个 ReportJob 然后获取这些数据。不过我很不高兴这样做，麻烦。不符合 XP 的精神。所幸我只需要 clicks, impressions, cost 的数据就可以了，不需要 averagePosition（或者不提供给客户这个信息）。所以我完全可以通过相减的方式得到“搜索网站广告总计”的数据。
三下五除二，基本上完成了统计报告的更动。
至于为什么 Google 不提供这些，谁都不清楚，可能是系统演进过程中产生的问题。看到邮件组中还是有很多人抱怨 Google 没有提供更为良好的针对开发人员的文档 — 他们发现可以在目标 URL 中使用一些标签，Google 会替换这些标签为相应的关键字和站点 URL 。他们籍此发现即便是搜索网站中的广告，仍然是和特定的关键字相关联的，为何 Google 没有针对每个关键字纪录相应的展示点击行为，而放到了上一层次，也就是广告组的级别纪录总和。
今年七月一日，Google 的 AdWords API 要做一番比较大的改动。第一，对 API 的操作不再是免费的了。每个操作都有一定数量的配额，交互一次，就要对这些配额计费，千个配额价格 $0.25。第二，使用条款的修订。
所以，为了节约配额，可能要对提交的操作斤斤计较，能够缓存的都缓存起来，避免重复无谓的配额消费。
通过 API 管理 Adwords 账户的时候，会碰到一些奇怪的问题。这些问题在 API 文档中是没有明确讲解的，只能从相关的 groups 中查找。这是让我觉得有些遗憾的地方。
昨天碰到一个怪问题，通过 API 提交的广告，每个关键字都给予了一个高得有些离谱的最低价格。如果删掉这些关键字，再重新创建的话，则恢复到较合理的（比较低的）最低价格。于是多方排查，把各种可能的原因都一一排除，最后才知道，在新建广告系列的时候，最后创建 Creative （我们看到的广告布局和内容）以及对应的关键字(Keyword)的时候，是讲究先后顺序的。关键字的最低价格的评估是根据 Creative 的内容而定。如果没有 Creative 那么关键字的价格多半会定在 $5 这个水平上。所以调整一下提交顺序：先增加 Creative 然后再提交各个关键字，就都正常了。
此外，如果选择客户群体的语言是英文，而提交的广告包含拼写错误的话，API 是不允许你提交的。可以通过另一个字段申请人工审核，只要在该字段中简要说明原因即可。不过也未必能通过。要看情况的。