李文兵

这周在给一些新员工讲JavaScript的时候，谈了==和===的区别，本质来说，===是严格的等同运算符，要求两者类型相同并且值相同；而==运算符在做比较时，会做一定的类型转换。我们在使用过程中应该使用===而不是==，因为这种类型转换后的比较往往都不是你想要的。当时列出了corckfork最喜欢一些例子：

	'' == '0'          // false
	0 == ''            // true
	0 == '0'           // true
	false == 'false'   // false
	false == '0'       // true
	false == undefined // false
	false == null      // false
	null == undefined  // true
	' \t\r\n ' == 0    // true

转换规则

当时有人就问了，那么在做类型转换的时候倒是等式的左边向右边转，还是反过来呢？其实这些都是不对的，我们去看看ECMAScript的规范，会发现它有对于等同运算符做类型转换很明确的比较算法，下面我将其翻译如下:
对于比较x==y，

1.如果x和y类型不同，那么到14步；
//
//2-13步，为类型相同的比较
//
14.如果x是null，y是undefined，返回true；
15.如果x是undefined，y是null，返回true；
16.如果x是Number，y是String，将y转化成Number，然后再比较；
17.如果x是String，y是Number，将x转化成Number，然后再比较；
18.如果x是Boolean，那么将x转化成Number，然后再比较；
19.如果y是Boolean，那么将y转化成Number，然后再比较；
20。如果x是String或者Number，y是Object，那么将y转化成基本类型，再进行比较；
21.如果x是Object，y是String或者Number，将x转化成基本类型，再进行比较；
22.其他情况均返回false；

ECMA这帮人写的算法过程比较啰嗦，简单一句话来概括就是，对于基本类型Boolean，Number，String，三者之间做比较时，总是向Number进行类型转换，然后再比较；如果有Object，那么将Object转化成这三者，再进行比较；对于null和undefined，只有x，y分别是它们时才相同，其他都为false。

另外，对于转化到Number的算法，细节可以来看ECMAScript的规范，但是基本上下面这个几个表可以覆盖大部分的内容:

再回头来看看corkford给出的例子，然后使用上面的规则去判断；

 '' == '0'          // false
//类型相同，毫无疑问，值不同，所以结果为false
 
0 == ''            // true
//String要像Number转化，''是空String，根据上面的表，转成0，所以结果是true
 
0 == '0'           // true
//String要像Number转化，根据上面的转化Number表，'0'转成0，所以结果是true
 
false == 'false'   // false
//有Boolean，转化成Number，所以第一步转化后为0=='false'；
//然后'false'向Number转，结果是NaN,最后变成比较0==NaN,那么肯定是false。
//（NaN和任何相比都是false，就算是自己也是false， NaN==NaN //false)
 
false == '0'       // true
//有Boolean，转化成Number，经过第一次转化就成了0=='0';
//就变成了上面的第3个例子，所以是true
 
false == undefined // false
//对于undefined和null，只有两边分别是两者才是true，其他都是false；所以是false
 
false == null      // false
//对于undefined和null，只有两边分别是两者才是true，其他都是false；所以是false
 
null == undefined  // true
//对于undefined和null，只有两边分别是两者才是true，其他都是false；所以是true
 
' \t\r\n ' == 0    // true
//对于String，先转成Number，对于空String，都将转成0，所以转化后成为0==0,结果为true
//（注意，空字符不仅仅是只是空格，还包括\t\r\n等等，更多可以见ECMAScript spec的9.3.1）

总结

虽然我们了解了==这个坏东西的本质，但是在我们的实际JavaScript编程中是要避免使用==，而是去使用===这个严格的比较运算符。

终于这篇文章在dWs上面发表出来了。
使用 Project Zero 和 WebSphere sMash Assemble Flow 构建 Mashup 应用，第 2 部分: 使用 Assemble Flow 开发简单协作流程

–文章摘要如下

在使用 WebSphere® sMash 中的 Assemble flow 来构建 Mashup 应用的第 1 部分中，我们介绍了 Assemble flow 的基本概念，以及如何使用 Assemble flow 来实现基于 Feed 的 Mashup 服务。本文中，我们将向您介绍如何使用 Assemble flow 来开发简单的协作流程。

–文章目录如下:

本文内容包括：
	引言
	开始之前
	在Assemble flow中访问REST资源和服务
	面向 REST 的流程接口
	使用 REST 风格实现流程会话
	简单人工协作流程
	webUI 活动
	使用 webUI 活动构建人工协作流程
	配置 sMash 应用程序
	结束语
	下载
	参考资料
	作者简介
	对本文的评价

–另外，发了另外两个blog在projectzero的中文博客上面；

• developerWorks文章：使用 Assemble Flow 开发简单协作流程
• 在TechTarget中国中的BPM活动

周末参加了一个opug的一个线下,真的很棒，收集到更多资料后，我会在后面的文章中来专门谈这个活动。其实活动之后我一直在琢磨在活动中给我触动的一件小事，记得当时有一位嘉宾说了一个观点后，我立刻机械地说“对”，坐在我对面的长城同学的反应是”你怎么知道“。其实道理很简单，对于观点你应该有一个什么样的正确的直觉反应。做技术，甚至无论做什么，都应该有一个怀疑和刨根问底的思维方式，这样才能很好的培养对于问题的独立思考能力。

