Flash 无法修改设置的问题

Adobe flash player settings

这个怪怪的问题也不是一天两天了,就是 flash 设置窗口,或者当 flash 游戏需要使用本地存储空间时,自动弹出的设置窗口,这个窗口无法用鼠标点击,用键盘 TAB 键能在各部分之间游荡但还是无法调整设置,基本上就卡死在这里了。

遇到这种情况,可以访问这个链接:http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html,注意链接中并不是图片,而是实际的设置调整组件。比如刚才说的访问本地资源需要确认的问题,在这里设置成Never Ask Again,同网站的资源就再也不会弹出窗口导致 flash 卡死了。

Ubuntu 9.04, Firefox 3.0.13, Flash Player 10.0 r32.

参考:

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 在一个“干净”的分支上处理更好。

压缩网页图片

不压不知道,一压吓一跳,大部分图片几乎都能在近似无损的情况下压缩掉 65% 原始大小左右,如果指明有损压缩,比如 jpeg 的 85 %,还能更小。

Smush.it

smushit 现在已经属于 Yslow 的一部分了,可以通过 firefox 插件使用,也能在线用,缺点就是你的图片必须能够从公网访问。

可以压缩各种图片,按照官方的解释,它会尝试各种工具和算法,找到最优的方式。因此,smushit 是一种很安全的压缩工具,几乎看不到差别,就是用起来麻烦些。

imagemagick

不同的图片格式有各自的特点,比如 gif 善于存储颜色较少的图片,也是动画图片的首选;png 善于存储能够矢量化的图片,jpg 则善于存储颜色、图片变化都比较多的图片。根据不同的图片特点,进行类型转换,有时能收到不错的效果。

图片 convert 之后,还可以利用其它工具进一步压缩,不过效果不大了。

另附一个转换图片类型之后,批量替换模板中调用文件名的脚本:

grep logo.gif * -R | awk '{print $1}' | sed 's/://' | xargs -I '{}' sed -i 's/logo.gif/logo.jpg/' '{}'

jpegoptim

这是今天刚发现的好东西,ubuntu 源中有,主要可以用它去除 jpg 图片文件当中的 comment exif IPTC 等无用标记,我测试的情况压缩率比 smushit 略低一点点。由于能够通过命令行使用,所以易用性更强。

一般我喜欢用 --strip-all 参数去除所有无用内容,实际压缩之前可以用 -n 参数预测一下压缩率(默认直接压缩覆盖源文件了),24bit Adobe 类型的图片基本上都能够压缩掉 65% 原始大小,碰到 24bit JFIF 这种类型的图片一般压不动,但带上有损压缩参数比如 -m85之后,依然能够达到较理想的压缩率,并且图片损失效果不明显。

遇到无法压缩的图片、压缩后体积反而增大的图片会自动跳过,很贴心。

基本上,有了上面三种方式,就能够处理大部分网页图片了。

[Git]初学者注意事项

实在是受不了有些人的 Git 提交,费大力气“回滚”,遂整理了这些刚开始用 git 或者还没有建立 scm 概念时容易犯的错误。

和源码无关的东西,尽量不要进仓库

不得不说一些图形化软件,在提交内容的时候大多提供一个“全选”或者“Select All”功能,这是最不好的了,一些懒惰的同志看都不看就连瓢带碗都提交了。

  • 测试时上传的文件,测试时的临时文件,统统不要
  • 对应上一条,强烈建议把所有文件的上传保存目录另行设置,放到源代码目录以外
  • 编辑器产生的备份文件、临时文件,编译时的中间文件,统统不要
  • 对应上一条,有个例外就是为了实现通过 Git 更新系统,.NET 的 bin 文件要进仓库,导致那个仓库现在都 100+m 了
  • 图片等资源文件,进仓库也可以,但应当使用有意义的文件名,便于后期管理
  • 对应上一条,现在设计网站界面喜欢先作图然后切割,产生一大堆 001_r5_c1.jpg 这样的文件,讨厌之极
  • 使用的外部类库,比如 php 类、js 类等,统统扔到源码目录以外,如果实在没办法要放在目录树中,也可以留出空目录,打包发行的时候再包含进来,依然不进代码仓库
  • 不要中文文件名,主要是跨平台使用有问题,文件名完全能够只用字母数字减号下划线

尽量采用相对小、相对独立的提交

Git 是作什么用的?Git 不是代码上传工具,也不是网站更新工具,而是软件开发过程的记录工具,为了更加准确的定位每个问题、每个功能修改,就需要在每完成一部分可以称得上是“一项”的工作时,就 commit 一次。哪怕只是修改了一两行,只要产生了必要的功能改变,就有价值记录。

