今天偶然使用Google搜索，发现了这个新功能。注意图片中画圈部分，是动态呈现的Twitter的内容，而且还会自动滚动更新。

Google终于向着实时搜索引擎的目标，迈出了脚步。我感觉搜索引擎可能又要掀起一场互联网的革命了。尝试了数个关键词，能够激活该功能的关键词很少，像“世博会”，“上海世博”等关键词，都未能激活此功能。目前尚不知道该功能出现的条件。

从过去12个月的搜索量来看，PHP在中国，俨然是老大的老大。然后是python，flex，perl，最后是ruby。这与ruby如日中天的名声不大相符。当然，搜索量不能说明什么问题，也可能，PHP的文档组织得最差，所以，解决这方面的问题，总要依靠搜索，还有一个可能，用PHP的人都喜欢用google，其他程序员则可能也用百度（说不定可以排除这个可能，有不喜欢用google的程序员么？）。不过，这么大的差距来看，在中国PHP的群众基础非常好。还有，京沪穗不单是经济大省，而且还是IT大省。

有一点有趣的事情，两个尖峰低谷，一个是十一黄金周，一个是春节。说明一个问题，中国的广大脚本程序员，在过年和长假的时候，基本可以抛开手头的程序，享受一下天伦之乐……

再来看看地球另一端，总是在IT行业引领潮流的美国呢？在美国，PHP也还是第一，然后就是如日中天的ruby，看来，ruby是在美国更火一些，然后是我意料之中的flex，接下去才是python和perl。

这里我还有一张总趋势图，没有贴，PHP日渐滑坡，老大地位岌岌可危，ruby稳坐上升态势的二把交椅，Flex从不为人知，一路脚踏实地爬上来，目前正与一向稳定平衡的python纠缠。当然，抛开python，也是指日可待。最后，前几年的二把交椅perl，怎么也止不住下跌的势头，一步步踏向人们回忆的最深处。

结论，python是一门有着稳定需求，但是需求又不是那么大的脚本语言，python与fashion这个词不沾边。PHP，Flex，Ruby都是这场时尚大赛的角逐选手，鹿死谁手还未知晓。但是年轻的Flex和Ruby靠着自己新颖的理念，让人眼花缭乱的技术，赢得了越来越多的fans。Perl垂垂老矣。

纯粹胡扯一下下，别跟我当真啊。

好了，好了，不玩了……

在CB看到的

百度是个无底洞，google稍微好点

这是搜索引擎的主要用途之一……

拿这个做文章，百度可以去下18层地狱了。

为何使用Google自定义搜索？

减少数据库查询？使用Google搜索的话，当然可以减少对自己博客服务器的查询次数，但是作为一个普通博客，每天能有多少人去你的博客搜索呢？5,000人够多么？50,000人又如何，这确实是服务器的负载，不过这对于服务器来说，不是什么很重的负载，毕竟一台主机上绝大多数人，达不到5万这个量级的。不过，能省则省，何乐不为？

速度更快？对于一台高性能，低负载的博客主机来说，Google的优势并不明显，毕竟1s和0.8秒的差距不是什么人可感知的差距。但是，对于某些架在国外主机上的博客来说，对于某一部分访问不畅的用户，Google搜索的速度绝对要快于博客主机本身搜多的速度，毕竟Google服务器遍布全世界，总能有一台相对快的对用户请求做出响应。

结果更精确？哈哈，这个说法其实是有相当问题的。因为，Google对你的博客的搜索结果，直接取决于对你博客的收录数量，如果某篇文章根本没有收录，就不可能搜出来，那么谈何精确呢？Google连你博客的一个完备的数据集合都不具备。另外，从时效性上来看，Google的搜索也要落后，你认为Google对你博客的抓取频率是多少呢？无论有多快和WordPress博客本身还是有区别的。

能整合广告？能赚钱？呵呵……对此，我只能苦笑了。

