鲁希德的城堡

newyorker盘点出08年几篇优秀的短篇小说

最近着手改进网站的代码，一方面通过memcache降低CPU使用，另一方面想把网站供稿在feedburner上烧制一下，以减少网络程序访问产生的CPU占用。以前的供稿在Google Reader上虽然显示正常，但在Feedburner上烧录后却只有乱码。研究了一下发现是由于feedburner是根据供稿的编码来识别代码，而不是根据实际的编码，因为这个XML模板是用Intype默认的ANIS编码编写的所以造成了这个错误。

另外用http://feedvalidator.org/验证了一下这个供稿，发现还有不少问题。文章内部字符和标记的错误就不计了，剩下的主要是时间格式不符合规范。其实以前这个时间规范的问题一直会影响Google Reader，不过不知道Google什么时候改正了时间显示的方式，用Google Reader抓取的时间代替了供稿生成的时间，所以我的这个问题也一直没有修正。

Atom使用的这个时间格式标准被称为rfc3339 Timestamps，其实编写一个能生成符合这个rfc3339标准的python代码也不算难，而我可能以后会用django生成的供稿，所以为了节约时间还是直接Google了一个rfc3339 for Python，上面还有Pyfeed这种东西，真是遗憾了，以后干什么一定要先Google一下。

在用http://jieblog.appspot.com烧录的时候发现feedburner居然直接识别了appspot的子域名并且返还了这么个地址http://feeds.feedburner.com/appspot/euFN。不过在没有修改完善之前还是不使用这个供稿了，毕竟修改供稿造成阅读器的项目混乱是很麻烦的。

虽然从控制台上看Application Quotas还都够用，但是Current Load里首页和feeds两个项目平均CPU占用都有警告：

This URL uses a heigh amount of CPU and may soon exceed its quota.

看着总是不太舒服。首页的高CPU自然比较正常，而feeds因为我没有使用feedburner这类的工具烧制RSS现在的确有点后悔了，再加上这个feeds还是Google Webmaster工具的Sitemap所以占用也会很高。而Google Reader甚至有时候在我发布文章后1分钟内就会更新。

Appengine的FAQ里提到衡量CPU使用的两个主要途径是：

1. Runtime CPU：应用程序本身产生的CPU使用，这显然是和代码的质量有关系
2. API CPU：用于调用App Engine API产生的CPU使用，例如：datastore API , urlfetch API, image API, 等。

第一条我显然没有太多时间做。。。所以直接转向第二条，使用Memcache进行优化。Appengine文档里有个很简单的例子，目前我只用Memcache尝试提取首页的Post数据，然后看看效果是否明显：

def get_data(the_key, time_exp):
  data = memcache.get("Post")
  if data is not None:
	return data
  else:
	data = query_for_data()
	if not memcache.add(the_key, data, time_exp):
		logging.error("Memcache set failed.")
	return data

通过使用这个函数，首先检查memcache的data是否有the_key这个数据，如果有的话直接返还data，如果没有的话则调用query_for_data()这个函数。然后将query_for_data()的结果加入memcache，而memcahe则是按照设定的time_exp进行更新。

小野丽莎翻唱John Denver的Take Me Home Country Roads

小野丽莎 - Take Me Home Country Roads

Github的Blog Rebase 9在本周介绍了这个程序，作者又在圣诞节这一天制作了视频来演示Gaebar的使用方法。Gaebar是一个独立的基于Django的程序，可以作为插件集成在使用Google App Engine Django或者app-engine-patch开发的应用中来备份和恢复Appengine上存储的数据。

Gaebar可以将Appengine的数据备份到Python代码中，而且可以执行这些代码来进行数据恢复。作者在程序中使用了Ajax来调用备份程序以避免产生Appengine不支持的长时间数据操作。为了避免产生过高的Cpu负载Gaebar默认每次备份五行数据，产生的备份文件也被分割为约300KB以避免发生Appengine 1m文件的限制。

源代码地址：

