七月佑安

搬家

2009-06-15T01:19:00.001+08:00

限于blogspot的各种限制，决定将博客平台更改为WordPress，相应的这个博客也将停止更新，以前的内容将陆续迁移到新的地址（http://oragg.com）。

Mozilla专有JavaScript扩展之一（noSuchMethod）

2009-02-18T22:38:00.006+08:00

JavaScript中有很多内部属性和方法，在大多数情况下，只有JavaScript引擎才可以访问，但不论什么都是有特例的，在这里就是指Mozilla的JavaScript引擎，包括SpiderMonkey和Rhino，都提供了若干接口来访问这些内部属性，如果加以合理利用的话，不仅可以让JavaScript更加健壮，还可以开发出一些有意思的功能，比如本文介绍的__noSuchMethod__()方法就是其中之一。

著作权声明

本文译自Nicholas C. Zakas于2009年2月17日在个人网站上发表的《Mozilla JavaScript extension: __noSuchMethod__》。原文是唯一的正式版，本文是经过原作者（Nicholas C. Zakas）授权的简体中文翻译版（Simplified Chinese Translation）。译者（明达）在翻译的准确性上做了大量的努力，并承诺译文的内容完全忠于原文，但可能还是包含疏漏和不妥之处，欢迎大家指正。译注的内容是非正式的，仅代表译者个人观点。

以下是对原文的翻译：

和其它浏览器相比，Mozilla的JavaScript引擎总会有一些与众不同的亮点。SpiderMonkey和他的好搭档Rhino（用 Java实现的JavaScript引擎）都提供了很多扩展特性，可以帮助我们开发更加健壮的JavaScript应用。其中之一就是本地对象的__noSuchMethod__()方法。在大多数JavaScript引擎中，访问一个不存在的方法时都只会简单的抛出错误，而在Mozilla的引擎中，这只是默认行为，我们可以通过覆盖某个对象的__noSuchMethod__()方来来重新定义这个行为。当这个对象试图调用一个不存在的方法时，就会触发该对象的__noSuchMethod__()方法。

当__noSuchMethod__()方法被调用时，JavaScript引擎会传入两个参数，一个是调用方法的名称，一个是参数数组，对应于要传递给调用方法的所有参数，注意这个参数数组应该是一个Array对象，而不是arguments对象，而且就算没有参数，也要传递一个空数组，下面举一个简单的例子加以说明：

// 注意，下面的代码只有在使用SpiderMonkey或者Rhino的浏览器中才会被正确解析
var person = {
    name: "Nicholas",
    __noSuchMethod__: function(name, args) {
        alert("Method called '" + name + "' executed with arguments [" + args + "]");
    }
} 

//"Method called 'sayName' executed with arguments []"
person.sayName(); 

//"Method called 'phone' executed with arguments [Mike]"
person.phone("Mike");

这段代码定义了一个person对象，并重写了该对象的__noSuchMethod__()方法。当调用person对象的sayName()方法和phone()方法时，由于这两个方法都不存在，所以__noSuchMethod__()方法会被自动调用，这样我们就避免了一个错误的显示，并且可以做出相应的处理。在上面这个例子中，我们所做的处理就是直接将方法的名称和传递的参数直接显示出来。

但话说回来，在运行时才发现未定义方法的情况，是不该出现在正常的开发实践中的，那简直就是自取烦恼。对于通常的情况来说，这个方法似乎没有什么作用，但他确实为我们提供了一个可能性，来创建一些有趣的动态工具，比如说建立一个可以输出有效XHTML文档的对象：

