''   是零字符串

update   db   set   username=null;

null   是空

1. 网站简明开发流程

简明开发流程是指假设网站开发的每个步骤都可以一次设计开发成功时的网站开发流程。

流程图如下：

2. 网站操作开发流程

网站操作开发流程是指假设网站开发的每个大的步骤都有可能产生未知问题时的网站开发流程。整个开发过程一般会有五次审核、三次测试才能够产品最终上线。看似步骤繁琐，实则是同时保证质量和效率的最佳方案。

流程图如下：

3. 网站操作、部署开发流程图

网站操作、部署开发流程是大型网站项目需要多人团队合理开发网站项目时的开发流程。在操作流程图的基础之上，每一个重要步骤都分别有一级主管领导负责统筹安排。同时对每一步骤的产品质量和效率负责。分管各部分的产品经理、美工、程序员有对应沟通，日常沟通不经过部门主管。每阶段的总体结果有每阶段主管领导负责。

流程图如下：

4. 总结

在开发周期的时间和进度把握方面，需要在“整体功能结构”确定以后，由产品项目经理评估“整体设计开发文档”(本人使用 Microsoft Office Visio 2003 文档)的完成时间。UI和网页工程师评估“产品网页Demo演示”的完成时间。后台程序总架构师评估“产品功能实现”的完成时间。

JavaScript事件是所有网页互动性的根基（我指的是真正的互动性，而不仅是那些CSS的下拉菜单）。在传统的事件处理中，你按照需要为每一个元素添加或者是删除事件处理器。然而，事件处理器将有可能导致内存泄露或者是性能下降——你用得越多这种风险就越大。JavaScript事件代理则是一种简单的技巧，通过它你可以把事件处理器添加到一个父级元素上，这样就避免了把事件处理器添加到多个子级元素上。

它是怎么运作的呢？

事件代理用到了两个在JavaSciprt事件中常被忽略的特性：事件冒泡以及目标元素。当一个元素上的事件被触发的时候，比如说鼠标点击了一个按钮，同样的事件将会在那个元素的所有祖先元素中被触发。这一过程被称为事件冒泡；这个事件从原始元素开始一直冒泡到DOM树的最上层。任何一个事件的目标元素都是最开始的那个元素，在我们的这个例子中也就是按钮，并且它在我们的元素对象中以属性的形式出现。使用事件代理的话我们可以把事件处理器添加到一个元素上，等待一个事件从它的子级元素里冒泡上来，并且可以很方便地得知这个事件是从哪个元素开始的。

这对我有什么好处呢？

想象一下现在我们有一个10列、100行的HTML表格，你希望在用户点击表格中的某一单元格的时候做点什么。比如说我有一次就需要让表格中的每一个单元格在被点击的时候变成可编辑状态。如果把事件处理器加到这1000个单元格会产生一个很大的性能问题，并且有可能导致内存泄露甚至是浏览器的崩溃。相反地，使用事件代理的话，你只需要把一个事件处理器添加到table元素上就可以了，这个函数可以把点击事件给截下来，并且判断出是哪个单元格被点击了。

用代码写出来的话是什么样呢？

代码很简单，我们所要关心的只是如何检测目标元素而已。比方说我们有一个table元素，ID是“report”，我们为这个表格添加一个事件处理器以调用editCell函数。editCell函数需要判断出传到table来的事件的目标元素。考虑到我们要写的几个函数中都有可能用到这一功能，所以我们把它单独放到一个名为getEventTarget的函数中：

function getEventTarget(e) {
  e = e || window.event;
  return e.target || e.srcElement;
}e这个变量表示的是一个事件对象，我们只需要写一点点跨浏览器的代码来返回目标元素，在IE里目标元素放在srcElemtn属性中，而在其它浏览器里则是target属性。

接下来就是editCell函数了，这个函数调用到了getEventTarget函数。一旦我们得到了目标元素之后，剩下的事情就是看看它是否是我们所需要的那个元素了。

