一会儿是多久?

转自: http://nhdxb.cuepa.cn/show_more.php?doc_id=241550

一个周末的上午,碰到一学生,学生说在等一位老师,8:00开始等,已经超过一小时了。我建议她再打电话催一下,她说,已经催过,可老师从开始——第一次接电话就说“等一会儿”。
一会儿是多久?
一般人理解为十分钟到半小时。若以20分钟计,这20分钟的空间也是够大的,简直是大得吓人!在这20分钟——1200秒的时间内,刘翔或者博尔特可以创造100个左右的世界纪录!比尔盖茨可以创造“133180美元”的价值(“英国达人”苏姗创造的价值更是这个数的两倍)!
然而,我的这位可怜的学生为了等他老师的“一会儿”,居然花掉了70分钟——3.5个“一会儿”。
无心追问等70分钟的原因,更无力追问谁该为这“一会儿”买单。在中国,等70分钟算什么?飞机、火车、汽车、轮船等等,一不留神就会告诉你“又晚点‘一会儿’”,晚70分钟算你幸运,一天、半天都是家常便饭。
可怕的是,我想到了一个很悲哀,也很悲观的命题——中国人的经验思维模式与经验主义太顽固!
中国人擅长形象思维,擅长经验总结,未尝不是令人骄傲的事,然而停留于此便是悲哀了!
因为经验主义,所以能成就《本草纲目》,却成就不了《进化论》;因为经验主义,所以汉语中的经验词汇(模糊词汇)比比皆是、不计其数——一会儿、立刻、马上、少数、极少数、个别、少许、部分……因为经验主义,中国的文明终究没能“冲顶”成功,而没落于十九世纪——以现代科学技术迅猛发展为主要特征的工业革命兴起之际。
该醒醒了,都已经到了百分之一秒的时代!科学需要经验,但不需要“经验‘主义’”。
中华民族要实现伟大复兴,“科学”是必由之路。

关于前缀查询的实现方式

在Tokyotyrant中有支持根据前缀来查询的方式,命令行如下:

tcrmgr list [-port num] [-sep chr] [-m num] [-pv] [-px] [-fm str] host

参数中的-fm 就是要指定的key的前缀,试想:不同的存储方式中,这种操作是怎么实现的呢?

1. 对于hash存储,遍历所有的key,然后和提供的前缀来比较,显然效率是很低的,所以如果有这种需求,就不要使用hash存储

2. 对于tree的存储方式,比hash方式查找要比较的少一些

3. B+tree, 这个就比较快一下,这个是比较适合的存储方式

域名解析时的进程死锁问题

PHP有遇到新问题:

不管使用file_get_contents() 还是 curl 都会遇到这个问题,不过,很像是一个更底层的问题:__lll_lock_wait ,涉及的系统调用为: fmutex

 

使用file_get_contents() 是的堆栈:

 

使用curl时的堆栈:

 

分析:

应该和域名解析有关

这里都用到了 getaddrinfo() 函数了,于是怀疑问题出现在getaddrinfo() 上,使用gethostbyname() 测试了一下,没有在遇到类似问题,但是后来又在另外机器上发现如下错误:

 

关于现代20手机使用中的一些问题

关于通讯录的问题

删除全部通讯录

可以选择删除sim卡中的还是手机中的;删除全部通讯录需要密码,默认密码为: 1234

识别的通讯录的格式

该手机识别的通讯录的格式和其它只能手机都不太一样,文后提供一段转换脚本;当然,这个是通过先将手机中的通讯录导出成文件后,分析导出的格式写的代码,这里关于通讯录的格式有几点注意事项:

// 1. 文件必须是 ANSI 编码
// 2. 文件必须是PC格式,不能是UNIX格式,即: 必须是 \r\n 换行,不能是 \n 换行
// 3. 电话中不能含有特殊字符, 如: 186-1234-5678 是不可以的; 但是 +8618612345678 是可以的
// 4. 删除全部联系人需要密码,密码为: 1234

 

转换脚本如下:

 

 

 

