年齡越大,越有種對失去自由的恐懼。“老牛自知夕陽晚,不用揚鞭自奮蹄”,於是越來越想走得遠點兒,然後就看到了這本書。這是我第一次正經買電子書,花了3¥,用了五天的時間。
這是本遊記,主要講的是作者十年旅行的見聞和心路歷程,從自然平實的詞句中可以看出作者心態很平和,能體會這種心態,已經很好。

PS: 有点淡淡的忧桑,今天,我高考十年……
年齡越大,越有種對失去自由的恐懼。“老牛自知夕陽晚,不用揚鞭自奮蹄”,於是越來越想走得遠點兒,然後就看到了這本書。這是我第一次正經買電子書,花了3¥,用了五天的時間。
這是本遊記,主要講的是作者十年旅行的見聞和心路歷程,從自然平實的詞句中可以看出作者心態很平和,能體會這種心態,已經很好。

PS: 有点淡淡的忧桑,今天,我高考十年……
I replaced NeoComplCache with YouCompleteMe today. The main reason is for the auto-complete feature and the fast speed. Besides, it seems that YCM provides more features than NCC.
Although NCC can also do auto-completions, it was so slow that I had to turn it off. For a long time, I have been doing completions by triggering the TAB key manually. YCM is much faster in most conditions, but I found it is also slow for C source files. Moreover, with the power of jedi, YCM makes completions of python sources much wiser, which is very convenient.
Then a problem raised again. It’s the confiliction of mappings for Tab key between YCM and UltiSnips. Many people changed the default mapping of either YCM or UltiSnips, but I cannot tolerate that. I insist that the most convenient way is UltiSnips having a higher priority above YCM, which means, when Tab is triggered, UltiSnips expands the snippet, if there is not a valid snippet, YCM will take over the job.
Fortunately, there is a solution. The idea is the same with my former post about NCC. I made it by the help of SuperTab.
I have to say that UltiSnips is a well-written script, it passes Tab key through if there is not a snippet. Then SuperTab will be triggered. Since the default action of SuperTab is customizable, so I can set it to the key-binding of YCM. That is the whole trick.
First, change the default key-binding of YCM to <C-TAB> and <C-S-TAB>:
let g:ycm_key_list_select_completion = [‘<C-TAB>’, ‘<Down>’]
let g:ycm_key_list_previous_completion = [‘<C-S-TAB>’, ‘<Up>’]
Then set the default action of SuperTab to triggering <C-TAB>:
let g:SuperTabDefaultCompletionType = ‘<C-Tab>’
OK, job done.
I have been using Pathogen for a long time and I am happy with it. But it seems that more and more Vim scripts are recommending to use Vundle in their install references. So I made a study today, the conclusion is, although almost all the articles I found from Google have a positive attitude on Vundle, I still prefer Pathogen.
Most supporters of Vundle praise it for one reason, that is, it can install and update scripts automatically, which is lacked by Pathogen. Yes, since Vundle leverages the vim-scripts repository on GitHub, it is really easier to do so than Pathogen. But the disadvantage is as good as the advantage. I found that the vim-scripts repo is not updated in time, the latest activity was carried out a month ago ! As an OCD patient of updating, I cannot tolerate old versions of vim scripts. Although that Vundle supports using scripts’ git repos of their own (either on GitHub or other places), there is still a problem, what if authors commit broken code to the master brunch ?
Moreover, not all scripts are deposited in public git repos. How can I organize those scripts in ~/.vim/bundle/ and prevent :BundleClean from deleting them at the same time ?
Pathogen only handles the organization job that puts scripts in individual folders under ~/.vim/bundle/, so there is without the above problem. For updating issues, GetLatestVimScripts.vim is a good choice, it fetches the latest stable updates from vim.org, so I don’t have to worry about careless commits. The only problem is, when GetLatestVimScripts.vim downloads all packages, I should install them manually. But since most scripts rarely update, I think this is not a hard work to do.
KISS things are always good.
13年5月,騎行京西古道。
從水峪嘴下去,進京西古道風景區,通過牛角嶺關城,到落坡馬志遠故居,然後經韭園橋沿永定河谷至擔禮大橋進入G109。
京西古道風景區收20¥,裡面有博物館、軍事酒吧、古道和牛角嶺關城。博物館其實就是個村史展館,很小,沒什麼內容,就一間屋子,一覽無餘。古道是亂石砌成的,非常不平,推車上去很累,好在只有一千米長:

牛角嶺關城,看著像個磚窯,地上的石頭溝溝坎坎:

馬志遠故居,看著像重建的,刻意營造成“小橋流水人家”的樣子,裡面就一四合院,收費10¥,沒進去。附近有一山泉,想老馬也算過了一把農婦山泉有點兒田的癮,夫復何求。

永定河谷一線的景色非常好,可惜沒有拍照。
默認情況下,ROX-Filer會將“*.docx”、“*.xlsx”、“*.pptx”文檔識別為zip壓縮包。由於ROX中與文件關聯的行為實際上都是和文檔類型掛鉤的,所以對這些文檔的操作會遇到很大麻煩,而且沒有變通方法。
實際上,Linux對文件類型的識別比Windows靈活。Windows只能通過文件名的後綴判斷文件類型,隨便創建一個文本文件,然後將後綴“.txt”改成“.exe”,Win就會傻乎乎地認為這是個二進制的可執行程序。這種做法很傻,而且很不安全,試想,如果將一個病毒程序的後綴改成“.jpg”,就可以騙過大多數用戶,然後通過某種手段執行它,後果會怎樣?更傻的是,XP以上版本默認是隱藏後綴的,那攻擊者連改後綴都可以省了。顫抖吧,神一樣的Win!
Linux不但可以通過後綴識別文件類型,更重要的,還可以通過文件開頭的幾個字節實現這一點,這就比前一種方式精確、安全很多。當然,Linux還支持更多的文件類型識別方法。
前面說過,在ROX-Filer下,所有行為都綁定到文件類型上,也就是MIME Types,ROX通過這種方式實現了將可靈活自由定製的文件操作與自身解耦,從而在確保自身穩定的同時實現對高度靈活的自由定製的支持,這是一個很值得學習的實現方式。因此,既然文件的後綴沒有問題,ROX仍將它們識別為ZIP格式,原因是什麼?顯然,最大的嫌疑集中在第二種識別方式上。
一個公開的秘密是,Office文檔本身其實就是一個ZIP壓縮包,裡面包含了描述文檔的XML、多媒體文件等成分,只不過MS賤賤地把壓縮包的後綴改成了docx之類的東東,加上Windows只能通過後綴識別文件類型,所以很多人不知道這一點。瞭解了這個,問題的原因就躍然紙上了,既然都是ZIP壓縮包,那第二種文件類型識別方式也就區分不出Office文件類型與ZIP壓縮包了。
能號出病因,就有方子治病。
既然ROX使用多種文件類型識別方式,那必然有一個優先級的關係,否則就會亂套。打開ROX的MIME Editor:

找到MIME類型“application/zip”:

打開zip的屬性對話框:

可以看到“Contents matching”這一塊裡,通過檢查文件頭部的幾個字節是否為“PK\003\004”來判斷,並且此項判斷標準的優先級是40。下面所要做的,就是找到相應文件類型,添加一項條件相同的“Contents matching”,並把優先級設得大於40。
12年8月,去樂山、峨嵋玩兒了兩天。
樂山大佛真的很大:

據說佛爺頭上的便便越多,表示智慧越大、級別越高:

峨嵋金頂的十面普賢菩薩,美輪美奐,從沒有見過這樣一尊佛像,能讓人在看第一眼的時候就感受到震撼:

雲開日出時的十面普賢,那一瞬間,場面無以言表,極為震撼人心:

剛到樂山時看到路邊的條幅,才恍然想起這是祖師爺的老家,沒時間拜謁,罪過罪過。這次旅行最大的收穫就是看到了雲開日出時的十面普賢,是我迄今見過的最攝人心魄的景觀。
今晚參加了綠野夜爬百望山的活動。主要為了認一下路,以前逃票都是從公路旁柵欄的缺口鑽進去的,後來封了就沒再去。
站在望京樓上俯瞰夜色中的帝都:

活動強度很低,適合下班後鍛鍊一下。百望山很矮,但是叉路很多,有的爬了。
綠野的活動。
頭天晚上的汽車,第二天早上三四點到恆山後山,五點出發。很冷,除了T恤,就穿了一件冲锋衣,冻得直哆嗦,不过一开始爬就好多了。上山的地方不知名,不是传说中的后山山门附近。爬上第一个山顶,转过去就是修好的登山道,放眼可见莽原与群山:

底下就是我们当晚要宿营的恒山湖:

朕與江山:

再往上没多远就是山顶,恒山海拔虽高,实际爬起来难度很低。

都说前山景色一般、精华在后山,没感觉,也许跟我们走的路线有关,倒觉得前山附崖而建的寺庙耐看:

逢山必看摩崖石刻:

前山處處隱沒在山林中的寺廟,很有意境:

邊下邊逛,中午就下了山,不明白這麼一座平平無奇的山怎麼稱得上北岳恆宗:

然後坐車去懸空寺,寺小、人多、票貴,沒上去,遠遠地拍上幾張交作業:

不宿營的人坐車去渾源縣城住宿,我們徒步走回恆山湖扎營。湖並不好看,水也不怎麼乾淨,有人釣魚,空手而歸,好在湖邊有小飯館,好吃就別想了,聊勝於無。扎營地是山腳一個凹口,是片干了的湖底,沒草,所以帳蓬容易進灰而且硌得慌,遠不像想像中青山綠水草地上伴著明月篝火清風入睡那樣享受。


雖然沒有魚,篝火還是要有的:

除了被凍醒一次,一夜無話。第二天早上坐車去渾源縣城吃傳說中的小媳婦涼粉,這個地方的涼粉配料有特色,主要有三樣東西:不辣的辣椒油、豆干和炸蠶豆,而作為主料的涼粉本身卻並不比其它地方的特別,我想像中好的涼粉應該是入口即化的。不管怎樣,有這樣的經歷也是好的:

然後坐車去雲岡石窟,首先進去是靈嚴寺:

靈嚴寺的塔和佛像都很有特色,不著重彩,呈乳白色或米黃色,觀感素雅:


雙層建築在我到過的寺廟裡是第一次見到:

大雄寶殿門口的黃金樹很耀眼:


寺後就是雲岡石窟,風化的石壁很有滄桑感,與前面金碧輝煌的靈嚴寺對比鮮明。最近越來越不喜歡破敗的事物,所以在前面寺廟的興致至此稍挫:

大窟中的巨佛,依稀可見鮮卑帝國時代的盛況:


石窟的外部原本都是有附崖建築的:

下午四點,坐車返京,晚上九點左右抵西直門散夥。
活動貼在這裡:http://bbs.lvye.cn/thread-780144-1-1.html
最後是恆頂合影:

春節前花了一周時間讀完了這本書。
是本不錯的Android入門教材,能讓人快速地搭出開發環境,瞭解Android應用的運作機制,對於移動應用開發的初學者尤其有用。當然,這種書一般不會講得很全面,更深的東西還是要看官方文檔,只是Android的官方指南寫得比較散,並且過於簡單,不適合初學者。

DualHead Watchdog is a Linux desktop app which runs commands or scripts after display settings are changed.
It is especially usefull for users who prefer window managers to those huge desktop environments. For these people, wallpapers often cannot be ajusted automatically when the screen size is changed or dual-head display is started. With this app, people can run custom commands to reset the background image when the display settings are changed.
For example, I use i3wm in my daily life and I use dual-head display, my laptop has a screen resolution as 1366x768 and my outer display is 1920x1080. So when I start the dual-head display, the background image in the outer display is tiled with 1366x768 images. So I put the following commandline into this app:
feh --bg-scale ~/.wallpaper
”~/.wallpaper” is a soft link to my wallpaper. So when dual-head display is started, this command will be called and my wallpaper will be reset to fit the new screen size.
More than that, users can make this app do everything when display settings are changed. At the moment, there will be a ‘monitors-changed’ and a ‘size-changed’ event, users can specify which event to listen to for each command.

version 1.0.0 (2013-02-06 Wednesday 15:14:24)