基于Google的学习过程 (笔记 by 车东)

内容摘要：

Google的使用如此重要， O'Reilly有本专门的书介绍了如何优化网站面向Google的设计，和使用Google的一些技巧：
http://www.oreilly.com/catalog/googlehks/ 这里我很想把以前遇到类似问题时在Google上寻找资料的思路和大家分享一下：

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

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

如果用户理解了使用更多的关键词可以更快的定位到所需要的信息这一点的话，那么每次查询时用户使用的关键词个数就反映了用户的搜索引擎使用水平，根据在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.net Apache.org上。

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

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

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

总结

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

笔记 by 车东

为而不有……