解决IE6 select总是在最上层的bug

if ($.browser.msie && parseInt($.browser.version) < 7) {
overlay = '';
}

Have a Joke!

上午我到一家外商公司联络业务完毕，乘电梯下楼。

在某一层电梯停住了，门打开，看见一个衣著性感的女郎。

一手挽著名牌手袋，一手扶著电梯门，身体斜靠著， 用挑逗的语气问我：“够淫荡吗？”

我控制住汹涌的思潮冷静分析，人家公司就是不同，

人家外商企业的女职员就是开放，怪不得有人说，

我们比他们落後起码三十年，这句话是有道理的。

我平静地说：淫荡是淫荡了点，但我喜欢!!

我知道我说这句话的样子也一定很酷，

作一个有骨气的受传统文化薰陶男子汉,

要在新时代新潮流面前努力转变思想，

不能甘於落後。

突然间那女郎用手袋猛地向我砸来，一边还说：你这变态！.....

直到晚上我才醒悟，原来她说的是：

Going Down 吗？ (下楼吗 ?)

XP系统提高网速有效方法

用XP的朋友注意了，教你一招如何提高网速！！！

使用宽带上网速度自然比普通的拨号上网快了许多，可是Windows XP系统会自动保留一部分带宽，咱觉得有些浪费，利用起来吧！单击"开始→运行"，在"运行"对话框中输入"gpedit.msc"（该文件位 于"C:\\WINNT\\SYSTEM32"文件夹中），单击"确定"按钮启动Windows XP组策略编辑器。在"本地计算机策略"中，逐级展开"计算机配置→管理模板→网络→QoS数据包调度程序"分支。
双击右侧窗口中的"限制可保留带宽"项目，可以看到这里的"带宽限制"默认值为20%，我们只要将它修改为"已启用"，并将"带宽限制"值改为"0%"就可以让带宽利用率达到最高了

一、测试网站的反应速度
先 用Ping来测试一下网站的反应速度。Ping是一个很小的网络程序，它会向Web网址的主服务器发送一条32字节的信息，然后将服务器的响应时间记录下 来。如果从发出信息到服务器响应的时间超过400ms，就可认为运行缓慢。注意：用户离Internet中心集线器距离越远，服务器的响应时间就越长。具 体测试方法是：单击"开始"→"运行"，键入Ping和你欲测试的网址(如：Ping www．etang.com，也可返回至DOS状态键入上述命令)。Ping将会向你显示出4次测试结果，响应时间低于300ms均可认为正常，时间超过 400ms则显示响应速度较慢。当出现"请求暂停(Request timeout)"信息提示时，表示网址未在1s内响应，这表明服务器没有被配置为对Ping做出响应或者网址反应速度极慢。如果当你看到4个"请求暂 停"命令时，说明这个网站不能正常打开或者网站已遭破坏。通过这种方式，还可清楚地了解到你所在的网址是否正常。这一点对于一般直接拨号上网的计算机用户 而言，显得尤为重要。
在某个固定的时间，如果网址很忙(或者出于其他原因运行速度很慢，如硬件配置不高、数据管道不够用)，可以稍后再试一 次，以确定网址是否真的有问题；若真的有问题，可以找一下这个网址是否有其他的可以替代，或者使用离线浏览器访问该网址，或者看看你的ISP否支持代理服 务，这是一种可以将网址内容定期缓存到本地服务器的办法，如果支持的话，通知你的ISP缓存这个网址的内容即可。
二、跟踪数据的传输快慢
如果你觉得计算机运行速度缓慢，也许只是因为网上的路途太远。在到达你想访问的网址前，你的信号可能正在通过10台或10台以上的Internet路由器，其中任何一台路由器都可能影响整个过程的速度。

Web开发敏捷迭代

Web-based Product Design Process - Spiral Model.pdf

做互联网设计最重要是为了运营，蓝图和文档好比做作业打草稿、画画先描白，经验丰富可以考虑先省下这步骤。因为如果不表现在具体web-based原型上，蓝图、文档再好也无法快速切入开发流程，做为有大局观的Producer应该尽快意识到这点。

UED团队合作与开发流程优化是以前在雅虎做产品同事写的，雅虎团队的产品工程师们技术好，而且有来自美国团队的协作经验传承，做前端编程一直是他们的强项。但传统瀑布模型进程必然要面对“前松后紧”问题，根源在于设计、技术团队要互相等。因此，如果规避必须从观念上做出调整：快速产出、快速迭代，也就是软件工程里的Agile and Iterative Development。

以前我也常抱怨做互联网设计没谱，一是资源紧、二是变化快。项目周期和人手似乎永远都无法满足，来自内部考虑不周、外部竞争压力双方的需求变更频繁。其实这就是互联网设计的常态，接下来提到的方法，分为三个大步骤，版本仅供参考。

Alpha.快速完成核心功能开发

这里“蓝图”只是个代名词，也许只有些蓝图片段，或规划片段。曾经我们在老板办公室开会，根据头脑风暴结果、会议记录直接做原型。这么说可能有点一觉回到解放前的感觉，事实如此，第一步很关键，但质量不重要。

因为开始就期望得到完善想法是不可能的。比如，你开会描述个东西，让同事提意见，可能大家什么都说不出来。但只要你动手做出具体原型，同事亲自测试体验之后，意见噼里啪啦一大堆就来了。在这层意义上，绝大多数原型是炮灰也应该。

最初工作用自己最熟悉、最快速的手法完成，别让开发团队等。当然，这部分代码质量将直接影响以后的迭代工作量，根据时间灵活安排。不要考虑的过于复杂，总结起来有三点：

