Category: 未分类

Linux服务器不小心断电，重启后，修复了硬盘，但是SVN Server出问题了。在浏览器中访问，看似一切正常，但是要check out，update的时候，就报错 no such revision ‘xxx’，xxx是一个版本号。

对repository目录执行svnadmin verify，发现很早之前的版本还在，从某个版本号就出错了。Google了一通之后，发现搜索结果里和我的症状都不太相同。丢失的太多了，近期备份也没有，难道就重新建一个repository了事？

不过很快找到了问题所在，db/revprops目录中的文件从0开始，到了出错的版本号就没了。打开这些文件，发现是纯文本，格式如下：

K 10
svn:author
V 7
someone
K 8
svn:date
V 27
2008-07-08T19:54:09.605509Z
K 7
svn:log
V 9
log here.
END

显然，一个key(K)跟一个value(V)，大写字母K、V之后是字符串的长度，revprops中的文件只是记录了每个版本提交的信息。

由于我们同时使用了trac，这些revprops文件丢失并没有损失，trac的数据库中都有保存，可以通过它来重新生成。但是为了简便起见，我就把最后一个存在的版本号文件复制了N遍：

for i in $(seq 250 500)
do
 cp 249 ${i}
done

250到500是缺失的版本号，249是最后一个存在的。就这样终于把版本库给修复了。

一个多月前我们去了一次凤凰岭，两男两女。原计划是十点上山，灌点泉水，两三点下山，然后去小汤山泡汤。

结果上山后不久，看到旁边有一条比较宽阔的山路，我们就抛弃了正途，沿这条山路向上走了。旁边出现一条小溪，一个水池子里有好多蝌蚪，某些没见过世面的同志看得很开心——“咦，这个长后腿了耶！”“啊，这个有四条腿还有尾巴哎！”漫山遍野散步的红色，也让人很兴奋，想到后来我还到香山去看了红叶，哪里有这么好啊。

沿南线走了不久遇到的一个岔路口成了这天行程的转折点，队伍一番商量之后，决定逢路口即选择右边的。后来证明，右倾机会主义害人不浅。在经过几次右倾之后，小溪离我们越来越远，路越来越不清晰，最后几乎找不到了。有时候是高大的灌木挡着，需要弯腰钻过去，或者把稍微矮小一点的用力踩到下面。有时候是大片大片的藤，差不多一人高，人就像在一张蛛网上爬一样，倒是很安全。

在山谷的时候，看着上面不远处就是几块巨石，似乎山顶并不远，不过往上爬的过程中才发现，那是很难爬上去的，我们只能斜向上，往更高的山顶爬。很快，最初的那些巨石就在我们下面了。

最后终于到了一个小山顶。没有任何准备，没有任何专业的装备，几乎没有食物和水，我们就爬上来了。因为路一直比较难走，甚至有的地方很危险，我们一直不想回头，想着前面的路可能会比较好走，前面也会有好的景色。那些高大的灌木和藤条，向下走的话，估计会更困难，所以我们决定从另一面下山。人大概都是这样，不知道前面的路是不是更危险，反正不想走回头路了。走到山顶那两块巨石前面，看到了不久前有人留下的痕迹，稍稍地宽慰了一些。毕竟这不是无人区，我们还能看到人的痕迹，远处就是北京市，还能听见对面山上有人说话的声音。

下山的路一开始就不好走，好几次需要从巨石上滑下来，主要是有两位女士。不过很快发现一条平整的小路，我们一下就兴奋起来，心想又找到路了，顺着它一定能走下山去。路况相对于乱石杂草那是好多了，但是它把我们引向了一个悬崖。悬崖边上有浓密的灌木，多亏我当时速度不是特别快，否则一下就走下去了。拽着藤条向下看，不是特别高，不过因为有女的，我们就退回去另选它路了。右边是一条山涧，堆满了从山上滚落的大石块，我们决定从那里走。过去以后发现那里也有人走过的痕迹，小心地下到谷底，又在一处石壁上发现了公交队的“到此一游”——果然，他们也是从这里下来的。这时看到前方的巨石附在悬崖上，仿佛一只乌龟在向上爬。

到了谷底终于有了真正的路，心情也就放松下来了，到处都是山核桃树，山核桃落得满地都是，我们用帽子装了不少。在山顶比较饿的时候，就是吃了几个山核桃充饥，味道很纯正。半小时后走到了南线的大路上，身心疲惫，回头望下来的山，如果事先知道，肯定不会爬上去的……路过一家采摘的园子，尝了一下我平时从来不吃的苹果，真好吃，买了一些带回家，结果第二天吃的时候，完全没有了下山时品尝的美味……

这一路真可谓是披荆斩棘，多少有点后怕。至于泉水，下次再灌吧。