function HTMLWriter() {
    this._work = [];
}
HTMLWriter.prototype = {
    escape: function(text) {
        return text.replace(/[><"&]/g,
        function(c) {
            switch (c) {
            case ">":
                return ">";
            case "<":
                return "<";
            case "\"":
                return """;
                case " & ": return " & ";
            }
        });
    },

    startTag: function(tagName, attributes){
        this._work.push(" < " + tagName);

        if (attributes){
            var name, value;
            for (name in attributes){
                if (attributes.hasOwnProperty(name)){
                    value = this.escape(attributes[name]);
                    this._work.push("" + name + " = \"" + value + "\"");
            }
        }
    }
    this._work.push(">");
},
text: function(text) {
    this._work.push(this.escape(text));
},
endTag: function(tagName) {
    this._work.push("");
},
toString: function() {
    return this._work.join("");
}
};
var writer = new HTMLWriter();
writer.startTag("html");
writer.startTag("head");
writer.startTag("title");
writer.text("Example & Test");
writer.endTag("title");
writer.endTag("head");
writer.startTag("body", {
    style: "background-color: red"
});
writer.text("Hello world!");
writer.endTag("body");
writer.endTag("html");
alert(writer);

这段代码通过三个方法来完成任务，分别是：startTag()、endTag()和text()。而上面给出的调用例子，却显得非常冗长。想象一下，如果不使用startTag()、endTag()和text()这三个方法，而是为每一个有效的XHTML标记都建立一个方法，那么这个例子的调用方法可能就会变成下面这个样子了：

var writer = new HTMLWriter();
var result = writer.html().head().title().text("Example & Test").xtitle().xhead()
    .body().text("Hell world!").xbody().xhtml().toString();

由于每个标签的实现大致相同，所以我们可能需要为HTMLWriter对象复制一系列非常相似的方法，这无疑是一种严重的浪费行为。而这正是__noSuchMethod__()发挥真正作用的时候。让我们来看看用__noSuchMethod__()来实现这种效果到底有多么简单：

function HTMLWriter(){
    this._work = [];
}

HTMLWriter.prototype = {

    escape: function (text){
        return text.replace(/[><"&]/g, function(c){
            switch(c){
                case ">": return ">";
                case "<": return "<";
                case "\"": return """;
                case "&": return "&";
            }
        });
    },

    text: function(text){
        this._work.push(this.escape(text));
        return this;
    },

    toString: function(){
        return this._work.join("");
    },

    __noSuchMethod__: function(name, args){
        var tags = [
            "a", "abbr", "acronym", "address", "applet", "area",
            "b", "base", "basefont", "bdo", "big", "blockquote",
            "body", "br", "button",
            "caption", "center", "cite", "code", "col", "colgroup",
            "dd", "del", "dir", "div", "dfn", "dl", "dt",
            "em",
            "fieldset", "font", "form", "frame", "frameset",
            "h1", "h2", "h3", "h4", "h5", "h6", "head", "hr", "html",
            "i", "iframe", "img", "input", "ins", "isindex",
            "kbd",
            "label", "legend", "li", "link",
            "map", "menu", "meta",
            "noframes", "noscript",
            "object", "ol", "optgroup", "option",
            "p", "param", "pre",
            "q",
            "s", "samp", "script", "select", "small", "span", "strike",
            "strong", "style", "sub", "sup",
            "table", "tbody", "td", "textarea", "tfoot", "th", "thead",
            "title", "tr", "tt",
            "u", "ul",
            "var"
        ];

        var closeTag = (name.charAt(0) == "x"),
            tagName = closeTag ? name.substring(1) : name;

        if (tags.indexOf(tagName) > -1){
            if (!closeTag){
                this._work.push("<" + tagName);

                if (args.length){
                    var attributes = args[0],
                        name, value;
                    for (name in attributes){
                        if (attributes.hasOwnProperty(name)){
                            value = this.escape(attributes[name]);
                            this._work.push(" " + name + "=\"" +
                                 value + "\"");
                        }
                    }
                }

                this._work.push(">");
            } else {
                this._work.push("");
            }
            return this;
        } else {
            throw new Error("Method '" + name + "' is undefined.");
        }

    }

};

这段代码的主要功能都是在__noSuchMethod__()中实现的。它包含一个数组，对应于全部有效的XHTML标签，用于查找可以调用的方法。如果需要关闭标签，只需要在方法名前面加一个“x”就可以，在__noSuchMethod__()中，会对方法名的首字母进行判断，如果首字母是“x”，就会标记为结束标签，并将“x”从方法名称中去掉。接下来，会通过Mozilla的数组扩展 indexOf()来判断方法名称是否在可用标签的数组里面，如果方法名是无效的，就会抛出一个错误；如果方法名是有效的，就会返回生成的标签字符串。代码所支持的标签数量是可以动态设置的，我们只需要对标签列表数组进行修改，就可以达到添加或者删除“方法”的目的。

很显然，由于这个特性不能跨浏览器，所以肯定不能用于通常的情况下。但对于那些专门针对Mozilla引擎（比如Firefox等）的JavaScript应用来说，这无疑为我们敞开了一道神奇的大门，尤其在开发动态接口时，__noSuchMethod__()将是一个非常强有力的工具。

在JavaScript中，为什么要尽可能使用局部变量？

2009-02-12T11:59:00.024+08:00

在JavaScript中，我们应该尽可能的用局部变量来代替全局变量，这句话所有人都知道，可是这句话是谁先说的？为什么要这么做？有什么根据么？不这么做，对性能到底能带来多大的损失？本文就来探讨这些问题的答案，从根本上了解变量的读写性能都和哪些因素有关。

著作权声明

本文译自Nicholas C. Zakas于2009年2月10日在个人网站上发表的《JavaScript Variable Performance》。原文是唯一的正式版，本文是经过原作者（Nicholas C. Zakas）授权的简体中文翻译版（Simplified Chinese Translation）。译者（明达）在翻译的准确性上做了大量的努力，并承诺译文的内容完全忠于原文，但可能还是包含疏漏和不妥之处，欢迎大家指正。译注的内容是非正式的，仅代表译者个人观点。

以下是对原文的翻译：

在如何提高JavaScript性能这个问题上，大家最常听到的建议应该就是尽量使用局部变量（local variables）来代替全局变量（global variables）。在我从事Web开发工作的九年时间里，这条建议始终萦绕在我的耳边，并且从来没有质疑过，而这条建议的基础，则来自于 JavaScript处理作用域（scoping）和标识符解析（identifier resolution）的方法。

首先我们要明确，函数在JavaScript中具体表现为对象，创建一个函数的过程，其实也就是创建一个对象的过程。每个函数对象都有一个叫做 [[Scope]]的内部属性，这个内部属性包含创建函数时的作用域信息。实际上，[[Scope]]属性对应的是一个对象（Variable Objects）列表，列表中的对象是可以从函数内部访问的。比如说我们建立一个全局函数A，那么A的[[Scope]]内部属性中只包含一个全局对象（Global Object），而如果我们在A中创建一个新的函数B，那么B的[[Scope]]属性中就包含两个对象，函数A的Activation Object对象在前面，全局对象（Global Object）排在后面。

当一个函数被执行的时候，会自动创建一个可以执行的对象（Execution Object），并同时绑定一个作用域链（Scope Chain）。作用域链会通过下面两个步骤来建立，用于进行标识符解析。

1. 首先将函数对象[[Scope]]内部属性中的对象，按顺序复制到作用域链中。
2. 其次，在函数执行时，会创建一个新的Activation Object对象，这个对象中包含了this、参数（arguments）、局部变量（包括命名的参数）的定义，这个Activation Object对象会被置于作用域链的最前面。

在执行JavaScript代码的过程中，当遇到一个标识符，就会根据标识符的名称，在执行上下文（Execution Context）的作用域链中进行搜索。从作用域链的第一个对象（该函数的Activation Object对象）开始，如果没有找到，就搜索作用域链中的下一个对象，如此往复，直到找到了标识符的定义。如果在搜索完作用域中的最后一个对象，也就是全局对象（Global Object）以后也没有找到，则会抛出一个错误，提示用户该变量未定义（undefined）。这是在ECMA-262标准中描述的函数执行模型和标识符解析（Identifier Resolution）的过程，事实证明，大部分的JavaScript引擎确实也是这样实现的。需要注意的是，ECMA-262并没有强制要求采用这种结构，只是对这部分功能加以描述而已。

了解标识符解析（Identifier Resolution）的过程以后，我们就能明白为什么局部变量的解析速度要比其他作用域的变量快，主要是由于搜索过程被大幅缩短了。但是，具体会快多少呢？为了回答这个问题，我模拟了一系列的测试，来测试不同作用域深度中变量的性能。

第一个测试是向一个变量中写入一个最简单的值（这里使用字面量的数值1），结果如下图显示，很有趣：

从结果中不难看出，当标识符解析的过程需要进行深度搜索时，会伴随性能损失，而且性能损失的程度会随着标识符深度的增加而递增。意料之中的是，Internet Explorer表现的是最差的（但公平的说，IE 8还是有一些改善的）。值得注意的是，这里有一些例外情况，Google Chrome和最新的WebKit午夜版在访问变量的时间保持得很稳定，不会随着作用域深度的递增而增长。当然，这应该归功于它们所使用的下一代 JavaScript引擎，V8和SquirrelFish。这些引擎在执行代码时进行了优化，而且很明显，这些优化使访问变量的速度比以往更快。 Opera表现的也很不错，比IE、Firefox和当前版本的Safari要快的多，但比基于V8和Squirrelfish的浏览器要慢。 Firefox 3.1 Beta 2的表现有点出人意料，对于局部变量执行的效率非常高，但随着作用域层数的增加，效率便大打折扣。需要注意的是，我这里使用的都是默认设置，也就是说 Firefox是没有开启Trace功能的。

上面的结果是通过对变量执行写操作而得出的，其实我很好奇，读取变量时的情况会不会有什么不同，于是接着做了下面的测试。结果发现，读的速度要比写的速度快一些，但是性能变化的趋势是一致的。

和上个测试一样，Internet Explorer和Firefox还是最慢的，Opera表现了非常抢眼的性能，而同样的，Chrome和最新版本的Webkit午夜版显示了和作用域深度无关的性能趋势，同样需要注意的是，Firefox 3.1 Beta 2的变量访问时间还是会伴随着深度出现一个奇怪的跳跃。

在测试的过程中，我发现一个有趣的现象，就是Chrome在访问全局变量的时候会有额外的性能损失。访问全局变量的时间和作用域层数没有关系，但是会比访问同样层数的局部变量的时间多出50%。

这两个测试可以给我们带来什么启示呢？首先是验证了那个古老的观点，就是要尽可能的使用局部变量。在所有的浏览器下，访问局部变量都比访问跨作用域的变量要快，当然也包括全局变量。下面这几点应该是通过这个测试得出的经验吧：

* 仔细检查函数中所有使用的变量，如果有一个变量不是当前作用域定义的，而且使用了不止一次，那么我们就应该把这个变量保存在局部变量中，而使用这个局部变量来进行读写操作。这样可以帮助我们将作用域外的变量的搜索深度减少到1.这对全局变量尤为重要，因为全局变量总是被放到作用域链的最后位置来搜索。
* 避免使用with语句。因为它会修改执行上下文（Execution Context）的作用域链，在最前面添加一个对象（Variable Object）。这就意味着在执行with的过程中，实际上的局部变量都被移到作用域链上的第二个位置，这会带来性能上的损失。
* 如果你确定一段代码肯定会抛出异常，那么就要避免使用try-catch，因为catch分支在作用域链上的处理方法和with是一样的。但try分支的代码是没有性能损失的，所以还是建议用try-catch来捕获那些不可预知的错误。

如果你想围绕这个话题展开更多的讨论，我在上个月的Mountain View JavaScript Meetup中曾经发表了一个小演讲。可以在SlideShare上下载幻灯片，或者观看聚会的完整视频，我的演讲大概从11分钟左右时开始。

译者笔记

大家如果在阅读本文的过程中，有什么疑惑，建议延伸阅读以下两篇文章：
* Richie写的《JavaScript对象模型-执行模型》
* 《ECMA-262第三版》，主要看看第十章，就是执行上下文（Execution Context）那张，本文提到的名词在那里都有详细的解释。

在最后的时候，Nicholas提到一个Mountain View JavaScript Meetup，Meetup那个网站其实就是一个各种现实世界活动的组织网站，需要翻墙才能访问，住在California真幸福，有那么多的好活动可以参加，呵呵。

如何判断JavaScript变量的类型

2009-02-06T17:12:00.011+08:00

数据类型是所有开发语言的基础，JavaScript虽然是一个弱类型的脚本语言，但是在数据类型上也有很多讲究的，看了淘宝UED玉伯的一篇文章，末尾有一个判断数据类型的函数，仔细揣摩后发现有一些改进的余地，于是有了本文。目标就是一个可以提供足够类型参考信息的函数。

【本文地址】http://cuimingda.com/2009/02/how-to-detect-javascript-object-type.html
【测试地址1】http://lab.cuimingda.com/jquery/tof/
【测试地址2】http://lab.cuimingda.com/detection/window.html

在JavaScript中，变量中可以存储的值主要有两种类型：原始值（primitive value）和引用值（reference value）。前者通常是固定而又简单的数据，存储在栈（stack）中，而后者则是比较大的对象，存储在堆（heap）中，而对于后者的调用，是通过存储在栈中的指针来完成的。原始类型有五种：Number、String、Boolean、Null和Undefined，引用类型都继承自Object。

我们的最终目标就是一个叫做tof的全局函数，返回值为字符串，代表anything对应的类型，因为所有的引用类型都是object，所以这里返回的类型应该不局限于数据类型，应该尽可能的反映出anything的真实信息：

/*
var t = tof(anything);
*/

第一个实现肯定是利用传统的typeof来实现：

/*
function tof(val) {
return typeof(val);
}
*/

typeof可以得出的结论有五种：undefined、string、number、boolean和object。和原始类型比较还差个null，这个比较特殊，typeof(null)的返回值是object，这本来是JavaScript早期的bug，但后来却被写入了ECMAScript标准，可以理解为null是object的占位符。很明显，typeof无法满足我们的需求。

幸好Google的Mark Miller找到另外一个非常有效的判断数据类型的方法，就是利用Object.prototype.toString.call，用这个方法对Date类型数据进行计算，得到的结果是“[object Date]”，对于其他类型，前半部分始终是object，后半部分会发生变化，这样就很方便我们判断了。jQuery从1.3开始，也采用了这种方法判断array和function。下面我们来改进一下：

/*
function tof(val) {
return Object.prototype.toString.call(val).match(/object\s(\w+)/)[1];
}
*/

这个函数现在已经可以判断非常多的情况了，等等，undefined和null怎么返回的是Window（Firefox 3.0.6和Opera 9.63），在IE 7下返回Object，在Chrome返回builtins，在Safari 3.2下返回DOMWindow，明显优于这两个被定义为全局对象的属性，在不同的浏览器下挂到了不同的全局对象上。既然这么特殊，只能对他们单独有待一下了：

/*
function tof(val) {
var t;
switch(val) {
  case null: t = "null"; break;
  case undefined: t = "undefined"; break;
  default:
      t = Object.prototype.toString.call(val).match(/object\s(\w+)/)[1];
      break;
}
return  t.toLowerCase();
}
*/

到这里，我们已经可以判断很多object了，包括array、regexp、date等。让我们再多想一些，比如你碰到过需要判断DOM元素类型的情况么？这个首先要说明个问题，我们访问DOM，其实有两种方式，一种是通过树型的继承方式，就是Element为基础的，另外一种是构建在xml基础上的node模式，而对应每个节点都有tagName和nodeName两个属性，大部分时候要求是必须一样的，一些特殊节点只有nodeName，没有tagName，比如document的nodeName为“#document”，tagName为空值。

/*
function tof(val) {
var t;
switch(val) {
  case null: t = "null"; break;
  case undefined: t = "undefined"; break;
  default:
      t = val.nodeName || Object.prototype.toString.call(val).match(/object\s(\w+)/)[1];
      break;
}
return  t.toLowerCase();
}
*/

如果是DOM元素，首先取节点名称，取不到再用老办法判断对象类型。这样，不管是通过document.createElement构建的元素，还是通过document.getElementById获取的元素，都可以得到一个可以参考的类型了，注意此类型非彼类型，只是元素名称而已。经过了以上几个步骤，还有什么情况会出现object呢，其中一个就是我们自己定义的对象，或者称为类？这里我们采用构造函数来搞定。

/*
function tof(val) {
var t;
switch(val) {
  case null: t = "null"; break;
  case undefined: t = "undefined"; break;
  default:
      t = val.nodeName || Object.prototype.toString.call(val).match(/object\s(\w+)/)[1];
      if(!!val.constructor && t.toLowerCase() === "object") {
          t = val.constructor.toString().match(/^\s*function\s(\w+)/)[1];
      }
      break;
}
return  t.toLowerCase();
}
*/

构造函数的判断放到最后，不得已而为之的情况。一是要处理那些还处于object状态的，二是要确保人家要有构造函数，可不是每个对象都有构造函数的。构造函数的类型是function，如果直接拿来比较在有些时候会有问题，比如不同框架的时候。所以我们将function的内容转换为字符串，通过正则表达式来取函数名。这里有个插曲就是，IE很缺德，在function前面加了一个空格，害我多调了好半天正则表达式。

基本上完结了，我们还是没有彻底的消除object，一个典型的情况就是通过{}直接定义对象，那个名字我是不会获取了，谁要是知道一定要告诉我。再比较特殊的就是IE了，有N多对象无法判断实际类型，只能给出object，暂时没有头绪。

2月7日更新，发现原来的代码还是存在很多漏洞的，更新了一下，并转换为jQuery插件：

/*
(function($){
$.extend({
tof: function(val, description) {
        var result, constructorName;
        switch(val) {
            case null: result = "Null"; break;
            case undefined: result = "Undefined"; break;
            default:
                result = Object.prototype.toString.call(val).match(/^\[object\s(\w+)\]$/)[1];
            
                if(typeof(Node) !== "undefined") {
                    if(val instanceof Node) {
                        if(typeof(val.nodeName) === "string") {
                            result = val.nodeName;
                        }
                    }
                }
                else {
                    if(typeof(val.nodeName) === "string") {
                        result = val.nodeName;
                    }
                }

                if(result === "Object") {
                    // can not access fireunit's constructor
                    try {
                        if(typeof(val.constructor) !== "undefined") {
                            constructorName = val.constructor.toString().match(/^\s*function\s(\w+)/);
                            if(constructorName !== null) {
                                result = constructorName[1];
                            }
                        }
                    } catch(err) {}
                }
                break;
        }
        return  result.toLowerCase();
}
});
})(jQuery);
*/

这里需要提一下的是，在IE中，无论怎么判断，alert、confirm和prompt三个函数的类型都是object，而在其他所有浏览器中都是function。

在玉伯那里，有一个这样的例子，经过测试是可以判断出数组的：

/*
function SubArray() {}
SubArray.prototype = [];
jstest.add(new SubArray(), "array", "prototype is array");
*/

对于数值来说，通过字面量定义的肯定返回number，而对于用new Number来定义的，虽然typeof的值是object，其实使用的过程中都会自动调用valueOf，所以在这里也会返回number的。而对于那些定义在全局变量上，和数值相关的特殊属性，获取类型也是number：

/*
jstest.add(0, "number", "literal number 0");
jstest.add(1, "number", "literal number 1");
jstest.add("1", "string", "string \"1\"");
jstest.add(new Number(1.5), "number", "new Number(1.5)");
jstest.add((new Number(1.5)).valueOf(), "number", "(new Number(1.5)).valueOf()");
jstest.add((new Number(1.5)).toString(), "string", "(new Number(1.5)).toString()");
jstest.add(NaN, "number", "NaN - not a number");
jstest.add(Infinity, "number", "Infinity");
jstest.add(-Infinity, "number", "-Infinity");
*/

和布尔值相关的测试用例：

/*
jstest.add(true, "boolean", "literal boolean true");
jstest.add(false, "boolean", "literal boolean false");
jstest.add(new Boolean(true), "boolean", "new Boolean(true)");
*/

和浏览器的内置对象相关的测试用例：

/*
jstest.add(new Error(), "error", "new Error()");
jstest.add(new EvalError(), "error", "new EvalError()");
jstest.add(new Date(), "date", "new Date()");
jstest.add(/abc/, "regexp", "literal regular expression");
jstest.add(new RegExp("a?"), "regexp", "new RegExp()");
jstest.add([], "array", "array by []");
jstest.add(new Array(), "array", "array by new Array()");
jstest.add(Math, "math", "Math");
*/

DOM对象的测试用例：

/*
jstest.add(document.createElement("div"), "div", "HTML Element");
jstest.add(document, "#document", "document");
*/

自定义对象的测试用例：

/*
function TestClass(){};
jstest.add(new TestClass(), "testclass", "custom object, new TestClass()");
*/

2009年2月10日更新，上面的测试用例，测试的内容没有变，但已经单独提出来了，这两天整理出一篇来。

测试环境：
* Firefox 3.0.6
* Internet Explorer 7.0
* Safari 3.2
* Opera 9.63
* Chrome 1.0.154.48

参考资料：
* http://lucassmith.name/pub/typeof.html
* http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=916
* http://lifesinger.org/blog/?p=1109
* http://lifesinger.org/blog/?p=1130
* http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html

写在最最后面的
现在的状态应该说只能算是第一个版本吧，应该还有很大的优化余地，最终的目标应该是一个非常增强的typeof，不止要能适应各个浏览器的各个版本，还要尽可能多的判断出各种对象。大家要有好的改进想法，记得告诉我哟。

如何提升JavaScript的运行速度（DOM篇）

2009-02-04T05:34:00.005+08:00

在Web开发中，JavaScript的一个很重要的作用就是对DOM进行操作，可你知道么？对DOM的操作是非常昂贵的，因为这会导致浏览器执行回流操作，而执行了过多的回流操作，你就会发现自己的网站变得越来越慢了，我们应该尽可能的减少DOM操作。本文是这个系列的最后一篇，给出了一些指导性原则，比如在什么时候应该对DOM可以进行什么样的操作等。

【原文】Nicholas C. Zakas - Speed up your JavaScript, Part 4
【译文】明达 - 如何提升JavaScript的运行速度（DOM篇）

以下是对原文的翻译：

在过去的几周中，我为大家介绍了几种可以加快JavaScript脚本运行速度的技术。第一节介绍了如何优化循环。第二节的重点放在优化函数内部代码上，还介绍了队列（queuing）和记忆化（memoization）两种技术，来减轻函数的工作负担。第三节就如何将递归转换为迭代循环或者记忆化方式的话题，展开了讨论。第四节是这个系列的最后一篇，也就是本文，将重点阐述过多的DOM操作所带来的影响。

我们都知道，DOM操作的效率是很低的，而且不是一般的慢，而且这也是引发性能问题的常见问题之一。为什么会慢呢？因为对DOM的修改为影响网页的用户界面，重绘页面是一项昂贵的操作。太多的DOM操作会导致一系列的重绘操作，为了确保执行结果的准确性，所有的修改操作是按顺序同步执行的。我们称这个过程叫做回流（reflow），同时这也是最昂贵的浏览器操作之一。回流操作主要会发生在几种情况下：

* 当对DOM节点执行新增或者删除操作时。
* 动态设置一个样式时（比如element.style.width="10px"）。
* 当获取一个必须经过计算的尺寸值时，比如访问offsetWidth、clientHeight或者其他需要经过计算的CSS值（在兼容DOM的浏览器中，可以通过getComputedStyle函数获取；在IE中，可以通过currentStyle属性获取）。

解决问题的关键，就是限制通过DOM操作所引发回流的次数。大部分浏览器都不会在JavaScript的执行过程中更新DOM。相应的，这些浏览器将对对DOM的操作放进一个队列，并在JavaScript脚本执行完毕以后按顺序一次执行完毕。也就是说，在JavaScript执行的过程中，用户不能和浏览器进行互动，直到一个回流操作被执行。（失控脚本对话框会触发回流操作，因为他执行了一个中止JavaScript执行的操作，此时会对用户界面进行更新）

如果要减少由于DOM修改带来的回流操作，有两个基本的方法。第一个就是在对当前DOM进行操作之前，尽可能多的做一些准备工作。一个经典的例子就是向document对象中添加很多DOM节点：

/*
for (var i=0; i < items.length; i++){
   var item = document.createElement("li");
   item.appendChild(document.createTextNode("Option " + i);
   list.appendChild(item);
}
*/

这段代码的效率是很低的，因为他在每次循环中都会修改当前DOM结构。为了提高性能，我们需要将这个次数降到最低，对于这个案例来说，最好的办法是建立一个文档碎片（document fragment），作为那些已创建元素元素的临时容器，最后一次将容器的内容直接添加到父节点中：

/*
var fragment = document.createDocumentFragment();
for (var i=0; i < items.length; i++){
   var item = document.createElement("li");
   item.appendChild(document.createTextNode("Option " + i);
   fragment.appendChild(item);
}
list.appendChild(fragment);
*/

经过调整的代码，只会修改一次当前DOM的结构，就在最后一行，而在这之前，我们用文档碎片来保存那些中间结果。因为文档碎片没有任何可见内容，所以这类修改不会触发回流操作。实际上，文档碎片也不能被添加到DOM中，我们需要将它作为参数传给appendChild函数，而实际上添加的不是文档碎片本身，而是它下面的所有子元素。

避免不必要回流操作的另外一种方法，就是在对DOM操作之前，把要操作的元素，先从当前DOM结构中删除。对于删除一个元素，基本有两种方法：
1. 通过removeChild()或者replaceChild()实现真正意义上的删除。
2. 设置该元素的display样式为“none”。

而一旦修改操作完成，上面这个过程就需要反转过来，将删除的元素重新添加到当前的DOM结构中，我们还是拿上面的例子来做说明：

/*
list.style.display = "none";
for (var i=0; i < items.length; i++){
   var item = document.createElement("li");
   item.appendChild(document.createTextNode("Option " + i);
   list.appendChild(item);
}
list.style.display = "";
*/

将list的display样式设置为“none”后，就将这个元素从当前的DOM结构中删除了，因为这个节点不再可视。在将display属性设置回之前的默认值之前，向其下添加子元素是不会触发回流操作的。

另外一个经常引起回流操作的情况是通过style属性对元素的外观进行修改。比如下面这个例子：

/*
element.style.backgroundColor = "blue";
element.style.color = "red";
element.style.fontSize = "12em";
*/

这段代码修改了三个样式，同时也就触发了三次回流操作。每次修改元素的style属性，都肯定会触发回流操作。如果你要同时修改一个元素的很多样式，最好的办法是将这些样式放到一个class下，然后直接修改元素的class，这可比单独修改元素的样式要强得多。比如下面这个例子：

/*
.newStyle {
   background-color: blue;
   color: red;
   font-size: 12em;
}
*/

这样我们在JavaScript代码中，只需下面这行代码就可以修改样式：

/*
element.className = "newStyle";
*/

修改元素的class属性，会一次将所有的样式应用在目标元素上，而且只会触发一次回流操作。这样做不止更加有效，而且还更容易维护。

既然DOM几乎在所有情况下都很慢，就很有必要将获取的DOM数据缓存起来。这种方法，不仅对获取那些会触发回流操作的属性（比如offsetWidth等）尤为重要，就算对于一般情况，也同样适用。下面介绍一个效率低的夸张的例子：

/*
document.getElementById("myDiv").style.left = document.getElementById("myDiv").offsetLeft +
   document.getElementById("myDiv").offsetWidth + "px";
*/

这里对getElementById()调用了三次，是一个很大的问题，访问DOM是很昂贵的，而这三个调用恰恰访问的是同一个元素，也许我们像下面这样写，会更好一些：

/*
var myDiv = document.getElementById("myDiv");
myDiv.style.left = myDiv.offsetLeft + myDiv.offsetWidth + "px";
*/

我们去掉了一些冗余操作，现在对DOM操作的次数已经被减小了。对于那些使用次数超过一次的DOM值，我们都应该缓冲起来，这样可以避免无谓的性能消耗。

也许，拖慢属性访问速度的罪魁祸首就是HTMLCollection对象。这些对象是object类型的，只要DOM需要返回一组节点时就会使用这个对象，也就是说childNodes属性和getElementsByTagName()的返回值都属于这种情况。我们可能经常会将HTMLCollection当作数组来使用，但实际上他是一个根据DOM结构自动变化的实体对象。每次你访问一个HTMLCollection对象的属性，他都会对DOM内所有的节点进行一次完整匹配，这意味着下面的代码将导致一个死循环：

/*
var divs = document.getElementsByTagName("div");
for (var i=0; i < divs.length; i++){  //infinite loop
   document.body.appendChild(document.createElement("div"));
}
*/

这段代码为什么会变成死循环呢？因为在每次循环中，将会向document中新增一个div元素，同时也会更新divs这个集合，也就是说循环的索引永远都不会超过divs.length的值，因为divs.length的值是伴随着循环而递增的。每次访问divs.length，就会更新一次集合对象，这可比访问一个普通数组的length属性要付出更大的代价。当对HTMLCollection对象进行操作时，应该将访问的次数尽可能的降至最低，最简单的，你可以将length属性缓存在一个本地变量中，这样就能大幅度的提高循环的效率。

/*
var divs = document.getElementsByTagName("div");
for (var i=0, len=divs.length; i < len; i++){  //not an infinite loop
   document.body.appendChild(document.createElement("div"));
}
*/

修改后的代码已经不是死循环了，因为在每次循环时，len的值都是保持固定不变的。将属性值缓存起来除了更加有效率，还可以保证document不会执行多于一次的查询。

本文是“Speed up your JavaScript”这个系列的最后一篇文章，我希望你现在已经知道如何避免那个脚本失控的对话框，以及如何让你的脚本运行的更快。我所提到的技巧很多别人已经提过了，我只是将它们组织到一起，这样大家可以更容易的找到这些信息。如果你有什么更好的话题需要来我整理，在评论中直接告诉我，或者直接联系我吧。

猜猜看，大家是不是喜欢jQuery 1.3这个版本？

2009-02-04T02:40:00.006+08:00

jQuery 1.3在2009年1月14日发布，这个版本大家满意么？大家很关心这个问题，其实这也是整个jQuery团队非常关心的问题之一。John Resig通过两个在线工具Google Analytics和Google Trends的数据来做分析，从一个侧面反映了jQuery 1.3这个版本的状况，同时也对jQuery的历史发展做了相关的说明。

【原文】John Resig - jQuery 1.3 Aftermath
【译文】明达 - 猜猜看，大家是不是喜欢jQuery 1.3这个版本？

以下是对原文的翻译：

有一个问题其实很难回答：如何判断一个版本是否取得了成功？在jQuery这个项目中，我们试图寻找一系列可以作为依据的准则。

* 用户对这个版本是否满意？
* 用户是否接受这个版本？
* 我们是否满足了那些以前不使用jQuery的用户的需要？

这几个问题都没有足够精确的数字来支撑（但我们确实仔细的倾听了用户反馈，无论是在博客上、Twitter上、邮件列表上、或是其他的任何地方，但截止到目前，我们得到的大部分是积极的肯定），但我们确实有几个可以用来利用的工具，让这个问题变得更加简单一些，这些工具就是Google Analytics和Google Trends。

上面这个趋势图，是通过Google Analytics对jquery.com在2008年12月和2009年1月的访问记录进行比对的结果。

我们可以很容易发现，相比于12月份，每天都有30%左右的增长。这是我非常愿意看到的，1.3这个版本非常具有“粘性”（用户会经常回来看看，每日访问人数不会低于预发布阶段时的程度）。

注意比对两个时间段的结果，跳出率（bounce rate）出现增长，而平均每次访问页数（pages/visit）和平均停留时间（avg. time on site）出现降低，而导致出现这个变化的页面都集中在1.3和1.3.1的发布页面，大家都是过来检查最新的发布版本，然后直接离开的。

2009年1月14日是jQuery 1.3发布的日子（那一周的流量特别大，Ajaxian、Reddit、Hacker News以及很多博客都介绍了这个新版本的发布），在26号所在的那周我们上了Digg的首页，但是在流量方面没有看到明显的变化。

我将圣诞假期这个时间段的数据去掉了，因为那时候的流量非常低，不利于比较。

以上数据都只是专门针对jQuery的，jQuery UI和静态文件都采用单独的配置文件进行统计。

Google Trends可以帮助我们了解jQuery的使用情况，最典型的应用就是“圣诞节大衰退”。

关注jQuery的用户主要出现在工作日（注意前面的分析日志，周末会出现衰退）。每年的圣诞节假期左右（12月23日 - 次年1月3日），访问人数都会有很大幅度的下降，我们也可以在Google Trends的统计中看出这种关联性。

在维护jQuery的过程中，我们学习到了一件事情，就是在两个项目的交替时会流失用户。一个开发者在结束了一个项目后，会重新评估他的开发工具链，寻找可以改进的地方，这个时候，用户可能会更换所使用的工具，我们的使命就是确保始终提供最棒的工具和经验，这样大家就没有更换工具的必要了（比如提供更清晰的文档、更有效率的代码以及频繁的更新等）。

还有一个类似的情况发生在休假之后。当用户休息了一到两周，没有碰工作时的代码，在回到工作岗位后就存在更换工具的可能性，要么被这些用户放下，要么就做到足够强劲，吸引用户继续使用。

现在的问题已经演变为：我们如何在低迷的时候挽留住用户（最好是发现新的用户）？

当我们仔细研究2006-2007时的低迷期数据，我们会发现在用户休假归来的时候有一个快速的反弹。为什么？因为jQuery 1.1在那个时候发布了。

但是回顾2007-2008的数据，休假以后基本上没有反弹，而且花了将近半年的时间才恢复到之前的水平，顺便说一下，在一月份没有发布任何重大版本。

于是我们修正了这个时间周期，我们发布了jQuery 1.3，你可以注意到我们是如何赢回用户，甚至在一段时间内提高了市场占用率的。

从长远的角度看，我对jQuery 1.3的发布非常有信心，我认为我们将有一个非常辉煌的2009年。很可能这周我们就发布另外一个后续版本（1.3.2），除这以外还有一点很明确，我们将在1.3.3以及后续的版本中增加更多全新的功能。

屏蔽Ad blockers，可行么？

2009-02-02T11:35:00.005+08:00

Firefox中最著名的扩展之一要属Adblock Plus了，有了这个扩展我们就可以清清静静的看网站，但是这对于网站的开发者来说可不是什么好消息，都把广告屏蔽了拿什么养家糊口啊。刚就在twitter中看到一个，只找到脚本的片段，但是其中的思想大家一看就可以理解了。但其实个人不是很推荐，如果网站的广告有针对性，大家不就没有理由屏蔽了，不是么？

【消息来源】http://twitter.com/schill/status/1167839656
【本文地址】http://cuimingda.com/2009/02/block-ad-blockers.html

先看截图，当用户使用广告屏蔽手段，而又没将这个网站加入白名单时，网站的所有内容就会被替换成下面的图片提示：

实现这个功能其实很简单，就是下面这一小段代码，我把完整的内容都粘贴过来了：

/* http://www.publicradio.org/config/cobrand/standard/js/apm001/national_fix.js
$(window).load(function() {
var $mainDiv = $('#apmAdsContainer');
var myHeight = $mainDiv.height();
if (myHeight == 0) {
   $('body').css({
       'background-image': 'url(http://www.publicradio.org/config/cobrand/standard/images/apm001/blockimg.gif)',
       'background-position': 'center 5px',
       'background-repeat': 'no-repeat'
   });
}
});
*/

脚本的基本思路就是判断广告图层的高度，如果为0，表明被屏蔽了，就拒绝显示内容。这段代码依赖于jQuery，虽然作者加载的部分写的不是很好，但为了完整，也一起贴过来吧，唉，为什么要用document.write呢？

/* http://www.publicradio.org/config/cobrand/standard/js/apm001/jQ_detect.js
function include_js(js_url) {
document.write("\<script type=\"text/javascript\" ");
document.write("src='" + js_url + "'");
document.write("\>");
document.write("\</script\>");
}
if (typeof(window["jQuery"]) == "undefined") {
include_js("http://americanpublicmedia.publicradio.org/standard/js/all_domains/jquery/jquery_1.2.6.pack.js");
}
*/

对于Adblock Plus来说，除了可以隐藏元素以外，还可以组织脚本加载，这时候这段脚本可能就无效了，也许需要判断广告对象是否存在？而且让元素消失的方法也不是只有一种，应该多判断几种才能兼容各种情况。但其实最主要的，也许这样做会吓跑部分用户吧，呵呵，通过其他方式积极的引导用户将自己的网站加到Adblock Plus的白名单中，也许是个更好的主意。

历史上，加密和解密作为两大技术阵营，此消彼长，客观上促进了安全技术的发展。Ad和Ad blocker会不会也这样呢？

咳咳～～大家如果真的看到这里，感觉这个博客还不错，记得把他放进Adblock Plus的白名单啊，我这里可没有广告，连Adsense都没有，主要我得知道你什么时候来过哟（Adblock Plus China-list会屏蔽各种网站统计工具，比如我用的Google Analytics，^_^），呵呵，这样我才能更有动力嘛。

FireScope - 面向Web开发者和设计者的参考手册

2009-02-01T22:01:00.005+08:00

Sitepoint有一个不错的针对Web开发者和设计者的参考手册网站，可以查询HTML、CSS和JavaScript的基本信息、兼容性和示例代码等，同时这个网站也包含了一个Firefox扩展，可以集成在Firebug中，可以显示所有你看到的HTML元素、HTML属性和CSS属性的参考信息，目前还不支持JavaScript部分。

【扩展名称】FireScope
【扩展作者】Sitepoint - James Edwards
【下载地址】http://tools.sitepoint.com/firescope/firescope-1.0.1-en-us.xpi
【AMO地址】https://addons.mozilla.org/en-US/firefox/addon/10273

FireScope是一个Firefox扩展，同时也是一个Firebug扩展，可以帮助用户快速的搜索HTML元素、属性以及CSS属性的参考信息，具体的功能大家从下面的一系列截图上就能体会了。目前版本为1.0.1，最低要求为Firefox 2和Firebug 1.2。大家可以直接点击上面的链接下载，或者到AMO网站上下载。

以下部分内容翻译自该扩展网站：

功能列表：

你可以查找HTML元素和属性，以及CSS属性（或者进行组合查询）。搜索结果是根据输入实时刷新的，通常你可能只需要书要查找内容的第一个到第二个字母就可以，这样可以帮助你更快的找到结果，

查找结果中会显示和浏览器兼容性相关的信息，以及一个简要的用法说明。当然还提供了一个指向SitePoint Reference网站的链接，在那里会有更相信的参考信息。

鼠标右键点击搜索结果，在菜单中有两个选项：一个是在线查询详细信息，另外一个是显示选择项的示例代码。

示例代码会在侧栏打开，里面会包含有实用价值的例子，你可以根据例子很快掌握用法。同时这些示例代码是可以编辑的，而且也很容易复制，在Firefox 3中直接双击就是全部选择。

在HTML面板中，你可以在任意元素、属性名称或者属性值上点击鼠标右键（编辑状态也可以点），这时在快捷菜单中你可以进行两项选择，查找你选择的项目，或者显示这个项目对应的示例代码。

类似的，在CSS面板中你也可以右键单击任意属性名称或者属性值，可以进行的操作与HTML面板中的相同。

在HTML面板中，如果你右键点击的标记名称是选择状态（就是通常深蓝色背景高亮那种），在菜单中选择“Look up selection”会执行一个特殊搜索，所有选中的元素、属性已经应用的CSS样式都将被搜索。有时候这个特殊搜索是自动进行的，比如在你选择元素后点击“Reference”面板时，就会自动搜索当前选中元素相关的所有内容。

当使用Inspector更能探索不同元素的时候，如果示例代码的侧栏处于打开状态，就将会实时显示当前选中元素的示例代码。

类似的，只要示例代码侧栏处于打开状态，在DOM列表中的选择也会触发显示相应示例代码的操作。当然和HTML面板一样，也包含一个快捷菜单，可以执行查找和显示示例代码的操作。

写在后面

其实个人认为Sitepoint的参考手册要比w3schools.com的实用一些。而且和Firebug集成这个思路很好。但是现在明显还是不够完善，不止是扩展，还有参考手册上资料，尤其是JavaScript部分现在还在测试中，还没有包含进来。但对于Web开发者和设计者，这应该是一个必备的工具，推荐使用。

如何提升JavaScript的运行速度（递归篇）

2009-02-01T04:06:00.003+08:00

影响JavaScript性能的另外一个杀手就是递归，在上一节中提到采用memoization技术可以优化计算数值的递归函数，但memoization不是万能的，不是所有的递归函数都可以用memoization技术优化，本文介绍了这些情况，并介绍了解决办法，就是将递归转换为迭代，同时需要注意，本文末尾介绍的方案不是最终的方案，还需要和上一节优化循环的方案综合起来才能达到最佳效果。

【原文】Speed up your JavaScript, Part 3
【作者】Nicholas C. Zakas
【译文】http://cuimingda.com/2009/02/speed-up-your-javascript-part-3.html
【译者】明达

以下是对原文的翻译：

递归是拖慢脚本运行速度的大敌之一。太多的递归会让浏览器变得越来越慢直到死掉或者莫名其妙的突然自动退出，所以我们一定要解决在JavaScript中出现的这一系列性能问题。在这个系列文章的第二篇中，我曾经简短的介绍了如何通过memoization技术来替代函数中太多的递归调用。memoization是一种可以缓存之前运算结果的技术，这样我们就不需要重新计算那些已经计算过的结果。对于通过递归来进行计算的函数，memoization简直是太有用了。我现在使用的memoizer是由 Crockford写的，主要应用在那些返回整数的递归运算中。当然并不是所有的递归函数都返回整数，所以我们需要一个更加通用的memoizer()函数来处理更多类型的递归函数。

function memoizer(fundamental, cache) {
  cache = cache || {};
  var shell = function(arg) {
      if (! (arg in cache)) {
          cache[arg] = fundamental(shell, arg);
      }
      return cache[arg];
  };
  return shell;
}

这个版本的函数和Crockford写的版本有一点点不同。首先，参数的顺序被颠倒了，原有函数被设置为第一个参数，第二个参数是缓存对象，为可选参数，因为并不是所有的递归函数都包含初始信息。在函数内部，我将缓存对象的类型从数组转换为对象，这样这个版本就可以适应那些不是返回整数的递归函数。在shell函数里，我使用了in操作符来判断参数是否已经包含在缓存里。这种写法比测试类型不是undefined更加安全，因为undefined是一个有效的返回值。我们还是用之前提到的斐波纳契数列来做说明：

var fibonacci = memoizer(function(recur, n) {
  return recur(n - 1) + recur(n - 2);
}, { "0": 0, "1": 1} );

同样的，执行fibonacci(40)这个函数，只会对原有的函数调用40次，而不是夸张的331,160,280次。memoization对于那些有着严格定义的结果集的递归算法来说，简直是棒极了。然而，确实还有很多递归算法不适合使用memoization方法来进行优化。

我在学校时的一位教授一直坚持认为，任何使用递归的情况，如果有需要，都可以使用迭代来代替。实际上，递归和迭代经常会被作为互相弥补的方法，尤其是在另外一种出问题的情况下。将递归算法转换为迭代算法的技术，也是和开发语言无关的。这对JavaScript来说是很重要的，因为很多东西在执行环境中是受到限制的（the importance in JavaScript is greater, though, because the resources of the execution environment are so restrictive.）。让我们回顾一个典型的递归算法，比如说归并排序，在JavaScript中实现这个算法需要下面的代码：

function merge(left, right) {
  var result = [];
  while (left.length > 0 && right.length > 0) {
      if (left[0] < right[0]) {
          result.push(left.shift());
      } else {
          result.push(right.shift());
      }
  }
  return result.concat(left).concat(right);
}

//采用递归实现的归并排序算法
function mergeSort(items) {
  if (items.length == 1) {
      return items;
  }
  var middle = Math.floor(items.length / 2),
  left = items.slice(0, middle),
  right = items.slice(middle);
  return merge(mergeSort(left), mergeSort(right));
}

调用mergeSort()函数处理一个数组，就可以返回经过排序的数组。注意每次调用mergeSort()函数，都会有两次递归调用。这个算法不可以使用memoization来进行优化，因为每个结果都只计算并使用一次，就算缓冲了结果也没有什么用。如果你使用mergeSort()函数来处理一个包含100个元素的数组，总共会有199次调用。1000个元素的数组将会执行1999次调用。在这种情况下，我们的解决方案是将递归算法转换为迭代算法，也就是说要引入一些循环（关于算法，可以参考这篇《List Processing: Sort Again, Naturally》）：

// 采用迭代实现的归并排序算法
function mergeSort(items) {
  if (items.length == 1) {
      return items;
  }
  var work = [];
  for (var i = 0,
  len = items.length; i < len; i++) {
      work.push([items[i]]);
  }
  work.push([]); //in case of odd number of items
  for (var lim = len; lim > 1; lim = (lim + 1) / 2) {
      for (var j = 0,
      k = 0; k < lim; j++, k += 2) {
          work[j] = merge(work[k], work[k + 1]);
      }
      work[j] = []; //in case of odd number of items
  }
  return work[0];
}

这个归并排序算法实现使用了一系列循环来代替递归进行排序。由于归并排序首先要将数组拆分成若干只有一个元素的数组，这个方法更加明确的执行了这个操作，而不是通过递归函数隐晦的完成。work数组被初始化为包含一堆只有一个元素数组的数组。在循环中每次会合并两个数组，并将合并后的结果放回 work数组中。当函数执行完成后，排序的结果会通过work数组中的第一个元素返回。在这个归并排序的实现中，没有使用任何递归，同样也实现了这个算法。然而，这样做却引入了大量的循环，循环的次数基于要排序的数组中元素的个数，所以我们可能需要使用在上篇讨论过的技术来进行修订，处理这些额外开销。

总结一下基本原则，不管是什么时候使用递归的时候都应该小心谨慎。memoization和迭代是代替递归的两种解决方案，最直接的结果当然就是避免那个提示脚本失控的对话框。

如何治理Firefox扩展的全局命名空间污染问题

2009-01-31T22:43:00.006+08:00

全局变量是魔鬼，这句话在JavaScript存在的地方应该就是成立的，当然Firefox扩展也不例外，如果大家把多于一个的对象置于全局命名空间下，和其他扩展的冲突是很容易发生的，而且发现这种冲突引起的错误是很困难的，因为每个人的扩展列表都不一样啊。避免全局名字污染已经成了一个基本原则，本文从这点引申，介绍了一个应用在Firebug中的扩展架构模式，非常值得推荐。

【原文】Firefox Extensions: Global Namespace Pollution
【作者】Jan Odvarko
【译文】http://cuimingda.com/2009/01/extensions-global-namespace-pollution.html
【译者】明达

以下是对原文的翻译：

最近有几个开发者向我咨询如何设计Firefox扩展的架构，第一个显现在我脑海中的答案就是要合理定义那些在ChromeWindow作用域下的全局变量。

不合理的定义全局变量，可以轻易的引发不同扩展之间的冲突，而这些完全是应该避免的（这也是AMO审阅的步骤之一），因为冲突所引发的问题是很难被发现的。就目前的开发环境来说，全局变量就是魔鬼，尤其是采用OOP开发模式的时候。

我不想重复介绍如何从头开始开发一个Firefox扩展，对于这方面已经有很多非常详细的文章。本文的重点放在如何设计一个更加易于维护的Firefox扩展架构。

如果你对前面的介绍感兴趣，那就接着看吧。。。

命名空间架构

扩展之间发生冲突的重要原因就是因为定义了不合理的全局变量。我认为对每个扩展来说，只有一个全局变量已经很足够了（可以根据扩展的信息来定义这个唯一的全局变量的名字，比如可以是扩展的名字、域名、地址等），不仅可以满足我们的开发，而且可以避免那些令人讨厌的冲突。

Firebug使用的命名空间架构，基本建立在著名的Module Pattern基础上（这种模式最早由Douglas Crockfod定义）下的。这种模式简单而清晰，但其实我在很长时间里都不是很明确这种模式究竟是如何工作的（I hadn’t understand how it actually works for a long time）。我相信每个开发者都可以充分利用这个方法。

基本的思路是将每个JavaScript脚本文件放进自己的作用域，这是通过一个函数来实现的，没有定义任何全局变量，比如下面这段代码：

function() {
  // TODO: 脚本文件中的全部代码
}

我管这个函数就叫做命名空间。

摆在眼前的第一个问题是，如何确定这个函数的内容会在正确的时间被调用。第二个问题是，如何在多个脚本文件中共享对象（这个会在后面的章节解答）。 Firebug通过将所有的命名空间进行注册，并在Firefox chrome UI加载的时候调用来解决第一个问题，也就是下面这段代码：

myExtension.ns(function() {
  // TODO: 脚本文件中的全部代码
});

命名空间（就是原来定义的那个函数）为当作myExtension.ns函数的一个参数，而myExtension对象是这个扩展中定义的唯一全局变量。这个对象代表着整个扩展。不用担心这个名字太长，我们可以为他建立个快捷方式（在实际开发中，这个名字可能会类似 comSoftwareIsHardMyExtension这个样子）。

ns函数比较简单，就是把所有的方法都添加到一个数组中。

var namespaces = [];
this.ns = function(fn) {
  var ns = {};
  namespaces.push(fn, ns);
  return ns;
};

执行已注册命名空间的函数，不可以命名为apply，别的什么名字都可以。

this.initialize = function() {
  for (var i = 0; i < namespaces.length; i += 2) {
      var fn = namespaces[i];
      var ns = namespaces[i + 1];
      fn.apply(ns);
  }
};

现在，然我们把前面的代码连起来，看看全局扩展对象是如何定义和初始化的。

下面这些代码是browserOverlay.js文件的内容，这个脚本文件会在一个界面文件（browserOverlay.xul）中被引用。

// 扩展对应的唯一全局变量
var myExtension = {};
(function() { // 注册命名空间
  var namespaces = [];
  this.ns = function(fn) {
      var ns = {};
      namespaces.push(fn, ns);
      return ns;
  };

  // 初始化
  this.initialize = function() {
      for (var i = 0; i < namespaces.length; i += 2) {
          var fn = namespaces[i];
          var ns = namespaces[i + 1];
          fn.apply(ns);
      }
  };

  // 收尾的清理工作
  this.shutdown = function() {
      window.removeEventListener("load", myExtension.initialize, false);
      window.removeEventListener("unload", myExtension.shutdown, false);
  };

  // 注册两个事件处理程序，维护扩展的生存期
  window.addEventListener("load", myExtension.initialize, false);
  window.addEventListener("unload", myExtension.shutdown, false);
}).apply(myExtension);

正如我前文所述，这里只有一个全局对象myExtension。

总结一下，这个对象要实现下面几个方法：
ns - 注册一个新的命名空间。
initialize - 初始化所有的命名空间。
shutdown - 收尾的清理工作。

当然这段代码也会确保initialize和shutdown方法会在正确的时间被调用，这也是两个事件处理程序的作用。

browserOverlay.xul现在看起来可能会是下面这个样子：

<?xml version="1.0"?>
<overlay xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <script src="chrome://namespace/content/browserOverlay.js" type="application/x-javascript"/>
  <script src="chrome://namespace/content/Module1.js" type="application/x-javascript"/>
  <script src="chrome://namespace/content/Module2.js" type="application/x-javascript"/>
</overlay>

在这里，Module1.js和Module2.js两个文件是一模一样的。

myExtension.ns(function() {
  // TODO: 脚本内的全部代码
});

在不同的模块间共享数据

我们已经把所有的脚本置于本地的作用域下，现在让我们来回答上面提到的第二个问题，就是在不同的命名空间下如何共享函数和数据。基本的思路当然是要利用我们唯一的全局对象啦，也就是myExtension。

首先，让我们先来看看下面这段代码（都在lib.js文件中）

myExtension.LIB = {
  // 共享函数接口
  getCurrentURI: function() {
      return window.location.href;
  },

  // 扩展对象的快捷方式
  theApp: myExtension,

  // XPCOM组件的快捷方式
  Cc: Components.classes,
  Ci: Components.interfaces,

  // 等等。。。
};

你可以注意到，这段代码在全局的myExtension对象下建立了一个新的LIB属性，这个属性定义了一个函数库，是要在扩展所有的模块中共享的。你应该在Java的包结构中看到过相同的做法，所有的命名空间呈树状结构分布在一个唯一的对象下面，YUI也是这样子做的。

lib.js文件也在browserOverlay.xul中引入，紧随browserOverlay.js的后面。

<?xml version="1.0"?>
<overlay xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <script src="chrome://myextension/content/browserOverlay.js" type="application/x-javascript"/>
  <script src="chrome://myextension/content/lib.js" type="application/x-javascript"/>
  <script src="chrome://myextension/content/Module1.js" type="application/x-javascript"/>
  <script src="chrome://myextension/content/Module2.js" type="application/x-javascript"/>
</overlay>

让我们对模块内的脚本也做一些改进。

myExtension.ns(function() {
  with(myExtension.LIB) {
      // TODO: 脚本内的全部代码
      var moduleVariable = "Accessible only from withing this module";
      dump("myExtension.Module initialization " + getCurrentURI() + "\n");
  }
});

通过利用with语句，我们可以方便的访问所有的库函数，就像访问全局变量一样。

既然我们要访问全局对象，还可以像下面这样利用theApp这个快捷方式（尤其是命名空间名字太长的时候）

myExtension.ns(function() {
  with(myExtension.LIB) {
      // TODO: 脚本内的全部代码
      theApp.sharedValue = "A new shared property";
  }
});

下面这个图是从UML的角度来纵观整个架构。

大家可以在这里下载本文提到的演示扩展。

有趣的JavaScript数组

2009-01-31T11:33:00.006+08:00

本文是Rick Strahl在使用JavaScript数组上的经验之谈，在一些细微的地方介绍了JavaScript在处理数组上，相对于其他开发语言的不同之处，有些可能是我们自己想当然的事情，但实际上不是那么回事，呵呵。具体涉及到JavaScript数组初始化、length、扩展属性等。

【原文】Javascript Array Fun
【作者】Rick Strahl
【译文】http://cuimingda.com/2009/01/javascript-array-fun.html
【译者】明达

以下是对原文的翻译：

Josh在我之前的一篇帖子中留下了一条评论，指出在CSS property watcher component中存在一些小错误，这是一个jQuery插件，将CSS属性保存在数组中，并且跟踪这些值的变化，当发现CSS属性值发生变化时，会抛出一个事件，用户可以在事件中做出相应的处理。

我的错误出在如何定义数组上：

var data = {
  props: props.split(","),
  func: func,
  vals: [props.split(",").length],
  itvlId: itId
};

这段代码是要建立一个特定长度的数组，但显然结果和我预想的不大一样。实际上这个数组只包含一个元素，就是length的值，而要实现初始化数组的目标，正确的做法应该是下面这个样子：

vals: new Array(props.split(",").length)

可为什么我以前定义的方法错了，那个插件却能正常运行呢？因为JavaScript可以根据赋值动态的建立数组，而不需要预先进行初始化，所以就算定义方法错了，也能正常运行。

$.each(data.props, function(i) { data.vals[i] = el.css(data.props[i]); });

这段代码遍历了props数组，并且通过对vals数组对应索引赋值，动态的建立了一个新数组。

JavaScript的数组可以根据所赋的值自动调整大小，比如下面这个例子：

var ar = []
ar[2] = 1;
debugger;

下面的结果是Firebug调试界面的截图，可以看到数组中有三个元素。

这个数组的长度是3，就像一个经过初始化的数组一样。所有没有赋值的数组对象，都将被定义为undefined。

JavaScript可以自动重新调整数组的大小，这真是太棒了，但也许预先设置一个固定的大小，可以避免数组内部频繁的调整大小。对已有的元素进行赋值，肯定要比每次赋值前重新调整大小要快的多。

这种自动调整大小的机制，更容易出现越界数组（out of bounds array），而且更难发现。所以要加倍注意类似的情况。

关于动态数组，下面介绍的这个情况也很有意思：

var ar = []
ar["test"] = 4;
ar[3] = 1;
var len = ar.length;
debugger;

让我们来猜一猜，此时此刻这个数组的大小应该是多少呢？

这段代码建立了一个数组，其中包含数值索引和字符串索引，而且这可以正常工作，无论你使用ar[3]还是ar["test"]都可以得到预期的结果。下面的截图展示了在Firebug中的调试结果：

请注意，数组的长度是4，而此时数组中包含4个数值索引的元素和一个字符串索引的元素。也就是说，字符串索引的元素是不计入数组长度的计算范围的。而取而代之的，字符串索引器实际上作为数组对象的一个扩展属性而存在。Visual Studio JavaScript Debugger更加准确的证明了这点：

从这张截图可以看出，test已经成为array对象的一个属性，和length属性的性质是一模一样的。

本文没有提到什么新内容，但如果不了解JavaScript在处理数组上的细微差别，就会出现类似我之前所犯下的错误。上面提到的内容都是我在实际开发过程中曾经遇到过的问题，借这个机会记录下来，就当是给自己的备忘录了，如果恰好对你有帮助，将不胜荣幸。

Firebug发布1.3.1b1和1.4.0a12等四个版本

2009-01-29T20:37:00.004+08:00

Firebug现在已经成了Web开发的必备工具，尤其是在Firefox浏览器上。这次同时发布了四个版本，其中有两个是带错误跟踪的，主要用于Firebug本身的调试。Firebug现在有两个分支，老版本1.3一直可以稳定使用，1.4正在全新开发，如果不介意没有中文语言包，个人还是比较倾向于用最新的，呵呵。

【原文标题】Firebug Releases: 1.3.1b1 and 1.4.0a12
【原文作者】jjb
【本文地址】http://cuimingda.com/2009/01/firebug-131b1-and-140a12-released.html

以下是对原文的翻译：

getfirebug.com上今天发布了Firebug的四个最新版本：

第一个是Firebug 1.3.1b1。这个版本修复了若干在addons.mozilla.org上发布1.3.0以来发现的缺陷，同时也支持了更多的语言包。修复的具体缺陷包括命令行的范围（the scope of the command line）、console变量和命令行有时会无效的问题（various console or command line not ready problems）、命令行按Tab自动完成输入（tab completion in the command line）以及文件锁定（file locking）等。

第二个是Firebug 1.3X.1b1。和1.3.1b1一样，但是多了FBTrace模块，该模块可以对Firebug进行诊断，判断出错的原因。

第三个是1.4.0a12。包括所有1.3.1b1已经修复的漏洞，还有一些1.3这个版本分支所不支持的功能的漏洞。另外，这个版本增加了跨文件搜索的预览版，由多才的kpdecker开发；还有就是，我们可能不得不将部分界面修改为1.4b1以前的样子。

第四个是1.4X.0a12，和1.4.0a12保持一致，只是多了FBTrace模块。

Firebug 1.3.1这个版本主要面向那些受困于现有缺陷的用户，我们迫切需要得到大家的反馈，以便知道是否解决了一些没有被测试到的问题，但实际上已经在这个版本中解决了。

Firebug 1.4.0这个版本的目标是要成为Firebug最棒的版本，我们同时希望这个版本能够弥补那个不幸的a11所犯下的一大堆初错误。

用JavaScript判断IE浏览器，只需要13个字节！

2009-01-29T18:53:00.008+08:00

在中国，用户最多的浏览器当属Microsoft的Internet Explorer浏览器，虽然现在呈现下滑趋势。同其他浏览器开发厂商一样，微软在ECMA-262的基础上为JScript增加了很多特性，这些特性只有在IE下才有效。而我们为了保证这些特殊的代码只在IE下执行，就必须正确的判断出当前用户的浏览器是不是IE，本文就介绍了三种方法，最小的一个才13个字节。

【原文标题】32 bytes, ehr ... 9, to know if your browser is IE
【原文作者】Andrea Giammarchi
【本文地址】http://cuimingda.com/2009/01/how-to-know-if-your-browser-is-ie.html

以下是对原文的翻译：

更新：答案更新为13字节版，非常感谢Gareth Heyes赢得了这次竞赛

if("\v"=="v") // 这个判断真的只有在IE下才为真，包括IE 8。

我以前的办法，32字节版本：

try{IE=window=!1}catch(e){IE=!0}

用很有效，不是么？这个技巧通常应用在类库（library/hack proof）中。但如果你认为使用execScript来做判断已经足够了，那你就要来考虑一下这种情况：

top["execScript"]=null

当然还要考虑到类库为其他浏览器也实现了execScript方法。

以下为译者的注释和补充说明：

在Ajaxian.com上列举的通过execScript判断IE的方法：

IE=top.execScript?1:0

在Ajaxian上的回复，提到了Microsoft的《JScript Deviations from ES3》（这个文档列举了JScript对ECMA-262第三版的增强列表），说在这个文档的7.2节提到了本文说的方法，我下载了这个文档，但第七章还没有编写完，可能找到不是一个版本吧。中国还是IE的用户比较多，所以推荐大家仔细看一下这篇文档，两个下载地址，一个是ECMA的，一个是Microsoft，链接在页面上很好找，PDF格式。
* http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs
* http://blogs.msdn.com/jscript/archive/2007/10/29/ecmascript-3-and-beyond.aspx

Ajaxian.com转载了这篇文章，下面这个是具体的文章地址：
http://ajaxian.com/archives/ievv

解决Blogger下jstiming和_WidgetManager未定义的错误

2009-01-28T21:02:00.007+08:00

昨天晚上精简Blogger的模板，不经意间发现Firebug报出两个错误，百思不得其解。一个提示window.jstiming未定义，另外一个提示_WidgetManager未定义。看名字应该都是Blogger自动添加的代码，跟自己修改的部分没有关系啊，于是找了一个默认的模板，一段一段替换成自己的代码，最后总算是让我找到了，虽然找得比较郁闷。

【本文地址】http://cuimingda.com/2009/01/blogger-jstiming-undefined.html

先看一下异常信息，在Firefox 3和Internet Explorer 7下都会提示：
window.jstiming is undefined
_WidgetManager is undefined

问题的症结是Blogger对代码进行了升级，在下面这个标记里自动添加了JavaScript脚本：

<b:include data='blog' name='all-head-content'/>

具体的脚本从Firefox 3上看是下面这个样子：

(function() {
var a = window;
function b() {
    this.t = {};
    this.tick = function(e, f) {
        this.t[e] = [(new Date).getTime(), f]
    };
    this.tick("start")
}
var c = new b;
a.jstiming = {
    Timer: b,
    load: c
};
if (a.external && a.external.pageT) a.jstiming.pt = a.external.pageT;
var d = false;
function g() {
    if (!d) {
        d = true;
        a.jstiming.load.tick("firstScrollTime")
    }
}
a.addEventListener ? a.addEventListener("scroll", g, false) : a.attachEvent("onscroll", g);
})();

而由于我把all-head-content给替换了，自然就没有更新这段代码，出错也就是理所应当的了。先不说这段脚本是做什么的，就冲着偷偷的插在我的博客中这点，就值得鄙视。问题的解决办法也很简单，把all-head-content加回来就可以了，这里需要注意的是，如果只是把那段脚本加过来，需要注意处理“&”，而且既然blogger在这里加了代码，肯定会更新的，所以这种方式也就不建议了。

SitePoint上线新版JavaScript参考手册

2009-01-28T19:07:00.004+08:00

SitePoint是一个面向Web开发者和Web设计者的网站，这里聚集了非常多的Web领域的高手，第一时间为大家提供最新的各类技术文章。 SitePoint的参考手册对于Web领域的朋友，是非常方便的助手，现在推出了新版，增加了JavaScript的内容，更加充实了。可以在一个搜索框内查询HTML、CSS和JavaScript的内容，但JavaScript貌似还不包括BOM的部分。

【原文标题】Introducing the NEW SitePoint CSS, HTML & JavaScript Online References
【原文作者】Shayne Tilley

SitePoint的HTML和CSS在线参考手册已经稳定运行很长时间了，而且已经成为了全世界Web开发者和Web设计者的一个重要的免费资料来源。

图例：新版参考手册搜索框

我们非常荣幸的宣布，全新的SitePoint参考手册网站已经与大家见面了。。。而且。。。备受期待的JavaScript参考手册也在这次一同发布了第一个版本。

无论是外观还是感觉，都已经被完全替换为一个崭新的系统，更加方便大家阅读，增加了更多的互动示例，优化了导航和页面布局，还有很多就不再这里透漏了，等着大家自己去发现。

图例：JavaScript参考手册的示例页面

所有最新、最棒的信息现在已经可以在参考手册中找到了，第一阶段的JavaScript部分，主要是由Jedi James(Brothercake)写的，DOM核心参考手册部分是由Edwards完成的。

还是让这个新网站自己来证明实力吧，去看看吧，好好体验一下，别忘了告诉我们你的想法哟！

图例：DOM异常对象树型表

如何提升JavaScript的运行速度（函数篇）

2009-01-24T23:24:00.007+08:00

这篇是Nicholas讨论如果防止脚本失控的第二篇，主要讨论了如何重构嵌套循环、递归，以及那些在函数内部同时执行很多子操作的函数。基本的思想和上一节trunk()那个例子一致，如果几个操作没有特定的执行顺序，而且互相不是依赖关系，我们就可以通过异步调用的方式加以执行，不止可以减少执行的次数，还可以防止脚本失控。本文还介绍了通过memoization技术取代递归的方法。

【原文标题】Speed up your JavaScript, Part 2
【原文作者】Nicholas C. Zakas

以下是对原文的翻译：

上周我在《too much happening in a loop》（译文）这篇文章中介绍了JavaScript运行时间过长的第一个原因。相似的情况有时也出现在函数的定义上，函数也可能因为使用不当而过载使用。通常情况是函数内包含了过多的循环（不是在循环中执行了过多的内容），太多的递归，或者只不过是太多不相干但又要一起执行的操作。

太多的循环经常是以嵌套的形式出现，这种代码会一直占用JavaScript引擎直至循环结束。这方面有一个非常著名的例子，就是使用冒泡算法排序。由于JavaScript有内置的sort()方法，我们没有必要使用这种方式进行排序，但我们可以借助这个算法理解嵌套循环占用资源的症结所在，从而避免类似情况的发生。下面是一个在JavaScript使用冒泡排序法的典型例子：

function bubbleSort(items) {
for (var i = items.length - 1; i >= 0; i--) {
   for (var j = i; j >= 0; j--) {
       if (items[j] < items[j - 1]) {
           var temp = items[j];
           items[j] = items[j - 1];
           items[j - 1] = temp;
       }
   }
}
}

回忆一下你在学校学习的计算机知识，你可能记得冒泡排序法是效率最低的排序算法之一，原因是对于一个包含n个元素的数组，必须要进行n的平方次的循环操作。如果数组中的元素数非常大，那么这个操作会持续很长时间。内循环的操作很简单，只是负责比较和交换数值，导致问题的最大原因在于循环执行的次数。这会导致浏览器运行异常，潜在的直接结果就是那个脚本失控的警告对话框。

几年前，Yahoo的研究员Julien Lecomte写了一篇题为《Running CPU Intensive JavaScript Computations in a Web Browser》的文章，在这篇文章中作者阐述了如何将很大的javaScript操作分解成若干小部分。其中一个例子就是将冒泡排序法分解成多个步骤，每个步骤只遍历一次数组。我对他的代码做了改进，但方法的思路还是一样的：

function bubbleSort(array, onComplete) {
var pos = 0; (function() {
   var j, value;
   for (j = array.length; j > pos; j--) {
       if (array[j] < array[j - 1]) {
           value = data[j];
           data[j] = data[j - 1];
           data[j - 1] = value;
       }
   }
   pos++;
   if (pos < array.length) {
       setTimeout(arguments.callee, 10);
   } else {
       onComplete();
   }
})();
}

这个函数借助一个异步管理器来实现了冒泡算法，在每次遍历数组以前暂停一下。onComplete()函数会在数组排序完成后触发，提示用户数据已经准备好。bubbleSort()函数使用了和chunk()函数一样的基本技术（参考我的上一篇帖子），将行为包装在一个匿名函数中，将 arguments.callee传递给setTimeout()以达到重复操作的目的，直至排序完成。如果你要将嵌套的循环拆解成若干个小步骤，以达到解放浏览器的目的，这个函数提供了不错的指导意见。

相似的问题还包括过多的递归。每个额外的递归调用都会占用更多的内存，从而减慢浏览器的运行。恼人的是，你可能在浏览器发出脚本失控警告之前，就耗尽了系统的内存，导致浏览器处于停止响应的状态。Crockford在博客上曾经对这个问题进行过深入的讨论。他当时使用的例子，就是用递归生成一个斐波那契数列。

function fibonacci(n) {
return n < 2 ? n: fibonacci(n - 1) + fibonacci(n - 2);
};

按照Crockford的说法，执行fibonacci(40)这条语句将重复调用自身331160280次。避免使用递归的方案之一就是使用memoization技术，这项技术可以获取上一次调用的执行结果。Crockford介绍了下面这个函数，可以为处理数值的函数增加这项功能：

function memoizer(memo, fundamental) {
var shell = function (n) {
   var result = memo[n];
   if (typeof result !== 'number') {
       result = fundamental(shell, n);
       memo[n] = result;
   }
   return result;
};
return shell;
};

他接下来将这个函数应用在斐波那契数列生成器上：

var fibonacci = memoizer([0, 1],
function(recur, n) {
  return recur(n - 1) + recur(n - 2);
});

这时如果我们再次调用fibonacci(40)，只会重复调用40次，和原来相比提高得非常多。memoization的原理，概括起来就一句话，同样的结果，你没有必要计算两次。如果一个结果你可能会再次使用，把这个结果保存起来，总比重新计算一次来的快。

最后一个可能让函数执行缓慢的原因，就是我们之前提到过的，函数里面执行了太多的内容，通常是因为使用了类似下面的开发模式：

function doAlot() {
  doSomething();
  doSomethingElse();
  doOneMoreThing();
}

在这里要执行三个不同的函数，请注意，无论是哪个函数，在执行过程中都不依赖其他的函数，他们在本质是相对独立的，只是需要在一个特定时间逐一执行而已。同样，你可以使用类似chunk()的方法来执行一系列函数，而不会导致锁定浏览器。

function schedule(functions, context) {
setTimeout(function() {
   var process = functions.shift();
   process.call(context);
   if (functions.length > 0) {
       setTimeout(arguments.callee, 100);
   }
},
100);
}

schedule函数有两个参数，一个是包含要执行函数的数组，另外一个是标明this所属的上下文对象。函数数组以队列方式实现，Timer事件每次触发的时候，都会将队列最前面的函数取出并执行，这个函数可以通过下面的方式执行一系列函数：

schedule([doSomething, doSomethingElse, doOneMoreThing], window);

很希望各个JavaScript的类库都增加类似这样的进程处理函数。YUI在3.0时就已经引入了Queue对象，可以通过timer连续调用一组函数。

无论现有的技术可以帮助我们将复杂的进程拆分到什么程度，对于开发者来说，使用这种方法来理解并确定脚本失控的瓶颈是非常重要的。无论是太多的循环、递归还是其他的什么，你现在应该知道如果处理类似的情况。但要记住，这里提到的技术和函数只是起到抛砖引玉的作用，在实际的应用中，你应该对它们加以改进，这样才能发挥更大的作用。

借助OCR和神经网络，用JavaScript识别验证码

2009-01-24T19:40:00.005+08:00

以前在写runrunrob的时候，研究过用JavaScript识别验证码，无论是找到的资料还是自己的结论，最后都说明对于JavaScript来说，这是一个不可能完成的任务，但当我看完了这篇文章以后，眼睛顿时一亮，迫不及待想把这篇文章推荐给大家。JavaScript、OCR、神经网络、验证码和Canvas，在一个脚本中有机的结合在了一起，也许文中提到的那个验证码太简单了，但这是一个不错的开头，不是么？

【原文标题】OCR and Neural Nets in JavaScript
【原文作者】John Resig

昨天发现的了一段非常令人惊奇的JavaScript代码，是由ShaunF编写的automatically solves captchas，一个专门应用在Megaupload网站的Greasemonkey脚本。如果你要亲自尝试一下，可以先看看这个演示。而这个脚本的作用，正如名字所示，可以识别这个网站的验证码。

现在，这个网站的验证码已经不是个什么难题了。（实际上，这是一个本来设计的就不怎么好的验证码，下面会给出一些例子）

对于这段脚本，我们有很多值得注意的事情：

1. Canvas可以将图片嵌入到画布上，而getImageData函数可以从画布上获取验证码的像素数据。
2. 这个脚本完全用JavaScript编写了一套神经网络的实现。
3. 通过Canvas从图片获取的像素数据，被传入神经网络，通过OCR技术来获取图片中所表示的真实字符。

如果我们翻开源代码，就会发现这个脚本究竟是如何实现的，我们也可以领会这个验证码究竟是如何实现的。就像我之前提到的，这个验证码设计的本身就不好，只有3个字母，而且还用不同的颜色区分，只包含26个字母，最主要的，他们始终是同一字体。

第一个步骤很明确：把验证码的像素图像复制到Canvas中，并且转换为灰度模式。

function convert_grey(image_data) {
  for (var x = 0; x < image_data.width; x++) {
      for (var y = 0; y < image_data.height; y++) {
          var i = x * 4 + y * 4 * image_data.width;
          var luma = Math.floor(image_data.data[i] * 299 / 1000 + image_data.data[i + 1] * 587 / 1000 + image_data.data[i + 2] * 114 / 1000);
          image_data.data[i] = luma;
          image_data.data[i + 1] = luma;
          image_data.data[i + 2] = luma;
          image_data.data[i + 3] = 255;
      }
  }
}

接下来Canvas被分解成3个独立的像素矩阵，每个矩阵都包含一个字母。（按道理来说，这是非常容易的事情。每个字母都由不同颜色组成，可以直接用颜色区分不同的字母）

filter(image_data[0], 105);
filter(image_data[1], 120);
filter(image_data[2], 135);
function filter(image_data, colour) {
  for (var x = 0; x < image_data.width; x++) {
      for (var y = 0; y < image_data.height; y++) {
          var i = x * 4 + y * 4 * image_data.width; // Turn all the pixels of the certain colour to white
          if (image_data.data[i] == colour) {
              image_data.data[i] = 255;
              image_data.data[i + 1] = 255;
              image_data.data[i + 2] = 255; // Everything else to black
          } else {
              image_data.data[i] = 0;
              image_data.data[i + 1] = 0;
              image_data.data[i + 2] = 0;
          }
      }
  }
}

然后最后，为了得到一个清晰的字母，我们还要把那些不相干的噪声像素从图片上去除。具体的方法，先要找到那些前面或者后面被黑色（之前没有匹配的像素）包裹的白色像素（之前已经匹配的像素），如果找到这样的像素，就简单的把它门直接删除。

var i = x * 4 + y * 4 * image_data.width;
var above = x * 4 + (y - 1) * 4 * image_data.width;
var below = x * 4 + (y + 1) * 4 * image_data.width;
if (image_data.data[i] == 255 && image_data.data[above] == 0 && image_data.data[below] == 0) {
  image_data.data[i] = 0;
  image_data.data[i + 1] = 0;
  image_data.data[i + 2] = 0;
}

我们现在已经得到了非常接近的图形，但还不够明确。脚本接下来会检测出这些形状的边缘，具体的是要找到图形中最上面、最下面、最左面和最右面的像素，然后把图形转换成矩形，最后将矩形的数据转换为一个20*25的矩阵。

cropped_canvas.getContext("2d").fillRect(0, 0, 20, 25);
var edges = find_edges(image_data[i]);
cropped_canvas.getContext("2d").drawImage(canvas, edges[0], edges[1], edges[2] - edges[0], edges[3] - edges[1], 0, 0, edges[2] - edges[0], edges[3] - edges[1]);
image_data[i] = cropped_canvas.getContext("2d").getImageData(0, 0, cropped_canvas.width, cropped_canvas.height);

最后，我们得到了什么？一个20*25的矩阵，里面包含着一个绘制着黑白两种颜色像素的矩形，真是令人兴奋啊。

矩形被进一步的缩小。一些关键位置的像素以接受体（receptors）的状态被提取出来，这些接受体最终会被传入神经网络。举例而言，某个接受体具体对应的可能是位于9*6位置像素的状态，有像素或者没有像素。脚本会提取一系列这样的状态（远少于对 20*25矩阵整个计算的次数 - 只提取64种状态），并将这些状态传入神经网络。

你可能要问，为什么不直接对像素进行比较？为什么还要和神经网络扯在一起？问题的关键在于，我们要去掉那些模棱两可的情况。如果你试过了之前提到的演示就会发现，直接进行像素比较比通过神经网络比较，更容易出现偶尔判断错误的情况。但我们必须承认，对于大部分用户来说，直接的像素比较应该已经足够了。

下一个步骤就是尝试猜字母了。神经网络中传入了64个布尔值（由其中的一个字母图像获取而来），同时包含一系列预先计算好的数据。神经网络的理念之一，就是我们首先要知道希望得到什么结果。很可能脚本的作者反复的运行脚本，并收集了一系列最佳评分，这些评分可能包含这样的含义：“如果9*6位置存在像素，那么有58%的可能是字母A”。

当神经网络对验证码中一个字母对应的64个布尔值进行计算以后，和一个预先计算好的字母表相比较，然后为和每个字母的匹配都给出一个分数。（最后的结果可能类似：98%的可能是字母A，36%的可能是字母B等）

当对验证码中的三个字母都经过了计算以后，最终的结果也就出来了。确定的是，肯定不是100%精确的（不知道如果在开始的时候不将字母转换成矩形，是不是可以提高评分的精度），但这已经相当好了，至少对于当前的用途来说。而且所有的操作都是在浏览器中，通过基于标准的客户端技术实现的，这不是很神奇么？

补充说明一下，这个脚本应该算是一个特例吧，这项技术可能会应用在更多设计不良的验证码上，但对于更多设计复杂的验证码来说，就有点力不从心了（尤其是这种基于客户端的分析）。

我非常期待能有更多人从这个项目中得到灵感，开发出更多有意思的东西来，它的潜力太巨大了。

如何提升JavaScript的运行速度（循环篇）

2009-01-24T00:08:00.006+08:00

根据Nicholas的说法，有四种代码会拖慢脚本的运行，并最终导致脚本失控。分别是次数过多的同步循环、庞大的函数体、不恰当的递归和不合理的DOM调用。这篇着重讲第一个原因。最后给出了一个开发模式，替换传统的循环结构，可以完全避免脚本失控的状况发生。

【原文标题】Speed up your JavaScript, Part 1
【原文作者】Nicholas C. Zakas

在我上一篇帖子（译文）中，谈到了各个浏览器究竟会在什么情况下弹出脚本失控提示，对于Internet Explorer来说，当浏览器执行了数量过多的语句时就会停止执行脚本，而其他的浏览器，则是持续执行脚本超过一定时间的时候就会给出提示。而我们要探讨的核心问题，不是这些浏览器如果探测失控的脚本，而是我们如何才可以让脚本运行的更快一些，从而避免这些警告。

脚本失控基本上有以下四个方面的原因：
1. 在循环中执行了太多的操作。
2. 臃肿的函数体
3. 过多的递归
4. 过多的DOM调用

在这篇帖子中，我将会把重点放到第一条上：循环中的过多操作。循环的操作是同步进行的，所以执行一个循环所花费的时间完全取决于循环的次数。因此有两种情况会导致循环执行的时间过长，并直接导致锁定浏览器。一是循环体中包含了太多的操作，二是循环的次数过多。这两种情况都能直接导致锁定浏览器，并显示脚本失控的提示。

解决这个问题的诀窍就是用下面这两个问题来评估每个循环：
1. 这个循环必须要同步执行么？
2. 循环里面的数据，必须要按顺序执行么？

如果两个问题的答案都是否定的话，你就可以选择将循环里的操作进行分解。关键是要根据代码的具体环境确定上面两个问题的答案。一个典型的循环可能像下面这个样子：

for(var i=0; i < items.length; i++){
   process(items[i]);
}

乍一看这个循环并没有太大的问题，是不是会运行很长时间完全取决于循环的次数。如果紧接循环后没有其他代码在执行的时候需要依赖于循环的结果，那么对于第一个问题的答案就是“不”。你还可以发现，循环每次只处理一个数值，而且不依赖于上一次循环的结果，所以对于第二个问题的答案同样也是否定的。这就意味着，循环可以通过某种方式进行拆解，不会导致锁定浏览器而显示脚本失控的提示。

在《Professional JavaScript, Second Edition》这本书中，对于那些执行次数非常巨大的虚幻，我推荐使用下面的方式来处理：

function chunk(array, process, context){
   setTimeout(function(){
       var item = array.shift();
       process.call(context, item);

       if (array.length > 0){
           setTimeout(arguments.callee, 100);
       }
   }, 100);
}

chunk()函数的用途就是将一个数组分成小块处理（这也是名字的由来），我们可以传递三个参数。要处理的数组对象、处理函数以及一个可选的上下文变量，用于设置process()函数中对应的this对象。第一个timer用于处理操作之间的延时（这里设置为100毫秒，大家可以根据实际需要自行修改）。每次执行这个函数，都会将数组中的第一个对象取出，并传给process()函数进行操作，如果这时process()中还有未处理完的对象，另外一个timer就会启动，用于重复等待。上面提到的循环，可以通过下面的方法使用这个函数：

chunk(items, process);

需要注意的是，在这里数组采用了队列（queue）的形式，而且在循环的过程中，每次都会发生修改。如果你要修改数组的原始状态，这里介绍两种途径：一种是通过concat()函数，在传递之前，建立一个当前数组的副本：

chunk(items.concat(), process);

另外一种选择是直接修改chunk()函数，直接在函数内部进行修改：

function chunk(array, process, context){
   var items = array.concat();   //clone the array
   setTimeout(function(){
       var item = items.shift();
       process.call(context, item);

       if (items.length > 0){
           setTimeout(arguments.callee, 100);
       }
   }, 100);
}

注意这种方法要比只保存一个索引安全的多，因为数组的内容在下次计时器生效之前可能会发生变化。

这里提到的chunk()函数，只是优化循环性能的一个起点。你可以根据需要不断改进它，让它拥有更多的功能。比如说，在数组中所有对象都处理完成以后，可以增加一个函数回调。无论你是否会按照这种方式对函数进行修改，这只是一种JavaScript的代码开发模式，可以帮助优化数组的处理性能，还可以避免那个脚本失控的警告。

浏览器根据什么来判定脚本失控？

2009-01-23T21:07:00.008+08:00

在Web开发的时候，经常会遇到的一种情况就是浏览器提示脚本运行时间过长，停止还是继续，无论你选择什么，相信你都会想尽一切办法让这个对话框远离你的用户们。可你是否知道，这些不同的浏览器究竟是如何判断，哪些脚本处于“失控”状态么？本文作者，就从Internet Explorer、Firefox、Safari、Chrome和Opera五种浏览器，分析了这个情况出现的原因。

【原文标题】What determines that a script is long-running?
【原文作者】Nicholas C. Zakas

以下是对原文的翻译：

Web开发者经常遇到并必须及时处理的问题就是“提示脚本运行时间过长的提示框”（或者称为“失控脚本提示”），这些令人讨厌的对话框会在你的脚本执行时间过长的时候出现。对于Web开发者的基本准则就是，无论什么时候，都不要让用户看到这些对话框，因为这会给人一种代码缺乏结构化的印象，更简单的说，你的代码负担太重了。

用Brendan Eich（JavaScript的发明人）的话来讲，如果JavaScript运行的时间需要用秒来计算，一定是什么地方搞错了。我个人可以忍受的上限可能更小一些，不论什么脚本，在任何时间、任何浏览器上执行，都不应该超过100毫秒。如果实际执行的时间长于这个底限，一定要将进程分解成若干更小的代码段。

另外，其实很少有人真正意识到究竟是什么原因导致脚本在不同的浏览器中运行时间过长，连我自己都没有深究过。所以我决定坐下来好好研究一下，我们究竟会在什么情况才会看到那个讨厌的对话框。判断脚本是否失控，无外乎就两种方法。一种是根据执行了多少条语句，一种是判断脚本执行花费的时间。各个浏览器判断脚本失控的具体方法会有略微的不同。

Internet Explorer

Internet Explorer判断一个脚本是否失控，主要通过JScript引擎执行语句的总数来判断。默认情况下，这个上限是500万条语句，这个值是可以通过注册表修改的。当你的脚本执行的语句数量超过这个限制，你就会看到下面的窗口。

这个对话框提示：“这个页面上有一段脚本导致Internet Explorer运行缓慢，如果你继续运行，你的计算机可能会变为无响应状态”。要不是追求技术上的准确性，这样说确实有点过了。对话框有两个选项，要么停止脚本执行，要么允许脚本继续运行。当这个对话框显示的时候，脚本已经被完全停止了。如果你选择继续运行脚本，就会重新计算当前执行的语句数，也就是说，如果这个数值再次达到上限时，你会再次看到这个对话框。

Firefox

Firefox是根据脚本引擎持续执行代码的时间来判断一段脚本是否失控。默认的上限是10秒，可以通过about:config页面来修改这个值。这里需要注意的是，当弹出类似alert的模式对话框的时候，是不计时的。当浏览器执行脚本的时间达到这个上限，Firefox就会显示类似下面的对话框：

Firefox的对话框提示：“这个页面的一段脚本目前运行忙，或者这段脚本已经停止响应。你可以停止执行这段脚本，并在调试器中打开这段脚本，或者保持这段脚本继续运行”。更清楚的描述了遇到的问题，并且没有IE说的那么恐怖。在这个对话框上可以执行三种操作：停止脚本执行、调试脚本或者让脚本继续运行。和Internet Explorer一样，当运行脚本继续运行以后，对持续运行脚本时间的统计就会重置。调试脚本按钮，只有在你安装了Firebug，并在该页面激活了调试的时候才会出现。执行调试脚本操作后，可以显示执行时间过长的代码段的具体位置。

Safari

Safari同样根据脚本引擎持续执行脚本的时间来判断，当我对Webkit的源代码进行反复研究后，发现默认的超时时间是5秒，一旦达到这个上限，就会给出下面的对话框提示：

对话框提示：“在页面url上的脚本让Safari失去响应，你是要继续运行脚本还是终止脚本”。同样的，对于用户来说，也不是什么可怕的提示。在Safari中，可以关闭失控脚本的检测功能。

Chrome

Chrome在跟踪技术上有点狡猾，失控脚本检测功能似乎和tab的事故控制（crash control）关联到一起。我仔细看了源代码，却没有找到具体的限制，但基本确定的是，这个限制是以时间为基础的，估计在10秒左右（要么是5秒，要么是10秒，总要和Safari或者Firefox看齐么）。我正在联系Chrome项目组中的朋友，看看能不能得到确定的信息。尽管如此，如果网页中存在失控的脚本，用户还是会看到下面的对话框：

毫无疑问，Chrome的提示比起其他浏览器来说，显得都更加严重。点击“Wait”按钮，脚本会继续运行，直到达到下一个上限为止，也可以点击“Kill pages”，直接关闭该页面在内存中的所有信息，并用一个空白页取而代之。

Opera

Opera的情况比较有趣：他貌似没有针对失控脚本的相应限制。我运行了几个很长的测试，甚至花了几分钟，而在这个过程中，浏览器一直可以正常响应，这很出我的意料之外。我不是很确定，对于现在的情况来说，这个方法是好是坏，但至少它生效了，不是么？

一些建议

无论你的用户使用什么浏览器，都不应该在任何时候看到类似的提示。在你的网站或者Web应用程序作为产品发布之前，做一些常规的性能测试是非常有必要的。在这方面有很多工具可以加以利用，比如Firebug’s profiler（只支持Firefox）、YUI Profiler （支持全部浏览器）或者Internet Explorer 8’s Profiler。你应该毫不犹豫地将那些执行时间超过100毫秒的脚本找出来，哪怕这些脚本只是在某些浏览器上运行不畅，这些脚本包含了一些需要执行很长时间的代码段，而这些代码应该通过性能检测工具进行重新评估。确保你不是使用Chrome作为测试的底线，因为Chrome在执行JavaScript的速度上比其他浏览器要高出一个数量级（和Firefox 3.1还有最新的WebKit Nightly相当）。最好使用Internet Explorer作为测试的底线，然后再测试其他浏览器，因为无论什么时候，IE的JavaScript引擎都是最慢的，当在IE上修复问题以后，十有八九在其他浏览器上也可以正常运行了。

JavaScript的2008，棒极了！

2009-01-22T20:08:00.027+08:00

2008年，对于JavaScript来说是非常振奋人心的一年，很多高人加入到JavaScript和Web开发的阵营中来，浏览器厂商在技术上互相竞争，渲染引擎和JavaScript解释引擎的性能不断提高，越来越多的人开发出各种基于JavaScript的神奇演示，让更多的人了解JavaScript的魅力所在。这篇是一个小结，也预示着一个更加辉煌的2009的开始。

【原文标题】2008 - A Year of Awesome JavaScript
【原文作者】Jacob Seidelin

如果对JavaScript感兴趣，建议点开文中提到的所有链接，实际试验一下效果，但需要注意的是，一定要使用Firefox 3.1或者其他浏览器的最新版本，如果使用Firefox记得打开tracemonkey，否则有的效果会很慢的，也不要同时打开两个实验窗口，有可能会造成浏览器死机。还有，相当一部分链接需要翻墙。

以下是对原文的翻译：

对于JavaScript来说，2008是伟大的一年，因为有很多牛人加入到了JavaScript、Canvas元素和Web的开发中来。浏览器供应商也在互相竞争，试图在JavaScript的性能方面超越对手，而最大的受益者当然是开发者和最终用户，因为现在可以开发出一些非常棒的东西，而这些东西在以前简直就是不可想象的。下面是一个列表，都是我在整个2008年中关注过，基于JavaScript开发的产品。

游戏

对于JavaScript游戏来说，2008年是非常重要的一年。基于DHTML和Canvas的游戏，在某些方面已经撼动了Flash的霸主地位。很多以前经典的电视游戏已经被通过这种方式移植了，比如：超级玛丽、吃豆人、Breakout、小蜜蜂、炸弹人和T&C Surf Designs等。

另外还有些人，按照自己的想法，对一些传统的游戏进行了扩展，演变出一些新的小游戏，比如：Matt Hackett开发的Spacius、Mark Wilcox开发的Invaders from Mars、VertigoProject开发的RedLine Racing和这个俄罗斯方块的变种版本Tetris game。

我们也找到一些角色扮演类游戏，比如Tombs of Asciiroth，而Andrew Wooldridge开发的CanvasQuest显得更加图形化些，它的Prototype引擎是构建在Pierre Chassaing开发的ProtoRPG基础上的，虽然这些游戏现在还在测试中，而且现在的演示版看起来比较粗糙，但我们有理由相信，有一天他们会完善出一个非常棒的版本出来。

在2008年，也有几个面向JavaScript/DHTML游戏开发的类库面世，其中最抢眼的莫过于GameJS（旁边的截图就是基于这个类库开发的游戏Jetris）和GameQuery了，后者是著名的JavaScript类库jQuery的一个扩展。

最后，我们还要留意一个伟大的游戏DEFENDER of the favicon，这个伟大可不是指尺寸哟。Mathieu 'p01' Henri把上个实际八十年代推出的Defender游戏压缩到了浏览器的favicon图标中，就是那个16*16的png图像，听到这个感觉怎样？神奇么？

演示

现在大部分的浏览器（开发这些浏览器的公司没有叫微软的，IE还不支持）已经支持了Canvas元素。这就意味着当我们以后要在浏览器中创建动态的图片时，将会有更多的选择。当然也会有更多的人，会乐此不疲的展示他们创建动态图片这项疯狂的技术，呵呵。其中有些人创建了短小精炼的例子，来展示Canvas强大的能力。另外一些人走的更远，比如Matt Westcott就建立了一个反社会的演示，来讽刺现在流行的社会网络，而这个演示完全是通过一个小工具制作的。

还有一些人，包括Mathieu 'p01' Henri在内，一整年都在制作一些非常短小精悍的内容，而这些小代码可以做出非常棒的效果，比如这几个：Rubber effect、Tunnex、Mars。每个演示，所有代码加起来，都不超过256字节！

如果这还不过瘾，可以到Ozone Asylum见识一下，Mathieu Henri在这里通过Canvas元素创建了很多20行的小视频，每一个都可以为你带来非常强烈的视觉效果，比如：Dynamic Hypnoglow、Twinkle和Hypno Trip Down the Fractal Rug。这些小视频同样给很多人带来了新的灵感，创作出了一些更好的效果，比如：colliding balls、3D cube effect和dynamically generated BMP flames等。

在Asylum上，大家甚至开发出了20行JavaScript代码写成的游戏，从Lunar Lander到Boulderdash clone，甚至还有一个homage to Wolfenstein 3D。

三维

到目前为止，尽管Mozilla和Opera的开发团队都在尝试启用硬件加速功能，但canvas元素还是只能支持2D图像。但这决不意味着现在不能生成3D图像。我们从类似basic 3D cubes和texturing experiments这样的例子中完全可以得出JavaScript/Canvas 3D engines已经可以使用的结论。

我们还可以留意那些基于Wii Opera SDK（这东西不止应用在Opera或者Wii上）开发的效果，当然还有Nihilogic编写的3D演示。

模拟器

JavaScript的性能越来越好，这已经是一个不争的事实，一个典型的证据就是我们现在甚至可以在浏览器上模拟其他系统。Matt Westcott（前面提到过他写的一个演示）在这里又给大家带来了一个惊喜：JSSPeccy，一个ZX Spectrum模拟器，这东西棒极了。

James Urquhart也做了一些尝试，建立了一个SCUMM interpreter的雏形，也许用他现在还不能玩疯狂时代（Day of the Tentacle）或者疯狂大楼（Maniac Mansion），但至少可以让你看到一些开放任务（OpenQuest）。

我个人的最爱则是António Afonso开发的JavaScript AGI interpreter，AGI是Sierra在冒险游戏的鼎盛时期所使用的系统，当António开发出这个可以用的模拟器后，我简直就是爱不释手。

图像

John Resig开发的JavaScript的进程接口：Processing.js，可能是这一年中给我印象最深刻的创造之一了，尤其是那数以百计，绚丽夺目的演示。Aza Raskin开发的Algorithm Ink也有着类似的功能，这是一个JavaScript/Canvas接口，基于各种规则和命令建立图像。当然除了这些还有很多，比如Eitan Suez很喜欢Turtle，一个Pascal下的图形开发工具，于是他用JavaScript重写了这个工具：TurtleJS。

还有一些数学偏执狂，使用JavaScript实现了一些碎片效果。首先是p01用137个字节的DHTML绘制了一幅Mandelbrot set，这段代码引发了一个小竞赛，有人写了一个不到128字节的版本，最终胜出的是111字节版本。Oliver Hunt建立了一个更漂亮的图形版本，我也做了一个，Russ Hall甚至做了一个完整的演示版。（译者注：这里需要相当的数学知识，可以参考wikipedia的说明，否则就只能感叹效果的华丽和字节的精简了）

音频

在HTML5正式支持音频元素之前，大部分人都是使用基于Flash音频的方式实现类似的功能，但这不意味着是我们的唯一选择，我们可以使用JavaScript做出各种稀奇古怪的声音。比如说，可以看看Cameron写的JS-909 drum machine，当然这东西依赖于Quicktime，但就算这样也很棒，不是么？

或者我们可以动态生成并播放WAV文件，就像sk89q写的那样，听得同时，我们还可以再生成点MIDI玩玩。

拾遗

除了图像和音频文件，我们还可以生成其他类型的文件。用一个短小精悍的类库生成ZIP文件，这个主意听起来怎么样呢？

你认为CSS现在都可以做什么？是不是只有设置字体或者排列div？答案当然是否定的，至少Román Cortés就像我们展示了一张完全用CSS制作的荷马·辛普森照片，只要你的CSS基础足够强，也可以做一张哟。

Ernest Delgado将我写的Mario Kart演示和OpenStreetMap结合在了一起，衍生出一个新的非常棒的演示，类似于汽车上的GPS导航系统。

最后，向你推荐Cubescape，一个漂亮有趣的玩具。你可以通过通过各种颜色的小方块，绘制出一幅漂亮的风景来，一个消磨时间的好办法。

这篇文章难免会有一些遗漏，我会在Nihilogi不断做些修补，所以记得定期看看这里，确定你没有遗漏什么。祝愿2009年会像2008年一样精彩，其实我真找不出什么2009年不会更好的论据。

你认为2008年什么最精彩呢？

修复若干漏洞 - jQuery 1.3.1发布

2009-01-22T16:05:00.007+08:00

jQuery 1.3是jQuery的一个很重要的里程碑版本，发布的时候John就说，要在最近发布一个bug修复版本，就是本文提到的1.3.1了，没有功能上的重大改变，只是修复了若干漏洞。

【原文标题】jQuery 1.3.1 Released
【原文作者】John Resig

以下是对原文的翻译：

这个版本是针对jQuery 1.3的漏洞修复版本。你可以在bug tracker上查看具体修复了哪些漏洞。

相对于1.3来说，1.3.1只是做了漏洞修补工作，在功能上没有什么重大改变。如果你想对正在使用的jQuery 1.2.6进行升级，建议直接升级到1.3.1这个版本。

下载

jQuery 最小化版本 (18kb，使用Gzipping压缩)
jQuery 标准版 (114kb)

(再过一会，大家也可以直接到Google Code上直接下载jQuery 1.3.1。)

如果你希望从Subversion repository导出这个版本的完整代码，你可以参照下面的说明，并从下面的地址导出代码：

svn co http://jqueryjs.googlecode.com/svn/tags/1.3.1

一些说明：

有些朋友可能注意到，在1.3的发布日志上，我们没有提到对Firefox 2进行的测试，认为jQuery已经不支持Firefox 2了。这是一个误会，jQuery现在还是支持Firefox 2的，只是我们在这个版本发布之前就已经做了测试，大家可以在下面查看完整的测试用例。

同样的，Safari 2也没有出现在浏览器列表中，但我们确实在1.3发布之前就已经进行了详尽的测试。但有一点很明确，我们正在逐步减少对Safari 2的支持，直至淘汰。这主要是考虑到Safari 2的市场份额已经降至很低的程度，而且实际上已经被三个不同版本的Safari版本所取代（3.0、3.1和3.2），我们认为已经没有必要再针对这个版本的Safari进行测试了。

最后一点说明，有些朋友注意到我们不再提供“packed”版本的jQuery（这个版本的jQuery将通过Dean Edwards’ Packer进行Base62编码转换）。我们有以下几个理由：

* 打包的脚本非常不方便调试，比用gzip压缩的脚本要困难的多。
* 打包的脚本还无法正常的运行在所有平台上（比如在Adobe AIR和Caja-capable环境中就无法正常运行）。
* 但最重要的，对于用户来说，只是想让脚本的尺寸更小一些而已，但大家可不想看到因为减小尺寸而运行的更慢。无论是直觉，还是测试数据，这一点都可以很容易发现，虽然打包的脚本在文件尺寸上要比最小化的脚本小，但是总体的加载时间明显要高于最小化的脚本（因为这其中包括了解压缩的步骤）。对于感兴趣的朋友，可以看看我们对两种脚本加载时间的测试数据。

我们提供下载的jQuery最小化版本，是通过YUI Compressor进行压缩的，这种版本应该是在产品中集成jQuery的最佳形式。

用jQuery插件形式实现的豆瓣小组数据接口

2009-01-21T01:50:00.006+08:00

豆瓣开放了很多API，但是到目前为止，还没有和小组相关的接口，无法获取用户的小组信息，也无法获取的小组内的帖子，由于大家都有很多小组，这就造成开发和小组相关的插件的难度。这个jQuery插件的作用就是获取当前登录用户的小组信息。在豆瓣开放和小组相关的接口之前，估计还是有一点作用的。

添加插件引用：

@require http://cuimingda.googlecode.com/svn/trunk/jquery-plugins/jquery.douban-groups.js

调用：

$.douban.groups({
    max : 10,
    load : function(groups) {
        for(i in groups) {
            // groups[i].id
            // groups[i].members
            // groups[i].isAdmin
            // groups[i].name
            // groups[i].imageUrl
            // groups[i].groupUrl
        }
    }
});

小组对象的属性
id：小组标识，对于豆瓣插件小组，将返回“plugins”。
members：获取小组成员数。
isAdmin：true或者false，该小组是否是自己管理的小组。
name：小组名称，对于豆瓣插件小组，将返回“豆瓣插件”。
imageUrl：小组图片地址，对于豆瓣插件小组，将返回“http://otho.douban.com/icon/g15647-1.jpg”。
groupUrl：小组图片地址，对于豆瓣插件小组，将返回“http://www.douban.com/group/plugin/”。

写在后面
一开始想采用同步的方式获取数据，然后返回一个数组，还是担心会造成阻塞，所以改成异步的，采用重写方法的形式。如果不传参数对象，直接调用，默认的事件会显示在当前页面找到多少个小组对象。

更新：增加max参数，设置返回的最大记录数。

笔记 - 在Ubuntu上安装VirtualBox Guest Additions

2009-01-18T20:50:00.006+08:00

VirtualBox Guest Additions是一个安装在Guest上扩展包，可以在很多方面加强Host和Guest之间的沟通，比如双向剪贴板等。安装过程本身不麻烦，但为了将这个扩展包安装到Ubuntu Server 8.1上，我花了整整两天时间，所以决定把这个教训记录下来，甚至为了写这篇笔记，我又重新装了一遍Ubuntu。

先把这个不麻烦的步骤大概说下，安装好系统以后，在虚拟机窗口菜单选择设备/安装增强功能，就会直接加载一个ISO到虚拟光驱，运行里面的安装程序就可以。

本文假设刚刚装完系统，sources.list只留下了指向安装光盘的源。还有，因为我架设服务器就是为了跑LAMP服务器，所以采用了Minimal Install的方式安装的，有些组件需要再安装，大家的情况可能略有不同。

第一次执行扩展安装程序：
$ sudo mkdir /mnt/cdrom
$ sudo mount /dev/cdrom /mnt/cdrom
$ sudo bash /mnt/cdrom/VBoxLinuxAdditions-x86.run

可能会给出下列提示，因为有一些依赖的组件没有安装：
VirtualBox 2.0.6 Guest Additions installation
Please install GNU make.
Please install the build and header files for your current Linux kernel.
The current kernel version is 2.6.27.7-server
Please install the GNU compiler.
Problems were found which would prevent the Guest Additions from installing.
Please correct these problems and try again.

安装需要的组件，然后再次安装扩展：
$ sudo apt-get install make gcc linux-headers-2.6.27.7-server
$ sudo bash /mnt/cdrom/VBoxLinuxAdditions-x86.run

成功以后的正确提示应该是下面这样的，最后一条错误提示是因为我没有装图形界面，不用管。
VirtualBox 2.0.6 Guest Additions installation
Building the VirtualBox Guest Additions kernel module...
Building the shared folder support kernel module...
Installing the virtualBox Guest Additions...
Could not find X.org or XFree86 on the guest system. The X window drivers will not be installed.

如果提示不是这个，通常是编译扩展包的时候发生错误，我遇到的所有情况都是在VirtualBox 1.6x出现的，Ubuntu Server 8.1的内核是2.6.27，使用这个内核编译VirtualBox 1.6x带的扩展包VBoxLinuxAdditions.run，编译基本上会出错。解决的办法就是将VirtualBox升级到2.x，用新的VBoxLinuxAdditions-x86.run安装就不会有问题了。

这里可能要问，为什么使用VirtualBox 2.0.6，而不是2.1.0。VirtualBox 2.1.0重写了NAT网络连接方式，很明显还不稳定，至少在我这个老本子加XP的组合上，在apt-get update的时候，时断时续，而且经常会导致虚拟机占用100% CPU，所以还是采用之前最近的版本2.0.6比较稳妥。我也就是在1.6x和2.1.0的来回换中，度过了两天的光阴。

我的环境：
* Host - Windows XP SP3
* Guest - Ubuntu Server 8.1
* VirtualBox 2.0.6

笔记 - 在Windows XP下为VirtualBox设置桥接模式

2009-01-18T17:33:00.008+08:00

在Windows XP下，通过VirtualBox安装Ubuntu Server 8.1，默认情况网络连接会被设置为NAT模式，也就是只要Windows XP能正常上网，Ubuntu就可以正常上网。但NAT模式有很多限制，为了能让这个Guest Ubuntu和Windows在局域网中拥有同样的地位，我们需求将网络连接设置为桥接(Host Interface)模式。

顾名思义，桥接也就是在Host和Guest之间通过接口搭建一个小桥（呵呵，不算太牵强附会吧）。这个小桥就是虚拟网卡（VirtualBox TAP Adapter)，建立一个虚拟网卡有以下两种方式：
* 使用命令：VBoxManage createhostif "VM1 external"。
* 在VirtualBox界面相应服务器的设置/网络/Host Infterfaces 中添加。

