Family Tree Builder 3.0发布

收到MyHeritage.com的邮件通知：Family Tree Builder 3.0发布了，比之前29种语言又新增了5种，纵然如此，亦纵然很久之前就有了MyHeritage中文站，但是软件的中文语言包还是迟迟未出。我之前为2.0版汉化的语言包仍然还可以凑合着用，注意：一些新版里添加的词条，默认显示为TODO。

其他功能没有细查，不知道有什么改善，虽然之前的中文乱码问题仍然存在（还没有中文语言包的情况下，这个可以理解，而且乱码部分不是太多），不过安装程序倒比2.0“大气”了些，而且默认选中将MyHeritage.com设为主页的选项，很智能的，另外还默认选中自动将族谱/家谱发布到网站的选项也很智能。

Javascript String 方法效率大比拼

最初是通过梅子（梅花雪）关于大型字符串拼接效率（1，2）的研究得到启发，最近又看到never-online的从trim原型函数看js正则表达式的性能 ，里面有介绍正则表达式效率陷阱等问题，并提出解决方法。我向来对这些鸡毛蒜皮感兴趣，也开始对大型字符串各种方法实现的效率进行比较，并尝试提高这些方法的效率。

1. 大型字符串拼接
如梅子所言，使用数组的join方法确实是最好的实现，可以根据这个思路设计StringBuilder, StringBuffer类。



2. 大型字符串trim
其实never-online在他的文章里有一些说的不准确的地方，代码也不算很精炼。既然这是鸡毛蒜皮的小事，这些零碎东西当然要斤斤计较了。
我很久以前有收集到这样一些实现，I：

String.prototype.trim = function(){
return this.replace(/(^\s+)(\s+$)/g, '');
};

为了避免正则表达式使用括号带来的消耗，可以写成这样，II：

String.prototype.trim = function(){
return this.replace(/(?:^\s+)(?:\s+$)/g, '');
};

另外有一套实现是这样的，III：

String.prototype.lTrim = function(){
return this.replace(/^\s+/, '');
};
String.prototype.rTrim = function(){
return this.replace(/\s+$/, '');
};
String.prototype.trim = function(){
return this.lTrim().rTrim();
};

其实调用函数也会多少有一点消耗，写成这样或许会快一点点（开个玩笑，这样写会带来一些冗余代码，这时候就需要基于效率（时间）、代码量（空间）和可维护性方面的考量了），IV：

String.prototype.trim = function(){
return this.replace(/^\s+/, '').replace(/\s+$/, '');
};

后来我对正则表达式有了更多的了解，知道了贪婪与非贪婪匹配，于是自作聪明写了这一段：

String.prototype.trim = function(){
return this.replace(/^\s*(.*?)\s*$/, "$1"); // 两端空白字符贪婪匹配，中间字符非贪婪匹配。
};

我曾经为这段代码自鸣得意了好长一段时间，不过后来想到点号不包括换行符，字符串中间有换行符时，返回值就不正确了，于是不情愿的改成这样（多行模式效率也很低），V：

String.prototype.trim = function(){
return this.replace(/^\s*((?:.\n)*?)\s*$/, "$1");
};

谁知，这样的代码遇到大家伙时效率会一落千丈，哎，失败。

原以为String.replace方法比String.substr、String.substring效率低，于是想，只使用正则表达式获得两头（或者一头）的索引位置，然后使用substring方法取出子串，VI：

String.prototype.trim = function(){
var l=this.length;
/^[\s]*/.test(this);
// /(?=[^\s])/.test(this);// -- never-online
var s = RegExp.lastIndex;
if(1==s && !Char.isBlank(this.charAt(0)))s=0;
if(s==l){return '';}
// /\s*$/.test(this);
// var e=RegExp.index;
var e=$lastIndexOf(function(c){return !Char.isBlank(c);});
e=-1==e?l:e+1;
return this.substring(s,e);
};

而最土的方法，莫过于两头都使用循环获得索引了，VII：

String.prototype.trim = function(){
var f=function(c){return !Char.isBlank(c);};
var l=this.length, s=this.$indexOf(f), e=this.$lastIndexOf(f);
if(-1==s)s=0;
e= -1==e?l:e+1;
return this.substring(s, e);
};

代码里老是for啊for的一大串，为了节省字节，而且有可能的话，也准备再优化一下循环，就实现了$indexOf和$lastIndexOf两个方法，可以传递一个返回boolean值的函数作为参数（本来还想也支持正则表达式参数的，想想以前扩展indexOf和lastIndexOf方法后的效率，就算了），这样就可以求得第一个非空白和最后一个非空白字符的位置了。

String.prototype.$indexOf = function(f){
for(var i=0,c,l=this.length; i=0; i--){
c=this.charAt(i);
if(f(c)){return i;}
}
return -1;
};
String.prototype.$lastIndexOf = function(f){
for(var i=this.length-1,c; i>=0; i--){
c=this.charAt(i);
if(f(c)){return i;}
}
return -1;
};

至于说要扩展到支持更长子串和起始索引，以后有需要再说了（顺便说一下，子串越长，有优化算法可以得到更高效率）。
另一个辅助方法：

var Char = {
isBlank:function(c){
//return /\s/.test(c);
return ' '==c '\t'==c '\r\n'==c '\n'==c '\r'==c;
}
};

到了永不在线(Google Translate翻译为“永远在线”)的算法，VIII：

String.prototype.trim = function(){
var s = this.replace(/^\s+/, '');
var l=s.length, e=l;
if(0==l){return '';}
for(var i=l-1; i>=0; i--){
if(!Char.isBlank(s.charAt(i))){
e=i+1;
break;
}
}
return this.substring(0,e);
};

最初这个算法让我很兴奋，直觉上，感觉这样效率肯定要高，不过事实并不是这么简单。

说到这些实现的效率，无法一概而论，因为不同的字符串，它们的效率比也大不同，甚至异乎寻常。

影响trim方法效率的，主要与字符串的总长度，前面空白字符串长度，后面空白字符串长度，以及前中后的比例有关。详细的效率对比表有时间再上，这里只简要提一下：

对于较小的字符串，各种实现都有不错的表现，而对于大型字符串，则实现III, IV表现较为稳定，甚至可以处理超大型字符串（修正：之前有误写成I，II两个较为稳定）。




3. 大型字符串字节长度
即双字节长度为2。注意：这个提法其实也不正确，Javascript是使用Unicode字符集的，所有的字符都（有可能）是双字节字符。将汉字等转换为双字节长度主要是为了某些应用。
最土的方法还是循环遍历所有字符，I：

String.prototype.bytes = function(){
var l=this.length, r=l, n=0xff;
for(var i=l; i>=0; i--){
if(this.charCodeAt(i)>n){
r++;
}
}
return r;
};

这里判断字符是否双字节有很多方法，效率较高的之间相差（大概）不大。

另一种实现则看起来很轻灵，寥寥几行，II：

String.prototype.bytes = function(){
return this.replace(/[^\x00-\xff]/g,"xx").length;
};

多动脑子，则想法愈多（也常把简单的事情复杂化），我想如果可以快速取得表达式(双字节/单字节)匹配次数，两值相加应该比较高效，III：

String.prototype.bytes = function(){
return this.length+this.replace(/[\x00-\xff]/g,"").length;
};

IV：

String.prototype.bytes = function(){
return this.length+(this.match(/[^\x00-\xff]/g)"").length;
};

另外看到梅花雪用数组能提供字符串拼接速度，也想：把字符串split为数组，不想对大型字符串而言，这split一步就慢得不行。

bytes方法的效率：使用Javascript脚本循环大型字符串（I），确实远不如内置的replace方法（II）快，而使用正则表达式match方法（IV）又比replace方法（III）稍快，排名第二。

总结：
1. replace方法因匹配而被替换的子串愈长，效率愈低。
2. 根据目标字符串，选择合适的实现。

foobar2000 Ctrl+Alt+Z 之灵异

最近发现一个怪异的事情，按Ctrl+Alt+Z键，不能够调出TM(QQ)的对话框，并且，当焦点在编辑器等可输入文本的区域时，按这个组合键会粘贴出一行字符（后来确认是Foobar2000当前播放曲目信息），Google搜到唯一的一个谈论这个的帖子，结论好像是说卸载（非禁用）Foobar2000的foo_amip插件就可以了。

