Thinking for Fun http://jsfox.cn/blog 网络 ● 生活 ● 技术 Tue, 01 Jun 2010 01:52:41 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 理清URL编码 http://jsfox.cn/blog/learning/understand-url-encodin.html http://jsfox.cn/blog/learning/understand-url-encodin.html#comments Mon, 31 May 2010 11:05:23 +0000 yongbin http://jsfox.cn/blog/?p=187 URL中，什么字符需要编码？

关于URL编码，RFC1738做了如下的规定：

“Only alphanumerics [0-9a-zA-Z], the special characters “$-_.+!*’(),” [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL.”

RFC继而说明了保留字、特殊符号、不安全字符的含义——也就是说，下面三类字符可以不经过编码，直接出现在URL上：

  • [0-9a-zA-Z]
  • 特殊字符：$-_.+!*’(),
  • 保留字符：&/:;=?@

为了让我们思路更清晰，我们再总结一下，哪些字符必须要编码：

  • ASCII表中没有对应可显示字符的，例如汉字
  • 不安全字符，包括：#”%<>[]{}|\^`~
  • 不当做保留字符来使用的保留字符，即&/:;=?@

详见这张图，一目了然（点击看大图）：

URL编码在ASCII表中的体现

URL编码在ASCII表中的体现

如何编码？

众所周知，字符是可由八位字节数（octet）来表示的，八位字节数可用十六进制来表示它的值。如字符“<”的八位字节数十六进制值是3C。在URL中，字符的编码方式为：“%”加上字符的两个十六进制数值。举几个例子：

  • “<”可以被编码为%3C，空格“SP”可被编码为“%20”
  • “田”的GB2312编码十六进制值是CC EF，这时“田”的URL编码为%CC%EF
  • “囧”的GBK编码十六进制值是87 E5，这时“囧”的URL编码为%87%E5
  • “田”的UTF-8编码十六进制值是E7 94 B0，这时“田”的URL编码为%E7%94%B0

URL中包含汉字时的更多话题

RFC1738没有规定汉字的编码方式，而是让浏览器自己去决定，因此造成了URL汉字编码的不统一。经过研究，对于URL中的“查询字符串”和“路径”中包含汉字，不同浏览器有不同的处理。

1. 查询字符串中包含汉字

在网址输入：http://www.baidu.com/s?wd=田囧 ，敲击回车，使用Fiddler观察浏览器发出的请求（以IE8和Firefox为例）：

查询字符串中含有中文

查询字符串中含有中文

IE8将汉字作为GBK编码，直接发往服务器（这其实是不符合RFC规范的）；Firefox则多了一次加%的操作。Windows操作系统是GBK编码。得到结论，地址栏直接访问URL，汉字作为查询字符串(Query string)时，IE和Firefox会使用系统编码发至服务器端，Firefox会按规矩编码。

注意1：不要用Google进行测试，Google的搜索URL（类似：http://www.google.com/#hl=en&source=hp&q=田囧 ），搜索关键词那里不是查询字符串，因为前面有个#……我开始没注意到，被搞迷茫了很久……

注意2：这只是对URL直接访问的规律。如果页面时从链接点击打开的，例如从A页面含中文的链接打开了B页面，那么浏览器对中文的编码取决于A页面的编码。

2. URL路径中包含汉字

在网址直接输入：http://www.hudong.com/wiki/田囧 ，敲击回车，观察请求：

路径中含有中文

路径中含有中文

IE8和Firefox都把汉字作为UTF8，按规范进行了URL编码，还好。

总结

什么字符应该编码，什么字符不用编码，URL编码的基本问题，到此已经解决啦。

]]> http://jsfox.cn/blog/learning/understand-url-encodin.html/feed 4 Web文档编码的指定 http://jsfox.cn/blog/learning/web-document-charset.html http://jsfox.cn/blog/learning/web-document-charset.html#comments Fri, 28 May 2010 02:32:36 +0000 yongbin http://jsfox.cn/blog/?p=182 Web开发中，文档常常指：(X)HTML文档、XML文档、CSS文档、js文档。指定文档编码的方式有以下几种：

HTTP Header中指定文档编码