建立了虚拟网卡以后，在控制面板/网络连接中就能看到这个设备。我们要将这个虚拟网卡对应的连接和现有的网络连接桥接器来，具体先按其中一个，然后按住Ctrl点另外一个，右键点其中任意一个，菜单中就会出现“桥接”项了。操作以后，会多出一个网络桥来。这以后，如果要设置Windows XP的IP地址和DNS，可以直接对网络桥那项进行编辑。

在VirtualBox主界面，进入相应的服务器设置界面，修改网络面板下的“Attached To”为“Host Interface”，在下面的Host Interfaces列表中选择之前建立的虚拟网卡，确认就OK啦。

按道理说，连接网络的工作就完成了，如果获取IP的方式之前设置为DHCP，进入到系统中直接ping一下host或者其他机器看看，应该就连通了。如果ping其他网站不可以，可能是dns没有设置的原因。对于IP和DNS怎样设置，完全就根据大家需要了，可以参考《笔记 - 在Ubuntu下设置IP、DHCP、DNS和主机名》这篇来设置。

备注：这样设置以后，虚拟的那个链接，就是例子中的VM1 External，可能一直处于网线没有连接的状态。

参考资料
* VirtualBox 使用筆記（五）：使用 Host interface 的網路介面
* VirtualBox中linux和windows建立桥接
* Windows XP為Host OS的VirtualBox橋接網路模式設定
* Linux為 Host OS的VirtualBox橋接模式設定