function editCell(e) {
  var target = getEventTarget(e);
  if(target.tagName.toLowerCase() === 'td') {
    // DO SOMETHING WITH THE CELL
  }
}在editCell函数中，我们通过检查目标元素标签名称的方法来确定它是否是一个表格的单元格。这种检查也许过于简单了点；如果它是这个目标元素单元格里的另一个元素呢？我们需要为代码做一点小小的修改以便于其找出父级的td元素。如果说有些单元格不需要被编辑怎么办呢？此种情况下我们可以为那些不可编辑的单元格添加一个指定的样式名称，然后在把单元格变成可编辑状态之前先检查它是否不包含那个样式名称。选择总是多样化的，你只需找到适合你应用程序的那一种。

有哪些优点和缺点呢？

JavaScript事件代理带来的好处有：

那些需要创建的以及驻留在内存中的事件处理器少了。这是很重要的一点，这样我们就提高了性能，并降低了崩溃的风险。
在DOM更新后无须重新绑定事件处理器了。如果你的页面是动态生成的，比如说通过Ajax，你不再需要在元素被载入或者卸载的时候来添加或者删除事件处理器了。
潜在的问题也许并不那么明显，但是一旦你注意到这些问题，你就可以轻松地避免它们：

你的事件管理代码有成为性能瓶颈的风险，所以尽量使它能够短小精悍。

不是所有的事件都能冒泡的。blur、focus、load和unload不能像其它事件一样冒泡。事实上blur和focus可以用事件捕获而非事件冒泡的方法获得（在IE之外的其它浏览器中），不过我们改天再说这个吧。
在管理鼠标事件的时候有些需要注意的地方。如果你的代码处理mousemove事件的话你遇上性能瓶颈的风险可就大了，因为mousemove事件触发非常频繁。而mouseout则因为其怪异的表现而变得很难用事件代理来管理。
总结
已经有一些使用主流类库的事件代理示例出现了，比如说jQuery、Prototype以及Yahoo! UI。你也可以找到那些不用任何类库的例子，比如说Usable Type blog上的这一个。

一旦需要的话，事件代理将是你工具箱里的一件得心应手的工具，而且它很容易实现。

架构设计的几个心得：

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最快最有效的响应。。

ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构
web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的
 

二，web架构生命周期：web architecture‘s life cycle

既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你

所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长

google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的

三，缓存：Cache

空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快速为好。。

缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定

老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具

钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存
 

四，核心模块一定要自己开发：DIY your core module

这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其代码是非常可怕的

五，合理选择数据存储方式：reasonable data storage

我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select   c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select   count(Id)   from   review   where   Reviewid=a.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id
select   a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d,review   as   e   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id   and   a.Id=e.Reviewid   group   by   a.Id ..............................................

我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型社区)需要面对的问题实际是有一些偏差的

同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存储结构，lucene使用文件来存储索引和文件

从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一个选项

六，搞清楚谁是最重要的人：who's the most important guy

在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在web中我们一定以为最重要的涉众莫过于用户了。，在一个传统的互动社区开发中，最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普通人是不可能看完的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要，有时甚至是最重要的。

七，不要执着于文档：don't be crazy about document

web开发的文档重要吗？什么文档最重要？我的看法是web开发中交流>文档，

现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以通过阅读产品设计文档来了解项目的概况

而web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢，一种是每个人都了解软件的整个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种face2face交流比文档有效率很多。

于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说，我们的项目是吵出来的，我听完会心一笑

八，团队：team

不要专家团队，而要外科手术式的团队,你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就

总结：

0)架构是一种权衡

1)web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。

2)此外，相应的，最有效率的交流方式必须留给web开发，那就是face2face（面对面），不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来

3)人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。

另：有关web效率，有著名的14条规则，由yahoo性能效率小组所总结，并广为流传。业已出现相关插件（YSlow），针对具体网页按彼规则评分，这次该小组负责人Tenni Theurer也受邀来到此次大会，我把Tenni小姐（之前真的没有想到她是个女孩，并且如此年轻）和她的团队的14 rules列在下面

SystemVersion & "&SystemBuildDate=" & SystemBuildDate & "'></script>"
注意：去掉这段代码，就不用再担心后台的升级提示了。不过，升级还是必要的，因为升级既是对程序的完善也是对安全的加固。如果您需要更新系统就需要关注论坛来查阅是否有更新版本了。