• Gaebar: http://github.com/aral/gaebar/tree/master
• Gaebar-gaed: http://github.com/aral/gaebar-gaed/tree/master
• Gaebar-aep: http://github.com/aral/gaebar-aep/tree/master

这是appengine官方blog上的一篇文章。

首先先是Zoho Creator的开发人员已经为Zoho Creator添加了生成GAE代码的功能。在用Zoho Creator创建了应用之后，在上面的More Actions的下拉菜单里有一个Deploy in Google Appengine的选项可以直接下载这个应用的python代码。目前Zoho Creator仍旧有一些在Appengine上不能实现的功能，包括：

• 文件上传和Notes field
• 使用Criteria的Views
• 使用运算符的分组
• HTML, Summary和Calendar视图
• Zoho Creator的主题支持
• 受限制的Deluge Scripting支持(仅支持邮件通告)

App Engine Site Creator，可以说这是一个简单的内容管理系统(CMS)，类似Drupal这样的程序。目前感觉功能还不完善，毕竟开发才刚起步，GUI风格感觉很像Google Cookbook - Google App Engine。不过按照他们的说法这个程序还是很值得期待的：

The resulting managed site is designed to be themed and branded, and the back end Site Creator code was written with readability and extensibility in mind.

很期待GAE上能有类似Drupal和Movable Type这样的程序出现。

Deadth Proof里的一段热舞一个插曲。

The Coasters - Down In Mexico

我时常在想这么个问题：如果塞林格或雷蒙德·卡佛这样的作家生活在这个年代的话他们是否还会抱着打字机写作呢？他们是否会如我这样用Google Doc或者Window Live Writer这些工具呢？最后自己终于还是回答了这个问题，用打字机噼里啪啦的打字恐怕还是某些作家无法割舍的，当然机械键盘也可以实现这样的效果。

每每到了年末事情总会非常非常多，单位加班、朋友结婚、家人生病，有点时间想改改程序却不知不觉读起雷蒙德·卡佛的小说看起昆汀·塔伦蒂诺的电影听起Dido的新专辑。译林出版社出版的《大教堂》已经在卓越上订购了，不过有点时间却还是忍不住想在网上找文章来看。英文原著也读，但是读的慢，有些时候还是想看看译文，究竟自己的理解是否会有偏差。卡佛的小说和非常推崇他的村上的作品风格迥异，村上的短篇大多是在一些非常离奇的故事中蕴含着深刻的意味，而卡佛的短篇则是”处处隐藏着超越日常生活的奇妙意外”。我尤其喜欢卡弗的短篇《当我们谈论爱情》。

写不张扬的小说，作不张扬的诗，自是不张扬的人。他晚年邂逅诗人苔丝·加拉赫，共同生活在一起。戒除酒瘾，重塑生活，这种被他自己称为“第二次生命”的平静氛围，孕育出了大量优秀的作品。苔丝现在还把他的书房保持成原来的样子。他的打字机里还夹着雪白的纸页。仿佛一直在等待谁来敲打出那最初的一行。

以上引自村上写的一篇介绍卡弗生平的文章，实际上卡弗也正是给我这样的感觉。

搜索到的一些卡弗短片小说译作的链接:

• 豆瓣的雷蒙德·卡佛小组：http://www.douban.com/group/RaymondCarver/
• http://www.heilan.com/databank/usa.htm
• 纽约客上有不少卡弗小说的原文
• 雷蒙德·卡佛中文译者们的Blogbus：http://carver.blogbus.com/

著名的网络艺术社区DeviantART终于也遭到GFW(Great Fire Wall)封杀了，只要是对摄影、涂鸦、美化等艺术创作和设计感兴趣的网民恐怕没有不知道这个网站的。作为全球最出色的“用户产生内容”网站之一，DeviantART的被封我们完全可以理解，因为他完全符合GFW三定律的第一条：只要是 “用户产生内容”(User-generated content, UGC) 的国外网站都会被和谐。第二定律：只要是被和谐的网站，国内一定会有个克隆版，这个我们拭目以待，我很期待国内的同类网站。第三条，其实我想说，没有被GFW封杀过的网站就不是一个出色的网站...

