-
关于PHP性能优化的演讲: http://talks.php.net/show/ezkey06
-
(P.S. 找了许久，终于找到了这副画。 Willem de Kooning, Door to the River)
-
如果精神状态不好，可以看几个笑话，放松一下。
(1)
有两个神经病患者，从病院里逃出来。
两人跑啊跑，爬到一棵树上。
其中一个人从树上跳下来，滚啊滚的。
然后抬起头对上面的人说：喂……你怎么还不下来啊……？
上面的那个人回答他：不……行……啊……
我还没有熟……(2)
神经病院里，有两位在交谈，
“我的小说怎么样？”
“不错，就是出场人数太多。”
此时，护士冲他们嚷到：“喂，你们俩快把电话簿放回去！”(3)
一个病人在写东西，护士小姐很好奇，就问：你在写什么？
病人回答：我在给我自己写信.
护士问：写的什么内容 ?
病人说：不知道啊，我还没收到。
-
"jQuery UI is a set of themable widgets and interactions, built on top of the jQuery JavaScript Library, that you can use to build highly interactive web applications."
请访问: http://ui.jquery.com/home
-
" FTPHP 全文检索系统的核心功能是实现对中小型规模数据量站点信息的统一全文检索。全文检索是指在“海量”信息中快速、准确根据关键词句返回用户所需的信息。
FTPHP 不仅追求高准确率同时追求超高查全率的手段，内部采用自主研发的 SCWS 复方词法分析系统。搜索结果可以按字段值或信息相关性排序，多字段联合搜索，基于字段的层级命中数量估算，支持字段数值的区间搜索，支持大量的布尔搜索语法规则。
FTPHP 它还是一个可完全定制的全文检索解决方案套件，底层采用 C、C++ 编写，前台和接口（API）调用采用 PHP 编写，运行在 Linux/BSD 等 Unix 类操作系统中。"
参见FTPHP项目的主页： http://www.ftphp.com/
其实我一直关注中小型Web应用的全文检索解决方案，车东的WebLucene 是在Java环境中的一种方案，另外，Zend_Lucene用PHP实现了和Lucene类似的功能，但是显然在处理效率上，纯粹PHP的实现有很大的局限性。
FTPHP让我很有启发的一点是，它作为PHP扩展使用C语言开发，这对于效率是种保证，同时，由于专注于解决搜索领域的问题，在底层数据存储上可以做更多的专门优化。
另外，还里有 一个小讨论，大家不妨看看。
-
-
我感觉搞软件开发有两个根本性的困难，而目前似乎没有什么方法可以克服这些困难。
一、 时间估计
给定一系列需求，估计所需的开发时间和成本是困难的。因为一方面，客户不懂自己真正的需求是什么。另一方面，客户的需求的确不停变化。
二、 完成计划
即便可以（根据以往的项目经验）估计出开发时间和成本，完成一个计划仍然是困难的。因为现实总在不停变化，而计划则无法适应这种变化。你的开发人员会生病，会士气低落，开发过程中，客户会有各种不满意的地方需要重新修改。
至于敏捷软件开发(ASD)的原则和方法，也不过是“狡猾”的绕过了这些难题，并没有解决这些难题，而在更多的情况下， ASD的原则和实践并不适用。举一个很现实的例子：软件外包产业。
软件外包项目有几个特点：
1. 有固定的时间限制。
2. 参与双方大都属于不同的国家地区。
3. 大多数情况下，大家并不签订合同。如果在执行过程中有任何不满的地方，可以随时停止合作。
那么在这个方面，ASD的原则就有很多局限性。
1. ASD提倡缩短交付周期，但很明显，总的开发时间是固定的，分段交付也没有意义。因为假如时间限制是两个月，而需求却很多。在总体时间上已经很难完成，分段交付又怎么完成呢？ 除非双方约定，只要实现客户方的需求就可以，而不限制总体时间。这显然很难做到。
2. ASD提倡客户方参与到软件开发中来，和开发方一起工作。但软件外包项目都是远程工作，这一点就很难保证。即使通过视频交流的方式，效果也不好。软件外包项目的性质更像是: 甲方提出项目的预算和时间限制，然后乙方在规定的预算和时间要求下完成项目，并且在这过程中，甲方应该尽可能少的参与乙方的工作（我们把项目外包出去，不就是为了节省精力，专注于自己的核心竞争力吗？）
当然，我对ASD的理解还很浅显，也许还没有掌握ASD的精髓，不过，在软件外包领域，的确存在很多根本性的困难.
如何解决这些困难？ 天知道。 只能自己思考答案。
P.S. 我比较喜欢 Feature Driven Development
-
安全问题是每个开发人员必须重视的问题，而且应该放在性能问题之前考虑。如果你的程序连SQL注入攻击都防止不了，那运行的再快也没意义。
最近一直在学习和PHP安全有关的技术，因为我想给Aeolus设计一套安全而方便的工具包，以便从最大程度上防止SQL注入攻击和XSS攻击（以及其他潜在的安全隐患）。
一个简单有效的安全措施是：过滤用户的输入，转义系统的输出。
在输入过滤方面，HTMLPurifier算是很不错了（目前我已经集成到Aeolus中)，但在输出方面，似乎没什么好的解决方案？ PEAR有个HTML_Safe 包，不知道效果如何（不过，我基本上不想再用PEAR的软件包了）。
有个叫 PHP Security Consortium 的网站，上面有很多常见的安全知识，如果你还没有读过，建议读一下上面的文章，对提高PHP程序的安全性很有帮助。
另外说句题外话，我发现做计划真是不靠谱的事情，敏捷开发的原则至少有一条是正确的： 不要做任何超过3个月的计划。现实总是变得太快，重要的是迅速响应变化，而不是遵循一个已经不切实际的计划。
从理论上说，任何计划都是在现实发生之前做出的，而我们对未来是如此无知，以至于任何计划都是我们自己的天真想象。
-
-
“四月是最残酷的季节”，我们的纪念是如此苍白无力。
下面是王小波《未来世界》的一段，摘录如下：
“ 后来不等了，从餐馆里出来。他们俩忽然往一起一站，小姚阿姨就对我妈说：大姐，我们今天结婚。我妈说：岂有此理！怎么不早说？我们也该有所表示。我跟着说：对对，你们俩快算了。我舅舅拍拍我的脑袋，小姚阿姨和我妈说了几句没要紧的话，就和我舅舅钻进了出租车，先走了。我感到了失恋的痛苦，但是没人来安慰我。没人把我当一回事，想要有人拿我当回事，就得等待。“
柏杨先生最近去世了，而王小波先生已经去世十年有余。
”庭有琵琶树，吾妻死之年所手植也，今已亭亭如盖矣“，是为悲痛。
-
I've decided finally that Aeolus framework would only run on PHP 5.2.0 and above, since the world
really doesn't need yet another PHP 4 framework and everyone who love PHP should use PHP 5 only.
PHP 4 is dead , so let's move forward !
-
最近的工作是设计Aeolus的缓存系统，众所周知，目前有三种缓存方式：
1. 文件后端缓存： 使用Serialization技术，将数据持久化，并保存在文件系统中。
基于这种缓存方式的工具包有Zend_Cache_Core和PEAR::Cache_Lite，Zend_Cache对PHP的版本要求比较高（PHP version > 5.1.4)，不太现实。而PEAR::Cache_Lite的性能不太好，而且代码质量一般（最近读了Cache_Lite的代码，发现里面有一些垃圾函数，没有实用价值。)
2. 内存级缓存： 把数据直接保存在内存中。
目前据我所知，Memcached是比较好的，而且开源。
3. PECL::APC： 使用PHP 的APC扩展。
在PECL中有一个APC的扩展，性能不错，但默认安装的PHP并没有启用这个功能，需要自己添加。
这里 有一篇很有价值的参考文章，我就不多说了。
目前我的决定是：自己写一个简单快速的基于文件的缓存系统，至于APC和Memcached，如果你安装了他们，就不需要Aeolus Framework来提供支持了。
-
我发现的PHP单元测试工具包有 PHPUnit 和 SimpleTest 有这方面需求的同学可以看一下，我比较喜欢那个Simple Test，似乎PHPUnit有些庞大。
-
I'm Going To Scale My Foot Up Your Ass
很务实的一篇文章。
-
请看这里：http://www.ralentz.com/old/space/feynman-report.html
这是著名物理学家费曼写的报告，很受启发！
-
经过艰难的漫长的令人期待的又错误百出的系统升级，我的Xubuntu 8.04终于正常运行了，下面是一些截图，哈哈。。心情好啊！
-
UPDATE: Aeolus 将放弃对PHP 4的支持，理由是我的判断并不正确。
又一个棘手的问题，众所周知，目前PHP有两个主要版本——PHP 4 和 PHP 5，其中PHP 4的公告如下：
The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.
也就是，在2008年8月8日以后，PHP 4系列的开发（包括安全更新）都将停止，在这段时间，大家应该把PHP 4平台的程序转移到PHP 5版本上来，因为目前最新的PHP版本都是5.2.5了。。
但是，考虑到虚拟主机市场反应迟钝，对PHP 4的支持还是必要的（至少要支持PHP 4.2.0），当然，有些虚拟主机厂商会提供两种PHP版本供大家选择，但PHP 4的市场还是比较大的。由于PHP 4和 PHP 5的面向对象模型不同（PHP 4的模型比较简陋)，所以在PHP 4平台上开发的软件无法享受PHP 5平台的好处。但是完全在PHP 5平台上开发，也不太明智（据我所知，Zend Framework的最低版本要求是PHP 5.1.4。），因为这样你就天然的减少了用户的数量，所以版本问题还是比较麻烦的。
至于Aeolus，我只好开发两个版本，一个针对PHP 4平台，另外一个针对 PHP 5平台，其实我一直坚持认为，针对不同平台不同版本推出不同产品才是最经济的，当然，你可以把系统设计的不需要特别大的改动就可以部署到不同平台（如Linux，虽然针对x86 平台，但可以比较容易的部署到别的平台)。在2008年10月24号发布的 Aeolus 1.0.0将针对PHP 4.2.0及以上平台，
而针对PHP 5平台的Aeolus framework将称为 Aeolus Pro，对PHP的最低版本要求是PHP 5.2.0，Aeolus Pro 1.0.0 将在2009年4月24号发布。对于PHP的版本问题，就这样解决吧。 -
在Linux 的内核自述文件中，有一段对Linux的描述：
Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net.
It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,including true multitasking, virtual memory, shared libraries, demandloading, shared copy-on-write executables, proper memory management,and multistack networking including IPv4 and IPv6.
It is distributed under the GNU General Public License .
-
作为一个计算机技术的爱好者，也许你已经对Linux内核的原理及实现感兴趣了，那么在开始研究Linux内核时，第一步要做什么呢？
毫无疑问应该把Linux内核的源代码下载下来。你可以直接下载压缩包，但推荐使用版本控制系统获取Linux内核的源代码。
目前Linux内核使用 Git 来作版本控制，如果你使用的是Debian/Ubuntu Linux，那么可以简单的使用如下命令安装 Git ：
$ sudo aptitude install git
在装好了 Git 以后，第二步就是下载Linux Kernel的源代码：
$ git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
目前Linux kernel 2.6有500M之多，完全下载下来需要不少时间。下载完成后，你需要更新到最新版本的Linux kernel (2.6.XX系列)：
$ cd linux-2.6
$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
到了这一步，你就可以使用Git创建自己的branch，开始Linux kernel的探索之旅了。
-
"GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease."
如果你在用 Git 做版本控制的话，Github则非常适合你。
我打算从Google Code 转移到 Github 上面，因为使用 Subversion太不爽。
-
"Google Web Toolkit (GWT) makes it easier to write high-performance AJAX applications. You write your front end in the Java programming language and GWT compiles your source into highly optimized JavaScript."
不知道有多少人用过GWT，反正我要尝试一下了，因为看上去这个toolkt真的很不错！
你可以访问 这里 来学习如何使用GWT。
-
最近两周比较忙，所以对Aeolus的更新不多。目前我主要确定了Aeolus Kernel下面的组件，然后在接下来的两周里把SimpleCache部分完成。
既然坚持两周发布一次的计划，那么今天照例要发布一下Aeolus R81，你可以用下面的命令得到Aeolus R81的源代码：
svn co -r 81 http://aeolus.googlecode.com/svn/trunk aeolus
其实Aeolus的主体MVC部分已经完成，只需要进行进一步的优化和标准化，所以你可以在目前的基础上写几个测试程序了。如果你需要第三方的库（例如Zend Framework或CodeIgnitor)，可以把这些库文件放到 'vendor' 下面，然后就可以使用了。
接下来我会写一个具体的RoadMap，对整个发布过程做出尽可能详细的规划。
-
"Hadoop is a software platform that lets one easily write and run applications that process vast amounts of data."
恩，目前在分布式计算领域，Hadoop算是很不错的开源软件了。。它实现了Google的MapReduce 框架，而且还有一个对应的HDFS文件系统来存储数据。
现在我对分布式计算真的非常感兴趣，目前在学原理性的知识，研究Google发布的一些文档以及WikiPedia上面的资料。
感兴趣的同学可以看看 Hadoop 的项目主页，上面很多介绍。
我打算在接下来几天写点Hadoop的研究心得。。
-
"An Application Server written in PHP that serves PHP servet . PHPlet are similar to Java Servlet as they implements the init(), service(), destroy() methods. The lifecycle of PHPlet is the same of servlet."
PHPlet是用PHP写成的类似Java Servlet的应用程序服务器，这样的想法很好，但是PHPlet项目已经很久没有更新了。。目前我在找一款用PHP写成的HTTP服务器，发现可以从这个项目中把它的HTTP Server部分取出来作为独立的HTTP服务器使用。
另外，有一个名叫 nanoweb 的HTTP服务器也是全部用PHP写成，我目前也在读Nanoweb的源代码，不过似乎写的比较乱，不如PHPlet的代码清晰。
-
“This plugin is an inline content editor to allow editing rich HTML content on the fly. It's an alternative to WYMeditor with much less features. With a small file size less than26Kb total and only 18Kb of code and 7Kb packed, the main concept is to keep it simple, not all users need font coloring or create tables, just the basic. ”
项目主页：jwysiwyg
P.S. 这个东西实在方便，如果你在用jQuery的话。另外，很多人用TinyMCE，这个我不多说了。我不太喜欢，因为它的代码写的很乱。
-
在开源领域，有什么商业模式呢？我的一些简单的想法如下：
1。使用双重授权，类似MySQL的办法。
2。开发不同的版本，普通版本开源而且免费，高级版本不开源而且收费，例如Aptana。
3。软件产品开源而且免费，而技术支持和咨询收费。
4。对普通用户开源而且免费，而针对企业用户提供收费的特别定制版本。
基本上我想到的方法就是上面几个，欢迎大家补充。
-
推荐一篇文章： Q&A: Jonathan Schwartz on Sun's open-source business strategy
对我很有帮助。
-
easyMule是VeryCD基于eMule开发的开源P2P软件，他具有更好的用户界面和功能
这里是easyMule的项目主页： http://code.google.com/p/easymule。
希望懂C++而且热爱开源软件的同学可以参与easyMule的开发，或者编写文档，参与测试，提供反馈等。
-
今天讨论MVC，因为这是一个非常困扰我的问题。
首先我想说说自己在MVC问题上的最初体会，大概在2006年12月份时，Zend Framework 0.6刚刚发布 ，我跟着一份教程弄懂了ZF的MVC设计，同时写了点测试代码。记得那天我从晚上10点一直学到第二天凌晨3点，因为当时真的感到非常兴奋：如果你读过WordPress的代码，也许会同样为ZF的设计感到兴奋吧。
通过一条RewriteRule把所有请求重写到一个Front Controller，我感到基于ZF写程序真的非常舒服，而且写成的代码会非常干净，相比于WordPress混乱的代码结构，也许你不难体会那种干净整洁带来的兴奋吧。
关于Front Controller，Martin Flower这样描述：
“The Front Controller consolidates all request handling by channeling requests through a single handler object. This object can carry out common behavior, which can be modified at runtime with decorators. The handler then dispatches to command objects for behavior particular to a request.“
ZF在当时给我留下了强烈印象， 但后来随着对PHP的了解，特别是“PHP之父” Rasmus 的一篇文章(The no-framework PHP MVC framewok)，我又有了动摇。
在文中Rasmus说：
"Just make sure you avoid the temptation of creating a single monolithic controller. A web application by its very nature is a series of small discrete requests.
If you send all of your requests through a single controller on a single machine you have just defeated this very important architecture. Discreteness gives you scalability and modularity. You can break large problems up into a series of very small and modular solutions and you can deploy these across as many servers as you like. You need to tie them together to some extent most likely through some backend datastore, but keep them as separate as possible. This means you want your views and controllers very close to each other and you want to keep your controllers as small as possible. "好了，到现在我们有了相反的两种意见，并且都有道理，那么到最后我们该如何选择呢？
有一点（"A web application by its very nature is a series of small discrete requests.")Rasmus说的很对，HTTP请求的确是离散的，所以离散的处理他们似乎更加符合直觉和自然，而使用Front Controller这种设计模式，非常明显的破坏了这种离散本性。
OK，那为什么最终还是要使用Front Controller模式呢？ 下面是我经过思考后的一些理由：
1。Rasmus提倡离散性的理由，除了"Web的本性就是离散的"以外，还有一点：Discreteness gives you scalability and modularity. 对于这一点，我有两个反对理由：
a) 在scalability问题上，"Languages don't scale, Architecture Scale"，所以使用Front Controller对scalability并无损害。
b) 在modularity问题上，使用Front Controller貌似更加模块化。所以这两个理由不足以反对Front Controller这一个设计模式。2。Web的本性是离散的，但不一定非要用离散的方式来处理才算符合直觉。Martin有段话如下：
“In a complex Web site there are many similar things you need to do when handling a request. These things include security, internationalization, and providing particular views for certain users. If the input controller behavior is scattered across multiple objects, much of this behavior can end up duplicated. Also, it's difficult to change behavior at runtime.”
而使用Front Controller模式，你可以用一种统一的方法来处理HTTP Request，并且可以更加容易的处理错误信息（比如 404错误）。
上面是我近期思考的结果，然而，为了最大限度的提高一个PHP Framework的运行速度，我按照Rasmus所建议的，把controller设计的非常短小（大约每个实际的controller不会超过30行代码)，而且使用过程化的思想实现了MVC设计模式（同Zend Framework的实现不同，在Aeolus中，一个controller是一个函数，而不是一个类)。
另外，其实要实现Front Controller，并不一定非要依赖Apache的mod_rewrite，CodeIgnitor的设计就很好，可以在每个 URL 中加上一个index.php（比如类似 http://www.foo.com/index.php/bar/buzz的URL），这一点我在 以前一篇文章中 已经讨论过了，就不再多说了。
Kinch's Geeky
The Missing Hacker
