基于Google的学习过程

据2000年的统计，美国用户在使用搜索引擎时平均用2.3个关键词，欧洲用户平均使用 1.7个关键词，因此从总体上说美国用户在搜索引擎的使用水平上领先欧洲用户半年左右……从这个统计中我们能够想像中国用户在互联网信息的利用水平上和国际先进水平的差距。

所以我把以前遇到类似问题时的解决思路总结了一下：

足够“多”的特征关键词是快速定位的关键

有朋友问我：在比较慢的机器上Resin不能自动启动问题我是怎么找到在“启动脚本中加入15秒的延迟”这个解决方法的。我当时遇到这个问题后：首先就是把错误日志中的"Can't connect to parent"字样复制下来，然后在google上查：resin2 "Can't connect to parent"，从Google找到的资料大部分在Resin的BUG跟踪报告，FAQ和邮件列表中。虽然这些文档中没有给出一个比较直接的答案，但从中我获得了大量的相关信息，从而方便我对问题的分析。整个查找/解决过程大约用了10个小时左右。

如果用户理解了使用更多的关键词可以更快的定位到所需要的信息这一点的话，那么每次查询时用户使用的关键词个数就反映了用户的搜索引擎使用水平，根据2001年的统计，美国用户在使用搜索引擎时平均用2.3个关键词，欧洲用户平均使用 1.7个关键词，因此，从总体上说美国用户在搜索引擎的使用水平上领先欧洲用户半年左右……从中我们可以想象在互联网资源的使用水平上中国和国际先进水平的差距。

提高搜索结果质量的途径：使用英文专业术语、文件类型过滤、专业站点站内搜索

使用英文专业术语：
最近一次经历是找一个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 2000的站点肯定跑在Windows服务器的IIS上，而Linux文档项目肯定是跑在Linux服务器的Apache上。

BUG反馈/改进意见也是一种非常有价值的劳动

首先，如果发现了问题一定要进行主动的反馈：有朋友问我说他以前早就遇到过类似的问题，说明Resin在CPU比较慢的机器上自动启动这个问题应该是比较普遍了，但为什么一致没有作为BUG提交上去呢？

其次，如果找到了解决方法，千万不要为自己的一点小技巧沾沾自喜，像在Java 编程技术中汉字问题的分析及解决这篇文章中提到的那个的高手那样，虽然他自己知道了通过Hacking Servert包的源文件解决中文字符集问题的方法，如果这真是一个正确的思路为什么不作为一个议程直接提交给JCP呢？

所以我在找到解决Resin自动启动这个问题以后，在相应的BUG跟踪报告中提交了自己的方法，如果以后的版本中有了改进，大家安装使用中可以少考虑一个问题不是更好吗。（虽然这个方法最后没有被采纳），有时候在反馈过程中你也许会发现让别人接受你的建议其实更难。尤其在中文支持问题上：但如果中文用户自己不主动反馈，以后很多的设计中就会继续忽略中文用户的一些特殊需求。

事实上无论是BUG提交还是改进意见，对于软件的进步都是一种非常有价值的。虽然目前国内还没有很多人直接参与开源软件的开发，但通过以上这些方式积极的参与也是在为开源软件加油。

更主动的反馈莫过于像Blogger一样的主动表达：把你的理解和想法通过互联网传播出去，由于在表达和交流过程中同时你也总结提炼了自己的思想，所以“教授他人其实正是一个非常好的学习过程”。

GNU的“工具箱”哲学：问题的分解

虽然常常发现自己碰到的很多问题在国外几年前就有人遇到过了，而且往往能通过Google找到大量相关资源。而且类似需求非常多的话，往往还会有很多Open Source的解决方案发布在SourceForge.net Apache.org上。

但不要指望所有问题都能够直接在互联网上找到答案，因为复杂问题本身的解决有可能利用其他一些工具组合解决完成的。比如：我在解决多台服务器之间的日志合并统计过程中找到的Apache的日志轮循工具cronolog，在OutLook Express邮件的HTML归档过程中找到的mbx2mbox+mhonarc，以及在CVS的常用工具整理过程中找到的大量优秀应用等。

GNU很推崇“工具箱”哲学：因为很多复杂的问题都可以通过几个更简单的工具通过一定的组合加以解决的。而Perl往往就是粘合这些优秀工具的“胶水语言”。这也是为什么Perl（或者说Perl的哲学）是任何一个程序员都因该学习并掌握的语言。

如果一个问题在Google上也找不到，有时候就需要反思一下自身需求本身的问题了，合理的需求是发展的源动力：如果你发现提出需求目前很多系统中不支持，说明我们对其设计目标理解不够深入或者对问题的复杂度缺乏正确的估计造成的。比如：MySQL早期版本中没有外键和事务处理的支持，CVS没有文件的锁定机制，但事实上经过很长时间的实践证明：这些功能并非必需，而且没有这些功能系统也是“够用”的，而且是高效的。

总结：

1. 毕竟搜索引擎只是帮助我们把“模糊的”人类语言转换成立了计算机比较擅长的“精确”匹配，因此往往需要使用一些特征关键词（不仅是多）把自己需要的资源与其他数十亿网页中区别出来；
2. 而返回的结果不可能达到非常完美的程度，所以有时候除了一些技巧外，还是需要我们自己从头几十条比较相关的结果中进行一下归纳总结。“搜索==>总结==>再搜索……”，我想基于搜索引擎的学习基本上就是这么一个不断提炼过程吧；
3. 如果直接找不到问题的答案就想办法把问题分解，如果还找不到，就反思一下自己的需求是否合理；
   
4. 把自己的经验通过互联网加以总结，反馈和推广，你的观点也可能在Google的结果中很靠前；
   

顺便说说我对开源软件的印象：开源社区很像一个基于互联网的原始丛林，那些经过近乎“物竞天择”式的发展并能够长期留存下来的工具/开发库往往都是非常“强壮”的，GNU这些工具包的高效稳定给我留下了深刻印象，而且由于很多开源软件都来自资深工程师的实践，实际上可重用度也很高。如果用“自私的基因”原理来解释的话，开源软件开发者最大的野心就是让同类的商业软件几乎没有生存的可能。毕竟连我们最经常用来查找资源最常用的的搜速引擎Google本身也是基于大量开源软件(GNU/Linux GCC Python...)开发出来的。