笔记 - 在Ubuntu下设置IP、DHCP、DNS和主机名

2009-01-18T15:54:00.013+08:00

在VirtualBox中安装Ubuntu后，默认是以DHCP方式获取IP，我们可以改成静态的IP地址，同样我们也可以手动设置DNS，这篇是我安装过程中的一篇学习笔记。包含一些和网络配置相关的命令，作为备忘吧。本文的Host是Windows XP SP3，Guest是Ubuntu Server 8.1，虚拟机使用的是VirtualBox 2.0.6。

设置本机的IP地址和子网掩码
$ sudo ifconfig eth0 192.168.0.120 netmask 255.255.255.0

设置网关
$ sudo route add default gw 192.168.0.1

配置网络连接使用DHCP
$ sudo vi /etc/network/interfaces
auto eth0
iface eth0 inet dhcp

配置使用DHCP时的DNS，防止每次重启刷新
$ sudo vi /etc/dhcp3/dhclient.conf
prepend domain-name-servers 208.67.222.222,208.67.220.220;

重新获取DHCP信息
$ sudo dhclient eth0

配置网络连接使用静态IP地址
$ sudo vi /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.0.120
gateway 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255

配置网络连接的DNS
$ sudo vi /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

配置主机名称
sudo hostname newname

每次修改网络配置后，重新启动网络使之生效
$ sudo /etc/init.d/networking restart