昨天在hexy要求下写了一个小脚本，在豆瓣的邀请页面加了全选按钮。

按照习惯，我把处理DOM的代码放在了窗口的load事件的处理函数中：

window.addEventListener('load', function(e) {
	...
}, false);

但是hexy说页面上有很多图片（头像）的情况下，页面一显示出来没有全选那个checkbox，延迟好一会之后才出现。以前处理的页面因为比较简单，都没怎么在意这个问题，看来这次是不行了。各种JavaScript库里都有另外的途径来替代”load”，比如jQuery有ready函数，mootools有domready事件。而我们写Greasemonkey脚本，只需要考虑Firefox就好了，它有一个DOMContentLoaded事件，页面上解释得非常清楚：

Fired on a Window object when a document’s DOM content is finished loaded, but unlike “load”, does not wait till all images are loaded. Used for example by GreaseMonkey to sneak in to alter pages before they are displayed.

我们要的就是它。然而在把load替换为DOMContentLoaded之后，我发现更糟了，代码根本不执行了。一番搜索之后，我发现我从来就没仔细想过一个问题，Greasemonkey的脚本到底是什么时候执行的？这个页面解释了这个问题。

原来Greasemonkey的脚本就是在DOMContentLoaded这个事件触发后执行的，而这个事件对每次打开网页只有一次，脚本中再往这个事件添加处理函数当然是徒劳了！于是解决方案就是更简单地，把处理代码外面的皮剥掉，直接放出来就可以了。结果就是现在的这个样子。

可能是最初学写脚本的教程里就是教用load事件的，看起来又比较专业，我就一直这么用了，可见启蒙教育是多么重要，要不是这次教训，可能我就一辈子这么缺钙了。

实际上一般情况下对DOM的操作都不需要等到load事件，DOM结构完整之后就可以了，这样给用户的体验也会好很多。

一想到弄个Facebook的小应用，我就有点雄心勃勃的，想针对Facebook的数据做一些处理。不过看了一些相关的文档和例子之后，才发现有了API并不能为所欲为，Facebook对于应用的限制还是比较多的。

对Facebook的用户生成内容做处理和分析是基本不可能的，它最多只向你提供用户的账户基本信息及朋友关系。Facebook的应用一般都是将Facebook庞大的用户群为我所用，借助应用本身的趣味性以及facebook错综复杂的朋友关系、news feed迅速蔓延、推广。这种模式在游戏类的应用中表现尤为突出。

Facebook的应用不限于那些像开心网的模块一样的。开心网的应用一般都是添加，然后就出现在左侧栏，就可以玩了。Facebook的应用不添加也可以使用，只要你授权给它，它就可以不同程度地取得你的各种信息。有了这样的机制，应用可以完全栖身于Facebook之外，最初的访问可能需要跳转到Facebook（登录）进行授权。一旦授权成功，用户就可以只访问这个独立的站点，与Facebook Server的交互只是该站点的服务器在后台做了。这种模式相当于是一个独立站点借用了Facebook的用户表和朋友表。

然而给Facebook开发应用远没有使用Facebook那么简单，它的文档、示例等有点像大部分的开源项目，让入门者找不到清晰的道路。最近Facebook出来新版，有了新的Profile设计以及一个Publisher，但是大部分的教程（尤其是第三方开发者的）都没有及时更新。

Facebook开发的首页是这个”Facebook Developers“，初看简介明了，不过浏览半天还是一头雾水。我的建议是看完Get Started之后，直接到wiki里去看”Creating your first application“这篇文章，写得非常详细。

Facebook给出了一些Demo App，多看看多用用就知道Facebook API能干些什么。不过到最后谁都很郁闷，看到了demo，它们的源代码在哪儿呢？Facebook似乎没在明显的地方告诉我们，它们在一个SVN代码库里：http://svn.facebook.com/svnroot/platform/samples/。

记得当初刚开始写blog的时候，周围好多人都在写，包括在BBS上认识的一些朋友。写blog的过程中也认识了不少新朋友，都是写blog的。而如今，那些最初认识的blogger大部分都不写了。打开网址，有的域名已经过期了都不续费，还有的就是荒废了，几年前的文章摆在那儿，有的甚至都不知道去向。

基本上所有的人都是为生活奔波，没时间也没心情写这玩意了。剩下来写blog的，几乎都是IT人士。甚至有的IT人士也整天见不到踪影，不要说让他写blog了。

就是因为大学快毕业的时候空闲时间太多，所以大家就靠写blog打发时间。而现在为生活奔命，谁还有工夫顾着这个？倒是长江后浪推前浪，我们开始奔命了，新一代的准毕业生来了，组成一个新的blog圈子，互相做链接，互相点名，互相探讨建站，blog圈依旧繁荣如初。

