| 我太懒了 的个人资料我太懒了,比猪还...照片日志列表 |  工具  帮助 |
|
|
5月22日 AJAX框架汇总此文原出于AJAX Patterns网站的一篇《Ajax Frameworks》的wiki文章，很早前我就注意到，后来在国内也有人翻译了，不过最近发现此wiki还是在不断添加维护中，截止此文发布前，作者又添加了好几个新诞生的AJAX开发工具，所以我决定重新翻译一遍，并且时常注意原文发布状态，一有新的内容立马也翻译过来，做到同步:) 此翻译稿很大一部分内容出自国内出现的那个先前版本，我只是对新加入的几项进行了翻译，并且对我熟悉的产品项着重介绍了一下，以后我会抽时间收集文中提到AJAX工具相关的文章，尽量将内容介绍和功能点评做到全面详细点。所以请关注和准备用AJAX做开发的朋友关注这篇文章，我会时常更新的。原文因为是由一个wiki系统维护，所以在所难免出现参差不齐，风格上也有不统一的情况，翻译时我也是参照原文原封不动的挪了过来，以后我会抽时间改良下。 翻译正文基于浏览器的应用框架一般分为两种：
基于服务器端的应用框架通常以下面两种方式工作(尽管它们根据不同的语言进行了分类)
目录
1. Pure Javascript: Application Frameworks1.1 Bindows (成立于2003年)Bindows是一个通过DHTML、JavaScript、CSS和HTML等技术强劲联合起来的一套完整的Windows桌面式的WEB应用程序解决方案。Bindows无需下载安装客户端支撑组件（如Java、ActiveX或Flash），仅需一个浏览器。纯OO的理念体现在Bindows任何地方，Bindows或许是笔者见过的最完整最强大的AJAX应用程序平台。 Bindows框架提供的功能和特性有：
Bindows开发环境：
1.2 BackBase (成立于2003年)BackBase是一个完整的浏览器端框架，提供了丰富的浏览器操作功能，以及对.NET和JAVA平台的集成。
1.3 DOJO (开发中,成立于2004年9月)DOJO提供完整的轻量级窗口组件和浏览器-服务器消息映射支持
1.4 Open Rico (开发中;成立于2005年5月;基于早期的一个proprietary 框架)Open Rico是一个支持Ajax架构和用户交互的多用途框架。
1.5 qooxdoo (开发中; 成立于2005年5月)qooxdoo，是另一个发展迅猛的应用框架，提供广泛的UI支持，正在开发基础架构等特性。
1.6 Tibet (开发中; 创建于2005年6月)Tibet提供了大量的易移植和完整的JavaScript API，通过这些可以快速生成大量的客户端代码，Tibet自称是企业级AJAX。
1.7 AJFORM (创建于2005年6月)AJFORM是一个极易上手的AJAX框架，被用来编写入门级的AJAX代码，提供有以下功能：
2 Pure Javascript: Infrastructural Frameworks2.1 AjaxCaller(创建于2005年5月，目前是Alpha版)AjaxCaller是一个具有多线程安全访问的XMLHttpRequest组件，主要针对Ajax开发新手，目前仍处于alpha开发阶段，仅在AjaxPatterns的在线搜索范例中使用了这个程序。
2.2 Flash JavaScript Integration KitThe Flash JavaScript Integration Kit可以使Flash和Javascript脚本实现相互集成。
2.3 Google AJAXSLT (2005年6月发行)Google AJAXSLT，是一个Javascript框架，用来执行XSLT转换以及XPath查询。
2.4 HTMLHttpRequest(Beta版；创建于2005年)HtmlHttpRequest最大的特点就是运用XMLHttpRequest对象和标准HTML标签IFrame来实现最大限度的跨浏览跨平台的AJAX支持，其原理是在支持XMLHttpRequest的浏览器上调用XMLHttp，如果不支持，就用IFrame来模拟实现异步交互。
2.5 Interactive Website Framework (创建于2005年)Interactive Website Framework定位在浏览器中支持各种各样的AJAX基础应用的开源项目。自称是通过JavaScript、CSS、XML和HTML实现高性能的交互式WEB框架，包括一个可定制易读的XML解析器。实际上，IWF是一个AJAX的基础框架，并且还包括一些通用脚本代码。
2.6 LibXMLHttpRequest (2003年6月发布)libXmlRequest是一个小型XMLHttpRequest封装包
2.7 MAJAXMAJAX是另一个非常小巧的HttpRequest封装包，为收发字符型信息提供简单接口，并为每步动作设置回调界面。 2.8 RSLite (x)RSLite是一个XMLHttpRequest封装组件，作为Brent Ashley的JSRS(JavaScript Remote Scripting)其中的一部分功能单独发布。详情可以看JSRS的介绍 2.9 Sack(开发中，成立于2005年5月)Sack也是一个很有名字的微型XMLHttpRequest封装包。调用者可以自定义回调函数或者是DOM对象。借助于回调DOM对象，可以把Response回来的数据直接以文本的方式嵌入DOM中。 2.10 Sarissa (发布于2003年2月)Sarissa是一个JavaScript API，封装了在浏览器端独立调用XML的功能。
2.11 XHConn (2005年4月发布)XHConn也是一个小型的XMLHttpRequest封装库。笔者也使用改良过的XHConn，其特点就是调用简单，代码也清晰易读。
3 Server-Side: Multi-Language3.1 Cross-Platform Asynchronous INterface Toolkit (2005年5月)CPAINT是一个真正的同时支持PHP和ASP/VBScript脚本的AJAX和JSRS工具包。CPAINT在后台提供你需求的AJAX和JSRS代码，并自动返回到浏览器端相应的Javascript脚本代码，这种方式易于实时反馈需求的WEB应用程序。
3.2 SAJAX (2005年3月)SAJAX的实现方式很独特，例如：调用一个javascript方法x_calculateBudget()，将先把响应传到服务器并调用一个Java calculateBudget()方法，然后以javascript方式把值返回到x_calculateBudget_cb()中。SAJAX的名气不错，估计很多人都听过甚至用过，不过缺点就是它的这套映射理论感觉较繁锁，远不如一些轻量级的封装库好用，不过SAJAX最大的特点就是支持的平台丰富，几乎囊括了WEB下常用的编程语言和平台
3.3 Javascipt Object Notation (JSON) and JSON-RPCJSON是一个"face-free" XML，而JSON-RPC是一种远程交互协议，类似于XML-RPC，对JavaScript支持较强
3.4 JavaScript Remote Scripting(JSRS)(2000年)JSRS，较经典的远程脚本访问组件，支持将客户端数据通过服务器做代理进行远程的数据/操作交互。
3.5 Bitkraft for ASP.NETBitkraft是个基于(.NET)Web框架的CLR(公共语言运行库)，允许用独特的方式创建和操作分布式Web内容。用C#编写，运行在微软的.NET 1.1和Mono框架下，无缝式的客户端-服务器响应方式是它的最大特点。Bitkraft没有使用XML组织数据，而是用JSON代替。
4 Server-Side: Java4.1 WebORB for Java (2005年8月)WebORB for Java是一个开发AJAX和基于Flash的富客户端应用程序的开发平台。在线例子
4.2 Echo 2 (2005年3月)Echo 2允许你用纯Java语言编写AJAX程序。 Demo.
4.3 Direct Web Remoting (DWR) (2005)Direct Web Remoting可以在Javascript代码中直接调用Java方法的应用框架
4.4 SWATO (2005)SWATO是一套可重用的和良好集成的Java/JavaScript库，它实现了一种更容易的方式来改变你的web应用程序的交互，通过AJAX方式实现。
4.5 AJAX JSP Tag LibraryThe AJAX JSP Tag Library是一组JSP标签库，用来AJAX程序开发。可以在J2EE下无需Javascript就能轻松开发AJAX模式的Web Form。标签库为比较通用的AJAX功能提供了5个标签：
4.6 AJAX Java Server Faces FrameworkThe AJAX-JSF用来把任意的JSF应用程序转变为AJAX应用程序
Server-Side: Lisp5.1 CL-AjaxCL-Ajax实现Javascript直接调用服务端Lisp
6 Server-Side: .NET6.1 WebORB for .NET (2005年8月)WebORB for .NET是一个用.NET和XML Web Services方式开发AJAX和基于Flash的富客户端应用程序(在线例子)
6.2 Ajax.NET (2005年3月)Ajax.NET是首家支持各种方式通过Javascript访问服务端.net的免费库
6.3 ComfortASP.NET (2005年8月)ComfortASP.NET可以让开发者在纯.NET下开发类似AJAX(DHTML,JavaScript,XMLHttp)特性的应用程序。
6.4 AjaxAspects (2005年8月)AjaxAspects是个可以用Javascript调用服务端WebService事件的引擎
7 Server-Side: PHP7.1 AjaxAC (2005年4月)AjaxAC用一个单独类封装了完整的应用程序功能
7.2 JPSpanJPSPAN通过Javascript直接调用PHP中的函数。
7.3 XAJAXXAjax通过Javascript直接调用PHP中的函数
8 Server-Side: Ruby8.1 Ruby On RailsRuby On Rails是一个支持AJAX的完整Web框架，使用Ruby语言编写，严格按照MVC结构开发。
引自：http://www.huihoo.com/web/ajax/ajax-frameworks.html Web 2.0 编程思想：16条法则原文：Thinking in Web 2.0: Sixteen Ways 1、在你开始之前，先定一个简单的目标。无论你是一个Web 2.0应用的创建者还是用户，请清晰的构思你的目标。就像“我需要保存一个书签”或者“我准备帮助人们创建可编辑的、共享的页面”这样的目标，让你保持最基础的需求。很多Web 2.0应用的最初吸引之处就是它的简单，避免并隐藏了那些多余的复杂性。站在创建者的立场，可以想象Google的几乎没有内容的主页，还有del.icio.us的简单的线条。从最终用户的角度来看，与之齐名的就是Diggdot.us所提供的初始化页面。你能够并且希望加入更多功能，但是先做好最开始的。在一个时候只做一个特性，完成一个目标。这听起来很太过于单纯化了，但它将使你更加专注，而且你也会明白我的意思。 2、链接是最基础的思想。这就是我们称之为Web的一个理由。链接是把Web中各种实体连接起来的最基本的元素。你的信息、你的关系、你的导航，甚至是能够被写成URL的任何内容。这里有一个链接应该遵循的规则（其实你也不必严格的遵守）： 1. Web上的任何东西都是可以被URI或者是URL所连接的。 3、数据应该属于创建它的人。是的，你听我的。任何用户创建的、贡献的或分享的都是他们自己的，除非他们很明显的放弃这个权力来让你自由处置。他们贡献到Web上的任何信息都应该是可编辑的、能被删除的、并且能够取消共享，无论在任何时候，只要用户愿意。这也包含了那些间接的数据，像他们所关心的记录、日志、浏览历史、网站访问信息，或者是任何可以被跟踪的信息。所有的网站必须清晰简单的陈诉那些信息是用户创建的，并且提供他们停止创建的方法，甚至是清除的方法。 4、数据优先，体验与功能其次。无论它是文本、图片、音频还是视频，Web最终还是把这些解析为数据。换句话说，你无法脱离数据去呈现内容。所有这些数据都通过那些易于发现的URL来定位（参见第2条）。通过另一种形式来看待这些，Web最终是名词优先，动词其次，虽然最近正在向动词偏移。来看看名词的例子：日历的条目、家庭照片、股票价格。还有一些动词的例子：定一个约会、共享一张图片、买一份股票。 5、做好积极分享一切的准备。尽可能的分享一切，你所拥有的所有数据，你所提供的所有服务。鼓励不遵循原有意图的使用，提倡贡献，不要那些需要分享的内容坚持设置为私有的。在分享与发现之后，提供易于使用的浏览方式是显而易见的需求。为什么呢：话说回来，你会从别人的共享之中受益匪浅。注意：这里没有许可让你去侵犯版权保护的法律，你不能够去分享你刻录的DVD或者是拥有商业版权音乐，因为你已经同意不会去分享这些东西。但是你可以发现并分享那些完全开放的媒体内容。一个小小的建议，你可以学习一下Creative Commons license（共创协议）. 6、Web是一个平台；要让它成长。当然，我们还有很多其他的平台（Windows、Linux、Mac），但是那些已经不是重点了。换句话说，Web是无法脱离的平台，不会中断的平台，你可以通过各种方式去扩展的平台。你在Web上提供的数据与服务将会成为Web一部分，最终你会在Web平台的某一处扮演你的角色。扮演好你的角色并照顾好后来者。 7、理解与信奉“阶梯性”。现在的Web越来越大，几乎蔓延到了全世界的所有国家，并且已经拥有了10亿用户。我的观点是Web的各个组成部分存在着细微的区别和不同，就像不同地方的用户那样。例如Web的设计部分：易用性永远优先于速度、可靠性、重用性与可集成性。你也应该提供同样的体验给你的用户。它已经被一次又一次的被人们在文档中强调，忠诚的用户很快会成为专业的用户，他们期待更快的速度还有更多。退一步支持他们。同样，也有很多很多的用户会进入这个阶梯的底端，如你所期待的那样。他们可能不会说你的语言，不熟悉你的文化，甚至不知道是如何到这里的。所以你需要向他们表达清楚。 8、任何东西都是可编辑的。或者是它应该被编织的更好。要确定的是，只有很少的东西是不能被编辑的，剩下的都可以，这是一个可写的Web。这并不意味着原始内容的丢失，而通常被理解为用户能够很容易的对内容加以评论，或者评注内容是在那里发现的。如果你对此应用的好，他们能够比你所想象的做的更多（把内容串起来并且给予原始内容来创建自己的，等等）。 9、Web上的身份是神圣的。不幸的是，这并不意味着你能够得到更多的隐私（这完全是上个世纪的想法）。但对身份的验证是必要的，你应该感谢那些只需一个邮件地址就能确定你身份的服务。这意味只要你对你的用户承诺了，你就必须保证他们的隐私安全。必要的时候，在这个世界的某处你还得为你的用户挺身而出，向当地的权威挑战。如果你没有打算那样做，你就得把实际情况告诉你的用户。另一方面，如果身份是必须的，不要试图伪装它，不然在某一天我们将会在Web上放弃我们的最后一点点隐私的权利。 10、了解流行的标准并且使用他们。从一个消费者或者是创作者的立场来看，数据将会以不同的格式与任何一个人交换。同时这样的数据也会反过来促进标准的完善与采纳。这通常意味像RSS、 OPML、XHTML、Simple XML、JSON等简单标准的流行，而避免SOAP、XSD，还有RDF、ATOM也一样，使用它们会给我的内心带来痛苦。请你也为你所钟爱的标准投上一票来支持它们。 11、遵循无意使用的规律。如果你把非常有趣的数据和服务用广泛使用的格式开放和共享出去，你将会得到你所应得的，其他人也将会基于你的那一块Web平台来构建。或许还会从别人那里得到更多，所以为这个做一下准备比较好。我已记不清有多少次我看到一个播客（podcasting）服务因为流行过渡而导致服务垮掉，就是因为他们被 Slashdot和del.icio.us给收录了。这一点要知道：网络上的大量化意味着如果一个内容非常有趣，即使是一个很小的角落也会得到惊人的访问量。鼓励使用这种方式，它还是非常有价值的，前提是你要有所准备。 12、粒化你的数据与服务。我们应该在很早以前就明白这些，大规模集成的数据仅仅适用于无需管理的下载与批量操作。分解你的数据，让他们独立成可描述的URL地址，对你的服务也一样。反过来说，你不要创建一些巨大的、复杂的、像圣诞树那样的数据结构和服务。保持简单，要非常的简单。让这些分离的片断能够容易的被重组和发现。 13、提供用户能够单独受益的数据和服务。渐渐依赖于这种社会化参与是存在风险的，你需要让你的用户有一点点动机来贡献时间、热情和信息，除非他们能够直接受益。社会化分享比个体行为的利益大很多，除非你能够激发用户的个人动机，否这你将无法享受这份厚礼。 14、让用户组织并过滤信息。不一定是必须的，但却是非常重要的。让用户以他们自己的方式来标注和组织数据，因为你自己是永远无法及时的处理他们的。用户会按照他们自己理解的最佳方式来处理并构建。要保证你的Web服务能够按照用户所需所想的方式来工作。这也是标签（tagging）和通俗分类（folksonomies ）的方式如此成功的主要因素。 15、提供丰富的用户体验。Web一直都在和本地的应用程序进行着激烈的竞争。为什么？因为本地程序还是感觉上好一些，速度也快一些。但是这不会长久的（确信在5年或者15年后，这种竞争就不存在了）。是的，我在谈论Rich Internet Applications, Ajax, 还有那些不可思议的交互应用。他们让Web成为了一个真正的“无平台”的平台，如果你知道我是怎么想的。 16、信奉并支持快速改进和反馈。这个通常意味着加快步伐，但也意味着使用轻量级的工具、技术和不要做出那些适得其反的痛苦决定（例如使用一个被层层环绕的Ajax框架来代替可以通过混合来实现的，或者用C++来构建所有的东西，其实使用Ruby会更好一些）。这同时也意味着需要一个非常快速的方式来处理错误报告，修复Bug，释放新版本。从一个用户的角度来看，报告你所发现的任何问题，还有那些你经常抱怨的地方，甚至那些都不是一个Bug。 当然，Web 2.0是一个极其广泛和深奥的话题，没有一个人能够列举出它的所有重点和特征。如果你对此充满了兴趣，请花一点时间来补充我没有提到的地方。我想这就是Web 2.0的参与性吧！ 原作者的这个标题借鉴了Bruce Eckel的两本畅销书的名字：《Thinking in C++》和《Thinking in Java》，《C++编程思想》与《Java编程思想》，在此说明一下为什么要这样翻译这个题目:) indigo 翻译整理 5月7日 Google美国总部探秘创新机制Google总部位于硅谷的山景(Mountain view)城，靠近101号公路。这家全球最大的搜索引擎公司成立于1998年，8年的时间里，它从斯坦福大学两位没有毕业的博士生创办的小公司，发展成市值超过1000亿美元、拥有7000名员工的企业。虽然101号公路附近已经有21栋建筑成为Google的办公室，很多上班时间来得稍微晚些的人还是不太容易找到车位，公司停车场的管理人员不得不经常挂出“车位已满”(Full)的牌子。 走进Google总部的办公室，就像走进了一个食物丰盛、玩具多多的小游乐园。据说当年Google公司最初创业的那一段日子里，大家非常忙碌紧张，为了工作，吃饭往往就是用快餐随便应付一下，没有时间锻炼身体，没有时间洗衣服。所以在公司发展到一定阶段之后，Google给员工提供了种类丰富的免费餐饮，在公司里随处可见的是各种体育器材和休闲设施，还有专门的洗衣房和按摩室。 互联网产业变化迅速，Google的发展速度也很快，在这个需要不断创新的产业里，很多人都会有这样的疑问：一家几百人的小公司也许可以灵活多变，一家在短短几年内就膨胀到7000多人的企业，如何还能不断创新呢？换句话说，在这样一种轻松、活泼、舒适的环境里，一个人是会变得更为勤奋呢，还是会慢慢变得懒散无聊呢？ 小团队与自下而上的创新 “你们有多少服务器？”“很多，但永远不够。” “互联网的下一个大事是什么？”“这很难说。” “你何时去中国？”“明年吧。” “最近在忙什么？”“开会！总是有很多的会。” 在短暂地接受中国记者采访的时间里，谢尔盖·布林的回答像Google的主页面那样简单直接。1998年他和拉里·佩奇一起创办Google。也许在他们的观念中，对于企业管理和运作，并没有那么多的条条框框。这两位创始人有着浓重的理想主义色彩，在与工程师一起讨论产品的时候，经常会问这样的问题：“这对世界有什么好处吗？”“世界会因此而变得更美好吗？”有时候，正是因为这样的问题，很多在商业上有利可图的项目最终因不能得到批准而搁置起来。 Google的使命是“整合天下信息，让人人能获取，使人人能受益”，无疑这是一种极具理想主义色彩的使命感。但是Google轻松舒适的企业文化能够承载这样的使命吗？也许在看似轻松活泼的氛围下面，是另一种文化。 “雇用最出色的计算机科学家，将有智慧有激情的员工针对关键问题分成3～5人的小团队，扁平化的组织，海量的计算资源和数据的支持，工程师有20%的时间可以根据自己的兴趣自己确定研究方向。”这些是Google组织结构的基本原则。Google 地图的技术来自 澳大利亚的俩兄弟，其中的一位不愿意离开澳大利亚，为了能让他安心工作，于是Google就在那里专门为其开办了一个研发中心。 小团队的工作方式也许蕴涵着一个基本假设：聪明人大多比较要面子，不想被别人看不起。所以一个聪明人或许会在庞大的组织中很快找到“混”下去的方法，但是在有3～5人组成的小团队中，却必须全力以赴才能被大家认可。这样一来，Google甚至不需要像很多企业那样对这些人做复杂的绩效考核，团队中的成员彼此非常了解，相互打分也不会很离谱。 Google的工程师可以将自己创新的点子放在内部的网络交流平台上，所有的人都可以对这些点子做出评价。工程师可以利用自己20%的时间将这些点子落实为具体的产品。从整个公司的层面上来看，Google有TOP100的项目，用来评价正在进行的各个项目。这在某种程度上就将所有员工调动起来，一起考察决定公司未来的各种研究项目。当这些由好点子发展而来的产品足够完善的时候，它们会被放在Google Lab里，这是一个向用户展示Google创意和产品的地方，同时用户的体验和反馈对这些还未正式推出的产品来说也是非常宝贵的建议。 这种自下而上的创新方式给Google带来了很多新奇的点子，带来了新鲜的创意和活力。而这些是一家快速发展的科技公司最宝贵的创造力所在。这可以看作是Google互联网民主观念在公司内部的一种贯彻。由于有众多工程师的参与，Google也就可以尽量地减少管理的层级，使整个组织更为扁平。每年公司都会有高达1000万美元的创业大奖，给那些对Google未来发展有重大意义的产品和项目。 小团队作战，民主的项目评价方式和高额的激励政策，在某种程度上将Google变成了一个创新的实验室，在硅谷这样一个创业氛围浓重、到处是风险投资商的地方，Google也许就是一个非常不错的技术孵化器。 20%法则与“笨”办法 3M公司给自己的工程师15%的时间来从事自己感兴趣的研究工作，在无数的研究创新的书籍中，这几乎成为一个必须提到的标志性数据。但问题是谁也不知道这15%的时间是如何分配的，在这种时间框架中工作的工程师是如何被考核的。 Google更加慷慨，给工程师20%的自由时间。事实上，从很多工程师的工作量来看，20%的自由支配时间并不那么容易安排出来。而很多工程师利用20%的时间做出来的东西的确很有创意。那个用来形象直观地显示全球搜索状况的在电视屏幕上不断滚动的地球仪，就是一位印度裔工程师利用20%的自由时间设计出来的。此人刚进Google的时候，曾经要求与CEO埃里克·施密特分享一间办公室，这个要求居然被埃里克同意了，两人大约有半年的时间在一间办公室里办公，直到办公室重新调整，他才搬出CEO的办公室。 在Google办公室的楼道上有两个空空的衣柜，会有专人不定期地将免费发放的带有公司LOGO的T恤衫放在这里。为了得到这些令人喜欢的T恤衫，一位工程师利用20%的时间开发了一套系统，他在楼道顶端的墙角处安装了一个摄像头，将摄像头与自己的计算机相连接，然后通过一个小程序自动监控，一旦发现有人在放T恤衫，系统马上就会提醒他并且会自动向他的好友发出电子邮件，提醒大家赶快到衣柜前拿衣服。 也许，你会觉得这位工程师实在是小题大作：为了得到几件免费T恤衫，要动用这么多高科技手段！但是这也许在一定程度上代表了Google的一种精神：懒惰的技术天才。他们觉得有些事情如果能让机器自动解决，就让机器去完成。Google的新闻服务据说是一位工程师突发奇想的产物。每隔一定时间，它会自动抓取互联网上的新闻，集成在一起，推送到用户那里，这样就可以不用在互联网上到处寻找也能得到非常及时的新闻服务了。 但是，从另一方面来看，Google工程师的思维方式又显的有些“笨”。当年拉里·佩奇和谢尔盖·布林在斯坦福大学测试他们自己的搜索引擎的时候，曾经向当时互联网上所有能够找到的网页发出链接邀请，为此在一段时间里仅仅他们的工作就占用了斯坦福大学一半以上的互联网带宽资源，还招来很多不明就里的公司的谴责，以为是斯坦福大学的黑客在做怪。正是基于对海量数据的收集、分析和整理，使他们的搜索引擎功能更为强大，使用也更为简便。这种传统到现在依然在发挥作用，按照Google负责公司产品研究和发展事务的工程部副总裁艾伦·尤斯塔斯博士(Dr.Alan Eustace)的说法，“一吨的数据好于一盎司的运算法则”。也就是说，技术的关键在于高效运用计算资源处理以数量级为单位猛增的数据，在数据量相对有限时，一些简单的方法看似失败，但这些方法却能在拥有海量数据的情况下变得有效。 目前，Google在机器翻译领域采用的就是这种做法。他们首先要做的是基于Web的翻译数据模型，然后运用决策理论做出决定(也就是得到翻译结果)。在他们所进行的阿拉伯语对英语的机器翻译测试中，经过21.9亿单词网络数据训练过的语言模型做出的翻译与人工翻译非常接近。 如今的Google的产品已经从当初单纯的搜索服务扩展到新闻、地图、图书等多个领域，并且开始全球化运营。如何在全球化运营中保持创新文化的活力，如何在众多的产品和服务中保持“不做恶”的信条，这对于只有8年历史的Google来说，将是一个考验。 |
|
|
