不过！经过今天一个中午的摸索研究测试， 终于能够一行代码搞定问题了！！！跟我来吧！

第一步：下载  user.css 文件。

里面就是一行CSS设置，也可以自己人肉写：

* { font-family: “Microsoft YaHei” !important; }

这行设置的意思是，所有的网页文字统统设置成为微软雅黑！ 这个是在我自己的显示器上人肉观察得出的喜好，如果你不喜欢，可以打开 字体显示效果测试页面 来挑选顺眼的字体。

第二步，设置opera使用该CSS配置。

打开菜单->[设置]->[首选项]->[高级]->[内容]->[样式选项]，在“我的样式选项”里选择刚才下载的user.css文件，保存！重启浏览器，即可看到效果！

这个做法的原理，是利用user css与author css之间的样式权重特点，通吃页面上所有文字的字体，强制设置成为自定义的字体（例如上面的雅黑），从而统一显示效果。欲了解更多的同学，请看W3.org上对!important规则的解释。

蓦然回首，原来我网购花费了这么多。。。

表现如此差，心中自然不爽。另外，也担心工作一年身体素质下降厉害，恐怕以后难以继承革命事业啊。

于是，之后几个月每逢周六下午我就自己去爬南山。登山依旧选阶梯——所以从北边的登山口上，然后越过山脊，接着从南边的登山口下去。全程约4、5公里，耗时近两个小时。下午四点出发，五点开始登山，7点左右下山坐公交车，路上吃一碗花溪牛肉粉。（那家店的菜式我彻底吃完了。。。）

每次登阶梯时其实都很累，甚至恶心欲吐；不过到了山顶后，健步行走于山林间，虽大汗淋漓却有清风徐徐，也是令人十分舒爽。手机上使用RunKeeper程序做了记录，发现自己每次登山耗时都差不多，没啥进步，郁闷。不过，登山本就是锻炼心肺锻炼耐力，哪儿会提高如此之快呢？也就释然。

话说，RunKeeper程序做得不错，搭配手机上的GPS，给户外运动助力很大。每次的记录都能够同步到网站上，我的历次记录地址是 http://runkeeper.com/user/dickeny/activitylist ，欢迎围观。

中秋节前夜那天，我怂恿了我的基友一起去爬山（口号是“登高赏月”）。基友很瘦，登山时完全不受万有引力约束，两步并作一步地走阶梯，飘飘然地登上了山顶，竟然一丝汗也没出！！而我当时也爆发了小宇宙极力跟随基友脚步，竟然突破了极限提速20%,仅花了18分钟就登上了山顶！！！后来再也没有过这样的突破了。。。基友果然是我无法超越的登山偶像。。。（提一句，山顶上看月亮果然很大很园～）

八九月去的很积极，几乎每周都去；十月放假和旅游，所以仅去爬了一次。今天小组再次举行活动，依旧是老套路爬南山。人员虽然还是五个，不过其中有两位是新入职的同事。登山伊始，我果断淡定地一步一步上，而两位“菜鸟”则是大步流星直奔——以我多次经验，这样子会突然给身体很大压力难以适应必然悲剧的——果然，还是六分之一的休息处，两位同学就累趴了……而我还体力充沛心平气和啊！心中那个爽啊！！第一次爬山时也在的另一个胖子显然也比不上我，浑身大汗气喘吁吁，呵呵呵呵～～～

于是和七月的那次爬山一样，登山过程里大家中场休息了几次，我也一点压力也没有，完胜！一雪前耻！！哇哈哈哈哈！！！

插点题外话：
1、爬山前，处于空腹状态比较好。因为腹腔压力很大，也容易感到恶心欲吐，午饭尽早吃。
2、RunKeeper的确很好用，推荐。虽然它每次报时总是卡在4:99, 9:99, 14:99让我很不爽。。。
3、我那台HTC Hero真是弱爆了。相机程序竟然会卡死，导致摄像头驱动挂了，然后无法再次启动了！只有重启手机才能解决！弱爆了！
4、iPad真是让我伤心。难得写好了几百字，谁知竟然因为没电而瞬间自动关机了！完全木有自动保存……而且iPad上面的手写输入法竟然无法手写除句号外的标点！你这是要让我回归文言文加强大家的断句能力么！

比起英雄无敌或者火焰纹章，韦诺之战有个很独特的地方，就是他的每一场战役里都没有「英雄」，唯一一些会导致战役失败的角色是领袖或关键人物，通常也只是带有领导技能，或者攻击力高一些罢了。游戏里没有力挽狂澜、万夫莫敌的兵种/角色，兵种一般最多三级，因此几个低级小兵也能围死髙级兵种——这个特性我认为再现了战争里的特点，靠的是全局统帅，而不是匹夫之勇。不过我最初玩韦诺之战时，却还是难以摆脱培养精兵、死绝小兵的思想，每当有三级兵种被人围攻致死，我总是会反复读档，然后刷概率，［扼住命运的咽喉］让他活下来。（后来学会来［放手］，虽然看着辛苦培养的高级兵种死掉很痛苦。。。）

韦诺之战另一个不错的地方就是种族设定比较平衡。人族、兽族、不死族、精灵族、矮人族、精灵族、蜥蜴族、人鱼族、龙族等等二十多个或大或小的种族，平衡性之间设置得很好，例如龙族虽然攻击里极其高，但是闪避率也很低，只要躲在树丛里就能放心虐待；而蜥蜴族虽然血少攻少，可是闪避率极其高，移动范围大而且还常常带有游击能力，最是折磨人。官方自带战役里，大多是人族的战役；不过我用iPad玩时，里面也带了很多其他族的战役——例如国庆时玩的《死水》就是人鱼族的战役，主要是对抗邪恶的不死族（我才知道人鱼族有这么多奇奇怪怪的兵种。。。）

