我有两台机子处于同一个内网，都有独立外网 IP。A 机用 http://ip_address/file 访问 B 机，如果 ip_address 为内网 IP，下载速度接近硬盘的读写速度极限；如果 ip_address 为外网 IP，下载速度为 2MByte/s，远低于内网速度，但又远高于 internet 速度（我用的是 2Mb 下行、0.5Mb 上行的 ADSL）。
想来想去，我只好做以下解释：ip_address 为外网 IP 时，数据流经过 router，但不经过 internet，小小的 router 数据处理能力有限，每秒只能中转 2MB 的数据。这是个 ADSL2+ router，设计能力就是为了应付 24 Mb 二代ADSL，所以能处理 2MB/s 的数据就达到了它的设计要求。
实测了一下，在已做了一些 Magento 速度优化措施以后，如 php opcode，memcache，mysql query cache，再启用 Magento 编译，速度并未提高，request per second 反而从 11 降为 8。
今天在安装 Virtualmin for Webmin 时碰到一个问题：启用 Postfix 时出错，出错信息为：
A problem was found with your Postfix virtual maps : No map sources were found in the Postfix configuration
解决方法是： edit the /etc/postfix/main.cf file and add:
virtual_alias_maps = hash:/etc/postfix/virtual
vtigercrm 早期版本安装总不顺利，最近下了 5.1.0 版，希望看到它有改进，但还是失望。
原因是我在安装时设定的密码含有非字母数字字符，vtigercrm 也没说这样不可以，还告诉我安装成功。可我总是登录不了，一时没想到是特殊字符的原因，以为是我输入错误或其他原因，于是拆了重装了好几次，均无法登录。
用了密码重置为 admin/admin 的办法，终于得以登录：
update vtiger_users set user_hash=’21232f297a57a5a743894a0e4a801fc3′, user_password=’adpexzg3FUZAk’,confirm_password=’adoY/6Mlw8kqg’,crypt_type=” where user_name=’admin’;
然后尝试着修改密码成我想要的密码，就算含有对 vtigercrm 非法的字符，vtigercrm 也没有阻止我修改，只是不让我登录，很不友好，我不喜欢。
Orange 通知我，可以用 callthru.co.uk 提供的 07978 620 000 接驳号码打免费国际电话了，消耗的只是合同通话时间。
得知这个消息，我倒没有太大激动，因为用其他公司 voip 的接驳号码打国际电话，也花不了几镑钱。Orange 使用成本低廉的 voip 为用户提供增值服务，我欣赏，但说心里话，这值增得不高啊。
在中国发票是由税务机关控制的，所以在中国人眼里，发票就是正规收条。无论先收货后付钱还是先付钱后收货，发票始终是发票。
西方的税务制度完全不同，税务机关不印发票，于是各公司的发票五花八门，但都算是正规发票。在西方人眼里，如果收到一张 invoice，那意味着有人在向他催钱；如果付了钱，那么应该有一张 receipt。我以前不懂其中奥妙，别人付过钱，我对他说：“We’ll send you an invoice.”
“我们会寄发票给你”？这话中国人听了觉得很正常，西方人听了，肯定觉得我拎不灵清，怎么付过钱了还在向他讨钱！
简言之，invoice 就是 proforma / proforma invoice，使用 proforma 一词只是为了加重语气，或者为了避免二义；receipt 不可与 invoice 等同使用。
First I want to declare – I love Magento very much!
但再完美的东西也是有缺陷的。正是因为 Magento 接近完美，所以改正它缺陷的愿望也强烈些。Magento website – store – storeview 3-tier 的模型逻辑分明，可是 Magento 在解释模型时用词不一致，造成最终用户和开发者如果是同一人的话思维混乱：
最终用户：website – store – storeview
These terms are used in documentation, and designer’s guide.
开发者：website – group – store
These terms are used in php code, and database table/field names.
这还是小毛病，关键是根据访问域名（或别的条件）加载不同的 website, store, storeview 时，我能看到的所有的指导都是叫我们修改 index.php，用一个条件选择 Mage:run(‘code’) 取代 Mage:run()。这样每次升级 Magento 都要特殊照顾一下 index.php，不符合 Magento 自己提倡的安全升级的原则。
其实如果是根据 base url 决定加载不同的 website, store, storeview，database 里已有对应的资料，就不能让 Magento 自己去选择加载，何必要用 php 再写一遍？因为 Magento overwrite 规则在 index.php 和 Mage.php 以后生效，所以我不欣赏修改 index.php 和 Mage.php 任何一部分。看来看去，只有 Mage_Core_Model_App 才是切入点，要写一个 Company_Core_Model_App 才能让 Magento 自动加载不同的 website, store, storeview。
很久以前做 Magento theme，直接把 default theme 所在目录复制到另一个目录。后来才知道定制 theme 不是这么干的，正确的做法是新建一个目录，要改什么文件就拷贝什么文件过来修改。这样既能个性化，又能向后兼容（如果修改部分跟新版本的 default 不冲突的话）。
Magento 在我做完 theme 后的某个版本开始支持 flat category 和 flat product，我一直无法垂涎这个功能，但一启用页面就是空白。知道今天才定下心来修改我的 theme 下的文件，把我没修改过的文件都删了。其实修改过的文件不多，十个左右，然后比较了新老文件（我修改的文件和对应的新版 default 文件）的差异，添加了一些 default theme 新增的语句，终于可以启用 flat category 和 flat product 啦。
因为产品不多，只有 200 个，感觉快了 3－5%，request per second 从 11 以下跃成 11 以上，Pingdom 测试也得到一个创记录的 2.23 秒（其中 index.php 的完成时间 0.6 秒，但 Pingdom 多次测试结果之间变化较大，大概跟 Pingdom 服务器当时状态有很大关系）。虽然没有体会到 Magento 声称在 2,000 个产品时能有 40% 的速度提升，我还是很高兴。
顺便我把 Magento 从 1.3.2.1 升级成 1.3.2.3，先用的是 magento connect 升级（以前有过一次 magento connect 升级失败的经历，这次想 give magento connect another try，考验一下它）。升级过程没有提示有错误，升级后前台也正常，可后台 system -> configure -> catalog -> frontend -> Use Flat Catalog Category / Use Flat Catalog Product 消失了， system -> configure -> admin 也不见了。只好 ssh tar 解压源文件全部覆盖了 Magento 的安装文件，终于一切回归正常。
Magento 的 default, modern, blank 等 templates 都带有一个文件 top.links.phtml (在 template/page/html)，第一眼看上去都会认为它是页面右上角 My Account, My Wishlist, My Cart, Checkout, Log In 的模板，但其实 top links 和 footer links 用的是同一个模板，即 template/page/template/link.phtml。
没有任何地方引用到 top.links.phtml，删了它一点事也没有；如果加载它，反而会出错。我猜 Magento core developers 原想把 top links 和 footer links 做成不同的模板，后来合并了模板，忘了删除一个废弃的文件？
我多次把 Magento 从一个服务器移动到另一个服务器，一直认为 Magento 不在意安装路径的改变，因为 Magento 总是在运行时检测安装位置（对比 WordPress 把 server absolute path 保存在数据库里，而且每个上传的文件都要保存一遍，不可取）。但今天我发现我错了：Magento downloader 仍保存有部分 server path 的信息，迁移 Magento 到新服务器后，Magento connect 不能正常工作。
有人提供了以下方法查找替换 downloader 目录下所有文件里的 OLD_PATH 成 NEW_PATH：
//shows all files with OLD_PATH element
find . -type f -exec grep -q "OLD_PATH" '{}' \; -print
//Replaces OLD_PATH string in all occurrences in every file to NEW_PATH
find . -type f -print | xargs sed -i -e ’s/OLD_PATH/NEW_PATH/g’
我试了试，查找替换是成功的，但 magento connect 还是不能工作，还是把 downloader 删了重装一遍来得干脆利落。