十/100
jQuery, working with PHP
5年前，我刚刚学习PHP这们编程语言的时候，我就放弃了学习很多前端技术，比如javascript和css。总是把所有精力放在服务器端的配置，开发和数据库的设计以及优化上。五年时间过去后，唯一的收获是对服务器端技术比较熟悉，但是开发出来的应用总是感觉缺少点什么。再后来发现了前端技术的重要性，因为前端技术的可优化余地要远远大于后端。于是恶补了一大堆js和css的优化和浏览器的工作行为理论。但越来越发觉自己做出来的应用“难以使用”了，我相信很多服务端技术开发的朋友跟我有同样的感觉。
首先，由于我们缺乏对javascript的熟练编写，导致一个应用很多时候都是借助服务器端完成（以下都以PHP为例），也就是说用户的浏览器只是在GET和POST数据，然后渲染HTML，很少用客户端来进行计算和交互，最多只是用来检测下表单的合法性。记得四年前开发一个CMS的时候，用javascript写了大量的代码，至今想起来犹如梦魇。那时对javascript很不了解，用PHP的思维去使用它，造成代码冗长，难以维护，加上自己调试能力不好，每次做bug修复的时候都想告别这个行业。08年初，在使用Drupal这个CMS的时候，意外看到了jQuery这个框架，是内置在Drupal中的，默认自动加载。为了编写好很多ajax应用，啃了几天jquery cookbook，算是入门了，后来也闲置了。最多就是写一些简单的ajax应用和前台效果。前几天看了一本书《jQuery with PHP》，09年10月份出版的，面向的主要读者就是做服务端开发，对前端知识比较少了解的人。200多页比较精简，语言通俗易懂，看完后收获颇多，从书中摘取一些比较有意思的东西分享给大家。（附上个人翻译，有误的地方欢迎拍转）我想这本书是对一个PHP工程师来说，平衡前后端能力，提高产品的用户体验，节省网络带宽，提高应用性能的重要一课。
It would be silly if a 3D screen was generated on the server and was sent to the client 24 times per second. And it would be awkward if you tried to do something like walk through a wall, and had to wait for the server to decide if it was allowed or not.
（这里用网游来比喻前端和后端的关系，很多程序员都玩网游吧！）
如果3D效果的显示数据是在服务端生成后以每秒24次的频率发送给客户端，可想这种设计有多傻。同样，如果你试着做一些很常见的操作，比如准备穿越一道墙，如果这个时候还要等待服务器来判断是否允许的话同样很傻，客户端做这个事情是最合适的。
However, in a pure PHP environment, that’s exactly what has been happening—the server generates absolutely everything that the client displays. If an element needs to be removed from a table, for example, then the server needs to be told, so that it can give the client the new view. If you try to do something illegal, such as submit a blank form where an email address is required, then pure PHP applications will let you do that, wasting time and server resources.
然而，在单独的PHP环境中，服务端产生几乎所有客户端要显示的东西。比如要从一个HTML表格中删除一个元素，必须通知服务器，这样服务端才能生成新的页面发送给客户端。如果你做了一些非法操作，比如没有填写重要的邮件地址就提交了一个空的表单，只有提交后PHP才能知道，这样大大浪费了时间和宝贵的服务器资源。
However, using JavaScript, and especially using Ajax, the client side is no longer a ”dumb terminal” for the server. We can write applications fully on the client side, if we wish, using the server purely as a database. This book will demonstrate ways to work towards that.
十/102
CakePHP Application Development
花了三天时间看完了《CakePHP Application Development》这本PDF文档，感叹作者的耐心，何奇的淡定。且不说我这个用了PHP做应用5年的人，就算是一个PHP不怎么了解的人估计都能看懂。这本书从头到尾都在案例之后进行分析，我觉得好处在于对初学者来说在cakephp这个框架能打好基础，对cakephp的个方面了解比较透彻。虽然从头到尾300多页感觉如果精简的话可能只有100多页，但是我不认为多余的是废话。只有对技术比较刨根问底的人才能把一门技术写的请清楚楚，让看客们也请清楚楚，明明白白。比起其他一些作者，写出来的东西都是一律而过来得更为实在。
cakephp是基于MVC这个模式来组织代码的，所以此书最重要的三章应该就是分别介绍controller，model和view的三章。早就听说cakephp是ror的php版本，虽然说法有些夸张，但是在cake里面还是能看到很多ror的思想和影子。很多人也说cake的Model实现方式过为复杂，我想只是使用群体不一样，具体的项目具体对待。
这次是因为一个中型项目而让我对cakephp产生要了解的想法。因为虽然php的framework很多，但是不像java阵营那样，php相关的框架大都是毁誉参半的，而且个别流行的框架也没有强大的社区支持。从众多的php框架中我选择了国产的thinkphp，相当于官方的zend framework以及轻量级的codeigiter，最后就是本文主要介绍的cakephp。选择的过程是个纠结的过程，因为框架的选择角度太多了，但从代码风格上来说，我更趋向于cake的代码。仔细研究了下，发现cake做的很人性化，这里人性化的意思是作者很像是个做产品的人，因为从很多地方都体现出了cake的方便和人性化。比如scaffold这个基本功能，在codeigiter里面也有，cake里面只需要在controller里面声明一个scaffold属性就行了，相当简单。
大家都知道，较高的便利性下面都隐藏着大量的命名约定。因为你只有遵守了框架作者的约定和设计思想，你才会得到很大的便利。因为作者在设计的时候，如果考虑使用者各种各样的习惯，设计出来的东西谁都用着不舒服了，只有使用者遵循一定的规则，框架就能带来强大的生产力，这也就是cake的脚本可以跑起来的前提条件。cake拥有一个小型的“shell”，叫做bake，ROR和Djangle都有类似的支持。只要我们在controller，model和views以及数据库设计的时候遵循了cake的命名约定，那么这一些都可以用bake来帮你处理。
我用cakephp建立了一个简单的定餐应用，发现确实像口号中所说那样：rapid development。大概一个下午，就做出了一个成熟的定餐系统应该有的所有功能。这样我就不用羡慕很多java开发者可以使用成熟的框架了，没办法自己对java也挺了解的，为什么就没法在实际应用中应用呢？总觉得太重。
搜索cakephp的时候，在网上看到一些中文资料，但质量都不是很好，强烈建议对cakephp有兴趣的朋友看看这本书，从头到尾没有一个晦涩的单词，通俗易懂。而且后面几章作者通过一个实例小应用配合cake的一些特性进行了说明，这写特性有分页，ajax，认证机制，cookie，session，rss订阅。在这写应用中，cake都显得极为方便。正如那句话：a piece of cake。
本书是面向cakephp新手的书，看完后我觉得还需要对官方文档详细阅读后才能达到用cakephp来开发复杂应用的程度。因为用户群不同，这本书只是介绍了cake的一些基础理论，而了解了这写，使用者可以在官方文档中自助式查询需要的东西。
七/095
什么是LLMP
在网站架构设计中，大家一定对 LAMP (Linux Apache Mysql Php) 不陌生。
LAMP确实是一个非常优秀的架构，秉承着自由，开放，高效，易用的设计理念。
但是，本文不打算探讨LAMP，网上有很多介绍LAMP的资料。
这里，想给大家介绍另一个在LAMP上衍生出来的，以提升性能为主要目的的开源网站架构。
1, 选择高性能 OS
首先，不难理解，任何一个server最底层的支撑还是OS，而OS的选择，主要包括 Unix, Windows server, Linux, BSD等等。
其中，开源的OS，有Linux, BSD及部分unix。从目前使用情况来看，linux还是网站首选OS之一。
但是，Linux由于其自由的特点，也给选择产生了一些不便 – 发行版太多。
现有的主流版本包括 red hat(RHEL), ubuntu, 红旗, opensuse, debian等。
其中，每一个发行版都有自己的特色，比如RHEL的稳定，ubuntu的易用，红旗的中文支持很棒等。
但要以性能为主，又兼顾稳定，易用性，以上都不是最佳选择。
这里推荐一个发行版，它是一个极限性能，加高度可定制，优化的 Linux – gentoo。
gentoo的性能优化是从kernel源码编译就开始入手了，通过选择不同的源码包，可以适应于不同的应用场景。
(不同内核介绍: http://imkenwu.javaeye.com/blog/168906 )
举个经典的例子：国内，douban.com 在定制优化过的 gentoo 上跑的web服务器最高一天支撑了 2500 万pv。
http://www.dbanotes.net/arch/douban_web_server.html
这种流量，哪怕是提供纯静态的内容，也是很恐怖的。
而支持这种大流量的，除了server本身，最关键的就是高度精简的OS了。
所以，综上所述，高性能网站推荐使用可优化，定制的 gentoo 作为载体。
2, 选择高性能 web server
Apache是 LAMP 架构最核心的 web server， 开源，模块丰富，功能强大，稳定是它的绝对优势。
在美国前100个网站中，有49%的使用apache。可见其影响力。
但是，有利有弊，apache的致命缺陷，就是多于臃肿，强大的功能，一定会带来性能上的损耗。
面对这种情形，在市场上，有一支异军突起，那就是更轻量级的 web server – lighty(lighttpd)。
官方为它定义的口号是 fly light。
它具有非常低的内存开销，cpu占用率低，效能好，以及丰富的模块支持等特点。
这让他在短时间内占据了14%以上的市场份额。并且有越来越多的人开始选择使用lighty作为前端 web server。
到这里为之，其实高性能 web server 非 lighty 莫属。但更棒的是，依靠 gentoo 的高度定制化，我们还可以
进一步提升 lighty 的性能潜力-那就是定制 lighty。
3，选择高性能 database
数据库是任何网站走动态化内容展现及业务数据存储的保障。
市面上的开源数据库主要有 mysql , postgresql , berkeley db, sqlite 等。
其中，对比一下，
mysql ： 多线程，多处理器，高性能，5.0以上支持事务，丰富数据类型和sql语法，跨平台。
postgresql ： 面向对象，集成web，支持事务，使用进程，速度略慢于mysql.
berkeley db ： 嵌入式，数据操作通过接口完成，跨语言。
sqlite ： 与php集成，支持ACID特性，支持大并发量，库锁。
从上面的对比中，不难看出，mysql 应该是性能，稳定性与功能性的综合之选。
4，选择高性能 script language
能与 lighty 结合的脚本语言，主要有 ruby, php, python, perl。方式主要是通过 fast-cgi 来访问。
只从性能角度对比几种语言:
不难看出，python 是此次测试中，性能最好的脚本语言。
动态处理方面有绝对优势。对比 php ， 前者，可以更快的渲染输出内容，并由经lighty， 高速flush缓存到浏览器。
值得一提的是， douban.com 也是使用 python 作为应用服务器。
总结一下，什么是 LLMP？
LLMP 是 Linux Lighty Mysql Python 的组合，作为一种高性能的网站架构设计存在。
什么是高性能的LLMP？
LLMP并不意味着高性能，只是比其他架构，更有性能的提升潜力。高性能的LLMP，需要从系统，程序，硬件各个层面上协同进行的。
六/095
PHPEclipse：A User Guide
今天看到一本好书：《PHPEclipse：A User Guide》，着重对phpeclipse这个插件进行介绍，此类资料中这个算是比较详细，三种平台都有介绍（Linux，Mac，Windows）。对Quantum DB Plug-In也有介绍，唯一“不好”的地方就是：晦涩的单词太多，不知道我辈的英文水平不是很好啊。。借助翻译工具还是硬着头皮看下来了，200多页，其中还有部分插图，花费3个小时，还算值得。
推荐给想用eclipse做php开发的朋友，熟练后就不必使用收费的zend studio了。
一/092
PHP Architect’s Guide to PHP Security [3]
今天继续翻译PHP Architect’s Guide to PHP Security这本书的第三章《SQL注入》。由于第二章XSS有专门的书籍介绍，以后会专门翻译，所以暂时跳过XSS，先对SQL Injection进行介绍。
SQL注入是另一种常见的漏洞（针对XSS来说），是由于对输入数据过滤不严导致的。它不像XSS是直接针对站点的用户，而是直接破坏站点本身，特别是数据库。SQL注入的目的是插入任意数据，常常是插入一条被数据库执行的SQL语句。这些潜伏的被插入语句常常执行很多操作，从获取数据到更改或删除数据库信息。
// supposed input
$name = “ilia’; DELETE FROM users;”;
mysql_query(“SELECT * FROM users WHERE name=’{$name}’”);
这段功能本来是想从user表中获取匹配name字段的数据，一般情况下，name变量是一些字母数字和空白字符的组合，比如字符串“ilia”，但如果我们附加了查询语句，这条注入的查询语句将会删除users表中的所有记录。（幸运的是，mysql的mysql_query函数不允许堆查询，在一次调用中不允许执行多次查询，但是SQLite和postgresql扩展是可以的。
PHP的自动转义机制GPC提供了一些基本保护，如果启用了magic_quotes_gpc，将会对单引，双引等一些字符进行转义（在前面加反斜线）。但是magic quotes不包括所有需要转义的字符，并且这个特性不总是开启的。所以你需要自己用代码来阻止SQL注入。
php的很多数据库扩展有自己专门的转义机制，例如Mysql扩展的mysql_real_escape_string()函数。
if (get_magic_quotes_gpc()) {
$name = stripslashes($name);
}
$name = mysql_real_escape_string($name);
mysql_query(“SELECT * FROM users WHERE name=’{$name}’”);
在调用数据库扩展的转义机制之前，首先要对magic quotes的状态进行检查，如果magic guotes启用了，则要去掉它可能添加的反斜线，以免输入数据被转义2次。
待续。。。有点累了。