在mootools的官方网站有一个网页专门用来测试几个框架的速度，大概是：mootools,jquery,prototype,dojo,yui，测试下来jquery的平均速度应该算是最快的。

那个评测下来IE下JS运行速度慢果然是很明显的。同样的测试在IE下面比FF下面，速度慢了一倍左右啊。

不多了。自己测试一下看结果吧。。
http://mootools.net/slickspeed/

1.6版本的zf终于将SOAP放进来了，同时也增加了DOJO的支持。不过我没有想通。为什么那么多的JS框架，最终会选择了DOJO。

这些不是我能够想得通的。还是看看到底更新了什么再说吧。

An overview of new features:

• Dojo Integration
  • JSON-RPC
  • Dojo Data packing
  • Dojo View Helper
  • Dijit integration with Zend_Form & Zend_View
  • Dojo Library Distribution
• SOAP
  • SOAP Server
  • SOAP Client
  • Autodiscovery
  • WSDL access
  • WSDL Generation
• Preview of Tooling Project in Laboratory (see /laboratory folder)
  • Command Line Interface
  • Project Asset Management
• Unit Testing Harness for Controllers
• Lucene 2.3 Index File Format Support
• Zend_Session save handler for Database Tables
• Paginator Component
• Text/Figlet Support
• ReCaptcha Service
• Zend_Config_Xml Attribute Support
• Character Set Option for DB Adapters
• Zend File Transfer Component
• New Media View Helpers (Flash, Quicktime, Object, and Page)
• Support in Zend_Translate for INI File Format

This obviously marks a very important step towards a high-quality, highly tested 1.6 GA release. Thanks to everyone who has contributed to this release in any way: with patches/check ins, documentation/translations, and bug reports.

But our work is not yet over! Let's do our best to bring this release to the breaking point to find areas we can improve the release for General Availability. Based on your feedback we will determine in the next few weeks whether we require additional release candidates, so please provide feedback on our issue tracker (http://framework.zend.com/issues) as soon as you can and ask any questions/post your experiences on the appropriate mailing list.

Again, the Zend Framework community does NOT recommend this release for production use. We do, however, recommend evaluating new features in this release with existing and new applications.

Enjoy 1.6RC1, and see you on the issue tracker, wiki, and mailing lists!

————END————

不知道：Zend File Transfer Component，这个会给我们带来什么样的惊喜？大文件传输还是其他的？下载源码研究一下，哈哈

原文地址：http://devzone.zend.com/article/3509-Zend_Acl-and-MVC-Integration-Part-I-Basic-Use

原文内容：

By Aldemar Bernal

So, what is wrong with Zend_Acl and the current MVC implementation in the Zend Framework? there is nothing wrong, it is just that it gets not too obvious for developers how to achieve an optimal integration between these two important parts of the framework.

First at all, this article is based on the following Zend Framework Proporsal (link), by this moment this proposal is in Pending Recommendation state.

Well, how it works? There are two key components in this proposal:

1. A Front Controller Plugin: This component resolves if the current user has access to the page which is being opened.
2. An Action Helper: This component allows you to check whether the current user has access inside a controller.

Based on these two components, let's try them with an example. Let's talk about a website like DevZone, we would need a controller that work with the user management and another one which will deal with article management, as well we need 3 types of users (roles), one for guests, one for writers and another one which will approve the articles; resuming, we have:

Resources:

1. user controller.
2. article controller.

Roles:

1. Guest.
2. Writer.
3. Admin.

Setting up the Zend_Acl component

After defined what we want to do, the next step will create a Zend_Acl instance which will reflect our model.

/** Creating the ACL object */
require_once 'Zend/Acl.php';
$myAcl = new Zend_Acl();

Creating the roles

Now we create the roles in our Zend_Acl instance.

/** Creating Roles */
require_once 'Zend/Acl/Role.php';
$myAcl->addRole(new Zend_Acl_Role('guest'))
      ->addRole(new Zend_Acl_Role('writer'), 'guest')
      ->addRole(new Zend_Acl_Role('admin'), 'writer');