参考资料
# Ubuntu服务器入门指南 - 5.联网
# 实验——LINUX常用网络测试命令
# ubuntu 8.10 设置IP及DNS（解决重启需要重设的问题）

笔记 - 在Windows XP下自动启动VirtualBox服务器

2009-01-18T07:03:00.009+08:00

在Windows XP中，要想启动某个虚拟机，正常情况下要先打开VirtualBox，然后在列表中选择一个服务器，然后点开始。但其实如果经常需要这么做，或者想让开机的时候自动启动某个服务器，还有一种命令行的方式可以选择。在VirtualBox的安装目录有一个叫做VBoxManage.exe的文件，除了可以用来更改VirtualBox的设置，还可以用来自动启动服务器。

默认情况下，VBoxManage.exe的地址应该类似下面这个样子：

C:\Program Files\Sun\xVM VirtualBox\VBoxManage.exe

我们建立一个快捷方式，目标的内容如下所示：

"C:\Program Files\Sun\xVM VirtualBox\VBoxManage.exe" startvm Ubuntu

注意的是，Ubuntu是我的服务器的名字，大家可以根据实际情况改成自己的。startvm是VBoxManage.exe自动启动服务器的命令。这个快捷方式可以直接运行，也可以放到开始菜单的启动项中，看大家需要了。