p.s. 这个插件挺有用，卸载了可惜，还是该TM的快捷键算了。

2=1?

花了好长时间才解出一个初中生都会的算术题，囧啊。

在微趣上看到一组数学漫画，里面有这样一张：

最初一步步看下来，貌似还真的没有错，，，但是题解结论却得到一个驳论。回头想了好久，才看出端倪。

这里的算式是有条件的，即：a!=0, a!=b，但是这里的前提条件戏剧性的又是a=b,所以最长的那个表达式两边是不可以化简的（a-b=0，两边=0，0=0）。。。

囧：梦见心脏掉出来了。。。

这两夜均是通宵过来而白天睡觉（生活太没规律），但是今天做了一个邪乎的怪梦：

大概是看《倚天屠龙记》的缘故，梦见了张三丰（已成仙），而且我帮他做了一件什么事，并（一厢情愿的）称他为师父。
后来，大概是床上什么东西顶住了心脏部位，我觉得心脏不对劲，轻轻掀开T袖，发现心脏滑出来了。
我怕心脏完全掉出来，也不敢有大动静，甚至都没看胸口现在是什么样子了。
我隔着衣服轻轻托着白萝卜一样的心脏，心急，四处寻找师父。
好久，终于在一个小池子旁边寻见师父，连连喊师父救命。
师父把我之前胡乱塞在胸口的萝卜型心脏取出来，又植入进去。
后来醒来，并没有发现能顶住身体的物件，难道是自己的拳头？
直到现在，还觉得心脏有点异样。

口才文笔不好，这么好的题材，都不能讲出好故事，甚至连文字都不流利，只能记流水帐了，惭愧。

使用Foxit Reader作为默认PDF阅读器，并在资源管理器中显示缩略图

Foxit Reader作为一款替代Adobe Reader的PDF阅读器，其性能上具有极大的优越性（v2.2），功能上也毫不逊色，实在是追求效率不可多得的工具。

当然为了提高效率，我们可能需要在资源管理器中显示PDF文件的缩略图。但是Foxit Reader似乎没有相应的功能，使用Foxit Reader作为默认PDF阅读器，无法在资源管理器中显示缩略图（Adobe Reader可以）。

解决方法：
将Adobe Reader/Adobe Acrobat作为默认PDF阅读器，并在资源管理器（已设置为以缩略图显示）中，调整视图模式为任一图标模式，等待系统生成缩略图后，再设置Foxit Reader为默认阅读器即可。
注意：当PDF文件内容被编辑（如使用Adobe Acrobat制作书签）后，缩略图会失效，需要重新生成。

 如上图，第一个是被编辑后的效果，后两个正常的效果。

汉化Family Tree Builder

前文有言说理想的族谱软件Family Tree Builder虽有中文站，但是软件本身没有中文化，因为很喜欢并且很需要这款软件，就自己动手汉化了过来。

汉化原理很简单：
1. 备份软件安装目录下，Lang子目录中的English.lang（也可以是其他国家的语言文件）。
2. English.lang其实属于一种属性文件（properties），将每一行的第二部分翻译成中文（或合适的文本）即可。
3. 备份安装目录下，Res子目录中的English.bmp图片。
4. 制作一张32x28像素，bmp格式的中国国旗图片，命名为English.bmp，放到Res目录。
5. 启动程序，菜单“工具(Tools)”-“选项(Options)”，
“名字(Names)”-“Display people's names”设置为“Last First (Armstong John)”，即让姓氏(Last Name)放在名字(First Name)之前，符合中文习惯。
“日期(Dates)”，“Day/Month/Year format”设置为“%y%-%m%-%d%”，“Month/Year format”设置为“%y%-%m%”。可以根据自己的习惯设置，其中%m%是使用英文短格式，如Mon，在English.lang改为数字即可。

注意：部分文本不可以翻译为中文，如日期选择按钮类的，提示文本为中文时，显示乱码。另外程序本身左侧的列表(List)的姓名列，中文也显示列表（好像所有List View都不支持中文）。

下载文件托管在Google Code上，同时支持SNV提交，有兴趣的朋友联系我，希望大家来共同完成。

Family Tree Builder:理想的族谱/家谱软件

去年春节回家，老爸让我把家谱（族谱）放到电脑上，但当时家里不能上网，手头又没有理想的家谱软件，只能把一些文本输入到电脑上。

后来又尝试使用树型结构（当时使用梅花雪树）临时模拟，但是族谱是一种双亲（甚至多亲：[古代可同时]结婚多次）树型结构，使用普通的单亲树型结构就显得很别扭，最后使用纯文本拼成一个简易版本。

爷爷 + 奶奶        外公 + 外婆
     |                  |
  ---+----+       +-----+---
          |       |
         老爸 + 老妈
              |
        +-----+-----+
        |           |
     大儿子       二儿子

这个版本也算理想，但是涉及到详细资料，尤其是当这棵树变得更大而复杂，盘根错节时，这个纯文本拼凑起来的双亲树就显得力不从心。

后来回杭州工作时，找了一些软件试用，大都不怎么理想（大概是我崇洋媚外的缘故，国内确实还没看到什么让我觉得有脸拿出来使用的族谱作品），只是找到一个仅支持联机使用的Flash版本：中国传家宝，只能联机使用让我觉得很不方便，而更不方便的是设计上有一些（大概）不合理，操作不便，并且速度也不行，让我满意的大概只有显示效果不错。

过了很长时间，零星的找找也没得到什么结果。

后来无意在VeryCD上看到一下族谱软件，是外国专业公司制作的产品，不过给人的感觉有点太强而大的样子，而且收费挺贵。顺手又上Google搜寻一番，收获不小，这个市场貌似现在很活跃的样子。

于是就发现了这个相当理想的免费软件：Family Tree Builder（这是它的英文网站），号称支持29中本地化语言（事实上也是如此）。不过遗憾的是，虽然它有中文网站，但是软件本身却没有中文本地化版本，刚安装在Windows Server 2008上时崩溃了好几次（大概是我没有摸清它的脾性），而且更糟糕的是程序左侧的List成员列表视图显示中文乱码。不过它的优点也相当可观，免费，启动速度快，自动备份（崩溃后可以恢复），支持多国语言，视觉效果好，操作方便，功能齐全，而且可以导入导出标准系谱数据格式gedcom，这里是它的中文官方介绍，传说是族谱学家级别的人士和专业软件设计专家创造出来的（事实上看起来应该也是如此），适用于管理大型及小型的族谱。

Firefox本地化及其切换

昨天用Firefox内置的下载管理器下载一个较大的文件，而且新搬来这边的网速慢到让我想起令人怀念的大学时期（那时候的校园网，不是一般人能够忍受的），无意中我看到下载管理器里当前下载的文件下显示着“第x小时，剩余x分钟”的提示（不超过一小时时，只显示“剩余x分钟”）。看到这个提示，我当时有两种想法：

1. Firefox下载管理器的剩余时间计算方法比较有趣，将每小时的下载分段，所以就有了第1小时，剩余20分钟的说法；
2. 翻译问题，实际应该是剩余1小时又20分钟的意思。

这两种理解方式都有其道理，而且在我最初看来，是各占50%的。

为了打消疑问，我Google，Baidu试了个遍，但是没有找到一条符合的记录，于是又尝试问一些对Firefox有/无兴趣的朋友，以及mozine的Gtalk群友，但是大伙都没有注意到这个，只能给个猜测的结果。

为了找到答案，就需要知道Firefox英文版是怎么说的，但是我还不想为此再装一个英文版Firefox，那么怎么切换本地化语言呢，又是大肆搜罗一番，找到一些近似的，这里整理如下：
I:
1. about:config
2. general.useragent.locale由zh-CN改为en-US。（前提：Firefox/chrome/目录下有en-US.jar和en-US.manifest）

II:
1. http://releases.mozilla.org/pub/mozilla.org/firefox/releases/下载安装对应的语言包(.xpi)。
2.  启用该语言包（安装后默认启用）并重启Firefox。

例如我的Firefox版本3.0.3，Windows，则语言包文件地址为：http://releases.mozilla.org/pub/mozilla.org/firefox/releases/3.0.3/win32/xpi/en-GB.xpi （粗体为Firefox对应的版本号）。

注意：http://releases.mozilla.org/pub/mozilla.org/firefox/releases/下的目录并不会列出xpi文件，将正确的版本号替换粗体部分，直接拷贝到地址栏回车即可。

