Joyqi.com

这周IE8团队发布了第二个beta版本，除了性能上有所提升外，也有一些重要的功能加强。

标签浏览加强

似乎Firefox插件也可以达到这个效果，不过在标签多的时候还是挺有用的。

开发人员工具的改善

在上一个beta版中出现的开发人员工具引起了业内极大的关注，它被寄希望于解决ie上调试网页程序困难的现状。不过当时的那个东西怎么看也像个玩具，连css属性动态修改都不支持，而且极不稳定。现在这种状况得到改善，不过还是没有firebug强大。

代码查看可以高亮了!

哇，这个细节不错

兼容模式切换不用重启浏览器了

而且现在打开兼容模式也只需要点一点这个按钮，而且是针对某个站点单独设置的

ok就这些，其他的功能网上有很多介绍，比如私人浏览模式等等，最后提一下，在浏览很多网站时还是有很多错位的现象，希望ie8团队下一步能尽快解决这些问题。该上班了-_-

今天来自中国雅虎的技术大牛宏威先生为我们讲解了当前雅虎的技术架构。具体细节没啥好说的，讲讲听后的感想。由于雅虎的web解决方案是标准的lamp模式，所以他对这个架构的理解以及其发展方向的把握，对我们这些工程师有很大参考意义。

首先解释一个误区，大家可能会认为中国雅虎被阿里巴巴收购后与雅虎总部就没什么关系了，其实不是这样，中国雅虎基本沿用了雅虎的技术以及研发体系，与美国总部的技术交流也很频繁，我们的开发机都是向美国雅虎申请的。而雅虎是一个php解决方案的范例，阿里巴巴由于与电子商务结合较多，所以基本是java平台。这种平台的差异也导致了中国雅虎很长时间没能融入阿里巴巴的技术体系。不过我所在的雅虎口碑可能是这种融合的一个契机，原来的口碑网是java体系，雅虎的工程师加入后，用php开发了一些产品。因此现在的雅虎口碑是一个php与java的杂合方案，有的产品是基于php，有的是基于java。不过最近公司也在思考一些平台整合与统一方面的事情，不过最终到底是php还是java，对我的影响倒不大。用我主管的一句话说，如果公司最后选择php，当然我们php工程师很happy，如果选择java，那么在公司能够系统学习一种新的体系对自己以后的发展也非常有用。

扯了这么多闲话，来讲讲正题。php的优点我不需要再说，有很多人比我说的好得多，我只是想结合自己的经历谈谈一个lamp工程师的技术发展方向。注意是技术发展方向，如果你想往管理层跳就单说了。写了三四年php了，越学到后面越觉得自己知识狭窄，越觉得自己理论知识方面的缺乏，因此目前自己补充的主要是一些基础理论知识，比如编程思想和操作系统原理等等，当你的技术从业务层延展到系统层时。你可能会跟我有一样的感觉，这里是一片新的天地，很多东西都要重新学起，不过大学里学的一些基础理论在这里会很有用，因此我就要不厌其烦的教育下学弟学妹们，如果你想以后的发展有点深度的话，珍惜自己的大学时光，学点有用的东西，特别是理论知识。

在系统这一级别，你就是一个初级的sa了，当然这个sa比你考的那个sa高级得多，系统分析师认证现在看起来没有任何价值。注意，我只是说这个认证，因为我大三时无聊报了一个，后来把这件事忘了，最后考的分数居然只是上午的理论分差了6分，下午的案例分析和论文分数都挺高，要知道那时候我的项目经验几乎为零。好了，别再纠结这个玩艺了，经过这件事以后我对我的某同学所谓湖北每年只有十几个系分考过的说法极为怀疑。。。

从系统级大概有两个发展方向，一个是向系统底层发展，基本就是hacker级别的人物，没事给linux的kernel做做patch啥的。或者是向框架级别发展，定义框架流程，把握整个系统的开发方向也就是所谓的architecturer。不管是哪一种，都是科学家级别的人物，需要熟悉很多技术体系。而有很多phper学了几个月php，就觉得可以做任何网站了，觉得这些门户也不过如此，开始产生一种独孤求败的感觉-_-!，这是很可笑的姑且不论你对系统有什么理解，在我看来对一种语言有所体会基本是需要5，6年以上的沉淀。

这是我到新公司后发表的第一篇文章，说得很杂，也代表了我现在的心情。很复杂，有些兴奋，有些茫然...

