CLURIES

一个耽搁了很长时间的项目，断断续续做了半年了吧，期间太多事情，二周都不写一句代码的事情经常出现，对这个项目的前景也越来越不看好。不过想到自己做了太多的半途而废的项目，不管怎么样，这个项目还是咬咬牙坚持下去吧。 于是，就这么一直坚持下来了，虽然现在时间更忙了，基本下班后就没时间写代码什么的。 最近，做到一个需要输入解锁密码的功能。 最开始想法是通过UITextFieldDelegate来实现，先回顾UITextFieldDelegate的定义： Managing Editing – textFieldShouldBeginEditing: – textFieldDidBeginEditing: – textFieldShouldEndEditing: – textFieldDidEndEditing: Editing the Text Field’s Text – textField:shouldChangeCharactersInRange:replacementString: – textFieldShouldClear: – textFieldShouldReturn: OK，看到这些，基本上是可以做出想要的效果了。 不过在实际的开发中，发现没那么简单，做出来的东西总不对，总是有问题不好解决。 然后又想到去监视键盘事件，不过觉得这样做会更麻烦。 正在烦躁中突然想到一个办法，把四个密码输入框的enable设置为NO，真正的密码输入的TextField其实是一个大小为0的不可见的一个TextField，然后每次输入一个字符后把响应的字符赋值到4个密码框中的一个，让看起来是输入到四个密码框中。 部分粗略代码如下： -(void) setTextFieldStyle:(UITextField*) textField { [textField setBorderStyle:UITextBorderStyleRoundedRect]; [textField setFont:[UIFont systemFontOfSize:32]]; [textField setTextAlignment:UITextAlignmentCenter]; textField.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter; textField.keyboardType = UIKeyboardTypeNumberPad; textField.secureTextEntry = YES; textField.enabled = NO; } -(BOOL) [...]

今天又搞到一个VPS(大笑)。 在搭建必要的环境的时候突然想起自己博客所在的VPS所用Nginx和PHP版本都比较老了，正好前不久PHP又爆出一个很严重的”Hash冲突拒绝服务攻击的”漏洞，于是想升级到最新的版本。 PHP的升级要稍微麻烦一些，首先要找到配置目前的 PHP 的 ./configure的参数，根据PHP官方文档的方法，这个参数可以用下面方式获取： http://www.php.net/manual/zh/faq.build.php#faq.build.upgrade 要么在你当前的 PHP 的安装目录查看 config.nice 文件，如果没有，只要运行此脚本： phpinfo(); 在输出的顶端显示了用来配置此 PHP 的 ./configure参数。 不过个人觉得这个方法获取到的 configure参数是不完整的，不过还好我当初保存了 configure的参数，就为了方便以后升级。 PHP configure后直接make 和 make install后就可以完成升级，配置文件因为以前配置了，所以也不用去管，不过一些扩展如eAccelerator需要重新编译。 扩展的重新编译非常简单，直接切换到以前make的目录，也不用执行phpize了，直接make和make install就完成升级。配置文件和PHP一样，不用理会，直接使用以前的。 Nginx的升级比php简单很多，要确定当前运行的Nginx的 configure参数，运行下面的命令就可以得到。感谢twitter上的@vnline和@JavasBoy告诉我这个方法。 nginx -V 使用得到的configure参数配置新版本的代码，然后编译，就可以安装了。不过重新安装之前，需要关闭正在运行中的Nginx。 这样，Nginx和PHP的版本就升级完成了。

今天有人在某QQ群中问下面这个结构体有多大： #pragma pack(4) struct STV { char a; short int b; char c; }; 当时我第一反应是12，不过又总觉得有点不对劲，还是写了段代码测试下，发现结果居然是6. 嗯？6，难道编译器没看到这句话么：#pragma pack(4)？ 但是当我把结构体的定义修改为 #pragma pack(1) struct STV { char a; short int b; char c; }; 后，结果又变成了4，那么#pragma pack是在起作用的。然后又试着改为#pragma pack(8)和#pragma pack(16)，结果还是6. 心中大概有点明白为什么了。 google之，原来对于#pragma pack的处理方式是这样进行的： 当结构体中最长宽度的数据成员的宽度小于 n 时，按该成员宽度对齐； 当最长宽度的数据成员的宽度大于或等于 n 时，按 n 对齐。 结构体STV中成员宽度最大为2，所以当n=4，8，16的时候还是按照宽度2来对齐的。 –EOF