無標題文檔

OpenSearch 初探

很多现代的浏览器在地址栏的右边有个搜索框,默认的安装有 Google 搜索等。如下图所示

https://friable.rocks/_/2008_06_17/1213670001.png

其实这是 OpenSearch 的一个应用,只要编写相应的微格式的 xml 文件,就可以制定相应的搜索框。

参考 OpenSearch 的定义文档 ,可以基本获得基本的 xml 格式。比如某个典型的的搜索 xml 文件可以这样指定。

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
    <InputEncoding>utf-8</InputEncoding>
    <ShortName>ShortName</ShortName>
    <Description>Description</Description>
    <Image type="image/vnd.microsoft.icon">favicon</Image>
    <Url type="text/html" template="http://who.am.i/search?word={searchTerms}"/>  
</OpenSearchDescription>

上面的 xml 文件很容易理解,除了固定的 xml 根以外,其他的定义从字面上就可以理解:

  • InputEncoding 指定搜索的编码,根据网站的实际情况而定
  • ShortName 这个是搜索的短名称,比如「Google 搜索」
  • Description 针对这个搜索框的描述,比如「淘宝购物搜索 - 只有你想不到,没有你淘不到」
  • Image 类似网页的 favicon ,用于标识搜索
  • Url 这个是最重要的参数,指定搜索的链接。它有很多参数,一般使用 {searchTerms} 参数指定搜索词即可。参数 type=\"text/html\" 注明返回的是页面(浏览器会跳转到这个页面),如果是其他格式就会使用相应默认程序打开(比如 type=\"application/rss+xml\" 就会使用 RSS 阅读器打开)。

编写 OpenSearch 的 xml 格式就完成了,详细信息可以参阅其 OpenSearch 定义文档

下面要在页面中加入这个搜索,基本上可以分为两种方式。分别是页面的在 head 中加入 link 标记(类似 RSS),以及使用 Javascript 方式添加(比如定义某个按钮触发)。

加入 link 标记非常简单,格式如下

<link rel="search" type="application/opensearchdescription+xml" 
            href="http://who.am.i/search.xml" title="ShortName" />