以前大学时，经常是我自己一个人玩战役，韦诺之战其实带有网络对战功能，但是万恶的教育网连接国外实在是太慢，无法成功。倒是后来ghack同学也开始涉足Linux，看我独自一人玩韦诺甚是寂寞，于是就常常约我去他们寝室享受电信网络玩对战——当然，基本上我胜率比较高～嘿嘿～～单从网络上对战来看，官网上开房间对战的其实不多（都不够三国杀的一个服务器上的几分之一的房间数），不过另一个值得赞的是［附加组件］的网络功能，能够从官方服务器上下载网友们制作的各种战役、地图等等，数量庞杂，十分丰富。（可惜大多没有英文翻译）

韦诺之所以耐玩，有个很重要的因为是他的文档/帮助很齐全。所有的游戏元素，例如种族、特质、能力、兵种、玩法等都有相关的说明，很多战役都有各自的兵种（例如［沙漠精灵］啥的），兵种的特性由战役设计者来决定，而我们玩家随时都可以在帮助手册里查看到详细的说明（这里有个有意思的地方，如果某个兵种没有出现过，那么是看不到他的介绍的；即使是现有兵种的高级级别，也是只有升级的一刻才会开放说明）。每次的战役大多会有不同的兵种，虽然一般遵守韦诺里面的世界观，但是也会又细微差别；而且玩着战役、看着每个兵种的介绍，也会有一种［游览世界、有懂得多一些了］的感觉。

而设备支持方面，目前PC上玩肯定是没问题的，其他设备上我只看到有iPhone和iPad版本（收费$4.99）。国庆回家，因家中没有无线网络，我的iPad基本变成木板一块，于是我倒是狠狠玩了几天，体验不错，基本上完整移植过去了，只是郁闷的是没有中文（当然如果熟悉了，看英文也是没问题的）。

当然国庆在家，还另外用电脑玩了《堕入黑暗》战役，讲述愤青堕落为亡灵的故事，12关逐步学习不死族，最后一关无尽的黑暗还被我找到据点能够永远不死，哈哈。

（本来这篇文章是想用iPad 来写的，发现实在是效率太低，而且很累。。。）

第一天，路途。

早上九点坐车回家，结果遇上大巴晚点两个小时；然后高速公路上各种堵车封路。车上百无聊赖，各种微博彻底看完。。。漫长的九个小时，干坐在同一个座位上，真是「宅」到极点。
回到家后，终于能吃上一顿好的了。美美地细个澡，和小妹研究iPhone iPad Android，然后给小妹的安卓刷机。
深夜两点睡觉。结果再次悲剧了！！！凌晨四点胆囊炎发作了（半年前也是大半夜），腹部疼死了，苦熬到早上八点，吃了早饭才好一些。。。所以﹣﹣

第二天，困和睡

第二天更宅。笔记本路上貌似震坏了，硬盘不识别了，只好拿出iPad 来耍。又因为没有无线网络（乡下地区连CMCC也没有！！），所以iPad 都快变成木板一块了。看完电影，玩了一下DreamAirHD，结果要收费，就没玩下去；幸好事先购买了Battle of Wesnoth HD，于是整个下午就在津津有味地玩~直到第三幕被蜥蜴族狂虐待，才停下来。
然后五点半晚饭。然后觉得困，就倒床睡觉了，直到第三天早上八点才起来。。。睡了13小时。。。
当然，也不是一下子沉眠这么久，中途尿急，起来尿尿过；小妹跑上三楼客厅这里打电话，被吵醒过；然后她没有关客厅灯，我的房间门又只是虚掩而已，于是被刺目的灯光照醒；后来热醒了；后来下半夜起风下雨，起床关门窗；后来冷醒了；后来天亮了。。。
不得不感慨，乡下就是安静。。。

今早起来，听我妈妈说，昨夜火龙果第二朵花开了，很是漂亮。这植物也很奇怪，只是在晚上八九点中开花，然后就谢了，跟昙花一个德行。第一天我回来时恰好碰上第一朵开放，乳白色的花瓣，直径半米的大花，很是好看。

不过睡前看告警邮件，发现全系列的网络访问都不能进行，PING也失败，开始怀疑VPS死机了。。。

今早起来，在Control Panel上看VPS上的状态，提示的还是绿色的“Online”（你妹的，后来发现只要电源开着就算是Online！），但显然SSH已经无法连接上去了。

场景介绍完毕，顺便讲述背景

我的VPS是这款 Hostigation 上的KVM 128m，前几天买着玩，发现网络很好（什么pr路线啥的我也不懂），访问速度比之前的directspace快一些些（对于我这种被教育网毒害若干年的，内心一直怀着对网速的渴望）。这个KVM机器后台有个VNC登录界面，是Java Applet，于是捣鼓了一下（顺便吐槽一下openjdk-plugin，弱爆了），成功登录机器——结果看到界面后我惊呆了：

内存用完了啊亲！久违的Kernel Panic啊亲！！我第一次知道内存爆掉会连着内核也爆啊！！吐槽不能……只能默默的点击页面上的Reboot按钮……

深入内核被爆的秘密

其实内存不足的原因我也能大概猜到，机器上跑的是nginx + php5-fpm + wordpress。fpm这货根本就是内存大户，VPS上又只有128M内存+256M Swap，Wordpress博客又慢又胖，VPS上的CPU又不给力，监控宝还在其他地方默默地发起请求访问博客首页……所以访问不能承受之重，VPS内存溢出了。

为了验证，我祭出压力测试工具ab2（就是apache带的工具），首先小试一招：

