在 Adobe AIR 的首页上，就给出了三种 AIR 编程的途径： Ajax – 主要编写 HTML 和 JavaScript 代码，对于经常编写 Web 应用的程序员们来说，很容易上手。 Flex – 我不太熟悉，应该是配置文件主导的一种方式吧，有可视化设计工具。 Flash – 利用可视化设计工具设计界面，配合编写 ActionScript 代码。 Flex 编程中应该也会用到大量的 AS 编程，但是 Ajax 方式的 AIR 呢？一开始，我认为它利用与 Web 编程几乎没有差别的环境吸引了以前熟悉 Web 应用的开发者，但是却牺牲了 Flash 强大的表现能力，如果用 JavaScript 实现 Flash 同等的动画效果，难度和复杂度应该会大很多。 但是很快我就发现这个顾虑是多余的。Adobe 的 livedocs 中就有一个页面教大家怎么在 HTML 页面中调用 AS 的 library：”Using ActionScript libraries within an HTML…

国庆回家，我一个朋友帮买的9月30号晚上的火车票，我们分头往西站走。 当时风声比较紧，天天超载去西站的一辆公交车也不敢跑了。不过天无绝人之路，四号线不是开通了么，正好也让我沐浴一下春风，分享改革开放三十年伟大成就，于是我计划先乘十号线，再换四号线到达西站。 四号线的地图给我的感觉，下面向东突出的部分就是北京西站，我也从来没有仔细辨认过那个字。之前坐火车去广东，跟旁边的人聊天，还说四号线就是通北京西站，他们还附和说是呢，后来看都是托…… 我悠哉游哉上了四号线，感觉挺不错，就是那么凉快的天，空调温度还开那么低，我冷倒也罢了，社会主义也禁不住你这么糟蹋啊。有点奇怪国庆前夕去西站的人怎么那么少，不过别想太多了，有座位真好。朋友打电话过来说你还有心情绕北京转圈啊，我不急，地铁又不堵车。 到了“北京×站”，我一下车，经过那个大柱子之后，又忍不住退回来，因为感觉柱子上的站名写错了。四处张望一番，发现到处写的都是“北京南站”，我一下懵了，一边往站外跑一边给朋友打电话——如果我为祖国牺牲了，你就一个人回家吧。此时距列车发车还有半小时，我也不清楚南站离西站到底有多远。骑三轮车的看我着急，说送到西站40块，真黑，我心里想，车票才二十几块，大不了明天再买一张，也不助长不正之风！这时开过来一出租车，司机师傅想进南站接个叫车的人，绕了好几圈都没找到进去的办法，正好拉着我一路顺风到了西站，我又一路狂奔拒绝出示身份证终于赶上了火车。 一个半小时后到达保定，住了一夜，第二天一早吃了一个半驴肉火烧，赶到人山人海的汽车站，设法挤上汽车，被超载和破烂不堪的公路折磨到家。 回到北京后上网看，果然又很多人认为四号线是通北京西站的……

Windows 7 新的一个小工具程序是截图工具，虽然还是比较鸡肋，但终归可以自选区域了。 不过有些时候，用它来截图的话，切换到截图工具的窗口，要截图的东西却已经没了，比如说上篇文章里的百度输入框自动提示。 这时候有个快捷键就解决问题了。我看到网上好多人在问截图工具的快捷键是什么，似乎大家都觉得 Windows 的帮助文档很没用。我在帮助里很快查到了 Ctrl+PrtScn，试了一下，果然可以。

最近需要写个 shell script，给定一个日期参数，它要得到该日期的前一天，然后做剩下的事。执行的时候就是这样： [code lang=’text’] # ./foo.sh 2009-03-01 [/code] 初看，这个问题有些棘手。最原始的办法是写个比较繁琐的函数，知道每个月分别是多少天，还要处理一下闰年的情况——这也有点太繁琐了，呵呵。 稍微看一下 date 命令，就发现利用它可以很方便的写出一个非常 stable 的函数。date 可以通过 -d 指定一个日期，然后用指定的格式输出。-d 不仅可以接受 “2009-03-01″ 或者 yesterday 这样的格式，还可以接受一个从 1970 年开始至今的秒数，当然也可以指定日期输出这样的秒数。如： [code lang=’text’] # date +%s 1252591191 # date -d @1252591191 +%F 2009-09-10 [/code] 这样，事情就变得很简单了。先用 date 命令将该日期转换成秒数，减去一天的秒数 86400，然后再转化成正常易读的日期格式，就可以了，不需要考虑复杂的大小月以及闰年问题。以下是简单的例子： [code lang=’bash’] #!/bin/sh function get_day_before { seconds=`date -d $1 +%s` seconds_yesterday=$((seconds – 86400))…

