最近有网友反馈CSDN的一个bug，某个CSDN帖子点击它里面的举报功能链接会报404错误，其他帖子则没有这个问题。这个点击链接如下：
http://forum.csdn.net/PointForum/Forum/Report.aspx?topicId=cc0b49bf-d6e8-4645-bf34-45f6e68bc569&postDate=2009-10-17&url=http%3A%2F%2Ftopic.csdn.net%2Fu%2F20091017%2F17%2Fcc0b49bf-d6e8-4645-bf34-45f6e68bc569.html&content=%E8%B5%9A%E9%92%B1%E6%95%88%E5%BA%94----%3E%E8%8D%90%E8%82%A1%E5%91%A8%E8%B5%9B%EF%BC%81%E8%83%BD%E8%B5%9A%E9%92%B1%E8%83%BD%E8%8E%B7%E7%A7%AF%E5%88%86%EF%BC%81
通过分析原因，发现是因为这个链接中有“>”这个字符所致。上述链接中的“%3e” 就是“>”字符。删除这个字符就一切都好了。
一些简单的其他ASP.net站点的演示这个错误的地址：
http://s.mybook66.com/Chapter.aspx?id=273>
http://s.mybook66.com/Chapter.aspx?id=273%3e
http://www.microsoft.com/downloads/details.aspx?FamilyID=CF13EA45-D17B-4EDC-8E6C-6C5B208EC54D%3e&displaylang=en
http://msn.qidian.com/ShowBook.aspx?bookid=1266402>
这个问题只有IIS才有，
Visual Studio 开发站点：ASP.net Development Server，Apache 我都没有发现这个问题存在。
并不是所有的Get参数值上增加“>”都会导致404错误，有些会，有些又不会，目前我还没有找出规律。
System.Web.HttpUtility.UrlEncode(">") 会输出 “%3e”，不论“>”还是“%3e” 在这个问题存在时，都会导致404错误。
昨天公司开年会，蒋涛给优秀部门颁奖的时候，竟然放的是《士兵突击》中的“征服天堂”（英文名：Vangelis conquest of paradise ）这首歌，我极度不好受，因为钢七连解散的时候，也是放的这首歌，现社区中心组织结构调整，去年我所带领的这个组，社区二组已经口头宣布解散，就差正式宣布解散时，也是放的这首歌。
昨天我强烈的感受到钢七连解散时，连长高城看到手下一个个兵被分走的那种感觉。最近一直没写博客，受这种心情影响是一个很重要的原因。
2008年初，公司组织结构调整，开发和运营合并成一个个团队，我所带领的这个团队主要负责CSDN论坛有关的开发和运营。我们想做的东西很多，但是人员有限，我们只做最有价值的。
另外一个原则是开发不能只闷头作开发，我们的产品正好是给开发人员用的论坛，如果我们自己的开发人员都不用自己的产品，只能说我们的产品作的非常垃圾，基于这个原则，开发人员的工作都没有安排得很满，让他们上班时间有时间使用论坛。大家都想出很多很有价值的点子，其中的不少就在08年实现了。
这些原则贯穿了整年，这也是我们能超额完成指标，并被评为优秀团队的根本原因。
我非常感谢我们社区二组的组员，李家佳，岳笑南，田彗星，柴丽华，周兆成，王集鹄，通过我们大家的努力，让我们无愧于“团队进步奖”。不但小组的年度目标超额完成，而且还获得了最佳团队奖。谢谢大家，让我们团队有一个很圆满的结局。现在我们组的每个人都被分配到不同的团队了，他们在每个团队中都是顶梁柱，我很自豪，我们团队出来的都是牛人。
昨天，由Sisley Lin 处得知，我将被推荐成了“十大杰出开发技术英雄”候选人之一，有点激动。推荐的理由是我为CSDN 这个最大的中文技术社区的成长所贡献的这些年。当我回首看自己在CSDN经历时，发现自己已为CSDN公司工作了7年半，在CSDN 论坛活动了8年。蓦然回首，八年光阴已匆匆而过，心中真是感慨万千呀。
记得那是在99年底，2000年初时，我从大学毕业刚半年，跟随一个我的铁哥们跳槽到一家新成立的电子商务的网站（http://www.ego88.com/， 不过这个网站现在已经无法访问了）。由于之前我是在一家使用Delphi开发ERP，医院信息系统的公司，我对Delphi非常感兴趣，当时最常去的就是大富翁论坛（http://www.delphibbs.com/）。经这次跳槽后，由于转行做网站，就开始学习ASP技术。在大富翁论坛时，听说新开了一个程序员的论坛CSDN，而CSDN有个板块在讨论ASP，于是乎，就整天泡CSDN论坛的ASP版，边学习，边帮别人解答问题。慢慢的，自己的ASP水平也提高起来了，后来就成了ASP版的最早一任版主。那时候，也达到了自己在CSDN专家榜的最高排名——CSDN总专家榜排名13。
2000年6月时，由于我在EGO88网站经常跟技术经理发生技术争执，被开除了。痛定思痛之后，我决定离开杭州，来北京发展，没想到这次离开成了我人生的转折点。恰巧当时CSDN网站刚刚被百联集团收购，准备扩展业务，正在不断招纳新人，于是我便和曾登高联系了一下， 7月15日就来到了北京，从此就开始了我为CSDN网站工作的历程。
还记得当时CSDN公司在亚运村，就是现在鸟巢的位置，而我就租住在旁边的惠忠北里小区。每天早上，我都从小区出来，向北跑步，就是现在的大屯路一带，全是麦田和菜地。不想经过这五六年的发展，现在这一片的房价均价已达到一万元以上…….
我在CSDN负责的第一个项目是文档中心（http://dev.csdn.net/ 现在这里已经不归我负责了，也不是我当初做的那个风格了），就是现在博客的前身，不知道还有多少人记得这个产品。当时为了测试和运作文档中心，我从2000年7月开始，疯狂转贴了很多文章。而文档中心文章在升级成博客后，全部迁移到博客中了，这还一度造成我的博客发文数是第一。
随后，在从事了其他一些小的工作后，我就接手了CSDN论坛，当时那一版本的论坛仍然是ASP开发的，采用了双缓存机制，同时静态帖子采用了XML+XSL技术。说起来你可能不相信，那一个版本的论坛是完全由我一个人开发完成的。 那可是单枪匹马闯五关的时代呀，由于我最早使用XML技术，最初时有些技术难题没能解决，一度被Boss批判说，不要使用不成熟的技术。2003年时，就是我创建的这个版本的论坛达到了历史最高在线人数，同时发帖量，回复量都相当高。要知道，当时的论坛只是两台服务器，一台WEB，一台数据库。当时服务器的配置也只是2G内存+双CPU，志强2.4G，能做到那个成绩实属不易。
04年是非常郁闷的一年，现在看来，04年忙忙碌碌的开发了很多项目，但是这些项目都荒废了，不再看得到了。03年下半年开始，我开发的项目都转到ASP.net 技术了，虽然这些项目最终由于运维等原因，流产了，但是至少也算是从那时候开始对.net 技术有了较深的了解吧。
05年的时候，已经开始基于.net技术开发新版论坛了。但是，由于不受公司重视，开发到一半竟被中止，把人员抽调到其他项目，使得无法继续。直到06年的时候，由于论坛在03年9月达到高峰后，一直走下坡路，公司终于决定在论坛方面增大力度。而新的论坛开发已经不再是单枪匹马就可以搞定的了，需要团队协作，而组建的团队又问题多多，磕磕碰碰后，终于在06年底发布了群组。群组使用的是跟论坛一样的底层架构。之后采用里程碑增量开发模式，终于在07年9月28日，把所有老论坛升级到了新版论坛。之后，就是一系列功能的补充完善，优化。随着公司投入力量的加强，我预计，也希望08年论坛又会象03年一样，达到一个新的高峰。
回首过去这八年，我很感谢CSDN为我提供了一片成长的平台。CSDN伴着我成熟，我也见证了CSDN的成长。随着CSDN的不断改进，我自己也从菜鸟成长起来。我的角色也从最初的程序员变成高级程序员，再变成开发经理。（我在CSDN注册时的ID是4807，也就是我之前CSDN用户只有 不到5000个，而截至2007年底，CSDN注册用户已经达到250万多了。）这些成长都是通过自己的努力来实现的。一分耕耘，一分收获，我在CSDN实现了我的第一个“孩子之梦”……
CSDN 论坛有很多有意思的故事。比如：女英雄无为；彭大力追旋玑；拉萨mm挖EDYang的故事等等，而这一个个故事都发生在自己一手搭建的论坛平台上，其中的成就感不言而喻。这也是我能在CSDN这家公司工作7年多的根本原因，我已经把它当成了我生活的一部分，无法割舍。
八年时光，弹指即过，人生能有几个八年？八年时间我做了不少事情，但仅凭一手搭建了CSDN论坛这个平台，此八年不算虚度。希望未来的八年，我的程序员人生将更加精彩。
仅以本文来怀念我患得患失的八年。
郭红俊
2008年1月10日 星期四 于北京
附，微软开发技术英雄，IT技术英雄的投票地址在 http://www.microsoft.com/zh/cn/default.aspx 的最大的那个flash 广告。 具体地址就是：http://www.hhhchina.net/ 。 需要在中国地图上找到某个人才可以投票，郁闷的是，竟然地图上把我丢到内蒙了。
拉票了，大家都来投我一票啦！^&^
先来听我说几个真实的故事：
上周面试了一个开发人员，这个人所有的面试题都答出来了。各方面我们需要的知识也掌握了，但是在初试中，这个人就被我们三个面试官一并否决了。 原因很简单，这个面试者提供的答案都是能解决问题，但几乎都是效率最差的方案；另外，从一些面试题中，可以看出这人很多时候，把开发工作当成一个应付差事的工作来做，而不是作为自己的兴趣来做。缺乏激情，工作只是应付差事，仅仅是由于有几年工作经验，才能答出我们的面试题。这样的人不要也罢。
另外一个故事，公司有个开发组，在他们组发生过这样一件事情：有次在一个界面布局文档中，有几个很明显的错别字。提交到某个开发人员那里后，开发人员在知道是错别字的前提下，不跟其它相关人员沟通，在WEB页面上，仍然采用了这个错别字。
再一个面试中听到的故事：在问面试者为何离开前一个公司的时候，有个面试者说了这样一种情况，一个10个多人的开发团队，忙了一年，产品还没有上线，需求还在因为Boss的灵感不断，还在不断修改中，最后他觉得对这个项目和这个公司失去了激情，为此他决定寻找新的工作机会。
种种原因，没能或不再把编程工作当作一种乐趣，没有成就感，这是上面三个故事产生的根源。这是我的看法。
不仅仅程序，编程系统产品在焦油坑中苦苦挣扎，程序员们也在焦油坑中苦苦挣扎。下图是人月神话第一章的插图：拉布雷阿的焦油坑壁画(Mural of La Brea Tar Pits)。我们每个人都象其中的动物一样，时时刻刻陷身在焦油坑中，都在苦苦的挣扎中。
说自己陷身焦油坑，有这个，哪个苦恼。谁没有苦恼，人在各个阶段都会有大量的苦恼存在，在苦恼中仍然有激情，这才是重要。
有时候，我就在关注身边的程序员，去想他们为何会有这样、那样的行为发生。分析的其中一个结果就是：程序员的水平差别很大程度是看他是否有编程的激情。
比如：刚毕业的大学生，差的，好的我都看到过，好的一个在还有半年才毕业的时候，就被我拉到公司工作了（这个人后来由于想自己创业，离职了，不过这个人的激情我非常佩服）。而差的，在面试中一些非常简单问题的答题，让我差点吐掉。要知道，我面试刚毕业者，一般不是考具体应用，而是重点考察算法、数据结构的简单知识，而这些知识，大学里是必修的。
有哪些方面可能成为程序员有激情的原因？
在人月神话的第一章《焦油坑》中提到编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”提供了五种乐趣：
- 创造事务的快乐；
- 开发对其它人有用的东西的乐趣；
- 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力；
- 面对不重复的任务，不断学习的乐趣；
- 工作在如此易于驾驭的介质上的乐趣--纯粹的思维活动--其存在、移动和运转方式完全不同于实体物件；
从我的角度来理解，就是以下两个方面：
- 编程的结果导致的激情，包括创造事务，以及创造的事务被其它人认可。
- 编程的过程，把一行行代码组装成一个功能强大的产品，组装中引入自己正在关注的一些技术，算法，模式。这个算法是我设计的，为此带来的一系列乐趣。
编程的结果和过程，很多时候受制于其它人的。这时候必然会对你在这方面的乐趣产生限制。
越是大公司，越是大型的系统，这种限制越多。另外，日企的严格开发规范，我觉得是对这些限制达到极致的表现。所以我个人肯定不会去日企。也不建议去日企。有些技术牛人，没有去大企业，可能的一个原因是因为他想把自己这些编程乐趣保留在一个更大的范围。
另外，微软开发流程我知道的可能比较多点。我就说说我对微软开发中的乐趣说说我的看法，毕竟我不在微软，可能不一定对。
1、我觉得在微软开发团队，测试人员的开发乐趣比开发人员的开发乐趣要更多。
开发人员需要有产品经理的各种文档作限制，他的最大开发乐趣可能是在设计各种更优秀的算法来保证界面功能可用。
而测试人员则需要用各种工具（包括自己开发的，使用脚本等）来测试各种场景。比如我挺佩服的施凡，有段时间，他为了测试Live Meeting，自己在设计写个语音机器人，来完成这个测试。
2、工作产品被很多人使用的成就感，这点大家应该都很明白，就不细说了。
上面说的是针对个人的编程激情，很多时候，周围人的习惯会影响你也会慢慢具有这个习惯，这就是团队，环境在潜移默化的感染者您。
如何让团队保持激情？
以下只是我个人的看法，并不一定使用于你的环境。
1、制度化，并以身作则。
比如我带领的CSDN论坛相关产品开发团队，有个制度就是每周四，组内一个成员介绍自己最近关注的技术。这个制度我没有往整个公司推广，是因为我觉得推广到整个公司，平均分配到每个人身上，就是4、5个月才轮到一个人一次，对于个人学习的督促作用一点用都没有了。
2、工作节奏松劲轮换，不能一直以一个节奏来进行。
该加班的时候就加班，该放松的时候就放松。注意不能一直是一个节奏，如果一直是一个节奏，那么人很容易懒散。
总结：
最近在看《人月神话》，其中的很多知识点感触很深，很浅显的一个道理，如果让自己一个人去慢慢悟的话，就不知何时才能出来。
回到本文讨论的主题，如何让自己保持激情？如何让团队保持激情？这是每一个程序员，每一个项目经理都要考虑的事情，只有有激情的团队才能产生伟大的作品。才能跟上时代的步伐。
前几天公司运维组的由于公司一台服务器中毒了,强制把公司所有服务器都装了经典的杀毒软件 Macfee VirusScan Enterprise 8.0i 。 结果一系列的问题都出来了。
单单跟我们组有关的 http://community.csdn.net http://topic.csdn.net 这两台服务器，都时不时出现下面的错误。停掉并卸载杀毒软件后，一切都恢复正常了。
下面罗列一下我们中间碰到的一些错误信息，当你碰到这样的错误信息时候，可能也跟我们一样，是因为服务器上杀毒软件的原因导致的。
ASP 程序产生的错误：
错误1：
Active Server Pages 错误 'ASP 0240'
脚本引擎异常
/t/20040401/11/2912553.html
ScriptEngine 产生了异常 'C0000005'(错误位于 'IActiveScriptParse::ParseScriptText()' 中，来自 'CActiveScriptEngine::AddScriptlet()')。
错误2：
msxml3.dll 错误 '8007000e'
存储空间不足,无法完成此操作。
******.asp , 行 176
错误3：
Microsoft OLE DB Provider for SQL Server 错误'80004005'
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()),]SSL 安全错误。
******.asp , 行 7
错误4：
Microsoft VBScript 运行时错误 错误 '800a0007'
内存不够: 'LCase'
********.asp，行 10
错误5：
Microsoft OLE DB Provider for SQL Server 错误 '80004005'
[DBNETLIB][ConnectionOpen (ConnectionOpen()()).]一般性网络错误。请检查网络文档。
****.asp，行 7
错误6：
Provider 错误 '80004005'
未指定的错误
*****.asp，行 7
ASP.net 的错误
错误1：
System.OutOfMemoryException: 引发类型为“System.OutOfMemoryException”的异常。
Generated: Thu, 04 Jan 2007 10:32:55 GMT
System.Configuration.ConfigurationErrorsException: 引发类型为“System.OutOfMemoryException”的异常。 ---> System.OutOfMemoryException: 引发类型为“System.OutOfMemoryException”的异常。
在 System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
在 System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
在 System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
在 System.Reflection.Assembly.Load(String assemblyString)
在 System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
--- 内部异常堆栈跟踪的结尾 ---
在 System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective)
在 System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory()
在 System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai)
在 System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig)
在 System.Web.Compilation.WebDirectoryBatchCompiler..ctor(VirtualDirectory vdir)
在 System.Web.Compilation.BuildManager.BatchCompileWebDirectoryInternal(VirtualDirectory vdir, Boolean ignoreErrors)
在 System.Web.Compilation.BuildManager.BatchCompileWebDirectory(VirtualDirectory vdir, VirtualPath virtualDir, Boolean ignoreErrors)
在 System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
在 System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
在 System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)
在 System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
在 System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)
在 System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
在 System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
在 System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)
在 System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
在 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
今天在考虑一个问题的时候，突然发现，对于一个企业级的大型应用，性能一般都不是很好的，他追求的重点是用户体验。而不是性能。
在用户访问量小的时候，企业级的大型应用性能一般不好（你做了分布式考虑，大量的数据被冗余）。但是这时候，用户体验并不会很差（因为用户量小）。
在用户访问量大的时候，企业级的大型应用性能仍然不好（同上，你做了分布式考虑，大量的数据被冗余）。但是这时候，用户体验并不会很差（因为使用了分布式技术）。
最近我在进行的下一代CSDN社区集群架构设计中，一度陷入既要考虑性能最好，又要考虑企业级应用下用户体验不差。结果发现好矛盾。
现在想想，我应该优先考虑的是用户体验最好，而不是性能最好。
摘要：
在性能和灵活性取舍的时候，插件做成一个虚假的插件。
正文：
最近一直在进行下一代CSDN社区的详细设计，其中各个社区都需要有自己的特色，苦恼的地方就是灵活定制和性能的取舍。
插件系统就是相当灵活的系统。
http://www.cnblogs.com/muddle/archive/2004/06/11/4762.html
这里对插件系统的描述就相当不错。摘抄几句：
插件系统就是指 当宿主程序开发好以后，可以开发一些符合自定义规范的程序(插件)，来扩充宿主程序的功能。
插件系统的设计注意点为：
1. 宿主程序如何知道插件的存在；
2. 插件如何从宿主程序获得必需要的内容；
3. 插件之间如何交换信息；
4. 如何对插件进行扩充(也就是说每一个插件都可以作为一个宿主程序)；
5. 考虑插件升级，等其它因素；
要实现以上灵活的插件系统，.net 下使用反射是必然。但是使用反射又有性能的问题。
反射的性能可以参看以下链接：
http://blog.csdn.net/leafwiz/archive/2004/10/18/141882.aspx
http://nickchen.mblogger.cn/posts/28131.aspx
另外，如果每个插件要用到自己的数据库的话，更麻烦。在社区设计中每个插件涉及到数据库就很明显，比如CSDN 社区的积分制可以被认为是一个插件。保存积分就需要数据表。而这个数据表又不是孤立的。
这样灵活的系统下，性能必然成为很大的问题，而社区一般都是众人集中的地方，性能、用户体验是第一要素。
考虑到以上的问题，在CSDN下一代社区开发中，我觉得采用一个中庸取舍方式比较好。
首先这个社区的插件应该都是由我们组织开发的，我们清楚有哪些插件。这样就不需要考虑特别灵活的扩创一个新的插件，而只需要考虑灵活的调用一个插件，同时调用时要考虑性能问题。
这样在新设计一个插件的时候，可能会比较麻烦。但好在这不是第三方完成的，我们是可以控制的。
我们在程序架构上，就可以假设这些插件都是存在的，只是调用不调用的问题。
这其实就变成配置参数的思想，而不再是插件的思想了。
只不过我们为了为了维护方便，仍然采用插件的思想，把每一个插件相关的操作，尽量集中到一个应用程序集中（这里仅仅是尽量而不是强制要求）。部署的时候，方便管理。
这个虚假插件系统中，甚至可能部分插件是混杂在一起的（比如数据库中，宿主数据表和插件用到数据表被集成到一个表中，宿主程序和插件程序对该数据表同一行不同列的操作，可能会被集中到一个函数中完成）。
这就是一个虚假的插件系统。但是他是照顾了性能，又有相当灵活性的。
虚拟组件的思想再整理
1、可以预知并控制有哪些组件；
2、性能优先的原则下，尽量使用组件、插件思想；
3、程序中具体实现，是通过配置调用与否来定义的，代码直接调用相应功能。而不是用反射机制。
4、代码举例：以下情况都是允许的
4.1 一个函数体内，我们根据配置来分类运算。
4.2 一个函数体内，根据配置，分别调用不同组件的不同方法；
5、数据库举例：以下情况都是允许的。
5.1、所有组件跟宿主需要用的数据表字段，是在一个数据表中的；
5.1、所有组件跟宿主需要用的数据表字段，是在不同数据表中的；
注意，如果我们事后需要新增一个插件，可能代价会比较大，考虑到这种情况，设计开发的时候，就要求程序员在考虑性能的前提下，尽量插件化，方便扩充。
这种要求，在负责外部需求的时候，可能是根本不可实现的，但是如果是内部需求，开发者就是其中一个用户，也是设计者。这反而是可以达到的要求。比如CSDN的社区。就是这样的一个实例。
结论：
以上的中庸取舍思想，其实在软件开发中很有意义，因为我们的实际项目需求，跟某个设计模式的理想状态总是有差别的。
附带说一下：网站的总体性能，总体体验，主要是由用户最常使用的功能决定的，如果你的一个优化把用户最常使用的功能反应速度提高了，而把不常使用的功能反应速度增大了，这仍然是一个好的性能方案。
首先说明这是我个人观点，不代表其他人，也不代表某个公司、群体。
对于非专门做广告的网站，我认为它在做广告的时候要遵循以下标准。
1、800*600 下，第一屏，必须有实质内容出现，不能只是广告；
现在版本的CSDN首页就非常不好，下面是800*600下CSDN首页的截图的缩微图。
2、广告尽量让网友感觉是自己可以控制的。
比如一些页面的广告，不想看是可以移下去，移下去后，用户就可以不再看这些广告。这样让用户感觉至少是自己可以控制的。
又比如弹出窗口的广告，用户不想看是可以关闭的。
但是以前CSDN论坛的那种布局，分桢模式，最头上的广告，网友如果不想看，只有不来CSDN论坛，这种广告是要不得的。
比如可以看下图，下图是以前版本CSDN论坛在800*600 下的效果缩微图。最上边的由于是在一桢中，用户只要来csdn论坛就必须看这个广告。对用户体验很不好。再加上以前经常出现Flash做的很不好，客户端CPU占用率很高。被骂了多次。
?
其实以上的原则，归跟到底，就是要遵循一个原则，不论你网站是干么的，用户体验中应该首先感受它是一个专业性网站，其次才是一个商业性网站。当然，如果你不考虑用户体验，就当我没说以上话。
当然广告必须赚钱、或者有价值这类的内容就不说了。
这两天，CSDN出现了有人注册中文ID的情况，CSDN 是不允许正常途径注册中文ID的，为此在注册页面专门用 asp:regularexpressionvalidator 作了限制，服务器端专门用 IsValid 作了判断。
通过联系网友，网友反馈是：是通过禁用客户端禁用所有js来实现注册中文名的。但我们是服务器端有校验的呀。一直查下去，发现是正则表达式写错了。写成了 ValidationExpression="\w+"
如下禁用所有JS。
查询MSDN的帮助,对 \w 有以下描述:
与任何单词字符匹配。等效于 Unicode 字符类别 [\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}]。如果用 ECMAScript 选项指定了符合 ECMAScript 的行为，则 \w 等效于 [a-zA-Z_0-9]。
晕倒，我以前看的几本书可没有这么说。反查一些关于正则表达式的书，晕倒，很多在对 \w 进行说明的时候，写得就是匹配任一单词字符，包括 A-Z、a-z、0-9和下滑线_ ，而没有提到 Unicode这部分。晕倒，被书害了。
而上面的说法，是JS的说法，以前学习这部分的时候，只是注意看书本内容，没注意看MSDN，害的出了这么一个大漏洞。
把正则表达式修改为： ^[a-zA-Z0-9_]+$ 就修正了这个问题。
置于为啥禁用掉JS，就可以注册中文，原因如下：
如果采用 \w+ 来校验的话：
如果客户端没有禁用JS，在js 这一层的校验，其实是校验的是 [a-zA-Z_0-9] ，
如果用户禁用了JS，在服务器端，它实际是校验的 [\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}]
这样服务器端中文的用户名也校验通过了。
置于在CSDN注册的中文ID，按照CSDN的制度，所有利用非正常途径、CSDN漏洞获得的利益，CSDN都不给与保护。除了少数几个帮助CSDN解决问题的帐号被保留外，其他都会被删除。
前几天，数据库文件出问题，现象就是，一些的查询操作会报以下错误：
Microsoft OLE DB Provider for SQL Server 错误 '80004005'
Warning: Fatal error 644 occurred at Aug 5 2004 8:45AM
或者：
Microsoft OLE DB Provider for SQL Server 错误 '80004005'
Warning: Fatal error 823 occurred at Aug 4 2004 10:39PM
823 错误是指：
SQL Server 在对某设备进行读或写请求时遇到 I/O 错误。该错误通常表明磁盘
问题。
644 错误是指：
当索引 ID 表示的非聚集索引出错时发生该错误。当进程试图删除不存在的行时检测到该损坏。
那个数据库服务器的硬盘是做了Raid 5 的，查询具体的硬盘，没有看到那块硬盘坏了。把数据备份，然后恢复到另外一台机子。仍然存在这个问题。显然数据库文件有坏块了。
试图通过下面语句修复数据库，但是只能修复部分数据，但是不能完全修复。
dbcc checktable('数据表')
dbcc checktable('数据表') WITH ALL_ERRORMSGS
DBCC CHECKTABLE (数据表,repair_allow_data_loss)
DBCC DBREINDEX('数据表')
sp_dboption '数据库名', 'SINGLE USER', TRUE
DBCC CHECKDB('数据库名', REPAIR_ALLOW_DATA_LOSS)
sp_dboption '数据库名', 'SINGLE USER', FALSE
用SQL Server 的导入导出功能无法完全导出数据。会报 823 错误。对所有数据的Select ，也会报 823 错误。
下面是用这些修复语句修复后，返回的一些有代表性的错误信息：
Server: Msg 8929, Level 16, State 1, Line 1
对象 ID 797245895: 在文本 ID 4582550994944 中发现错误，该文本的所有者是由 RID = (1:65204:25) ReplyID = 22853478 标识的数据记录。
Server: Msg 8909, Level 16, State 1, Line 1
表错误: 对象 ID 0，索引 ID 13824，页 ID (1:430153)。页首结构中的 PageId = (31744:9744137)。
Server: Msg 2533, Level 16, State 1, Line 1
表错误: 未发现页 (1:307388)，该页分配给了对象 ID 397244470，索引 ID 0。可能页无效或页首结构中的对象 ID 信息不正确。
Server: Msg 8978, Level 16, State 1, Line 1
表错误: 对象 ID 397244470，索引 ID 1。页 (1:307360) 缺少上一页 (1:307391) 对它的引用。可能是因为链的链接有问题。
Server: Msg 8976, Level 16, State 1, Line 1
表错误: 对象 ID 397244470，索引 ID 1。在扫描操作中未发现页 (1:307388)，而其父代 (1:308098) 和上一页 (1:307387) 指向了该页。请检查先前的错误。
Server: Msg 8980, Level 16, State 1, Line 1
表错误: 对象 ID 397244470，索引 ID 1。索引节点页 (1:308098)，槽 155 指向子页 (1:307389) 和上一子页 (1:307388)，但未遇到这些页。
Server: Msg 8939, Level 16, State 1, Line 1
表错误: 对象 ID 825360384，索引 ID 62467，页 (1:430152)。测试（m_slotCnt < MaxSlot）失败。值为 5409 和 4048。
Server: Msg 8986, Level 16, State 1, Line 1
发现的错误数目（201）太多（属于对象 ID 797245895）。若要查看所有的错误信息，请用 'WITH ALL_ERRORMSGS' 重新运行该语句。
Server: Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 797245895. The text, ntext, or image node at page (1:90548), slot 53, text ID 4297096364032 is not referenced.
Server: Msg 8974, Level 16, State 1, Line 1
Text node referenced by more than one node. Object ID 797245895, text, ntext, or image node page (1:100941), slot 15, text ID 4367996551168 is pointed to by page (1:407572), slot 25 and by page (1:430169), slot 25.
Server: Msg 8961, Level 16, State 1, Line 1
Table error: Object ID 797245895. The text, ntext, or image node at page (1:100944), slot 29, text ID 4582550732800 does not match its reference from page (1:430166), slot 55.
Server: Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 797245895. The text, ntext, or image node at page (1:307381), slot 4, text ID 4584554954752 is referenced by page (1:3786), slot 75, but was not seen in the scan.
Error: 823, Severity: 24, State: 2
I/O error (torn page) detected during read at offset 0x000000d2086000 in file 'E:\database\DbName.mdf'.
17310 :
SqlDumpExceptionHandler: Process 3224 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
17065 :
SQL Server Assertion: File: <"xact">, line = 838 Failed Assertion = '!m_parNestedXactCnt' Trying to use the transaction while there are 5 parallel nested xacts outstanding.
18052 :
Error: 3624, Severity: 20, State: 1.
17066 :
SQL Server Assertion: File: , line=1576 Failed Assertion = 'm_activeSdesList.Head () == NULL'.
17066 :
SQL Server Assertion: File: , line=1378 Failed Assertion = 'm_offBeginVar < m_SizeRec'.
这些修复都无效后，最后只有采用了最原始的方式，写程序逐行用SELECT语句将数据提取出来。好在每天都有备份，这次只有几十条数据丢失。
至于为啥产生这个错误，目前仍然不知道。