在一个典型的HTTP响应头里，Content-Type的值中可以指定文档编码，如：

HTTP/1.1 200 OK
Date        Tue, 11 May 2010 04:09:22 GMT
Server      Apache
Content-Type    text/html; charset=gb2312

对于动态网页，用这种方式指定文档编码，在脚本中直接输出响应头即可：

header( 'Content-type: text/html; charset=gb2312' );

对于静态网页、CSS文件等，则需要在Apache等服务器中配置，例如：

AddType 'text/html; charset=gb2312' html

Content-Type meta元素中指定HTML文档编码

对于HTML文档（或当成HTML解析的XHTML文档），用这种方式指定文档编码，应在<head>标签 里的最上方，加入：

<meta http-equiv="Content-type" content="text/html; />

指定XML文档编码

对于XML文档，如果不指定编码，则一般会按照UTF-8来解析文档。指定编码的方式是在第一行加入：

<?xml version="1.0" encoding="gb2312"?>

HTML5的charset meta元素

我们潮一些，DOCTYPE为HTML5的文档，可以用带有meta标签的charset属性指定文档编码，类似于这 样：

<meta charset="gb2312">

用链接的charset属性指定编码

<a>, <link>, <script>元素都可以带有charset属性，用来指定目标文档的编码。例如：

详见：<a href="../index.html" charset="utf-8">老田的博客</a>。

但一般html的文档都采用其他方式指定编码，所以此方法常用于指定外部script脚本的文档编码，例如：

<script type="text/javascript" src="main.js" charset="gb2312"></script>

使用@charset指定CSS文档编码

如果CSS文档中存在非ASCII字符，为了不让浏览器费力去猜测编码，可以指定CSS文档的编码。一种方式是使用 @charset指定，在CSS文件的第一行：

@charset "utf-8";

编码指定方式的优先级

上述方式指定文档编码，会使用下面的优先级：

  1. HTTP响应头的Content-Type
  2. XML的首行声明
  3. meta标签charset声明
  4. 链接的charset属性

例如对于一个CSS文件，它的编码优先级会按照下面的顺序指定：

  1. HTTP Content-Type
  2. @charset rule
  3. <link charset=”..” rel=”stylesheet” … />

总结

本文总结了Web文档（包括HTML, XHTML, XML, CSS, JS）的编码指定方式。比较常见的是(X)HTML文档中用meta标签指定编码，但优先级不如HTTP响应头高。外部js/css文件指定编码的方法也不尽相同，js文件用引用它的script tag charset attribute指定，css文件用文件开头的@charset指定。

]]> http://jsfox.cn/blog/learning/web-document-charset.html/feed 0 HTML5 历史、现状及未来 http://jsfox.cn/blog/others/html5-history-and-future.html http://jsfox.cn/blog/others/html5-history-and-future.html#comments Tue, 20 Apr 2010 11:31:38 +0000 yongbin http://jsfox.cn/blog/?p=179 分享一下HTML5的东西。

HTML5 历史、现状及未来

View more presentations from Yongbin Tian.

]]> http://jsfox.cn/blog/others/html5-history-and-future.html/feed 0 Even Faster Web Sites: 读书笔记(二) http://jsfox.cn/blog/javascript/even-faster-websites-notes2.html http://jsfox.cn/blog/javascript/even-faster-websites-notes2.html#comments Sun, 24 Jan 2010 08:54:18 +0000 yongbin http://jsfox.cn/blog/?p=170 这次因为一个项目的原因，又重读了《Even Faster Web Sites》书里的第四章：Loading scripts without blocking，并且在Cuzillion里做了大量测试，又发现了很多有意思的细节。发现自己读书太糙，自责一下。结合实际工作，加上自己的理解，再把这一章的实用内容总结一下。

要解决的问题

页面的script标签引入外部js文件时，会阻塞后续外部资源的下载和加载，包括图片、CSS文件、iframe等等。

1. Script DOM Element比较常用

