2010年1月13日星期三

据说转载这个过些天百度会给钱

以下文字转载自一个现已不存在的地址:http://is.gd/6bEeB;发文时间是2010年1月13日下午1:20分左右,作者时百度的首席设计师孙云丰(孙老师你好,恭喜一博成名):

google宣称要退出中国,所证明的,恰恰不是市面上的那些g粉所宣称的那样,google是个人权斗士,而刚好反了过来,正好证明google是个市侩分子。

google 的首席法律顾问的调调让我感到恶心。因经济利益退出,就直白白的说好了,把自己涂脂抹粉一番,还煞有介事的提到google被中国人攻击,中国异议分子的 Gmail信箱被攻击,把这些事情作为退出中国的铺垫,这种论调是侮辱中国普通老百姓的智商,但还真有可能迎合那帮目空一切,但从未到过中国、对中国没有丝毫了解,却又喜欢对中国说三道四的西方人的假想。

只提一个假设,如果谷歌占据了中国80%的搜索市场份额,google的高管,还会这么高调的宣称要do no evil,从中国退出吗?

整个事情给我的唯一感受,就是恶心。

科普一点:

信息不对称是造成社会不平等最主要的原因之一。而对普通百姓最为关键的信息,并非中南海秘闻,而是最为常规的经济、文化、科技等领域信息。尽可能的为普通老百姓对这些领域的信息提供便捷,并消弭信息占有的不对称,这是搜索引擎存在的最大社会政治意义之一。

从这个角度而言,尽可能的设法为百姓提供便捷的信息获取技术服务,提供切实的价值,而不是挂羊头卖狗肉的宣称自己do no evil和政府撕破脸皮搞壮烈,才是一种真切的负责态度。找台阶下可以,但不要拿一个高管制国家的民众感情来做台阶,这是极其不道德的。

政治环境短期内是无法改变的。在中国,每个企业或者个人,都必须戴着镣铐跳舞。其实在别国一样,只是程度之别。但这是现实。在有限的条件下,尽可能的提供自己勉力而为的一份子,才是一个真切的做企业、做人态度。

在我博客上乱喷的兄弟,甚至还有搞笑的喷我five毛党的,都回家好好的念点书,再回来喷吧。希望看得见点水平的,而不是除了咒死爹死娘就不知道说啥的。 80年代的愤青,可不是现在这副衰样儿。

————–

以上是作为一个曾经的忠实google用户而说的,和百度无关。市面上沾沾自喜于了解一点google的产品技术细节将google奉为道德楷模而自封G 粉的兄弟,请勿跟帖瞎喷,你们根本不懂什么叫搜索引擎,什么叫自由人权。

————–

btw,评论关闭。要喷到twitter上喷吧。我的地盘不欢迎。

2010年1月1日星期五

支持生成 <a href="http://goo.gl">goo.gl</a> 短网址的 Firefox Google 工具条

挺好用的,不明白为什么tinyurl和bitly之类的缩短服务被墙,大概是看着一个个身材短小精悍的字符串这些家伙心里发毛。google的服务生命周期应该长点吧?

主旨:

