不过，从去年开始，我就使用KeePass来生成和管理密码。这个软件将密码保存在一个文件当中，为了防止这个文件丢失，我又将它同步到dropbox里面。

keepass在Android和iOS平台都有相应的免费软件，dropbox亦然，所以应该是一个稳妥而可行的密码管理方案吧。就是麻烦了点…

绝望之下，觉得归根到底还是弄清楚pubsubhubbub（以下简称PuSH）协议的原理。试着搜索有关GR和PuSH的文章，发现@keakon曾经发表过『PubSubHubbub不通知Google Reader的原因』『实现PubSubHubbub订阅』和『使用PubSubHubbub』三篇文章。拜读之后，明白了什么叫publisher和subscriber，也得知GR可能会自动忽略订阅数少的feed的PuSH，于是先写了一个sub，然后拿菜包工作室来当小白鼠（不好意思啦@tc201158），由于这个博客刚开张，只有我一个人在GR订阅了（订阅数为1），在装了PuSH插件并在hub上进行subscribe之后果然还是无法实现PuSH，可是我用另外一个GR帐号订阅其feed（订阅数为2）之后，PuSH就能正常工作了。

大喜，以为终于找到了原因，于是对重制的feed也如此这般地弄，结果却失败了…无奈之下，我又试着对danbooru的原feed重新在hub上subscribe，发现原feed实现了PuSH的同时，重制的feed也实现了PuSH！难道因为重制的feed中提供的id、url等信息仍然是原feed的信息，所以只有在收到原feed更新的ping请求后，hub才会通知GR抓取重制的feed？

不过既然原feed能够实现PuSH，那重制的feed就没什么意义了；只需要实现在GAE上利用cron定期检查原feed是否有更新，有的话就ping一下hub就可以了。于是又浪费了一整天的人参来实现了这个功能…

至此，对Danbooru feed的PuSH改造完满完成。经验教训：

1. 尽管有约定，但在feed中添加hub link并不是必须的，至少对于Google的hub（http://pubsubhubbub.appspot.com）是如此；
2. 利用第一点，可以对任何一个feed实现PuSH改造。先写一个sub以便在Google的hub上对feed进行订阅（必须有订阅才能实现PuSH），然后写一个cron定期检查feed的更新并且ping hub即可；
3. 开发GAE应用时，利用handlers和wsgi来架构整个应用，无论是应用结构还是debug都方便太多了，决定从此放弃像twitter2weiboviagtalk那样面向过程开发的方法…

题外话。今天是⑨月⑨日的⑨节，可是⑨的同人图一点都不给力啊…

前两天开始，我发现这个feed的更新数变少了——通常一天下来会有超过100的更新，但当天只有六十多，而且某次我在扫feed时，发现feed的上一次抓取时间是2个小时以前；而另外一次扫feed时，发现feed一下子实时更新了20篇——通常一个rss feed只会包含最近20篇投稿，这意味着由于GR的抓取频率比较慢，很可能没有办法将所有的近期更新抓全。

为了解决这个问题，我首先想到的是PubHubSubBub——一个能够在feed有更新时主动通知Hub（如GR），使其主动过来抓取更新的协议。我当然不可能直接让D站方面实现这个协议，但搜索了一下相关资料，似乎并没有要求通知者和feed一定要同一服务器，所以利用PubHubSubBub的代码在本机上测试了一下，发现即使通知了http://pubhubsubbub.appspot.com/，GR也不会主动抓取对应地址的更新…几番测试下依然无解，只能放弃了这个想法，转而考虑为D站的feed制作一个包含足够多篇数的近期更新的feed。

重制feed的应用仍然放在GAE上。初步构想了一下，应用要实现2个功能：

1. 以比GR高得多的抓取频率（如1分钟1次）抓取D站的对应feed，并且将新投稿保存在数据库中；
2. 输出rss feed，其中包含足够覆盖GR抓取频率的数量的新投稿数，甚至可以根据GR抓取的User-Agent智能判断那些投稿已经被GR抓取。

然后开始忙活…为了解析D站的feed，先是打算用minidom，后来发现Google Data APIs中提供了atom的解析器，于是将代码下载下来，稍微看了下doc就知道怎样用了；输出rss时则参考了PubHubSubBub代码中的Atom模板。

由于不懂如何在本地环境调试GAE应用，所以每次都要先上传到远程再调试；由于GAE的log有延迟，所以程序出错后要等几分钟才能在后台看到trackback，后来干脆直接把整个程序代码放到一个try-except块中，再用print命令把异常打印到网页上。

就这么个小东西弄了一天，半吊子的悲剧啊…

拍的照片整理好放在picasa相册了，上方传送门。

大清早穿着之前定做的衣服出门，找住在校外的本科室友然后一起K93过去。上了车才发现自己忘记带预售票了，而且还上错了一辆K93导致晚了一班车才过去，还担心今天会一整天诸事不顺，幸亏在那之后厄运就终结了…

在香积寺路口下车，离CM02会场——海外海国际会展中心大约还有1公里，然后一路走过去；发现即使是在会场门外也没有感受到宅气场…直到进入会场那一刻才真正觉得处于同好的世界中。

总体来说，CM02的同人摊位还是比较多的，之前做了点功课，所以现场的东方同人摊的作品都翻了一遍，考虑了有爱程度和自身预算只入手了扑克牌『东方数游符』和ideolo的『BLACK★ALBUM 2』。

