2、在对网站的定位也略有不同，实际上FACEBOOK并不是”交友网站“，官方不推荐大家去结交新朋友，而是鼓励与现实生活中的朋友沟通，所以FACEBOOK的聊天上都是和好友聊天，而SOHU的列表是和陌生聊天。

3、他们新的登录条方式借鉴了FACEBOOK的设计，不过对于这个设计个人认为现在的屏幕是足够宽，但是不够长。牺牲有效可视范围来实现这个功能是否正确也是仁者见仁，智者见智。

另外，从对FACEBOOK的这个安排可理解为用户浏览网页时因为是 F Scanning (“Ｆ”形状的模式阅读网页，如开心)，所以右下角区域相对内容重要度较低，所以把聊天功能安排在这里对功能干扰较少。

而对于SOHU的页面浏览方式是 Box Scanning(“盒”形状的模式阅读网页)，页面顶部、底部、左右两边基本都有广告，主要浏览区别为中间的盒状区域内，像SOHU的这个聊天功能在使用时就对他页面右侧的“搜狐博客”和“精彩推荐”的内容产生了影响。

以下两个链接是对小纸条的介绍：
http://www.hudong.com/wiki/%E6%90%9C%E7%8B%90%E5%B0%8F%E7%BA%B8%E6%9D%A1
http://it.sohu.com/20081124/n260803249.shtml

相关文章

• 怀旧女歌手系列 – 瑞典歌手 (0)
• 司马南：中国是一个什么样的国家 (0)
• 二十一世纪让人悲伤的七个原因 (0)
• 一个有关用户体验的文章 (0)
• [转载]在职程序员为啥比不过在野程序员 (0)

在 php.net 上也没有找到办法，后来反到是在 zend.com 上找到了解决 catch fatal error 的办法就是在 auto_prepend_file 和 auto_append_file 上做手脚。

prepend 的文件里面有一个 string 里面是个 error page 的 html 包括一个 script 可以把错误信息发送到 server 的一个 api 上。

而在 append 的文件里通过 ob_get_contents() 来把那个 string 给去掉，如果能去掉就说明程序中间的执行流程正确，无错，如果有 fatal error 则没有办法到达 append 文件这步，所以会显示那个 html 页面。

方法还可以，但是因为每个 php 都要 prepend & append 可能效率会不行，和 Xuanyan 讨论了一小会暂时还是没有什么好办法来捕获 fatal & parse error 。

