版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
http://www.chedong.com/tech/study.html
關鍵詞： google Open Source Gnu search 工具箱 學習 E-learning
內容摘要：
Google的使用如此重要， O"Reilly有本專門的書介紹了如何優化網站面向Google的設計，和使用Google的一些技巧：
http://www.oreilly.com/catalog/googlehks/ 這里我很想把以前遇到類似問題時在Google上尋找資料的思路和大家分享一下：
足夠“多”的特征關鍵詞是快速定位的關鍵
有朋友問我：在
如果用戶理解了使用更多的關鍵詞可以更快的定位到所需要的信息這一點的話，那么每次查詢時用戶使用的關鍵詞個數就反映了用戶的搜索引擎使用水平，根據在1997年，英語國家的用戶平均每次上網查詢鍵入2.1個單詞，歐洲其他國家為1.5個單詞；到1999年，英語國家是2.7個單詞，歐洲國家是2個單詞。英語國家用戶的經驗值要領先其他國家將近1年半的時間。中文搜索引擎也將經歷一個用戶經驗值逐漸提高的過程。 
從中我們可以想象在互聯網資源的使用水平上中國和國際先進水平的差距。
提高搜索結果質量的途徑：使用英文專業術語、文件類型過濾、專業站點站內搜索
2000年1月，Excite公司的科學家對全球約6.4億的Internet網頁進行了語言認證，發現其中英文信息內容占了71%，而日文是6.82%、德文是5.08%、法文是 1.75%、中文則為1.52%。如此豐富多彩的英文海量數據庫，勢必吸引著英語國家的上網用戶不斷應用搜索引擎去尋找那些有價值的信息內容。使用英文專業術語：學會把自己的問題翻譯成英文后再查最近一次經歷是找一個Linux應用的安裝文檔，但用中文關鍵詞搜出的內容大部分很多都很舊，甚至有基于RedHat5.2的，而且絕大部分只是的把臺灣開發人員寫的繁體板HOWTO轉成了簡體中文，此外，由于一些計算機名次中文名稱的翻譯不一致也限制了搜索結果的數量和質量。所以目前來說，質量比較高的仍然基于是相應領域英文關鍵詞的搜索。比如，我在解決Perl源代碼格式美化的過程中學到了 indent，pretty print和source code beatufier這些術語。通過這些關鍵詞，也方便我找到了其他開發語言的代碼格式美化工具。
文件類型過濾：
Google有對PDF, Word(Power Point, Excel), PS文檔的索引能力，由于這種文檔的內容比一般的HTML經過了更多的整理，學術價值一般比較高，所以這些類型的文檔天生就比一般的HTML類型的文檔 PageRank要高。可以通過"filetype:pdf keywords"這種格式過濾返回結果的文件類型，從而提高搜索結果的質量。
利用站內搜索減小搜索范圍：
如果某個站點的結果數很多，Google會類聚成2條，并可以通過“www.example.com 站內的其它相關信息”執行站內檢索，在查詢的命令中其實就是"site:www.example.com keywords"，所以很多時候可以進一步通過站內檢索將搜索結果限制在某些專業站點的范圍內，這樣很多問題的資料往往可以從其官方站點的FAQ或郵件列表HTML歸檔中查到。
此外Google本身也有按操作系統分類的主題搜索入口：
http://www.google.com/linux
http://www.google.com/bsd
http://www.google.com/mac
http://www.google.com/microsoft
我的猜測：Google其實是針對有相應內容的WEB站點根據其服務器進行了類聚，要知道關于Office的內容如果跑在Linux服務器的 Apache上那么很有可能是OpenOffice，而關于Office 2000的文檔項目肯定是跑在Windows服務器的IIS上的多。
BUG反饋/改進意見也是一種非常有價值的勞動
首先，如果發現了問題一定要進行主動的反饋：有朋友問我說他以前早就遇到過類似的問題，說明Resin在CPU比較慢的機器上自動啟動這個問題應該是比較普遍了，但為什么一致沒有作為BUG提交上去呢？
其次，如果找到了解決方法，千萬不要為自己的一點小技巧沾沾自喜，像在Java 編程技術中漢字問題的分析及解決這篇文章中提到的那個的高手那樣，雖然他自己知道了通過Hacking Servert包的源文件解決中文字符集問題的方法，如果這真是一個正確的思路為什么不作為一個議程直接提交給JCP呢？
所以我在找到解決Resin自動啟動這個問題以后，在相應的BUG跟蹤報告中提交了自己的方法，如果以后的版本中有了改進，大家安裝使用中可以少考慮一個問題不是更好嗎。（雖然這個方法最后沒有被采納），有時候在反饋過程中你也許會發現讓別人接受你的建議其實更難。尤其在中文支持問題上：但如果中文用戶自己不主動反饋，以后很多的設計中就會繼續忽略中文用戶的一些特殊需求。
事實上無論是BUG提交還是改進意見，對于軟件的進步都是一種非常有價值的。雖然目前國內還沒有很多人直接參與開源軟件的開發，但通過以上這些方式積極的參與也是在為開源軟件加油。
更主動的反饋莫過于像Blogger一樣的主動表達：把你的理解和想法通過互聯網傳播出去，由于在表達和交流過程中同時你也總結提煉了自己的思想，所以“教授他人其實正是一個非常好的學習過程”。
GNU的“工具箱”哲學：問題的分解
雖然常常發現自己碰到的很多問題在國外幾年前就有人遇到過了，而且往往能通過Google找到大量相關資源。而且類似需求非常多的話，往往還會有很多 Open Source的解決方案發布在
SourceForge.netApache.org上。
但也不要指望所有問題都能夠直接在互聯網上找到答案，因為復雜問題本身的解決有可能利用其他一些工具組合解決完成的。比如：我在解決
多臺服務器之間的日志合并統計過程中找到的Apache的日志輪循工具cronolog，在
OutLook Express郵件的HTML歸檔過程中找到的mbx2mbox+mhonarc，以及在
CVS的常用工具整理過程中找到的大量優秀應用等。
GNU很推崇“工具箱”哲學：因為很多復雜的問題都可以通過幾個更簡單的工具通過一定的組合加以解決的。而Perl往往就是粘合這些優秀工具的“膠水語言”。這也是為什么Perl（或者說Perl的哲學）是任何一個程序員都因該學習并掌握的語言。
如果一個問題在Google上也找不到，有時候反思一下是不是自身需求本身的問題，因為只有合理的需求是發展的源動力：如果你發現提出需求目前很多系統中不支持，說明我們對其設計目標理解不夠深入或者對問題的復雜度缺乏正確的估計造成的。比如：MySQL早期版本中沒有外鍵和事務處理的支持，CVS沒有文件的鎖定機制，但事實上經過很長時間的實踐證明：這些功能并非必需，而且沒有這些功能系統也是“夠用”的，而且是高效的。
總結
- 畢竟搜索引擎只是幫助我們把“模糊的”人類語言轉換成立了計算機比較擅長的“精確”匹配，因此往往需要使用一些真正能夠幫助去其他信息區分開的特征關鍵詞（不僅是多）才能夠把自己真正需要的資源比較高效的提煉出來；
- 而返回的結果不可能達到非常完美的程度，所以有時候除了一些技巧外，還是需要我們自己從頭幾十條比較相關的結果中進行一下歸納總結。“搜索= =>總結==>再搜索……”，我想基于搜索引擎的學習基本上就是這么一個不斷提煉過程吧；
- 如果直接找不到問題的答案就想辦法把問題分解，如果還找不到，就反思一下自己的需求是否合理；
- 把自己的經驗通過互聯網加以總結，反饋和推廣，網志Weblog是一個不錯的手段，善于把你的觀點共享給別人；
相關資源：
Google搜索幫助
http://www.google.com/help/
NEC Research Institute CiteSeer
http://citeseer.nj.nec.com
The Apache Software Foundation
http://www.apache.org/
GNU項目
http://www.gnu.org
各種開源項目資源
http://sourceforge.net
http://freshmeat.net