Creating the resources

And then we create the resources needed (one per controller) and their relationship with the roles we created.

/** Creating resources */
require_once 'Zend/Acl/Resource.php';
$myAcl->add(new Zend_Acl_Resource('user'))
      ->add(new Zend_Acl_Resource('article'));

Creating the permissions

Now that we added the roles and resources to our Zend_Acl instance, it's time to explain what actions must be available to which roles.

1. Guest won't have access to edit, add or approve an article.
2. Writer won't have access to approve an article.
3. Admin will have complete access.

/** Creating permissions */
$myAcl->allow('guest', 'user')
      ->deny('guest', 'article')
      ->allow('guest', 'article', 'view')
      ->allow('writer', 'article', array('add', 'edit'))
      ->allow('admin', 'article', 'approve');

Creating the access denied view file

We will need to create a view and an action which will address all those denied users, in order to do it, first we create a new action in our error controller:

class ErrorController extends Zend_Controller_Action
{
    ....

    public function deniedAction()
    {
    }

    ....
}

And then we create our view file (/application/views/scripts/error/denied.phtml) with some warning message:

<h1>Error</h1>
<h2>Access denied</h2>
<p>You are trying to access an area which you have not allowed.</p>

Finishing the configuration

Okay, we have setup our Zend_Acl configuration, so far, it doesn't look like something new, but the next step is register the controller plugin, this important part takes the Zend_Acl instance we created and then validates it against the current page being accessed by an user.

/** Setting up the front controller */ 
require_once 'Zend/Controller/Front.php'; 
$front = Zend_Controller_Front::getInstance(); 
$front->setControllerDirectory('path/to/controllers'); 
 
/** Registering the Plugin object */ 
require_once 'Zend/Controller/Plugin/Acl.php'; 
$aclPlugin = new Zend_Controller_Plugin_Acl($myAcl);
$aclPlugin->setRoleName($currentUserRole);

$front->registerPlugin(new Zend_Controller_Plugin_Acl($acl, 'guest')); 

/** Dispatching the front controller */ 
$front->dispatch();

After this configuration is done, once an user enters in our application, depending the role he/she has the page will be displayed or an access denied page will be displayed.

For more information about this you can go to:
Zend_Acl & MVC Integration
and here is a small implementation source code of this:
Source Code

————END————
由于本文并没有什么特别的地方，而且单词也没有什么，故不作翻译。

日常工作中，有一些网站是经常要去的，因此在这里加上链接，以后就可以偷懒了，而且，也防止自己以后找不到相应的网站。[逐步更新中]

PHP官方网站　　　PHP官方手册　　PHP下载　　PHP snap 　　pear for PHP

APACHE官方网站　　APACHE手册　　MYSQL官方网站　　MYSQL官方中文手册

SMARTY官方网站　　SMARTY手册　　smarttemplate官方网站(改名叫quickskin了)

jQuery官方网站　　prototype官方网站　　mootools官方网站

PYTHON官方网站　　PYTHON手册

下面是系统类的链接
FREEBSD操作手册

偶在网上闲逛。突然发现一段内容，对应家中现有的有线电视情况，突然感到好紧张。。。贴上部分内容，陪我一起震惊吧。

自从用了这个遥控器，我就感觉不对劲儿，怎么赛事正精彩的时侯屏幕上会出来个小窗口提示有奖答题呢? 第一次看到以为是央视搞的，后来频繁的出现感觉有点不对，按遥控器的"退出"键，居然提示，"确定退出么?" 按"确定"，居然也要半天才能消失这个小浮动窗口。真是有些震惊啊，这下真的互动了，弹窗广告居然搞到电视上来了!

流氓会武术，谁都挡不住! 相信这个技术会被更多有线电视运营商采用的。到时候面对时不时的弹窗广告，加上原来就有的贴片广告，以及那些"精彩绝伦"的电视购物广告，这电视还能看下去么? 奥运过后，电视关闭!