安装并重启之后，可以看到Add-ons - 语言页签下会列出刚安装的English(GB) Language Pack语言包，想撤回中文时，禁用此语言包，重启Firefox即可。

III:
另外还有几个用来切换本地化语言的扩展，Locale Switcher 和 Quick Locale Switcher，它们可以让Firefox直接在菜单栏切换语言。

言归正传，话说回来，切换为英文语言后，尝试大文件下载发现原文是类似于2 hours, 8 minutes remaining这样的提示，意思是剩余2小时8分钟。

Firefox中文版的这个翻译确实不怎么样。

文本宽度 及 文本框滚动偏移量(scrollLeft)

背景：
最近将多标签输入框进行修改，把原来随光标(caret)移动的自动建议浮动条改为根据当前标签相对左对齐。

解决方法很简单，计算当前标签前的文本宽度(将需要计算的文本转义后放入一个各字体样式与目标输入框相同的容器，如span中，span.offsetWidth即是文本的宽度。注意：文本框中，中文半角空格的宽度和英文半角空格的宽度显示为不同，虽然这两个空格本质上相同)，浮动条根据该值定位即可。

问题：
当标签文本过长，超出文本框宽度时，标签文本会向左滚动，但是此时当前标签前面的文本宽度不变，定位浮动条时需要减去文本向左滚动的尺寸。

网页文档对象中，元素都有一个可读写的scrollLeft属性，表示元素内容相当元素容器向左移动的偏移量。

但是Firefox和Opera有一些例外，如文本框的scrollLeft始终为0，Mozilla的描述是：

If the element can't be scrolled (e.g. it has no overflow), scrollLeft is set to 0.

对于一些不可滚动(scroll，即没有溢出)的元素，scrollLeft始终为0。而单行文本框（在Gecko引擎看来）是不可滚动的，即使将样式指定为overflow:scroll（IE会出现水平和垂直滚动条这样的怪胎）。

虽说单行文本框是不应该出现滚动条这样怪异的形态，但是这不表示它是不可滚动的，当文本宽度大于文本框宽度时，（为了将光标caret显示在文本框可见区域）文本势必向左滚动，如图：

解决办法：
对于文本框不支持scrollLeft的浏览器，一个临时的解决办法是，在文本宽度大于文本框宽度时，浮动条定位在相对文本框后端若干像素（便于输入）的位置，在增量输入时，体验不是太差，但是在光标向前移动使文本向右滚动时，就会出现偏差。

最终解决办法是期待浏览器能够得到正确的scrollLeft值，或者其他巧妙的计算方法。

Windows Server 2008未激活导致黑屏

Windows Server 2008未激活导致黑屏，地位与盗版软件平等

 

这本是Windows Server 2008试用版，未激活，昨天是到期后之最后一天，频繁提示激活未遂，今日凌晨准备关机时发现已经被黑屏。

 

网上找了一下关于激活的帖子，有说临近到期时运行命令：slmgr.vbs -rearm 即可，可以故计重施三次。 

虽说黑屏也算的上酷的，但传言纯黑色于眼于显示器都不利，值得庆幸的是还可以改回来，没有特别关心黑屏这件事，不知道会怎么个黑的有规律法。

想要自-由，考虑换Linux？但是开发能不顾Windows及其IE吗，这就像想离开QQ和用友财智家庭理财一样，已经深陷封闭性其中时，要投入到自-由的怀抱，还是要付出很大的代价的。

期待自-由软件颠-覆封闭专有软件的政-权。

PANDA-glGo，完美的围棋软件

我的围棋水平虽然很差，但是这一点也不影响我对围棋的喜爱程度。而今天意外的发现一款让我满意度达到100%的围棋软件，它就是PANDA-glGo，（这是它在GNU和SourceForge上的地址，不过sf上已经过期）。



PANDA-glGo是一个GUN自由软件，支持Windows，Linux和Macintosh平台，不论外观，还是内涵，无一不是完美绝伦。PANDA-glGo支持2D和3D的风格，界面简洁大方，操作方便。可以设置棋盘背景图和更换棋子，支持多语种，包括中文。

PANDA-glGo默认没有机器人，如果想要人机对战，需要另外下载GNU Go（解压至PANDA-glGo安装目录即可，也可以放在其他位置）。机器人跑起来一点都感觉不到慢，即使设置棋力为最高级别（机机对战除外），至于算法是否高明，机器人棋力能达到什么程度，我不（需要）知道，目前我还没赢过。可以设置机器人的棋力级别，棋盘大小（纵横数目）和对战让子目数。另外PANDA-glGo还支持网络对战，或者观看他人对战。联机时，可以查看棋手级别等资料，正在进行的棋局。可以这么说，PANDA-glGo不仅仅是一款围棋软件，更是一个围棋平台。

帮助文档很完整，只是缺少中文文档。

如果你也是围棋爱好者，这是不容错过的一款软件。好想找一份和这类似的中国象棋软件，因为我的象棋水平比围棋稍好，可以坚持久一点。

电子图书管理软件幻想

一直以来，稍微好点的电子图书管理软件是特别的少，而做很不错的更是少之又少，要说真正让用户喜欢，或者至少还满意的，到目前为止，没有。

而与之功能相似，状态却截然相反的是，图片和音乐文件的管理软件却如此兴旺发达。

下面先介绍一下图片管理软件，它们大致有以下几个特点（这里以个人最偏爱的Picasa 3 Beta作参照）：

1. 看图，图片管理软件最好能（方便快捷的）阅读各种格式的图片。（Picasa 3的看图模块很炫很优秀，半透明状态悬浮在窗口上，附有一些播放，翻转，标星，打开在Picasa中编辑等快捷功能。不过Picasa对GIF动画支持很烂，甚至会毁掉动画的动态特性）

2. 管图，每一张图片都不是独立存在的，它们存在于一些相关/无关的相册中。对于一个图片管理软件来说，对相册的管理能力尤为重要。（Picasa可以动态扫描整个磁盘/指定目录的所以支持的图片，还可以建立独立于存放目录物理路径之外的虚拟相簿功能，感觉就像管理你的家庭相册一样）

3. 搜图，搜索功能对于任何一个信息系统来说都必不可少，而对于图片搜索，还有一些有待探索的领域。（以搜索著称的Google生产的Picasa自然有这个功能，虽然还有待提高）

4. 写图，这是对单张/多张图片进行微量/智能调整的高级特性。这个可以交给专业的图片处理软件，对图片管理软件来说非必要，但是一定要提供快速定位到系统资源、直接由这些专业的处理软件打开的特性。（Picasa有一些像改变色相，去除“红眼”这样的简单功能，另外，和Google搜索的“手气不错”一样，Picasa也有这样自作主张的功能）



而我所期待的图书管理软件，就像上面列出来的这些特性一致：

1. 看书，软件最好能支持多种图书格式，因为现在的图书格式繁多，一一支持不太现实，也没有必要，让管理者做好管理的事情就够了，当然还需要能够方便的定位资源，并能与其他专业的看书软件配合。另外最重要的，是有一些读书计划方面的规划系统（可以结合一些读书技巧/理论）。

2. 管书，每个人都会有自己的个人图书库，当这个库越来越多时，管理则是势必施行，在管理方面，图书有它和图片的不同之处，比如分类（可以参考但不拘泥于图书馆的管理方式），加一些现流行使用的小标签，图书的名称，ISBN，缩略图，作者等，软件最好，或者说最起码能像Picasa一样支持动态扫描指定位置的所有支持/指定格式的图书。

3. 搜书，并不是每个人都能够/需要看并记住所有收集的电子图书的，在需要时快速定位的指定位置，或者至少找到匹配的书。

4. 写书，编辑书名，作者，缩略图，分类，标签，ISBN，给喜欢的书标星等，另外像编辑PDF的书签或添加评语/附注，非必须，有专业的编辑软件支持就可以了。

目前发现最好的有Foxit Library，它支持静态扫描和书架归类，并能够使用自己的Fixit Reader打开PDF文件，但是在使用它管理图书时，操作不便到简直不可用的地步，而且速度很慢（可能是因为我的书太多，但是Picasa管理我更多的 图片时，一点都不显胖），并且不支持搜索（有一个索引功能）。