http://www.google.com.hk/finance?chdnp=1&chdd=1&chds=1&chdv=1&chvs=maximized&chdeh=0&chfdeh=0&chdet=1348400359756&chddm=8211&chls=IntervalBasedLine&q=NASDAQ:SINA&ntsp=0&ei=evReULCfGomkkgXZ0wE&gl=cn

关于实现验证码需要注意的问题

缘起:

如果能在用户输入验证码后就知道输入是否正确的话,用户体验会好很多,而且对于难以识别的验证码还能给用户重新输入的机会。【后来才发现,允许重新尝试同一个验证码本身就是有安全问题的

思考:

方案1: 验证码不和真实业务数据一起提交的话,而是验证码先提交,如果验证码正确则换取一张有效的凭证,然后将凭证和真实业务数据一起提交;否则刷新验证码(安全考虑,验证码必须验证一次后失效),重新输入

方案2: 生成验证码图片的时候,将验证码的hash值返回给用户端,这样,用户输入验证码后,通过js来比较hash值,就可以在很大程度上预判验证码的正确性了,因为同一个验证码可以尝试多次(这本身就是个漏洞)。

安全方面的考虑:

  1. 如果hash值是对验证码直接做的hash,则:
    1) 可以生成一个足够大的hash值的数据库,直接根据hash值反解出验证码
    2) 图片验证码的识别技术 + 根据hash值的进一步校验,使得验证码的破解成功率大大提高
    3) 可能有一个足够强大的计算平台,根据一定的规则反解hash值
  2. 或许可以对验证码和一个临时的随机串来一起来做hash值,如此,则:
    1) 图片验证码的识别技术 + 根据hash值的进一步校验,使得验证码的破解成功率大大提高
    3)   可能有一个足够强大的计算平台,根据一定的规则反解hash值
  3. 理论上来讲,验证码必须只能验证一次后失效,否则:
    1) 图片验证码的识别技术 + 根据hash值的进一步校验,使得验证码的破解成功率大大提高

 结论:

方案1 基本可行,但是要对验证码的尝试做IP封禁策略

方案2 对于不太关键的业务或许可以临时用一下

 

验证码服务模型

1. 一个输出验证码的接口,同时输出验证码的id

2. 一个验证验证码的接口,可能会输出验证成功的票据(票据是一次性的)

3. 一个验证票据的接口

 

票据的引入为了处理这种情况: 提交的数据量比较大,如果提交后报告验证码错误,显得很没有效率;这种情况,就可以先验证验证码,验证码成功后再提交数据,但是需要借助票据来实现

 

母亲我叫钓鱼岛

母亲我叫钓鱼岛
七百年前你起的名字植入我的襁褓
我徜佯在你温暖的怀抱
从此我不再是无根的水草
母亲我叫钓鱼岛
一百年前的马关火炮
撕裂我伤痕累累的骄傲
我在你的眼眸里云散烟消
那些年你可知道
我飘摇的心多么需要依靠
母亲我叫钓鱼岛
六十年前你轻轻把我的名字呼叫
我的欣喜被阳光照耀
可是强盗在最后时刻强行夺去了我的贞操
那一刻,母亲你可知道
我屈耻地活着水深火热地煎熬
母亲我叫钓鱼岛
三十年前强盗在我的身躯上修起了跑道
他们想要掠夺我
全部的妖娆
我不应该是强盗餐桌上的佳肴
我的呐喊母亲你可听到
母亲我叫钓鱼岛
二十年前强盗在我的身躯上让灯塔闪耀
他们想要占有我的身体到天荒地老
我不应该是强盗无耻的夜宵

我支离破碎的容貌母亲你可看到
母亲我叫钓鱼岛
不是强盗嘴里的尖阁列岛
我不应该背着沉重的背包
在尘世的纷纷扰扰中被人嘲笑
我的精彩应该闪
耀在你博大的云霄
我的骄傲应该执着在你温暖的怀抱
母亲我叫钓鱼岛
我期待期待那一秒
您披起战袍吹响号角
在犀利的炮火中将我的名字呼叫
那一刻母亲
躺在你温柔怀中我是您永远要呵护的宝
母亲我叫钓鱼岛