好吧，貌似我已经把必须使用Google搜索的理由都推翻了，至少，从我自己的视角来看，使用Google搜索的必要性是不存在的。得出这么一个结论，是不是让诸位看官有点吃惊了？不过呢，我个人还是选择了整合Google搜索到我的博客。接下来，我来谈谈我是怎么想的。（以下内容，不喜欢的可以跳过）

首先，请大家去看看WordPress里面关于搜索的那段代码是怎么写的。那段代码在wp-includes/query.php中。wp2.5.x的是966行附近。wp2.6.x是979行附近。wp2.7.x是1740行附近。当然，内容是相当雷同的。简单说下，首先处理查询字符串，怎么处理的，我也看不大明白，结果我是知道的，查询内容被分解成了一个个关键词。然后，生成SQL语句中的条件字符串，类似于post_title LIKE %term_i% OR post_content LIKE %term_i%，对于每一个关键词i来说，都要生成这么一个串，于是乎，如果用户在搜索框中写了一长句话的话，那么结局可想而知了，博客主机的MySQL服务器将运行一个十分冗长的SQL语句。其效率也可想而知了。

其次，不知道有没有高手了解数据库的原理，即，这个LIKE操作，到底是怎样搜索的呢？就我所了解到的非常有限的知识来看，这个LIKE是使用了近似于正则表达式的方法，逐条检索数据库中的每条记录的。好，问题来了，现在数据库里只有一点点数据，1,000篇文章够不够多？有这个量的人很少吧，哈哈。10,000又如何？博客很难达到那个量的。所以，WordPress的搜索功能，看起来总是那么迅速。但是，WordPress博客自带的数据库搜索的发展趋势是明确的，文章越多越长，速度越慢。数据库里的内容本来是没有顺序的，索引给数据库带来了高速检索的机制（排好序的数据），但是，大家从代码里可以看到，这么样子写查询，跟索引是八棒子打不着的。

那么，搜索引擎的工作原理是如何的呢？第一步，蜘蛛爬取网页，博客的每个页面，由Google蜘蛛统一抓取到Google的服务器上；第二步，对所有得到的网页的内容建立索引，这里所说的索引，是搜索引擎内部使用的索引，非是数据库那种索引。基本上来说，一篇文章到搜索引擎里面，所有的词语会被切割开来，这个过程叫做分词，然后对每个词语建立一个索引，非常庞大的工程吧，简直令人叹为观止的庞大，因为全世界的网页约有600亿之多。而且，一般来说，搜索引擎会建立倒排索引（reverse index），简单说，就像英文技术书后面的Index一样，某个词，出现在第几页，第几页。；第三步，就是等待查询请求了，如果请求来了，搜索引擎就会去它自己建立好的索引中去查找，然后返回结果集合给用户；第四步，对检索结果进行排序，一般来说，搜索引擎的排序是按照跟关键词相关的程度来排序的，一篇出现WordPress十次以上的文章，肯定是比只出现了一次的要更与WordPress这个词有关了（对于数据库来说，根本没有这个步骤，你查询密码破解，很有可能查到一篇《黑客帝国》的影评）；第五步，这个步骤只对自定义搜索引擎才有，就是对结果集合进行过滤，将不属于你的域名下的结果全部清除。

搜索引擎是多么一个让人叹为观止的系统啊，一次看似简单的查询，有早先蜘蛛的辛勤工作，然后加上建立索引，最后是成千上万台机器去检索那些索引，一次搜索是无数计算机告诉计算的结果，单单冲着这个，我就要选用真正的搜索引擎了，因为，这真的很伟大。

最后，是搜索引擎对于查询字符串的分析能力，不知道大家知不知道，可以在Google搜索框中敲入及其复杂的查询语句，无论是整个句子，还是布尔表达式，或者许多奇怪的Google语法，这种竭尽全力去理解用户意图的贴心做法，绝对不是WordPress内部那两个正则表达式可以比拟的东西。

综上所述，使用Google搜索，可以获得更相关的搜索结果，可以更好的理解用户的查询，可以调动更多的计算机工作，满足你更大的支配欲（O(∩_∩)O）。所以，我还是选用了Google搜索。当然，对于我个人，还有个原因，我是Google Fans，你看我的主题，使用Google搜索才是理所当然的事情嘛。