“Script DOM Element”方法是常见的方法，也就是createElement(“script”)的方法下载js文件，以此并行加载后续资源。这其实是很棒的一个方法，因为不需要担心跨域，而且我们在中文应用中，不用担心编码的问题（可以为<script>指定编码）。但这里需要注意的是，非IE浏览器下，这种方法会阻止window.onload事件，因此如果你的js文件很大，可能会带来用户体验不好。IE浏览器对这种贴script标签的行为是“无动于衷”的，不会在状态栏、光标和进度圈上做任何指示。看来IE也不是一无是处嘛，哈哈！测试地址。

2. 个人不提倡使用XHR Eval

XHR Eval方法我不提倡使用，首先是中文编码上会遇到麻烦，其次跨域问题。另外就是下面这句：

eval(xhrObj.responseText);

当js文件比较大的时候，用eval会相对较慢，并带来安全性隐患。

3. XHR Inject是个好东西

如果编码和跨域问题都不是问题，那么XHR Inject就是最好的方法了。这是XHR Eval和DOM Script的一个这种办法，实现机制就是：

var s = document.createElement('script');
s.text = xhrObj.responseText;

这种方法避开了evil eval，并且和DOM Script一样，可以按顺序加载js文件，当然，不会阻塞后续资源的加载。更为重要的是，在所有浏览器下，这种方法都不会阻止渲染和onload事件，体现了XMLHTTPRequest的本色。测试地址在此。

4. defer属性可以快速尝试

Script标签的defer属性，可以让后续资源并行加载。在实际的项目中，偶尔也可以尝试使用，因为比较快捷。Firefox 3.1以后，也开始支持script的defer属性啦。

5. document.write(“a.js”)的注意事项

注意：在<head>用document.write来插入js脚本，只能让浏览器并行加载<head>里的资源。也就是说，<head>里write脚本，会阻塞<body>的加载。测试地址。另外关于document.write，还有两个需要注意的问题。第一，它只能带来“并行加载js文件”的效果，对其他资源无效；第二，IE、Chrome支持，Firefox不支持。

6. Script in Iframe方法强烈不赞同

在iframe放js，来实现页面资源并行加载，无疑是得不偿失的行为。首先，iframe太沉重了；其次，你还得改你的js代码。反正我是不能接受的，哈哈。

结束语

在开发中，如果要加载数个js大文件，比较实际的做法还是插入script标签的方法。如果没有编码和跨域问题，用XHR Inject方法当然更好啦。

欢迎指正！

]]> http://jsfox.cn/blog/javascript/even-faster-websites-notes2.html/feed 0 只做题，先不说话 http://jsfox.cn/blog/javascript/understanding-javascript-prototype-chain.html http://jsfox.cn/blog/javascript/understanding-javascript-prototype-chain.html#comments Thu, 03 Sep 2009 08:29:50 +0000 yongbin http://jsfox.cn/blog/?p=161 已知：

var str = "string";
var Fn = function() {var i;};
var f = new Fn();

下面的语句执行结果，你能说对几个？

   1. str.__proto__
   2. str.prototype
   3. str.constructor
   4. str.__proto__.constructor
   5. Fn.__proto__
   6. Fn.prototype
   7. Fn.constructor
   8. Fn.__proto__.constructor
   9. Fn.__proto__.__proto__
  10. f.__proto__
  11. f.prototype
  12. f.constructor
  13. f.__proto__.constructor
  14. f.__proto__.__proto__

测试页面：test_proto.html

]]> http://jsfox.cn/blog/javascript/understanding-javascript-prototype-chain.html/feed 3 Even Faster Web Sites: 读书笔记(一) http://jsfox.cn/blog/javascript/even-faster-websites-notes1.html http://jsfox.cn/blog/javascript/even-faster-websites-notes1.html#comments Fri, 21 Aug 2009 04:31:43 +0000 yongbin http://jsfox.cn/blog/?p=156 《Even Faster Web Sites》是Steve Souders的新书。Steve Souders现在是Google工程师，《High Performance Web Sites》一书的作者，Google Web Ex系列讲座的主持人，对前端优化有很专业的研究。他的UA Profiler和Cuzillion项目尤其引人注目。

《High Performance Web Sites》这本书相信大家都比较熟悉，Souders在其中主要讲解了Yahoo!的14条网站性能军规。很是期待这本《Even Faster Web Sites》，可惜国内市面上还没有。偶得电子版一套，迫不及待打印出来，细细读来。

