2010年12月25日星期六

Tangram 前端库通过 Github 开源了

Tangram 是百度内部一直在开发和使用的前端库之一,功能与 jQuery 、 Prototype 等库类似,主要功能是简化 DOM 操作,并且扩展 JavaScript 语言。这部分功能准确来说属于 Tangram Core ,另外一个叫做 Tangram Component 的库提供一些类似 YUI 、 Sencha 这个级别的组件。

之前 Tangram 说要开源很久了,一直卡在流程上,并且也有人觉得必须把库做得足够好了才好意思拿出来开源。我个人的看法是,跟 John Resig 的一样,前端库应该从第一天开始就开源,因为就算你不开源别人也一样能看到,所以还不如开放出来接受别人的贡献。如果你写得不好,就算你不开源,别人要看也还是能看得到的,所以还是直接把代码晒出来好了,看得不顺眼的可以直接说,实在看不下去了可以动手改,改完了再把代码贡献回来。

说完了我对开源的看法,接下来我们看看 Tangram 和 Git 分别有什么好,先从 Tangram 说起。

Tangram 能做什么

熟悉我的人都知道,我从来不讨论哪个工具更好的,我只讨论在特定的情况下哪个工具更适用。因此,我们来看一下什么情况下 Tangram 是适用的。

Tangram 的总体设计很大程度上是参考了 Mootools 的做法,就是将框架拆散到函数的级别,你可以引用单个函数,而不一定要加载整个库。这样做的好处是节省带宽流量,尤其适用于那些流量很大但 AJAX 功能不多的网站。百度的很多服务流量都不小,而且常用页面上需要的 AJAX 功能也不多,因此 Tangram 成为了一个很好的解决方案。

那么什么情况下 Tangram 不适用呢?如果你要写一个 AJAX Web App , Tangram 就没有什么特别的优势了,除非你尤其熟练使用 Tangram 。一个 AJAX Web App 本身就依赖于库中大量分散的功能,把一个库拆分到函数级别并没有什么意义。当然,在 AJAX Web App 中, Tangram 也没有什么明显的劣势,跟 jQuery 、 Prototype 都差不多,这时候就由团队成员对不同库的使用熟练程度来决定选用哪个库了。

现在 Tangram 的最大弱势在于,它缺乏一种机制让你对页面逻辑的描述变得流畅( fluent ),而这正是我们使用 DSL 时所追求的。过去我也说过 jQuery 是一种 DSL ,它允许你用一种很流畅的语言来描述页面的交互行为,这使得页面交互行为变得很容易管理──读懂别人写的 jQuery 页面并不难,在上面做调整也很简单。这是 Tangram 为了减少下载体积做作出的牺牲,不过我希望它将来可以通过编译工具等方法来弥补这个缺陷──例如说,我还是用某一种 DSL 来描述页面交互,然后这种 DSL 能够被编译为 Tangram 代码。

Git 有什么好

为什么选择开源到 Github ? Git 到底有什么好处?我觉得一个简单的例子就能很好地说明问题。

例如说,你想看看 Tangram 的源代码,那么你可以直接打开 Tangram Github 的首页,然后以只读的方式把代码都复制到本地。

git clone https://github.com/BaiduFE/Tangram-base.git

读着读着,你觉得 Tangram 写得也不是那么好,想改改看。于是你回到刚才那个页面上,点 Fork 按钮,然后就相当于把 BaiduFE 下面的 Tangram 项目整个复制到你个人帐号下了。你当然拥有你个人帐号下 Tangram 项目的完全读写权限啦,这时候你就可以把它复制到本地了。

git clone git@github.com:CatChen/Tangram-base.git

可以看到,这是我的帐号( CatChen )下的 Tangram ,不再是 BaiduFE 下面的。这时候你就可以随意改动啦,改动完提交就是了。

git commit -a -m 'Tangram improvement'