如何在WordPress中整合Google自定义搜索引擎？

看看参考【3】，你可以从宏观上把握住这个整合的总体流程。而参考【4】，可以给你一个整合操作的详细指导。

参考文章：

【1】Google自定义搜索引擎重大更新：可自动搜索相连网站

【2】Google推出多语言自定义搜索引擎

【3】我爱水煮鱼：《整合Google自定义搜索到WordPress中》 ：这是一篇简单介绍如何整合Google搜索到WP博客的文章，不过，这篇文章只有简单的1，2，3，... 基本没有什么可操作性。不过讲解的步骤是对的。

【4】網生@誌 | zEUS.'Blog：《给博客添加 Google 自定义搜索》 ：这篇文章介绍了整合Google搜索的详细步骤，包括申请，修改代码，等等，并且给出了代码范例。可操作性很强。

WordPress自带的这些js类库有个弊端，就是基本上都没有经过minify和zip（这两部操作的作用，就是将js代码的体积，尽可能减到最小，以加快下载速度），所以引用WordPress自己的js类库，往往会浪费很多流量（比如，没有zip过的jquery有30KB，prototype有122KB，而压缩过后，jquery只有17KB，prototype只有28KB）。

我是否使用了类库？

WordPress是一个灵活的系统，用户可以通过插件扩展系统的功能，所以，一个博客上是否使用了某个类库，取决于你博客用到的所有的插件对类库的使用情况。如果你想看看自己到底使用了哪些，你可以用一个简便的办法，就是查看源文件。

看上面的代码，是我模板中的一段代码，类似这个样子的就是对类库的引用了。这是我的本地调试系统，使用的是wp2.5.1，引用到了jQuery类库，版本1.2.3。

如果你看到了类似“xxxxxxxxxxxxxwp-includesjsxxxxxxxx?ver=xxxxxx”的字符串，那么，你的博客里，调用了类库。

使用Google AJAX Libraries API

什么是Google AJAX Libraries API（GALA）？使用它有什么好处？简单来说，Google是个很牛X的公司，很乐意做好事，它专门优化了这些类库，包括代码精简，压缩，然后用高性能地服务器来Host这些类库，供用到的网站调用，帮助这些网站节省流量。我爱水煮鱼写了个小短文，介绍过这个，大家可以看看（点这里）。Google为什么做这种事情？好吧，这个问题，我不知道。

怎样用GALA来替换WordPress自带的类库？

关于这一点，首先我想说说WordPress对于引用脚本的一些机制，那就是scripts loader。这是个什么东西呢？一句话：对于博客使用到的所有脚本，进行统一的管理的一个装置。这个装置是怎么管理的呢？首先，所有的脚本登记注册，包括名称，路径，版本号，依赖关系，一一详细记录。然后，是对脚本的调用，通过这套系统来调用。最后，由系统负责把所有需要用到的脚本，无重复的，满足依赖关系的，满足前后顺序的，有条不紊的加入到你的最终的博客页面里面。怎么样？是不是非常酷？不过呢，总是有“不过”，这种秩序高度依赖模板作者和插件作者的自觉性。

好吧，我们的方法不得不建立在所有的模板作者和插件作者都自觉使用scripts loader系统的基础上。在这种情况下，一个模板或者插件使用到某个类库，会使用wp_enqueue_script函数来调用需要的类库，使用这个方法，一般不会直接指明类库的路径，只是说明类库的版本号和依赖关系（因为，WP默认就会给所有wp-includes/js目录下的类库进行登记register）。

发现又废了很多话，到这里，我们的替换方法，已经呼之欲出了，因为所有的类库引用都是对已登记的类库的调用（建立在我的假设之上），所以，我如果想要替换，那么只要替换登记在册的那个名单就OK了，完全跳过了去修改每个有可能引用到类库的插件这种繁琐的事情。而且，WordPress确实提供了能够替换那个名单的方法。使用wp_deregister_script可以注销一个脚本，然后使用wp_register_script可以重新注册一个脚本。用这个办法，我们可以把wp自己注册的脚本给注销掉，然后换成GALA的，重新注册，就OK了。