PHP界的开发热潮可以用风起云涌来形容了，最新的WEB动向都可以在这里体会到。在我上大学那会还是流行开发论坛，后来流行开发博客，最近似乎开始流行框架了。我们亲爱的水水同学也加入到这水生火热的框架开发大军中了，那么我觉得作为一个PHP开发人员，有必要谈一谈我对框架的看法，希望对这些框架开发者有些启示。

我大二开始接触PHP开发，毕业论文的题目就是《大型网站框架开发》。当然那个时候对框架的认识还是比较幼稚的，但是在实习公司CTO的指导，和大牛老覃的帮助下，对框架的认识开始逐渐加深。到现在已经过了“向世界宣布要独自一人开发出最牛逼，最高效的框架”的时期了，当然并不是磨灭了志气，如果说我有这种资源我还是会尽力一试的，这也就是为什么我一直在推进开源blog项目，因为我们团队有这个实力，我们肯定会成功。

但是框架开发并不是那么回事了，我自己开发过一个框架，那个框架真的完全是我一个人写，也就是现在Magike的前身。当时我心中真是把它当成世界上最好的框架了，执行效率尚可，代码布局规范，开发方便。但是在项目中总会遇到种种问题，当时我对自己的框架开始产生动摇，它毕竟不能解决所有问题，因此我开始在追求全面解决问题的基础上，修改框架，最后搞得身心俱疲，那个项目也以失败告终（当然失败的主要原因是市场运作，而不是技术上的问题）。我当时在这个公司做毕业设计时，公司的CTO告诉我，你只需要回答我一个问题，框架是什么？

现在回想起来，当时的回答可真够烂的，具体是甚暂且不表。经过多个项目的磨炼，我也接触了很多框架，对框架的理解也有所加深。我承认我目前对Zend Framework很欣赏，基本上要我开发项目，我的首选就是它了，自己也给它写了一些插件。现在让我用问答的形式展开此文

1.框架要解决什么问题?

对我来说，框架并不是要给我限制一种开发方式，一种程序结构，它就是帮助我们快速开发的，至于用什么结构，项目多种多样，我们可以自己选择。Zend Framework可以解决这个问题，他几乎包含了所有的PHP应用以及第三方应用支持，所以我选它。因此我并不要求框架给我提供一种解决方案，我只需要它能够根据我的需要组合出一个解决方案。Zend Framework是用package方式来组织项目结构，需要什么模块，只需要引用相关package就行了，也不需要关心依赖问题。

在此我要特别提醒各位框架开发者，目前几乎大多数开源的第三方库都是使用package模式来发布，如果你希望自己的框架能够快速扩展第三方应用，我觉得还是用这种方式来组织结构比较妥当。

2.中小型框架在乎执行效率，大型框架在乎生产效率。

这是它们所服务的对象不同所造成的，初学程序的同学会把程序性能看成头等大事，但当你经过了项目的洗礼后你就会发现，对于大型项目来说程序性能已经被放到比较次要的位置了，结构才是王道。现代计算机系统发展非常迅猛，很多在程序中性能提升的小技巧很快就会被淘汰，特别是像PHP这种脚本语言，最终计算机指令集与其语言解释器本身有很大关系，与其关心这些技巧，不如把注意力放到程序结构的优化上来。

我举一个很简单的例子，为什么在很多框架中都有数据库抽象层这个概念？如果你不理解它的意义，你设计出来的抽象层可能没有任何意义。在我看来数据库抽象层有三个意义

1. 减少SQL书写量，从而降低出错几率

2. 通过提供给开发者统一的接口，让Developer与DBA角色分离，即使数据库被更换，也无需更改程序

3. 缓存考虑

以上三点，第一点，对于小型框架来说一般开发者比较少，出了错可能也是你自己调试，因此基本这一条可以忽略。第二条也可以忽略，理由同第一条。第三条看上去比较重要，但是小型项目在数据库这一级用到缓存的机会比较少，也可以忽略。综上所述，小型框架里没有存在数据库抽象层的必要，直接上SQL吧，当然为了少写些代码，不用每次都要先query再fetch，也为了满足程序员懒得每次都connect数据库的愿望，还是可以简单得封装一下的。但也就是connect封装到__construct里，query封装到fetch里了事，不用搞得太复杂。

如果你想把数据库层搞得复杂点，可以达到另一个极致，现在有的数据库层已经可以直接绑定ORM视图，这意味者什么？意味着你在所见即所得设计工具里把数据库ORM关系映射设计出来，丢到PHP里面就可以直接生成Model了，不用管什么联动操作，因为关系里面都标明了。