另外SSReader也有一个“本地图书馆”，可以导入本地目录。它会按照目录结构生成默认归类（跟系统资源管理器差不多，建议还是用资源管理器比较好）。

不知道为什么现行的图书格式都不支持（像音乐文件一样）将书名，作者，缩略图，ISBN等信息存储在图书属性中，这方面难道没有对应的规范，还是牛仔太多了？

这样的软件是一个梦吗，真悔当初不懂事。给我再多一点时间，我可以自己来实现这个梦。

约会事宜流程及注意事项

根据以往与朋友碰面的经验，以及前日与一Beyond爱好者约定，去他那里拷贝Beyond APE歌曲时，对方手机停电关机的经历，得出以下几条，供日后约会碰面参考：

1. 确定事因。确保做出最佳选择，甚至可以谢绝；避免做出不合时宜的举动。
2. 确定地点。事先在地图上做好标记，并让对方确认；有需要的话熟悉附近区域的街道和地形。知道约会缘由，可以更好的选择合适的约会地点。
3. 确定时间。出发前与对方保持联系，避免事后才获知对方无法赴约，或者根本联系不上对方（比如手机关机）；尽量不要迟到（预知将要迟到时，事先告知对方，迟到后一定要道歉），也不必过早到达。
4. 确认对方。与不熟悉或初次见面者约会时，最好能看一下对方照片，或者约定大致衣着款式和色彩。

与写小说类似，有事件起因、时间、地点、人物，但是这里地点放在时间之前，是因为确定了地点，能够更好的把握时间。

p.s. 好在这位Beyond朋友心肠好，说有时间给我送过来。

热烈庆贺QQ升级到两个太阳那么多

腾讯名声不算特别好，我以前对他也有一些偏见，但是国内他仍是必须的选择，我们我们一时还无法抛开这里的朋友，让他们也一起来用自己偏爱的产品。

本人大概有洁癖，对花里胡哨的QQ深恶痛绝，但是对TM这款软件还是比较中意的，因为不会过多的干扰我的行为，界面也算大气和简洁，尤其是新版的TM（限于社会和历史原因，现在的软件都做成流线型，3D效果，运行慢，软件越做越大也是一大弊病）。

无意看了一下自己的Profile，发现前几天升到32级了，两个太阳，很牛叉，天天上线2小时以上不是盖的。

对比看起来笨拙，启动却要更快的MSN，TM还是有许多好的功能的，比如发图片直接预览，发生文件速度快等。

由于不是商务人士，对MSN没什么依赖，谢谢各位微软fans不炮轰我。

Google之恶

1. Google中国的首页在多数浏览器（FF例外）里有一个有趣的动画（模仿自Google 韩国），但是可恶的是翻译部分的图片是使用日文，明显又是从Google日本 抄来的。

关于 Google Chrome

作为心得也好，作为八卦也罢，无所谓了，只是随便写写。

I. 值得称道的细节：

1. 整个页面对于Javascript第二次（及其两次以上）调用alert时，用户可以选择不弹出提示（可以避免恶作剧），但现在这个功能是停止当前页面的所有alert，用户下次操作的alert仍然不会被弹出（类似于“记住我的这个选择”或“下次不再提示”）。合理的情况应该是一次用户操作时连续的alert才被阻断（javascript引擎可以识别：一次执行javascript脚本开始，到脚本交回控制权，视为一次连续的过程），当然为了避免恶意程序，也应该提供中止整个页面alert的选项。

2.textarea会检查拼写，但是text input却不会（与同样使用Webkit核心的Safari一样，textarea可以拖放大小）。

3. 没有状态栏，只有在需要显示状态信息时，左下角才隐现出一个浮动条（这个浮动条宽度是固定的，自适应可能更好）。

4. 另外这里看到关于Chrome的中文选词，很强大。
5. 简洁，动态效果，灵活的界面。如页签和单窗口的随意切换（怯怯地：其实我很早之前也想过用Javascript开发一个类似web控件，但一直懒于动手，现在倒是桌面应用程序先实现了 -_-!）。
6. 搜索文本时自动高亮全文匹配（类似于FF3的“全部高亮显示”选项），不过Safari似乎做得更漂亮（文档本身变暗，高亮全部，并且第一个匹配项会有一个警戒色的泡泡提示，感觉这个泡泡影响速度，所以未必需要这样的美丽）。

II. 不足之处：

1. 功能不够完善，比如没有编码选择，导致Google Picasa Web在nametags功能里出现乱码（添加名字标签(Add name tags)操作的页面）时无法手动调整（后来发现都有这些功能）。

2. 一开始就没有做成支持插件的框架，不知道以后会不会改变，现在这样是很简洁，但是在需要定制时，就显得很无助。

3. 下载的视觉效果相当好，但是安全控制似乎不够，尝试用Chrome打开这个页面，浏览器会自动启动下载，并将文件自动保存在默认目录下（一般是系统盘当前用户的Download目录），而其他浏览器至少还有一个保存提示框让用户选择确认。另外已经下载过的文件，仍然会不动声色的再次下载。
4. 不支持全屏(Safari3也不支持)，而这一点FF3和IE7做得比较好，Opera9反应最快，只是鼠标移到显示器顶部附近时，地址栏和页签都不会显示出来（Ctrl + T 创建新页签时出现地址栏，并且地址栏不再消失，除非再次全屏）。

III. 技巧：
Ctrl + B : 调出（默认在地址栏下的）书签栏。
Ctrl + F : 调出搜索框（所有浏览器通用）。
Ctrl + T : 创建新页签（所有浏览器通用）。

Google 的更新

Google基本上每天都有更新（包括创新和失误），然而这次的更新非同一般。

I. Google Chrome
经过两天各大新闻媒体和个人博客的大量相关报道的洗礼，使用Webkit内核（同Safari）的Google浏览器Google Chrome于昨晚（美国时间周二）发布诞生了，Google作为一家以网络为主的公司，Web浏览器对他的影响可想而知，这里是相关链接：谷歌浏览器（中国），Google Chrome漫画书（Google Books，中文版），更多内容可以搜索Google Chrome。

II. Google Picasa Web
很早就知道Google有图片的人脸（包括动物脸）识别技术，主要用于Google街道的隐私方面，但是最近Picasa Web提供了一项新特性：nametags(名字标签)，Google将你的相册中所有人脸识别出来，并进行归类，把相同的同一个人的脸（或相同脸型）的“ 1寸免冠照片”放在一起，你可以给它们加上名字，以后就可以点击这个人的照片找到所有有他在的照片，Picasa Web本身还有其他一些更新，包括界面改版，另外Picase这个客户端图片管理软件也升级到了3(beta)(晚上补充：早上尝试下载3.0，发现链接404错误，晚上可以下了，但是已经退回到了2.7)。

III. RSS AD (is not update)
今天在Google Reader里看订阅的文章，有一篇是GSeeker关于Google Chrome下载的快讯，在Google Reader里出现了一个图片连接广告（甚至在同一窗口中打开），上面的标志是“Ads by Pheedo”（有时是Google的广告）。

我看了一下，是GSeeker做的恶，之前只是类似于“相关文章”或者“看了这个的人也喜欢那个”之类的文本链接（其实内容本身也是外部广告链接），但是这个更招摇而令人厌恶而已。

同步Web客户端的时间

富客户端应用的普遍流行，许多操作直接在客户端完成，而一些跟时间相关的操作，客户端时间的正确性就显得尤为重要，一个和标准时间相差得离谱的时间，可能会带来滑稽甚至严重的错误。

在C/S构架下，对时间有要求的应用程序一般解决方法是同步客户端和服务器端的时间，一些要求较高的应用甚至需要专门的时间戳技术。

普通的B/S应用程序一般没有权限同步客户端的时间（也不一定有这个必要），这个问题也有一些解决办法。

1. 响应用户请求时返回服务器时间，并使用计时器（如：window.setInterval）做一个虚拟时钟。但是考虑到浏览器消耗和脚本计时器本身并不精准，长时间运行后时钟会出现较大的误差，予以忽略。

2. 响应用户请求时返回服务器时间，并计算服务器与客户端之间的时间差，每次时间操作均以该差值进行修正（可以专门做一个接口）。或者考虑只有在差值较大的情况下才进行修正（并提醒用户修正客户机时间）。

另外还要考虑用户所在不同时区的情况（Date.getTimezoneOffset）。

