MENU => PROFILES | FOCUS LISTS | MUSIC WORKS | CONTACT
Fedora 10 Cambridge 即将发布
好吧我承认这阵子找不到什么话题来写BLOG，于是乎……
下面这个Banner会自动倒计时的，在微软黑屏和大门叔叔早已布置好的10年计划的围追堵截下，希望有更多的朋友能够认识Linux吧～就这样……
这东西，应该建议公司给每个人都刷一张
好吧我承认我有点无聊，公司的新LOGO还只是个征求意见稿，嘛，等定下来了我重新做一张再刷一遍就是了
。美中不足的是那几块系统强制加上去的东西，其实Energy Star那个还不难看，Intel那个也算可以，就是“a product of Lenovo”那条实在是太不和谐了，还非要是黑的orz。嘛……既然去不掉也就只能摆在那里了orz……
这东西，应该建议公司给每个人的电脑都刷一张，多拉风。
【NOTICE】擅自修改、刷写BIOS有变砖风险，且不属于保修范围，操作须谨慎。
关于MSN机器人的一点开发心得
从进公司以来就想自己学学JAVA，无奈我这个人是一定要有实际的工程才能有心思学的（你这个啥的不会的公司也不会把项目给你做啊=v=|||），不然看了半天文档还是没有用啊～最近一段时间项目没那么忙了，我把以前尘封的一个想法翻了出来，那就是写一个MSN机器人。以前从来没有用过OOP（面向对象编程）的编程语言，一直觉得是一个遗憾，进公司之后从CakePHP架构上接触了MVC（Model-View-Controller，数据模型层-表现层-控制层）的理念，才算是有了一些OOP的影子吧，既然OOP是现在的主流，作为自称会写程序的我来说，还是不能不学的呀……嗯，公司的Reinhardt.Shi师父在JAVA上给了我很大的帮助，在此表示感谢m(_ _)m。
说起JAVA，这个东西的最大优势就是“一次开发，到处可用”，因为代码是在虚拟机上运行，所以拥有跨平台的移植性能，而也正是由于要在虚拟机上运行，因此JAVA的代码在效率上存在着不足。不过MSN机器人这个东西，只是个实验品而已，也不会过多牵涉到对于代码效率的研究，所以用来练习JAVA是个不错的项目～这个项目现在还在开发中，暂时先不公开测试（小规模内测状态=v=|||），下面只是说一些心得和感想，牵涉到项目的各个方面的。
怎样的字体色和背景色搭配是合适的？来看看W3C的标准吧
这两天在研究用JAVA开发类似MSN机器人的应用程序，今天想到要让程序每次发送消息的时候更换一种随机的字体颜色，于是这就有一个问题，假设大部分情况下背景色是白色（#FFFFFF）的，万一随机出来的颜色太淡看不清楚怎么办呢？这时候就需要一个对于颜色的判断标准，我首先想到的就是亮度，每种颜色有它的色彩亮度，这个计算在JPG压缩等场合也会用到。这里提供一个由RGB计算色彩知觉亮度的公式：
Y = ((R*299)+(G*587)+(B*114))/1000
根据这个公式，白色的知觉亮度最大，为255，而黑色最小，为0，根据W3C标准，字体色和背景色的知觉亮度差值大于125，也就是至少有50%亮度差异的情况下，人眼比较容易辨认。看看上面这个公式，可以发现在亮度计算中，RGB所占有的权重不同，绿色居然占到了58.7%的权重，以前还真没注意到……
除去亮度以外，背景和字体的色彩差异也是对辨认感有影响的，而色彩差异则是通过计算两种色彩RGB的差值绝对值之和，即：
Δ = |R1-R2| + |G1-G2| + |B1-B2|
根据这个公式，黑色和白色的差异最大，为765，而W3C的标准建议，背景和字体颜色的色彩差异应当大于500，也就是至少有35%的色彩差异，人眼才容易分辨。
参考资料：W3C Working Draft
[工作笔记]PHP的GD函数imagettftext()要注意默认字符编码
这阵子在开发一个小功能，就是类似论坛个性签名的东西，根据会员信息自动生成一张图片上面还有文字的那种。图片的拼合用imagecopy()和imagecopyresampled()等函数就可以搞定，到了画文字的时候遇到了一个难题。文字的模板是保存在一个文本文件中，程序先读取这个文件然后用数据替换掉里面的变量，再使用imagettftext()函数画到图片上，不幸的是画出来的图片居然是乱码@_@……于是上Google搜索相关的问题，发现大部分人都是在说imagettftext()函数中传递的字串要UTF-8编码，而PHP官方手册中也明确写着“UTF-8编码的字串可以直接传递”，可问题是模板文件的编码本来就是UTF-8的，这就有点莫名其妙了。无奈之下我用EmEditor打开原来的模板文件，尝试转换成不同的编码后和GD输出的乱码做对比，结果发现转换到EUC-JP编码的时候居然和GD输出的乱码吻合了……也就是说，这里服务器上GD的默认编码是EUC-JP，而那是一种日文编码。查找了一下php.ini的设置没有发现相关选项，于是又一个问题来了，这个默认编码是在哪里设置的呢？还是史文大哥牛，发现了PHP编译参数里面有一个“–enable-gd-jis-conv”的参数十分可疑，Goo一下果然发现了很多乱码问题与这个编译参数有关……官方给出的参数说明是“GD: Enable JIS-mapped Japanese font support.”，也就是让GD支持日文编码的字库（可恶，为什么没有支持中文编码字库的编译选项……PHP也国籍歧视么= =b），说白了开启了这个选项的话GD就会把TTF字库中大于127的部分（即不属于标准拉丁文字库的部分）按照日文JIS的顺序来映射，那么用来映射中文字体的时候自然就变成乱码了。二话不说，去掉这个选项重新编译，问题解决。去掉这个选项之后，imagettftext()的默认编码就变成了UTF-8，就可以正常显示中文了～
[工作笔记]优化PHP平台网站性能别忘了PHP编译缓存工具
工作上遇到了一个比较大的问题，我们运营的网站由于从8月底在其它网站投放广告以来，访问量急剧上升，再加上新功能的上线，网站的性能面临着前所未有的压力。从8月27日开始的一周之内，凡高峰时段（9:00-18:00，19:00-21:00）网站的响应十分缓慢，几乎就无法正常访问，导致广告招募会员的效果基本流失。在使用放置在同机房的另外一台服务器测试后，排除了网络因素，通过MRTG的图表来看，很明显高峰时段CPU的占用率一直维持在99.9%，登录到服务器上用TOP命令监测进程，发现几个httpd进程（一般有3～4个进程）一直占用99.9%的CPU资源，居高不下。
网站的硬件架构是两台配置一样的Red Hat服务器，配置为Apache2、PHP5，使用Pulse实现负载均衡，另一台数据库兼NFS共享服务器为MySQL5。既然是httpd占用CPU那么就是Apache或者PHP所造成的了。首先从Apache的设置开始进行优化，涉及超时时间等设定，这里面有一点值得说的，那就是Apache的文档上说Apache2在UNIX平台上运行最好不要使用Threaded MPM（Worker）模式进行工作，以免发生运行不稳定的情况。于是我们尝试将Apache编译为Prefork模式运行，结果发现速度比以前更加慢了……其实道理也很简单，Prefork模式其实是用资源来换取稳定性（每个独立线程都有独立的内存资源，对于PHP应用就比较稳定），在现在CPU资源紧缺的情况下显然是火上浇油。
Apache换回Worker模式之后再考虑其它方面的解决方案。本来是觉得既然服务器已经到负荷极限，那么再添一台WEB服务器也是计划之中的，而且这部分预算也是有的，问题是按俺PL同志的经验来看，这样的负荷不足以让这么好配置的服务器到达极限。之前研究过一个问题，那就是服务器是64位Xeon处理器，而安装的操作系统是32位版本的Red Hat，但是咨询了Red Hat的工程师之后得到的答案是，这样对性能没有影响，只是64位CPU以32位模式运行而已。接下来从PHP上面入手，开发方的PM同志给了一个建议说可以安装eAccelerator试试看。这东西是一个PHP缓存，也就是说将编译好的PHP脚本进行缓存，以节省每次运行的编译过程，提高PHP程序的执行效率。服务器上已经安装过Zend Optimizer的，原本以为那东西也是类似这样的缓存工具，结果后来才发现缓存工具是Zend另外一个产品，收费的，而这个Optimizer只不过是页面压缩输出而已……
于是eAccelerator的安装上面也遇到了一些问题，主要是它跟Zend的兼容问题，如果作为PHP组件安装的话，必须要在Zend前面载入才行（官方文档：http://www.eaccelerator.net/wiki/TroubleShooting）……安装好之后大吃一惊，高峰时CPU占用率维持在70%左右，页面响应速度明显提高了一个等级，某评测网站上说eAccelerator可以让PHP执行效率提高越3～4倍，看上去并不是夸张的说法……
以上仅仅对这次事件的处理进行一个简单的记录，提醒自己和大家在优化PHP平台网站的时候不要忘记还有PHP编译缓存工具的存在。
关于Live Messenger字体问题的解决方案
自从Live Messenger（即MSN 8.0）版本出来之后，在很多系统上都会出现字体大小显示异常的状况。最初是我自己的电脑，好像从7.5版本就有这个问题来着，联系人列表中中文字体非常小，由于Windows的宋体在9pt以下就很难看，所以不管什么软件在显示中文字体上9pt应当是可以允许的最小值。网上也流传了很多关于字体大小的修改方法，基本原理是修改msgsres.dll（即资源库）中几个常用字体的fontsize属性，强制改为9pt。但是MSN里面设定字体大小的地方很多，这样改虽然可行但是并不是根本的解决方案。
我们看一下msgsres.dll里面的描述就可以发现，8.0版本刚出来的时候，其字体大小的代码是这样写的：
FontSize:SysMetric(-16);
其中SysMetric的含义应该是取操作系统的某个默认数值，然后在这个基础上减去16。因此在8.0版本里面，要修改字体大小就只能从msgsres.dll里面强制改成9pt。不过从8.1版本开始，字体大小的定义方法变成了这样：
FontSize:rcint(20102)pt;
FontSize:rcint(40614)pt;
其中rcint是向其资源文件取字符串，编号为20102和40614，这和一些MSN本身用到的字符串取法是一样的。譬如MSN上要显示“外出就餐”这个字符串，因为每种语言版本的MSN显示的内容都不同，就需要把字符串单独放在一个资源库里面来调用。字体和字体大小也是同样的道理，应该根据语言版本是有所变化的。因此如果你使用的是MSN 8.1版本，可以Resource Hacker之类的软件修改一下msgslang.8.1.xxxx.xx.dll（xxxx是版本号），具体方法请参考这篇文章：
http://superding.spaces.live.com/blog/cns!89E842A8485366C7!820.entry
不过不知道作者的版本是什么原因，他用Resource Hacker修改过之后出现校验错误，最后只能用二进制编辑器来改，不过我用RH改过之后却没有问题，因此大家尽量先使用RH来做测试。另外我们把这篇文章的思路拓展一下，我们还可以把MSN的字体改掉，比如很多人现在都喜欢用微软雅黑，那么你先从msgsres.dll找找以下代码：
FontFace:rcint(xxxxx);
然后记录一下找到的字符串编号，从msgslang.8.1.xxxx.xx.dll中找到相应的字符串，改成微软雅黑的字体名称“Microsoft YaHei”就OK了。我用的版本的话是修改了40614、49803、20071号字符串，为了以防万一，大家还是先从自己的msgsres.dll中查找一下吧。哦对了，FontFace是“Marlett”的不要改，那个是滚动条上的小箭头啦之类的系统标记，改掉你就等死了orz雅黑字体的话8pt也不难看，喜欢小字体的朋友也可以尝试一下。另外还是要提醒大家改之前备份一下原来的文件，实在改得面目全非又懒得恢复的话，就把文件夹整个删掉重装一遍吧～不然你新改过的文件，貌似直接重装是不会覆盖掉的。