李文兵

PPK也是在JavaScript世界中的风云人物了，这位老兄对于浏览器端的技术以及各种浏览器的兼容性有极其丰富的经验。在这本书中，他谈了很多关于可访问性(Accessibility)和可用性(Usability)的一些问题，非常有趣。比如他说“不同的开发者以不同的方式诠释了JavaScript的目的。简单而形象地说就是：深受CSS革命影响的传统Web开发者们，创建的是瘦的、可访问性很强、乱糟糟的JavaScript代码；而来至服务器端开发的‘资深程序员们’用完美的面向对象代码、创建的是胖的、可访问性很差的Ajax客户端”。显然，ppk同学应该属于写乱糟糟但可访问性很好的人，而现在我做的大量事情却是后者。他更多相信现在的Ajax只是一种泡沫，当这个泡沫破灭并且大量‘资深服务器程序员’消失时，JS的开发者会更加注重可访问性。 可能体会不到ppk经历浏览器各种痛苦的经历，但是总体来说浏览器都在坚定地遵循Web标准，JavaScript的支持也会成为浏览器必备要求。anyway，事情总在发展，好戏在后头。分享一下我觉得这本书中几个有趣的地方。

可访问性和可用性

可访问性(Accessibility)是指你的网页对于任何人、在任何环境下都是可持续访问的。特别是指某些用户，比如弱视、浏览器不支持JavaScript或者另外一些情况，比如用户使用Mobile使用你的网页等等。而可用性(Usability)是指使用或者浏览你的网页的容易程度(这里我们只谈web页面),通常它指我们能更有效率地使用、更容易地学习以及更加满意地使用它。举个例子来说，你让你的web页面支持IE6，或者支持mobile都是在提高它的可访问性；而是用CSS来改善布局让用户更容易阅读、使用JavaScript做一些对用户有帮助的互动都是在提高它的可用性。

Web页面都是由下面三个层组成的，通过它们我们可以了解到它们之间的关系以及它们和可访问性和可用性之间的关系。

• HTML结构层
• CSS表现层
• JavaScript行为层

Web页面的三个层，HTML结构层是必需的基础，CSS表现层和JavaScript行为层建于它之上。所以在客户端代码中不得不关注的话题就是这三个层的关注点分离。具体探讨一下这三个的分离：

表现与结构的分离(CSS与HTML)

这个分离很好理解，基本思想就是确保HTML来定义结构，而所有的表现都定义在另外单独的CSS文件中。HTML不应该出现<font>标签和用于表现的表格。如果想定义字体和布局，都应该在CSS中处理。

大部分情况下面我们知道达到某个效果是修改表现或者结构是清楚的。但是有些情况下当更改HTML和修改CSS都可以时，你需要慎重地思考到底哪种是合理的。比如一个节点，你希望它不显示，那么你可以在HTML上面删除该节点或者使用CSS来“display:none”。当这种情况是，需要自己分析所需要的效果属于哪种情况，然后修改合理的层。

行为与结构的分离(JavaScript与HTML)

这个也比较好理解，就是不要把任何的JavaScript代码写到你的HTML页面中。应该把所有JavaScript代码放到一个独立的js文件中，然后将它链入到所有需要它的HTML页面中。

关于这个有一个有趣的话题就是：无侵入脚本编程(unobtrusive scripting).简单来说它就是通过HTML和JavaScript的分离以达到页面的可访问性和可用性的最大化。既JavaScript失效了，页面还是可阅读和理解的；而通过引入脚本和JavaScript的hook，就可以让脚本运行，增强可用性。

行为与表现的分离(JavaScript与CSS)

这个的分离是非常复杂的，而且并没有总结出什么特别系统的规则。CSS和JavaScript是有重合的灰色地带的，有时候完全不能确切地把某个效果归为表现还是行为。比如是使用CSS中的hover还是JavaScript的mouseover/mouseout。基本来说你自己得根据具体情况做合理的选择吧。

事件捕捉模型