这本书只有一多半是Souders写的，其他部分是Crockford, NCZ等人的贡献，因此十分有内容。这次先记一些关于页面加载性能方面的读书笔记。

Splitting the initial payload

要提高前端性能，可以这样：页面在第一次加载时，只加载渲染页面所需要的资源（主要针对js），以及一个ScriptLoader方法。其他js资源在需要的时候再动态加载。这样做的挑战就是分离用于初次渲染的js资源，也就是找到split。微软有一个Doloto项目是做这个的，但Doloto还没有向外公布，所以我们得手动搞分裂了。

Loading scripts without blocking

外部js文件在下载和执行时，大多数浏览器都会阻塞其后面的内容（ps这也是可以理解的）。要防止这种阻塞，有若干种办法。我们比较常用的大概是XHR注入和Script tag。Souders还介绍了XHR Eval, Script in Iframe, Script Defer, document.write(<script>)等，并且画出了决策树。这些方法原理都是用异步加载外部js文件，以提高页面渲染速度。方法类似于我们用script tag来实现类ajax跨域应用。

大家可以用Cuzillion来真实测试一下堵塞情形，非常有意思，非常有必要，非常好。

前两天NCZ在他的博客上也对这种异步加载作了介绍，The best way to load external JavaScript。他认为这项技术的best practice是，首先写一个scriptLoader.js，再把页面所需要的其他js都放在second.js里，把scriptLoader.js放在</body>之前，再紧跟行内js加载second.js文件。确实不错，而且YUI和Google Analytics都这么做了。

那么到底用哪种方法来做script loader呢，在实际应用中，我认为如果不需要跨域、不考虑多个js文件加载顺序的话，XHR Injection最好，因为它不会阻塞onload事件（发现TinyMCE加载插件就是这个原理）；否则的话，就是用script tag方法。

Positioning inline scripts

行内js在执行时，会阻塞其后内容的并行加载、页面渲染。顺便说，如果执行时间过长（100ms以上），用户会感觉到卡，体验非常不好。为了防止阻塞，可以用setTimeout来实现异步调用。那么文档下载完之后，为了给浏览器喘息的机会（进行渲染），延时多久才让这些js执行呢，IE下0ms即可，Firefox下是250ms。

另外有一个大忌，就是外部css文件紧跟行内js的情况。这样会造成比较严重的阻塞。是什么原因呢？行内js一般不会被阻塞，除非代码前面有css。

<link rel='stylesheet' type='text/css' href='a.css' />
<script type="text/javascript">
// do a lot of things
</script>

假如行内js前有一个外部css文件（如上述代码），那么这段js要等到css文件完全下载完才会被执行，js被阻塞，造成了页面剩余内容被阻塞，恶劣的连锁反应被引发。

先总结这么多，欢迎指正！

]]> http://jsfox.cn/blog/javascript/even-faster-websites-notes1.html/feed 7 获得原始href属性的方法 http://jsfox.cn/blog/javascript/get-right-href-attribute.html http://jsfox.cn/blog/javascript/get-right-href-attribute.html#comments Sat, 08 Aug 2009 05:35:16 +0000 yongbin http://jsfox.cn/blog/?p=141 JavaScript里得到某个链接的href属性时，有三种方式，总结一下：

1. 直接获得href属性，也就是

var url = el.href;  // el是一个a元素

2. 使用getAttribute方法，像这样：

var url = el.getAttribute("href");

3. IE下的getAttribute方法有第二个参数，参见msdn的这篇。第二个参数如果是2，意思是以字符串形式返回。

var url = el.getAttribute("href", 2);

获得href属性的这三种方法，同样的，有三点，让人很费解，而且浏览器实现各不相同。

  1. 如果href写的是相对地址，得到属性时，浏览器可能会自动转为绝对地址。（很多情况下我们是不希望这样的）
  2. 如果href里有汉字，浏览器会自动编码吗？
  3. 如果href里有特殊字符，浏览器会自动编码吗？例如大括号{}。

为此我做了一个小测试页面（点这里可测试），得到了如下的结果：