写代码的时候不可避免的会使用到注释。大多数的情况下，我们都是使用<!-- 这里是注释 -->，因为这是HTML自带的注释功能，在这里的代码都不会被显示到浏览器。

然而，使用了smarty之类，我们确实不是很建议这样使用，因为，在<!---->标记里的smarty代码其实还是被解析了，如果是这样的话，那么，我们其实是多做了很多事情，却没有被显示出来，那就是说，我们其实多做了很多无用功。

因此，我们在使用smarty模版的时候，应该根据smarty的规范来。让我们看看手册怎么说：

所有例子中，我们假定你使用缺省的分隔符。Smarty中，所有在分隔符之外的内容被显示为静态内容，或者说不会被改变。一旦Smarty遇见分隔符，它将尝试解释它们，然后在其位置处显示合适的内容。

注释

模板注释由星号包围，继而由分隔符包围，型如：{* 这是一个注释 *}。Smarty注释不会在最终模板的输出中显示，这点和<!-- HTML comments -->不同。前者对于在模板中插入内部注释有用，因为没有人能看到。;-)

{* 这是Smarty注释，不出现在编译后的输出中 *}
<html>
<head>
<title>{$title}</title>
</head>
<body>

{* 另一个单行Smarty注释 *}
<!-- HTML注释将发送到浏览器 -->

{* 这是一个多行
Smarty注释
并不发送到浏览器
*}

{*********************************************************
多行注释块，包含了版权信息
@ author: bg@example.com
@ maintainer: support@example.com
@ para: var that sets block style
@ css: the style output
**********************************************************}

{* 包含了主LOGO和其他东西的头文件 *}
{include file='header.tpl'}


{* 开发注解：$includeFile变量在foo.php脚本中赋值 *}
<!-- 显示主内容块 -->
{include file=$includeFile}

{* 该<select>块是多余的 *}
{*
<select name="company">
{html_options options=$vals selected=$selected_id}
</select>
*}