1. 尽早用web原型评估设计质量
2. 制作避免过早陷入web结构和表现细节
3. 设计避免过早陷入功能细节

每个业务都会有核心功能，也就是用户的核心需求，基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块，意思就是逐步提炼，找准关键点下手，这样才能搭好框架。也许经过几次迭代后，这部分工作已经是个可以跑起来的低保真产品，颇具alpha版本规模。

Beta.迭代完成固化需求功能开发

搭框架不要下手太狠，别自以为经验丰富把盘子搞大。因为刚才说了，互联网产品灵活最重要，虽然需求变化是经常的事，但我们要把风险控制在最低点。接下来在已有框架内，用同心圆放大的模式，按优先级实现辅助功能迭代，直至需求固化。

与此同时，产品设计团队除了对低保真原型的继续支持，还应并行完善和提炼高保真原型，并且着手对产品规范中复用模块的持续化整理，主要分为三部分：

1. web呈现效果迭代。先做图再切效率太低，因此我是直接用css美化低保真原型，通常这步可以把效果做的很得体。实在有必要，最后再截屏用photoshop处理细节并完善css。
2. web结构和表现迭代。我自己可以完成html framework, css framework两大块。
3. web行为迭代。需要工程师协助完成javascript framework。

也就是说，在包括beta版本以及之前，重中之重是实现功能需求层的良好用户体验。可访问性、兼容性、可用性、标准化、搜索引擎友好这些具体指标不要过早引入到应用开发中，让它们都在高保真原型的迭代内准备就绪。

比如可用性，做低保原型时尽量用最容易的方式解决问题，不要过早追求“用户体验”玩花样。大量的js互动效果和ajax异步加载会给原型维护、迭代测试带来大麻烦。

再比如标准化，良好结构的web页面，很受应用开发工程师欢迎，样式表则无伤大雅。因此我们可以多花功夫先处理html结构，节省时间让css样式表与功能开发并行迭代优化。

Release.模块化迭代提升用户体验

至此如果一切顺利的话，应用程序已经模块化并测试通过，设计规范也已经模块化、并有针对性的给出了高保真原型界面标准。用户体验的具体指标，已经在高保真原型的迭代中测试通过。

经验丰富的Producer可能都了解，成熟网站真正模块化后的内容其实不多，无非头、尾、导航、页签、表格、列表、搜索等等。传统方法流程的没有把操作体验与功能体验割裂开来，以至于来回折腾，反复做了大量工作才让产品模块化。根据设计规范迭代提升用户体验有两步：

1. 先处理界面视觉效果，比如分情况美化数据表格、文章列表等。
2. 再处理界面交互效果，比如可以把某些跨页流程改为层异步加载等。

永远记住不可能一步到位，花本钱的创意设计要用保守方案，用户体验是奢侈的。对多数应用开发工程师来说，使用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子，加上css马上就能风光起来，并且还不影响已经开发出来的程序，有点不可思议。

其他

敏捷设计思路同样来自前辈们总结过的软件工程思想，只不过换在了设计支持角度。真正的敏捷设计必然与开发绑在一起，只在产品阶段的砍掉文档、砍掉步骤、砍掉管理对全局影响不明显。

对产品团队来说，应该不断利用等待空闲调整规划，用任务分解、故事板等专业手法出文档优化结构。敏捷设计关键不在技术有多高深莫测，而是动作要跟得上节奏，前后衔接得当，才可能把时间一点点抠出来。不墨守陈规，把专业方法打散使用，融会贯通于每个思考点。

UCD翻译小组的同学们已将Boxes and Arrows的这篇Prototyping with XHTML译成中文，操作细节和心得很丰富，关于快速迭代总结的相当好。类似方法我们也已实践近两年，并且主导执行过两款大型产品，核心思想超过90%重合，以上补充了部分本地化快速产出经验。

原文说“只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写xhtml。”事实上即使计算机背 景的同学，没有两三年功力，要实 现兼顾前后的无缝协作都很困难，搞不好还会返工增加工作量。但长远来看，这样的训练很有意义，用web方式做web-based产品设计的优势将更垂直的 专业、体系化发展。

Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time.

团队成员越少，沟通效率越高；每人承担越多，整体风险越低。这是行云流水的产品、技术并行迭代的优势体现。总之，除对瀑布模型进程深刻认识，方法流程得靠团队的内力来推动。

Method for Javascript

//去左空格;
function ltrim(s){
return s.replace( /^\s*/, "");
}
//去右空格;
function rtrim(s){
return s.replace( /\s*$/, "");
}
//左右空格;
function trim(s){
return rtrim(ltrim(s));
}
//替换
function replace(s, t, u) {
i = s.indexOf(t);
r = "";
if (i == -1) return s;
r += s.substring(0,i) + u;
if ( i + t.length <>=
function checkbadwords(str, badwords) {
if (typeof (str) != "string" || typeof (badwords) != "string") {
return (false);
}
for (i=0; i0) {
allValid = false;
break;
}
}
return (allValid);
}
//函 数 名：chklength
//功能介绍：检查字符串的长度
//参数说明：要检查的字符串
//返 回 值：字节长度值
function chklength(checkStr) {
var n = 0;
for (i=0; i=0 && chcode<=255) { n++; } else { n += 2; } } return (n); } //复选框全选和不全选 //使用方法： //
function unselectall()
{
if(document.myform.chkAll.checked){
document.myform.chkAll.checked = document.myform.chkAll.checked&0;
}
}
function CheckAll(form)
{
for (var i=0;imonth){
return false;
}
return true;
}