但是对于较精准的时间需求，这样仍然有一个问题，即从服务器端响应到客户端返回过程中的网络传输时间。这是一个随机数，根据网络情况和其他偶然因素有关，从几十毫秒到几十秒不等，有时达数分钟之久，最惨的是整个页面超时，当然同步也就没有必要了：）

如上图，客户端从客户机的t0时刻发送请求到服务端，然后服务端在T0时刻得到请求，经过连接数据、计算等操作，最终在T1时刻响应完成，客户端最后在t1时刻加载完成。

此时我们最关心的是服务器返回到客户端加载完成这段时间的网络传输耗时，但是暂时无法精确求得，只有一个相当不凑和方法：客户端发生请求时，带上当时的客户机时间（t0，浏览器请求头信息里一般带有，也可以通过客户端脚本new Date()，此时则需要通过异步请求），服务器计算所耗时间也可以得到，响应时返回服务器计算耗时（T1-T0）以及浏览器请求的时刻（t0）以及服务器时间，客户端加载完成时刻（t1）计算网络传输总共耗时为：(t1-t1)-(T1-T0)，之后以一定比例（如1:1）计算响应的网络传输耗时。

结果相当不凑和，而过程又相当麻烦，所以只作为抛砖引玉之篇。

图片来自Baidu图片搜索。

去北京的途中

每一次长途旅行都能给平淡的生活带来一些不同的感觉，这次也一样。

和以往一样，我如蛟龙一般，每次远行、或者远行前后，都会伴随着雨水。上次端午回家给久旱的家乡带去一抹湿意，这次出行前又给自己的裤腿留下一圈地图。

22日（周五）和同事喝完临别酒，23日抓了两个同事冒雨帮忙挑送私人物品到火车站托运，24日早上和（恶心的）房东交接完手续，骑上了前往上海的客车。旅途的风景总是那么可爱，但是中午将到上海站时英明突然说不能来接我了（晕，车票还控制在他手里呢！），心里有点不愉快，导致和（被我误会的）花花通电话时也带上一丝不满的嘲意。心里很过意不去，但是嘴上一点都没表现出来。

最终，英明改变了主意，还是来接我了。我没有感激他：如果他直接来接我，我会理所当然的不用感激；而他“制造”这一曲波折，有些心情不爽的我也是不会感激他的。当然，也没有了那些许嘲意。

中国人会面，自然少不了酒席，何况正好是中午肚子饿的时候。我被自家的朋友和自家的烧酒灌醉了。这是我有生以来第二次喝醉（第一次是过年接待二十多个同学到家里吃饭，被一550ml矿泉水瓶自家酿的陈年烧酒和两瓶啤酒灌得烂醉，疲惫一周），我倒是一点都不怕醉，反而怕不醉。我独饮时觉得烧酒难以下咽，一滴都不想沾；如果我醉了，说明至少我还有（哪怕只是酒肉的）朋友。

花花做的八宝粥很好喝（虽然我酒醉朦胧醒时，粥已几近于晾干为饭了），其实我更喜欢绿豆汤，尤其是酒醉之后。希望还有机会，希望那次机会也还有足够的时间。

带着掩饰疲倦的墨镜，挪腾到火车站时，同车的其他乘客已经登车了。感谢英明送行，直到他被乘务员挡在列车门口。这是有生以来第一个为我送行的朋友，也是我所有的酒肉朋友当中，值得珍惜的一个；而且我知道我还有好几个和这个一样的酒肉朋友。

gnotify disconnect again

继上次说gnotify连不是收件箱（2）之后（Google有了修正 2），gnotify再次连不上了。不过这次的链接错误提示消息与上次不同：

An error has occurred.
Cannot log in to mailbox (12031)
The connection was unexpectedly reset.

爱因斯坦推荐的站点

有兴趣的朋友请看这里：http://www.hetemeel.com/einsteinform.php

msn 钓鱼网站

最近频繁出现一个msn钓鱼网站，他本身通过msn传播，例如，你的好友会给你发一个链接（可能会连续发，每次发的地址都不相同，但是链接到同一个地址）。我就接到一些地址：
http://msn.thatzyou.com
http://msn.datsyou.com
http://msn.is-dat-u.com
http://msn.checkpics.com
...

它们都是以msn为子域的二级域名，打开后界面都如下，是一个msn登录窗口（提供msn等IM的web服务很多，所以它至少看起来不是那么假。）。
注：部分地址已经被FF3/Google报告为钓鱼网站。



它一般只有一个页面（即首页），登录窗口下是他的服务条款：

Terms of Use / Privacy Policy:

By filling out this form, you authorize TST Management, Inc to spread the word
about this 100% real and upcomming Messenger Community Site.
You will receive your share of the credit in helping us spread the word. This is a harmless
Community site which is offering users a platform to meet each other for free.

We do not share your private information with any third parties.
By using our service/website you hereby fully authorize TST Management, Inc to send messages
of a commercial nature via Instant Messages and E-Mails on behalf of third parties via the information
you provide us. This is not a "phishing" site that attempts to "trick" you into revealing personal
information. Everything we do with your information is disclosed here. If you are under eighteen (18),
you MUST obtain permission from a parent or guardian before using our website/service.

This page is not affiliated with or operated by Microsoft(tm) or MSN Network(tm).

ANY LIABILITY, INCLUDING WITHOUT LIMITATION ANY LIABILITY FOR DAMAGES CAUSED OR
ALLEGEDLY CAUSED BY ANY FAILURE OF PERFORMANCE, ERROR, OMISSION, INTERRUPTION, DEFECT,
DELAY IN OPERATION OR TRANSMISSION, COMMUNICATIONS LINE FAILURE, SHALL BE STRICTLY LIMITED
TO THE AMOUNT PAID BY OR ON BEHALF OF THE SUBSCRIBER TO THIS SERVICE.

We may temporarily access your MSN account to do a combination
of the following:
1. Send Instant Messages to your friends promoting this site.
2. Introduce new entertaining sites to your friends via Instant Messages.


This is a free service. You will not be asked to pay at any time.
You will not be subscribed to anything asking for payment.
This service is made possible by many hours of human effort.

TST Management, Inc reserves the right to change the terms of use / privacy policy
at any time without notice. To view the latest version of this privacy policy,
simply bookmark this page for future reference.

You understand that this agreement shall prevail if there is any conflict between this
agreement and the terms of use you accepted when you signed up with MSN. You also
understand that by temporarily accessing your msn account, TST Management, Inc
is NOT agreeing to MSN's terms of use and therefore not bound by them.

This agreement shall be construed and governed by the law of the
republic of Panama. You expressly consent to the exclusive venue
and personal jurisdiction of the courts located in the Republic of
panama for any actions arising from or relating to this agreement.

If any provision of this agreement is held to be invalid, illegal or unenforceable
for any reason, such invalidity, illegality or unenforceability shall not effect any
other provisions of this agreement, and this agreement shall be construed as if
such invalid, illegal or unenforceable provision had not been contained herein.


Copyright 2008 TST Management, Inc

Google Blogger 更新(Updated)

难道昨天是Google更新日，发现好多服务都有局部的更新，一般来说不怎么更新的Blogger也有动静了。

这是控制台首页最新的布局：


全部按钮都换了，重要/优先级较高的按钮使用警戒（橘红）色，其他的使用Google经典蓝色：


其他大的改变没有发现，不过留下一个不合理/不爽的东西，上面的按钮是写新文章时的按钮，之前保存（包括自动和手动保存）后会变成灰色（并不可用），直到内容被改变（类似下图，不过不仅仅是保存过程中）。

Google Reader 的红线

Google Reader昨天晚上（或者是今天凌晨）出现了一条（大概是用来调试的）红线(on FF3，调试发现是样式表里背景图片上带的红线，可能是美工的失误)。刚刚看了一下，直到今天下午1点还在。


之前Gmail左上角也出现了一个很小(未被隐藏掉)的iframe，大家纷纷猜测他是干什么用的。

Google Docs updated

Google Docs支持PDF格式文件，目前支持上传、浏览、共享、打印、下载pdf文件，用Google docs打开pdf文件时，右侧有预览图，可以选择和复制（如果是）文本，不支持拖放上下/左右移动文档。看起来像是用了Google 图书搜索中的部分技术。


另外还有新的“表单(Form)”文件，不知道干什么用的。