测试环境：
Host - Windows XP SP3
Guest - Ubuntu Server 8.1
VirtualBox - 2.0.6

备注：如果某个服务器已经启动，再次采用这种方式启动会报异常。

参考资料
* Run Ubuntu from XP host at bootup of XP without intervention

脚本 - 小组讨论中，直接显示最后一条回复

2009-01-16T05:30:00.006+08:00

小组有几个反馈的帖子，都有100多楼，每次翻阅，总是要先打开帖子，等待，然后跳到最后一页，还要向下翻。虽然np把分页给放到屏幕最上面了，虽然可以直接跳到页尾，可还是要先到首页，再到最后一页，多了一道工序，所以有了这个脚本。

【脚本名称】Douban Group Last Reply
【下载地址】http://userscripts.org/scripts/show/40538

Douban Group Last Reply是一个Greasemonkey脚本，应用于豆瓣网的小组讨论模块。在帖子列表中，为回复数添加一个链接，不管有多少页，多少个回复，点击这个链接都可以直接跳到最后一页的最后一个回复。（其实是最后一个回复向下偏移1/3个屏幕，呵呵）

有些页面的表格是四列的，有些是五列的，这里折中取了倒数第二列。

0-100页的地址格式：
http://www.douban.com/group/topic/5039392/#last

101-200页的地址格式：
http://www.douban.com/group/topic/3388182/?start=100#last

往后类推。。

目前支持的页面：

小组讨论首页
http://www.douban.com/group/

单独小组首页
http://www.douban.com/group/*/

更多小组讨论
http://www.douban.com/group/*/discussion*

我所在小组的最近话题
http://www.douban.com/people/*/group_topics*

我最近的发言
http://www.douban.com/people/*/topics*

我回应的话题
http://www.douban.com/people/*/replied_topics*

脚本 - 根据访问频率调整小组的显示顺序

2009-01-16T01:54:00.009+08:00

Douban Group Frequency是一个Greasemonkey脚本，应用于豆瓣网的小组模块，可以记录用户的访问习惯，将那些经常访问的小组排在最前面。

【脚本名称】Douban Group Frequency
【下载地址】http://userscripts.org/scripts/show/40534

在豆瓣插件小组置顶的帖子里，很多朋友希望增加小组分类的脚本，这两天一直计划写一个，可是当用了Wakoopa以后，有了新的想法。无论是设置分类，还是设置标签，都需要手动操作，小组多了也很麻烦。而我们要达到的最终目的，只是要把那些经常访问的小组置于最前面而已，所以有了根据大家的访问习惯来自动设置顺序的想法。

现在的操作还很简单，在本地为每个你访问过的小组增加一个频率属性，你每访问这个小组一次脚本就累加一次，在我的小组界面，按照这个频率属性由高向低排序，时间长了自然经常访问的小组就显示在前面了。

以后计划多储存一些数据，比如小组的最后访问时间，加入时间，访问的帖子数等，数据越多，就可以做出越多的统计，让大家知道自己平时最钟爱的小组有哪些。

访问频率初始值为0，访问小组首页加1，访问小组内帖子首页加1，除了首页其他页面暂时还没有统计，主要怕各个小组的值差的太悬殊，呵呵。

脚本最后调用了debug函数，会在右边的侧栏显示所有小组的访问记录，包括那些你没有加入的小组，和开始记录的时间。在小组人数后面，会以中括号标识访问频率数的具体值。如果不想看这些数据，可以直接把debug的调用注释或者删除。

脚本在Firefox配置中保存了两个字段：

greasemonkey.scriptvals.http://cuimingda.com/Douban Group Frequency.groups
保存我的所有小组的访问次数，采用JSON格式

greasemonkey.scriptvals.http://cuimingda.com/Douban Group Frequency.startDate
保存开始统计的时间

在侧栏增加了一个“清空我的小组访问记录”链接，点击以后将会清空没有加入的小组的访问记录，以及将我的所有小组的访问次数设置为0，开始统计时间也会重置。

更新：之前都只能在我的小组页面调整显示顺序，现在在小组首页也可以了

更新：除了有我参与的小组外，还有我建立的小组，之前把所有的内容都添加到我建立的小组中了，修改了下父元素，将两组给区分开来了。

脚本 - 用Ctrl Enter为所有的文本框提速

2009-01-15T16:33:00.007+08:00

Douban Ctrl Enter是一个Greasemonkey脚本，为豆瓣所有的多行文本框增加Ctrl+Tab快捷键，通过这个快捷键可以直接模拟点击表单内的提交按钮。在Firefox 3.1b2和Greasemonkey 0.8下测试通过。

