十/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的一些基础理论，而了解了这写，使用者可以在官方文档中自助式查询需要的东西。
五/102
《高性能网站建设进阶指南》书评
这本书比上一本《高性能网站建设指南》更加的深入，虽然目前我只读到第六章内容，但是我已经把该书的等级从”推荐“改为”力荐“。
目前看到的对几个经典问题的剖析：javascript单线程问题，脚本拆分节省下载负载问题，行内脚本和外部链接脚本的加载过程以及对组件下载和渲染的影响，内存使用对响应时间的影响（其中提到了GC机制，对后端开发人员也有很好的参考价值）。
本书中出现了好几个我一直膜拜的javascript的牛人，其中有jquery框架的创始人，有jsmin的作者（一个js的压缩工具）。结合本书的javascript章节，我相信对javascript的机制会有个更加深入的了解。正如上一本书中所说，70%的页面响应时间都花费在浏览器端，这部分的优化对高负载流量站点来说不容忽视，不管是架构师，还是前台或者后端开发人员本书都有很高的参考和研究价值。
注：本书中部分章节需要有程序设计的基础知识，比如多线程和内存管理。
今天终于看完了所有章节，个人感觉后半部分三个章节内容写得不错。1，javascript代码优化。此部分内容不仅仅局限于javascript代码，对别的语言也是一个参考，（除了作用域对性能影响），因为大部分讲的是程序控制流程对语言性能的影响。
2，Gzip压缩。这个章节很有趣，分析了15%的用户在http请求头中为什么没有gzip。并给出了一些解决方案，这个章节的特约作者在上一本书中对gzip压缩也做了详细的介绍。书中那个性能对比图比较重要。
3，图像优化。可能做后端程序的人对这个方面不是很了解，这个章节刚好对我是个补充。以前项目涉及到图片的压缩率，处理图片的cpu占用率和图片压缩算法，加上这个章节的介绍，就更完美了。
三/102
CodeIgniter 入门
终于花了1个半星期的时间看完了“CodeIgniter 1.7”这本书，300多页，不过内容还算丰富。从web开发的各个方面介绍了CodeIgniter这个PHP框架，章节的安排跟那本“Pro Drupal Development”类似。看完本书后，感觉codeigniter确实能弥补一些目前的PHP框架开发现状，目前来说基于PHP的CMS比较全，国外流行的有drupal，joomla，CMSMS等等，国内的就更数不胜数了。但提到framework，大家都想到zend framework，研究过一段时间这个框架，感觉过于庞大了，至于剩下的cakePHP，thinkPHP，国内的FleaPHP都没有涉及过，第一个接触的正式PHP框架（正式是针对drupal来说）就是CodeIgniter了。
使用drupal2年多，已经身心疲惫。总是感觉还不是那么的灵活，性能还不是那么的好，总想对它控制得更多，但我们能做的只有hook。不可否认，drupal在快速搭建一些中小型站点确实是不错的选择，模块很多，社区很活跃，但是如果用来开发一些大型的应用就显得力不从心了，比如我们开发一个万人活跃用户的SNS社区，一个多应用服务器架构的系统。drupal本身是面向过程的PHP通过HOOK机制组织起来的，这时我们就迫切需要一款MVC的面向对象设计的框架。codeigniter正是如此。
比较喜欢CI（codeigniter的简称）的一些设计理念，第一个就是从不强迫用户，CI为开发者提供了很多功能（helper，plugin，library等等），方便开发者，但它不强迫你使用这些功能，你完全可以自定义开发自己的功能模块，甚至可以很方便的集成第三方工具进来，不像drupal，你必须对drupal机制要很了解，才能做一些比较深入的工作。另外，CI的定制性很高，你可以参考CI的文档对其任意定制，足以迷惑用户是不是CI开发出来的站点。
网上有一个老外做的视频，20分钟用CI搭建一个blog系统，虽说有些夸张，但功能也太简陋了，不管是安全性还是UE都没有考虑太多，我做过一个测试，3-4个小时开发出来一套多用户blog系统是完全可行的。
此外，CI为我们提供了很多类库，涵盖的功能如下：
- 文件下载
- 邮件发送，可包含附件
- 表单
- FTP
- 分页
。。。
CodeIgniter，值得学习。
六/095
PHPEclipse：A User Guide
今天看到一本好书：《PHPEclipse：A User Guide》，着重对phpeclipse这个插件进行介绍，此类资料中这个算是比较详细，三种平台都有介绍（Linux，Mac，Windows）。对Quantum DB Plug-In也有介绍，唯一“不好”的地方就是：晦涩的单词太多，不知道我辈的英文水平不是很好啊。。借助翻译工具还是硬着头皮看下来了，200多页，其中还有部分插图，花费3个小时，还算值得。
推荐给想用eclipse做php开发的朋友，熟练后就不必使用收费的zend studio了。