{* 模板的cvs标记。下面的36应该是美元符号。
但是在CVS中被转换了。 *}
{* &#36;Id: Exp &#36; *}
{* $Id: *}
</body>
</html>

smarty中的变量和平时使用有点区别，比如$aa.bb其实代表的是$aa['bb']，具体如何个使用法，其实在手册里已经有详细说明了

Smarty可以识别嵌入在双引号中赋值的变量，只要变量名只包含数字，字母，下划线和方括号[]（参见命名）。如果有其它字符（如句点，对象引用等），变量必须由反引号对`backticks`包含。你不可以嵌入修饰符，它们必须永远在引号之外使用。

实际使用中应该是这样的：

语法例子：
{func var="test $foo test"}       <-- 使用$foo
{func var="test $foo_bar test"}   <-- 使用$foo_bar
{func var="test $foo[0] test"}    <-- 使用$foo[0]
{func var="test $foo[bar] test"}  <-- 使用$foo[bar]
{func var="test $foo.bar test"}   <-- 使用$foo（不是$foo.bar）
{func var="test `$foo.bar` test"} <-- 使用$foo.bar
{func var="test `$foo.bar` test"|escape} <-- 修饰符在引号外！

实际例子：
{include file="subdir/$tpl_name.tpl"} <-- 将以实际值替换$tpl_name
{cycle values="one,two,`$smarty.config.myval`"} <-- 必须有反引号！

看清楚哦。平时在使用的时候应该是感觉不出问题的，只有用在函数、循环里面，这才会成为使用中的问题。

看到这段，觉得有理。。。记录下来，实在不知道原作者是谁。。。。

一个程序员的13口决！
1、编程就像吃饭，不可能一口变成胖子。
2、还没练几天就想要高工资，不如去批发白菜好了。
3、程序员也民工，不觉得自己太高尚。
4、你的代码永远存在可优化的可能，所以有空要回头再看看。
5、编程时要永远开着记事本，测试数据，测试方法，搜到的代码等等要常放进去，存起来以备不时之需。
6、不要再回忆你的代码有多牛B，第二天早上别人的代码就可把你的程序替换了。
7、每一天都不是糟糕的，更糟的还在后面。
8、整理你的代码，文档，思维方式，以及行为方式。
9、第一次看到时千万别说你已经理解了。。。未来的变数还很大。
10、任何事物都是由简单开始，并最终回归简单。只是层次不同了而已。
11、首先感谢自己，然后再谢别人。还要感谢人民政府给你提供了就业机会。
12、永远都知道自己当前该做什么。
13、理解正念，并认真执行。

1.知书达礼：仅知道书本知识是不够的，还要学会送礼；
2.度日如年：日子非常好过，每天像过年一样；
3.杯水车薪：每天办公室喝喝茶，月底可以拿到一车工资；
4.知足常乐：知道有人请自己洗脚，心里就感到快乐；
5.见异思迁：看见漂亮的异性就想搬到她那里去住；
6.语重心长：别人话讲得重了，心里怀恨很长时间；
7.有机可乘：出门考察有飞机可以乘坐；
8.不学无术：不要白费工夫学那些不实用的东西；
9.夫唱妇随：丈夫进了歌厅，妻子跟踪尾随。

何谓开源？网上有多种说法，但从字面意义来说，就是：开放源代码。
我们看看百科上怎么说：

关于开放源代码的定义(1.7版）

开放源代码并不仅仅意味着对源代码的访问权。开放源代码软件的发布条款必须满足以下条件：

1. 自由地再发布

如果被发布的软件是由不同来源的程序组成的，许可证不得限制任何当事人或组织（party）销售或赠送作为被发布软件成分之一的开放源码软件。

许可证不得从此项销售中索取使用费或其它任何费用。（理由）

2. 源代码

程序必须包括源代码，必须允许以源代码方式发布、还必须允许以编译后的形式发布。如果产品的某个部分没有与源代码一同发布，那么必须提供通行的、不需要支 付合理范围之外的任何费用的手段以获得源代码---从网络上免费下载是一种可取的方式。源代码必须是程序员对其进行修改的最佳形式。故意地使源代码变得含 混晦涩是不允许的。也不允许给出预处理器或翻译器处理的中间结果。（理由）

3. 派生作品

许可证必须允许修改软件和派生软件，并且必须允许它们按照原软件的许可证的条款进行发布。（理由）

4. 作者的源代码的完整性

只有在许可证允许与源代码一同发布"补丁文件"（该"补丁文件"以在创建时对程序进行修改为目的）时，许可证才能限制对修改形式的源代码的发布。许可证必 须明确地允许发布由修改后的源代码生成的程序。许可证可以要求派生的作品采用不同的名称或不同的版本号以区别于原来的软件。（理由）

5. 不得歧视任何个人或团体

许可证不得歧视任何个人或者由多人组成的团体。（理由）

6. 不得歧视任何应用领域（fields of endeavor）

许可证不得限制任何人把程序应用于任何领域。例如，不得规定程序不能应用于商业领域或基因研究领域。（理由）

7. 许可证的发布

与程序有关的权利必须适用于该程序的任何使用者，并且程序的使用者也不需要为了使用该程序而获得其它许可证的许可。（理由）

8. 许可证不能针对于一个产品

与程序有关的权利不能由该程序是否作为某个软件产品的一部分来决定。如果程序从那个发布中被抽出来，并且按照程序的许可证的条款进行使用和发布，那么得到该程序的当事人或组织将获得与得到原程序的使用者相同的权利。（理由）

9. 许可证不能影响其它软件

许可证不得向与采用它的软件一同发布的其它软件提出任何限制。例如，许可证不能坚持要求在同一媒体上发布的其它程序都是开放源代码软件。（理由）

Conformance

（本节不是开放源代码定义的一个部分）

我们认为本开放源代码定义涵盖了由绝大多数软件团体使用的术语"开放源代码"的最初含义和当前含义。然而，该术语被广泛地应用，并且它的含义变得不精确 了。OSI Certified标志是某个软件发布许可证是否服从开放源代码定义的OST认证方式。一般的术语"开放源代码"并不提供这种担保，但我们仍然鼓励使用" 开放源代码"这一术语以表明它符合"开放源代码定义"。关于OSI Certified标志的信息，以及已经通过了OSI Certified、符合"开放源代码定义"的许可证，请参见OSI Certified标志与纲要。

开放源代码定义之原理

给出开放源代码的定义的目的是：把我们所确信的、由软件开发团体所公认的"开放源代码"的含义作为一组具体的准则写下来---该准则确保按照开放源代码许 可证发布的软件可以得到与其它软件同样认真的评审、使软件可以不断地得到改良和遴选，从而提供非开放软件所难以提供的可靠性与能力。

为了使此项工作持续发展，我们必须抵制人们为了短期利益而中止为软件开发做出贡献。这意味着，许可证的条款必须防止人们藏匿（lock up）源代码从而导致只有很少的人才能够阅读和修改它。

当软件的开发者按照由OSI认证的许可证发布他们的软件时，他们可以在软件中使用"OSI Certified"标志。这种认证标志告知用户，该软件所采用的许可证符合开放源代码定义。关于我们的认证标志的更多信息及其纲要，请参见OSI Certified标志与纲要。

1. 自由地再发布

通过强制要求许可证允许自由地再发布，我们抵制了任何为了获得少量短期销售金额而放弃长期效益的诱惑。如果我们不这样做，就会有很多压力迫使合作者放弃承诺。

2. 源代码

由于软件只有通过修改才能够得到改进，因此我们要求获得易于理解的源代码。因为我们的目的是使软件易于改进，我们也就希望软件易于修改。

3. 派生作品

仅仅提供可以阅读的源代码，对于实施认真的评审、对于软件的快速改良与遴选来说都是不够的。为了加快改进软件的速度，人们需要能够进行试验和对修改进行重新发布。

4. 作者的源代码的完整性

鼓励对软件进行各种改进是一件好事，但使用者有权知道谁应该对他们所使用的软件负责。软件的作者和维护者都有权知道需要他们提供支持的软件是什么，以维护他们的名誉。

因此，开放软件许可证必须保证可以容易地得到源代码，但可以要求源代码以原始源代码和一组补丁文件的形式发布。按照这种方式，就可以获得"非正式的"的修改而同时又可以轻易地把它们从原始源代码中区分出来。

5. 不得歧视任何个人或团体

为了从该进程中获得最大的收益，应该给尽可能多的个人和团体以同等资格对开放源代码软件做出贡献。为此我们禁止开放源代码许可证把任何人排除在这个进程之外。

6. 不得歧视任何应用领域（fields of endeavor）

该条款的主要目的是禁止许可证中含有使开放源代码软件无法在商业上使用的规定。我们需要商业用户参与我们的工作，而不让他们感到被排除在外。

7. 许可证的发布

本条款的目的是禁止通过非直接的手段，例如需要签署非公开的协定，使软件无法公开。

8. 许可证不能针对于一个产品

本条款用于预防其它许可证陷阱。

9. 许可证不能影响其它软件

开放源代码软件的发布者有权为他们自己的软件做出选择。

是的，GPL满足这条要求。按GPL发布的库只影响（contaminate）在运行时与之连接的软件，于仅仅和它一同发布的软件无关。

OSI Certified标志与纲要

开放源代码定义给出了开放源代码软件的基本性质。不幸的是，术语"开放源代码"遭到了滥用，并且由于它的描述性，它不能作为一个商标（这是我们的首选）被 保护。由于社团需要一种可靠的方式以确定一份软件是否真正是开放源代码软件。OSI为此目的而注册了一个认证标志，OSI Certified。如果你在一份软件上看到了该标志，那么该软件就是必定是按照遵从开放源代码定义的许可证发布的，否则，该发行人就是在滥用该标志而且 违反了法律。

OSI Certified标志被用于软件而不是许可证：人们需要知道的是组成软件的包和它们的许可证是开放的源代码。此外，单独的许可证可能不是"货物"，它由 美国专利和商标局注册认证标志。但是软件的作者显然必须能够在不询问我们的情况下（自我认证）、在适当的时刻确认他们的软件是按照OSI Certified的开放源代码方式发布的。所以认证按照两步进行：

* OSI提供一个满足开放软件源代码定义的开放源代码许可证表。这些许可证经过公众的详细审查并且被我们所批准。如果你有一个希望加入该列表的许可证，请与license-approval@opensource.org联系，它启动了获得许可证批准的程序。

* 如果你希望在你的软件上设置OSI Certified标志，你可以从列表中选择一个获得批准的许可证并根据它发布软件，并且适当地为软件做标志。

上面仅仅是一个概括。下面给出申请批准许可证和把OSI Certified标志应用在你的软件上的详细说明。

获得许可证的批准

1．通过电子邮件把许可证发送给license-approval@opensource.org。在电子邮件中说明你是否愿意以你的签名或者匿名地把许 可证发送到许可证讨论列表中。（我们愿意考虑那些根本不希望被发送的许可证，但由于社团的评审是批准的一个重要组成部分，我们将不得不把该许可证私下地发 送给评审者：因此，对没有被发送到许可证讨论列表中的许可证的批准，要花费更长的时间，并且通常要更多地与你交流。）

2． 如果我们发现你的许可证不符合开放源代码的定义，我们将与你一同解决这个问题。

3． 同时，我们将关注许可证论坛列表，并且与你一同工作以解决大家提出的任何未包含的问题。

4． 作为该过程的一部分，我们还将就许可证问题向外界寻求法律上的建议。

5． 一旦许可证符合了开放源代码定义，并且在许可证论坛上经过了充分的讨论或者其它的评审者没有提出我们认为重要的问题，我们将通知你，许可证已经被批准了，同时它被复制到我们的网站上，并且被加入以下的许可证列表。

使用该标志

你可以在这两种软件的发行上使用OSI Certified标志。该软件的发布包括并且达到了被批准的许可证列表中某个许可证的要求，或者该软件的源代码已经被明确地放到公众可以得到的位置。

为了表明你的软件是按照OSI Certified发布的，你必须不加任何修改地把下面两者之一，按照下述方式加入你的软件。完整的声明是：

This software is OSI Certified Open Source Software.

OSI Certified is a certification mark of the Open Source Initiative.

较简短的声明是：

OSI Certified Open Source Software

你的软件的每种发布形式都有自身的要求：

* 如果软件以电子的形式发布（而不是实物（tangible）的形式），你必须把完整的声明放在README文件或者类似的、人类用户将首先阅读的文件中。

* 如果软件以实物形式发布，你必须完成以下所有可行的任务：

* 如果软件的发布包括印刷品，你必须把完整的声明加入该印刷品。

* 如果软件发布在可擦写的媒体（例如软磁盘）、CD-ROM、磁带等媒体上，它们在物理上可以添加能够被人的裸眼所阅读的简短声明，而不影响它们的功能，你必须把完整的声明或简短的声明标注在该媒体上。

* 如果软件的发布是一个的包，从而使其中的声明不能被阅读。你必须在包的外面放置完整的声明。

如果不能把以上任何条款用于发布，请与我们联系，我们将把你选择的位置加入本列表。

获得批准的许可证

以下许可证满足开放源代码的定义，并且已经被批准用于OSI Certified的开放源代码软件。没有给出批准日期的许可证是在1999年1月1日以前批准的。

* The GNU General Public License（GPL）；

* The GNU Library（Lesser） General Public License（LGPL）；

* The BSD License；

* The X Consortium License；

* The Artistic License；

* The Mozilla Public License（MPL）；

* The QPL；

其它符合定义的许可证包括：libpng许可证、zlib许可证、IJG JPEG许可证和OPL（Open LDAP Public License）许可证。

看看shopNC官方怎么说：我们是开源作品。确实，你是开源了，但你只开了几个目录的代码就叫开源吗？
真是有中国特色啊。

如果你自己没有自信，那你完全可以不开源。不开源本来就无所谓的，只是用这种欺骗的手段，好象有点。。。。