【脚本名称】Douban Ctrl Enter
【下载地址】http://userscripts.org/scripts/show/40498

豆瓣有很多栏目，每个栏目都可以评论、留言，发表大部分内容都是在一个文本框内填写内容，然后点击“加上去”，多了这一步加上去着实不爽，所以写了这个脚本。

这个脚本只针对Textarea做了处理，没有对单行的文本框绑定事件，主要是大部分的单行文本框直接按回车就可以提交，再加就多此一举了。

一开始的时候采用的是直接调用表单的submit方法，但是调用这个方法不会激活onsubmit事件，这个事件中有可能存在校验代码。而且豆瓣大部分的表单，是在submit按钮的点击事件中做了表单的校验，所以后来改为鼠标模拟点击submit按钮。如果表单中有内容校验不通过，会向正常情况一样给出提示。

这里做个备忘，在HTML中，按道理说FORM是不可以嵌套的，jQuery也是这样处理，在测试代码中设置某元素父节点存在两层FORM元素，用parents("form")只能获取最近的那个。

更新：选择submit元素的时候，加上了visible过滤条件，发现豆瓣部分页面的表单，里面包含多个submit，根据页面功能的不同，将其中一个设为显示，其他的设为隐藏。如果不加这个条件，获取的提交按钮就不对了。

脚本 - 为译言添加“推荐到豆瓣”功能

2009-01-14T21:48:00.008+08:00

Yeeyan To Douban是我在豆瓣的推荐Bookmarklet基础上写的一个Greasemonkey脚本，在译言所有文章的末尾，添加一个“推荐到豆瓣”的链接，点击就会弹出个小窗口，确认就可以把这篇文章推荐到豆瓣了。

【脚本名称】Yeeyan To Douban
【脚本地址】http://userscripts.org/scripts/show/40423

推荐语会自动从全文中提取，如果选中了部分文字，则推荐语就是这部分文字。如果没有选中任何文字，则会提取文章的简介部分，而如果译者还没有加简介，则会提取正文第一段落的内容。当然，不论推荐语自动填入了什么，你还可以根据需要修改。

译言和豆瓣之间应该已经有相应的接口，用豆瓣的Bookmarklet推荐，会提取一些非网页上的内容，比如译者和原文地址等，而且采用这种方式，不会把选中的文章内容传过来，还是很不方便的。所以这里使用了一个Hack，就是在所有推荐的地址后面加了点东西，这样就不被识别为标准的译言文章，就不会走那个特殊渠道了，呵呵。地址还是那个地址。

写在后面的心得

对window.open加一层判断，如果打开失败，改用location.href，是个很不错的想法，防止对打开窗口加以屏蔽的情况。
jQuery是不能跨域发送AJAX请求的，一直以为可以，一直都错了。

MIIT Record Tracker - 网站备案了么？

2009-01-12T04:31:00.004+08:00

中国从几年以前开始对网站实行监管，非营利性网站实行备案制度，营利性网站实行许可证制度，其他特殊业务的网站有专门部门发许可。按要求是在网站页面下方要显示备案号，并放上工信部的链接，但其实工信部自己和国家部委的网站就不符合要求。对于规范的网站，如何来判断备案号是否有效呢？

MIIT Record Tracker是我写的一个Firefox扩展，目前版本0.1，还处于沙盒中，想法也很简单，找到网页上的备案信息，并显示是否找到，多点一下鼠标就在后台去工信部的网站查找详细信息，并显示出来。

【下载地址】https://addons.mozilla.org/firefox/addon/10337

计划完善的内容：
兼容更多不规范格式的备案号。
对于一些外观上的内容增加选项，让大家自定义。
显示详细信息。

写在后面

貌似也写了很长时间Firefox扩展了，一直计划要把自己写的扩展传到AMO上，可总有各种各样的原因导致流产，其实只是很简单的几步，就在刚才，一激动就把这个很久以前的扩展给传了，丑媳妇总是要见公婆的嘛，呵呵。刚才还在SF.net申请了这个项目，也是第一次，希望能快点批下来吧。

如何在Firefox扩展中使用jQuery

2009-01-12T00:30:00.006+08:00

jQuery是一个非常强大的JavaScript类库，如果在Firefox扩展的开发中使用，可以让我们的代码清晰很多，刚在网上搜了一下，问如何将两者结合在一起的有那么几个，可是回答的基本都是所答非所问，大家问的是怎样通过Firefox扩展在Firefox打开的网页中使用jQuery，而回答都是怎样操作XULDocument的。

先整理下思路，jQuery不管怎么说，都是对DOM操作的，这就要求首先要有一个可以操作的DOM对象。在扩展中直接调用document，获取的类型是XULDocument，对应于整个浏览器，而这个onload事件，在打开浏览器的时候就调用了，这时候我们还没有输入地址打开网页呢。而其实我们是想在Firefox扩展中，对要操作的网页使用jQuery，这其实用到了和Tab相关的一些技巧。

来写具体的，首先准备一个jQuery的类库，我们这里使用最新的1.2.6，如果没有，可以到这里下载。下载后放到扩展的content目录中。

建立一个overlay.xul，我们目前没有任何界面元素，建立这个文件的目的主要是加载脚本，该文件的内容如下：

<overlay id="myext-overlay" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
 <script type="application/x-javascript" src="chrome://myext/content/jquery-1.2.6.min.js" />
 <script type="application/x-javascript" src="chrome://myext/content/overlay.js" />
</overlay>

如果我们有一些界面元素，加载脚本的代码，应该放到overlay的最后面，这和HTML的规则是一样的。加载了两个脚本，一个是jQuery类库，另外一个包含了我们的所有操作，当然jQuery应该放在前面了。下面看看overlay.js的代码：

/*
;(function() {
 function pageLoad(doc) {
     $("a", doc).click(function(event) {
         event.preventDefault();
     });
 }

 window.addEventListener("load", function () {
     gBrowser.addEventListener("load", function(event) {
         if (event.originalTarget instanceof HTMLDocument &&
             !event.originalTarget.defaultView.frameElement) {
             pageLoad(event.originalTarget);
         }
     }, true);
 }, false);

})();
*/

pageLoad这个函数，只有在每个页面load完毕的时候才会调用，而doc则对应于该页面的document对象，我们可以直接使用下面的方式获取网页的标题。
alert($(doc).attr("title"));

这样对网页和对扩展页面的操作就区分开来了。在pageLoad中操作doc，是操作网页的HTMLDocument对象，而直接操作document是处理Firefox的XULDocument对象。

当然，最后不要忘了加载这个脚本，和往常一样啦，在chrome.manifest中加上下面这两行就可以：

content myext content/
overlay chrome://browser/content/browser.xul chrome://myext/content/overlay.xul

小结

总的来说，在Firefox扩展中使用jQuery，是为了更方便的操作XULDocument对象，而如果需要大量操作网页DOM的情况，应该使用Greasemonkey，而不是做一个Firefox扩展，有很多Greasemonkey的工作，又重新做了一遍，这轮子没什么意思啊。

本文对于pageLoad的判断，完整的版本大家可以参考MDC上的文章《Tabbed browser》，这里做了小小的改动，思路不变。

JavaScript正则表达式生成器

2009-01-10T14:38:00.025+08:00

看到很多人把一些JavaScript开发的小工具嵌入到Blogger中，感觉很神奇，我也来尝试一下。这个工具的想法，是将给定的字符串转换成JavaScript正则表达式，目前功能还很简单，只是将特殊符号和汉字用转义符替换，以后会增加一些选项，更加智能一些。为了避免显示一份脚本，再执行一份，后面使用了一点小技巧，页面功能所用的脚本就是下面显示的那份源代码，这样排版也容易些。

要转换的内容：

转换结果：

$("document").ready(function() {
    $("#convert").click(function(event) {
        $("#convertTo").val(convertToJsEsc($("#convertFrom").val()));
    });
    $("#clear").click(function(event) {
        $("#convertFrom").val("");
        $("#convertTo").val("");
    });
});

function convertToJsEsc(chars) {
    var result = '';

    for(var i=0; i<chars.length; i++) {
        var code = chars.charCodeAt(i);
        switch (code) {
            case 0x20: result += "\\s";     break;
            case 0x22: result += "\\\"";    break;
            case 0x27: result += "\\\'";    break;
            case 0x28: result += "\\(";     break;
            case 0x29: result += "\\)";     break;
            case 0x2A: result += "\\*";     break;
            case 0x2B: result += "\\+";     break;
            case 0x2E: result += "\\.";     break;
            case 0x2F: result += "\\/";     break;
            case 0x3F: result += "\\?";     break;
            case 0x5B: result += "\\[";     break;
            case 0x5C: result += "\\\\";    break;
            case 0x5D: result += "\\]";     break;
            case 0x7B: result += "\\{";     break;
            case 0x7D: result += "\\}";     break;
            default:
                if(code > 0x1F && code < 0x7F) { result += chars[i]; }
                else { result += "\\u" + code.toString(16).toUpperCase(); }
                break;
        }
    }
    return result === "" ? "Nothing to convert" : result;
}

参考资料：
☆ http://www.beginningtoseethelight.org/ascii/
☆ http://rishida.net/scripts/uniview/conversion.php
☆ http://cuimingda.com/2008/12/gb2312.html

可用的Google GHS地址（2009年1月23日更新）

2009-01-09T15:39:00.013+08:00

在中国，政府一直主张实名制，这样可以让大家对自己说的话更加负责一些，也更容易控制一些，但这只是对运营在国内的服务器的限制，政府对运营在国外的服务器没有管辖权，那就只有屏蔽了，也就是传说中的GFW。但就算如此，我还是喜欢国外的Blogger，图的就是这里清净、纯粹。由于GHS经常被封，所以根据经验整理这个列表吧，希望能对大家有帮助。

不同的ISP，在不同时间连接各个GHS的状态可能不一样，我的测试数据是通过上海网通的网络测试的，大家可以多试试。

☆ 64.233.179.121 - 不可用
☆ 66.249.81.121 - 不可用
☆ 66.249.91.121 - 不可用
☆ 72.14.205.100 - 可用
☆ 72.14.207.121 - 不可用
☆ 72.14.235.121 - 不可用
☆ 74.125.43.121 - 不可用
☆ 74.125.47.121 - 可用
☆ 74.125.93.121 - 不可用
☆ 209.85.171.100 - 可用
☆ 209.85.171.121 - 不可用

备注：找GHS，有个好工具是很必要的。

使用jQuery发送AJAX请求的小技巧 - 拒绝缓存

2009-01-03T21:52:00.005+08:00

通过jQuery发送ajax请求，无论是get方式还是post方式，当前后两次请求的参数完全一样时，浏览器就有可能调用缓存里的数据，最直接的结果就是造成有些操作没有生效的假象。这种情况，我们应该通过下面这个技巧来避免浏览器调用缓存里的内容。

【本文地址】http://cuimingda.com/2009/01/ajax-tip-anti-cache.html

先整理下思路，浏览器之所以调用缓存里的内容，最主要的一点是判定现在要访问的内容和之前的是一样的，那我们解决这个问题的方法就明确了，怎么让前后两次的内容不一样。这里介绍的技巧是为查询请求增加一个随机的参数。

对于get请求：

url = "someurl.php?id=123";
url += "&anticache=" + Math.floor(Math.random()*1000)
$.get(url);

对于post请求：

parms = {
   id : "123",
   anticache : Math.floor(Math.random()*1000)
}
$.post("someurl.php", parms);

小结

编写脚本的过程中，发现应该为大多数请求添加随机参数，这样可以保证获取数据的实时性和准确性。使用了这个技巧以后，基本没有发现操作好像无效的情况，呵呵。

技巧 - 如何使用JavaScript监视动态变化的DIV元素

2009-01-03T21:02:00.005+08:00

在HTML中，不管是select元素还是input元素，都可以激活onchange事件，这样当元素的值发生改变时，我们可以做出相应的处理。可当我要监控的内容不是一个form元素，而是一个div的时候，应该怎么办呢？比如有一个div的内容是通过ajax控制的，我们必须保证要在div内容发生变化的时候，进行相应的操作，这里我来介绍一个学来的小技巧。

【本文地址】http://cuimingda.com/2009/01/html-div-change-event.html

首先整理下思路，Div元素本身无法发出改变信号，那么我们就要做个监视器，来监视div的改变，可能就需要一个定时器来判断内容。而对于内容是否改变，我们还要有一个判断的标识，通常通过AJAX更改内容，都是通过innerHTML来修改，所以我们可以为其中的某个元素添加一个属性，代表我们已经处理过了，当内容刷新，这个属性就会消失，当我们检查的时候就会知道，这样就可以重新操作了。

我们假设Greasemonkey脚本要应用的网站中，有一个页面存在类似下面的内容，news的内容会经常的自动刷新，而我们要做的就是，当内容刷新时，显示出当前的段落数量，也就是p元素的数量。

<div id="news">
   <p>some news...</p>
   <p>some news...</p>
   <p>some news...</p>
</div>

为了监视div内容的变化，我们需要在页面加载的时候添加一个监视器：

$(document).ready(function() {
   newsMonitor();
});

我们可以设置为1秒检查一次，当然可以根据实际的需要做些调整：

var newsMonitor = function() {
   newsChecker();
   setTimeout(function() { newsMonitor(); }, 1000);
};

下面这个函数负责检查和操作：

var newsChecker = function() {
   if($("#news p:first").attr("checked") === "true") return;

   // 中间的部分编写当内容发生改变时要进行的操作。

   $("#news p:first").attr("checked", "true");
};

以上的代码都只是一个简单的思路，通过这个思路我们可以对任何元素的内容进行动态的监控。在实际的开发中，我们可以根据需要精简或者复杂代码。

Greasefire - Greasemonkey的最佳拍档

2009-01-01T22:10:00.004+08:00

使用Firefox和Greasemonkey的朋友，应该都知道找脚本要去Userscripts.org，可是你知道到底有多少人为你正在访问的网站编写了脚本么？比如说，你知道Userscripts.org上有多少可以应用在Google Reader上的脚本么？我就知道！现在有450个。什么？我是怎么知道的？向你隆重介绍Greasemonkey的最佳拍档：Greasefire。当你用过之后，你就可以体会这个“最佳”绝对不是浪得虚名。

【扩展名称】Greasefire
【扩展作者】Steve Krulewitz
【下载地址】https://addons.mozilla.org/firefox/addon/8352

Greasefire是一个Firefox扩展，也是一个Greasemonkey扩展，可以显示Userscripts.org上有哪些脚本可以应用在你正在访问的网站上。Greasefire的当前版本是1.0.1，2008年8月2日发布，2005KB大小，兼容于Firefox 3.0 - 3.1b3pre。这里需要说明两点，尺寸很大是因为集成了一个本地索引的关系，还有就是这个扩展不支持Firefox 2.0。

安装了Greasefire以后，咋一看浏览器界面好像没有什么变化，可是当你访问网站的时候，你就会发现Greasemonkey的图标有时候会“着火”，这是Greasefire找到了适合当前网站的脚本，这时候你只要点击那个猴子，最上面一条就是“XX scrits available”，XX就是找到的脚本数。而点击这个菜单项就会打开一个类似下面的窗口：

下面对这个窗口进行一下简要的说明：
☆ 左面的窗口显示所有支持当前网站的脚本，点击以后就会在右面显示该脚本在Userscripts.org的主页。
☆ 虽然显示出了内容，但上面大部分的链接都是点击无效的，少部分可以点。
☆ 在Tab栏选择Source，可以直接查看源代码。
☆ 而在下面有一个很宽和宽的按钮，可以直接安装脚本。
☆ 左面的列表，默认显示的脚本名称和排行，其实还可以显示更新时间、安装数量和匹配程度。但由于数据是每隔一段时间更新，所以和当前数据可能会有比较大的差别。

关于这个扩展的数据来源，都是利用接口直接从Userscripts.org上获取，但不是实时的，是定期下载，并保存在本地的。在选项中可以设置更新的频率，默认大概是一个星期。

小结

如果安装了Greasemonkey，Greasefire这个最佳拍档简直就是必须装的，甚至我都认为安装Greasemonkey的理由就是Greasefire，呵呵。

技巧 - 你今天为Blogger设置页脚了么？

2008-12-28T18:44:00.004+08:00

【原文标题】Add Post Feed Footer - Let Googlebot discover the source
【原文作者】talksmart

以下是对原文的翻译：

如果你是一个Blogger用户，你是否已经为你的博客设置了页脚链接（Post Feed Footer Link）？“帖子供稿页脚”可以在设置下的供稿中找到。你可以在这里设置一个链接，这个链接将会出现在你所有帖子的页脚位置。这之前，你需要设置“启用帖子页”为“是”（在存档设置里），并且设置“博客帖子供稿”为“完全”。

可是为什么要设置页脚呢？你可能会好奇这样做的具体原因，其实很简单，并不是所有的网站都会照单全收你博客的RSS，而是经过了一定的格式化，尤其是当你把供稿模式设置为“完全l”的时候。当Google蜘蛛访问你的网页时，很有可能看到的是经过格式化的内容，而不是你最开始看到的那份。

所有，为了让这些蜘蛛看到你的地址，还是在你每篇博客的下面添加一份吧。

下面举个简单的例子，你可以仿照这样来做。只需要把下面的内容添加到“Post Feed Footer”中，并替换内容为你网站的名字和链接就好。

<hr /> <a href="http://www.myblog.com">My Blog Name</a>

再次强调，为了实现这个功能，你必须将同步模式设置为“完全”。

【译者注】

如果通过FeedBurner或者FeedSky输出博客RSS，那么通过Google Reader这类工具订阅的时候，看到的只是FeedBurner或者FeedSky地址，当然这个地址可以转换为你网站的实际地址。可是不幸的是，FeedBurner不定期的会遭到屏蔽，导致读者找不到你博客的真实地址。所以，在内容中添加一份地址，还是很有必要的。

3款可以模拟浏览器分辨率的Firefox扩展

2008-12-28T17:13:00.009+08:00

之前我介绍了Window Resizer这个Firefox扩展，可以模拟浏览器在各种标准分辨率下的显示效果。之后我又在AMO做了一下搜索，又发现了两款名字类似，功能相同的Firefox扩展。开两篇文章介绍实在太浪费了，就在一篇里介绍吧。

先来看看这几个扩展的基本信息，基本上Window Resizer是最早开发的，但因为不能自定义分辨率，所以又出现了Yet Another Window Resizer，而最后开发的Firesizer完全是借鉴了YAWR的灵感，呵呵。

既然都是模拟浏览器在各种分辨率下显示效果的扩展，我们就对他们的能力做一个比较：

下载

Window Resizer 1.0
https://addons.mozilla.org/zh-CN/firefox/addon/1985

Yet Another Window Resizer 1.21
https://addons.mozilla.org/zh-CN/firefox/addon/2498

Firesizer
https://addons.mozilla.org/zh-CN/firefox/addon/5792

小结

从功能上讲，最晚开发的Firesizer肯定胜出，但是从使用角度将，我更倾向于使用最早开发的Window Resizer，一是我只需要测试那些标准分辨率，二是工具栏图标这种方式操作很符合我的习惯。呵呵。

再送你一个可以模拟各种分辨率的Firefox浏览器

2008-12-28T16:50:00.003+08:00

作为一个Web开发者，一个很基本的素质就是理解世界不是由自己一个人组成的，还包括很多人、很多不同类型的显示器、操作系统和浏览器。而考虑到这点，为了让我们的网站适应更多的人使用，模拟他们的环境就变得很重要，首先我们先来谈谈怎样模拟大家的显示器分辨率，就是这个叫做Window Resizer的Firefox扩展。