如果你习惯使用 SVN 或者 CVS ,那么你需要注意啦, Git 的提交都是本地的,不会提交到服务器上去。你 Github 帐号下的 Tangram 是一个仓库,你本地编辑的则是另外一个仓库。别忘记了,你刚刚是用克隆命令把 Github 上的仓库复制下来的。所以在提交后,你还必须用推送命令把本地仓库复制回 Github 去。

git push origin master

在这里, origin 是一个远程仓库的别名。因为你本地的仓库是从 Github 上克隆下来的,所以 Github 上的仓库叫做 origin 。默认情况下,仓库只有一个分支,叫做 master ,所以你要把本地仓库推送到这个分支上去。

这时候,你自己的 Tangram 是更新了。如果你希望 Tangram 的官方版本也接受这个更新的话,你可以点击页面上的 Pull Request 按钮,这时候 Tangram 的管理员就可以考虑从你这里把更新拉取到官方版本上去。

如果你在开发自己版本的 Tangram 时,看到别人的 Fork 有更新了,并且也想要那个更新,怎么办呢?你可以主动地从别人那里拉取,然后 Git 就会帮你完成合并。例如说,我发现 Leeight 那里在做的一个 Tangram 升级不错,尽管他还没完成这个升级,也没提交到官方版本中去,但我就可以先把这部分升级拉取到我本地的仓库中来。

git pull https://github.com/leeight/Tangram-base.git

这样子,我就能看到 Leeight 所做的升级,跟我正在做的改动是否能够良好地兼容了。或者,我可以先做一些依赖于他的升级的事情,等他把升级做完了并且被官方版本采纳了,我再向官方版本提出 Pull Request 。

可以看到, Git 对开源项目来说是非常友善的,尤其是跟 SVN 和 CVS 做对比的话。 SVN 和 CVS 尽管允许分支,但分支之后通常要到项目完成时才会进行合并,这时候主干已经发生了很多变更,合并起来就相当痛苦。 Git 允许你分支后随时从别人的分支拉取变更,同时你还可以在自己的仓库内做很多子分支,这就使得开源项目管理变得十分方便了。

小结

说了那么多道理,建议大家还是动手实验一下比较好。试用 Tangram 无需下载,直接创建一个页面然后引用我们放在 CDN 上的脚本即可,然后可以尝试按照入门指南做些简单的东西试试。

使用 Git 管理开源项目的话,推荐阅读 Git 开发管理之道 ,能够让你更好地了解 Git 项目一般是如何进行分支的,以及如何利用这些分支获得更好的灵活性。如果你想看完整的 Git 手册,可以看看 Pro Git 这本书,作者把这本书放到网上并且免费公开了。

最后插播一下小广告,我的 jsHelpers 库也跟随着 Tangram 开源了,大家可以来 Fork ,我很欢迎大家提交 Pull Request 。

2010年12月10日星期五

Tech·Ed 2010 及动手实验室资源下载

今年是第二年以讲师身份参加 TechEd 了,没有了往年的兴奋,认真把工作做好才是关键。 TechEd 对我来说,更多是一种年度聚会,能够跟国内 Microsoft 及社区的朋友见面聊天。

课程

第一天下午到得比较晚,来到的时候 Keynote 快要开始了,赶紧领了讲师的书包和衣服后就去听 Keynote 了。今年的 Keynote 对我来说没有什么吸引力,因为主要是面向 Azure 和 Windows Phone 7 的内容,这两样东西都是面向企业用户的,自己一个人玩没什么意思。 Keynote 后,两个基础课程都没去听,主要还是基于上面所说的原因,自己回到了讲师休息室,继续调整 PPT 。

All TechEd China shirts and bags are from Vancl.

今年的书包和衣服都是 Vancl 赞助的,不过至少拥有 TechEd 徽标。去年的衣服连徽标都没有,讲师都要另外发一个印着 speaker 的别针。此外今年还有 Vancl 赞之的围巾,过去从来没见到过印着 Microsoft 的围巾,这是第一次见到。

