你可以先注册Gmail账号，然后注册app id。因为app id会为Gmail账号的用户名保留，但前提是你的用户名不含特殊字符，例如小数点。

这是Google员工前天说的。

你可以用logging来记录时间，urlfetch属于service，可以参考这个来hook：
https://bitbucket.org/keakon/doodle/src/9830de2a181b/hook.py

twitter 客户端确实没什么办法加快，不过web端的可以弄成ajax，在用户不知情的情况下去fetch

latency越低越好（一般应该低于1000ms，我的不到100ms），QPS越高越好（不过钱也花得多）

支持PubSubHubbub的话，订阅后自己抓＝＝

发信人只能是当前用户或这个app的管理员，这个是GAE的限制

“创建分类时保存之后 一会分类就会消失”是指sidebar吗？
我设置了10分钟的缓存，过10分钟才会完全更新。
但是在后台创建和编辑文章时应该不会有问题，可以选择所有分类。

第一个是你没有设置正确的管理员邮箱（ADMIN_EMAIL），这个邮箱必须是这个app的管理员的邮箱。

第二个在之前更新的版本已经修正了。把blog.py里出错的那行代码删掉就行了。

第三个是格式不对的问题，目前我是把feed关闭的，所以没有测试这个问题…刚才我已经修正了，下载或check out最新的code即可。

谢谢指出这些问题。

我传了个新版本上去。原版本删了一个页面，但是URL映射里没有删，所以会报错。

你报的这个错看上去和Doodle无关，因为我的代码里没有调用过fetch.py。很显然是你把andy-wallproxy和Doodle集成时才出的错。

如果不是很熟悉YUI的话，建议你在app.yaml里将fetch.py分离出去。

@deepice 报的什么错贴出来吧，不然我怎么知道…

@pudd
这个问题可以用JavaScript解决，也就是预加载图片。
纯HTML+CSS也能做到，底部写个div来下载图片，但是隐藏显示就行了。

@pudd
速度还不错，很漂亮，建议导航栏加个title属性，不加文字说明的话，有些图标不知道代表什么。

这里css sprites的应用感觉并不恰当，还记得它的本意吗————减少HTTP连接数，加快下载速度。
可是你的all.jpg有500多k，我花了5秒才下载完，这时候一直都只能显示load.gif。
事实上让用户第一时间看到第一张图，在用户还在摸索你的导航条时偷偷完成其他几张图的下载更合适。

另外，blog的响应速度很慢，感觉应该是被数据库拖慢了。

这个是旧的，下个月主机到期就会自动转到GAE了，因为有些文章还在整理中，所以地址就懒得公布了

演示在这里（版本比较旧）：http://acgpedia.appspot.com/blog/

@disinfeqt

就我本身来说，我没有采用上述的任何一种技术，因为我觉得简单就是最好的。我甚至完全不考虑IE浏览器，我自己的博客就是HTML5 + CSS3。

小图像下载本身就很快，拼在一起并没有让我感觉到更快。对用户来说，它们是次要的，关注的重点应该是内容本身。

而data URI会增大CSS体积这个缺点对我来说是致命的。这种次要内容绝对不应该影响到用户正常浏览网页，而CSS在下载和解析过程中对浏览器的独占性决定了它必须尽可能简化和轻量。
单个5kb的文件看上去是可以接受，但整个网站会用到多少个这种图片呢？如果就3、4个，增加几个HTTP链接又不会怀孕；如果10几20个，我想这个CSS也就不可接受了。
而且从维护上来说，看到一堆乱码一样的东西，人脑是不可能读懂这是什么图片的。

举个很现实的例子，我手机用的是GSM，网速慢得要死，所以我是不显示图片的。可你如果放在CSS里，我就被迫去下载这些我不关注的玩意了。

我还见过一些体验很差的网站，打开后先展示一个框架，然后下载半天资源，过了30秒才给你展示最重要的文字内容。
我想你必然更愿意在3秒内看到主要内容，然后花27秒去下载其他资源。至少在这个等待过程中，你可以看到想看的内容，而不是一个空白的框架。

我认为它真正有意义的地方是用来生成验证码。这个玩意不需要在服务器端生成和维护一张临时图片，这对于不能更改文件系统的GAE来说是很有意义的。

@chone

1.我们使用的图像大部分就是压缩过的，如果base64后再gzip会变得更小，那么这个图像压缩算法就太傻了。
拿http://www.google.com/images/logo.gif来说，原大小是11430字节，base64后是15240，再gzip是11473。
而且你测试下就知道，多一次compress和decompress的操作，肯定会对性能造成影响，更何况你还是用在CPU不给力的手机设备上。

2.如果要缓存，就必须每个图片写一个css。而获取这个文件本身就相当于多了一个HTTP请求，没有起到减少HTTP请求这个目的。

4.这个是和1相关的。一般的css文件只有几k到几十k，是很容易下载完的，不需要等待太久。而你加上了图像后，css变成了几百k甚至上m，这对用户来说就很慢了。因为我可以忍受图片暂时不显示，但不能忍受整个网页都暂时不能显示。

不知道楼上2位是否真的将data URI投入实际使用，至少在我看来有几个严重问题：
1.base64编码会增大1/3体积。
2.无法让浏览器缓存图像，只能缓存引用它的文件。
3.在HTML上不能复用，要复用只能放在CSS和JavaScript里。
4.你如果把背景图片写在CSS或JavaScript里，你在下载完CSS和JavaScript之前，浏览器是完全停止解析和渲染的，而常规的引用外部图片的方式是可以并行下载的。

直接在后台找到对应的Member实体，修改username属性即可

Disqus不支持HTML，想设置字体样式发个图贴个视频贴段代码都不知道咋弄