【扩展名称】Window Resizer
【扩展作者】Yellowpipe Web Hosting
【下载地址】https://addons.mozilla.org/firefox/addon/1985

Window Resizer是一个Firefox扩展，可以模拟Firefox在6个标准分辨率下的显示状态。本文介绍的版本1.0，2008年6月10日更新，23KB大小，兼容于Firefox 1.5 - 3.0.*。

安装了Window Resizer以后的，可以到“定制工具栏”窗口找“Resize this window”图标，形状和调节窗口大小的鼠标类似。点击这个图标，就可以弹出一个小窗口，可以将浏览器模拟为以下其中之一的分辨率：
* 640×480
* 800×600
* 1024×768
* 1280×800
* 1280×1024
* 1600×1200

如果模拟的分辨率小于浏览器的当前分辨率，浏览器窗口会缩小，否则浏览器窗口可能会变大，并超出屏幕范围。所以基本上这个扩展只能测试比当前分辨率小的情况，无法测试大的情况。

小结
对于Web开发者来说，这是一款既方便又实用的扩展。

送你一个可以自由调整大小的Textarea文本框！

2008-12-27T15:14:00.004+08:00

每一个你所能遇到的问题，最终都会用很多种解决方案，有一些很麻烦，有一些很简单，只是可能有一些还没有被想出来而已。经常浏览网站，遇到比较多的问题就是让你输入大段文本，可是却给了你一个很小的Textarea。没有Firefox的时候你只能忍耐，看过了我的博客你知道用Text Area Resizer and Mover，本文将介绍一个更简单的解决方法。

【扩展名称】Resizeable Textarea
【扩展作者】Raik Jürgens
【下载地址】https://addons.mozilla.org/firefox/addon/3818

Resizeable Textarea是一个Firefox扩展，可以任意调整Textarea的大小。本文介绍的版本是2006年11月8日发布的0.1d，大小只有4KB，兼容于Firefox 1.0 - 3.1b2。

安装了这个扩展以后，大部分Textarea都会支持缩放功能，就是当你不鼠标移动到Textarea的一边或者一角时，会发现鼠标形状发生变化，这时候只要拖动就可以，非常的方便。

当然，对于一个两年以后最后更新的扩展，我们没有办法要求更多了。这个扩展确实不能支持所有的Textarea，有一些Textarea连我自己都发现不能调整大小，但是不影响我对这个扩展的评价，这个思路简洁而优秀。

而且，如果能增加一些智能的因素，比如记住每个文本框上次的大小，当刷新页面的时候自动调整到那个大小，应该就更加出色了。

BTemplates.com - 我所知最棒的Blogger模板网站

2008-12-27T14:08:00.006+08:00

世界上有一些优秀的网站，由于本身是英文的，所以只有用英文版的Google搜索才能排在前面，而如果用谷歌搜索，也许连第一页都进不去。BTemplates.com就是一个案例，这是我见过的最好的Blogger模板网站，但如果你用Blogger模板作为关键字是搜索不到的，用Blogger Templates搜索，也只是有一个非首页的结果而已。但用英文版Google搜索Blogger Templates，确是第一条结果。

先说两个数字：第一个，在发表此文的这个早上，也就是在我睡觉的8个小时过程中，通过订阅，我又发现了6个模板的更新；第二个，按照模板栏数的分类统计，该网站的模板数在650到700之间，如果所有的模板都设置了唯一的栏数类别的话，呵呵。

BTemplates是我见过的最好的Blogger模板网站。

在这个网站，每一个模板都对应于一个blogger上的独立博客，也就是说你除了可以看截图，还可以看到最终的使用效果，而且和应用到你网站的时候一模一样。看到喜欢的，你可以直接把模板文件下载到本地，导入到你的博客。至于可以再修改的权限，要看模板原作者的版权声明了。BTemplates只是把这些模板像图册列出来而已。

你可以为每个模板评分，一到五颗不等的星星，这样可以帮助其他人更快速的挑选模板，当然对你非常喜欢和非常讨厌的模板，留下一条评论，也许更加有效。

对于有天赋的你，如果看到这些模板激发了灵感，想自己来试试，并把自己的模板也上传到这里，可以通过这个地址提交。

你可以按几种方式找到你要的模板：

从到头为一页一页翻，很多啊，看完就需要很长时间。
按模板的类别来查找，具体的类别会在后面列出。
按模板的标签查找，具体的标签会在后面列出。
通过网站的搜索，按照模板或者作者的名字直接找到你要的模板。
订阅这个网站的RSS，通过阅读器获取最新的模板，从中发现你想要的。
通过FeedBurner提供的Email订阅方式阅读。
根据网站提供的三个排行榜（下载榜、浏览榜和评分榜）发现你的最爱。

网站的标签

Animals Art Arts ArtWorks Beauty Books Business Cars Christmas City Communications Computers Culture Dark Education Electronics Entertainment Family Fantasy Fashion Floral Food and Drink Games Geometric Girl Grunge Home Internet Jobs Kids Modernity Movie Music Nature Neutral People Personal pages Photography Science Software Space Sport St. Valentine Travel Vector

网站的分类

* 1 Column
* 2 Columns
* 3 Columns
* 4 Columns
* Adaptation of Wordpress
* Black
* Blue
* Brown
* Elegant
* Fixed width
* Fluid width
* Fresh
* General
* Gradients
* Gray
* Green
* Left sidebar
* Magazine
* Minimalist
* No images
* Orange
* Photolog
* Pink
* Red
* Right sidebar
* Rounded corners
* Shadow
* Violet
* Web 2.0
* White
* Yellow

小结
综合起来说，如果你有一个Blogger上的模板，非常推荐你订阅或者经常访问这个网站，会不断有惊喜的。

正在浏览什么网站？用TwitterBar分享一下吧！

2008-12-26T03:36:00.004+08:00

TwitterBar所要解决的问题就是，告诉大家你在浏览什么网站？你除了可以把你正在浏览的网站分享出来，还可以加个小评论，只要记得别写太多了，有140个字的限制哟。这个扩展很大的一个特点就是人性化，具体怎么个人性化法，我们下面慢慢介绍。

【扩展名称】TwitterBar
【扩展作者】Christopher Finke
【下载地址】https://addons.mozilla.org/firefox/addon/4664

TwitterBar是一个Firefox扩展，可以将地址栏的内容发表到自己的Twitter中。本文介绍的版本是1.1，2008年11月1日发布，12KB大小，兼容于Firefox 2.0 - 3.1b3pre。

上手

安装了这个扩展以后，在地址栏后面，就会多出一个灰色的小豆豆图标，这个就是发表Tweet的按钮，既然看到了就顺便点一下吧，看到什么了？呵呵，当然是提示你的登录了啊。

登录

我们就先来说说TwitterBar的帐号验证模式，主要有两种：第一种是利用Firefox自身的密码管理器，安装后首次发表Tweet，就会自动启用这种模式，并提示你输入用户名和密码，如果打算以后也采用这种方式，我们可以选择保存密码。第二种是利用扩展自己的功能保存，在扩展的设置窗口中选择safe模式，然后输入用户名和密码就可以。

发布消息

登陆以后，我们在地址栏输入任何内容，然后点击那个灰色的小豆豆，就发布了，发布成功地址栏会给出提示的。如果不愿意动鼠标，输入完内容以后，可以直接输入“--post”，TwitterBar会监控地址栏的内容，你一旦在地址栏输了这个命令，就会把前面的内容发布了。

人性化设置

开始的时候说到人性化，其中一点就是在地址栏输入的内容，会自动计算字数，当你把鼠标移动到灰色的小豆豆上时，就会显示出这个字数来。这里要注意的是，用TwitterBar发送消息，会自动包含一个前缀，而这个字数是抛出了前缀的字数。前缀的具体内容在设置里面可以修改。

小结

TwitterBar功能很方便，但不足也还是有的啦。比如设置窗口点确定不会自动关闭，也没有相应提示，就很不方便。而且消息前缀不支持中文，也是一个瑕疵。但总的来说，是非常不错的。

许个愿望：以后不再使用document.write模式！

2008-12-25T16:58:00.003+08:00

长久以来，使用document.write来输出动态脚本都是很多网站的做法，可是这种做法有着先天的缺陷，而且也是可以通过其他方式替换的，可还是有很多人这样做。让我们在圣诞节和Dion Almaer一起许个愿望吧，以后不会再用document.write动态输出脚本！

【原文标题】A Christmas Wish: “I promise not to use document.write()” mode
【原文作者】Dion Almaer

以下是对原文的翻译：

昨天晚上的几次谈话激起了我写这篇的想法。他们现在的工作就是处理一些和布局有关的问题，而我听到最多的话就是“我只有用document.write才可能实现这种效果”。

这其实很难讲，为了动态添加一段脚本，很多人通常会使用document.write来完成。（这算是广告么？）

这样做带来的最大问题是，我们需要为每个页面付出更大的维护成本，而且这些代码根本无法直接进行优化。

既然这样，那让我们在这个圣诞节告诉所有的浏览器，你已经许愿不会再使用document.write()，就算使用了也不会生效。

估计这种事情只能出现在圣诞节的愿望中，还是让我们回到现实中来吧：

Bob Philips曾经说过，这个世界上有三种男人：

* 相信圣诞老人存在的男人
* 不相信圣诞老人存在的男人
* 圣诞老人

好好休息，节后见！

代码片段 - 如何在Greasemonkey脚本中加载CSS

2008-12-24T16:32:00.010+08:00

在我们编写的Greasemonkey脚本中，有时候会需要加载样式表，你会怎么做呢？Greasemonkey 0.8新增了一个叫做resource的meta标记，其实我们完全可以通过这个标记十分方便的加载样式表，就和以前一样，我们介绍两种加载样式表的方式，一种是通过style标签，一种是通过link标签。孰优孰劣，看大家喜好咯。

首先我们要先介绍Greasemonkey 0.8新增的两个函数：GM_getResourceURL和GM_getResourceText。GM_getResourceURL函数可以获取加载资源的地址，通常用于元素的href或者src属性，该函数的返回结果是一个base64字符串。GM_getResourceText函数可以获取加载资源的内容，如果是文本文件，这个内容就是实际的、你能看懂的内容，但如果是图片等二进制文件，返回的内容就是不可阅读的了，这时候要读取资源，就必须采用GM_getResourceURL方式。

下面我们就介绍如果在Greasemonkey脚本中通过resource方式添加样式表。

为了添加一个资源，当然我们需要有这么一个CSS样式表，你不会是想通过字符串连接的方法写入样式表吧？具体的方法如下所示：

// @resource  cssfile http://www.somewhere.com/test1.css
// @resource  cssfile http://www.somewhere.com/test2.css

先看看如何通过这个资源来加载样式表：

$(document).ready(function() {
    loadCssFromResource1("cssfile1");
    loadCssFromResource2("cssfile2");
});

下面是具体的通过link方式加载的函数代码：

var loadCssFromResource1 = function(resourceName) {
    var link = document.createElement("link");

    link.href = GM_getResourceURL(resourceName).replace("undefined", "text/css");
    link.type = "text/css";
    link.rel = "stylesheet";

    document.getElementsByTagName("head")[0].appendChild(link);
};

下面这个是通过style标签样式表的代码：

var loadCssFromResource2 = function(resourceName) {
    var style = document.createElement("style");

    style.type = "text/css";
    style.appendChild(document.createTextNode(GM_getResourceText(resourceName)));

    document.getElementsByTagName("head")[0].appendChild(style);
};

补充说明：

采用GM_getResourceURL读取非图片类型的文件，无法获取文件的类型，但是不影响加载。
通过resource加载的资源可以不使用绝对路径，可以使用相对于脚本安装位置的相对路径。

用Inline Code Finder检查一下你的HTML代码吧！

2008-12-23T13:36:00.006+08:00

在很长一段时间以来，快速开发和易于维护是相互冲突的，但是如果你可以遵照一些标准和规范来进行开发，在很大程度上可以保证鱼和熊掌兼得，但遵守标准本身就很难。尤其是一些短小的代码，可能一着急就会把他们内联到HTML中，只要一个两个可能看不出来，但假如有几十个上百个，你还会认为易于维护么？

【扩展名称】Inline Code Finder
【扩展作者】Robert Nyman
【下载地址】https://addons.mozilla.org/firefox/addon/9641

Inline Code Finder是一个Firefox扩展，有两个版本，一个是独立的，一个是Firebug版本，功能都一样，本文介绍的是Firebug版本，目前最新版本是0.90，2008年12月17日发布，只有9KB大小，兼容于Firefox 2.0 - 3.1b2pre。Inline Code Finder可以帮你找出网站中那些让人看着恼火的内联代码，帮助你快速改进。

内联代码？

第一个是内联的样式（Inline style），已经经过很多很多人的亲身实例证明，直接设置HTML元素的style属性是非常不容易维护的做法。成熟的做法应该是根据id或者class属性，通过head或者外部的CSS文件来设置样式。

第二个是内联的JavaScript事件（Inline JavaScript events），比如直接在HTML元素的onclick内书写代码，这是非常典型的把表现层和行为层分不开的表现，对于某些简单的操作，这样做可能显得非常方便，但是代码冗余加上不利于维护的问题，似乎更加严重。

第三个是在链接的href属性中直接编写javascript代码，达到点链接就执行相应操作。其实链接有click事件，不是么？

简单的使用说明

安装扩展以后，在Firebug上就会多出一个Tab：Inline Code Finder。点击这个Tab，在上方可以执行四个操作：
Run：对当前页面执行测试，并在页面用不同颜色显示出来。内联事件为红色、内联样式为绿色、JavaScript链接为紫色。鼠标移动到颜色框内，会显示出内联的代码。
Toggle：在显示测试结果和不显示测试结果两个状态间进行切换。
Clear：清除测试结果。
Hide：隐藏Firebug窗口。（独立版本应该是隐藏Inline Code Finder窗口）

设置

除了可以对是否进行这三项检查，做单独的启动设置外。Inline Code Finder还提供一个自动检查模式，打开的新页面会自动检查并显示测试结果。

总结

对于Web开发者来说，这个扩展提供了一个非常实用的功能，基本上属于必备工具。

John Resig - jQuery 1.3进入Beta测试阶段

2008-12-23T12:55:00.002+08:00

这是John Resig博客2008年12月22日的文章。jQuery已经进入beta测试阶段，并计划在2009年1月14日正式发布，现在正需要大家进行广泛的深度测试。这个版本重写了相当多的模块，而且据说会非常让人振奋，让我们共同一起期待吧。

【原文标题】Help Test jQuery 1.3 Beta 1
【原文作者】John Resig

以下是对原文的翻译：

为了能让jQuery类库的新版本尽快和大家见面，jQuery团队最近一直都在很努力的工作，而且工作的成果也已经显现，jQuery现在已经可以经受一些深度的测试了。但在我们清除那些隐藏起来的Bug之前，很明显jQuery 1.3还不能作为一个成熟的产品供大家使用。

下载

你可以在这里下载jQuery 1.3b1：

http://code.jquery.com/jquery-1.3b1.js

测试的时候请大家不要下载minified或者packed版本，因为使用这两个版本，就算你发现了问题，也很难定位出错的代码。

主要的修改

下面这几个地方在新版本中做了较大的修改，而且是很有可能出错的部分：

选择器引擎 - 我们将选择器部分的代码基本上重写了一遍，有一些边界情况现在可能还没有考虑到。
DOM操作(append/prepend/before/after) - 这部分代码大部分也被重写了，主要是在执行内联脚本的逻辑上。
.offset() - 又一个被完全重写的方法。
事件命名空间（Event Namespaces） - 处理命名的事件的逻辑被重写了。
事件触发机制（Event Triggering） - 现在触发事件的话，冒泡模型会一直关联到DOM，但这好像会在某些代码中引发问题。

我们在这里没有列举出jQuery 1.3中具体添加了哪些新特性，这个工作我们会等到最终发布的时候来做，初步计划是在2009年1月14日。对于大家将要提供的任何反馈，我代表jQuery团队表示由衷的感谢。

如何提供反馈

在jQuery bug tracker提交缺陷报告（当然你要先注册一个帐号）。
对于你所提交的，在测试过程中发现的问题，请确保附带一个简单的测试用例，也可以把发现问题网站的链接发给我们。
需要注意的是，我们需要你测试的版本是“jQuery 1.3 Beta 1”，不要弄错了。
将你的测试用例和缺陷报告邮寄给jQuery Dev list，这样开发团队就能及时关注你所发现的问题。

再次感谢所有参与测试的朋友，这将是一个非常棒的版本，我们已经迫不及待的想快点把她送到你身边。

FireUnit - 体验测试驱动的JavaScript开发

2008-12-23T00:19:00.007+08:00

FireUnit是一个Firefox扩展，同时也是一个Firebug扩展，这个扩展提供了一堆API可以帮助你实现JavaScript代码的单元测试，还在Firebug的一堆Tab中再增加一个用于显示测试结果。现在提供的还是很基本的测试，但是我们要相信这个扩展的潜力，因为它的作者是John Resig和Jan Odvarko，什么？没听过他们？小声问句，你听过JavaScript没有？

【原文标题】http://ejohn.org/blog/fireunit/
【原文作者】John Resig

以下内容是对原文的翻译：

在和Firebug团队一起工作的几个月里，我和Jan Odvarko尝试建立一种对JavaScript进行单元测试的方法，这段工作的最后成果是一个叫做FireUnit的Firefox/Firebug扩展。

FireUnit提供了一组JavaScript API，可以进行简单的单元测试，同时把结果显示在Firebug中新增的Tab栏下。

下面就是几个利用FireUnit API进行单元测试的例子（现在我们只提供一些基本的方法，以后就会扩展出更多的方法）。

// 最简单的true-like/false-like测试
fireunit.ok( true, "I'm going to pass!" );
fireunit.ok( false, "I'm going to fail!" );

// 比较两个字符串 - 并将差异显示出来
fireunit.compare(
"The lazy fox jumped over the log.",
"The lazy brown fox jumped the log.",
"Are these two strings the same?"
);

// 用正则表达式比较字符串
fireunit.reCompare(
/The .* fox jumped the log./,
"The lazy brown fox jumped the log.",
"Compare a string using a RegExp."
);

// 显示全部结果
fireunit.testDone();

单元测试的结果会显示在Firebug中叫做Test的Tab中（当然为了让FireUnit运行，必须先安装FireBug）。结果页面中的每一项都可以通过展开显示详细信息，包括测试的跟踪记录，以及字符串比较的区别等。

FireUnit也提供了一组方法，用于模拟本地的浏览器事件

// 你可以通过下面的方式模拟浏览器事件
var input = document.getElementsByTagName("input")[0];
fireunit.mouseDown( input );
fireunit.click( input );
fireunit.focus( input );
fireunit.key( input, "a" );

And a way of running a batch of test files (each of which would contain a number of individual tests).

// 或者可以一起运行多个页面的测试
fireunit.runTests("test2.html", "test3.html");

// 测试文件的结尾标识
fireunit.testDone();

我们通过这种方式设计了很多Firebug测试用例，尤其针对那些基于网络的功能。

现有的测试用例，只要通过简单的改写，就可以在FireUnit直接显示结果。

jQuery选择符的测试用例是由下面的代码片段组成的：

if ( typeof fireunit === "object" ) {
QUnit.log = fireunit.ok;
QUnit.done = fireunit.testDone;
}

这个测试用例的结果如下所示：

如果你要开始使用FireUnit，可以先去Fireunit.org看看，顺便下载最新版本。

你也可以到Github去下载源代码。

Jan也在自己的博客上写了一篇更加详细的文章，介绍我们如何在Firebug的开发过程中应用FireUnit。

这个项目现在还处在雏形阶段，还有很大的提升空间，我们需要大家的反馈。