昨天中午进小区门口的时候，在水果摊买了半块西瓜。老板当下给切开一个西瓜，给我一半。
老婆晚上下班回来路过小区水果摊，也买了半块西瓜。因为她把手机忘在公司了，所以不知道我也买了。等她把西瓜拿回来，我一看，似曾相识啊。搬出我买的半块，凹凸一致。往上一扣，真是天生的一对：
看来老板的西瓜卖的不是太好啊 :)
关闭了所有文章的评论，打算重新整理一下自己的网站，包括 blog 在内。
可能将来就不再使用 wordpress 了。
过半个月或者一个月，你就会看见我的新网站巍然屹立在 linode 上，以全新的技术（对我来说）驱动。
关闭评论，就可以把数据拿回来随便玩了。
公司在 SOHO 尚都，看起来很时尚很前卫的楼。租的是一间 LOFT，空间超大，非常开阔，墙壁多半都是玻璃，很亮堂。不过住在里面，很快就发现缺点不必优点少：
- 空调－我们租的 LOFT 据说是业主自己装的空调，所以不好用。由于屋顶特别高，所以夏天凉风吹下来就变热了（每人发一把扇子），冬天暖风吹下来就变冷了（那时我还没来，估计大家都穿着羽绒服）。后来又租了一件普通的办公室，中央空调，依旧不好用，三天两头打电话让物业来修。
- 漏雨－有一台小服务器放在窗台上（窗台很宽），某次下雨，第二天早上去，发现机器重启了，进而发现机器顶上还有下面都有不少水，于是检查前一天晚上是不是没关窗户。最终发现原因是“紧闭”的窗户漏水，需要定期让物业来涂密封胶。
- 网络－似乎大楼有专门的 IT 部门，住户不是跟网通、电信等 ISP 直接打交道，但是网络非常之不稳定，正好这几天尤其严重呢（这也是促发本文的重要因素），作为一家网络公司，遇到这样的情况真是窘迫。为了提供原始的“failover”，同事故意给两间办公室选择了不同的接入，但是……似乎效果不是很明显 :-)
- 电力－这个就不用细说了，我们的多台服务器都被摧残过许多次。搞得我每次在上面执行个较长事件的任务都得探一下风声，看看断电的可能性有多大。
周围也有其它的 SOHO 建筑，应该都是出自万科，同事说都是中看不中用。是啊，破烂的办公楼见的多了，但是从来没有遇到过空调、电力、网络都这么差劲的……
国庆回家，我一个朋友帮买的9月30号晚上的火车票，我们分头往西站走。
当时风声比较紧，天天超载去西站的一辆公交车也不敢跑了。不过天无绝人之路，四号线不是开通了么，正好也让我沐浴一下春风，分享改革开放三十年伟大成就，于是我计划先乘十号线，再换四号线到达西站。
四号线的地图给我的感觉，下面向东突出的部分就是北京西站，我也从来没有仔细辨认过那个字。之前坐火车去广东，跟旁边的人聊天，还说四号线就是通北京西站，他们还附和说是呢，后来看都是托……
我悠哉游哉上了四号线，感觉挺不错，就是那么凉快的天，空调温度还开那么低，我冷倒也罢了，社会主义也禁不住你这么糟蹋啊。有点奇怪国庆前夕去西站的人怎么那么少，不过别想太多了，有座位真好。朋友打电话过来说你还有心情绕北京转圈啊，我不急，地铁又不堵车。
到了“北京×站”，我一下车，经过那个大柱子之后，又忍不住退回来，因为感觉柱子上的站名写错了。四处张望一番，发现到处写的都是“北京南站”，我一下懵了，一边往站外跑一边给朋友打电话——如果我为祖国牺牲了，你就一个人回家吧。此时距列车发车还有半小时，我也不清楚南站离西站到底有多远。骑三轮车的看我着急，说送到西站40块，真黑，我心里想，车票才二十几块，大不了明天再买一张，也不助长不正之风！这时开过来一出租车，司机师傅想进南站接个叫车的人，绕了好几圈都没找到进去的办法，正好拉着我一路顺风到了西站，我又一路狂奔拒绝出示身份证终于赶上了火车。
一个半小时后到达保定，住了一夜，第二天一早吃了一个半驴肉火烧，赶到人山人海的汽车站，设法挤上汽车，被超载和破烂不堪的公路折磨到家。
回到北京后上网看，果然又很多人认为四号线是通北京西站的……
有阵子没这么开心过了，今天终于又看到了一个大笑话：
http://news.sina.com.cn/c/2009-09-17/103318670219.shtml
哈
哈
哈
文中的数字怀疑不怀疑倒不重要。有量无质，这科技也是山寨科技，劳动密集型科技。大批的“科技人力资源”找不到一口饭吃，大批的急需人才的企业找不到“科技人力资源”，想给人饭吃，但是没有人可以吃得下。
要创意没创意，要创新没创新，要实力没实力。
我过了一段不是单身却胜似单身的生活，而且这样的生活还要继续。我是个比较悲观的人，心里挂念着很多事，而且不善于往好处想。发生了不幸的事情，我也不知道该怎么去想。
我越来越觉得每天下班后以及周末心情就突然变得极差，有时候甚至想砸东西发泄。所以以后尽量在公司多待一段时间，回家来就睡觉好了。其实这种心情也影响我工作了。
周末想各种办法调整心情，没有什么效果。本来约同事来做客的，算了吧。心情不好不想见别人。见了别人也不会让我的心情变好。取消吧。
Google 在中国一度被吓得精神恍惚，不敢联想了，不过百度却一直安然无事。
在百度输入“阜平” （似乎是一个县名），自动提示的列表如下：
我很严肃地告诫大家，中国不可能有黑社会。可是我在搜索结果里去翻看，刀光剑影，兄弟义气，杀机四伏，这绝对不是中国，这是巴格达街头吧，或者是古惑仔电影？这显然是百度想象出来的。
百度啊，千万不要害了我们这一代青少年啊，我们可是祖国的花朵啊。
今天晚上跟同事们一起看电影 “UP”，挺不错，就是没吃饭，有点饿。不过电影看完的时候，又没有食欲。一个同事说想吃桂林米粉，于是就跟着一起去了。
初到那里，看到招牌挺不起眼的，在周围繁华街景的映衬下显得格格不入。不过进去之后就感觉舒服一些了，虽然里面的布局、通向二楼的窄小楼梯让人回想起大学时代校门口的小餐馆，但是相比之下干净多了。跟风点了个酸辣笋尖米粉，先来了两碗都让给同事了，不过我在旁边看得很想吃。终于等到之后，吃起来感觉还真的挺不错，汤稍微有点辣味，但是喝下去很舒服。
最近经常是在外面吃，还好久没遇见这样吃着好吃，吃完了也舒服的东西了。于是就上点评网写了条好评……在这里。所谓酒香不怕巷子深，这么小的店都让我给找到了——一方面也说明点评网的设计比较合理，我搜索“桂林米粉”然后按地域筛选，很快就找到它了。
人写点评，一般是感觉特别好，就像我今天这样的，或者是感觉特别烂，比如我前一段时间在住处旁边吃那个田园鸡火锅。这是我目前在点评网贡献的仅有的两条点评……一个指标特别好的话，会不自觉地其它方面的分数；某个指标特别差的话，自然地其它的印象也好不到哪儿去。有了这样强烈的感受，分享的欲望就随之很强烈，非常希望让别人也知道这里很好或者很差，让别人赶紧来或者千万不要来。
请了一天假，算上周末一共三天，回了一次家。
其实我老家挺近的，到北京的公路长度也就400公里，不过由于路况不是那么好，要走一整天。比如今天九点早上从家里走，晚上八点才到北京的住处。这样回家一次真实上火，所以我懒的回家。
从北京到河北，很明显地感觉到各种各样的差异。其实一到木樨园客运站，就能感受到河北的气息了，又脏又乱。很难理解，一个包围着首都的省份，竟然这么落后。在南方也坐过不少次公共汽车，再坐河北的汽车时，感觉真是不堪忍受。
总之，今天从家到北京，就仿佛穿越了几个世纪的文明……从县城到保定的车，慢慢腾腾到处停车拉客、超载，乘客习以为常，坐着脏兮兮的座椅（如果有座位的话），不知道投诉也没有投诉的地方，运营这些车辆的多少有点黑社会背景。而到了保定到北京的车上，乘务员竟然给乘客端茶倒水，让人有点受宠若惊。
对了我家是以前说的那个“晋察冀边区”，以后一定得讲讲革命老区的现状，让大家开开眼界。
对于类似当当、京东、新蛋这样拥有海量商品目录的商家来说，全靠手工去找出针对每种商品的关键词然后上传到 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 请求都可能出现连接问题导致的异常，你需要捕捉它们。一旦发现网络连接方面的一场，就让程序休息一小会再重试——简单的粗暴的方法是将执行 SOAP 请求的代码包装在一个 infinite loop 里 (例如 while true)。
例如这个讨论：ssl broken pipe | connection reset by peer. 这个问题应该很多人都会遇到，AdWords 官方也给了不少答复，但是始终没有清晰的答案。我个人认为这大概跟 AdWords API 的实现没太大的关系，用上面的方法即可解决。
跳过不可恢复的错误
少数情况下，上面提到的网络异常会导致另一种情形，重试是没有意义的。即 Google 的服务器收到了你的请求（如添加了一个 ad group）并且正确处理，但是你却没有得到 Google 的 response，即无法得到该 ad group 的 id。重试的话，Google 会告诉你，名字重了。如果我们的程序够细致，这时就该跳过这个 ad group 了，如果是简单粗暴地捕捉到一切异常都重试并且是无限循环，那程序就死在这儿，并且不停的消耗 API units. 如果懒得做那么精细（不要把过多精力浪费在小概率事件上），稍微文雅一点，可以换成有限次数的循环，在 ruby 里可以：
[code lang='ruby']
10.times do
...
end
[/code]
当然跳过的话一定要记录在 log 里。
对于一批数十万的关键词，远渡重洋到达 Google 的服务器至少需要许多个小时甚至许多天（无数次 HTTP 请求），在这段时间内，断电、断网的几率都是有的，我前阵子比较倒霉，都遇到了。后来学精了，遇到大批量操作都事先跟相关人员确认一下电力供应和网络状况，可是仍免不了大楼网络被攻击之类的事情发生。有一次甚至是一位同事好心帮我“开机”，把正在运行任务的服务器给关了……
做这种事本来就是压力很大的，一不小心银子就像流水一样白白花出去了，比如你买对了关键词，指错了链接 :-) 在压力很大的情况下又要面对许多的不确定因素，就更加刺激，更有挑战性了。