十/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的一些基础理论，而了解了这写，使用者可以在官方文档中自助式查询需要的东西。
六/100
Apache Rewrite
Apache的rewrite的重写非常常用,现总结了一下.
Apache mod_rewrite规则重写的标志一览
R[=code](force redirect) 强制外部重定向
强制在替代字符串加上http://thishost[:thisport]/前缀重定向到外部的URL.如果code不指定，将用缺省的302 HTTP状态码。
F(force URL to be forbidden)禁用URL,返回403HTTP状态码。
G(force URL to be gone) 强制URL为GONE，返回410HTTP状态码。
P(force proxy) 强制使用代理转发。
L(last rule) 表明当前规则是最后一条规则，停止分析以后规则的重写。
N(next round) 重新从第一条规则开始运行重写过程。
C(chained with next rule) 与下一条规则关联
如果规则匹配则正常处理，该标志无效，如果不匹配，那么下面所有关联的规则都跳过。
T=MIME-type(force MIME type) 强制MIME类型
NS (used only if no internal sub-request) 只用于不是内部子请求
NC(no case) 不区分大小写
QSA(query string append) 追加请求字符串
NE(no URI escaping of output) 不在输出转义特殊字符
例如：RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE] 将能正确的将/foo/zoo转换成/bar?arg=P1=zed
PT(pass through to next handler) 传递给下一个处理
例如：
RewriteRule ^/abc(.*) /def$1 [PT] # 将会交给/def规则处理
Alias /def /ghi
S=num(skip next rule(s)) 跳过num条规则
E=VAR:VAL(set environment variable) 设置环境变量
使用mod_rewrite时常用的服务器变量：
HTTP headers:HTTP_USER_AGENT, HTTP_REFERER, HTTP_COOKIE, HTTP_HOST, HTTP_ACCEPT
connection & request: REMOTE_ADDR, QUERY_STRING
server internals: DOCUMENT_ROOT, SERVER_PORT, SERVER_PROTOCOL
system stuff: TIME_YEAR, TIME_MON, TIME_DAY
RewriteRule规则表达式的说明：
. 匹配任何单字符
[chars] 匹配字符串:chars
[^chars] 不匹配字符串:chars
text1|text2 可选择的字符串:text1或text2
? 匹配0到1个字符
* 匹配0到多个字符
+ 匹配1到多个字符
^ 字符串开始标志
$ 字符串结束标志
\n 转义符标志
反向引用 $N 用于 RewriteRule 中匹配的变量调用(0 <= N <= 9)
反向引用 %N 用于 RewriteCond 中最后一个匹配的变量调用(1 <= N <= 9)
RewriteCond适用的标志符
‘nocase|NC’ (no case)忽略大小
‘ornext|OR’ (or next condition)逻辑或，可以同时匹配多个RewriteCond条件
RewriteRule适用的标志符
‘redirect|R [=code]’ (force redirect)强迫重写为基于http开头的外部转向(注意URL的变化) 如：[R=301,L]
‘forbidden|F’ (force URL to be forbidden)重写为禁止访问
‘proxy|P’ (force proxy)重写为通过代理访问的http路径
‘last|L’ (last rule)最后的重写规则标志，如果匹配，不再执行以后的规则
‘next|N’ (next round)循环同一个规则，直到不能满足匹配
‘chain|C’ (chained with next rule)如果匹配该规则，则继续下面的有Chain标志的规则。
‘type|T=MIME-type’ (force MIME type)指定MIME类型
‘nosubreq|NS’ (used only if no internal sub-request)如果是内部子请求则跳过
‘nocase|NC’ (no case)忽略大小
‘qsappend|QSA’ (query string append)附加查询字符串
‘noescape|NE’ (no URI escaping of output)禁止URL中的字符自动转义成%[0-9]+的形式。
‘passthrough|PT’ (pass through to next handler)将重写结果运用于mod_alias
’skip|S=num’ (skip next rule(s))跳过下面几个规则
‘env|E=VAR:VAL’ (set environment variable)添加环境变量
实战
例子：
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^MSIE [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Opera [NC]
RewriteRule ^.* – [F,L] 这里”-”表示没有替换，浏览器为IE和Opera的访客将被禁止访问。
例子：
RewriteEngine On
RewriteBase /test
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ([^/]+)$ /test/$1.php
#for example: /test/admin => /test/admin.php
RewriteRule ([^/]+)\.html$ /test/$1.php [L]
#for example: /test/admin.html => /test/admin.php
限制目录只能显示图片
< IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !^.*\.(gif|jpg|jpeg|png|swf)$
RewriteRule .*$ – [F,L]
< /IfModule>
五/102
《高性能网站建设进阶指南》书评
这本书比上一本《高性能网站建设指南》更加的深入，虽然目前我只读到第六章内容，但是我已经把该书的等级从”推荐“改为”力荐“。
目前看到的对几个经典问题的剖析：javascript单线程问题，脚本拆分节省下载负载问题，行内脚本和外部链接脚本的加载过程以及对组件下载和渲染的影响，内存使用对响应时间的影响（其中提到了GC机制，对后端开发人员也有很好的参考价值）。
本书中出现了好几个我一直膜拜的javascript的牛人，其中有jquery框架的创始人，有jsmin的作者（一个js的压缩工具）。结合本书的javascript章节，我相信对javascript的机制会有个更加深入的了解。正如上一本书中所说，70%的页面响应时间都花费在浏览器端，这部分的优化对高负载流量站点来说不容忽视，不管是架构师，还是前台或者后端开发人员本书都有很高的参考和研究价值。
注：本书中部分章节需要有程序设计的基础知识，比如多线程和内存管理。
今天终于看完了所有章节，个人感觉后半部分三个章节内容写得不错。1，javascript代码优化。此部分内容不仅仅局限于javascript代码，对别的语言也是一个参考，（除了作用域对性能影响），因为大部分讲的是程序控制流程对语言性能的影响。
2，Gzip压缩。这个章节很有趣，分析了15%的用户在http请求头中为什么没有gzip。并给出了一些解决方案，这个章节的特约作者在上一本书中对gzip压缩也做了详细的介绍。书中那个性能对比图比较重要。
3，图像优化。可能做后端程序的人对这个方面不是很了解，这个章节刚好对我是个补充。以前项目涉及到图片的压缩率，处理图片的cpu占用率和图片压缩算法，加上这个章节的介绍，就更完美了。
五/105
Google的pac-man
经典的pac-man吃豆子小游戏大家小时候都玩过吧，今天是这款游戏面世的30周年纪念日，google的搜索主页logo也换成了这个截图，不过更加惊奇的是这款游戏已经用javascript实现出来了，也就是说在google的主页可以直接体验下，背景音乐也在里面。
无独有偶，http://jsmario.com.ar/这个站点的作者Jacob Seidelin已经用javascript实现了玛利奥的小游戏，大小仅仅14k。这款游戏利用了Canvas元素（IE中用HTML 模拟），图像存储在加密的字符串中， 还用base64存储了MIDI背景音乐。除了这些技巧，其它代码就是我们熟悉的HTML、CSS和JavaScript。感叹牛人们的强大，感叹牛人们对经典的追随。
你是否想到很常见的技术竟然可以做出这么牛的应用？我记得以前也看过一个用汇编做出来的只有7k大小的迷宫程序，当时也很乍舌。