招商银行推出了“账单分期DIY”，不过好多人都在网上抱怨说过不了审核。我觉得这些大概都是那种“玩”信用卡的人，整天把申请、刷信用卡当成自己的事业了。如果信用记录良好，银行应该不会刁难的。

账单分期在网银里就可以申请，具体方法在这个网页有详细说明。

申请提交后，马上收到一条短信说网上消费××元，这实际上就是第一期的金额，会出现在下个月的账单里。收到这条短信，应该就说明分期成功了。我没有失败的经验，所以不知道分期失败是什么效果……网上说会告诉你综合评分不够。

几天之后，短信提醒的这笔金额会出现在网银的“未出账单查询”中，同时有账单分期的手续费（这个没有短信告知），还有招商银行暂时替客户还的款，也就是办理分期的总金额。这时再看“账户查询”里的“本期应还金额”，已经减去了分期的部分。

Uploadr是Flickr自己开发的照片上传工具，但是存在不少问题。这个3.0的版本似乎就不支持文件路径上有中文字符，于是我一直在使用3.1测试版。3.1支持中文路径，可惜经常崩溃。最初的时候，是每次关闭的时候Windows都会弹出一个对话框说崩溃了。到后来，一批文件经常是上传几张就崩溃掉，要不停地重试才上传完成，很烦。

jUploadr是第三方工具，跨平台（Flickr Uploadr只支持Windows和Mac），在Flickr工具页上也有推荐。

跟Flickr Uploadr比较，jUploadr的操作方式和显示方式稍微有点差异，初用可能不太习惯，但是用多了也可以像Flickr Uploadr一样顺手。最大的优点当然是稳定了，再多的东西点一下Upload就可以扔在那儿不管了，它会一张一张给你传上去，而不会像Flickr Uploadr，过一会去看的时候，发现一个崩溃对话框……

不过jUploadr有一个比较致命的毛病。假如选中的一批照片有不同的permission，最好不要批量编辑它们，因为即使你在编辑时不修改permission，最后它们也都会变成同样的permission。这一点真是太不应该了，在Flickr Uploadr中是不会发生的。为避免这样的事情发生，可以把permission的设置放在编辑的最后一步。

稳定是王道，目前还是用jUploadr最好。当然大家都希望Flickr自己做的Uploadr能够更完善一些。

在安徽待了7天，现在又回到了北京。

这次的照片基本整理完了：

宏村 | 翡翠谷 | 黄山 | 合肥

一共拍了大概500张照片，整理的时候删了一多半。

我还得努力争取下一次旅行的时间和钱。

这是在安徽也是在合肥的最后一天。中午退房后，又去了王仁和米线，因为昨天给了两张代金券。于是两人花10元吃了一顿饱饱的午餐，擦擦嘴就去科大东区参观了。

如今科大正门的风头已经被高架路给抢去了：

天屎路已经是淡季，人们可以安全地通过。以下分别是全景和路面细节：

校园里转了一圈后，买了几本杂志，去二教“上自习”。老婆说她又找到了上大学的感觉，我却没有，大概是因为我从来不在教室看彩页杂志……

晚上在教学楼前的“星座”餐厅吃晚餐，然后乘1路车到火车站，踏上归途。

辣糊汤这种东西，我也不知道是不是合肥的特产，反正我是上了大学才发现的，科大食堂里就有。配料应该有淀粉、海带、豆腐丝，少许辣椒，微辣，很开胃。科大人不拘小节，经常把名字弄错：“一碗呼啦汤，三个包子！”到底是辣糊汤，还是胡辣汤？我也搞懵了。

今天早上就在路边小摊吃的这东西，不过口感不如科大食堂的好。吃完后，就大摇大摆混进了科大西区。科大和科大人都有着与其它大学不同的气质，到了周六，校园里仍然十分安静，学生们有很多待在教室、图书馆里。去芳花园转了一圈，去三教上了个厕所，顺便站在扇形教室的门口张望一番，许多学生在上自习，依旧是以前的那种气氛。

从西区出来，坐车沿黄山路向东，寻找记忆中的烤羊腿——小肥羊的烤羊腿。不过走到了尽头仍然没有发现——又倒了一个。一边短信hsm帮忙查小肥羊的地址，一边四下搜寻好吃的地方。hsm短信过来的时候，正好在一个十字路口发现了八大碗。在合肥就经常听说，倒还没去过。小肥羊是全国连锁，不过八大碗只有合肥才有，于是就进去了。一个渣茄子，一个龙骨炖玉米，汤很好喝。

下午就在酒店看电视，休息。

晚饭去西区门口新开的“王仁和米线”，以前在合肥的时候不记得有。30块一大盆“状元过桥米线”，两个人吃得很饱，这才知道正宗的过桥米线是啥。里面的汤和肥西老母鸡的鸡汤有点像，好喝。