悲催地看到，请求处理时间为1879ms。。。接近两秒啊！而从后台top命令可以看到 [php-fpm: pool www]这个进程突然冒出来，然后吃住20M内存不动了。。。

再来一次强大的招式，每秒并发10个请求，一共请求100次，看看啥情况：

偶也，跑了一分钟后突然来了一句超时，压力测试工具自动停了。这时候VPS上的悲惨状况我就不截图了（当时也没截图），内存已经彻底不够用，256M SWAP都快分配完毕了，幸好在悲剧重演之前，ab2工具自己停掉了，呼！看着岌岌可危的VPS，看着进程列表中满眼的 php-fpm，我只好默默地把他们都重启掉。。。

娇小的VPS果然不能承受野蛮的访问

研究出是php5-fpm的问题后，那就容易办了。按每个fpm进程20M内存占用来算，VPS上最多只应该启动5个进程；另外考虑到咱的博客基本没访问量，所以空闲fpm进程就设置为少一些吧。另外，也限制一下请求处理的时间，避免排队排到死：

这一次，再跑ab2压力测试工具，总算能够活下来了：

不过，悲惨地看到请求时延平均增长到了6秒。。。可见排队之长。。。

请求量之禅

这一次的事件告一段落了。不过有关这个请求量、处理时间的数值却引起我的思考。

目前这个弱小的kvm虚拟机，良好情况下，一个请求要消耗 2s，进程数限制是最多 5 个进程，这样所能承受的每秒最大请求是 2.5 r/s 。真是一个微小的数字。。。

在我的实际工作中，公司里的WEB机器跑的还是古老的C++写的CGI，一般单个CGI进程承受的访问量是 10r/s ~ 20r/s，机器配置是酷睿CPU+8G内存，一般CGI开50个进程（还同时跑着其他CGI），单机CGI承受量为500r/s（目前最高的我见过有1600r/s)。这时机器负载还算是正常服务，性能消耗还留有余地，一般CPU占用为30%，负载小于1，能再承受50%的高峰访问。

或许会问，有必要追求这个高的访问承受力吗？？实际上，我们公司的CGI部署起来，很少只用1台机器就够的。多数情况下，需要用4台以上（刚才提到的那个1600r/s的CGI），有些极高访问量的CGI会有每秒1万次请求，如果单机以 500r/s算，那么需要20台服务器组成集群来处理。而这些机器还只是专门跑WEB服务器的，DB还是另外独立部署，所以后面还有一大堆的DB机器……这些都是赤裸裸的钱啊……

所以，VPS什么的，真的是只能玩玩，搭个没访问量的个人博客。弱爆了唉。。。

最近一段时间主要在搜集动画电影看（非连续剧）。之前很赞赏《千年女优》，于是找她的编导今敏的片子来看。前几周看的是《Paprika》，讲述梦境与现实，当时里面人物切换变化细腻不突兀，给我一种［拍电影的话完全无法有这种效果］的感觉。心里隐约感觉动画别具一格。

以上都是背景。而这两天在批量看［豆瓣高分动画榜］里的电影时，尤其是看这部《Dead Leaves》时，以前的想法突然变得清晰，有一丝明悟。

所谓的动画就是一场梦境。

《Dead Leaves》这部片子完完全全体现了这个观点。且不说他剧情本身就很跳线、发展方向诡异奇特，更不说他的人设千奇百怪、充满妄想，单单说到里面的一些片段，就让人仿佛身处梦境。

片段一：失忆与似曾相识的过去。我自己（没体会过庄周梦蝶，只能以自己举例了）做梦时，忽然就会从某个片段开场，梦中我会浑浑噩噩，却又带有一丝清明，知道我能够做什么，应该怎么做。这部片子开场十几分钟，就是男女主角失忆登场、忽然又自以为是地去抢劫、然后还认为自己以前可能就是做黑帮的。没有背景、没有开始、没有独白介绍。宛如一场梦的开始。

片段二：女主回忆起身世时跳跃出现的记忆画面。这种风格其实电影也能剪辑出来，但是动画本身的［绘画］的特点使得他能自已变幻，更加突破电影的表现力。本片中有一段就是这个效果，而且还是有个老头参与双声道说话，极佳的梦之效果；另外一部片子《Mind Games》更是将这个特点用到极致，随意搭配时间，使得动画展示出来宛如［心头闪过无数念头］的真实体验。

片段三：随意变化地技能设定。这个必须是梦境（含白日梦）中的基本元素了！例如我以前做过一个梦，虽然我是人类、只能行走地面；但是梦境发展一半后，我却有羽族飞翔的能力（还深刻感觉到飞翔就是在空气这种液体里游泳）。当时我只用双手即可游翔，甚至还拥有百步穿杨的箭技，杀敌于万军之中，多爽！！而本片中，女主角本来也是普通人族，到了月亮上后忽然就变成了能在宇宙空间生存了，而且浑身冒火仿佛超级赛亚人；而男主角更是强大，一拳打碎巨型机器人、身形如风子弹打不中等技能都是基本的，更强悍的是他被人分尸后本来应该死了，却突然靠一个头就能活下来！而且还换了个机器人般的身体！Oh，god，这个的确就是在做梦了啊！

另外，还有女主的儿子，做爱当天立刻怀孕生子成长老死，蜉蝣般的生命大概是导演心血来潮的分支剧情；很多奇奇怪怪的克隆人失败之处（例如JJ成了合金钻头），也是体现了导演无比混乱、脱线的意淫。

说到底，我很怀疑，这个动画就是导演某次午睡的一个梦。

—–
以上即使对《Dead Leaves》这部片子的影评。然而，我还想补充一点理由。

