jQuery 1.9 移除了 $.browser 的替代方法

jQuery 从 1.9 版开始,移除了 $.browser 和 $.browser.version , 取而代之的是 $.support 。 在更新的 2.0 版本中,将不再支持 IE 6/7/8。 以后,如果用户需要支持 IE 6/7/8,只能使用 jQuery 1.9。 如果要全面支持 IE,并混合使用 jQuery 1.9 和 2.0, 官方的解决方案是:

<!--[if lt IE 9]>
    <script src='jquery-1.9.0.js'></script>
<![endif]-->
<!--[if gte IE 9]>
    <script src='jquery-2.0.0.js'></script>
<![endif]-->

从长久来看,这样有利于在复杂情况下根据浏览器特性进行分别处理, 而不是简单的检测浏览器类型和版本。 但目前很多旧程序的移植恐怕无法直接过渡为根据浏览器支持特性, 所以在网上找了一些能够直接替换的解决办法。

判断浏览器类型:

$.browser.mozilla = /firefox/.test(navigator.userAgent.toLowerCase());
$.browser.webkit = /webkit/.test(navigator.userAgent.toLowerCase());
$.browser.opera = /opera/.test(navigator.userAgent.toLowerCase());
$.browser.msie = /msie/.test(navigator.userAgent.toLowerCase());

等号后面的表达式返回的就是 true/false, 可以直接用来替换原来的 $.browser.msie 等。

检查是否为 IE6:

// Old
if ($.browser.msie && 7 > $.browser.version) {}
// New
if ('undefined' == typeof(document.body.style.maxHeight)) {}

检查是否为 IE 6-8:

if (!$.support.leadingWhitespace) {}

终极方法是用另外的类库替代,比如 这个 , 但作者也不推荐使用浏览器类型和版本来进行判断。

参考

PHP foreach 中使用引用的注意事项

问题

先看一个例子:

<?php
$ar = array(1, 2, 3);
var_dump($ar);
foreach ($ar as &$v) {}
foreach ($ar as $v) {}
var_dump($ar);
?>

输出为:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}
array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  &int(2)
}

???为什么没有进行赋值操作,数组最后一个元素的值却发生了改变呢?

我早就发现了这个问题,一开始以为是 PHP 的 bug,就扔着没管它, foreach 中不使用引用就没事, 用 foreach $k => $v 然后 $ar[$k] 来改变原始数组, 略微损失点效率。

分析

今天花了点时间,看了 参考 中的文章, 算是稍微明白一点了,原来是这个样子的:

在执行第一个使用引用的 foreach 时, 一开始, $v 指向 $ar[0] 的存储空间,空间内存储着 1 , foreach 结束时, $v 指向 $ar[2] 的存储空间,空间内存储着 3 。 下面要开始执行第二个 foreach 了,注意和第一个 foreach 不同, 第二个 foreach 没有使用引用,那么就是赋值方式, 即将 $ar 的值依次 赋值$v 。 进行到第一个元素时,要将 $ar[0] 赋值给 $v 。 问题就在这里,由于刚刚执行完第一个 foreach, $v 不是一个新变量,而是已经存在的、指向 $ar[2] 的那个 引用 , 如此一来,对 $v 进行赋值的时候,就将 $ar[0] = 1 写入了 $ar[2] 的实际存储空间, 相当于对 $ar[2] 进行赋值。 依此类推,第二个 foreach 执行的结果, 就是数组的最后一个元素变成了倒数第二个元素的值。 参考文章 2 中有详细的示意图。

如果说这是一个错误,那么错误的原因就在于对引用变量的使用。 当引用变量指向和其他变量时,改变引用变量的值当然会影响到他指向的其他变量。 单独说谁都明白,但在这个 foreach 例子中,凑巧了, 同一个变量两次被使用,前一次是引用的身份,后一次是普通变量身份, 就产生了意料之外的效果。 PHP 的开发者也认为,这种情况属于语言特性造成的,不是 bug。 的确,如果要修复这个问题,一种方法是对 foreach 进行特殊处理之外, 另外一种就是限制 foreach 中 $v 的作用域, 这两种方式都与目前 PHP 的语言特性不符,开发人员不愿改, 但还是在 官方文档 中用 Warning 进行了说明。

解决方法

简单,但谈不上完美,就是在使用了引用的 foreach 之后, unset 掉 $v , 开始的例子改为:

<?php
$ar = array(1, 2, 3);
var_dump($ar);
foreach ($ar as &$v) {}
unset($v);
foreach ($ar as $v) {}
var_dump($ar);
?>

运行结果:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}
array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}

Git commit 注释格式

Git 本身并没有硬性限制注释的格式,不过,对于多人参与的项目来说, 好的注释风格更加有利于团队合作。 即使是自己用,也应当坚持实用好的注释风格, 一来是对自己的工作历史负责,二来得以养成好的注释习惯。 虽然这里标题说的是 Git,其他源代码控制系统也可以参考的。