根据WordPress的源代码显示，所有类库的引用，是在最后页面生成的时候才真正进行的，准确一点并且专业一点来说，是在wp_head这个action发生的时候，对类库的引用才通过wp_print_scripts函数写入到页面里面。我们的替换动作只要在此之前完成就OK，所以，我们把替换这件事情，写到functions.php里面，当然，更好的做法，是使用一个单独的插件里。

具体的写法，我曾经在侠姐的文章里见过，大家可以去看看，我就不想进行重复劳动了。《wordpress里js文件的调用》from 轶侠的网上小窝

有没有学习写插件的小朋友写个干这个事情的插件呢？亲爱的读者，如果你写了，请告诉我，我会把你的作品列在下面的。

Updated:

经由侠姐提出，如果直接替换掉WP自带的js类库可能会在后台造成冲突而导致某些功能失灵（比如Simple Tags的标签推荐功能，详情可见讨论），不得不在使用的做出一定的修正。

通过is_admin()标签，可以将前后台区别对待。但是这种情况还不能涵盖所有的例外，如果某个插件正好引用了prototype或者jquery，并且正好利用了WP对齐进行的无冲突修正，那么以上方法可能导致部分功能失灵。有经验的用户可以酌情使用。

Updated2：

经小墨提醒，已经找到了一个这样的插件的实例了。我看了代码，是利用了两个hook，一个是我说过的wp_print_script，这个hook用来探测jQuery和prototype是否同时存在，然后解决冲突问题，另一个是script_loader_src，用来替换里面的src地址，并指向到google提供的js库。不过，我个人觉得，这个方法很可能还是不能完美解决后台的类库冲突问题，但是我没有验证过。

插件主页：

http://blog.clearskys.net/2008/05/28/google-ajax-libraries-api-plugin/

昨天，寝室里一个同学就在大放厥词，说谷歌中国一点创意都没有，招了一堆程序员回去，什么东西都没做出来，整天干的事情就是搞汉化，我对此评论相当不忿，没有说话……结果，今天，我刚刚看到这个东西……太有空了吧，谷歌同学，这些东西有必要汉化吗？

好吧，同学们，以后，你们可以看中文版的Google API文档了。^_^

本来想彻底卸载掉google toolbar的，于是要寻找我常用功能的替代工具，其中一个要找替身的就是google bookmarks。

当然，我第一个想到的就是用美味来代替，其实我早就是美味的用户了，只是一直没有好好利用而已，后来就是因为google toolbar上有bookmarks，就彻底不用美味了。

装上美味，第一件事情，就是想要把google bookmarks彻底导入过来，怎么办呢？一点点试，果然还是有点办法的，首先要做的事情是把google bookmarks导出，导出的文件为html文件，然后，在美味那边狂找，没有做找到导入选项，可能是我实在太菜吧，不过我知道ff可以导入html的，于是导，成功将google bookmarks都导入到了ff里面了。这时候，我惊喜的发现，可以通过美味的ff插件把ff的书签导入到美味里面。大功告成。

不过，接下来的事情，就让我大跌眼镜了。就是tag的使用方式的问题。我本来在google这边使用tag的时候，喜欢把每个关键字都加上，慢慢我发现，那个下拉菜单奇长无比，不但选择起来很累，而且并不准确。后来，我对tags进行过一些重新标注，使用了带有空格的tags，比如“WordPress docs”，“WordPress plugins”，“WordPress themes”等等，这次进入了美味，发现有40多个网页标上了wordpress标签，美味在导入的时候，不但把原来的tag切断，而且还把空格后面的tags直接忽略了。

