由多名网友联名发起的Javascript裸奔日 (Javascript Naded Day)活动，欢迎有兴趣的朋友参加。
- 11 2009. 04
-
Javascript 裸奔日
- 02 2010. 02
-
禁用CNNIC的所谓安全证书
我个人是不信任 CNNIC 的，这里只是记录一下自己的学习过程，对 CNNIC 仍抱有幻想的同学可以无视。
我都是在他人的教学指导下学习实践的，有兴趣的可以参考下面的链接：
CNNIC CA：最最最严重安全警告！
CNNIC，我不信任你！——从“受信任的根证书”里赶走CNNIC
如何阻止不信任的 CNNIC 证书
Mac 下禁用 CNNIC CA 证书
linux下的chromium删除CNNIC的CA
- 30 2010. 01
-
“正则表达式”分享资料
这周三做了一次内部“正则表达式”分享活动，本来是针对小组成员的分享，结果部门很多高手也来捧场，非常荣幸。
有兴趣的朋友可以下载 RegExp.zip 这个资料。我使用 XMind 做的一个分享大纲，从简介，基础、高级语法，一些经典的案例和有趣的用法。另外还附有一些有用或有趣的资料。
这是我生平第一次较正式的分享（上次是项目启动，没有什么实质的分享内容），由于没有什么经验，所以准备的相对比较充分，不过分享过程中的演说和演示的比提纲中的更丰满，同事参与的探讨也非常热情。
- 26 2010. 01
-
让Editplus和Everything结合，快速搜索
今天朋友向我分享了他新学的一个小技巧：将 Everything 搜索集成到 Editplus。
毫无疑问，Everything是NTFS磁盘下，本地文件快速搜索的极品，而Editplus也是Windows下非常优秀的文本编辑器。
虽然 Editplus 本身也有文件搜索功能，而且支持内容搜索，不过这个集成也非常有意思。
- 首先需要安装（绿色的也可以）有Everything本身。
- 下载面向命令行界面的 es.exe 2 程序，放至 Everything 安装目录。
- 打开 Editplus ， “工具” -> “配置用户工具” -> “添加工具”
- “菜单文本”可以随便命名，
- “命令”填入es.exe 所在的完整路径，如
E:\Everything\es.exe - “参数”填
$(FileDir) $(CurSel) - 选中捕获输出
- 确定，现在选中一串文本，就可以使用
<Ctrl-N>快捷键或菜单执行搜索了，搜索结果集会输出在输出窗口中。
谢谢晓东的分享。有时间的话可以为 Vim 也写一个插件，搜索结果在 QuickFix 窗口中输出。
注意：一定要记得先选定文本一串，否则会搜索出所有的文件，如果参数没有加入当前文件所在的目录，还会更惨 ^_^! 。不过作为 Vim 插件就可以更灵活了，不需要选定文本，直接执行类似命令就可以了。
:ES ${keyword}[ ${path}]
- 26 2010. 01
-
正则表达式重复子模式前、后倾的性能比较
在准备内部的正则表达式(Regular Expression)分享的过程中，注意到一个细节问题：重复的子模式，是应该前倾还是后倾，这两者在性能上有什么差异？
前倾和后倾是我胡诌的两个词，我的定义如下：
前倾就是前面的子表达式使用贪婪匹配或较大的量词，尽可能多的匹配内容，导致前面匹配的内容较多而使“天平”前倾。例如：/(?:\d{1,3}\.){3}\d{1,3}/。
后倾则相反，后面的子表达式使用贪婪匹配或较大的量词。如：/\d{1,3}(?:\.\d{1,3}){3}/。前倾和后倾在实际应用中很常见，如时间，主机名等，中间以某特殊字符（串?）分隔，被分隔部分的规则又相同的情况下，一般都是使用这两种实现方式之一。
上面定义中的两个例子只是简例，可以用来大致匹配 IPv4 地址，完整的 IPv4 地址正则式如下，它要求每段都在 0-255 之间：
前倾：/^(?:(?:[0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}(?:[0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$/后倾：
/^(?:[0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(?:\.(?:[0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])){3}$/我写了一个测试比较这两个正则性能的页面，在 IE7, FF3.6, Safari 4, Opera 10 下测试均为前倾的性能较高，Chrome 4 下则不相伯仲。
p.s. 这种重复子模式，要有语法上的简写就好了，像 Perl 正则的递归引用（或类似运行时反向引用），维护起来就方便多了。
- 07 2010. 01
-
arguments to Array 之效率
怿飞昨天发有一篇《如何将函数的实际参数转换成数组》的日志，其实核心不是讲“如何如何”，而是比较了几种算法/语法的效率。说到算法本身的性能，我和 army 的看法一样，对这篇日志的观点提出质疑。
从语法原理上，
Array.prototype.slice.call(arguments)是对数组的slice方法的原型直接引用，而[].slice.call(arguments)则需要创建数组对象。没有理由后者比前者的性能还要高的。不过我还是写了测试来证实自己的观点，为了尽量少的避免其他干扰（包括函数调用带来的消耗），算法/语法都直接内联写在计时器一起。
这几个例子分别比较了：
Array.apply(this,arguments)Array.prototype.slice.call(arguments)[].slice.call(arguments)- Prototype 的
$A(arguments) - jQuery 的
makeArray(arguments) - 和最土的循环算法。
并在各个浏览器（Multi IE 6, IETester 5.5, IETester 6, IE 7, FF 3.5, Chrome 4, Safari 4, Opera 10）下一一测试。也欢迎各位参与测试并将结果提交给我，如果你觉得测试有不公平合理的地方也可以提出。
至于结论，也不是那么好确定，不过大致如下：
Array.apply(this,arguments)在大部分情况下都能取得优胜；
而Prototype和jQuery其次，不过这两者不仅仅是针对arguments编写而且是直接调用其函数（稍有消耗），这里只拿来比较一下，这两个还是非常出色的；
Array.prototype.slice.call(arguments)和[].slice.call(arguments)则旗鼓相当，并没有说谁比谁一定更强，更浏览器实现有关，在部分浏览器中前者有稳定的微量优势；
至于老土的循环法，arguments.length 较小时表现不俗，较大时也更浏览器有关系。
而怿飞说的那点（不确定的）非关键或巨大性能优势，其实意义不大。延伸阅读：
正则表达式拼接和构建零长度对象
Javascript String 方法效率大比拼
Javascript相等符(==)与完全相等符(===)之效率
- 06 2010. 01
-
让索引和内容靠的更近
我在看淘宝新首页的类目时，眼睛总是不自觉的先看靠右的细类目，因为它占有更大的面积，更容易被扫视。但实际上先看左侧定位大类目，再找更为精确的细类目可以更快的发现目标。
我粗略画了一张样图，展示如何让大类目更容易被扫视。
人眼的深浅远近调节比上下左右转动似乎要舒服的多。
图片本身还可以做的更好更有层次感，或者你也有其他的方案欢迎交流。