我这个人是不是太爱唱反调了？呵呵，管他呢。 言归正传。大家先看一帖：http://www.phpchina.com/bbs/thread-30529-1-1.html 首先，小路这帖总结写得，实在是天花乱坠。很多没有参加的朋友看了一定口水直流：腾讯技术使用状况、PHP 的设计模式、PHP 框架的使用、大负载缓存……但是我认为这次聚会就技术而言是失败的。请注意，仅仅是技术而言！ 那就先说说腾讯技术使用状况这个话题吧。听完这个使用状况，对于我来说印象最深的就是腾讯 50 亿美金的市值。没错，是这个。至于其他的内容，不知道是美金太吸引我，还是介绍的时候轻描淡写一带而过，反正我没看到腾讯在 web 应用整体技术架构上的闪光点。反而，在一些细节技术上用得非常粗枝大叶。比如拥有众多 C 程序员的腾讯在分流服务器同步上使用的是 shell 脚本实在令我费解；而在 mysql 本身提供了memory table 的前提下，又用 C 编写了一个带有 SQL 查询功能的 cache。当然，架构的细节可能由于一些原因，不能让大家一窥，但是就透漏出来的信息，无法体现腾讯的技术亮点。
Monthly Archives: July 2007
为提升便利性，为 ninny Project 添加两个脚本工具
工具存放地址：svn://www.i-fang.com/IfangSites/trunk/app/bin 说明：这些工具是为快速开发编写的，请不要尝试在部署的时候使用。因为，多数服务器无法使用 CLI 方式执行 PHP 脚本。而这些工具只能执行于 CLI 模式下。 collectResouces.php —— 资源收集工具 我一直为 ACL 中资源的管理而烦恼，所以编写了这个工具。对于通用性资源（module、controller、action）进行采集，并按照顺序插入数据库中的资源表。 使用方法：php collectResouces.php createModule.php —— 模块、控制器、动作自动创建工具 其实编写 Controller Action 和 View Script 的第一步工作都是一样的。创建目录，创建文件，添加固定的内容……对于我来说，很烦。所以编写了这个脚本可以通过简单的 Yes/No 方式自动创建必要的目录、文件、代码框架。 使用方法：php createModule.php
基于 Zend Framework 的整合快速开发结构
在思考现有项目代码重构的过程中的附带产品。主要是基于 Zend Framework 并对其中一些内容进行扩展、整合。放弃部分灵活性，同时提高耦合度为代价，换取开发速度的提升。 我准备将这个项目的代号命名为“ninny”。 项目SVN ： svn://www.i-fang.com/IfangSites 项目页面：http://blog.xxiyy.com/?page_id=21 欢迎拍砖。 现有 E-R 图，权限控制部分
php 5 中使用get成员方法返回对象可能存在的问题。
"错误的类设计可能会改变本不应该改变的成员属性。"这个问题是在看 Java 的时候书中提到的。PHP5 默认传递的也是引用，那么可能也存在这个问题。于是跳下床来，做了个试验。果然…… 先看一段代码： <?php /** * privateClass * * 一个私有的类，在 publicClass 中使用 */ class privateClass { /** * name * * 保存一个名字 * * @var string * @access protected */ protected $name = ”; /** * __construct * * 构造函数 * * @param string $name * @access public * @return void */ public function __construct($name) { $this->setName($name); } /** * getName * * 获得名字 * * @access public * @return string */ public function getName() { return $this->name; } /** * setName * * 设置名字 * * @param string $name * @access public * @return void …
就之前性能测试反馈的一些补充
我说过对于FXXX 不在公开场所将其同 Zend Framework 比较的这样的话。所以我在这里做一些补充说明，一些是关于技术的，一些是关于技术人员应有的技术涵养的。 在收到性能测试的反馈之后，我特别进行了测试： 在 include(‘FXXX.php’) 之前定义： define(‘NO_LEGACY_FXXXPHP’, true); 则 FxxxPHP 只会载入两个文件：FXXX.php （核心）和 Config/DEBUG_MODE_CONFIG.php（默认的设置文件，用于调试模式）。而不会再载入 Compatibility.php 文件。此时，开发者按照 FxxxPHP 1.0.70 的规范编写应用程序即可。而 Compatibility.php 是为了方便 FxxxPHP 1.0.60 应用程序升级而设置的。 于是，我将这个开关加到之前的测试之上。很遗憾，在50次测试中，只有两次 FXXX 比 Zend Framework 快。 据说，在 L 兄的测试中通过修改了两行多余的代码，使得 FXXX 的执行快过了 Zend Framework。我没有办法测试，因为他并没有给出这个修改方法。不过我想也有可能的，因为框架本身在 loadClass 上的工作几乎完全相同。那么通过优化是完全可以得到相同的效能。
关于 Zend Framework 和国产 FXXX 在类加载性能上的测试
之前，FXXX 的主要开发者 L 兄曾经在 phpchina 上同我做过一些讨论。当然讨论的结果似乎不能令人满意。FXXX 对于我一直所诟病的数据库支持对于 L 兄来说似乎不是什么大的问题。而 Zend Framework 对于他来说似乎也是一直拥有效率黑洞，以及大而不精等诸多糟粕。Zend Framework 即将成为 PEAR2 是 L 兄一个比较精辟的形容。 项目中最初推翻 FXXX 转而使用 Zend Framework 主要是由于 Orcale 的支持问题。但是这个问题似乎是 FXXX 的软肋，不能碰，一碰就招致狂风暴雨般的质问。当然，质问的内容不是框架的数据库支持。而是触碰这个软肋的人的技术水平问题。而 Zend Framework 的性能黑洞，也让我带着意思疑虑。Zend Framework 的性能是否真的不可调和，这个框架是否真的又臃肿，又庞大？带着这个问题，我做了以下试验： 试验内容：为了检测 Zend Framework 的性能到底如何，我必须选择一个参照对象。很遗憾，优秀的 FXXX 被选中了。因为这个性能的疑虑正是 L 兄带给我的，所以………….解铃还需系铃人。 那么对两个框架所有的部分都进行测试，似乎不太可能。这绝对是超出我能力范围的。那么我选择了 Loader 作为测试的内容。两个框架都有各自的加载类的方法。而这个方法又是在所有使用框架的开发中需要使用的。 Zend_Loader::loadClass() vs FXXX::loadClass() 我首先在Doc Root 目录中创建了 Zend 和 FXXX 目录，用于存放两个框架必要的文件。既然是测试 Loader …