可以先看看一些著名开源项目源代码管理系统当中的提交注释, 其中也有用 SVN 和 Bazaar 的, Apahe 的源码看不到 logview,可能是使用了 CVS 文件格式的原因:

结合其他参考文章,我总结 Git 的 推荐 注释风格如下:

  1. 第一行为对改动的简要总结,建议长度不超过 50,用语采用命令式而非过去式。

    Vim 很贴心,在默认配置下,注释的第一行文字颜色是黄色, 超过 50 列之后就变成白色了。

  2. 第一行结尾不要英文的句号 . ,中文的就也不要 吧。

    为啥?我给 rst2wp 提交的时候,对方也提出了这个要求 [1] [2] , 后来查了查,大概原因是,第一行被认为是一个“标题”,也会作为邮件标题, 而标题是不需要标点的。 上面那些开源项目也都遵守了这一规则。 不过也有 例外的

  3. 第二行为空行。

    如果配置了自动发送邮件,那么第一行就用来做邮件标题, 第三行开始的内容是邮件正文, 第二行是分隔线,用于区分两者。

  4. 第三行开始,是对改动的详细介绍,可以是多行内容,建议每行长度不超过 72。

    可以包括原因、做法、效果等很多内容,一切你认为与当前改动相关的。 为何是 72 长度呢?因为 git log 输出的时候能显示得比较好看, 前面 4 个空格作为缩进,后面留 4 个空格机动(英文按单词排版)。 Vim 的 gq 命令排版很方便。

    一些项目还对这个部分的内容有特殊要求,比如加一些特定标签什么的。

  5. 建议全部英文,首字母大写。如果一定要用中文,请尽量使用 UTF-8 编码。

  6. 大项目中,可以用 module/submodule: 前缀作为第一行的开头, 前缀首字母不必大写。

    前缀的冒号后面跟一个空格比较好看。 为了控制字符串长度,子模块名称可适当缩写,但应保持统一。

我以前喜欢在注释第一行加上 New: Add: Fix: 这样的前缀, 看来也是没有必要了。

Tips: 提交之前,用 git diff --check 可以检查有无空白字符错误, 比如行尾留有空白什么的。

BTW,在使用 Git 或者其他 SCM 时,还应当避免下面这些做法:

  • 把 SCM 当做备份工具。

    SCM 是项目/代码管理工具,备份功能只是“福利”。 随意将未完成测试或临时的工作结果进行提交, 不仅破坏日志的“纯洁性”,还不利于日后的浏览、整理、汇总等工作。 在开源项目中这么做的话,没人会接受这种提交。 如果确实需要备份当前工作异地继续的话,可以采用这样的折衷方法:

    $ git commit                # 在本地进行提交
    $ git format-patch -n1      # 导出 Patch
                                # 这个 Patch 就是你的备份
    $ git am Path_To_Patch_File # 如果换了工作地点,导入 Patch
    $ git reset --mixed [hash]  # 撤销提交,保留更改,继续工作
  • 一个改动不一次提交完成。

    “提交”的概念是具有独立的功能、修正等作用。 小可以小到只修改一行,大可以到改动很多文件, 但划分的标准不变,一个提交就是解决一个问题的。

    对格式的修正,不应该和其他功能修补一起提交, 这种情况应该考虑使用 git add --editgit add -p 也可以用用,更复杂和强大一些。

  • 注释不清晰。

    比如只有“修正 BUG”、“改错”、“升级”等,没有其他内容,等于没说。

参考

WordPress 烦人的 revision 和 auto-draft

revision 是早就有了,auto-draft 是最近才发现的,个人非常不喜欢这2个功能,偏偏 WordPress 还没有在后台中增加显式的关闭功能,所以更显得烦人。

revision 是你每保存一次 post 的时候,都把修改前的内容存成一个 revision,这样你就不用担心以前的版本找不到了。问题是,写 blog 又不是写代码,用得着这把牛刀么?就是写代码,也有不想保存的版本,基本上扔到 scm 里面就不会再看了呀。

禁用 revision 的方法,对目前的 WordPress 3.0 有效,在 wp-config.php 中添加:

define('WP_POST_REVISIONS', false);
define('AUTOSAVE_INTERVAL', 60000);

同时也禁止了自动保存,多手工保存吧,或者本地写好了再 post 。

auto-draft 是这样出现的,当你 new 一个 post 的时候,以前是第一次保存的时候生成 id,现在则是打开 new 页面的时候就生成了,体现在数据库中 wp_posts.post_statusauto-draft。这种没有内容先保存的方法一般是用来避免多人同时保存时的写入数据冲突,可一般的 blog 会频繁产生这种情况么?更糟糕的是,auto-draft 类型的post 无法在 Posts 管理中进行编辑,也就是说如果你打开了 new post 页面,输入了一些内容,然后没有保存或者发布就离开了这个页面,那么数据库中就多了一条 auto-draft “僵尸记录”,你再也找不到它了。

auto-draft 目前好像没有方法关闭,但可以从数据库中把他们更改为 draft,以后当草稿修改成新文章就是了:

mysql> SELECT DISTINCT post_status, COUNT(1) FROM wp_posts GROUP BY post_status;
mysql> UPDATE wp_posts SET post_status='draft' WHERE post_status='auto-draft';

最后,贡献一个 php 脚本,自动把 revision 和 auto-draft 都修改成草稿 draft,并且找出数据库中不连续的 post id,把他们也都存成草稿,这样可以保持 url 中 id 的连续性,似乎更加美观和整洁。未经严格测试,请参考使用:

可恶,被 PHP-Mcrypt 的官方 Example 误导了

在看 php 的 mcrypt 加密,想使用对称算法,解决小块内容(比如 url、post)网上传输的安全性。即加密、解密用同一个密码。官方文档有个非常完整的演示功能的例子,大概顺序是:

  • 打开 module
  • 生成 IV
  • 得到 key/密钥/密码
  • 初始化(引擎?)
  • 进行加密操作
  • 关闭(引擎?)
  • 重新初始化(引擎?)
  • 进行解密操作
  • 关闭(引擎?)
  • 关闭 module

加密、解密放在了一个代码片段中,大概是想说,加、解密就那一句代码不同而已。

按照这个理解,为了使用方便,我把加、解密分解成了2个函数,内容都和例子差不多,不会有错。但一运行,不管用哪种加密算法,都会出现奇怪的解密后与原文不一致的错误。还不是完全不一致,后面大半段内容都是正确的,比如原文是包含 a-z 26个字母的字符串,运行结果如下:

$ ./mcrypt.php 
Encrypt:
M~<5¶¤Jw^TÝ×. ÃV¯
Decrypt:
Âò¹ÁIijklmnopqrstuvwxyz

好一通找原因,最后在支持算法列表页面中找到这么一句:The IV must be unique and must be the same when decrypting/encrypting.加、解密时所使用的 IV 必须相同。

昏,例子代码中 IV 是使用随机数生成的,分成2个函数之后,加、解密操作生成的 IV 肯定不一样,这就是解密失败的原因。mcrypt_create_iv() 函数文档页面的 user notes 中有位 Chris 还对 IV 纠正了一些错误观点。

综上,正确解密需要将 IV 与密文一同存储、传递。而我的需求比较简单,就没有必要这么作,反正 IV 也不需要保密,所以直接用 key 的 sha1 值的片断,比如前8位(与 git 版本号简写类似)作为 IV,对安全性影响不大,应该是可以接受的。

问题解决,收工,有和我一样吃过亏的同学么?

Git 合并 patch 时的冲突处理一例

git version 1.6.0.4

几个新手刚刚开始接触 Git,为了维护核心仓库的“纯洁”,避免太多无关信息被误提交进仓库(再次批评一些图形化工具默认的“Select All”),采用了核心仓库只读,邮件提交 patch,审核后再提交的工作流程。

期间有时会遇到合并冲突,正常的原因一般是未及时下载新版本产生了冲突,特殊一点的原因是手工修改 patch 内容导致的。有时候看注释写得不够准确,忍不住就改了,有时候是 Geany 保存时自动去除了 patch 原文中的行尾空格,有时候是文件回车格式、BOM 等变动了,总之合并 patch 的时候,如果生成 patch 的“原稿”找不到,一般就产生了冲突,比如:

$ git am 0001-BUG-Sybase.patch
Applying: CHG: 读取Sybase如果时间为空,设置默认时间的修改
error: patch failed: source.php:38
error: source.php: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

刚开始一看有些懵,因为没有任何冲突在哪里的提示,后来找到一种方法,am 操作出问题后先手工 apply:

$ git apply --reject 0001-BUG-Sybase.patch
Checking patch source.php...
error: while searching for:
        // 注释
        // 以下为几行代码片断
error: patch failed: source.php:38
Applying patch source.php with 1 rejects...
Rejected hunk #1.

这样,就把没有冲突的文件先合并了,剩下有冲突的作了标记。先看输出,error: while searching for: 说明是这段代码有冲突,error: patch failed: source.php:38 指明了产生冲突的代码片断的开始行号,相应的,patch 中应该有这么一段:

diff --git a/source.php b/source.php
index 8770441..4e77b8a 100644
--- a/source.php
+++ b/source.php
@@ -38,27 +38,23 @@ class Site extends Module
        // 注释
        // 以下为几行代码片断

同时,还会产生一个 source.php.rej 文件,里面也是上面这段因为冲突无法合并的代码片断。

现在,在这段代码中查找冲突原因,并对文件进行修改,source.php.rej 参考完了可以删掉。改好之后,用 git add 把 source.php 添加到缓冲区,同时也要把其他没有冲突合并成功了的文件也加进来,因为在作 apply 操作的时候他们也发生了变化:

$ git add source.php
$ git add 其他 apply 进来的文件们

最后:

$ git am --resolved
Applying: CHG: 读取Sybase如果时间为空,设置默认时间的修改

大功告成。

中间如果处理乱了,用 git reset 恢复即可,所以合并 patch 在一个“干净”的分支上处理更好。