发现一个问题：选择使用英文语言，中国北京时间，但是文件的时间好像有问题，明明昨天最后编辑的，显示为今天，似乎有几个时差。把语言改为中文就正常了。

-- 2008/8/15

p.s. 昨天来回设置，今天发现又正常了（2008/8/16）

（浏览器被拉小以便节省截图）
注意TODAY里的Aug 16和YESTERDAY里的Aug 16（第1个的Google Logos...的时间也是不正确的，你见过12:47 pm的吗？应该是凌晨0:47 am才对的）。我看过Revisions，这两个都是在24小时之内最后编辑过（大约都在20小时之前），所以排除按小时差值计算相对时间的误差问题（将来发布详细介绍文档和源码）。
诡异，这是13:53分的截图（可能有异步刷新，上次也发现类似的情况），这是正确的，但是刷新或重新打开又会回到原来的错误状态。

不知道这是Google Docs的什么毛病。
-- 2008/8/17

Rating for Foobar2000 columns UI

给Foobar2000 的Columns UI设置标星功能：

I. 显示歌曲标星级别。
1. 文件 -> 参数设置。
2. 显示 -> Columns UI -> Playlist view。
3. 切换到Columns页签，新建（New）一个列。

如图，Display里的代码是：
$if(%rating%,
$select(%rating%,
*,
**,
***,
****,
*****),
)
)
其实也可以简单是输入：%rating%。


II. 设置标星级别功能。
1. 右键播放列表某首歌曲 -> 标签 -> 管理脚本。


2. 打开“批量标签”窗口。


3. 点击“准备的任务”中的“添加”按钮，选择动作类型为“从另一个字段格式化值...”，确定。


4. 目标字段名：RATING
格式化原型：$if($greater(6,$add(%RATING%,1)),$add(%RATING%,1),5)


5. 保存为rating++，名称可以自定，点击“运行”按钮。


6. 重复第3步。

7. 重复第4步，目标字段名：RATING
格式化原型：$if($greater(%RATING%,0),$sub(%RATING%,1),0)
保存为：rating--
点击“运行”按钮。


III. 设置标星界面（操作按钮）：
1. 右键工具栏，点击 Customise...


2. 添加(Add)一个按钮(button)，并点击Change...按钮。


3. Command group中选择“Context menu items”，Item group中选择“Now Playing item”，Command中选择“标签/脚本/rating++”。OK保存后回到Command picker窗口，设置按钮图片什么。注：支持bmp和png格式的图片，但是png图片如果有透明的部分，则可能不会显示。


4. 重复第2步。Command中选择“标签/脚本/rating--”其他雷同。

5. 最后OK保存就可以了，下面是配置完成的界面，两个带星星的按钮功能分别是标星自减和自增。

gnotify可以连上Gmail了

四处散布谣言（歌谣的谣，言语的言），广结友朋的好处终于体现出来了，这位朋友在看了我的评论后回顾了我给出的“广告”链接(2)，不仅告诉我gnotify的补丁已经出来了，而且还提醒说我的博客（我有两个博客，这是另一个）评论系统出问题了。

之前说gnotify连不上服务器(2)是因为在Gmail设置里把Browser connection设成了Alway use https，导致使用http协议的gnotify连不上（马后炮：之前我也想过让gnotify被双击后以https协议打开Gmail邮箱，不过不知道怎么改，Gtalk默认使用https协议）。

解决方法：将注册表 HKEY_CURRENT_USER\Software\Google\Gmail\Flags 里的 url (没有的话新建一个字符串值)的值改为 https://mail.google.com/mail/ （Google官方补丁原理也是这样）。

感谢Yi Ran，参考这里和这里（选择英语）。


林妙可“歌唱祖国”的背后英雄杨沛宜

这是音乐总监陈其钢的“爆料”，这里我们不谈它的真实性，类似于LMK假唱的新闻和文章大都已经被屏蔽/删除，这也足以从反面做了论证。下面两张是背后英雄杨沛宜的照片，第一张大概是近照（有文章说她正处于换牙时期，怕影响国容），第二张应该是在做操吧，很可爱很漂亮，我不知道她在张艺谋大导演眼里怎么会丑的（大概老谋子拍电影用多了明星的缘故）。

这里不再做批判，只为这可爱的小沛宜（新闻/文章里都有说她一点都不抱怨：“当记者问她有没有觉得遗憾时，她回答说不遗憾，开幕式上有自己的声音已经很满足了...”）。






http://cache.baidu.com/c?m=9d78d513d9d430ac4f9b90690c66c0171843f7142ba7a4020edf8448e2732d42501194ac26520775d4d20b6316d9494b9b802235775d2feddd8eca5ddcc88f3573df6275671cf1164e8e59e9915125b671cd05feaf6eb6e6ed73d8ef9484804953c8510f6782fa96590009c86df11030e4a69b48025f67fbb7763aa1&p=8664c54ad49812a05af3c1685a&user=baidu

http://blog.sina.com.cn/s/blog_4a8e198a0100amrn.html

http://cache.baidu.com/c?m=9f65cb4a8c8507ed4fece76310419171192380606d8bc7150885ce178e251d12077babe160795a5f8f90613b56f41f07f7f034703d1e22bd86cb8857dab99528248a2323706bc71b548c47bb8e1b65972f872beab86fe3adf14284dfd3c4a82344ba27120b8be78b2b1764bb78861f2693a78e3b66&p=882a975d85cc43bc17fec82247&user=baidu


百度搜索“林妙可 杨沛宜”

Beijing Olympics Opening Ceremony-北京奥运开幕式

北京奥运开幕式应该说不错，尤其是两百多个国家的出场仪式，空前浩大，还是很值得收藏的。



找了一天的视频源，虽然很辛苦，但毕竟找到一些可用的源头（期间看到一个15G，1920X1080的ts格式的视频，不过貌似没有了源头，很可惜）。

http://www.mininova.org/get/1676926 (found from aw's blog)
http://isohunt.com/torrent_details/48882928/olympics?tab=summary
http://isohunt.com/torrent_details/48872826/beijing+olympics?tab=comments

迅雷本也有提供者的，但大概被和谐掉了。

八卦一下，Google有出奥运Logo，但是Baidu貌似暂时没有什么动静。
Beijing 2008 Olympic Games， beijing2008.cn, Olympics.cn

IM软件互联畅想

现在的IM软件（如QQ, MSN, Gtalk...）都有各种支持的新邮件，日志/博客更新及好友联系资料更新的检查功能，它们各自为政，互不相干，每个IM服务商都只支持自己提供的服务。

而现在的IM领域愈来愈趋向于互联互通，相互开放。这也是众心所向，大势所趋。

在这个时候，IM软件的检查用户更新的功能也应该相互开放，相互支持。

就拿新邮件检查来说，其实mail notify的相关软件相当多，它们有的具有针对性，只对某些邮件服务商服务（如gnotify[仅支持单个帐号]，Gmail Manager[Firefox插件，支持多个Gmail帐号]），有的具有开放性，同时支持若干个不同服务商和多个不同帐号。当然最好是能同时支持多个服务商和多个帐号了。由于不同邮件服务商（为不同用户）提供的服务不同，获取新邮件的方式不一而足，一般服务商只提供pop服务（如126，163邮箱。另外某些服务商该功能需要收费），而Google同时提供Atom格式（gnotify支持该格式）。以pop方式实现的检查新邮件功能总觉着不那么舒服（但至少能实现），Atom格式比较合适（但其他服务商不支持）。如果IM软件能提供多邮件帐号、多服务商的新邮件检查支持，这将是相当棒的了。（注：Pidgin，原Gaim，支持检查登录帐号各自新邮件的功能。）

再就是日志/博客（以下简称博客）更新，现在的博客都支持RSS/Atom输出，检查更新应该没有技术难度。

用户资料更新的话，可能还需要出新标准才行，最好能支持第三方应用（比如我在某个专业提供个人联系资料服务的服务商那里公开某部分资料给某些好友，这些有权限的用户就可以得到相关更新）。

最后关于IM本身的互联互通，希望有一天能做的真正的互联，就像我有Gmail可以发邮件到163一样，之间只有通信标准，没有其他阻碍。

Facebook不允许使用个人域名为后缀的邮箱注册

艺高人胆大，财粗门槛高。

红了好久的Facebook，我今天才有注册玩一下的念头，但是注册时发现，它居然不允许使用个人域名为后缀的邮箱注册（如图）。