在HTML的事件模型中有一个有趣的话题。这个简单的问题就是：如果一个节点和它的父亲节点都有对同一个事件的处理，那么到底哪个事件会被先执行呢？这就是关于事件的冒泡和捕获。事件冒泡是说事件从它的目标元素开始，沿着文档树依次向上冒泡，并触发相应的事件处理函数。而事件的捕捉是刚好相反的，它从文档的第一级开始，然后沿着文档树向下游，知道事件目标为止。

在W3C模型中，捕获和冒泡都会发生。当一个事件触发时，它先被文档捕获，到了事件目标后，再冒泡到文档顶层。而传统模型和微软模型只支持事件冒泡，而不支持事件捕获。所以最好是限制使用事件冒泡。其实在我们的实际编程中，很少关心这个话题，是因为大部分情况我们都只使用了事件冒泡。

更加具体的可以查看ppk的文章：http://www.quirksmode.org/js/events_order.html

小记

应该来说PPK所谈的JavaScript是一个更加全面的浏览器编程的世界，让人可以全面来了解这个世界包含的东西。其实大部分的内容在PPK的网站上都有，值得读读。http://www.quirksmode.org/js/contents.html

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那么正式。所以还是一切随缘吧。

如果你访问我的website，你可能注意到我的页面中多了两个小东西（我们一般叫gadget），通过它们，你可以加入我的website、看到所有的人、加他们为好友、或者可以留言。嘿嘿，看，我的website也成为social了哦。（一定要给面子加入到我的website，:),）。不过感觉比较遗憾的一点是，朋友之间不能相互地发message，是我漏点了什么吗？

这就是Google Friend Connect所提供的能力，你只需要copy/paste它提供的HTML到你的页面中就完事了。是不是很简单呢？

Google的确在兑现它的承诺，让所有的website都能容易加入social的能力，并且还是使用最基本的东西(HTML/Javscript)。年初的时候在讲什么OpenSocial，觉得挺玄乎的，并没有搞懂这个东西到底怎么折腾到我的website，也懒得去研究它。现在Friend Connect可以说是提供了一个平民化的social方式 – Copy/Paste HTML总会了吧， 2分钟搞定。

OpenSocial就是提供了一堆的API来帮助你构建你需要的Social能力。当然这个对于需要social能力的商业网站是可行，能力很强，干啥都可以。而Friend Connect就更进一步了，就是将OpenSocial的能力平民化。通过使用OpenSocial的API写相关的OpenSocial gadget，你就可以通过Copy/Paste的方式加入各种各样的gadget。Cool？YES.  当然Friend Connect另外提供了一些基本的login，管理的能力。

看看几个简单的OpenSocial的API (当然就是JavaScript的)：

• API: opensocial.DataRequest.newFetchPersonRequest('OWNER')
  Site Name: 李文兵的主页
• API: opensocial.DataRequest.newFetchPeopleRequest('OWNER_FRIENDS')
  Site Members:。。。。
• API: opensocial.DataRequest.newFetchPeopleRequest('VIEWER_FRIENDS')
  Viewer friends:。。。

是不是很cool？你是不是也想抄起code写点东东,呵呵。 当然你也可以找些你喜欢的OpenSocial gadget来用就可以了。http://opensocialdirectory.org/.

未来的mashup会怎么样呢？还有多少infrastructure的东西都被google给占了? 期待&反思。

对于firefox的插件大家都觉得属于添加浏览器的功能，这些插件只是firefox中的小甜点，并不能自成一个完整的软件。 我也是一直这么认为，但是今天看到一个用firefox做的画图的工具，http://www.evolus.vn/Pencil/Home.html，一个和原有插件很不一样的插件。它只是将 Mozilla Gecko engine做成了一个画图的工具。并且最特别的地方是大小只有400K，非常的惊人。

觉得firefox非常有希望成为一个RCP的平台，相对Eclipse这样的RCP平台(或者Abode的AIR)来说是有非常多的优势的：