这几天用 Excel，发现点击里面的链接都会出来这么一个警告：“由于本机限制，该操作已被取消，请与系统管理员联系”。要是一般的链接也就算了，关键是有个 VBA 的 addon，很多功能都是用链接实现的，出现这样的错误就基本上不可用了。 搜索中文内容好几天，没有找到正确的解决办法，最后想想这个信息在英文的系统中会是什么样，于是在 Google 上搜到了这个页面，问题终于解决了。里面的回答每个都比中文的内容靠谱。 我最后使用的方法是，先让 Firefox 成为默认浏览器，然后再让 IE 成为默认浏览器，问题就解决了。 两点感想： 有时候配置编译 Linux 里面的软件，觉得遇到的问题非常难以解决。可是真遇到 Windows 里的问题，解决起来更加困难，而且这些问题一般都很弱智，很不可思议，微软给出的错误信息也很没用。 中文的内容太差了，且抄袭严重，抄袭时不加验证。

刚装了一个试用了一下，没有感觉到像 Vista 那么难用。微软总算重新站稳了脚跟，据说 Windows 7 的市场占有率已经是 Linux 的两倍，看来 Windows 依旧是桌面操作系统的统治者。 任务栏吸取了 Mac OS 的精华，做得像模像样，不需要再像以前那样翻来翻去找不到窗口了。不过同一程序有多个窗口时，点击任务栏图标不能使该组窗口获得焦点，仍需选择某一个窗口，我觉得这一点做得不太合适，不知道其他用户是怎么想的。 用户的主目录路径成了 C:\Users\username，这一点可以说也是 Unix 系统的经验，终于不再是繁琐的 Documents and Settings 了。Library 的概念也很不错，此外也应该还有很多我没有发现的优点，比如计算器稍微改进了一点。 现在有了个专门的“截图工具”，比 PrintScreen 稍微强了一点点，不过仍然没有随意调整截屏选区的功能。这应该是微软怕 SnagIt 之流没饭吃吧？呵呵。这样应该围绕这个操作系统会有一个更好的生态系统，反观国内的 51、校内，这一点上就做得太不厚道了。

前阵子在一个大项目中做了一个小的 tool，在本机上测试完成之后，放到 production 环境中去，却发现页面上的 Ajax 功能不能使用。 在 Firebug 的帮助下，很快就想到可能是因为 production 环境使用了 https，由于浏览器的安全限制，页面不允许随便请求 http 的页面。Ajax 请求的 url 其实就是本机的一个页面，不过因为 url 中没有写 protocol 以及 hostname，浏览器就默认是 http 了。 我解决的办法是用 JavaScript 生成完整的 url，然后再发送请求。我测试的环境是 Firefox，不知道其它浏览器中有没有同样的问题。

今天晚上跟同事们一起看电影 “UP”，挺不错，就是没吃饭，有点饿。不过电影看完的时候，又没有食欲。一个同事说想吃桂林米粉，于是就跟着一起去了。 初到那里，看到招牌挺不起眼的，在周围繁华街景的映衬下显得格格不入。不过进去之后就感觉舒服一些了，虽然里面的布局、通向二楼的窄小楼梯让人回想起大学时代校门口的小餐馆，但是相比之下干净多了。跟风点了个酸辣笋尖米粉，先来了两碗都让给同事了，不过我在旁边看得很想吃。终于等到之后，吃起来感觉还真的挺不错，汤稍微有点辣味，但是喝下去很舒服。 最近经常是在外面吃，还好久没遇见这样吃着好吃，吃完了也舒服的东西了。于是就上点评网写了条好评……在这里。所谓酒香不怕巷子深，这么小的店都让我给找到了——一方面也说明点评网的设计比较合理，我搜索“桂林米粉”然后按地域筛选，很快就找到它了。 人写点评，一般是感觉特别好，就像我今天这样的，或者是感觉特别烂，比如我前一段时间在住处旁边吃那个田园鸡火锅。这是我目前在点评网贡献的仅有的两条点评……一个指标特别好的话，会不自觉地其它方面的分数；某个指标特别差的话，自然地其它的印象也好不到哪儿去。有了这样强烈的感受，分享的欲望就随之很强烈，非常希望让别人也知道这里很好或者很差，让别人赶紧来或者千万不要来。