获得href和src属性的浏览器差异（相对地址与自动编码情况）
.href getAttribute(“href”) getAttribute(“href”, 2)
IE6 转绝对，不编码 转绝对，不编码 正常
IE7 转绝对，汉字不编码，特殊符号编码 转绝对，汉字不编码，特殊符号编码 正常
IE8 as IE7 转绝对，汉字不编码，特殊符号编码 转绝对，汉字不编码，特殊符号编码 正常
IE8 standard 转绝对，汉字不编码，特殊符号编码 正常 正常
Firefox 3.0+ 转绝对，全部编码 正常 正常
Chrome 2.0 转绝对，全部编码 正常 正常
Safari 4.0 转绝对，汉字编码，特殊符号不编码 正常 正常
Opera 10.0beta 转绝对，汉字编码，特殊符号不编码 正常 正常

其中，“正常”的意思是，得到href属性里原始链接，不自动转绝对地址、汉字和符号都不编码。

结论，如果想得到href里的未经转换、未经编码的原始内容，IE浏览器下全部使用getAttribute(“href”, 2)，其他浏览器下使用getAttribute(“href”)即可，这在序列化DOM时会非常有用；如果想得到绝对地址、编不编码没关系，那就用href属性。

]]> http://jsfox.cn/blog/javascript/get-right-href-attribute.html/feed 4 JavaScript调试技巧之：断点调试(2) http://jsfox.cn/blog/javascript/debug-js-using-break-points-part2.html http://jsfox.cn/blog/javascript/debug-js-using-break-points-part2.html#comments Tue, 04 Aug 2009 06:31:47 +0000 yongbin http://jsfox.cn/blog/?p=116 上次总结了Firefox下进行JavaScript断点调试的技巧，这次来看一下其他浏览器下的调试。一点说明，这里的调试技巧都不借助于浏览器之外的工具，例如Aptana，VS2008等。如果要找这方面的一些资料，我这里没有哈。

其他浏览器，主要是Opera, Safari, Chrome和IE8。这之中除了IE8，它们的调试功能都挺不错的，基本都可以搜索脚本，加入断点，查看调用栈、本地变量，以及强大的console。

1. 使用Opera的Dragonfly进行断点调试

使用Opera进行断点调试

使用Opera Dragonfly进行断点调试

打开Tools – Advanced – Developer Tools，即可看到类似于Firebug的开发工具，名字叫做Dragonfly，也就是蜻蜓。在这里可以查看页面结构，查看网络交互，以及断点调试，并且可以在调试过程中使用Command Line (console)。

Opera on WindowsXP也属于YUI要支持的A-grade（详见此表格），所以我们在开发的时候，也要尽量去支持。此外Dragonfly的DOM查看工具有一个亮点，Export current DOM view。我们可以在线做一些DOM改动，然后Export一下，即可得到改动后的HTML代码，非常方便。

2. 使用Chrome和Safari进行断点调试

如果你觉得Opera太小众，那么你可以在Safari或者Chrome上进行调试。两个浏览器的调试方式、界面极其相似，所以这里以Safari 4.0为例。打开Menu – Develop – Start Debugging JavaScript，即可弹出一个调试工具。值得一提的是，Safari和Chrome的调试工具最好不要Dock到浏览器下面，因为弹出来的话，调试界面是刚刚好的。

首先找到要调试的脚本：

使用Safari进行JavaScript调试：找到脚本

使用Safari进行JavaScript调试：找到脚本

设置断点，重新加载页面（或者执行动作）：

使用Safari进行JavaScript调试：设置断点

使用Safari进行JavaScript调试：设置断点

在右侧查看本地变量和函数调用栈：

使用Safari进行JavaScript调试：变量查看

使用Safari进行JavaScript调试：变量查看

Safari的调试工具一个亮点是，console和断点调试在同一个界面上，这样可以非常方便地在程序中断时，利用console来做一些验证操作。

3. IE8的断点调试功能

IE8自带的开发者工具，虽然极其难用，但也可以断点调试。断点调试的方法与上述雷同。

使用IE8开发者工具进行断点调试

使用IE8开发者工具进行断点调试

