当点亮下面节拍器的按钮，就能发出相应的声音来，感觉非常好玩
主要是基于不用flash，文件JS实现声音播放的原理做的
function startWav(uri) {
stopWav();
embedEl = document.createElement(”embed”);
embedEl.setAttribute(”src”, uri);
embedEl.setAttribute(”hidden”, true);
embedEl.setAttribute(”autostart”, true);document.body.appendChild(embedEl);
}
通过embed来实现的
我从来都没有直接的做过团队管理的岗位,主要是我人比较内向,以前还有点木讷,(呵呵,不过现在好多了).但是做过的项目不少,碰到管理上的问题也不少,但是主要问题是,计划定制,沟通和时间的问题,一直都没有好的处理方法.有的时候,不仅没有方法,连方向都找不到,很多返工,最后一拖再拖,磨的人都没有什么锐气了,慵懒的频于应付交差.所以,完成的根本不是我们起初想要的.这样,带来两个负面影响,首先,对于项目而言成本会剧增,东西的质量也不是很好,还有就是对于团队的士气和凝聚力也会下降.
再回过头来看看互联网的开发,在讲方法之前,拜托,先把方向明确了.这个是主要的,然后去讲方法,再然后对于这个方向再分析,产生计划,落实去做,测试,上线.
有了方向,就有了核,然后产生凝聚力.
再谈方法,我觉得底气就足了.
负责人:”我们要做一个什么什么东西,可行不?”
成员:”不错,好主意!” “没前途,不好” ”….”
(可行性分析) #%$#@#$^
————————————-
负责人:”大家看看要怎么做?”
成员:”用用Scrum的敏捷开发方法不错吧?” “还是像我们以前一样,会比较好吧(内心独白:这个人老喜欢新概念,烦不烦阿)”
负责人:”好吧,Scrum可以借鉴下,我们分解下任务吧,大家认领下”(内心独白:不要再散开话题了,抓紧时间,准备在19:30搞定,20:00还有另一个会议要开呢.)
(计划)
—————————————-
之前得测试过
里程碑到了…
负责人:我来过下大家做的怎么样?都提交了吧.
(检查)
—————————————-
不行,改!
ok,迭代就开始了.
以上的开发次序有问题吗?未必,但是大部分小团队基本上都是这样的.
如果每一步都做到位了,我想这一切都会往一开始订下的方向走.
如果不行可以及时的微调方法,逐渐形成自己团队管理模式.
总结下:
1.方向明确
2.计划清晰,职责明确,任务分工到位(落实)
3.及时的团队沟通(讨论,会议,走查)
4.落实测试审查,确保质量
之前都没有系统学习过闭包，对于闭包的概念也比较迷糊。今天搜了下关于闭包的资料和文档，有的说的很复杂，也许是翻译的问题吧。之后还是找的了一个比较简单的笔记性说明文档来自于never-online的一篇不错的文章：在Javascript中，什么是闭包(Closure)？
这篇文章的英文原创来自于：http://blog.morrisjohns.com/javascript_closures_for_dummies
于是我对照了原著看了下，更加深了印象，感觉闭包使用的恰当，效果很好的。
首先，闭包是什么？
function sayHello(name) {
var text = 'Hello ' + name;
var sayAlert = function() { alert(text); }
sayAlert();
}
以上的代码就表示了闭包的最基本的形式，在一个函数里面包含一个内部函数。
闭包有一个好处，就是变量作用域控制，和内部函数作用域的控制，是外界没法访问内部函数，使代码安全性提高，形成代码的单元。
其实，我还是看到never-online的另一篇
eval解闭包
里面说道：
[edit] Syntax
eval(string [, object])[edit] Parameters
string
A string representing a JavaScript expression, statement, or sequence of statements. The expression can include variables and properties of existing objects.
object
Non-standard
An optional argument; if specified, the evaluation is restricted to the context of the specified object.
呵呵，这么看来对于JavaScript私有的概念十分的弱了。eval是一个危险的方法，虽然灵活，但是得小心的用，就像goto语句一样有争议了。
最后总结下：
Final points:
* Whenever you use function inside another function, a closure is used.
每当你在一个函数里有另一个函数，表示已使用了闭包。
* Whenever you use eval() inside a function, a closure is used. The text you eval can reference local variables of the function, and within eval you can even create new local variables by using eval(’var foo = …
每当你使用函数里使用eval()，也表示使用了闭包。你执行的文本能够应用这个函数里的局部变量，甚至在eval里创建新的这个函数的局部变量，像这样：eval(’var foo =…
* When you use Function() inside a function, it does not create a closure. (The new function cannot reference the local variables of the function calling Function()).
当你在一个函数里使用Function()，并不会创建一个闭包。（当调用这个新建的函数并不能引用函数的局部变量）
* A closure in JavaScript is like keeping a copy of the all the local variables, just as they were when a function exited.
当一个函数退出时，在JavaScript里一个闭包就像是保持了所有局部变量的拷贝。
——————————————————————–
下面偷懒了，不翻译了，发现翻译措辞很痛苦，虽然看懂了，却不知道咋么表达好，大家一起看e文吧，或者有哪个达人帮忙翻译下。
* It is probably best to think that a closure is always created just on entry to a function, and the local variables are added to that closure.
* A new set of local variables is kept every time a function with a closure is called (Given that the function contains a function declaration inside it, and a reference to that inside function is either returned or an external reference is kept for it in some way).
* Two functions might look like they have the same source text, but have completely different behaviour because of their ‘hidden’ closure. I don’t think JavaScript code can actually find out if a function reference has a closure or not.
* If you are trying to do any dynamic source code modifications ( for example: myFunction = Function(myFunction.toString().replace(/Hello/,’Hola’)); ), it won’t work if myFunction is a closure (Of course, you would never even think of doing source code string substitution at runtime, but…).
* It is possible to get function declarations within function declarations within functions - and you can get closures at more than one level.
* I think normally a closure is the term for both the function along with the variables that are captured. Note that I do not use that definition in this article!
* I suspect that closures in JavaScript differ from those normally found in functional languages.
下午，在忙完事后，大家讨论起最近发起的博客模板的活动来，于是就做了《懒》的博客主题，纯粹搞笑，主要目的是雷人的。
下面是网址：http://i.yoho.cn/lan
主要是适用于浏览，且无语的潜水者看的。
不知道为什么，偶MM突然对烹饪产生了兴趣，问了下，原来兴趣来自于论坛那几篇饮食达人的帖子，心里痒痒，就想折腾下，再说好吃的，是偶MM的嗜好之一。
接下来，着实动真格了，端着本本，一一记下做菜的材料，然后就去超市采购一番，我就打下手，拎东西，哎，莫办法，不过想想有好吃的，嗯，打起精神来好好干哦！
做鲫鱼豆腐汤（我的最爱之一），还有就是可乐鸡翅（蛮新奇的），骨头汤（无肉不欢），还有就是做蛋糕，为了之个还特定买了个做可以做蛋糕的电饭煲。
打下手：洗鲫鱼，切菜，打蛋，还有喝可乐（不好意思，小小偷懒吧）
偶MM也忙的不可开交，不停的看帖子，来回于房间和厨房之间。
呵呵，不过最后还是做完了，我正准备吃呢，偶MM说不行，得先咔嚓几张片片，给大家看看做的好不好，不能一下子就吃了。
不过说实话—-很难吃啊~~~~~~~~~~~
哦，不对，说错话了。
不要生气，逗你啦，如果你在看的话。
嗯，很好吃的，真的。特别是鸡翅很好吃，蛋糕也不错。
难怪不过瘾，后来又做了一个蛋糕，结果得到大家的一致肯定了啦！
刚来到一个互联网应用团队，团队的技术leader对我说，你既然是专做web前端的，以后开发尽量少用js框架，应该多自己去写点东西，虽然我们现在使用了prototype的。
我想了想，就问那为什么之前还要用prototype框架呢？回答总结三点，一是时间紧，二是跨浏览器兼容问题，三是没有专业前端开发。这么一来，我就是专业的，所以要在解决跨浏览器兼容性的同时，要在时间足够里，不使用框架开发目前web前端的开发工作，想想要求的确不是很高。
而我主要是在想为什么要用框架，其实代表是一种进步，使用框架并没有什么不好的，常说不要重复去发明轮子一样，可以省的为什么要去不断的去重复，关键不是不使用框架，而是如何理解编写的前人为什么要这么写框架，如果不理解，就不能真正去用好它，使代码会乱，虽然快速实现了功能，但是在维护或复用该功能时发现问题多多。所以，写出有质量的代码才是主要的，至于是否使用框架，而是相对你所要实现的功能或需求而言的，按需开发，需要什么就使用什么技术，什么框架。
例如，你需要写一个，在页面上每隔10秒钟显示一条友好提示，就相当“你知道吗？”这样的功能。
可以这么写：
var tips=
{
msg:["你可以点击右键打开浏览器的其他选项！","使用“F1”可以获取帮助。","“F5”刷新页面。"],
current:0,
show:function()
{
document.body.innerHTML=tips.msg[tips.current];
if(tips.current
tips.current++;
else
tips.current=0;
setTimeout(tips.show,2000);
}
};
window.onload=function()
{
tips.show();
}
以上代码就没有使用任何的框架，因为简单，而且也没有必要去使用框架之类的，一样可以完美的实现这个功能的。
但是如果功能增加了一些要求，如tips的内容需要服务端动态加载，则需要Ajax的支持，另外需要淡入淡出效果，这两要求非常通用，则可以通过框架的支持来实现，可以重构以上的代码，加入框架的应用。例如，prototype或其他什么框架，基本上目前主流框架都有类似的支持，没有必要重新去开发这些，但是对于框架依赖可以抽离出来写，这样就方便解耦。这样代码结构就清晰很多了，便于维护。
所以说，使用框架是站在巨人肩膀上的一种行为，代表一种进步，前提是你要理解它。