当采用代码审核机制或者需要用邮件提交补丁时,较小的提交能够更有效、更容易、更准确的被检查和审核,这个在 linux kernel 开发文档中也有提到。

当然不能矫枉过正,必须有可记录的改变才有提交的价值。对应的,Git 日志大多数情况下主要显示第一行,控制每次提交都能用一句话简单概括,也是有必要的。

注释格式

格式属于个人习惯和团队规范范围,有必要采用相对统一的风格。

Git 本身不允许空注释,同时建议注释的第一行写简要说明,下面留一行空行,再写详细说明。

我的个人习惯,喜欢在每条注释前面用大约三个字母来表示本次修改的性质:

  • Add something
  • Bug [fix|found]: describe the bug or fix.
  • Chg something
  • Del something
  • Enh some treatment
  • New something
  • Tmp for some cause

为了保持语法通顺,也可以采用前三个字母后面加冒号,后面有啥写啥的方法。

最后,我觉得,能够遵守行业规范和团队约定,主动养成良好习惯,应当是鉴别人才的一项重要因素。

Update @ 2012-12-03

关于注释格式,在使用了几年 Git 后,又有了更深的认识, 参见 Git commit 注释格式

Windows安全更新KB951748可能导致dns无法解析

很久没有鼓捣 windows 了,今天帮一个朋友修复他“不能上网”的问题,遇到了,记录于此。

首先遇到的是局域网 ip 设置问题,居然自己无法 ping 出去,别人却能 ping 通自己,怀疑是网络管理员作了什么设定,更改ip设置绕过。

然后就是 windows 里 dns 的怪问题了,具体表现为:用 nslookup 能够正常解析域名,直接 ping 域名却得到域名无法解析的错误。用 ip 地址可以直接打开网站,可输入域名却由于无法解析而打不开。

怀疑是 winsock 或者 lsp 的问题,尝试修复却未发现任何问题。

最终原因就是这个 windows 安全更新 KB951748,网上的说法是:

这个问题是microsoft把dns解析的本地端口改成了49152-65535,和visita一样(所以visita系统不受影响)。对于lns等 rules based firewall,只需要把dns rule的本地端口范围改成49152-65535就ok了(xp系统缺省是1024-5000)。

卸载之,一切恢复正常。

Curl奇怪的403错误

自己用的小PHP应用,使用curl抓网页下来处理,为了穿墙方便,使用Privoxy作为代理,便于选择哪些网站使用proxy、哪些不用。但今天却遇到了奇怪的问题,访问google baidu这些网站居然都返回403错误,而访问其他的一些网站没事,如果设置为不使用proxy则都能正常访问。

难道google baidu就不让用proxy连接么?显然不可能,所以打开curl的信息输出(curl_setopt($this->mSh, CURLOPT_VERBOSE, 1);)看看,得到以下结果:

*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 8118 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:80
> CONNECT www.baidu.com:80 HTTP/1.0
Host: www.baidu.com:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

< HTTP/1.0 403 Connection not allowable
< X-Hint: If you read this message interactively, then you know why this happens ,-)
< 
* The requested URL returned error: 403
* Received HTTP code 403 from proxy after CONNECT
* Closing connection #0
... Failed.

可以看到proxy服务器工作正常,的确是baidu返回了403错误,但原因肯定还在我这边。终于,从网上(1of2, 2of2)得到了点启发──我使用的是proxytunnel而非proxy。

在代码中,有这么一句:

	curl_setopt($this->mSh, CURLOPT_HTTPPROXYTUNNEL, true);
	curl_setopt($this->mSh, CURLOPT_PROXY, $phost);

php文档中没有详细说明,不过man curl中有详细解释,两者都是代理,proxytunnel(-p参数)允许其他协议通过http代理传输,而proxy(-x参数)则只能走http协议。所以我猜测,google baidu的服务器和curl的proxytunnel不和,所以返回403。

禁用掉上面2行代码的第一句后,curl访问恢复正常。

比较奇怪的是,几种操作系统下还不一样,一台MAC OSX就要显式的禁用proxytunnel才可以,curl版本:

$ curl --version
curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

而另外一台ubuntu则完全不受影响,怎么都能用,curl版本:

$ curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

MT主机上的centos也没事,curl版本:

$ curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

看来不完全是curl版本问题,MAC OSX的确与众不同啊。

还有一个原因也会导致curl返回403错误,如果设置了:

	curl_setopt($ch, CURLOPT_NOBODY, true);

则需要紧跟着设置:

	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

不然会因为http服务器不允许 HEAD 命令而返回403错误。参考:Trouble with a cURL request in PHP。MAC OSX上curl之所以特殊,也不排除是这种原因吧。