可以看到，IE8似乎莫名其妙地终止了js代码的识别。这样的话，从74行往后，都没办法加断点了，真不可思议。但我们有时为了兼容IE，不得不在IE下进行一些调试，怎么办呢？可以用上一篇文章的办法，在需要中断的位置加入debugger语句，这样程序运行时，IE8就会中断在debugger语句上了。

总结

有时候我们为了实现JavaScript程序的cross-browser，即兼容若干浏览器版本，会希望在不同浏览器上进行调试。IE8开发者工具出现之后，几大浏览器都可以调试了。先不论好不好用，总算都有了！

我的个人习惯是：对于一般的功能性调试，使用Firebug即可满足需求。Firefox扩展开发需要调试的，使用JavaScript Debugger（Venkman），页面脚本一般不用这个，因为它启动比较慢。对于浏览器兼容性需要的调试，使用该浏览器的开发者工具即可。对于IE6的调试……%￥……%……&×&×#￥%￥@@，我是没别的办法，只能用眼睛来调了……

欢迎交流！

]]> http://jsfox.cn/blog/javascript/debug-js-using-break-points-part2.html/feed 2 JavaScript调试技巧之：断点调试(1) http://jsfox.cn/blog/javascript/debug-js-using-break-points-part1.html http://jsfox.cn/blog/javascript/debug-js-using-break-points-part1.html#comments Mon, 03 Aug 2009 16:26:00 +0000 yongbin http://jsfox.cn/blog/?p=77 如果您还没有阅读《JavaScript调试技巧之：快速定位》，建议先看看那篇。说不定，用快速定位就能解决问题了，呵呵。这次我会总结记录一下断点调试的笔记，希望也对大家有用，欢迎补充交流！

首先，在各个浏览器中，断点调试支持的最好的当然是Firefox，Firefox不仅可以使用Firebug调试页面js脚本，还可以用高级调试工具例如JavaScript Debugger (Venkman) 来调试Firefox扩展里的js。除此之外，Firefox还支持一些更为高级的断点调试、变量监视功能。

其他浏览器里，Opera、Chrome和Safari的调试功能也比较好用。Opera的DragonFly速度相对比较快，界面清爽，功能强大，但不如Safari等友好。相比来说，IE8的程序员工具简直没法用。

这次时间有限，先来总结一下Firefox下的调试技巧。

1. 使用Firebug进行断点调试

使用Firebug调试JavaScript非常方便。具体步骤：

a. 打开Firebug后，启用“脚本”调试，找到引用的脚本文件（或者行内js）；

用Firebug找到要调试的脚本（点击放大）

用Firebug找到要调试的脚本（点击放大）

b. 在适当的位置加入断点；

c. 如果断点已经执行过，则刷新页面，这时脚本就会在断点处中断。如果断点没有执行过，那可以直接执行页面上的动作（例如点击按钮等），然后代码会在断点处中断；

用Firebug进行断点调试

用Firebug进行断点调试（点击放大）

d. 观察函数调用栈，观察local变量，也可以进行单步执行，进行调试。

确实非常简单！用Firebug断点调试的优点总结如下：

  • 能加断点的行用绿色行号，非常直观；
  • call stack用两种方式显示出来，很方便；
  • 本地变量的显示非常清晰明了。

2. 使用JavaScript Debugger进行断点调试

这是老牌的调试工具，之前叫做Venkman，可以以扩展形式安装在Firefox上，我们在这里就称他为Venkman吧。它不仅能够调试页面脚本，还能调试Firefox扩展（extension）里的js。我们在做Firefox扩展开发时，Venkman是必不可少的工具，老田强力推荐！当然，Firefox本身的逻辑实现，也是用JavaScript来做到的。我们现在可以用Venkman来调试一下Firefox本身。Firefox的核心js是browser.js，在这个路径下：

chrome://browser/content/browser.js

我们打开Venkman之后，在Loaded Scripts里填入browser.js，这个js文件就会被过滤出来（如果没有看到browser.js，那么你可能需要查一下是否选上了Debug->Exclude browser files）。

Venkman：选择要调试的js文件

Venkman：选择要调试的js文件（点击放大）

我们找到让浏览器后退的代码，然后点击Firefox的后退按钮，这时Venkman就会停在BrowserBack方法上！让我们再一步一步地看一看，Firefox自己到底做了什么。btw，实现Firefox的js代码也不是很漂亮嘛~~~