动画切换时极大的自由性。在《千年女优》里这个技法用得很是成功，例如原本是在女主角在火车站月台上奔跑，忽地不小心滑到，就变成了她初次在那个男人前滑到在雪地里的画面；等她从雪中爬起，又回到了月台；她继续追赶火车，忽然又成了某部片子的拍摄现场……这个女演员的一生交织着过去与现在、生活与演戏，片子里这样的大量这种宛如梦一般的画面切换，仿佛一念之间置身于多个时空，思维片段自在地融合切换（或者说，搭错线？）。

总的来说，我觉得好的动画电影就是能体现我们的梦，能反映这些念头的闪现、记忆片段的切换。

（PS：这也是我为啥对宫崎骏的片子没感觉的原因。）

我那悲剧的笔记本电脑，5月份时挂掉一次，上个月又挂了一次。现在已经修了两个星期了，还木有消息。

于是搞的我心痒痒想去买平板电脑来替代之。不过还是忍住了。

另外，这个域名上个月又续期一年了，这个长草的博客至少还能残喘一年。

基本上，就这些了。

目前主要的三个版本管理系统分别是 svn, git, hg ，为啥是他们呢？因为googlecode.com上支持的就是这三个，可见其流行程度。

SVN是很早以前就出现的版本管理系统，适合于集中式的版本管理，就是咱们公司这种集中的版本server，改代码的人基本坐在一起。它一直流行至今，估计大家都很熟悉了，不多说了。

GIT是Linus同学为了解决Linux分布式开发的问题而弄的系统，它的特点就是拉取/合并分支非常简单，它与svn的不同之处是，它不全量保存每个文件，而是类似保存diff的方式存储每次版本的差异。这样存储方面会小很多，而且所以svn里需要拷贝目录的操作都变成了折腾diff，拉分支、打基线都不需要文件拷贝，很强大。

HG其实和GIT差不多，它出现的原因是因为GIT死活不肯弄windows版，所以HG就用python来开发，号称能跨平台。基本的操作方式抄袭GIT（其实版本管理就那么几种命令），因为我较少使用HG，就不详说了。