今年我要讲两个动手实验室,一个是关于 IE9 + HTML5 的,另外一个则是关于 WCF Data Service + ASP.NET MVC 的。内容我都熟悉,唯一让人担心的是环境。我们使用的材料跟美国 TechEd 的是一样的,但是美国 TechEd 时这些虚拟机都跑在 Azure 上面。不知道是不是带宽问题,中国 TechEd 无法使用 Azure 上面的虚拟机,所以必须在实验室中部署 Windows Server 2008 Hyper-V ,然后在本机跑虚拟机。

我的动手实验室都在第三天,所以我第二天就可以去看看别人讲得怎么样了。 TechEd 对我来说最重要的已经不是内容了,我更倾向于去了解那些讲得非常出色的讲师到底是如何演讲的。此外,由于今年我第一次讲动手实验室,所以我也需要了解一下别人是怎么讲的。一个完整的实验手册,到底有多少应该是我讲的,有多少是应该让大家动手做的,这是我最关心的问题。我围观了王兴明的动手实验室,觉得他的课程安排很不错——先讲一个简单的例子,再让大家动手做两个类似的稍微复杂一点点的实验。

资源

我讲的两个动手实验室,都遇到了虚拟机带来的问题,导致有些人无法完成实验,所以我就向大家承诺资源会发布到我的博客上,以便大家会后再深入学习。

IE9 的实验相对简单,它基本不依赖于任何外部软件环境,只要有一个 IE9 就能做,假若你愿意使用记事本写代码的话。下载包括:实验手册及代码,其中手册中的一个 bug 在我的完成版代码中已修复。(先提供英文手册,中文手册稍后提供,到时候会更新下载包的内容。)

ASP.NET MVC 的实验依赖于 Visual Studio 2010 。由于虚拟机太大了,我不可能提供下载,所以你需要在自己的机器上安装 Visual Studio 2010 后进行实验。下载包括:实验手册及代码。(下载稍后放出。)

花絮

我觉得 Microsoft 的会议组织形式是非常好的,尽管有时候会务公司执行起来会出一些细节问题。 Microsoft 非常懂得如何鼓励大家参与到互动中来,以达到预期的市场活动效果。举个例子来说,去年的 MVP 展台让大家去找 MVP 盖章,今年的做法就更近一步了——你找到 MVP 后需要跟他合影,然后发布到微博上。这使得活动不仅仅覆盖现场的参会者,还让微博上关注参会者的人都注意到 MVP 是什么以及 MVP 都有谁,这是十分成功的推广。MSDN 和 TechNet 的做法也是类似的,只要你发微博就能换取围巾,这能让微博上的微软社区气氛瞬间活跃起来,就算没有来到现场,也能感受到身边的人对 TechEd 的关注。

之前幾天在微博上活動,是為了拿 #TechEd 的禮品~

Baidu 现在也开始尝试组织自己的会议,尽管规模非常小,通常就只有一个 track ,一组话题。学习 Microsoft 成功的会议组织经验是很有必要的,尤其是对于向来就不懂得做开发者关系的 Baidu 来说。在未来的 Baidu 会议中,我们也会尝试学习 Microsoft 的成功经验,让开发者更好地参与到互动中来,体会到乐趣的同时又能赢取奖品。

2010年12月5日星期日

Windows 和 Mac 都支持 ExFAT 了

过去在 Windows 和 Mac 之间交换文件,总要受到文件系统差异所造成的限制。 NTFS 在 Windows 下很好用,但是在 Mac 下面只能读取; HFS+ 则正好相反, Windows 下面只能读取。如果使用 FAT32 的分区作为中转站,则无法容纳超过 4G 的单个文件。

自从 Snow Leopard 升级到 10.6.5 后, Disk Utilities 增加了 ExFAT 这个格式,看了一下 Wikipedia ,原来它就是传说中的 FAT64 ,一个能够支持超过 4G 文件的解决方案。考虑到 Windows 7 内置了 ExFAT 的支持,低版本的 Windows 安装 Service Pack 后也能支持 ExFAT ,我立即把我的移动硬盘切换到 ExFAT 格式。

Disk Utilities