:(

相关文章

• 免费软件套装 (0)
• [超长篇] Inject Your Code to a Portable Executable File (0)
• 解决 AJAX 跨域方案一(PHP Proxy) (0)
• 大型高并发高负载网站的系统架构 (0)
• 各系Rails大点兵 (0)

第一种测试方法：

<?php
/**
 * @date : Wed Jul 04 11:34:00 CST 2007 11:34:00
 * @author : Deng Wei <dengwei@gmail.com>
 * @package : test
 * @version : $Rev$
 * @info : $Id$
 */

$sth_like_config = array(
 ’a' => 1,
 ’b' => 2,
);

function get_config_a()
{
 global $sth_like_config;
 foreach ( range(1,10000) as $i )
 {
  $b = $sth_like_config['a'];
 }
}

class StaticConfig
{
 public static $sth_like_config = array(
  ’a' => 1,
  ’b' => 2,
 );
}

function microtime_float()
{
   list($usec, $sec) = explode(" ", microtime());
   return ((float)$usec + (float)$sec);
}

/**
 * start test
 */

$s = microtime_float();
get_config_a();
echo microtime_float()-$s;
echo "\n";

$s = microtime_float();
foreach ( range(1,10000) as $i )
{
 $b = StaticConfig::$sth_like_config['a'];
}
echo microtime_float()-$s;
echo "\n";

?>

结果：

0.15xxxxxxxx
0.18xxxxxxxxx

按上面这种方式测试的话是数组比静态类快，原因是我们在函数里调用的全局数组，只用了 global 一次，在同一作用域下变量比类快，这是一定的。但是在实际环境里，比如我们的配置数组经常要在一些函数里用，那么就会有多次 global 声明，让我们换一种方式测试。

测试方法二：

<?php
/**
 * @date : Wed Jul 04 11:34:00 CST 2007 11:34:00
 * @author : Deng Wei <dengwei@gmail.com>
 * @package : test
 * @version : $Rev$
 * @info : $Id$
 */

$sth_like_config = array(
 ’a' => 1,
 ’b' => 2,
);

function get_config_a()
{
 global $sth_like_config;
 return $sth_like_config['a'];
}

class StaticConfig
{
 public static $sth_like_config = array(
  ’a' => 1,
  ’b' => 2,
 );
}

function microtime_float()
{
   list($usec, $sec) = explode(" ", microtime());
   return ((float)$usec + (float)$sec);
}

/**
 * start test
 */

$s = microtime_float();
foreach ( range(1,10000) as $i )
{
 $b = get_config_a();
}
echo microtime_float()-$s;
echo "\n";

$s = microtime_float();
foreach ( range(1,10000) as $i )
{
 $b = StaticConfig::$sth_like_config['a'];
}
echo microtime_float()-$s;
echo "\n";

?>

结果：

0.51952910423279
0.18489503860474

可见 global 有多慢了，并且我们经常还会因为一些原因忘记写他，所以我的“建议”是把一些全局变量都放到静态类里，这样还用的时候就不用一直记着去 global 声明了，并且通过类来访问，我们还可以对访问进行一些控制。：）

不知道您是怎么想？我现在是把配置信息都放到静态类里了。终于告别了“global”~！

相关文章

• 英文网站大全 (0)
• 翻译：On having layout (0)
• 二十一世纪让人悲伤的七个原因 (0)
• SOAP(简单对象访问协议) 简介 (0)
• PHP5 效率优化 (0)

拉德认为：每一位顾客身后，大体有250名亲朋好友。如果您赢得了一位顾客的好感，就意味着赢得了250个人的好感；反之，如果你得罪了一名顾客，也就意味着得罪了250 名顾客。   在你的网站访客中，一个访客可能可以带来一群访客，任何网站都有起步和发展的过程，这个过程中此定律尤其重要。

2.达维多定律

达维多认为，一个企业要想在市场上总是占据主导地位，那么就要做到第一个开发出新产品，又第一个淘汰自己的老产品。   国内网站跟风太严重，比如前段时间的格子网，乞讨网，博客网，一个成功了，大家一拥而上。但实际效果是，第一个出名的往往最成功，所以在网站的定位上，要动自己的脑筋，不是去捡人家剩下的客户。同理，买人家出售的数据来建站效果是很糟糕的。

3.木桶定律

水桶定律是指，一只水桶能装多少水，完全取决于它最短的那块木板。这就是说任何一个组织都可能面临的一个共同问题，即构成组织的各个部分往往决定了整个组织的水平。   注意审视自己的网站，是速度最糟糕？美工最糟糕？宣传最糟糕？你首先要做的，不是改进你最强的，而应该是你最薄弱的。

4.马太效应

《新约》中有这样一个故事，一个国王远行前，交给三个仆人每人一锭银子，吩咐他们：“你们去做生意，等我回来时，再来见我。”国王回来时，第一个仆人说： “主人，你交给我们的一锭银子，我已赚了10锭。”于是国王奖励他10座城邑。第二个仆人报告说：“主人，你给我的一锭银子，我已赚了5锭。” 于是国王例奖励了他5座城邑。第三个仆人报告说：“主人，你给我的一锭银子，我一直包在手巾里存着，我怕丢失，一直没有拿出来。”于是国王命令将第三个仆人的一锭银子也赏给第一个仆人，并且说：“凡是少的，就连他所有的也要夺过来。凡是多的，还要给他，叫他多多益善。”这就是马太效应。   在同类网站中，马太效应是很明显的。一个出名的社区，比一个新建的社区，更容易吸引到新客户。启示是，如果你无法把网站做大，那么你要做专。作专之后再做大就更容易。

5.手表定理

手表定理是指一个人有一只表时，可以知道现在是几点钟，而当他同时拥有两只表时却无法确定。
一个网站，你只需要关注你特定的用户群需求。不要在意不相干人的看法。

6.不值得定律

不值得定律：不值得做的事情，就不值得做好   不要过度seo，如果你不是想只做垃圾站。不要把时间浪费在美化再美化页面，优化再优化程序，在你网站能盈利后，这些事情可以交给技术人员完成。

7.彼得原理

劳伦斯.彼得认为：在各种组织中，由于习惯于对在某个等级上称职的人员进行晋升提拔，因而雇员总是趋向于晋升到其不称职的地位。
不要轻易改变自己网站的定位。如博客网想变门户，盛大想做娱乐，大家拭目以待吧。

8.零和游戏原理

当你看到两位对弈者时，你就可以说他们正在玩“零和游戏”。因为在大多数情况下， 总会有一个赢，一个输，如果我们把获胜计算为得1分，而输棋为-1分，那么，这两人得分之和就是：1+（-1）=0   不要把目光一直盯在你的竞争网站上，不要花太多时间抢它的访客。我们把这些时间用来寻找互补的合作网站，挖掘新访客。

9.华盛顿合作规律

华盛顿合作规律说的是： 一个人敷衍了事，两个人互相推诿， 三个人则永无成事之日。
如果你看准一个方向，你自己干，缺人手就招。不要轻易找同伴一起搞网站，否则你会发现，日子似乎越过越快了，事情越做越慢了。

10.邦尼人力定律

一个人一分钟可以挖一个洞，六十个人一秒种却挖不了一个洞。合作是一个问题，如何合作也是一个问题。你需要有计划。

11.牛蛙效应

把一只牛蛙放在开水锅里，牛蛙会很快跳出来；但当你把它放在冷水里，它不会跳出来，然后慢慢加热，起初牛蛙出于懒惰，不会有什么动作，当水温高到它无法忍受的时候，想出来，但已经没有了力气。   如果你是soho，注意关注你的财务。不要等到没钱了再想怎么挣，你会发现那时候挣钱更难。

12.蘑菇管理

蘑菇管理是许多组织对待初出茅庐者的一种管理方法，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。
  做网站毕竟要遭遇这样的阶段，搜索引擎不理你，友情链接找不到，访客不上门。这是磨练。

13.奥卡姆剃刀定律

如无必要，勿增实体。
把网站做得简单，再简单，简单到非常实用，而不是花俏。google的首页为什么比雅虎好？

14.巴莱多定律(Paredo 也叫二八定律)

你所完成的工作里80%的成果，来自于你20%的付出；而80%的付出，只换来20%的成果。
随时衡量你所做的工作，哪些是最有效果的。

1.马蝇效应

林肯少年时和他的兄弟在肯塔基老家的一个农场里犁玉米地，林肯吆马，他兄弟扶犁，而那匹马很懒，慢慢腾腾，走走停停。可是有一段时间马走得飞快。 林肯感到奇怪，到了地头，他发现有一只很大的马蝇叮在马身上，他就把马蝇打落了。看到马蝇被打落了，他兄弟就抱怨说：”哎呀，你为什么要打掉它，正是那家伙使马跑起来的嘛！”   在你心满意足的时候，去寻找你的马蝇。没有firefox，不会有ie7，firefox就是微软的马蝇之一。马蝇不可怕，怕的是会一口吃掉你的东西，像 ie当初对网景干的那样。

2.最高气温效应

每天最热总是下午2 时左右，我们总认为这个时候太阳最厉害，其实这时的太阳早已偏西，不再是供给最大热量的时候了。此时气温之所以最高，不过是源于此前的热量积累。
你今天的网站流量，是你一个星期或更长时间前所做的事带来的。

3.超限效应(溢出效应)

刺激过多、过强和作用时间过久而引起心理极不耐烦或反抗的心理现象，称之为“超限效应”。 别到别人论坛里发太多广告。别在自己网站上放太多广告。别在自己的论坛里太多地太明显地诱导话题。

4.懒蚂蚁效应

生物学家研究发现，成群的蚂蚁中，大部分蚂蚁很勤劳，寻找、搬运食物争先恐后，少数蚂蚁却东张西望不干活。当食物来源断绝或蚁窝被破坏时，那些勤快的蚂蚁一筹莫展。“懒蚂蚁”则“挺身而出”，带领众伙伴向它早已侦察到的新的食物源转移。   不要把注意力仅仅放在一个网站上，即使这个网站现在为你带来一切。你要给自己一些时间寻找新的可行的方向，以备万一。

5.长尾理论

ChrisAnderson认为，只要存储和流通的渠道足够大，需求不旺或销量不佳的产品共同占据的市场份额就可以和那些数量不多的热卖品所占据的市场份额相匹敌甚至更大。   对于搜索引擎，未必你需要一个热门词排在第一位，如果有一千个冷门词排在第一位，效果不但一样，还会更稳定更长远。

6.破窗理论

栋建筑上的一块玻璃，又没有及时修好，别人就可能受到某些暗示性的纵容，去打碎更多的玻璃。   管理论坛时，如果你发现第一个垃圾贴，赶紧删掉他吧。想想：落伍现在为什么那么多××贴？现在控制比最初控制难多了。

7.“羊群效应”，又称复制原则(Copy Strategy)

一个羊群(集体)是一个很散乱的组织，平时大家在一起盲目地左冲右撞。如果一头羊发现了一片肥沃的绿草地，并在那里吃到了新鲜的青草，后来的羊群就会一哄而上，争抢那里的青草，全然不顾旁边虎视眈眈的狼，或者看不到其它地方还有更好的青草。
不要轻易跟风，保持自己思考的能力。

8.墨菲定律

如果坏事情有可能发生，不管这种可能性多么小，它总会发生，并引起最大可能的损失。
除非垃圾站，否则不要作弊，对搜索引擎不要，对广告也不要。

9.光环效应

人们对人的某种品质或特点有清晰的知觉，印象比较深刻、突出， 这种强烈的知觉， 就像月晕形式的光环一样，向周围弥漫、扩散，掩盖了对这个人的其他品质或特点的认识。
不要轻易崇拜一个人或者公司、一个概念、一种做法。

10.蝴蝶效应

一只亚马逊河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，两周后，可能在美国德克萨斯州引起一场龙卷风。
不管你做什么，网站或者其他，你都应该关注新闻。机遇或者灾难可能就在那。

11.阿尔巴德定理

一个企业经营成功与否，全靠对顾客的要求了解到什么程度。   我赞同别人的点评：看到了别人的需要，你就成功了一半；满足了别人的需求，你就成功了全部。尤其是做网站。

12.史密斯原则

如果你不能战胜他们，你就加入到他们之中去。  
不要试图做孤胆英雄。如果潮流挡不住，至少，你要去思考为什么。

相关文章

• 设计模式之Life time controller模式 (0)
• 设计模式之Double Checked Locking模式 (0)
• 泛型：类型化缓存(I) (0)
• 应用加速 (0)
• 如何针对MSN搜索进行网站优化 (0)

个人定制那里挺费脑细胞，还好搞定了。

：）

相关文章

• 暂无相关文章

启发式评估该选择由什么样的人来进行？
启发式评估是专家评审法的一种，选用具有可用性知识或选用具有和被测试系统相关专业知识的“专家”，具有以上两种知识的人是最合适人选，他能多发现约20%的可用性问题。

启发式评估如何进行？
每一个评审人员进行1-2小时的使用系统，之后提供一份独立的报告，在报告中应包括可用性问题的描述，问题的严重性以及改进的建议。

启发式评估的通用准则
 •Visibility of system status.可视性原则
 •Match between system and real world.系统应符合用户的真实世界
 •User control and freedom.用户有自由控制权
 •Consistency.一致性原则
 •Error strategy.有预防用户出错的措施
 •Recognition rather than recall.要在第一时间让用户看到
 •Flexibility and efficiency of use.使用起来灵活且高效
 •Aesthetics and minialist design.易读性
 •Help users recognize, diagnose, and recover from errors.给用户明确的错误信息，并协助用户方便的从错误中恢复工作
•Help and Documentation.必要的帮助提示与说明文档

附：普渡大学可用性测试检查表
使用说明：本调查表共有100题，回答每一个问题时按照以后三个步骤：
（a）请评估每一个问题是否适用于所评审的系统。如果不适用，跳到下一题。如果适用，请继续回答。
（b）对于所评估的系统，请评价该问题的重要性（1是最不重要的，3是最重要的）
（c）评价系统在该问题上的表现（1是非常糟糕，7是非常好），如果不存在，请选择不存在项
1.兼容性
 1）光标的控制是否符合光标的移动？
 2）用户控制的结果是否符合用户的期望？
 3）所提供的控制是否符合用户的技能水平？
 4）界面的编码（例如，颜色、形状等）是否为用户所熟悉？
 5）用词是否为用户所熟悉？
2.一致性
 6）界面颜色的编码是否符合常规？
 7）编码是否在不同的显示及菜单上都保持一致？
 8）光标的位置是否一致？
 9）显示的格式是否一致？
 10）反馈信息是否一致？
 11）数据字段的格式是否一致？
 12）标号的格式是否一致？
 13）标号的位置是否一致？
 14）标号本身是否一致？
 15）显示的方向是否一致？（漫游或卷动）
 16）系统要求的用户动作是否一致？
 17）在不同的显示中用词是否一致？
 18）数据显示和数据输入的要求是否一致？
 19）数据显示是否符合用户的常规？
 20）图形数据的符号是否符合标准？
 21）菜单的用词和命令语言是否一致？
 22）用词是否符合用户指导的原则？
3. 灵活性
 23）是否可以使用命令语言而绕过菜单的选择？
 24）系统是否有直接操作的功能？
 25）数据输入的设计是否灵活？
 26）用户是否可以灵活地控制显示？
 27）系统是否提供了灵活的流程控制？
 28）系统是否提供了灵活的用户指导？
 29）菜单选项是否前后相关？
 30）用户是否可以根据他们的需要来命名显示和界面单元？
 31）系统是否为不同的用户提供了好的训练？
 32）用户是否可以自己改变视窗？
 33）用户是否可以自己命名系统命令？
 34）系统是否允许用户选择需要显示的数据？
 35）系统是否可以提供用户指定的视窗？
 36）为了扩展显示功能，系统是否提供放大的功能？
4. 可学习性
 37）用词是否清晰？
 38）数据是否有合理的分类，易于学习？
 39）命令语言是否有层次？
 40）菜单的分组是否合理？
 41）菜单的顺利是否合理？
 42）命令的名字是否有意义？
 43）系统是否提供了无惩罚的学习？
5. 极少化的用户动作
 44）系统是否为相关的数据提供了组合输入的功能？
 45）必要的数据是否只需要输入一次？
 46）系统是否提供了默认值？
 47）视窗之间的切换是否容易？
 48）系统是否为经常使用的控制提供了功能键？
 49）系统是否有全局搜索和替代的功能？
 50）菜单的选择是否可以使用点击的功能？（主要的流程控制方法）
 51）菜单的选择是否可以使用键入的功能？（辅助的控制方法）
 52）系统是否要求极少的光标定位？
 53）在选择菜单时，系统是否要求极少的步骤？
 54）系统是否要求极少的用户控制动作？
 55）为了退到更高一级菜单中，系统是否只需要一个简单的键入动作？
 56）为了退到一般的菜单中，系统是否只需要一个简单的键入动作？
6. 极小的记忆负担
 57）系统是否使用了缩写？
 58）系统是否为输入分层次的数据提供了帮助？
 59）指导信息是否总是可以得到的？
 60）系统是否为序列的选择提供了分层次的菜单？
 61）被选的数据是否有突出显示？
 62）系统是否为命令提供了索引？
 63）系统是否为数据提供了索引？
 64）系统是否提示在菜单结构中的当前位置？
 65）数据是否保存简短？
 66）为选择菜单使用的字母代码是否经过认真的设计？
 67）是否将长的数据分成不同的部分？
 68）先前的答案是否可以简便的再利用？
 69）字母大小写是否等同？
 70）系统是否使用短的代码而不使用长的代码？
 71）图符是否有辅助性的字符标号？
7. 知觉的有限性
 72）系统是否为不同的数据类别提供不同的编码？
 73）缩写是否清晰而相互不同？
 74）光标是否不同？
 75）界面单元是否清晰？
 76）用户指导的格式是否清晰？
 77）命令是否有清晰的意义？
 78）命令的拼写是否清晰？
 79）系统是否使用了易于分辨的颜色？
 80）目前活动的窗口是否有清楚的标识？
 81）为了直接比较，数据是否成对的摆在一起？
 82）是否限制语音信息使用的数量?
 83）系统是否提供了一系列相关信息？
 84）菜单是否和其他的显示信息有明显的区别?
 85）颜色的编码是否多余？
 86）系统是否提供了视觉上清晰可辨的数据字段？
 87）不同组的信息是否明显分开？
 88）屏幕的密度是否合理？
8. 用户指导
 89）系统反馈的错误信息是否有用？
 90）系统是否提供了“取消”的功能？
 91）错误的输入是否被显示出来？
 92）系统是否提供了明确的改正错误的方法？
 93）系统是否为控件输入提供了反馈？
 94）是否提供了“帮助”
 95）一个过程的结束是否标志清楚？
 96）是否对重复的错误有提示？
 97）错误信息是否具有建设性并提供有用的信息？
 98）系统是否提供了“重新开始”的功能？
 99）系统是否提供了“撤销”的功能？
 100）用户是否启动流程控制？

转自:http://www.dtell.net/article.asp?id=37

相关文章

• 用rsync对网站进行镜像备份 (0)
• 常用的HR相关英文词汇 (1)
• 什么是bootloader程序及其功能和特点 (0)
• 一个有关用户体验的文章 (0)
• [转]嵌入式系统 Boot Loader 技术内幕 (0)

：）

不过因为封装得太多了，以至于程序运行效率有些下降，但是比起其它的语言还是很快。

相关文章

• Tim Bray 又有惊人之语：PHP比Java更具有伸缩性 (0)
• PHP5 效率优化 (0)
• 翻译：On having layout (0)
• 大型高并发高负载网站的系统架构 (0)
• 各系Rails大点兵 (0)

当你希望访问者每次都刷新你广告的图标，或每次都刷新你的计数器，就要禁用缓存了。通常HTML文件没有必要禁用缓存，对于ASP等页面，就可以使用禁用缓存，因为每次看到的页面都是在服务器动态生成的，缓存就失去意义。如果网页过期，那么存盘的cookie将被删除。
　　　用法：<Meta http-equiv="Set-Cookie" Content="cookievalue=xxx; expires=Wednesday, 21-Oct-98 16:14:21 GMT; path=/">
　　　注意：必须使用GMT的时间格式。
　　6、Window-target (显示窗口的设定)
　　　说明：强制页面在当前窗口以独立页面显示。
　　　用法：<Meta http-equiv="Widow-target" Content="_top">
　　　注意：这个属性是用来防止别人在框架里调用你的页面。Content选项：_blank、_top、_self、_parent。
　　7、Pics-label (网页RSAC等级评定)
　　　说明：在IE的Internet选项中有一项内容设置，可以防止浏览一些受限制的网站，而网站的限制级别就是通过该参数来设置的。
　　　用法：<META http-equiv="Pics-label" Contect="(PICS－1.1′http://www.rsac.org/ratingsv01.html’ I gen comment ‘RSACi North America Sever’ by ‘inet@microsoft.com’　for ‘http://www.microsoft.com’ on ‘1997.06.30T14:21－0500′ r(n0 s0 v0 l0))">
　　　注意：不要将级别设置的太高。RSAC的评估系统提供了一种用来评价Web站点内容的标准。用户可以设置Microsoft Internet Explorer（IE3.0以上）来排除包含有色情和暴力内容的站点。上面这个例子中的HTML取自Microsoft的主页。代码中的（n 0 s 0 v 0 l 0）表示该站点不包含不健康内容。级别的评定是由RSAC，即美国娱乐委员会的评级机构评定的，如果你想进一步了解RSAC评估系统的等级内容，或者你需要评价自己的网站，可以访问RSAC的站点：http://www.rsac.org/。
　　8、Page-Enter、Page-Exit (进入与退出)
　　　说明：这个是页面被载入和调出时的一些特效。
　　　用法：<Meta http-equiv="Page-Enter" Content="blendTrans(Duration=0.5)">
　　　　　　<Meta http-equiv="Page-Exit" Content="blendTrans(Duration=0.5)">
　　　注意：blendTrans是动态滤镜的一种，产生渐隐效果。另一种动态滤镜RevealTrans也可以用于页面进入与退出效果:
　　　　　　<Meta http-equiv="Page-Enter" Content="revealTrans(duration=x,transition=y)">
　　　　　　<Meta http-equiv="Page-Exit" Content="revealTrans(duration=x,ransition=y)">
　　　　　　　Duration　　表示滤镜特效的持续时间(单位：秒)
　　　　　　　Transition　滤镜类型。表示使用哪种特效，取值为0-23。
　　　　　　　0 矩形缩小　　　　　　　1 矩形扩大
　　　　　　　2 圆形缩小　　　　　　　3 圆形扩大
　　　　　　　4 下到上刷新　　　　　　　5 上到下刷新
　　　　　　　6 左到右刷新　　　　　　　7 右到左刷新
　　　　　　　8 竖百叶窗　　　　　　　9 横百叶窗
　　　　　　 10 错位横百叶窗　　　　　　 11 错位竖百叶窗
　　　　　　 12 点扩散　　　　　　 13 左右到中间刷新
　　　　　　 14 中间到左右刷新　　　　　　 15 中间到上下
　　　　　　 16 上下到中间　　　　　　 17 右下到左上
　　　　　　 18 右上到左下　　　　　　 19 左上到右下
　　　　　　 20 左下到右上　　　　　　 21 横条
　　　　　　 22 竖条　　　　　　 23 以上22种随机选择一种
　　9、MSThemeCompatible (XP主题)
　　　说明：是否在IE中关闭 xp 的主题
　　　用法：<Meta http-equiv="MSThemeCompatible" Content="Yes">
　　　注意：关闭 xp 的蓝色立体按钮系统显示样式，从而和win2k 很象。
　　10、IE6 (页面生成器)
　　　说明：页面生成器generator，是ie6
　　　用法：<Meta http-equiv="IE6" Content="Generator">
　　　注意：用什么东西做的，类似商品出厂厂商。
　　11、Content-Script-Type (脚本相关)
　　　说明：这是近来W3C的规范，指明页面中脚本的类型。
　　　用法：<Meta http-equiv="Content-Script-Type" Content="text/javascript">
　　　注意：
※NAME变量
　　name是描述网页的，对应于Content（网页内容），以便于搜索引擎机器人查找、分类（目前几乎所有的搜索引擎都使用网上机器人自动查找meta值来给网页分类）。
　　name的value值（name=""）指定所提供信息的类型。有些值是已经定义好的。例如description(说明)、keyword(关键字)、refresh(刷新)等。还可以指定其他任意值，如：creationdate(创建日期) 、document ID(文档编号)和level(等级)等。
　　name的content指定实际内容。如：如果指定level(等级)为value(值)，则Content可能是beginner(初级)、intermediate(中级)、advanced(高级)。
　　1、Keywords (关键字)
　　　说明：为搜索引擎提供的关键字列表
　　　用法：<Meta name="Keywords" Content="关键词1,关键词2，关键词3,关键词4,……">
　　　注意：各关键词间用英文逗号“,”隔开。META的通常用处是指定搜索引擎用来提高搜索质量的关键词。当数个META元素提供文档语言从属信息时，搜索引擎会使用lang特性来过滤并通过用户的语言优先参照来显示搜索结果。例如：
　　　　　　<Meta name="Kyewords" Lang="EN" Content="vacation,greece,sunshine">
　　　　　　<Meta name="Kyewords" Lang="FR" Content="vacances,grè:ce,soleil">
　　2、Description (简介)
　　　说明：Description用来告诉搜索引擎你的网站主要内容。
　　　用法：<Meta name="Description" Content="你网页的简述">
　　　注意：
　　3、Robots (机器人向导)
　　　说明：Robots用来告诉搜索机器人哪些页面需要索引，哪些页面不需要索引。Content的参数有all、none、index、noindex、follow、nofollow。默认是all。
　　　用法：<Meta name="Robots" Content="All|None|Index|Noindex|Follow|Nofollow">
　　　注意：许多搜索引擎都通过放出robot/spider搜索来登录网站，这些robot/spider就要用到meta元素的一些特性来决定怎样登录。
　　　 all：文件将被检索，且页面上的链接可以被查询；
　　　 none：文件将不被检索，且页面上的链接不可以被查询；(和 "noindex, no follow" 起相同作用)
　　　 index：文件将被检索；（让robot/spider登录）
　　　 follow：页面上的链接可以被查询；
　　　 noindex：文件将不被检索，但页面上的链接可以被查询；(不让robot/spider登录)
　　　nofollow：文件将不被检索，页面上的链接可以被查询。(不让robot/spider顺着此页的连接往下探找)
　　4、Author (作者)
　　　说明：标注网页的作者或制作组
　　　用法：<Meta name="Author" Content="张三，abc@sohu.com">
　　　注意：Content可以是：你或你的制作组的名字,或Email
　　5、Copyright (版权)
　　　说明：标注版权
　　　用法：<Meta name="Copyright" Content="本页版权归Zerospace所有。All Rights Reserved">
　　　注意：
　　6、Generator (编辑器)
　　　说明：编辑器的说明
　　　用法：<Meta name="Generator" Content="PCDATA|FrontPage|">
　　　注意：Content="你所用编辑器"
　　7、revisit-after (重访)
　　　说明：
　　　用法：<META name="revisit-after" CONTENT="7 days" >
　　　注意：
※Head中的其它一些用法
　　1、scheme (方案)
　　　说明：scheme can be used when name is used to specify how the value of content should
　　　　　　be interpreted.
　　　用法：<meta scheme="ISBN" name="identifier" content="0-14-043205-1" />
　　　注意：
　　2、Link (链接)
　　　说明：链接到文件
　　　用法：<Link href="soim.ico" rel="Shortcut Icon">
　　　注意：很多网站如果你把她保存在收件夹中后，会发现它连带着一个小图标，如果再次点击进入之后还会发现地址栏中也有个小图标。现在只要在你的页头加上这段话，就能轻松实现这一功能。<LINK> 用来将目前文件与其它 URL 作连结，但不会有连结按钮，用於 <HEAD> 标记间， 格式如下：
　　　　　　　<link href="URL" rel="relationship">
　　　　　　　<link href="URL" rev="relationship">
　　3、Base (基链接)
　　　说明：插入网页基链接属性
　　　用法：<Base href="http://www.csdn.net/" target="_blank">
　　　注意：你网页上的所有相对路径在链接时都将在前面加上“http://www.cn8cn.com/”。其中

target="_blank"是链接文件在新的窗口中打开，你可以做其他设置。将“_blank”改为“_parent”是链接文件将在当前窗口的父级窗口中打开；改为“_self”链接文件在当前窗口（帧）中打开；改为“_top”链接文件全屏显示。

<head>　　
<title>文件头，显示在浏览器标题区</title>
<meta http-equiv="Content-Language" content="zh-cn">
　<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
　<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
　<meta name="ProgId" content="FrontPage.Editor.Document">
　<meta name="制作人" content="Simonzy">
　<meta name="主题词" content="HTML 网页制作 C# .NET JavaScript JS">
</head>

以上是META标签的一些基本用法，其中最重要的就是：Keywords和Description的设定。为什么呢？道理很简单，这两个语句可以让搜索引擎能准确的发现你，吸引更多的人访问你的站点!根据现在流行搜索引擎(Google，Lycos，AltaVista等)的工作原理，搜索引擎先派机器人自动在WWW上搜索，当发现新的网站时，便于检索页面中的Keywords和Description，并将其加入到自己的数据库，然后再根据关键词的密度将网站排序。

相关文章

• flickr对javascript干的好事 (0)
• 翻译：On having layout (0)
• 有漏洞的Web 2.0 (0)
• 大型高并发高负载网站的系统架构 (0)
• 二十一世纪让人悲伤的七个原因 (0)

在茫茫的框架之海认出一个Rails框架，基本上靠四个特征
1.一门动态语言
2.一个extreme simple to use的ORM框架
3.一个extreme simple to use的MVC框架
4.一些自动生成代码的命令、模版
其余ajax、web service、i18n等特性自由扩展

1.Ruby: Ruby on Rails
Rails系的旗手，一己之力搞得J2EE阵营鸡飞蛋打。
旗手的作用表现在：
*最接近1.0的版本，目前已出到最后一个RC版 1.0 rc4(0.14.3)
*拥有一本amazon超级畅销的《Agile Web Development with Rails》，而且这本书的组织也好，part I是一个渐进的sample application 让你快速入门，partII是几个重要领域的深入介绍。
*拥有自己的IDE: RadRails ，基于Eclipse但独立成军，目前出到0.5。(是不是怕惨了Eclipse的多变，现在这些IDE的发行版本开始反包含了Eclipse在内。)

2.Python: DJango、turbogears
认识不深，所以DJango请看limodou的blog，turbogears看xlp123的。

3.Groovy: grails
如果能顺产，绝对是J2EE阵营里感情分最高涨的项目。因为它语言用Groovy，ORM用annotation版Hibernate，MVC用Spring。不用担心它换汤不换药，因为经过extreme的封装，再结合Groovy，绝对不再是原来的Spring+Hibernate，而是和RoR差不多的一样东西了。不信可以看看他的Sample。
不过这个项目的源码目录树非一般的乱，也还没有0.1版释出。还有一样奇怪的事情，这个Groovy项目，大多数的class代码都是Java写的。

4.Php: symfony ,cake
据说cake比symfony弱非常多，所以没看。
symfonys是基于php5的项目，成功整合了Propel(ORM)、Mojavi3(MVC)，再配合自动生成的脚本打造而成。看他的sample，最后整合出来的东西也很Rails了，除了ORM层的xml文件。
还有一个发现是Php项目现在可以用pear来安装，很像Ruby的gem，Java的Maven要努力了。
C: />pear channel-discover pear.symfony-project.com
C: />pear install symfony/symfony
这样就装完了symfonys和propel&croel, mojavi3,还有用来运行脚本命令的pake(php make)，PHing(php ant?)，一大堆东西。

from :http://www.blogjava.net/calvin/archive/2005/11/22/20938.html
author:江南白衣

相关文章

• 免费软件套装 (0)
• Tim Bray 又有惊人之语：PHP比Java更具有伸缩性 (0)
• PHP & memcached (0)
• 翻译：On having layout (0)
• 搜索关键字 (0)

什麼是REST?

REST 是一種分散式超媒體系統(如WWW)的軟體架構風格，你可以想像它是一個良好設計的Web應用程式規則: 一組網路Web頁面(虛擬的狀態機器)，其中 Client 透過點選超連結(狀態變換)，結果是下個Web頁面(表示應用程式的下一個狀態)。

REST 所描述的網路系統包括三個部份:
data elements (resource, resource identifier, representation)
connectors (client, server, cache, resolver, tunnel)
components (origin server, gateway, proxy, user agent)

幾個重點:
Data elements 由標準化介面存取
Components 透過介面傳輸 資源表徵 (representations of resources) 來溝通，而不是直接操作資源本身。
Connectors 提供 component 的抽象介面來溝通，隱藏溝通機制的實作細節。
Components 使用 connectors 來存取，connectors 提供資源的存取或居中。
所有來自 connector 的 requests 必須包含所有必要的資訊來了解該 request，不需要依靠之前的request (即 stateless)

嚴格來說REST符合以下幾個條件:
應用程式的狀態跟功能拆成 resources
每個 resource 使用獨一無二用來當作超連結的通用定位語法(在WWW中即URI)
所有 resources 共用一致的介面在 client 跟 resource 之間轉換狀態，包括:
一組有限的良好定義操作 well-defined operations
一組有限的內容格式 content types,也許包括 可執行的程式碼 code-on-demand (在WWW中即Javascript)
這種通訊協定 protocol (在WWW中即用HTTP) 包含以下特色:
使用者端/伺服器端 Client/Server
狀態無關 Stateless
可以快取 Cacheable
分層的 Layered

符合 REST principles 的系統稱做 RESTful。

一般來說REST這個詞彙常被用來描述任何使用XML (or YAML, JSON, plain text) 的簡單介面，而不須靠其他機制(如SOAP)。另外 REST 雖然是個來自 WWW 的架構概念(比WWW晚)，但是這兩者並不是綁在一起，有可能設計一個大型軟體系統符合REST但是不用HTTP協定也不需跟WWW互動，也有可能設計一個簡單的 XML+HTTP 界面使用 RPC model 而不符合 REST principles。

Resources

REST的一個最重要的觀念就是 resources (特定資訊的資源)，每一個 resource 由一個 global identifier (即URI)所表示。為了操作這些 resources，網路的 components (即 clients 跟servers) 透過標準化的介面 (即HTTP) 來溝通並交換這些 resources 的 representations (即實際上傳達資訊的文件).

任意數量的 connectors (如clients, servers, caches, tunnels等) 可以居中 request，但是都不可以 “seeing past” (不需要其他 layer層)。這樣的應用程式跟一個 resource 互動根據兩件事情: resource的URI 跟 要做的動作 – 它不需要知道是否有 caches, proxies, gateways, firewalls, tunnels, 或其他任何藏在sever之間的東西。這個應用程式只需要知道資訊的格式 (representation)，通常是 HTML或 XML 或圖片什麼的。

REST 有什麼優點?
支援快取 caching 將改善反應時間跟server的負載能力。
因為不必維持連結狀態，大大改善 server 的 scalability 能力。這表示不同server可以處理同一串 requests。
一個瀏覽器就可以存取任一應用程式跟資源，client 端不需使用別的軟體。
在HTTP之上不依存其他機制跟軟體。
跟其他連結方式相比(如RPC)，可以提供相等的功能。
不需要其他的 discovery 機制，因為使用超連結了。
提供比RPC更好的長期相容性，因為 :
如同HTML這種文件具有後前及向後的相容能力
支援新的內容格式不需要丟掉舊的

另外比起RPC-style，URL command line 有極佳的 human-friendly 優點，容易 discovered/ transmitted /scripted/bookmarked 一個 URL。請參考 The Beauty of REST 跟 Tangled in the Threads 的優點介紹。

跟 RPC 的比較

跟 REST Web 應用程式對比的就是 RPC (Remote procedure call，實作上有XML-RPC或SOAP等) 了。RPC 應用程式曝露一或多個網路物件，每個有特定的 functions 可以呼叫。在 client 與物件溝通之前，它必須知道這個物件的知識來操作。

REST 的設計限制了 resource 的面向，它定義了介面 (動詞 verbs 跟內容型別 content types)，導致比RPC更少的型別，但是更多的resource identifiers (名詞nouns)。REST 的設計尋求定義一組 resources 讓 Clients 可以一致性的互動，而且提供超連結在資源之間可以瀏覽，而不需要了解整個 resources 的知識 。Server 提供的表單 forms 也可以被用在 RESTful 的環境來描述 clients 如何建構 URL 來跟特定的resource做溝通。

這張圖指出了REST的三位一體 : Nouns, 有限的 Verbs 跟 Content Types。

需注意的是，根據不同的用法要求跟效率，在不同的應用程式環境中，該使用哪種架構仍有很大討論的空間跟爭議(SOAP的支持者認為REST仍有其侷限，只適合簡單的應用)。REST的重要性在於它有個目前最成功的大型軟體架構應用: Wide World Web。RESTful 是 Web 的天性，也是讓 Web 成功的原因，因此 RESTful 的支持者認為使用 RESTful 架構就是 Web上最好的方法來做到有擴充性(scalable),彈性跟有威力的應用程式。在有這麼多複雜的RPC技術之後，REST因其簡單又有威力的架構近來越來越受到矚目跟重視。

舉例

一個 RPC 應用程式可能會定義以下的操作:

getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()

Client 的程式碼可能會這樣存取:

exampleAppObject = new ExampleApp(”example.com:1234″)
exampleAppObject.getUser()

在 REST中，重點在 resources(或稱作 nouns)的多樣性，比如說可能有以下的用法:

http://example.com/users/
http://example.com/users/{user} (one for each user)
http://example.com/findUserForm
http://example.com/locations/
http://example.com/locations/{location} (one for each location)
http://example.com/findLocationForm

Client 的程式碼可能這樣存取:

userResource = new Resource(http://example.com/users/001)
userResource.get()

每個 resource 擁有自己的識別名詞，而 Clients 從單一 resource 開始瀏覽，透過標準操作走訪 resource ，如 GET 下載，PUT更新，DELETE刪除，POST新增，注意到每個物件有自己的URL，而且可以容易被快取，複製跟書籤化(bookmarked)。

參考資源
Representational State Transfer
RestWiki
How to Create a REST Protocol

From :http://ihower.idv.tw/blog/archives/1542

相关文章

• PHP & memcached (0)
• google背后的分布式架构 (0)
• flickr对javascript干的好事 (0)
• 解决 AJAX 跨域方案一(PHP Proxy) (0)
• 翻译：On having layout (0)