"支持生成 goo.gl 短网址的 Firefox Google 工具条"
- 天涯来吧 - Google - 支持生成 goo.gl 短网址的 Firefox Google 工具条... (查看 Google 边栏评注

2009年4月28日星期二

3G初体验

运营商真黑。
听说联通的wcdma试运行了,周末烧包一下,订了个50元包600M的套餐,告诉我24小时开通,将近至少30小时之后,开始使用,能连wcdma,虽然不太稳定,但速度还算流畅,又下载又看视频的,试了老半天,很快收到短信说余额即将不足,又玩一会,联不通了,好半天才发现是欠费了,赶紧缴费,上网一查费用,原来套餐还没开通,是按1k一毛钱收费,在不到一天的时间里,扣去将近一百元,NND,算是我吃饱撑的交学费了吧。仔细再看清单,怎么这么多种费啊?!于是打客服电话,要改套餐,答复说着套餐是按一整月算的,也就是说我27日定制成功的套餐,只能用到月底,下个月如果不改就默认还是这个套餐。于是我打自动台去改,告诉我只能带身份证去营业厅修改,再转人工台询问,得到同样的答复,只好作罢。顺便问了一下那些SP收费和增值费怎么回事,怎么取消,回答那是在网上下载东西时网站收的费,我说那你帮我取消吧,回答那是服务商收的费,跟我们无关,我说费用都在你们网站上列着,有代码(虽然不知道代码代表什么服务),有时间,有扣掉的钱数,为什么与你们无关?那我就想取消怎么办啊?回答还是那都是你自己下载东西收的费,要不给你发个短信自己查看一下你定制了什么服务吧。于是我按提供的短信查询了一下,吓了一跳,怎么一下子凭空冒出来五六种服务?我只记得定制过一个天气预报的服务,其他是哪来的?上网查一下,果然有很多骂声,比如“106558550”这个代码所代表的业务,到现在我也没弄清到底是个什么东西,钱倒是每月照扣不误。

作为一个懒人,从99年用上现在这个联通号码,就一直没换过,现在一打客服电话,都是“世界风VIP客服为您服务...",都熬成VIP了,不容易啊,但这服务哪见得一点VIP的影子?资费高就认了,信号不好也都习惯了,最让人受不了的就是完全不符合普通人正常思维方式的计费标准,以及强行定制乱收费的盗贼行径。懒如我者都要发飙了,却一点办法都没有。拿起法律武器以理力争?顶天退你个十块八毛的,够不够花的那些时间生的那些闲气?电话还是要打的吧,3G还是要用的吧,这么多年到处留号,实在没法轻易换掉。莫非是我当年用联通没用移动是站错队了?莫非其他移动业务运营商没有这种问题?未必吧。面对强势的垄断行业,除了自己加点小心之外,忍了吧。

老夫很生气,但是相信后果一点都不严重。

2008年11月19日星期三

这集Boston Legal太扯

美国人对中国的妖魔化印象根深蒂固。

最近一集Boston Legal(S5 EP08),讲述一个在美国呆了三年的15岁中国女孩,意外怀孕,打算堕胎,最后的真相竟是:堕胎的原因是这个女孩得知胎儿是女性,作为中国人,很自然的 要把孩子。在美国人看来,中国人对性别选择已经到了令人发指的地步。还有这样一句台词:B超对中国人不是件好事。整个一集,中国人重男轻女和性别选择竟成 为了中心思想,像其他每一集一样"发人深省"。

真他奶奶的讨厌。现在中国农村都没像以前那样看重性别了吧?想象一下,一个15岁,在美国生活的女孩会因为胎儿性别原因堕胎?放他娘个屁!美剧的编剧有水 平,不过只要涉及到中国相关的话题,必定是20年前的陈词滥调,没有调查,没有体验,单凭想象和印象,便极尽污蔑鄙视之能事。让人恶心。

几乎每一部美剧都有类似情况,包括我最喜欢的House和Boston Legal,近期都有这种倾向。令人失望!

2008年10月13日星期一

无病呻吟之科幻小说

好几次,家里大清理的时候,老婆总是跃跃欲试的要把那些占据书架一大角,积攒了十来年的科幻世界杂志当废纸卖掉。在一哭二闹三上吊和威逼利诱的把戏用尽之后,我还要费好大口舌才能为这坨故纸堆争取到更长久的生存权。

的确,对科幻作品,通常的看法是不登大雅之堂,是与漫画游戏一样给少年人消磨时间用的,几十岁的人还看科幻,在很多人看来是挺可笑的一件事。另外,在信息触手可及的当下,积攒大堆故纸,似乎也是某些上了年纪的人无事可做时聊以怀旧的习惯。所以看科幻、攒杂志这样的事情,对我而言权作自娱自乐,不足为外人道。

优秀的科幻小说作者通常都良好的科学素养,对其所处时代的科学技术发展有全面深刻的认识,对科技发展的方向和可能带来的变革及影响有着卓越的敏感性和预见性。比如儒勒凡尔纳的科幻小说在今天的读者看来几乎没有科幻元素,更像是一部部历险记,这正是因为凡尔纳对他所处时代的科学技术发展有着异乎寻常的前瞻性认识,他在小说里的种种“奇思妙想”,早已被一一变成现实,甚至有些东西很难说究竟是凡尔纳预言了未来还是科学家发明家们受到他的启发创造了未来。同样,现今流行的林林种种高科技的新玩意,比如互联网、病毒、卫星、基因技术等等,在三十年前也都是科幻小说里的常客。而克拉克曾经在小说里预言的太空梯、太空核动力、地震预防、人体冷冻等技术,也正是目前科学前沿的一些主流方向。从这个角度看,不得不说科幻也是具有现实意义的。

身处于这样一个科学技术飞速发展的时代,人们对科技的进步趋向于两个极端,一方面,不论多么稀奇古怪不合常理的事情,总有人信以为真,或是认为理所应当,因为总有人去研究,总有人去控制可能产生的不良后果;另一方面,由于媒体的误导,大众反而对一些原本正常的科学领域的现象和研究小题大做、夸大其词、杞人忧天。从这个角度看,更广泛的科普教育是必要的,而优秀的科幻作品往往能做到寓教于乐,且雅俗共赏,不失为一种科普方式。这算是作为一名科幻爱好者的一个借口吧(爱好科幻是需要借口的,否则会被认为是幼稚浅薄,比较尴尬~_~)。

科幻作家往往是悲观论者,他们往往会更敏感的看到科学技术发展的负面效应,在他们的笔下,世界曾经一次又一次的被毁灭。因此,作为一名科幻爱好者,我对那些有科幻色彩的现实的第一反应,往往反而是负面消极的。下面是近来看到的几则具有科幻色彩的新闻,我的第一反应都是回忆起曾经看过的某些类似题材的科幻作品(新闻标题后面对应的是相应的科幻小说),权作自娱自乐。





2008年9月3日星期三

Chrome之画蛇添足

整整一天,到处都弥漫这Chrome的味道,原本没必要多说什么了,不过在随便记录点想法之后,忍不住手贱,狗尾续貂一下,反正也不多我一个。

关于google的浏览器Chrome,原来的很多想法不准确,比如以下几点:
 - 原以为,google会推出自己的浏览器,但短期之内(甚至三年内)不会,实际上几天之前人们还只是捕风捉影,而Chrome几乎一下子就从石头缝里蹦出来了;
 - 原以为,google即使出浏览器,也是为了给自己的现有服务提供一个定制的平台,而非与MS、Mozila、Opera和Apple以及大批山寨浏览器直接交锋的通用的桌面浏览器;实际上从对Chrome的试用可以感觉,它的目的就是一个通用浏览器,有为其自身服务提供优化的余地及可能,但绝非单纯的google服务客户端,它同时借鉴了各家之所长,虽然beta还很简易,不过其心昭昭,如果说MS的浏览器是利用了OS的优势而进行垄断,google就是利用了它的口碑和明星效应强势出击;
 - 原以为,google的浏览器至少会与其自家的服务有很好的集成;但是从这个beta来看,与google服务的集成很弱,甚至远不如Firefox方便;
 - 原以为,google的浏览器会与自家的一系列客户端软件有很好的集成,比如gtalk,picasa, desktop search,google earth等,而且与Firefox类似,必然提供设计良好的扩展机制;目前来看,任何集成都没有,设置连google toolbar相匹配的插件也没有,也没看出可能的扩展方式;
 - 原以为,google的浏览器会有很多看起来非常标新立异的东西;事实上看起来都是其他主流浏览器已经具备的特性,比如标签页预览(Opera和Firefox相应扩展),简洁的外观(Safari),url快捷输入,标签页和书签管理(各种新版本的主流浏览器)等等;
 - 从发布前的截图看,Chrome似乎很简易,直观的感觉就像gtalk那样,虽然有特色,但为了简洁而放弃很多主流IM必备的功能,所以很难成为主流;不过试用之后,发现之前的臆断很错误,google很像是在玩真的。

Chrome很多特色功能与现有的主流浏览器看似雷同,但细节上下了很多功夫,增强了用户体验,也就是在保证用户已有的浏览器使用经验的同时,用起来更舒服。比如:
* 对现有浏览器的兼容与重用。书签、密码、浏览历史、导航条等可以直接从默认浏览器中导入,完全称得上无痛迁移;
* 地址框兼作搜索框,这样一个细节的变化,不仅给google最核心的搜索功能带来了便捷,更重要的是,如果以Firefox上近来流行的Ubiquity扩展为参照,这个简洁的地址栏给mashup带来了更多的想象力,而mashup面对的是无穷的天地。虽然功能上与Ubiquity差距甚大,不过对google而言,这几乎是举手之劳了;
* 速度快。好事者已经测试并得出结论,Chrome的浏览速度是IE的40倍。这个数据未必客观公正,“速度”一词也很含糊(我想准确讲应该是指页面渲染效率和并发的web资源访问的效率),但即使只凭主观感受,Chrome比其他主流浏览器都快,甚至比系出同门的Safari(同样基于Webkit)都快,确实快。不过问题是,裸奔的Firefox也很快,Chrome现在差不多算是裸奔,不知道加上那么多插件后是否还能这么快。与速度(效率)相对的是,Chrome占用系统资源很多。
* 默认的平台支持。最重要的是google gears,这差不多相当于微软在IE里默认内置了Silverlight。尝试一下zoho,rememberthemilk,google reader等支持gears的应用,没有障碍。还有默认内置了flash plug-in,似乎其他主流浏览器第一次访问flash内容时都需要安装flash插件,google把这个约定俗成的插件变成必备的了。当然还有google对Chrome最重要的原创功能,即多线程javascript引擎V8,对用户而言它是透明的,不过访问那些重度使用javascript的应用时,有性能提高的感觉(或者是错觉?)。
* 另外还有一些细节,是很有原创意味的,比如tab可在窗口间自由拖拽,地址栏高亮显示域名,将当前页面创建为应用程序快捷方式等,书签栏包括了一个“其他书签”,很惊讶的发现安装在Firefox里的StumbleUpon的内容作为书签被导入进来(但没有delicious书签,也许是因为它属于yahoo?)

这一切都像是google在向所有用户在招手:试试我的浏览器吧,不会让你失望的,至少不会让你不习惯的。

据说Chrome这样一个beta一天之内占有了2%的桌面,很多人会很受伤,最受伤的大概是Firefox,因为google原本是Firefox最大的客户。与Sarari相比,Chrome优势也很明显,而且更容易占领各种桌面操作系统。

作为beta版,Chrome还有很多需要改进的地方,就个人喜好而言,我觉得one process per tab的方式太耗系统资源,相应的进程管理也没什么必要,标签页的管理不如firefox或ie方便,不支持gesture,浏览器本身还很脆弱,容易崩溃,等等。

接下来google会做什么?进一步改进用户体验?提供扩展机制?让Chrome更健壮?提高安全性?与google各类服务及软件的整合?我们试目以待。


2008年8月29日星期五

浅谈developer friendly

Windows XP推出的时候,XP一词几乎到了被滥用的地步。XP大概是指user experience,即用户体验。为软件付钱的是用户,所以用户体验当然重要。而开发者(以下称developer以特指)大概是“用户”的一个特例,当developer在使用一种开发工具、平台或框架的时候,developer的体验也就是用户体验。作为一个developer,很多时候更关注的是开发体验。好的开发体验可称为developer friendly。下面基于自己的体会,结合.NET和ROR两种开发体验的范例,谈谈对developer friendly的理解。

.NET和Ruby On Rails均是最先进的软件开发模式的代表,虽然它们并非一个级别的东西,但思想上有很多共同之处,这些“共通“的地方,大概就是他们”先进“之所在。我觉得它们最大的一点共通之处在于二者都花了很大的功夫在developer friendly上。另一点在于二者都力图在应用开发的不同领域(domain)内提供相同或类似的用户体验,更准确讲叫开发者体验。

先以.NET为例,.NET的出现对developer有两个重要意义:
* 一是对多语言的支持,使得developer能最大限度的利用已有的知识和经验,同时还能从统一的clr中得到同样丰富的类库与run-time支持,vb到vb.NET,java/c++到c#(还有那个被废掉的java版本的.NET实现),javascript到jscript.NET,以及现在的DLR支持下的多种动态语言的实现(ironpython, ironruby, javascript等等),而CLI(和DLR)的标准化,使得在.NET平台上扩展任何编程语言的做法在理论上是可能的。虽然我也总是认为,这只是把同样的东西(.NET framework)用不同的方式(各种基于.NET的语言)来表达,很多时间与精力花在这上面有点浪费,但是从微软的角度看,不论你从哪里来,.NET总是欢迎你,对developer来说,没有什么比直接使用已有的知识在新平台开发更友好的方式了。

* 另一个方面是在不同domain内开发方式上的趋同。原本针对微软平台的产品做开发和二次开发都需要相应的语言和方法,这种”domain"很多,传统的开发方式更多,比如桌面应用(vb, vc++等),web(asp/COM/vbscript/jscript/html/css,iis...),database(T- SQL),office(vba),mobile(embedded vb/vc)等等,一个domain内的熟手要想转到另一domain,是很困难的事情,不仅在于不同domain所需知识的差异,还包括开发方式,编程习惯等很多方面,在跨domain开发时,developer很难应用现有的经验和知识,基本上跨domain的技能都需要从头学起。而.NET从发布至今,微软的几乎所有产品都在悄悄的(或突然的)支持.NET开发,至少在编程习惯和开发方式上是这样的。
- 桌面应用自不必说,从1.0开始,Windows Forms便屏蔽了不同开发工具和语言的差异(几乎只剩下不同语言语法上的差异了),到.NET framework 3.0(3.5/SP1)对WPF的支持,从前使用的SDK和API几乎可以完全忽略。

- web应用方面,对客户端的要求只是浏览器,当大多数编程工作集中在server上时,更可以完全放弃以往ASP+COM粗糙的编程模型,而随心所欲地发挥.NET平台/语言的功效。 asp.NET提供了基于server control的web form编程模型,这种方式几乎屏蔽了web应用本身固有种种复杂因素(stateless, client/server roundtrip, debug, security, validation等等),使得web开发变得如同传统的桌面程序开发那样方便与直观(拖拽,数据绑定,属性设置,双击,编写事件代码,F5运行...),继而在ajax走到前台的时候,ajax也作为server control的extension被加入到toolbox里,在2.0的时候,masterpage,membership等原本需要大量编程才能实现的工作被抽象成了一个个out-of-box的feature,只需配置和简单编程即可使用,等等。当然webform屏蔽了太多细节,为了事件驱动的编程模型增加了太多原本不必要的东西,以黑盒子方式出现的server control给developer带来了很多不安和麻烦。为了顺应developer之意,随后asp.NET mvc作为另一种可选的开发模型被一个preview一个preview地加入进来,借鉴了ROR, django和monorails等成熟的mvc框架后,在强大的.NET framework和visual studio支持下,asp.NET mvc应该会是web开发领域的best practice,虽然其中几乎没有什么微软的创新。随着基于DLR的动态语言的成熟,rails式的DSL也不在话下,JRuby+Glassfish已经做了一个很好的榜样。

- 在database开发方面,无论DDL, DML还是DCL,原本都是SQL(T-SQL)的天下,从SQL Server 2005开始,数据库引擎开始支持.NET assembly,developer再也不必感叹stored procedure和function在实现复杂编程时的限制和不便了,除了部署时有些许麻烦,用vb.NET操作数据库实在是爽(如果有过在stored procedure里实现复杂逻辑的经历会深刻体会到这一点,虽然这不是一个好习惯)。更牛的是针对sql server所提供的报表服务,分析服务和集成服务,SQL Server安装时可以选择安装一个visual studio环境,可以用来在数据库上直接开发和部署这些服务,所以,甚至在生产环境里,developer都可以使用自己最熟悉的开发环境(visual studio)进行编译和部署,微软为developer想的真是周到。

- 基于office产品的二次开发由来已久,没记错的话,office2000以前只能使用VBA开发,2003里office里各产品开始支持.NET开发特性,visual studio里开始安装vsto扩展,到如今,vs2008里默认的项目模板包含了对2003/2007里各种产品的全面支持。office开发和部署原本是一个限制很多而且有些别扭的模式,而现在,把word/excel/infopath作为一种客户端形式,使用熟悉的编程语言,熟悉的事件驱动模型,基于完整的.NET framework,针对office的编程模型几乎与winform和webform完全统一起来,熟练的掌握winform编程的经验几乎可以没有任何障碍的转移到office应用开发上来,加上SharePoint的扩展,这种转移意味着现有的技能可能被放大到一个更宽广的领域。自身技能的可重用意味着经验知识增值和平缓的学习曲线,对任何developer来讲这都是个好消息。

- 还有一点可以说明,微软有一些很重要的努力几乎完全是为了developer friendly而做的。两个domain可以体现这一点,一是基于compact .NET framework的mobile的开发,另一是RIA方面的开发。mobile开发只了解大概,不过有一点比较明确,以前的windows CE上的应用开发一般是使用embedded c++/vb,简言之就是基于Windows CE这个小型的Windows(应该是小型而不是子集)采用非托管代码开发应用,优缺点与在windows上用c++和vb开发应用雷同,mobile开发毕竟不如desktop和web开发更广泛,所以按理说这已经足够了,在资源受限的mobile设备上,应该能简则简。之所以裁剪出个 compact .NET framework,除了移动设备硬件水平大幅度提升,j2me等移动设备上的虚拟机已有先例等原因外,给developer提供便捷一致的开发环境是一个重要原因,曾经做过简单尝试,虽然对mobile开发没有概念,但是按照开发winform的经验建立一个winCE程序(现在叫smart device了吧),拖拽、双击、事件编码,运行,直到一个手机样式的模拟器打开,程序运行起来,几乎没什么障碍,虽然实际的应用开发一定比这复杂得多,但对于一个developer来讲,这种体验必定能让人感觉到友好与自信。

- 更有说服力的是微软在RIA应用与开发上下的功夫,即Silverlight。从Silverlight的产生和发展过程即可见一斑。.NET framework 3.0发布以后,WPF是其中最酷最直观的一个新特性,不过曲高和寡,推广是个大问题,虽然微软想尽办法简化安装.NET framework的过程,也不遗余力的推vista,时至今日,仍然看不到wpf得以普及的希望。于是wpf/e出现了,'e'大概指 everywhere,能称得上everywhere的平台,大概只有浏览器,而基于浏览器的web客户端的局限性不可能从根本上解决,所以只有通过RIA。WPF的“样子 ”(和编程模型)看起来天生就与另一个早已遍地开花的RIA类似,也就是flash(flex)。在RIA上,Adobe与微软殊途同归,一个是从浏览器开始,flash到flex再到AIR,表明Adobe从网络扩展到桌面的野望。微软倒着走,既然暂时看不到wpf得以普及的希望,那就利用wpf给用户带来的印象深刻的使用体验,把wpf推广到浏览器上去。如今,真正基于wpf的应用并不多,对于普通用户来讲也无所谓有无,而所谓印象深刻的“用户”,很大程度上指的是developer,而“使用体验”也更多意味着开发体验。wpf的编程模型很优秀,有时候我甚至会想,桌面编程原本就应该是这种直觉的模型,比如以 tree结构组织的窗体和控件,本来就应该直接映射到xaml这种hierarchy结构上,用来描述UI component外观的属性,本来就该像css那样用resource和template来抽象和重用,等等等等... 从微软的角度看,他们也并没有“发明”这种新的编程模型,只是在向flex和xul等已经存在并经过实践检验的成熟的编程模型趋同而已。不过对于 developer而言,这种趋同绝对是一件好事,一个有经验的flex developer转而开发wpf或Silverlight是一件相对容易的事情,我们可以把wpf和silverlight看成是微软在向所有潜在的 developer示好的重要努力。再回头看Silverlight的发展过程,先前的wpf/e很快更名为现在的Silverlight,从名字到开发方式,都很有规划,很有章法,之前的wpf/e实际上只是一个过度,也许是因为当初有这个想法的时候很着急推出点什么,所以Silverlight 1.x 实际上只是wpf/e的别名,作为过度,它最大的问题并不在于它本身是否具有足够丰富的功能(事实上silverlight从一开始就支持各种媒体播放和很酷的交互方式,下载的run-time也很小),而是对于developer而言,它没有提供一个很好的编程模型,为了host一个silverlight组件(实际上是一个浏览器的plug-in在host),并控制silverlight与html的交互,只能通过javascript来完成。时至今日,vs2008(或其他任何一种IDE)都不能提供绝对完善的javascript编辑环境,而且javascript这种看似平常的动态语言,在充分发挥其动态特性并且代码越来越复杂的时候,会展示出其非常诡异的一面,所以如果silverlight要完全依赖于javascript的话,显然不容易被developer所广泛接受。于是微软推出了一种比较奇怪的版本策略,一方面这个从wpf/e改名而来的silverlight从beta演变成了1.0版,其后的1.x版本也都都基于同样的编程模型(javascript);另一方面Silverlight 2.0的alpha被推出,形式上与1.x同,但几乎整个run-time都被重写。实际上并不是重写,据说silverlight与wpf是从同一个代码树派生下来的,可以说silverlight的run-time是.NET framework的一个子集。第一次看到2.0的这个思路让我觉得非常惊讶,因为这意味着整个.NET framework要被挪到浏览器中,只依赖于浏览器里的run-time,而不论本地OS是否安装(或支持).NET framework。这需要多大的一个run-time啊?!当确认我的想法基本没错后,就马上开始浮想联翩了。因为这意味着.NET developer可以使用最熟悉的语言和环境来开发一个RIA程序,几乎不需要太多的额外知识,意味着一条平滑的学习曲线(当然前提是对wpf、 linq等有足够的了解)。而微软对silverlight运行环境的承诺是只需下载一个2-4M的run-time,难以置信。随后我们看到的是 silverlight的不断改进,包括加入越来越丰富的控件和对动态语言的支持等,同时runtime的尺寸一直控制在可以接受的范围内,直到2.0的 beta版本推出,北京奥运会期间NBC采用silverlight播放网络视频,使其知名度一举飙升。Silverlight 2.0实现到目前的状态,微软花了极大的努力,Scott Gu在一个专访中提到了这些努力,包括如何裁剪和如何尽可能的优化以控制尺寸。回头再看,Silverlight2.0所做的这些努力,几乎只是为了一个目标:developer friendly。(btw:采用同样策略的还有IronPython,1.x版本基于CLR实现,并行的2.x版本基于跟适合动态语言开发的DLR实现)



再看看Ruby On Rails。ROR是一个优秀的web开发框架,虽说与.NET framework并不是一个级别的东西,不过ROR的很多优秀之处体现了和.NET framework同样的理念,重要一点就是对developer而言十分友好。

与.NET开发相比,ROR并不十分强调IDE的先进性,textmate据说是DHH们的最爱,咱没有mac,不过体验过号称为textmate移植版的e-texteditor,老实讲,用惯了visual studio的developer不会觉得他们有何不同凡响之处,不过是一个对ROR开发而言便捷得恰到好处的编辑器。即便更高级的ROR IDE如NetBeans 6.1和3rdrails,也与visual studio有很大差距。而ROR的主要特点是一个框架、一种语言、一套惯例与思路。对developer而言,ROR最大特色是它的全部东西对开发而言都是实用的,也是易用的,换言之,developer friendly。

作为框架,ROR提供了shell command来生成代码,固定的目录/文件结构直接映射到MVC模式,无需配置文件(需要的话也只是几行简单yaml),大量helper方法几乎囊括了web开发中所有常用的功能,扩展很简单,写helper,放在相应的helper文件,写类库,放在lib目录,第三方扩展,放在vender目录,执行任务,运行rake即可,运行和调试很便捷,script中内置方便使用的web server,等等...就像常说的那样“框架为你规定了一切,你只需把精力放在真正重要的事情上”。

对developer而言,过多的选择有时候会让人不知所措(比如在使用php时,单单MVC框架,就有十种以上选择,再加上不胜枚举的模板引擎和数据访问方法,以及他们的组合),在纷纭复杂的选择中,花费了时间,最终却未必得到一个适合自己方案。rails则恰到好处地把所有必要的东西包装(比如ActiveRecord、 ActionPack和ActiveResource)并组织在一起,近乎于best practice,其不同版本对框架结构的调整也体现其与时俱进的生命力。“恰到好处”非常重要,这意味着框架能够在一方面能够满足大部分常规需要(不必开发大量底层重复性的代码),另一方面提供足够灵活的机制让developer有充分的扩展余地。这个“恰到好处”正是针对developer而言,“恰到好处”也是rails从众多类似框架中脱颖而出并被纷纷效仿的关键所在。

作为一种动态语言,ruby几乎是最简洁优雅的(个人认为要强于python)。ruby本身是一种通用语言,但它的动态特性使其经常与另一个词联系在一起,即DSL(Domain Specific Language),这里所说的domain可大可小,可以用来描述某种业务领域,也可以用来代表软件开发的某个方面,比如,html或css都是各自 domain内的DSL,分别用来描述web页面内容/布局和定义style。而Rails本身就是一个典型的用ruby定义的在web开发领域内适用的 DSL。也就是说用ruby语言定义一组在web开发中实用/常用的语法,这套语法接近自然语言,专门适用于web开发。打个比方,"3.years_ago"这样一个语句,实际上是rails为int类型扩展了一个years_ago方法,以简洁易懂的方式代替了通常至少需要几行代码才能实现的功能,即显示3年以前的时间。之所以定义了这样一个方法,是因为在web开发中经常会有计算和显示特定时间的需求,rails里包含了大量此类扩展,但绝不是随意为之,比如不存在一个"3.yeas_ago_plus_two_months"方法,因为就一般意义上的web开发而言,这种方法没有代表性,且不可枚举。而ruby的好处在于其开放性,如果在你的应用中确实会经常用到“n年以前加两个月”这种方法,你可以在helper或lib甚至 rails本身中扩展这样的方法。所以DHH采用ruby来实现rails并非偶然,这样一种灵活、易读的动态语言,对developer而言,是最舒服的选择。这里有个体会:即使使用cakephp或django这些与rails类似的web框架,因为编程语言上的差异(php和python),都没有使用ruby on rails时那种惬意的感受,这只是个人看法。对developer而言,大概这便是friendly的体验。

说到DSL,再补充一点。由前例可以体会,对DSL而言最重要的一点就是对domain恰到好处的抽象。 “恰到好处”可以理解,也就是前面提到的为什么扩展了years_ago方法而没有years_ago_plus_two_months方法。而“抽象” 这个词本身比较抽象,什么样的工作算是抽象?抽象到那种级别合适?没有标准答案。不过在rails里一些重要的方面体现了如何抽象和抽象到什么地步。有三个典型的方面:

* Model: 这个词就是MVC里的M,本身就有点抽象,通常理解为数据模型,在rails里,数据存储介质一般指database(当然也可以是xml,csv或一个 pojo样式的不与任何存储介质关联的实体类),对数据的抽象就是model, ActiveRecord就是model的具体体现。ActiveRecord就是一个ORM,与其他ORM工具的不同之处在于,在rails里,不需要描述实体与db映射的复杂配置文件,多数时候这种映射的依据就是convention,也就是按一些约定俗成的规则做映射,比如一个叫posts的表对应一个叫 post的model类,posts表中一个叫user_id的字段表明users表与posts之间存在一个多对一的外键关联。这种规约看起来没什么大不了,不过对于一个通用web框架而言,“以规约代替配置”这种设计理念是很大胆的,某些时候,这意味着rails里的ActiveRecord可能无法满足一些特殊需求(当然rails提供了足够灵活的机制在需要时可以用代码配置这种规约),而这种代价换来的好处是在很大程度上简化了配置,简化的代码结构,减少了依赖,目的无他,程序对developer而言更清晰简洁而已。ActiveRecord的好处当然不止于此,一旦在实体中定义了 association,就可以便捷的在关联对象之间导航,这种关联可以是1:1, 1:n, n:n, join tables, conditional joins和polymorphic associations,尤其是polymorphic associations,几乎可以实现传说中的OODB了。此外,在ActiveRecord中定义grouping,定义validation,都是非常简洁惬意的事情。在第一次看到LINQ to SQL时觉得这是非常棒的一种数据访问方式,不过随着对rails中ActiveRecord的深入了解,我简直怀疑LINQ是在照抄它的思路了。再加上migration和针对db的rake任务,以及自动生成的test框架,rails中的数据访问相关功能就完整了。

* HTML Template: rails中使用ERB作为默认的模板引擎,ERB本身功能很完善,不过与其他知名的模板引擎相比,似乎并无特别之处,有时反而觉得django的模板引擎更规范一些。rails2.0中也可以使用haml作为模板引擎,如果习惯perl的模板方式,haml也是一种很好的选择,更为清晰简洁。在这里谈起模板引擎,是因为考虑到模板的概念是对传统html的一种抽象。更准确的说,rails提供了一套比较完整的view templates,除了ERB之外,rails还提供一整套helper,比如“form_for",”text_field“等等。我们得理解web应用是由一系列元素构成的,比如客户端的html和javascript,以及服务器端用来控制逻辑和做render的代码,而html中翻来覆去使用的就是 button, div, textbox等等html控件,加之css控制外观,javascript控制行为,才组合成千变万化的web page。如果手工编写一个form,很多工作是重复或大同小异的,rails里的helper们正是对这些重复却又不尽相同的工作的抽象。比如一个 text_field方法,只提供name和value参数,他就是一个textbox,加上其他option作为参数,可以为其定义css,或响应一个 onclick事件,如果再对其扩展,它还可以成为一个带有suggestion功能的textbox。采用常规的方法实现这样的一个控件,我们需要多样技能,比如html,css,javascript,服务器端的ruby代码,甚至ajax(XmlHttpRequest)等。helper的作用就是把这些重复性的工作抽象,包装在一个个望名而知其意的方法里。虽然常用的helper并不多,但rails还是提供了大量的helper,它们可以应用在web开发的方方面面,有些功能甚至是我们想不到的,他们唯一的共同点就是都是在实践中总结出来的,有实用价值的东西,而不是像一个通用类库那样包含了方方面面,但实际上很多东西是用不到的。这种使用简洁的抽象,唯一的受益者就是developer。

* Javascript: 这种东西需要抽象吗?能抽象吗?rails给出了肯定的答案。这里说的是RJS。可以把RJS理解为一种针对ajax特性的DSL。据说高级的 developer是不用这种javascript的抽象的,我的理解是对复杂的ajax操作,RJS有一些局限性,而且RJS以Prototype和Script.aculo.us作为基础库,也妨碍的根据个人喜好使用其他javascript库,比如jQuery。不过这不妨碍我们理解和使用RJS。RJS是一种模板形式,被成为javascript generator template,与通常提交一个动作结果的模板不同,这些模板会生成如何修改一个现有的被提交页面的指令。这可以很容易地修改声明有Ajax 应答的页面内的多个元素。这些模板的动作在Ajax背景下被调用,并可更新页内容。一个简单的例子如”page.insert_html :bottom, 'list',“,它的作用是在当前页面底部插入一个'list'元素。这是一个javascript在客户端操纵html元素的例子,然而作为developer,实现这个功能(以及其他复杂得多的客户端功能),几乎不需要javascript相关知识,因为这里没有javascript代码,只有对javascript的抽象。我想asp.NET的ajax控件扩展,实际上也是类似的道理:即封装javascript以及与服务器交互的功能,屏蔽复杂细节,展现高级特性。 如果不考虑RJS的限制,对developer而言,只要会用ruby,并且了解RJS能完成哪些功能,就足够了。

上述几方面有一个共同的特点:虽然它们针对的是web开发中的不同方面(db访问,html template,javascript),但抽象的结果是不要求developer精通每一方面的知识(比如 SQL,html,css,javascript,ajax等),熟练掌握ruby和rails框架的原理基本上就够了,我想对developer而言,这意味这平滑的学习曲线和快速开发的能力。

最后,说说为什么需要developer friendly。DHH在谈论为什么要使用ruby来开发rails时的一段话很有代表性:

Ruby is a language for writing beautiful code. Beautiful code is code that makes the developer happy, and when a developer is happy, they are more productive. Ruby is unique in the way it lets you express something briefly, succinctly, and beautifully.

没错,软件开发的主体是developer,用户会选择产品,但不会去选择开发工具与框架,只有developer(广义上的)才会在意这些,developer的取向直接引导了用户的使用习惯,Windows 的成功说明了这一点。让developer感到舒服,不仅会提高生产力和产品质量,也意味着你的框架,你的平台将被广泛接受,直接影响的就是你的市场占有率。

我想,当鲍尔默在微软开发者大会上歇斯底里的高呼”developer!developer!!developer!!!“的时候,大概想到的也是这些。