我个人比较喜欢GIT，这里有个好玩的网站( http://zh-cn.whygitisbetterthanx.com/ ) 对比说明了Why Git is Better Than X （为啥GIT比其他的XXX都强）。

PS：有个有意思的八卦，最初05年CVS大行其道时，KDE作为第一个大型软件工程切换使用SVN，证明了SVN的靠谱，于是广大人民纷纷跟进；去年，KDE迁移到了GIT，足以证明GIT的前途一片光明啊。。。

root/
├── src
│   └── aaa
├── tmp
│   └── bbb
└── doc

然后有几个目录是git archive打包时希望排除的。查看了一下手册git help archive，里面提到man gitattributes可以知道如何添加export-ignore属性，来排序不希望的目录。

经过十几分钟的折腾与搜索，终于弄明白.gitattributes的用法和里面的目录/文件的表达方法了。记录如下：

.gitattributes可以放在任意目录下。并且根据目录的不同，内容表达也有区别。 例如想要排除 src/aaa/目录和tmp/bbb/目录，可以这样写：

1、root/目录下添加.gitattributes文件，内容如下：

/src/aaa   export-ignore

/tmp/bbb export-ignore

2、或者分别在src/和tmp/目录里各自添加文件：

# src/.gitattributes

/aaa    export-ignore

# tmp/.gitattributes

/bbb   export-ignore

这里最蛋疼的就是目录的表达，必须以/开始，而且不能以/结尾。如果想要指定某个子目录，只用一个aaa只会被解释为当前目录里的文件，子目录只有写全路径。。。

另外，如果跑去 src/目录执行git archive master，那么所有的父目录都不会被导出，父目录里的.gitattributes也是无效的。

嗯。就这么多。备忘一下。

看完真是各种忧伤啊。现在听着片尾曲《转身之间》，更是觉得“依稀抓住了时间”，可却只是“寂寞如雪”。

说说片子里的人物。

几个男主角真是选得很恰当。令狐冲的两条眉毛经常跳来跳去的，然后常说着自认为 很有意境的话语。郭靖有点显老，不过的确是很憨厚。段誉的表情相当神奇，两条粗眉光是看着就觉得搞笑（可惜他的剧情没有出来，王语嫣很难选吧）。杨康很是贴切，双眼半眯，典型一脸欠揍的北京高才男。还有乔峰的大哥大风范，壮就一个字。

女主角选得感觉不够好。黄蓉不太符合我心中的形象，不过使小性子的样子倒有几分书中描述的味道了（其实女生撒娇都差不多唉）。穆念慈演的很是不错，怯怯的，沉默的样子，终究与杨康越走越远（配音我不太喜欢，应该更温怯的）。康敏演得更好一些，阿朱出场太少了，不过书里的康姐个子大概更矮一些吧？

片子里讲述了几个故事。郭靖的傻愣与黄蓉的 傲娇，杨康的臭屁与穆念慈的娇怯，乔峰与康姐的暧昧姐弟恋。还有段誉的痴迷和王语嫣的美丽没有讲述。125分钟的短暂时间讲述三个故事已经有些吃力了。以时间次序讲述郭靖与黄蓉的故事，然后穆念慈的独白悠悠吐露与杨康的默契与分离，最后是大段回忆来描写乔峰与康敏之间的暧昧。

《此间的少年》对我的影响有多大呢？大一时初读此文，顿时产生了对大学思念的美好向往，以为自己就是郭靖，必然能碰到桃花运；可是接着的几年却发展为段誉般的日日偷偷围观美女，有贼心没贼胆；大三时更是与杨康一般悲催，听到了初中时崇拜自己的妹子已经嫁人（谁当年不是学校里的某某某啊！）；到了大四，竟然发现自己连乔峰这样的暧昧都没有过，整整四年只是令狐冲一般的臭屁死宅、意淫无数、夸夸其谈罢了。想到这里更是觉得忧伤。

《此间的少年》文字版其实是没有结尾的，百度贴吧里无数人每年都要怨念很久。 可是没有结局也是很符合这本书的主题的。大学的四年，他们来了又走了，故事消散在校园的风里；而后来的新同学们，还会在风中演绎自己的故事……

另外，看了《此间的少年》，我一度以为康敏是个很正派很悲惨的人物，后来才发现在金庸的书里康敏是彻底的坏蛋。。。汗

附，我看的优酷在线的版本（虽然avi版正在下载，恐怕要很久了）。然后也找了片尾曲《转身之间》，歌曲真是忧伤。

直接测试插件的【发送邮件】却又是成功的。很纳闷。 却也怀疑是由于服务器上的主域名不是banjuan.net导致的。

问了谷哥，他说，那就安装一个SMTP发送邮件的插件呗。于是就使用了wp-mail-smtp插件。该插件的作用如下：

Reconfigures the wp_mail() function to use SMTP instead of mail() and creates an options page to manage the settings.

然后跑去多年没使用的Google Apps上开了个blog@banjuan.net的邮件帐号，填上。从此SMTP邮件就走smtp.gmail.com:25/TSL的通道发出了。

在网页上测试了一下@user的功能，已经能收到wordpress和mail to commenter的邮件了。啊嗯。

PS：顺便鄙视一下#中国电信#昨晚的网络速度堪比拨号上网啊！！！尼玛的分配给我的IP彻底错了有木有！连接网关都需要300ms的！！

他之前初中肄业，不爱上学校，于是四处乱窜。后来在某技校学了牙医。

他比我小一岁，已经在多家医院干过活了，现在回到我们老家那里，在自家楼下开了个小牙医诊所。每天工作就是给一边给病人【通通牙龈神经】，一边看看电影什么的。又是会到深圳广州玩几天，或是坐两天火车到北京【学习】。懂得玩，出手阔绰，牌友不缺，炮友也不缺。不过半年钱老母相中了一姑娘，所以现在算快有家室了。

虽然是乡下，病人却也不少，价格更是符合全国水平。固定成本很小，两三百块钱的器械转眼变成两三千块，所以月入万把块不成问题。

唯一缺点是乡下太沉闷，每天喂猪养鱼之后就无所事事了。

忽然之间想起来了我。刚毕业的愣头青。每天加班到9点。周末闷头死睡。工资小半奉献给房东，小半各种支出，剩下还得攒着做原始资本。平时的娱乐也是和我的老邻居一样，对着电脑上上网，只不过他打游戏我打程序。

睡前的时间还得用来看各种博客更新、推特更新，甚至没时间思考！

我还是乡里【传说】中的人物。

只不过各自的生活，哪个才是更好的？

因为网速慢，使用在线编辑很是折磨人。因此有时喜欢把文件下载到本地进行编辑。 而dokuwiki恰好是txt进行后端存储的，可以自由编辑，所以能供我实现git管理wiki。

工作列表

安装dokuwiki和Git
配置HTTP服务器，确保dokuwiki的安全
配置服务器的Git repo
配置本地的Git repo
配置本地编辑器（VIM的语法高亮）
安装dokuwiki

这个就不用多说了。在本文中，假设dokuwiki的安装路径是
/var/www/wiki/

服务器访问的URL是：

http://banjuan.net/wiki/

安装Git

这个更不用多说了。以我的Debian 6为例：
apt-get install git-core
配置HTTP服务器

这一步的主要工作是确保dokuwiki的安全性。根据官方安全指南 上的介绍，需要确保以下目录无法通过URL进行访问：
/wiki/(data|conf|bin|inc)

本文接着所创建的Git repo，是在目录/var/www/wiki/data/下的，故而需要保证安全性。
配置Git repo

大概的命令如下，主要是设置一下git，允许作为服务器repo接受代码提交
cd /var/www/wiki/data/
git init –shared
git config receive.denyCurrentBranch ignore
git add pages/ media/
git commit -a -m ‘initial’

为了让服务器上的Git能够在版本提交时自动更新文件，需要设置hooks。下载 文件post-receive，放到.git/hooks/目录下，或使用以下代码：
cd /var/www/wiki/data/
cd .git/hooks/
cat > post-receive <<_EOF
#!/bin/sh

cd ..
env -i git reset –hard
chown www-data:www-data * -R
_EOF

然后给服务器添加定时命令，合并网页编辑wiki所产生的变更：
crontab -e

然后在最后添加一行：
0 */1 * * * cd /path/to/htdocs/wiki/data/ && git add pages/ media/ && git commit pages/ media/ -m ‘update’ &>/dev/null || true
配置本地Git repo

在本机上取出服务器上的wiki（使用ssh作为传输方式。git web服务器什么的不再此讨论范围）
git clone ssh://banjuan.net/var/www/wiki/data wiki

进去后即可看到所有的wiki页面都在pages/目录下，媒体文件则在media/目录下。

如果需要添加commit自动上传到服务器上的功能，那么给本地git repo添加hooks:
cd wiki/.git/hooks/
cat > post-commit <<_EOF
#!/bin/sh
#

echo “Auto push to server ….”
exec env -i git push
_EOF
配置vim语法高亮

因为dokuwiki的页面文件的后缀是.txt，而且它的语法与标准的wiki有些不同，因此需要额外的语法高亮支持。

此处我使用的编辑器是vim，因此可以在vim网站上下载安装dokuwiki语法高亮文件。

如果不熟悉dokuwiki的语法也没关系，版本库中自带了一个语法说明的wiki页面，路径是pages/wiki/syntax.txt，大概直接参考即可。
参考
如何自动更新服务器上的Git工作目录树: http://debuggable.com/posts/git-tip-auto-update-working-tree-via-post-receive-hook:49551efe-6414-4e86-aec6-544f4834cda3

PS：实践证明，博客是还是适合贴纯文字的文章。技术文档以后就贴去wiki里算了。

目标

这里，我的目标是使用宏进行代码生成。例如以下宏：
ATTR(id, name, value, price)

需要展开为一组函数调用：
read(“id”, item->id);
read(“name”, item->name);
read(“value”, item->value);
read(“price”, item->price);

而上面的宏是在一个更大的宏中使用：
LOAD_ITEM(MyLoader, \
ATTR(id, name, value, price), \
GROUP(prize, p_id, p_value) )

这个大宏需要展开为一个函数体：
int MyLoader::load_item()
{
read(“id”, item->id);
read(“name”, item->name);
read(“value”, item->value);
read(“price”, item->price);
while( m_xml.findChildElem(“prize”) )
{
struct prize* sub_item = new struct prize;
read_sub(“p_id”, sub_item->p_id);
read_sub(“p_value”, sub_item->p_value);
item->prize.push_back(sub_item);
}
return 0;
}

ATTR(id, name, value, price) 的实现

先说一组函数如何生存吧。这个其实就是个for/while循环，或者理解为递归也行。

可是GCC不支持宏的循环/递归处理。宏的复杂应用一般也就是不定项参数了（通常 是封装printf之类的），可是那也就是将参数直接传递罢了。

从我查阅到的资料来看，所有的递归宏处理都是转化为了【穷举】进行实现的。

穷举 =？ 递归

由于宏ATTR()的参数是任意个属性，可以预先设定好参数的最大个数，然后人肉 递归，穷举出所有的展开结果：
#define ATTR_(attr) read(#attr, item->attr)
#define ATTR_0(attr, args…)
#define ATTR_1(attr, args…) ATTR_(attr); ATTR_0(args)
#define ATTR_2(attr, args…) ATTR_(attr); ATTR_1(args)
#define ATTR_3(attr, args…) ATTR_(attr); ATTR_2(args)
#define ATTR_4(attr, args…) ATTR_(attr); ATTR_3(args)
#define ATTR_5(attr, args…) ATTR_(attr); ATTR_4(args)

那么，如果有四个参数，就可以直接调用ATTR_4()这个宏来处理四参数的展开：
ATTR_4(id, name, value, price)
=> ATTR_(id); ATTR_3(name, value, price)
=> ATTR_(id); ATTR_(name); ATTR_2(value, price)
=> ATTR_(id); ATTR_(name); ATTR_(value); ATTR_1(price)
=> ATTR_(id); ATTR_(name); ATTR_(value); ATTR_(price); ATTR_0()
=> ATTR_(id); ATTR_(name); ATTR_(value); ATTR_(price);

可是，如果我有五个参数，咋办？？？只有乖乖调用ATTR_5(….)这个宏。 这种人工计算参数个数的做法实在是土。有没有办法自动计算参数的个数？？

GCC的预处理器并没有提供参数个数的变量，而且貌似网上也很少有人提到需要这个值。 不过，今天查看维基百科上的资料时1)，意外的发现 有人实现了一个宏 2) ，用来计算参数的个数：
#define PP_NARG(…) \
PP_NARG_(__VA_ARGS__,PP_RSEQ_N())
#define PP_NARG_(…) \
PP_ARG_N(__VA_ARGS__)
#define PP_ARG_N( \
_1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \
_11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
_21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
_31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
_41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
_51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
_61,_62,_63,N,…) N
#define PP_RSEQ_N() \
63,62,61,60, \
59,58,57,56,55,54,53,52,51,50, \
49,48,47,46,45,44,43,42,41,40, \
39,38,37,36,35,34,33,32,31,30, \
29,28,27,26,25,24,23,22,21,20, \
19,18,17,16,15,14,13,12,11,10, \
9,8,7,6,5,4,3,2,1,0

