IT 技术领域学海无涯。其实任何领域都学海无涯，无非 IT 发展太快了，让我有更多嘘唏。希望我掌握的技术有如小小草，虽然渺小，却有旺盛的生命力。
Zend Framework is evolving quickly. Some while ago, it did not have Zend_Paginator, but now it’s there. But a component of paginator is enough for me. I want something like Zend_Datagrid. It’s not there yet.
pao.fresco has developed Datagrid for Zend Framework. It looks good, but I am not confident using unofficial code.
Magento also implement its own datagrid, but I do not know how to utilise as part of code outside of Magento.
I can not blame Magento for its slow. It is such a big system aim to fit in all sectors of business. After all, after optimisation, Magento can achieve a decent speed on a entry level of server. However, I think Magento developers should bring more features of ajax into Magento. Fore example, when adding a product to compare, Magento give a success message “Product brah brah successfully added to compare list”. Magento currently reload the page to show the message. It is absolutely not necessary. Why not use ajax?
我感觉配置 nginx 渐入佳境了。配置 nginx 时应该用不同 apache 的思维，最主要的不同点是：
apache 是 fallback 式配置，比如有两个 <directory> block，分别是 mydirectory 和 mydirectory/subdir。mydirectory/subdir 可以重写 mydirectory 的 directives，但 mydirectory/subdir 没有提到的 directives 就沿袭 mydirectory 的 directives。
nginx 是 parallel 式配置，location 只能按优先规则取其一。
另外，我觉得有人批评 apache 层层检测 .htaccess 造成效率低下的一个原因。我感觉这种说法并不妥，很多 apache 发行版默认 allowoverride none，用户只要根据需要在确实需要启用 .htaccess 的那一层启用 allowoverride，这并不造成效率损失，反而带来配置的灵活性。当然，nginx 不需要这种灵活性，因为它不是面向 share hosting 的产品。
除了内存占用大是 apache 的硬伤，其他 nginx 的优势并不明显，apache 同样可以优化配置达到相应的效果，尽管很多配置不是 apache 的默认配置。（这只是我的总体感觉，我并没有深入去比较，欢迎探讨。）
最近被 Lycos.co.uk 搞得够呛。它突然洗手不干了，估计是因为经济危机的关系。一个不想继续经营的公司服务质量是无法保证的，而且连个 complain 的地方都没有！
我用到 lycos 的地方并不多，但还是在域名转移上有点麻烦。有几个 eu 域名委托 lycos 注册时，lycos 把联系人邮箱填为我的 lycos id，这个 id 已经无效了。而我一直认为 eu 域名转出需要原注册商的配合，所以反复请求 lycos 支持，而 lycos 爱理不理。事实上并不需要 lycos 配合。现在无暇去研究这个转移模式是否合理，能转成功已经谢天谢地了。
以转到 godaddy 为例，godaddy 称之为四部曲：
前两步几乎是同时完成的，只要在 godaddy 账户里点点鼠标就可以，第三步比较关键，但 godaddy 说
The transfer is waiting for the customer to accept it at the losing registrar. If the customer does not accept the transfer at the losing registrar within 5 days, the transfer will be accepted automatically.
这么说默认是 Accept 。如此很好，只要等上 5 天，域名就到 godaddy 账户项下了。
ngnix 0.6.35 没有实现 path_info。不知道 nginx 开发者是疏忽了，还是觉得没必要在 http server 层实现 path_info。我印象中有很多 php 程序的运行都依赖 $_SERVER[‘PATH_INFO’]，所以在 ngnix proxy pass 给 php-cgi 之前，必须设置好正确的 path_info 参数。
我认为最好的办法还是用正则表达式在 $fastcgi_script_name 里隔离出 script_name 和 path_info，但这样计算出的 path_info 用起来不如 ngnix variable 方便，而且得在脚本的安装位置或扩展名确定时才能写出相应的正则表达式。我是 nginx 新手，在 path_info 上折腾了三天才总结出一个相对满意的方案。如果 nginx 能给我一个 in-built variable $path_info，那会省事很多。
当然我并不想责怪 nginx（apache 已经够令人称赞了，nginx 能超越它实属不易），说不定 nginx 不搞 path_info 有它的道理。 既然这样，php 编程时就应该考虑到 path_info 是不可靠的。以前我不太注意环境参数的获得性，如今审视了一下，除了 $_SERVER[‘PATH_INFO’]以外，$_SERVER[’PHP_SELF’] 和 $_SERVER[’SCRIPT_NAME’] 也是不可靠的。
$_SERVER[‘REQUEST_URI’] 和 $_SERVER[’SCRIPT_FILENAME’] 相对可靠。
我刚注意到 Godaddy 注册了一个 Tax ID EU826010755，开始对 perchase from the UK 征收 VAT，当前是15% （我在 2月份时仍是免 VAT的）。我不晓得这种财务变动是否伴随着基础设施的变动，可能这种变动已经发生。因为我注意到我的 Godaddy dedicated server 莫名其妙快了很多。
很多地方在解释 Linux 软连接时都喜欢把它比作 Windows 的快捷方式（当然它们是有实质区别的），而且在解释硬连接时找不到 Windows 下的对应事物。
但，我绝没有想到 Windows XP 也能建立如同 Linux 下的硬连接（真正意义上的硬连接，最简单的办法就是下载 Link Shell Extension 来用），据说 Vista 还能建软连接。是不是我的思维太激进了，总认为 Windows 要成为末日黄花？我看到在 Linux 下很普通的技术在 Windows 里也有就觉得很惊奇。
Formating date correctly is one of the troublesome work in all computer languages because remembering how to format is difficult.
In Microsoft Word, the formatting process is –
这可能是一个不可能实现的任务。
Actinic 的动态部分是 perl 写的，我不想触及 perl，陆陆续续做了很多 extensions，都是 php 写的。Actinic perl 有很多漏洞，其中一个就是会把我的 php 源码暴露。可能 Actinic 的目标用户都是 htmler，根本没指望 phper 会给它写 extensions（我也是没办法，早就不想干了）。我能做的，就是尽可能地调整 php 的代码方式，做到即使源码暴露了，也不包含机要信息。
我也不打算在 Actinic 浪费时间去研究怎么修改漏洞，只是最近把 apache module 研究了一遍，突然想重提这个历史遗留问题是否可以从 apache 方面给予弥补。漏洞的源头是 Actinic perl 读入我的 php script，当成 html 直接输出。如果能把 handler 再交给 php-cgi，那么 php tag 之间的内容就可以得到解析。
可是 apache 是以后缀推定 handler 的，那么某个后缀怎么可以有两个 cgi handlers?
I have tried all formats of PayPal Download History, and found “Comma Delimited – All Activity” is the most comprehensive one. I send it as an attachment for your review. My problem with this history is – every transaction has a different Transaction ID, it is not give me enough information to group related transactions. Basically, it is missing a column Parent Transation ID (or call it Related Transaction ID, whatever).
Some virtual terminal transactions have an update transaction, some don’t (depends on whether AVS matches). I can’t use any ID number to trace a update transaction back to its parent transaction ID, so I might calculate one transaction twice.
PayPal should improve its data download format. At least, it should provide an extra column of “Parent Transaction ID” (indicate its parent transaction if any), or “Unique Tranaction ID” (all related transactions have a unique transaction ID) for me to group related transactions.