用JavaScript Debugger调试Firefox

用JavaScript Debugger断点调试Firefox（点击放大）

Venkman当然也带有一个console，利用这个console，我们可以看一看浏览器层次的window和document都是什么东西。类似于Firebug和其他浏览器的console，只要直接输入js代码片段即可！

使用Venkman自带的console

使用Venkman自带的console（点击放大）

有兴趣的话，可以在这里发现更多有关Firefox开发（以及扩展开发）的好玩的东西！

3. 使用debugger在程序中加入断点

另外还有一个少为人知的断点加入方法。我们可以在程序中加入debugger语句，这样Firefox的调试工具会停留在这条语句上，代码也暂停执行，和加入断点的效果一样。例如：

var myfunc = {
    get_field_value_callback : function() {
        debugger;
        var ed = this, target = ed.currSpan;
        /* do something more */
    }
}

这时重新加载页面，断点就会停留在debugger语句上。这样，我们就可以在写代码时随心所欲地加入断点了。另外，其他浏览器（包括IE8！Surprise！）同样支持debugger语句！

]]> http://jsfox.cn/blog/javascript/debug-js-using-break-points-part1.html/feed 2 夏暮观海——BeijingOpenParty见闻与收获 http://jsfox.cn/blog/events/july-09-beijing-open-party.html http://jsfox.cn/blog/events/july-09-beijing-open-party.html#comments Mon, 27 Jul 2009 16:42:43 +0000 yongbin http://jsfox.cn/blog/?p=80 这次的Open Party颇为热闹。首先去的人比较多，其次是遇到很多同行熟人，交流起来非常亲切。总结一下见闻与收获。

遇到了MozillaOnline的Wendy和SunBin，他们带工程师来讲解了Firefox3.5的新特性。因为之前关注了Upgrade the web in 35 days，所以这些新特性我不算陌生。最后赶上了Wendy带来的Firefox3.5 cheese蛋糕，幸福得很哪！另外Wendy介绍我认识了Bastien，一个法国佬，下周举办OSWER‘09 Camp Week 2，一个探索教育中的开源软件应用的活动。在这里做一下广告，这个活动的注册地址是这里，大家踊跃参加啊。我会去参加8月1日的活动，会介绍一下Firefox南开校园版的开发情况。另外Bastien向我介绍了他们的olpc，意思是One Laptop per Child，一个给小孩用的小型开源操作系统，基于Linux和XULRunner，使用非常简单，并且加入了social networks概念。有机会我再详细了解一下。

Firefox 3.5 Cheese Cake

Firefox 3.5 Cheese Cake

和Jacky聊了聊Real-Time Web在国内的现状。Jacky一直试图推广他的实时web技术，但是似乎不是很成功。（在这里再做一下广告，他的site好象是playii.com）。Real-Time Web是我前一段时间研究过的，如果我们像lightstreamer.com那样，实现一整套技术，包括前端、服务器端，polling、long polling、push技术等等，并且做一套很酷的demo，开发完整的文档——我想这个东西在国内还是可以推广的。

黄修源，以前在豆瓣的设计师，《豆瓣，流行的秘密》一书作者，讲解了他的创业经历和对B2C的理解。虽然他大部分时间是在炫耀自己的番茄树网站，但是听听也很有意思。我尤其印象深刻的是，这些小孩做事情真是非常认真。他的题目是变轻的B2C，在市场日益细分的今天，B2C业务会越来越专一和轻量。

张韡武，一个做事也非常认真老道的人，在这次OpenParty上讲解了给企业用户推广Ubuntu的案例。大学读书期间就创办了锐业软服，“左眼看需求，右眼看实现； 左手写材料，右手写程序”，让人佩服。另外他总结的“网上商店及网上银行非Windows平台兼容性列表”，很有ppk的精神。

写完才发现，这篇竟有软文的嫌疑！其实最大的收获还是在于开阔了眼界，不会让自己眼里全部都是js代码。不过说软文就软文吧，都是朋友，呵呵。

]]> http://jsfox.cn/blog/events/july-09-beijing-open-party.html/feed 1