真是精巧呀。使用 PP_NARG() 宏，我们就可以自动将 ATTR() 转换为对应的 带参数个数的穷举版宏了。
#define CONNECT(a, b) CONNECT1(a, b)
#define CONNECT1(a, b) CONNECT2(a, b)
#define CONNECT2(a, b) a##b
#define EXPAND_NARG(name, args…) \
CONNECT(name, PP_NARG(args))(args)

#define ATTR(args…) EXPAND_NARG(ATTR_, args)

以上宏定义整理在文件macro.h中了，读者可以下载回来使用 gcc -E 展开宏， 尝试一番。

LOAD_ITEM(loader, code1, code2, …)

使用上面的宏，已经可以搞定 ATTR() 和 GROUP() 了。至于外面的大宏， 实际上是先展开为一下的代码：
LOAD_ITEM_FUNC(MyLoader)
{
ATTR(id, name, value, price);
GROUP(prize, p_id, p_value);
LOAD_ITEM_END();
}

上面的代码再进一步展开为实际的函数体。

对于这里的展开，我暂时还没发现什么巧妙的做法，唯有使用上述的【穷举法】。 具体就没啥技术含量了，也不再多解释了。

参考

* Roland Illig, Re: __VA_NARG__, http://newsgroups.derkeiler.com/Archive/Comp/comp.std.c/2006-01/msg00072.html
1) 一时找不到来源了，明天补上
2) 这就是今天最大的收获啦~~

