自勉

社会是残酷的，人情是冷漠的；不要期望向社会索取太多，也不要期望别人能给自己什么。得之幸也，失之命也。

或许还有饿死的鬼，或许还有冻僵的尸；但是我不会，只是觉得有很多事情难以理解，或许被气死是有可能的，所以撰此文以自勉，寻求一些精神的慰藉。

很多时候，不是自己得到的太少，只是自己期望的太多，惹来一些不愉快，浪费的还是自己的时间，阻碍了自己的进步。所以，要理性地期望，不要有太多的期望，得之可兴，失之不悲。

曾经在上学的时候，我一直告诫自己：要不断地自我完善与发展，继续保持谦虚谨慎的作风，继续保持不骄不躁的作风；这些对我的影响很大。工作以后，我更感觉到学习的重要性，几乎无时无刻不再学习，学习使我不断地进步，学习给我带来了很多；不知道从什么时候开始，自己变得有些懒惰了，也有了些抱怨；我感到了问题的存在，这里有方法的问题，更有心态的问题；我想，我改变不了什么，只有重新回到学习的轨道上来，找回真正的自我，学习不仅能让我找到解决问题的办法，更能让我避免陷入一些不必要的烦恼；切记： 学习是一种信仰，学习是一种心态，学习是一种习惯。

在和别人相处的过程中，善待他人，不急不躁，不要苛求别人对自己有多好，再拾起曾经一度告诫过自己的一句话：人之有恩于我者，不可忘也；我之有恩于人者，不可不忘也。

 

如果能做到上面的这些，生活中当会少却很多烦恼了，也有利于自我完善与发展。

一会儿是多久？

转自： 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. 一个验证票据的接口

 

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