Walleve | 理想就像内裤,要有,但不能逢人就去证明你有

@转载 http://blog.csdn.net/21aspnet/archive/2008/12/19/3558455.aspx 一，不要过设计：never over design 这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。 ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构 web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的 二，web架构生命周期：web architecture‘s life cycle 既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你  [attach=43] 所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长 google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的 –待添加

web效率，yahoo性能小组总结的这14条规则 Make Fewer HTTP Requests Use a Content Delivery Network Add an Expires Header Gzip Components Put CSS at the Top Move Scripts to the Bottom Avoid CSS Expressions Make JavaScript and CSS External Reduce DNS Lookups Minify JavaScript Avoid Redirects Remove Duplicate Scripts Configure ETags Make Ajax Cacheable   翻译下？太多E了，有些看不懂，回头找词典翻一下

终于领略那一句话了，所有的技术屏障都有解决的办法_ 1、问题的重要性 2、解决得办法 3、造成的后果 思考和行动是相互的，如果我们的行动需要迅速，那么留给我们思考的余地很少，唯一能做的是在已经出现的办法前面选择一个或者尽快想一个最快的办法来迅速的投入行动中去。同理，如果我们需要谨慎行事，那么我们就需要将思维扩散出去，把所有的情况容纳进来，利用“负载均衡”的原理来考虑下一步的行动。 如果没有比当前更好的办法，我们要做的是选择。而一旦有比目前要好的方法，我们要做的是应用，如果留给我们充足的时间，我们要做的是超越。 – 关键字说明一切_外：如何优化

要禁用后退的话，在每个页面的顶部加上脚本： history.forward();

SQL Select语句完整的执行顺序【转】 1、from子句组装来自不同数据源的数据；  2、where子句基于指定的条件对记录行进行筛选；  3、group by子句将数据划分为多个分组；  4、使用聚集函数进行计算；  5、使用having子句筛选分组；  6、计算所有的表达式；  7、使用order by对结果集进行排序。 举例说明: 在学生成绩表中 (暂记为 tb_Grade), 把 "考生姓名"内容不为空的记录按照 "考生姓名" 分组, 并且筛选分组结果, 选出 "总成绩" 大于 600 分的. 标准顺序的 SQL 语句为: Select 考生姓名, max(总成绩) as max总成绩 from tb_Grade where 考生姓名 is not null group by 考生姓名 having max(总成绩) > 600 order by max总成绩 在上面的示例中 SQL 语句的执行顺序如下: (1). 首先执行 FROM 子句, [...]