Crane
Table_bottom

Search
Loading
Table_bottom

分类
Table_bottom

随机文章
Table_bottom

标签云
Table_bottom

最新评论
Table_bottom

链接
Table_bottom

功能
Table_bottom

创意验证码

行走网上,不免看到好的服务,想要使用,于是第一道门槛就是注册,而且现在为了防止机器自动注册,大多采用了验证码,就此一验证码,各家是各有特色啊,一般的纯字母数字组合的不再提,而Yahoo,Google的要是碰上了的话,是个人都半天认不出来,更不要说机器了,传说这才是真正功能强大的验证码,但是人都认不出来怎么办,来个声音提示,读一遍就行了。

记得以前看到过一个新奇验证码的集合,不过不记得地方了,也没有收集下来,大概记得有个叫计算极限的比较有意思,类似这种

请输入下列式子的答案:

\lim\limits_{n\rightarrow\infty}(1+\frac{1}{n})^{n}

这样的我觉得创意已经够好了,结果今天看到一个更绝的:

验证码

这个应该还好吧,不过我刷新了一下,看这个

程序验证码

上面那个还可以用眼睛看出来,这个就得好好花一点功夫了,非geek不会玩这种东东。

一般都会跑一下这个程序来得到结果,这里有在线服务可以办到这事,强强的codepad就可以。

消失的11天

最近做一个万年历的作业,粗粗了解了下历法,做农历的时候发现农历没有固定的算法,只能查表来计算,中华人民共和国提供了1800-2100三百年间的标准农历供使用,于是一下子限制了我的程序的查询范围。所以想着公历的准确,计算的容易,可是正想着公历算法的好呢,发现了一个问题,那就是以前公历不大完善的时候,也有问题。

比如这个,在linux下打入这个命令(windows限制时间范围是1980-2099,所以看不到这个现象)

[email protected]:~$ cal 9 1752
   September 1752
Su Mo Tu We Th Fr Sa
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

cal 9 1752就是查询1752年9月的日历,于是很跌眼镜的发现,2号后面就是14号,少了11天,怎么回事呢?

查了下资料,发现是因为历法调整的问题。

1582年2月,罗马教廷要求从1582 年10月中减去10天,因此1852 年10月4日后面紧跟着就是15日。在意大利、西班牙等国家都这样处理了。其他天主教国家也很快跟着这么做了,但是新教国家不愿意修改,而且希腊等东正教 国家直到20世纪初才修改,所以这个改革在英国及其殖民地(包括美国)在1752年9月才被执行。这样 1752 年9月2日后面跟着的就是1752 年9月14日。 这就是为什么cal会生成上面输出的原因了。

这里有个问题,上面说教廷说的是减去10天,但是刚才发现1752年9月减了11天,这是为什么呢?

这是历法转换的问题,现行公历叫格里历(Gregorian calendar),这是十六世纪的罗马教皇Gregorian XIII (格里十三世)针对当时使用的儒略历 (Julian calendar)进行修订后,于1582年10月开始实行的。所以就出现了上面的1582年10月调整10天的情况。但是由于写cal的是美国人,cal是从AT&T的Unix中出来的,前面说到过,美国跟从英国的历法是从1752年才开始改的,所以不太一样,所以还牵涉了1600-1800年的一些问题。

根本原因是因为1800年以前的闰年计算的问题,我们知道闰年是4年一闰,百年不闰,400年再闰,但是1800年以前(所以不包括1800年)没百年不闰,所以就出现了偏差,比如我们可以看一下

[email protected]:~$ cal 2 1700
   February 1700
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

[email protected]:~$ cal 2 1600
   February 1600
Su Mo Tu We Th Fr Sa
                1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29

可以清楚地看到,1600和1700年2月都是29天,一眼看去,想当然的认为多算了17天,其实实际上多算了13天,因为400,800,1200,1600是闰年,2月应该有29天。但是为什么调整的时候只少了11天呢,有个很纠结的原因,由于儒略历 (Julian calendar)公元前闰年的不规则,少算了2个闰年,从13天中去掉2天,所以在cal中看到的是少了11天。

话说回来,做万年历的时候这可是陷阱啊,得小心才是。

WikiTaxi--随身带的wikipedia

喜欢读书的朋友都可能会有过这样的想法,要是自己家有个图书馆就好了,可以天天在家看书,想看什么就看什么,不用跑图书馆了。

想必常上网的朋友也有这样的想法,wikipedia可真是个好东西,要是能搞一个在自己电脑上,那查起来不仅速度超快,而且离线也可以使用,多好啊!

其实,对于图书馆,我们没有办法,但是对于wikipedia,我们可是有不止一种办法噢!

首先是个精简版的wikipedia叫Pocket Wikipedia,这个口袋维基是一个精选版本,选出了重要的条目,而且是原汁原味的wikipedia,据说图片什么的都不少,但我查了一个Emacs没图,这个软件所有的东西都打包在一个zip包中,不到200MB,可以随身带,放U盘啊什么的都很方便。

软件是这个样子:

PocketWikipedia

右边那个位置本来是有图的,不知为什么没有显示出来。

可能有发烧级的觉得这个口袋版的容量太小了,不能满足要求,要知道英文wiki可是已经突破200万词条了,下面这个家伙便可以让你拥有最新wikipedia。

WikiTaxi,也是一个移动版的,不需要安装,只有两个可执行文件,一个是主程序,一个用来导入数据库,只有有了个这个数据库才能做到在本地查询,这个数据库可以到wikipedia上去下,英文数据库的地址在这里,这个是最latest的版本,bz2压缩的,大概有4.8G的大小,可以想像里面有多少内容,你也可以从朋友那里拷。有了这个后用那个包中的WikiTaxi Importer把这个xml.bz2导入成WikiTaxi database文件(以.taxi为扩展名)。PS:这个可能用的时间比较长。

有了这个.taxi文件后,执行主程序WikiTaxi,选刚才你生成的那个.taxi文件,成功的话会随机显示一个页面,然后就可以本地查询wikipedia了,速度当然一流。

WikiTaxi

可以按“CTRL+L”激活那个搜索框,而且也支持一些搜索功能,它的搜索大小写不敏感,全部按小写处理,也可以精确匹配,只需要把搜索词用双引号括起来,也可以用“- word”表示不包含某些内容,用空格分隔单词表示按and搜索,两个词中间加个OR表示匹配任意一个,是不是和google的搜索语法很像呢!See more:http://www.wikitaxi.org/

有了这些工具,我们就相当于有了一个随身携带的资料库,用知识武装到牙齿了!!