场内coser的种类还是比较丰富的，感觉比110807的广州yaca要好，可惜场地偏小所以略挤。之前入手了一个SAL50f18的标准定焦镜头，对这次漫展的照片质量提升挺大的，可惜没有多少余裕空间供我用双脚「调焦距」，所以基本上没拍到全身相…此外，发现这边无论是coser接受拍照还是阿宅求拍照的习惯都尚未形成，经常是路过求拍照，coser等求拍照的人拍好了就无视其他围上来拍的人扭头离开了，对于我这种略腼腆的人来说有点不方便…场内设置的摄影区也没有coser和摄影阿宅聚集，感觉成了休息区了。

大概中午12点左右离开会场，在胜利河美食街解决了中饭然后回校。

发件人 2011-08-13

印了一件这样的T恤…看了一下条款，p站不允许在其他网站转载其作品，不允许作品用作商业宣传，出于个人爱好用作品印衣服自己穿大概没问题吧XD

发件人 20110815 22&33娘

然后败了22&33娘。生平第一次买手办，以后会一发不可收拾吧（茶

图片放在picasa上，如果你能上google+就应该能看到图片。

具体请移步这里：http://www.blogjava.net/stone2083/archive/2011/07/09/353664.html

这个小程序的本意是在局域网中建立一个简单的DNS服务器，不过由于其支持通配符hosts，所以可以用于干坏事：之前的hosts经常要这样改：

203.208.46.133 www.google.com
203.208.46.133 mail.google.com
…

有了这个应用，就可以实现这样的hosts：

203.208.46.133 *.google.com
203.208.46.133 *.youtube.com

该作者刚更新了一个standalone版本序，配置十分方便，推荐有大规模hosts需要的童鞋去试试看。

能将twitter帐号的消息同步到围脖中，利用了围脖的gtalk机器人功能发布消息功能和GAE的xmpp功能，借鉴了月光博客的twitter-feed项目写出来的程序。

自己之前一直在用，后来在推上看到有一些人也有这个需求，就把程序改了下放出来了。没什么代码规范可言，只是做到“能用”的程度…

不知道会不会被广泛使用，也不知道渣浪到时会不会把这个东西封掉…

欢迎大家拖走测试。

而自从回绝了导师让我读博的建议，并且团队中另一师兄决定转博之后，团队的研究核心从我身上转移，不过导师仍会让我参加只有博士生和/或小老师参加的学术讨论，在一些重要问题上也很看重我的意见，这算是对我的认可吧；我也有兴趣对研究问题作自己的思考，且在跟导师唱反调时也丝毫不口软，总体来说，我没有效仿以往的主流读硕经历，让自己变成一个学术混混；然而从实用性角度去考虑，我也不是很清楚这种学术锻炼能对以后求职或工作有什么帮助，这多少让我有点忐忑不安：我不打算读博，却投入大量时间“搞学术”（因此还增加了导师随时召唤我的概率，影响到了我自己的实习，下详）；而别人在学术上得过且过，把时间用在考各种认证和实习上面。而从以往经验来看，似乎在研究上弄得越糟糕的人，找到的工作就越好-_-|||。

实习

6月以来，我找到了一份创投的实习，主要工作是协助对拟投资企业进行尽职调查并撰写分析报告，这和之前在银行当客户经理时写的授信报告有点像但又不太一样，所以这算是一份能锻炼我的能力、增加我的见识的实习。

实习这事儿瞒着导师。尽管工作不多且时间安排尚算自由，但出于导师随时召唤的担忧，我已经拒绝过几次短途出差的要求，另外一位实习生告诉我，公司的领导因此对我有所不满。

得知此事后，我反思当前的做法：尽可能确保到公司的出勤（即使在公司闲着），为了出勤我会适当推掉一些参加讲座之类的学术任务；同时为防止导师突然找我时无法抽身离开，拒绝公司的出差任务…这种做法一方面比较“安全”（降低被导师抓到正在实习的概率），而且能确保自己的实习出勤（主要和实习收入挂钩）和自由支配时间，但因此牺牲了工作中的调研机会以及公司领导的评价。事实上，我并不十分看重实习的收入，对我来说，实习的经历比收入要重要；而我在避免导师召唤却无法出席这一点上不敢冒风险，让公司领导觉得我“不懂变通”、避重就轻的同时也牺牲了宝贵的到企业调研的机会，让我觉得为防范风险所作出的牺牲有点大了。

幸好暑假即将到来，如果导师放我们暑假的话，那7—8月的实习就不用担心他随时召唤了…

本来想说运营商对客户数据完全不做备份也太说不过去了，不过了解了一下，觉得更换运营商也并不一定能避免这种问题，所以只能自认倒霉…不知道有没有办法定期运行wp time machine。

此外，我所处的网络环境似乎已能定点打击wallproxy的连接了…从昨天开始，我的wallproxy都处于抽风状态，与此同时基于同一ip的google服务却仍能正常运作…不知道wallproxy连接是不是有什么特征被gfw识别了呢。在绯礼君的介绍下，我换用了goagent，这个应用很好很强大，目前基本正常工作，不过偶尔还是能看到gfw干扰的痕迹。

墙娘越来越萌，让人没有安全感…