• 安装非常的方便:显然firefox的插件安装方式非常方便，点个link就安装了。
• 更新同样简单： 同样由firefox自己对插件更新的支持，自动检查更新最新版本。
• 软件大小非常小：看一个完整的画图工具只有400K，就知道能它能多小，安装可以多快。使用firefox所提供的对UI等的支持，将js的文件压缩后真的可以非常的小。
• 多平台支持：firefox就支持多平台，你写出来的软件也就自然能跑在所有firefox能支持的平台了。
• 开发要求低：基本上只需要掌握javascript，而世界上最多程序员的将会是javascript程序员。firefox的UI开发比起HTML，CSS来说是简单的。每个人估计是受到过写HTML，尤其是CSS中要处理多平台的煎熬。从这个角度来说，写firefox的插件比开发一个Rich的Web应用要快很多。
• 不需要安装体积庞大的SDK：你只需要firefox就可以了。很多人抱怨abode的SDK或者java的JDK都太大了，而很多非技术人不明白为什么需要安装这些乱七八糟并且几十M的东西，这也是abode的AIR很难快速流行的问题。

现在也是有很多不太如意的地方：

• 每次启动你得从firefox中启动，不能直接在OS的建立快捷方式。我觉得这个问题应该不大，看看Prism这样的firefox的lab project就可以了。
• 如何来操作数据库？操作数据库是一个基本的，可惜firefox并没有提供这样的支持。wait，firefox 3提供了类似google gears的能力，估计将数据持久化到本地是问题不大。但是连接到传统的数据库mysql等的呢？

当然firefox从来没有提过它要成为一个RCP的platform，它是否想成为abode AIR的competitor？是否它可以成为新的RCP平台，甚至它是否可以成为RIA平台，让我们试目以待吧。

这个是google对developer的一个大会，有非常多好的session，做web的都需要关注一下google到底在做什么。在它的keynote 讲了google努力做事情的方向：

1. Make the cloud more accessible
2. Keep connectivity pervasive
3. Make the client more powerful

Presentation Slides
另外更多的google I/O的session可以从这里找到:
http://sites.google.com/site/io/:所有session的video和slides

一直以来都在用Aptana的Editor来编辑Javascript/CSS/HTML,都挺好。今天尝试了Aptana自己一直在推的所谓‘世界上第一个Ajax Server的Jaxer。

在Jaxar里面写code倒是很有意思，所有你需要做的事情就是写Javascript/CSS/HTML。你根本不需要使用任何其他server-side语言,所有的事情就是写Javascript就可以了。来看一个例子：

 <script type="text/javascript" runat="server">
	function getAuthenticatedUser()
	{
		var username = Jaxer.session.get("username");
		if (typeof username == "undefined") return null;
		var rs = Jaxer.DB.execute("SELECT * FROM users WHERE username = ?", [username]);
		if (rs.rows.length == 0)
		{
			return null;
		}
		return rs.rows[0];
	}
</script>

用‘runat=server’就可以让上面对数据库的操作运行在server端，而client端对该方法的调用不变，这样在写Web应用时就不用在Server side和client side两边跑来跑去了。并且还有对template的支持。

这个和原来老毛和科长做的project zero client programming model是非常相似的，目的是都用来屏蔽client和server之间的boundary。不过Jaxar做的更加彻底，通过扩展Apache的server，加入自己的Server side framework和client side framework，让所有的一切都通过写JS就搞定了。并且对session，database, web ,SMTP 进行支持，对于一般的应用差不多就够了。老毛原来做的也是通过加入client framework以及扩展server的一些能力来让开发者在client和server之间进行无缝交互。可惜还是需要写Javascript和groovy，并且有一大堆的convention，不知道为什么没有发展下去（又是政治问题?).