可以说这也是一种发展方向，但PHP是一个解决实际问题的语言，它所有的函数都是为了解决问题才出现的，以前天天有人说PHP不够企业级，语言不规范，不是完全OOP等等。其实他们都没有看到PHP流行的实质，没有看到PHP草根的原因？这个原因可以用他们的问题来解释，也就是这个世界上非企业级的问题比企业级的问题多得多。PHP只是专注于它自己的问题，而恰好这个范围又比较大，门槛比较低罢了。

但PHP的学习者也不必担心，自己提高到某个程度后就到顶了，没有这回事，虽然说高处不胜寒，但也有无限风光在险峰一说。其实PHP是一门对系统工程要求比较高的语言，因为它的开放性，开发者需要不停地与不同的系统打交道，一般做过几年开发的，对服务器优化，数据库管理都比较精通。

3.不要盲目地选择框架，更不要盲目地开发框架

经常看到有人用"Hello World"程序来对比两个框架的执行效率。这样的对比是没有任何意义的，虽然大家都说没有意义，但是还是有很多人要这样比，因此我也不指望我说的这句没意义能像许三多那句这么有影响力。就我自己来说，选择框架主要看两点:

1. 完善的支持

2. 适合项目需要

为什么我把“完善的支持”放到第一点，因为从某种意义上来说如果你有强大的支持社区那么这个框架也可以和“强大”二字画上等号了，因此从这一点上来说zend framework是世界上最强大的php framework不为过。这种成熟框架的文档一般比较全面而且规范，它不会在一些无关紧要的问题上废话一句，而在那些可能会出现问题的地方则是详加解释，又是注释又是FAQ，从这里就可以看出开发者的素质。可能是自己性格问题，我实在是不喜欢在论坛上提问题等着别人来回答，也不喜欢碰到个问题就要和开发者联系，这样耽误大家的时间。

适合项目需要，当然也不必多提。杀鸡不用牛刀的道理大家都懂。

好了，杂乱地写了这么多，从头到尾看了一下好像又什么都没说，各位权当浮云罢

今天在CSDN闲逛的时候，发现PHP版有人发帖说php.net把中文文档删掉了，到phpchina的论坛也发现有人在说这件事。大家不约而同地把此事跟最近的国内外政治事件联系起来。我到php.net调查了一翻，发现http://www.php.net/docs.php页面确实没有中文的链接了，繁体的也没有了。但是http://www.php.net/manual/zh/的内容却完好无损，这说明并不是因为什么人为意志因素导致的。

更进一步地调查发现，中文文档的上次更新时间是2007年10月，至今已经有半年。当我浏览到http://www.php.net/manual/help-translate.php页面时，就大概了解事情的实际情况了。中文文档因为已经很久没有更新所以被放到了Inactive languages already in CVS列表里面。并不是因为其他的什么原因。

不过细想一下，如果开源项目是凭借贡献程度来判断是否有使用权的话，那么中国实际上发言权应该很小。中国对开源的贡献明显与其应用程度不符，虽然中国的信息化程度有限，但是开源的应用程度却与发达国家不相上下。当我们疯狂地索取他人的成果，是否可以反过来向其贡献自己的力量，以促进整个行业的发展呢？

首先说明，此文是原作者04年撰写的，当时的情况确实如文中所说。但是CSDN却在现在把这篇文章的翻译给刊出来，而且还是在新闻频道中，真是让人不理解。以下是原作的全文

PHP确实十分容易编写。但是PHP也有一些十分严重的缺陷。

下面我会给出我的理由，为什么PHP不适合于比小型业余网站更大的网站。

1. 对递归的不良支持

递归是一种函数调用自身的机制。这是一种强大的特性可以把某些复杂的东西变得很简单。有一个使用递归的例子是快速排序(quicksort)。不幸的是，PHP并不擅长递归。Zeev，一个PHP开发人员，说道：“PHP 4.0(Zend)对密集数据使用了栈方式，而不是使用堆方式。也就是说它能容忍的递归函数的数量限制和其他语言比起来明显少。”见bug 1901。这是一个很不好的借口。每一个编程语言都应该提供良好的递归支持。

2. 许多PHP模块都不是线程安全的

在几年前，Apache发布了Web服务器的2.0版。这个版本支持多线程模式，在这个模式下，软件一个一部分可以同时运行多个。PHP的发明者说PHP的核心是线程安全的，但是非核心模块不一定是。但是十次有九次，你想要在PHP脚本中使用这种模块，但这又使你的脚本不能合适Apache的多线程模式。这也是为什么PHP小组不推荐在Apache 2 的多线程模式下运行PHP。不良的多线程模式支持使PHP常被认为是Apache 2依然不流行的原因之一。

请阅读这篇讨论： Slashdot: Sites Rejecting Apache 2?.