对于类似当当、京东、新蛋这样拥有海量商品目录的商家来说，全靠手工去找出针对每种商品的关键词然后上传到 Google AdWords 账户，恐怕不是特别可行。AdWords Editor 是非常优秀的软件，然而它的 scalability 有限，假设有上千万级别的关键词，即使 Adwords Editor 恐怕也无能为力。 AdWords API 对于这样的情景再适合不过了。利用 API 可以将海量的关键词自动地上传到 AdWords，更能方便地将它们在 Google 的花费、表现跟自己的商品数据库对接，实现投入产出比的及时计算，对市场的变化作出快速反应，从线上广告的角度让利益最大化。对于如此大量的数据，仍然可以在很细的粒度上对广告做优化。 听起来很美好，可是实际做的话，就会发现一些让我们很烦恼的问题。Google 的系统足够稳定，非常值得信赖，我们的代码也很容易写得完全正确——AdWords 的 SOAP API 很简单，照着 Google 给的例子写就可以了吧。但是，网络却不是那么稳定，即使传输是基于具有纠错能力的 TCP，只要网线一拔，再强的纠错、重传也是白搭。所以光看 Google 的例子不行，程序需要更强的生命力。 记录足够的日志 不管你的程序多么 robust，遇到断电也得歇菜（除非你有昂贵的保障系统保证这个概率极低），所以至少你得知道它死在什么地方了，这时 log 是必不可少的。 此外，大批量的操作中必然会遇到一些错误，但又不必因为这些错误让任务就此停止，这样的错误就应该记录在日志中，等上传结束后供认核查。 check before add 这是 Google 的建议。广告创意上传之前要 check 一下，关键词也要。看到有问题的就删掉（或者加个解释传上去），然后再上传。应用了这个机制，即使你不小心尝试上传重复的关键词，也不会导致错误。 尽量恢复错误 最常见的问题出在网络连接上。TCP 再可靠，也终有它失败的时候。即使网线没被拔掉，在数百万的请求中，有那么一小撮出问题是很正常的。按照 Google 的例子，遇到任何异常都会退出。当你第二天早上兴致勃勃去查看昨晚开始的一个上传任务时，发现它实际上没上传几个就遇到异常退出了，可想而知会多么沮丧…… 认清这一点，我们搬过来 Google 的示例程序之后，就应该改造一下 Google 的例子。每个 SOAP…

在 AdWords API 的开发中遇到这样的 Exception，总是让人感到很迷惑——Google 为什么把它的服务器内部错误直接给我们看呢？按理说应该告诉我们到底我们的输入数据错在哪里…… 今天在调用 updateCriteria 的时候又遇见了这个错误，经过一番搜索之后，在这里找到了答案： http://groups.google.co.uk/group/adwords-api/msg/3a311805b76e37f4 哦，原来是因为我没有加 “criterionType” 这个属性。Criterion 有两个 subclass —— Keyword 和 Website，没有 criterionType 的话，Google 就不知道我们要操作的是哪一种类型了。 关键是 adwords4r 的 examples 太少，没有覆盖 API 的全部，在调用 addCriteria 的时候，很自然地把例子里地代码复制过来改改就好了，但是 updateCriteria 的时候，就没有例子可供参考了。而 Google 给的文档中，并没有将 criterionType 列在 “Required fields” 之中（大概该文档倾向于给使用 Java client 的人看吧）。 另外，我觉得在添加关键词的时候指定 criterionType 是合理的，但是在 update 的时候，Google 根据我们提供的 id 和 adGroupId，已经完全可以确定该 criterion 的 type…