其它空着的项是基于个人隐私考虑去掉的，虽然对别人来说没什么用处。

我很不满，有没有效你验证一下就知道了，凭什么凭空瞎说。如果只能用指定邮件服务商的服务，那直接说好了，还非得服务器来回往返一次。

另外有一个翻译错误：选择性别前面的标签居然是“我正在：”，这个一个是当前状态的标签吧。

不过注册码方面的设计还是做的挺好的（不是说注册码上的文字，那个超难辨认超恶心），第三次错的时候注册码已经不出来了。


以下是来自ichina.cn的报道：

Facebook放开注册邮件域名限制
作者:互朕网 文章来源:互朕网 更新时间:2008-6-29

据国外媒体报道，本周，社交网站Facebook表示，该网站将对业务进行扩充，所有拥有有效电子邮件地址的用户都可享受该网站提供的服务。

　　据路透社报道，此前，Facebook只接纳邮件地址中包含".edu"、".com"、".org"、".gov"或".mil"域名的用户注册。Facebook网站创始人兼CEO马克·祖克伯格表示:"为了满足绝大多数用户的需求，我们对目前的业务进行了扩充，而在此之前，受限于客观条件一直没有进行业务扩充。"

　　Facebook表示，为了配合新的业务扩充，网站也加强了对用户隐私的保护。

　　9月21日，《华尔街日报》报道称，Facebook打算将自己出售给雅虎，双方当时正处于谈判中，据称Facebook的要价几乎接近10亿美元。

搞笑歌名排行榜

  1.王心凌《爱你》，S.H.E《我爱你》，Beyond《真的爱你》，李宗盛《我是真的爱你》，言承旭《我是真的真的很爱你》。
  点评：不用这么复杂吧！
 
  2.王菲《如果你是假的》，邓丽君《假如我是真的》，萧正楠《假如我是假的》。
　点评：能退货么？
 
  3.成龙《我是谁》，蟑螂《忘了我是谁》，蔡依林《你是谁》，许志安《忘了你是谁》。
　点评：你们都需要脑白金！
 
  4.萧亚轩《一辈子做你的女孩》，龙梅子《下辈子做你的女人》。
　点评：不错，成熟了！
 
  5.朴树《我爱你 再见》，丁薇 《再见 我爱你》
  点评：不送……

  6.苏永康《男人不该让女人流泪》，陈小春《女人不该让男人太累》。
  点评：多么体贴的小夫妻啊！
 
  7.姜育恒《爱我你怕了吗》，孙燕姿《害怕》，王力宏《不要害怕》，潘玮柏《我不怕》，赵薇《不怕》，郭美美《不怕不怕啦》，郑伊健《怕什么，什么也不怕》。
　点评：真是人多胆子大！

  8.董文华《春天的故事》，杨千桦《夏天的故事》，陈艾玲《秋天的故事》，马天宇《冬天的故事》。　　
　点评：小红帽，来！听狼外婆给你讲故事

Javascript:undefined & null

昨天遇到一个问题：之前工作良好的代码，突然不受控制。经过调试发现，函数中传递进来的undefined常量居然是一个对象(IE:Object, FF:NodeList)。最后换成null解决。

测试发现undefined虽然是系统内置的常量（表示类型/对象未定义）但不是关键字，可以像String对象一样被覆写（undefined={}）。


注：
Javascript中undefined和null是两种很特殊的类型/对象。undefined表示对象未定义，未定义对象会抛出不可预测的异常，而null则表示变量引用对象不存在。使用等于号（==）比较，他们相等；而使用完全等于号（===）比较时，他们不相等。

gnotify最近老连不上收件箱

不知道出于什么原因，从浏览器仍然可以打开Gmail邮箱，但是gnotify已经好几天连不上服务器了，害我总是在打开邮箱之后才发现有新邮件。可惜Firefox的better Gmail 2又只是在浏览器状态栏给个提示，并没有报警声。

An error has occurred.
Cannot connect to your mailbox.
Service temporarily unavailable

神龟遗照

咱（阔地 codyy.com）家长期被包养的小乌龟已于昨日傍晚神秘失踪，到此时已经24小时矣（如果是我，早就饿的不行了，不过这方面我应该差小乌龟太远了，不是一个级别）。关于小龟的神迹流传版本甚多，各种离谱之说，这里略过。

我很为小龟龟获得自由和自主生存的能力感到高兴，同时希望它不要因为这自由和这生存之能力而不能生存。

其实我曾劝诫carol放生，这样小龟将得到更许多的自由与更强大的生存能力，而不至于现在这样生死未卜、下落不明。不过像carol这样有爱心的人，绝然不会舍得小龟自食其力，辛苦过活的。

还好，有拍照癖的小温给它留下了几张“遗照”供我等怀念。

小龟，一路平安。

下面是两天评论：
[carol]说：。。。为什么我觉得你很高兴，原来我一直以为你不是一个将自己的快乐建立在别人郁闷之上滴银。。。我错了 (2008-07-11 10:07:14)

[闲耘]说：O, my Ga de.如果别人(包括别的动物)获得自由而让carol郁闷的话，我就是将自己快乐建立在你的郁闷之上。谢谢？！。：）
哈，玩笑。 (2008-07-15 15:54:15)

神龟遗照

咱（阔地 codyy.com）家长期被包养的小乌龟已于昨日傍晚神秘失踪，到此时已经24小时矣（如果是我，早就饿的不行了，不过这方面我应该差小乌龟太远了，不是一个级别）。关于小龟的神迹流传版本甚多，各种离谱之说，这里略过。

我很为小龟龟获得自由和自主生存的能力感到高兴，同时希望它不要因为这自由和这生存之能力而不能生存。

其实我曾劝诫carol放生，这样小龟将得到更许多的自由与更强大的生存能力，而不至于现在这样生死未卜、下落不明。不过像carol这样有爱心的人，绝然不会舍得小龟自食其力，辛苦过活的。

还好，有拍照癖的小温给它留下了几张“遗照”供我等怀念。

小龟，一路平安。

下面是两条评论：
[carol]说：。。。为什么我觉得你很高兴，原来我一直以为你不是一个将自己的快乐建立在别人郁闷之上滴银。。。我错了

[闲耘]说：O, my Ga de.如果别人(包括别的动物)获得自由而让carol郁闷的话，我就是将自己快乐建立在你的郁闷之上。谢谢？！。：）
哈，玩笑。

生死历险记

早晨上班，玉古路上遇到一貌似前世与我有仇之公交司机，挡我去路，夹我于龟裂之中，害我爆胎，几近谋我性命；完了又来个梅开二度，夹我于车道之中，欲与迎面之轿车相撞也。

于生死存亡之际，我冷静迎战度过危机，平时练就之单车本事亦派上自保之大用处也。

强行钢圈行路二千米，于玉泉站上了那与我有仇之同僚坐骑，迟到十分。

小议“范跑跑&郭跳跳事件”

前段时间范跑跑事件炒得相当的热，但是我一直没有关心，今天上网查了下事件的经由，并看了凤凰卫视一虎一席谈相关话题视频，了解了个大概。
说实在的，我还是挺支持范跑跑的，觉得他当时是在暂时失去理性的情况下自行先跑的。事后将这"有违伦理"的想法写成文也相当有勇气，道歉真诚而毫不让步。觉得范跑跑有点鲁迅的风格。

至于郭跳跳，是个不值一提的伪君子，而那个让我们怀念微笑的周老师也虚伪的还可以：你可以这么做（弃学生先跑），但不可以说出来；"我没有但是我想有，你连想都不想。"。。。