与 RSS 相似,rel 和 type 是固定的,我们主要指定 href (上述 xml 的 url 路径,保险起见使用绝对路径,即 http:// 开头)以及 title (也就是搜索的短标题)即可。

就这样,在 Explorer 以及 Firefox 中打开这个页面就可以看见相应的菜单了,如图所示

https://friable.rocks/_/2008_06_17/1213670018.png

使用 Javascript 添加比较麻烦(或许现在的情况会很好多)。我们主要会使用浏览器的扩展功能,在 Explorer 有个 window.external.AddSearchProvider 参数( 详细文档 )。

典型的调用方法如下

window.external.AddSearchProvider('http://who.am.i/search.xml');

参数中的链接就是上述 link 中的内容。在 Firefox 下可以使用

window.sidebar.addSearchEngine(
    "http://who.am.i/search.xml",  /* engine URL */
    "favicon.ico",  /* icon URL */
    "ShortName", /* engine name */
    "Description" );            /* category name */

参数和例子如示例代码中所述( 官方文档 )。值得注意的是在 Firefox2 版本以后已经「兼容」 Explorer 的 window.external.AddSearchProvider 调用方法( 详细信息 )。

那么我们对应的 Javascript 代码就可以这样编写(为了兼容 Firefox2 之前的版本,加入 else if 判断)

function addEngine()
{
    if (window.external || window.external.AddSearchProvider) {
        window.external.AddSearchProvider('http://who.am.i/search.xml');
    } else if (window.sidebar && window.sidebar.addSearchEngine) {
                window.sidebar.addSearchEngine(
                    "http://who.am.i/search.xml",
                    "favicon.ico",  /* icon URL */
                    "ShortName", /* engine name */
                    "Description" ); /* category name */
    }
}

这样,就可以将这个函数注册到某个链接或者按钮的点击事件中,就会跳出个确认框,如图

https://friable.rocks/_/2008_06_17/1213670034.png

用户点击确认以后,就加入到浏览器搜索框中了。

--EOF--

Firefox3 即将发布支付宝 的兄弟们正在完善对于 Firefox 的支持,在这里表示关注和支持。

Twitter 的前端浅析

前段时间(似乎目前也有)Twitter 的网站不是非常的稳定,虽然是 服务器方面的问题 ,而本人职业倾向,于是就看了下 Twitter 的前端代码,下面我说下我的个人观点。

按照期前所说的 评定标准 ,我们来对比下 Twitter 做得如何。

减少 HTTP 请求数,以及使用 CDN、加 Expires 头等

https://friable.rocks/_/2009_11_05/058855b87c6a.jpg

这是本人的 Twitter 主页的请求数统计( 大图 ),看得出在页面不大(150K)的情况下,请求数竟然达到了 60 个居多。

其中,大部分的请求数是图片等,主要的内容是用户的头像。其中,大部分的图像资源来自 s3.amazonaws.com 这个站点,而同时多达 60 多的并发请求数,还是让人对效率方面堪忧。

https://friable.rocks/_/2009_11_05/648315b87e99.jpg

上图是 Twitter 返回的 HTTP 头信息,看得出虽然设置了 Expires 头等信息,但是似乎缓存并没有发挥实际的功效(谁能告诉我原因?)。

Javascript 和 CSS 方面

Twitter 的 CSS 文件仅为一个,并且在页面的头部就已经载入。在这里我无法理解的就是为什么它们没有把样式给压缩,甚至连注释都存在。

https://friable.rocks/_/2009_11_05/345865b87c66.jpg

特别是针对 Twitter 这样突发流量非常大的站点,相信压缩过以后效率会更理想些。

https://friable.rocks/_/2009_11_05/024525b87c64.jpg

Javascript 方面的问题除了说了上述的 CSS 一样未被压缩过以外,它们还分别载入了两套不同的 Javascript 框架,分别是 Prototype 和 jQuery

相信 Javascript 运行开销会比较大的还有 urchin.js 这个文件,它是 Google 的统计埋点(Twitter 没有自己的统计系统?)。

Twitter 的页面虽然简单,但是如此安排前端脚本,在庞大的流量基数面前,个人认为不应该抱乐观的态度。

其他

Twitter 的 HTML 结构发现,有很多的结构都是被简化了的(可能这是处于针对移动设备的考虑)。

https://friable.rocks/_/2009_11_05/939665b87c68.jpg

有趣的一点就是他们会将很多事情交给 Javascript 去做,比如是否出现「On a mobile phone」的提示。

个人认为针对「无障碍」的 HTML 结构而言,固然是可以这样做(给用户更多的提示信息)。

但对于桌面用户而言,毕竟这是属于多余的结构,所以此类的提示信息应该放在服务器上面判断。当然,反驳本热观点的最好理由就是:其一,坚持「无障碍」的 HTML(结构);其二,减少服务器的运行开支。

--Split--

本人的水平有限,此文希望能起到抛砖引玉的效果。PS:大家想听我发牢骚,可以 去我的页面看看

怎样才算 PHP 入门?

译言上有篇 「40 个迹象表明你还是 PHP 菜鸟」 ,里面的内容非常不错,但部分观点不完全苟同。

PHP 入门的确很简单,但这并不说明它不复杂。在从事 前端开发 之前,本人也作为 PHP 程序员混了一段时间,在这里根据此文的部分观点说下我的个人看法。

不使用 MVC

MVC 这玩意 几乎成了后台开发的「Web 标准」。很多程序员在没有真正弄清楚项目需求和规模前,就大喊「我们要些遵循 MVC 的代码」。

MVC 固然有众多的好处,但是退一步讲,其出发点也是为了提高效率的。在并不复杂的项目中刻意使用 MVC ,这好比将一个脚本分成三份,我想谁都不会这样做的。

不使用 autoload

PHP5 中加入的 autoload 特性 意在容许给编码人员二次出错的机会。有时候这个特性非常的棒(本人也经常在使用,这样可以省去不少的 inlcude/require 代码)。

这里要说明和提醒的就是,不要滥用这个特性 -- 比如你明知道这个类在某个文件中,何必劳神让 autoload 再去寻找?特别在些注重高效率的场合,必须面对这一点。

对集成开发环境(IDE)视而不见

好的 IDE 是能提交效率,但坦白的说,本人没有使用 IDE 的习惯。

在大学期间学习 Linux 系统开发(c 语言)的那会,已经习惯用 Vim 编辑代码 、使用 make 和 autoconf 组织代码、使用 gcc 编译,如果碰到需要调式,还可以让 Vim 和 gdb 配合。

本人的观点就是「好的软件只做一件事情」,我敢保证 IDE 中的编辑器没有 Vim 好,断点调试也没有类似 gdb、xdebug 要来的方便(至少熟悉)。

所以,本人觉得作为工具的工具,没有孰优孰劣的说法。

-- Split --

总之,文中的很多观点本人甚为同意,除了技术上的些细节,看得出很多都包含了「思想」这一范畴。比如良好的代码风格和开发方式、使用 OOP (不过和 MVC 一样,经常会被玩概念)、还有很多脚本基本安全方面的的意识(比如输入过滤)等等。

在我看来,好的 PHP 程序员不仅仅需要过硬的技术,重要的还是思想--团队意识、责任感、兴趣、激情、还有敬业等等(再这样说下去直接去学 六脉神剑 去算了)。

说到这里就不仅仅是 PHP 程序员的范畴了,希望广大的技术人员都能共勉。

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章