这又是一篇来自于 帕兰映像 的文章：14条最佳JS代码编写技巧，但并非全部，我只复制粘贴了一小部分我所需要了解的，如果需要看全文，还是点上面的链接去他那里看吧。
1、总是使用 ‘var’ ，其实这个真的很重要。如果你一个不小心，你就会遇到变量重名或者无意中就引用了全局变量。
2、使用方括号记法。对于JS的对象，一般我们都是采用 aa.bb.cc来访问的，但其实也可以用aa["bb"]["cc"]来进行访问。
使用”.”号，属性名是硬代码，不能在执行时改变。使用”[ ]“方括号，属性名是一个通过计算属性名而来的字符串。字符串要以是硬代码，也可能是变量，甚至可以是一个调回一个字母串值的函数。 如果一个属性名在执行产生，方括号是必须，如果你有 “value1″, “value2″, 和 “value3″这样的属性，并且想利用变量 i=2来访问
如：MyObject["value"+i] ，你就不能写成：MyObject.value+i
并且在某些服务器端环境（PHP、Struts等）下，Form 表单被附加了 [ ] 号来表示 Form 表单在服务器端必须被当作数组来对待。如此，用”.”号来引用一个包含 [ ] 号的字段将不会执行，因为 [ ] 是引用一个 Javascript 数组的语法。所以，[ ] 号记法是必须的。推荐使用”[ ]“方括号记法是说当其需要时（明显地）总是使用它。当不是严格需要使用它的时候，它是一个私人的偏好和习惯。一个好的经验原则是，使用”.”号记法访问标准的对象属性，使用”[ ]“方括号记法访问由页面定义的对象属性。这样，document["getElementById"]() 是一个完美可行的”[ ]“方括号记法用法，但 document.getElementById() 在语法上是首选，因为 getElementById 是一个 DOM 规范中定义的一个标准文档对象属性。混合使用这两个记法使哪个是标准对象属性，哪个属性名是由上下文所定义的，在代码中显得清晰明了
3、在锚点中使用 “onclick” 替代 “javascript: Pseudo-Protocol” ：如果你想在 <a> 标签中触发Javascript 代码，选择 onclick 而非 JavaScript: pseudo-protocol；使用 onclick 来运行的 Javascript 代码必须返回 ture 或者false（or an expression than evalues to true or false [这句要怎么翻译呢? 我是这样理解的：一个优先性高于true 或 false 的表达式]）来返回标签本身：如果返回 true，则锚点的 href 将被当作一个一般的链接；如果返回 false，则 href 会被忽略。这就是为什么”return false;” 经常被包含在 onclick 所处理代码的尾部。
4、使用一元 ‘+’ 号运算符使类型转向Number：大家都知道“+”是javascript的连接符，但其实他也可以作为转换符来使用，如可以使用”+”号来把数组转换成数字。给变量或者表达式前置一个”+”号将会强制其当作一个数字来处理，而这也将使得数学”+”得以成功应用。
5、避免乱用全局命名空间。一般很少需要全部变量和函数。全局使用将可能导致 Javascript 源文件文档冲突，和代码中止。因此，一个好的做法是在一个全局命名空间内采用函数性的封装。有多个方法可以完成这个任务，有此相对比较复杂。最简单的方法 是创建一个全局对象，并把属性和方法指派给这个对象。但即使这样，命名空间也可以使用 Closures（闭包?） 来创建，并且 Private Member Variables （私有变量?） 也可以伪装于 Javascript中。
6、避免同步的 ‘Ajax’ 调用：当使用”Ajax”请求时，你要么选择异步模式，要么使用同步模式。当浏览器行为可以继续执行，异步模式将请求放在后台执行，同步模式则会等待请求完成后才继续。应该避免同步模式做出的请求。这些请求将会对用户禁用浏览器，直至请求返回。一旦服务器忙，并需要一段时间来完成请求，用户的浏览器（或者 OS）将不能做任何其他的事，直至请求超时。如果你觉得自己的情况需要同步模式，最大的可能是你需要时间来重新想一下你的设计。很少（如果有的话）实际上需要同步模式的 Ajax 请求。
这些，是我所关注的。。。一共有14条，你会关注哪条？
前段时间，我做了一个小记录： 即将进入10W以内，今天终于跨进10W大关
10W其实也算一个坎了。04年左右进来过，但后来停站后就再也没有了。
去年差一点进来，但还是离他而去了。。。
如今，我终于进来了，虽然有点辛苦，但。继续喽
努力。向前冲
今天是11月11日，传说中的丨丨节啊。。
本人是没有机会过了，不过俺的小家伙可以考虑提前过节了。
不知道“丨”念啥吧？
gǔn
上下贯通。
笔画数：1；
部首：丨；
其实，好象以前在看电视的时候，听 说河南有一个村的人都是姓这个的。
光棍节快乐，各位光棍们。
突然发现，原来，博客离10W又进了一点。多少年了。。。终于又要重入10W内了。。
先上个图，预祝一下，等确实定了之后，再来上图。。。
很激动人心的图哦【忘了说了，主域名是指：www.neatstudio.com，neatcn.com还没有到呢。。。】
这个，又是老王的文章，队列，确实还是需要用到的。不过，我倒真没有想过用专业的队列消息数据库等来处理。我最初只是想把一些要队列的信息用SQLITE来处理，一边是往里推，一边是往外拉。拉一条删除一条。等到数据量太大的时候，就清除掉。
老王还是有介绍的，我在PHPRPC群里也听缘起缘灭和廖羽雷他们谈过专业的队列处理，但，我目前做的事情，还是用不了专业的队列处理，所以也就没有放在心上，不过，既然老王有介绍，也可以稍看看【原本我计划做个短信定时发送也就是准备用队列处理的，但最后没做，因为139邮箱里居然有类似功能，NND，抢我饭碗】
Web应用中为什么会需要消息队列？主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update 之类的请求同时到达mysql，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。在Web2.0的时代，高并发的情况越来越常见，从而使消息 队列有成为居家必备的趋势，相应的也涌现出了很多实现方案，像Twitter以前就使用RabbitMQ实现消息队列服务，现在又转而使用Kestrel来实现消息队列服务，此外还有很多其他的选择，比如说：ActiveMQ，ZeroMQ等。
上述消息队列的软件中，大多为了实现AMQP，STOMP，XMPP之类的协议，变得极其重量级，但在很多Web应用中的实际情况是：我们只是想找到一个缓解高并发请求的解决方案，不需要杂七杂八的功能，一个轻量级的消息队列实现方式才是我们真正需要的。
第一感觉是能不能使用memcached来 实现消息队列？稍加考虑后就会发现它不合适，因为memcached仅仅支持键值方式的操作，没有排序之类的功能，所以如果要用它来实现消息队列，则必须 自己通过某个键来保存数组形式的队列，不过这样的话，在操作队列的时候很容易丢失数据，比如说我们要添加一个消息，则需先取出现有队列，然后把消息保存到 队列尾部，最后保存队列，单纯使用memcached的话，由于我们无法保证整个过程的原子性，所以当处理若干个并发请求时，各个请求间可能会互相覆盖， 丢失数据就在所难免。另外，memcached只是内存键值缓存而已，一旦宕机，数据就消失了。
memcacheq的出现解决了上面的问题，它在memcached的基础上实现了消息队列，以php客户端为例：
消息从尾部入栈：memcache_set
消息从头部出栈：memcache_get
memcacheq依附于memcached之上，所以你可以通过现有的memcached工具来操作它，这无疑是它的一大优势，但它也有一个很大的缺点，那就是memcacheq本身的开发维护似乎并不活跃，如果遇到问题的话，你很可能需要自己动手解决。
目前看来，我更推荐下面这种解决方案，那就是redis，如果不了解，可以参考我以前的文章，表面上看，redis和memcached差不多，也是键值操作，但是redis本身实现了list，相关操作也可以保证是原子的，所以可以很自然的通过list来实现消息队列：
消息从尾部入栈：RPUSH
消息从头部出栈：LPOP
redis本身虽然是一个新项目，但很有朝气，开发维护也很活跃，如果你的下一个Web应用里需要使用轻量级的消息队列，不妨使用它。
此外，还有不少其他的选择可供尝试，比如说MySQL第三方的Q4M引擎，通过扩展SQL语法来操作消息队列，也是一个不错的选择。
套用网络流行语：那些重量级软件实现的不是你要的功能，而只是独在高处不胜寒的寂寞，所以不必迷恋其中，它们只是传说而已。
--EOF--
原文链接：http://hi.baidu.com/thinkinginlamp/blog/item/27a18202578f3d054bfb511f.html