参考：
《范美忠 郭松民 凤凰卫视 一虎一席谈》( http://v.ku6.com/special/show_2458689/18QaQEVpFEhSLOBw.html )
"郭跳跳"的失态和时评人的缺憾 ( http://campus.eol.cn/guan_zhu_1854/20080613/t20080613_302578.shtml )
"范跑跑"、"郭跳跳"、"赵光光"…… ( http://www.ycwb.com/sp/2008-06/17/content_1913777.htm )

qout:
“不合时宜”后果如此严重？

我想，一个人如果仅因说实话本事而受到谴责，那么这个社会虚伪到了什么程度？构建文明社会首先应基于一个自由、公正的社会契约，而不应过分指望，依赖于人性的“道德”和“善良”。当社会的根基“公正”被破坏，以牺牲个人利益去成全多数人的利益成为一种“顾全大局”的行为理所当然地纳入道德体系；当主流价值观以正义和真理自居，扼杀多元化思想，践踏个体自由已经成为一种习惯；我们看到的一切社会问题便是一个系统问题，不是局部，更不是某些人某个人的问题。

让Google Calendar Sync支持Windows Server 2003

至于Google Calendar，没什么好说的，迄今为止世界上最优秀的Web日历（虽然离期望还差一截，但是目前仍然是最好的）。

很早就知道Google Calendar Sync了，但是它不支持安装在windows 2003上，直到今天才找到解决办法：右键安装文件->属性->兼容性->选中“兼容模式”，并选择下拉框中的“Windows XP”->确定。安装后运行很正常。如果需要，可以放到“启动”菜单中随机启动。

整个程序和gNotify一样简洁干净，只有状态栏图标和设置窗口。

经常计划一下要做的事情，有助于控制你的时间；记录做过的事情，有助于分析你如何才能控制时间。

全国哀悼日

19号到21号三天的全国哀悼日已经过去了，但是百度，谷歌中国，偶偶等网站还是一片灰色甚至关闭了网站。我认为似乎有点过火了，难道从此举国上下就不能娱乐了，不能见光彩了，为灾区做点实事才是重要的吧。

上面的话可能会被认为有点大不韪。

阶乘(factorial)&尾递归(Tail Recursion)

今天看了dennis的《用递归计算阶乘咋不行呢？》受益良多，这里做下小结。

传统的递归算法写起来很漂亮，代码很简洁，但是没递归一次就需要更深一层的堆栈支持，可能会造成内存溢出而失败，所以递归和goto语句一样声名狼藉。

甚至《代码大全》的作者有这样一句话：如果为我工作的程序员用递归去计算阶乘，那么我宁愿换人。作者对递归的态度相当谨慎，这在静态命令式语言中显然是正确的，但是在函数式语言中，由于有尾递归优化的存在，递归反而是最自然的形式，况且我打心里认为递归更符合人类思维。(by dennis)

尾递归就是从最后开始计算，每递归一次就算出相应的结果，也就是说，函数调用出现在调用者函数的尾部，因为是尾部，所以根本没有必要去保存任何局部变量，直接让被调用的函数返回时越过调用者，返回到调用者的调用者去。举例说明。

 

线性递归（传统递归方式）：

function recursion(n){

    return n==1?1:n*recursion(n-1);

}

 

尾递归：

function tailRecursion(n, a){

    a = a||1; // 尾递归之尾，即上次递归结果。

    return n==1?a:tailRecursion(n-1, a*n);

}

这里将基于尾递归的求数值阶乘算法贴下：

Math.factorial_III = function(n){
    var a = arguments[1]||1;
    return n<=1?a:Math.factorial_III(n-1, a*n);
};

 

效率上和循环迭代、阶乘改进算法相当甚至稍胜出（ie6,firefox2,safari3），普通递归的效率最为底下，且需要深入堆栈。

 

参考：
《尾递归》-百度百科
《用递归计算阶乘咋不行呢？》-dennis

罪名：程序员。

群里一个朋友开发时需要封闭，这是他们的聊天记录片段：

Ray(317058699)  9:35:30
封闭还未归？
aspirin(71446375)  9:35:38
早回来了
aspirin(71446375)  9:35:46
刑期已满
Ray(317058699)  9:36:09
呵呵，以后不要干坏事了哦，
IaiJava(282705730)  9:36:11
犯了什么罪？
Ray(317058699)  9:36:26
当了程序员。。

 

正则表达式拼接和构建零长度对象

之前在网上收集到一个正则表达式拼接的方法/函数，一直没有注意，直到昨天用jsdoc生成api文档时才看到。心里想这样的方法实际应用中大概没什么意义，但是出于好奇就拿出来玩了一下，这一玩不要紧啊，这么精炼的东西差点成垃圾。

可能是网络编辑器的原因，原始代码有bug，经过修正和测试，现在的代码如下：代码I

/**
 * 连接两个正则表达式。
 * 题外话：获得字符串常量""的长度，比构建空数组再求其长度效率高（忽略构建过程，求长度消耗时间相同）。
 * @param {RegExp} r 指定被连接的正则表达式对象。
 * @param {String} p 连接后的表达式使用的选项，由"i","g","m"组合而成。
 * @return {RegExp} 返回连接后的正则表达式。
 */
RegExp.prototype.concat = function(r, p){
 var i=(this.source.match(/\((?!\?:)/g) || "").length; // 正向预搜索。
 return new RegExp(this.source+r.source.replace(/\\(\d)/g, function($0, $1){
  return "\\" + (i+($1 | 0)); // 修正第二个表达式中的反向引用。注意这里的位运算。
 }), p);
};

原方法名是contact，现在为了和字符串类的一致，换为concat，至于bug/不足这里不做解读。

这个实际应用意义不大的小程式却有值得称道的几点：

1. 正向预搜索匹配第一个表达式里左括号（不包括非捕获组(?:)）的个数。

2. 当第一个表达式没有匹配时返回0长度对象（再求其长度），可以构建空数组（[]）和空字符串（""），这里使用空字符串，理由下面再解释。
3. 修正反向引用时用的位运算（），这里将匹配到的数值字符串与0位或没有其他意义，只是将数值字符串转型为数值，相当于parseInt()函数。

下面介绍为什么使用空字符串而不是空数组构建0长度对象。代码II

var I = 10000;

var d = new Date();
for (var i=0; i<I; i++){
"".length;
}
d = new Date()-d;

var d2 = new Date();
for (var i=0; i<I; i++){
[].length;
}
d2 = new Date()-d2;

document.write(d+":"+d2);

一万次循环叠加可以发现构建空字符串比构建空数组求长度快1到3倍。
再将代码改为：代码III

var I = 10000;
var s="";
var d = new Date();
for (var i=0; i<I; i++){
s.length;
}
d = new Date()-d;

var a=[];
var d2 = new Date();
for (var i=0; i<I; i++){
a.length;
}
d2 = new Date()-d2;

document.write(d+":"+d2);

可以发现，求空字符串长度与空数组长度的过程效率相当。可见，代码II处空数组效率多余的消耗主要在构建空数组对象上。

又是神奇的邮件

昨天收到的神奇邮件令我诧异不止，不想今天又收到一封更为神奇的邮件，它的来源是我自己的邮箱地址，却不是我发给自己的：

同样，它被放在了垃圾收件箱，同样打上了警告标语“Warning: This message may not be from whom it claims to be. Beware of following any links in it or of providing the sender with any personal information. Learn more”

邮件的内容为空，而标题则是RE...。你哪怕发给我一些广告也好啊，我想，现在这样让我怎么给你的身份定位呢？

你可能怀疑这是我发给自己的作秀邮件，但是我的邮件都会带上个性签名。而且我也尝试过，Gmail不会将发给自己的邮件当作垃圾邮件，也不会打上警告标语。

神奇的邮件来源

今天收到一封来自google.com域的垃圾邮件，如图：



当然，这个邮件地址是虚假的，它被Gmail自动放在了Spam里。邮件地址下面的红色警戒条上写着“Warning: This message may not be from whom it claims to be. Beware of following any links in it or of providing the sender with any personal information. Learn more”


这种虚假的邮件地址来源很常见，而且我还收到一些邮件地址不合法的邮件，甚至还收到收件人不是我的灵异邮件。


但是，纵然这封邮件的地址很假，纵然这封邮件被放在了垃圾邮件箱，纵然这封邮件本身也是广告内容，我在这里还是要提一下这封邮件本身，他是一封公益广告邮件，内容是拯救西北的沙化，绿化西北，防止沙尘暴。


下面是引用原文：

用您善良的心灵，请友善的点击一下吧!Http://www.net114.com/green/拯救地址，携手绿色西北行动用我们的 爱心我们的 责任我们的 双手
支持 绿 西北行动让沙尘暴不再肆虐 让 绿色 驱赶贫困让我们传递这个共同的责任!请友善的点击一下吧!Http://www.net114.com/green/

拷贝过来的文本已经失去了原文的格式，这里不做调整。

我看过文中提到的地址，下面发一些里面的牛图：

中国许多地区被沙化。




肆虐的沙尘暴。