以django项目中的某个功能为例，网址http://py.banjuan.net/tool/build_recipe/对应django工程中的某个函数 tool.build_recipe(request)，这个网址GET的时候吐出网页，而POST的处理结果以json方式返回。那么我们就可以编写两个装饰器来专门处理这种页面渲染和json转换：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from django.http import HttpResponse

from django.utils import simplejson

from django.shortcuts import render_to_response



def page_render(view):

    def func(request, *arg):

        (tpl, ret) = view(request, *arg)

        return render_to_response(tpl, ret)

    return func



def json_render(view):

    def func(request, *arg):

        pydata = view(request, *arg)

        json = simplejson.dumps(pydata, ensure_ascii=False)

        return HttpResponse(json)

    return func

如果需要装饰，那么就是这样写：

1
2
3
@page_render

def build_recipe(request):

    return "running build_recipe"

给略懂python额外讲解一下，上面的代码定义了两个函数page_render, json_render，函数的返回值还是函数。当这两个*_render（其实就是所谓的装饰器了，和普通函数没啥区别）用来装饰build_recipe(request)时，就会起到【李代桃僵】的左右，实际执行的就只是func(xxxx)了。被装饰的原函数build_recipe(request)会作为参数传递给page_render。形象地理解，上面那句@page_render会等效于：

1
build_recipe = page_render(build_recipe)

实际上，我的代码中是这样写的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
def build_recipe(request):

    #@csrf_protect

    @page_render

    def get(request):

        return ("tool/build_recipe.html", {})



    @json_render

    def post(request):

        content = None

        if 'content' in request.POST:

            content = request.POST['content']



        if 'recipe' in request.FILES:

            f = request.FILES['recipe']

            content = f.read() 



        ret = 1000

        if content:

            name = mktemp(prefix=u'ebook-', suffix='.recipe')

            with open(name, 'wb') as f:

                f.write(content)

                f.close()

            cmd = EBOOK_CONVERT%(name, name+u'.mobi')

            #ret = os.system(cmd)

            ret = cmd

        return {'ret': ret}



    if request.method == 'POST':

        return post(request)

    else:

        return get(request)

根据request.method来分流处理，get()/post()只是返回基本数据，然后交由各自的装饰器进行数据渲染（弄成网页，变为json等）。于是上面的page_render/json_render便可以大量应用与其他类型的函数上，节省代码。

而在实际项目中，除了页面渲染，一个网页请求可能需要先验证登陆态、然后校验典型参数的有效性，为了调试还得统一捕抓异常，为了对付各种黑客还需要csrf_token（就是上面那行注释掉的装饰器），返回结果也还要统一，等等。这些公共的操作都是可以使用装饰器来实现。根据不同的页面权限，组合使用不同的装饰器（会从上倒下层层装饰），达到简化工作的目的。

当然，装饰器的另外一个作用技巧是用来实现注册功能，能够【显得】简约、整洁许多：

1
2
3
4
5
6
7
8
9
10
11
12
funcs = {}

def register(func):

    funcs[func.func_name] = func

    return func



@register

def abc(msg): print msg



@register

def show(): print "hello"



print len(funcs), " functions registed"

最后，果然觉得python的诡异细节真是无穷尽啊。

啊，补充说一下。最初想要用装饰器，是因为calibre的处理recipre的代码中，下载url的start_fetch(url)被调用得太过凌乱了，手动修改各处调用来增加cache会很崩溃的。于是就想到了【李代桃僵】的装饰器的特性，虽然其他地方仍然是调用start_fetch(url)，但是已经被我神不知鬼不觉地掉包了，HACK成功！或许有人会想，为啥不直接修改start_fetch(url)的内部代码？？介个嘛，这要是因为start_fetch(url)内处的处理也很冗长凌乱，改起来也很崩溃……所以，还是【装饰器】好用啊！

手动编译安装。默认带的配置nginx.conf有简约的例子。照着做。不懂的问谷歌。

。。。可是。。。然后。。。我竟然搞不定配置。。。恨。。。

说不出哪里不对，折腾了一晚上。郁郁地睡去。

今天早上起床，不再看各种博客、教程、谷歌了，直奔nginx.org看英文wiki！于是，发现了第一个趣事：

Nginx works perfectly well with a wide variety of applications, and WordPress is certainly one of them. NginX’s configuration language is very powerful and straightforward if one is familiar with it, but often people coming from other servers are not sure how things work in NginX and just copy and paste whatever they see from a blog that seems to fill their needs. Everyone, especially people new to NginX, should check out the nginx.org documentation for an overview of how things work and should be done in NginX.

加粗部分即为亮点。大意是说，nginx的配置是很牛X的，但以前使用其他HTTP服务器的人常常不知道nginx的配置咋整，然后就从网上随便找个博客改改别人的配置就贴过来了。。。天啊！这不就是在说我么！！多次经验证明，拷贝配置是最纳闷最悲剧的事了。。。所以，大家要多去看nginx的文档啊！

然后我就虚心地阅读文档。嗯，原来nginx.conf里面的配置段是层层继承的，server{}里的root配置会继承给location{}，所以那些每个location{}里都定义root的人肯定都是折翼的天使了。不过，Reference location的说明中，对某个有趣的特性讲述得太简陋了，倒是在try_files的说明里对location的@特性有个很详细的举例，我这里做一个类比：

# @xxx 定义一个名称
location @dabr {
  rewrite /([a-z]*)/(.*)$ /$1/index.php?q=$2&$arg;
}
location /netputer/ {
  try_files $uri $uri/ @dabr;
}
location /mytwitterapi/ {
  try_files $uri $uri/ @dabr;
}