现在，我发现，我又退回到了在书签中选择一次tag不能找到自己想要的网页的时期了。郁闷……看来，我对书签的整理问题，更习惯使用目录式的结构，而不擅长使用tag，因为我实在不知道到底应该怎么去使用这些tag，虽然，有人告诉我，有了tag，可以使用搜索，很方便，其实，我个人觉得，这个是极其的不方便，首先我点一下鼠标，打开一个面板，再点一次鼠标，输入框得到焦点，打字，回车，重新换回鼠标拖动滚动条，天哪！！简直是灾难……

话说，我觉得浏览器的书签管理貌似还是目录式更加科学高效一点。因为，我个人不是胡乱收藏网页的，而且，收藏页面都是我的主动行为，很少会因为数量太多了自己记不清楚，搜索这个功能完全是鸡肋。而我对搜索最好的体验是GMail里面的搜索，因为收取邮件是被动的，别人发给我，我都会收到，这个时候有用的信息会被大量的邮件淹没，这个时候，搜索给我带来极大的效率提高。

结局，我只好换回了google bookmarks，由于还是抱着彻底不安装google toolbar的幻想，我装了著名的gmarks，但是这个东西的操作方式仍旧让我觉得和toolbar上的那个小星星的效率上有所差距，不知道我最后会因为忍受不了而退回去，还是终于找到了高效操作的方式。

好了，看文章的你，你是怎么在浏览器里管理书签的？你觉得怎么样的方式更方便快捷？你有什么独门绝技？能否跟我交流一下呢？

悄然无声息中，Gmail完成了它的升级动作，但是我想说，It Sucks!

我只看到了外观上的变化，显示邮件的label的时候，后面多了个浅绿色的背景色框。打开带有标签的邮件，会在顶部显示一个标签的快捷按钮，可以跳回label页面，还有一个可以删除label的快捷按钮。除了这个，我还注意到，页面被强制添加了聊天框，如果你选择关闭，那么你不能真正关闭这个聊天框，你只能将它收缩！（在老版本里面，是可以完全拿掉的）

我还感受到了内部的变化：1，速度极慢，比起原来的Gmail，新版本速度下降不少；2，极度地IE不友好，在IE下会时常使浏览器处于无响应状态，而且那个见鬼的聊天框，永远没法使你处于在线状态，我甚至怀疑那是IE无响应的根源所在；3，暂时还没有3

对于我这个极端喜欢使用IE上网的败类来说，新的Gmail真的是一点都不友好啊~~我毫不犹豫的在右上角按下了"旧版"按钮，（这里又暴露了一个弊端，就是每次都得按，好像不会记住用户的偏好呢！）唉，真是让人奇怪的版本升级，奇怪Google怎么会做这么不理智的事情（IE7极端不友好，FFX2相对友好很多，不会无响应，还会提醒用户关闭firebug），难道他们想靠一个Gmail打败微软，这个就太可笑了一点，如果不是的话，请关照一下世界上所有用户中占80%以上的IE用户吧。

（观众朋友们请不要幸灾乐祸，在Windows下，FFX绝对算不上是优秀的浏览器，单启动速度一条，就已经让我讨厌万分了，还有很多可恶的地方，就是无法静默升级，每次都要问，升级过程不能无缝，总是要重启，无论是升级插件还是升级自身，都要重启，简直混蛋逻辑，还有就是升级太频繁，你不能一次性地做个好点的release吗，非得隔三差五地升级，以至于频繁到我产生一种每次用它浏览网页，都要经受一次因为升级造成的重启的错觉。我承认FFX有很多优点，但是它的这些众多缺点，也是客观存在的。有人说插件怎么怎么，定制怎么怎么，其实大部分插件作用及其有限，我现在除了用firebug，其他基本用不上。因为不是太有必要。我曾经为FFX狂热过的，但是狂热过后，我必须批评它，如果想要从IE手中抢到更多的用户，请继续提升你的性能，不要依靠google，不要依靠linux，他们的优秀，不是你的优秀，FFX！其实这些都是题外话了，FFX还是优点是不容抹杀的，我就不开专门的帖子骂它了。）