GFW这个东西时常让我想起村上在<舞舞舞>中对资本主义社会无形之网的一段描述：

网无处不在，网外有网，无处可去。若扔石块，免不了转弯落回自家头上……时代如同流沙一般流动不止，我们所站立的位置又不是我们站立的位置

自从Google Chrome浏览器发布第一个测试版到现在已经一百天了，现在Google终于发布了第一个Google Chrome的稳定版1.0.154.36，拿掉了beta的标签。

回想当初发布的时候因为不堪Google Chrome的Flash Bug我还是放弃使用了这个浏览器，而现在Google Chrome在处理Flash的时候cup占用得到了明显的优化，书签管理器也有所改善，另外Google Chrome最新的V8引擎又在SunSpider benchmark和V8 benchmark中领先其他浏览器。在安全方面Google Chrome的独特的sandbox technology会为用户提供一个防御恶意程序的保护层使得浏览器更加安全。

据Google方面称:在这发布的一百天里Google Chrome在世界范围内已经得到了一千万的活跃用户。实际上Google Chrome浏览器的开发应该说到现在仅仅完成了一些浏览器必须具备的功能，要像Firefox那样获得广泛的扩展功能更全面的设置相信Google Chrome还有很长的路要走。

CWOW更新3.0以后以前自己做的oUF_LUCID这个头像插件布局不能用了，这个布局我好像是根据zypher的oUF_Adalyn修改的，此人目前好像已经告别WOW。准备花点时间来研究一下这个版本的oUF，根据oUF_lily重写一个布局出来。话说目前Wowinterface上的oUF布局比起以前真是多了不少，比如这个死亡骑士专用的布局oUF_Runed做的还真不错。

另一个插件就是tekkub的tekticles，这是个修改游戏字体的插件和著名的ClearFont功能类似，但是要更加精巧。tekkub这个插件作者其实还是很猛的，非常多产的一位插件作者另外好像他是为Github工作？记得在Github的Blog上看到过他写的文章。这个插件的问题是：新版在CWOW似乎不起作用，我用的旧版报错太多严重影响玩游戏的心情，需要找时间修改一下，Repositories已经建好，依然是用Git～

今年五月份的时候Google Friend Connect的服务好像就可以申请了，不过对这个东西的概念还不是很清楚，最近使用Google Friend Connect beta无需等待邀请了，于是小小的研究了一下。功能和前几天SixPart发布的TypePad Connect类似，不过Google Friend Connect功能明显要更强一些，支持多浏览器和多种账户登录。

在appengine里使用Google Friend Connect非常简单，在app.yaml文件里映射rpc_relay.html和canvas.html两个文件到根目录就可以了。

- url: /rpc_relay.html
  static_files: static/rpc_relay.html
  upload: static/rpc_relay.html

- url: /canvas.html
  static_files: static/canvas.html
  upload: static/canvas.html 

除了Members gadgets，还提供各种Social gadgets可以实现评论、评级、等功能。

忽然发现最近有很多做Profile的网站，包括Google、Yahoo、微软，不过感慨一下当Google、SixPart已经把Profile应用到各种网络程序的时候微软才刚刚开始做Profile的概念，而国内的互联网巨头们还不知道有没有对OpenSocial这类东西感兴趣的。

我是在上一次Google Reader用户界面更新后才从Firefox内置的RSS阅读器转移过来的，那时候看重的还是Google Reader的用户界面和功能。今天Google Reader用户界面再次得到了改进，基本上所有的圆角都被移除，去掉了侧边栏的背景，侧边栏的各个项目都可以使用折叠功能。查找和搜索供稿中添加了更多供稿和分类，不过中文版的好像还是只有那几个。

关于为何突然撤除Google Reader中圆角设计Official Google Reader Blog中这样写到:

Google is all about speed, both under the hood as well as in the user experience. So, in order to make Reader act and feel more speedy and responsive, we've removed some visual clutter, simplified some features and given everything a bit more breathing room.