我的理解就是，@abc能够用来给try_files之类的命令提供一个增强处理的机会，进行if{}判断啊，rewrite一下啊什么的。很少在其他博客中看到对这个特性的介绍，发现它觉得有些小惊喜。嘿嘿

另外，在第一篇入门指引上还发现了一个对php.ini的配置的安全提示：

As said previously, Nginx does not care about files but rather locations. This location block matches a URI that ends in .php but it does not care if it’s a file or not. Therefore a request for /forum/avatars/user2.jpg/index.php will be matched and sent to PHP, and if PHP is not configured properly PHP will then execute /forum/avatars/user2.jpg when /forum/avatars/user2.jpg/index.php doesn’t exist. This provides a huge security risk. Do note that this is not a bug in Nginx, it’s the intended behaviour and as such will not be “fixed”.
This can also be fixed on the PHP side by setting cgi.fix_pathinfo=0 in the php.ini file.

我了个去！再次说明网上教程什么的真是不靠谱啊！！例如我搜索【nginx php debian】所看到的这篇教程，里面就特别说明了要把fix_pathinfo设置为1（默认是0的）。。。而我还傻傻地信了。。。

最后，就是照着wiki，参考Reference来配置好了nginx。由于是手动编译nginx的，所有/etc/init.d/里没有nginx的启动脚本。不过尝试执行nginx -h，却发现它的命令行参数及其简约。其中有个参数-s signal基本上类似于一个控制器了，能够让nginx进程重新读配置、退出等：

-s signal : send signal to a master process: stop, quit, reopen, reload

嗯，所以觉得nginx还是很好很强大的嘛。。。

PS: blogilo程序还是不够靠谱。发表完后总是还要到wordpress后台进行二次排版。囧。

然后一看，移动硬盘上的数据烟消云散了。

悲痛啊！比清明节上坟还悲痛啊！有木有！

赶紧祭出Testdisk工具，选择undelete工具来扫描（插一句，openSUSE源里的testdisk没有编译支持ntfs，汗），可是怎么扫已只能发现一个文件！还是我上周正常途径删除的！我积攒了多年的200G的电影资料难道就要离我而去？！

我想着，这文件系统格式是NTFS的，还是去看看windows下有啥工具来恢复吧！赶忙重启进windows，下了一个叫【undelete plus】，结果也是和testdisk一样的德性，只发现了一个文件。估计其他finalData之类的也不会很给力了。。。

重新回到Linux系统下。正心灰意冷，猛然发现有个工具叫ntfsundelete（怎么发现的？输入ntfs，然后Tab列出所有命令[grin]），惊喜啊！赶紧使用：

哗啦啦啦处理3000+个文件结果！！感动得想哭！T_T 不过这些被删除的文件都被擦除了文件名，这大概也是其他工具无法扫描出文件的原因？

(找了个网上的图片来示意一下）

不管了，反正我就开工恢复数据！因为文件名都丢失了，所以就逐个恢复了。然后就是一个一个inode来恢复。。。

然后用file命令来猜测文件类型。然后再用mplayer来播放一下，看看是啥电影。。。

1
2
$ file 68412.data

68412.data:　Matroska data

痛苦的是，笔记本硬盘只剩50G空间，而移动硬盘的数据至少有200G。。。我的电影们，你们安心去吧。。。

最后，总结，如果NTFS上的文件被误删，不妨到linux下来恢复之

PS: 刚才又谷哥了一下，发现windows下也有个工具叫ntfsundelete呢，不知道是不是同一个。。。？

去年愚人节进行了疯狂的大表白，今年惯例还是要发这个的。还是挑高中和大学的同学、加上公司的同事（才有数人手机号而已），再次发表白短信：

“我一直偷偷喜欢着你，你可喜欢我？”

一共发了130+条，其中有40+发送失败的，收到36个人的回复。其中才只有7个女生回复……再次发现我认识的女生太少了。（幸好比去年多了）

还是摘抄一些回复吧：

• 首推琼瑶阿姨版（某博士哥哥的回复）：

我也无比思念…每每想起泪如雨下…你还好么？

• 强推反愚人版：

我苦笑阿，你和班花一个人发就够了，如果有需要我可以配合的。我刚被暗恋了十一年的梦中情人拒了，真的心情不怎么好。。。

• 演戏版：

等你这句话很久了，我也对你很有感觉

我等你的表白这么多年了,现在迟了,我心里已经有其他人了……

• 欲擒故纵版：

你喜欢我什么，我改还不行吗

倒，我说同学，虽然今天是愚人节，可你也不能这样群发短信吧，哥是男滴啊

• 一针点破版：

别指望我能上当/虽然我手机没你号码’但现在还是禺人节的最后半小时-

哎呀我擦，你tmd别恶心我了

• 发错号码版：

你是哪个,说话!

不知道你是。。。？

• 直接拨打电话过来版：

前面的那博士GG和第二天接到的一个小MM的回电（汗，不知道会不会令人家小MM春心萌动）

最后摘录一个长篇对话版：

你已经连着两年发这样的短信给我了 我是不是可以认为你不是在整蛊我？

你终于被我感动了！！

………愚人节表白会有女孩子相信么？

这样才能深入发展关系嘛。。。

反正我是不相信的……

真是残酷的句子。。。

因为这个说喜欢我的人会在一个可以用玩笑当借口的日子表白 我怎么敢相信他是真的喜欢呢 对么

没头没脑地表白你也会考虑的么。。。太饥渴了吧。。。

你不就挺没头没脑的开我玩笑么……

囧。被反攻了。。。

以后对其他人别这样啦 喜欢的话要堂堂正正的表白去 就这样啦 愚人节快乐 晚安

嗯。就这么多。明年继续表白吧！