非主流密码管理方案:keepass+dropbox

最近发生了CSDN用户密码明文泄漏事件,还好我没有被波及,因为我在csdn注册的帐号用的是当年的一个通用密码…

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

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

关于pubsubhubbub和Google Reader

上一篇文章中,我描述了自己如何重制了一个Danbooru的feed。然而,经过一夜的睡眠,我「惊喜」地发现Google Reader在睡前到醒后的7个多小时里面都没有抓取过我订阅了的这个feed——也就是说,就算重制的feed包含10000条最近更新,只要GR不主动抓取,那这些更新也还是没有意义。

绝望之下,觉得归根到底还是弄清楚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那样面向过程开发的方法…

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

重制danbooru的feed

作为一只东方众,我每天都会通过Danbooru来收一堆东方同人图——Danbooru类型的图站有一个很出色的地方,就是搜索结果可以输出rss feed,直接在GR中添加feed「http://danbooru.donmai.us/post/atom?tags=touhou」,就可以在GR中订阅D站的带有touhou标签的新投稿,十分方便。

前两天开始,我发现这个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命令把异常打印到网页上。

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

杭州ComicMe02流水账

2011-08-27杭州ComicMe02

拍的照片整理好放在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+就应该能看到图片。

架设个人DNS服务器来解决一些「国情」问题@

 

具体请移步这里: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需要的童鞋去试试看。

twitter2weiboviagtalk发布,欢迎试用

https://code.google.com/p/twitter2weiboviagtalk/

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

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

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

欢迎大家拖走测试。

兼顾实习和研究的困境

研究

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

实习

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

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

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

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

恢复了博客

存放博客的服务器上由于一个做仿牌的网站被投诉而被回收了,数据全部丢失…好在我用wp time machine对博客进行过备份,今天早上才把博客恢复起来。

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

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

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