嗯，对于你不知道的东西/观点，多问点为什么，别让‘对’/’行‘成为自己的第一反应。

09年是year of twitter, 这个东西现在火的一塌糊涂，google和facebook对它是羡慕的不得了。国内IT圈中也是刮起了一阵twitter风，好像你没有个twitter都不好意思和别人打招呼。但是当你屁颠屁颠地在上面发点东西的时候，也同时也被大量的信息噪音给淹没。有的人用twitter在聊天，有的人发布的信息非常多但是毫无意义，慢慢地这个东西成为了一种负担。其实twitter火起来有它的原因，但要看怎么来用了。

twitter来至一个简单的想法，告诉别人你在做什么。现在有很多的工具来帮助人们进行交流，比如blog和IM，但是日常发生在自己身上的一些事情使用这样一些工具都不太适合。我们不可以发一个blog告诉别人我在做什么，也不可能在聊天工具上面像疯了似的给每个人发这些消息。然而通过twitter，人们可以进一步加深相互的了解。比如，我的一个好朋友发消息说他在做一道菜。我看到后，很好奇他居然还会做菜呀，于是我们有了公共的兴趣点，可以进一步地聊聊。

从技术上面来讲，twitter的火爆说明了开放API的成功。有了twitter提供的API，就有了它的客户端的繁荣，桌面的、浏览器插件的、手机的….任何平台任何环境，只要你想到的都可以找到一堆的twitter客户端。 如果twitter没有这些多的客户端和社区支持，估计也难以流行起来。

话说回来，怎么用twitter呢？我想可以从两点来看，一是你希望收到什么消息；二是你应该给出什么样信息。关于收到什么消息，基本的原则应该是：只follow你所关心的人和事。前端日子follow了很多技术名人的twitter，发现他们发的信息根本都不是我关心的。我并不是他们的朋友，我根本不关心你和谁吃饭了，你今天去哪里运动了。所以很简单，将你并不认识的名人从你的follow列表中删掉，因为你对这些名人其实真正关心只是他的知识，而这些只要订阅他们的blog就可以啦。对于技术和某种事情的关注，follow这个社区的twitter就好了。另外对于那些乱发垃圾消息的人，删除好了。这个世界不是信息太少，而是太多了。

那用twitter应该发什么样的消息呢？我想原则应该是：只发有用的信息，并且这个信息不需要通过其他消息的上下文就能理解。如果是个人还是用twitter的本意就好了，就是发你在做什么，或者发现什么有意思的事情。社区类的twitter可以发当然社区发生重要的事情。切忌使用twitter进行聊天了，因为follow你的人并不一定follow了和你聊天的朋友，所以这些没有上下文的消息就毫无意义。

最后我想到了一位美女同事对于twitter的理解，twitter的消息就像一种缘分，你看到了就是一种缘分，不需要像聊天那么有紧迫感，也不像blog那么正式。所以还是一切随缘吧。

在GMail的Lab中有这样的一个小东西，它可以随机地加入签名档到你的邮件中。这个一直是我想要的，于是在五一无聊的时候试试。

首先当然是要到GMail的Lab中enable这个功能了。

这个时候到Setting->General中的Signature中会多出这么一个东西，

默认是http://www.brainyquote.com/link/quotefu.rss这个地址，这个时候当你新建一个邮件，就会发现有签名档随机插入到邮件中。但是这个并不是我想要的签名档，我需要它是从我自己的签名档列表中去找。这个功能的签名档的信息是由一个RSS来给出的，那么何不使用Google App Engine来做一个自己的签名档管理的小系统，这样我可以加入自己新的签名档，然后还可以提供签名档的RSS给它呢？

说动手就动手吧，很快就完成了。http://liwb-quote.appspot.com/。界面是抄twitter的，因为我的功能的确就是和它一样。我不得不说，在App Engine上面开发这样的应用的效率是惊人的。我很久没有动python了，App Engine的东西也是边看它的tutorial来完成的。但是我还是没有碰到太多的障碍就完成这些事情。看截图吧。

然后再是提供RSS就可以了：http://liwb-quote.appspot.com/rss。 再将这个地址放到gmail中设置就可以了。嘿嘿，当你再新建一个邮件的时候，签名档就是你在appspot上面的自己的了。是不是很high呢？

Conclusion

App Egine来开发这样的应用的效率是极高的。无非是数据库的一些操作，开发、调试和上线的体验只有用过才知道是如何的high。

另外，Gmail中的Random Signature还是非常不成熟，它并不是实时地去拿我当前的记录。也不知道它多久抓一下，这点让人沮丧。

Download

这个是我的App Engine的工程，如果你管理自己的签名档或者类似一句话的东东，这个都可以用。

下载App Engine应用

一些注意事项：

1. 下载后，修改app.yaml 文件中的application: {{ 你的应用名字  }}。
2. 在main.py中需要把users.get_current_user().email()==’wbinglee@gmail.com’改成你自己的email，因为我让只有本人才有添加的能力，其他人只有浏览的权限。
3. 然后appcfg.gy update 就好了。