那么这种开发模式到底好不好呢？我觉得对于比较小的应用，不考虑扩展和与外界交互，还是一个比较快捷的开发方式。毕竟client和server的无缝交互所带来的好处是非常大的，比如说学习的门槛低（只需要知道一个Javascript就搞定了), 数据传输中麻烦的异步调用，编码，解码，格式转换等等都将消失。但是一旦你的web应用大一些的时候，我想这种模式就面临着很大的问题。关键还是不容易扩展，当它把UI和数据逻辑混合的时候，要做分离是比较困难的。当然你可以在它的编程模型上写一层数据操作层，但是这样就变成了典型的RPC了。另外，这样做并不REST,Jaxer开发出来的应用根本提供不了service(更谈不上RESTful)，这样就无法被它人所用了。如果Jaxer应用以后要做整合，那绝对是一个大麻烦。

今天晚上看到一篇关于twhirl(居然是.org的域名)的文章，于是开始尝试用一下。你猜怎么地，wow！！ 有了这么一个twitter的client，我觉得这个东西是如此地有用，如此有意思。其实twiter就是一个所谓的迷你blog，写一句话，爱说什么就说什么。人的脑子里总是有各种各样的杂念一闪而过，写出来，感觉也挺好。

在twitter上我用了所有的gmail和msn的联系人(>300)，发现在上面注册的只有10个,而真正活跃的只有一个。看来现在用这样的服务的人还是少，可能是没有client体会不到它的好处吧(就想原来我一样,谁tmd的会跑到一个网站就为了写一句话).

试试了国内最好的饭否,感觉速度、用户体验都非常的棒。可惜没有联系人导入的功能（至少我没有找到吧），所以也不知道我有哪些好友在用这个。在国内这个要更多的人来接受（就像QQ一样)，可能还需要一些时间。希望饭否能够成功。

My twitter:http://twitter.com/wbinglee

我的饭否:http://fanfou.com/liwenbing

昨天老大要我们开始用自己的feed reader。是一个好的开始啊，毕竟自己的狗食要自己吃。想想我现在做的东西，也面临着同样的问题。自己的东西很少用在实际的生活中，这样不对。只有我们自己知道用户的体验，才能去改善我们的产品。其实很早的时候，老毛就提这样的概念，可惜感觉事情总是不了了之。可能与我们做的产品的类型有关系，毕竟不是那种日常生活中用到的东西。

现在这个内部的friend feed还是一个不错的开始，希望我们组能有更多的人来用它，虽然我并不是它的开发者,我还是非常支持的。其实我一直在想，我们自己写的projects都应该host到我们内部网站上。随着数目的不断增多，也会在我们的工作生活中用到。

现在哪个行业都在讲服务，如果说SaaS，那么改善用户体验就是提高服务质量。

拿google app engine做的小留言板，从注册（国内的手机记得要在前面加+86)，到下载python, 下载Google App Engine SDK ，然后安装，到写完这支程序发布出来只用了1个半小时。感觉真是太棒了。我的google Application是：http://liwb.appspot.com/,试试吧。

编程的思想还是在那里，和PHP，projectzero是一样的概念。但是当这个东西可以直接发布出来的时候，这样的体验确实很爽，再加上有google强大的infrastructure的支持，对数据储存的数量和效率的保障，着实不错。本地的调试也很方便，并且将发布只需要一个命令就搞定了。挺high的。
相比projectzero来说，最大的不同还是它的定位，projectzero还是希望为企业来服务的。所以没有如此的直接就可以使用的感觉，还是不断地玩localhost。另外，关于projectzero提供Web GUI的builder的话题：是否google的App Engine也会提供一个简单的GUI的页面让用户直接在浏览器里面去写code，而不是在本地写，调试在上传的模式，而是写了save就可以？我想这个也许并不是他们的目标，就像google的mashup editor并没有提供GUI的编辑一样。他们更多的目标还是能提供更多好的API，或者说能够有一天像PHP一样，其他的程序员都能贡献API，这个社区就真能繁荣了。

如果有了这个东西，google pages还有什么用吗？我想google pages还是给非程序员来使用的，用来构建基于content的website还是有它的价值的。从某种意义上来说，那个东西只是一个简单的web page creator了。

P.S. 刚才看到了一篇文章，http://16cards.com/2008/04/09/project-zero-in-the-cloud/，看来zero下一步也会在cloud computing上面做文章的。