3. PHP 由于商业原因而不健全

通过使用缓存，PHP的性能可以陡增500%[见基准测试]。那么为什么缓存没有被构建在PHP中呢?因为Zend——PHP的制造者，它在销售自己的Zend Accelerator，所以当然，他们不想抛弃自己的商业产品这块肥肉。

但是有另一个可选择的： APC. (Zend后来推出Zend Optimizer，免费的加速器——译者)

4. 没有命名空间

设想某个人制作了一个PHP模块用来阅读文件。模块中一个函数叫做read。然后另一个人的模块可以读取网页的，同样包含一个函数read。然后我们就无法同时使用这两个模块了，因为PHP不知道你要用哪个函数。 但是有一个很简单的解决方法，那就是命名空间。曾经有人建议PHP5加入这个特性，但不幸得是他没有这么做。现在，没有命名空间，每个函数都必须加上模块名作为前缀，来避免名称冲突。这导致了函数名恐怖得长，例如xsl_xsltprocessor_transform_to_XML让代码难于书写和理解。

5. 不标准的日期格式字符

很多程序员对 日期格式字符 都很熟悉，它是从UNIX和C语言中来的。其他一些编程语言采用了这个标准，但是很奇怪的，PHP有它自己的一套完全不兼容的日期格式字符。在C中，“%j”表示一年中的当天，在PHP中他表示一个月中的当天。然而使事情更混乱的是：Smarty (一个很流行的PHP模版引擎)的 strftime 函数和 date_format 函数，却使用了C/UNIX的格式化字符。

6. 混乱的许可证

你也许认为PHP是免费的，所有的在手册中提到的PHP模块也是免费的。错了!例如，如果你想在PHP中生成PDF文件，你会在手册中发现两个模块：PDF 和 ClibPDF。但是这两个都是有商业许可证的。所以，你所使用的每个模块，你都要确保你同意他的许可证。

7. 不一致的函数命名规则

有些函数名称是有多个单词组成的。一般有三种单词组合的习惯：

直接拼接：getnumberoffiles

用下划线分开：get_number_of_files

骆驼法则：getNumberOfFiles

大部分语言选择其中一中。但是PHP都用到了。

例如，你想要把一些特殊字符转换成HTML实体，你会使用函数htmlentities (直接拼接单词)。如果你要使用相反的功能，你要用到它的小弟弟html_entity_decode。由于某些特殊的原因，这个函数名是由下划线分隔单词。怎么能这样呢?你知道有一个函数叫strpad。或者他是str_pad?每次你都要查看一下到底这个符号是什么或者直接等他出现一个错误。函数是不分大小写的，所以对于PHP来说rawurldecode 和RawUrlDecode之间没有什么区别。这也很糟糕，因为两个都使用到了同时他们看上去还不一样，混淆了阅读者。

8. 魔法引用的地狱

魔法引用(Magic quote)可以保护PHP脚本免受SQL注入攻击。这很好。但是出于某些原因，你可以在php.ini中关闭这个配置。所以你如果要写出一个有弹性的脚本，你总要检查魔法引用是开启还是关闭。这样一个“特性”应该让编程更简单，而事实上变得更复杂了。

9. 缺少标准框架

一个成长中的网站没有一个整体框架，最终会变成维护的噩梦。一个框架可以让很多工作变得简单。现在最流行的框架模型时MVC-模型，在其中表现层、业务逻辑和数据库访问都分离开了。

很多PHP网站不使用MVC-模型。他们甚至没有一个框架。甚至现在有一些PHP框架同时你都可以自己写一个，关于PHP的文章和手册没有提高框架的一个字。同时JSP-开发人员使用像Struts的框架、ASP开发人员使用.net，看起来好像这些概念都广泛被PHP开发人员所了解。这就说明了PHP实际上到底是多专业。

总结

什么问题?

对于非常小的项目，它可以是一个十分符合人意的编程语言。但是对于较大的和更为复杂的项目，PHP就显出他的薄弱了。当你不断地摸索之后，你会发现我提到的某些问题的解决方案。所以，当解决方案已知之后，为什么不能修正他呢?另外为什么这些修补不在手册中提到呢? 一个开源的语言十分流行是一件好事。但不幸得是，它不是一个伟大的语言。我希望所有的问题能有一天得到解决(也许在PHP6?)，然后我们就将拥有一个开源语言，他既开源，又好用。

到现在，当你要启动一个多于5个脚本页面的项目的时候，你最好考虑C#/ASP.NET或者 Java/JSP或者也许Python同样是一个更好的选择。

Read the rest of this entry »