微信号:hackerline

介绍:精选Hacker News内容.

甲骨文业务再次动手,欲对Java加以扼杀

2016-07-08 12:12 Hacker时间

甲骨文公司对于Java EE的沉默态度已经将开发者社区的不信任感激发到白热化程度。

相信大家早已经发现,甲骨文公司正悄悄从社区驱动型技术项目中撤出资金援助与开发资源,只留客户与合作伙伴对其进行推动与维护。理由自然非常明显,甲骨文无法从这类项目中获取充足的经济收益。

这类套路对于甲骨文已经不是新鲜事,其向来会通过此种方式将开源项目转化为专有技术成果,当初的OpenSolaris与OpenOffice.org都经历过同样的命运。而这一次,噩运降临到了Java头上——更具体地讲,是Java企业版(即Jave EE)。作为服务器端Java技术,其已经成为无数互联网与商务应用程序中的重要组成部分。事实上,Java EE甚至在众多非Java应用中也占有一席之地。

最近几个月以来,甲骨文公司的律师团正在法庭上针对Android Dalvik编程语言中使用Java接口一事猛击谷歌,而这无疑会给甲骨文自身的Java开发进度造成影响。在Java EE方面,甲骨文公司则采取了全面停滞的态度。这种死一般的沉寂令众多为Java平台做出贡献以及参与Java技术社区的企业客户感到极度不安——其中也包含相当一部分甲骨文公司的大型客户。

甲骨文公司内部负责Java EE项目的员工告知社区内的其他成员,他们已经接到命令转而进行其它方面的研发。另外还有一份来自各位为Java平台开发fork版本的Java EE开发者的公告,指出他们决定将自己的实现成果拆分出来,即放弃与甲骨文于六年前收购得来的、已经拥有二十年发展历史的Java平台间的兼容能力。目前甲骨文公司对于Java EE的发展规划仍然一言不发,完全无视Java标准社区成员们的激烈情绪。

“他们的行为无异于玩火,”Java社区进程执行委员会独立当选成员Geir Magnusson在接受采访时表示。“这实在令人震惊——正是这家公司让我们越发思念已经消失的Sun。”

Magnusson指出,甲骨文公司如今的作法类似于当初的“苏俄政权”,其整个决策流程完全不具备透明性。不过根据熟知甲骨文方面内情的消息人士透露,目前公司董事长Larry Ellison对全部争论都心知肚明。而为了在法庭上与谷歌公司正面对抗,甲骨文方面的高管已经撤销了对Java EE技术团队的资金援助。

而伴随着甲骨文公司的闷声作大死,除了Java EE之外,整个Java社区也开始对其进行口诛笔伐。一个名为Java EE护卫队的组织目前就在进行公共关系交涉与请愿活动,旨在向甲骨文施加压力以督促其继续推动Java EE发展或者将其设置为免费项目。不过由于甲骨文公司对于Java拥有极为明确的知识产权掌握能力,因此其胜算极为渺茫——特别是考虑到甲骨文还在对谷歌方面进行起诉。

已经于今年3月离职的甲骨文公司前Java布道者Reza Rahman如今成为Java EE护卫队组织的一名发言人。“截至目前,我们从Java EE规范负责人处获得的惟一回应就是,他们无法继续推进相关工作,”他在采访中指出。“他们甚至没有透露还有哪些进一步工作可以进行。”

Rahman认为,如果甲骨文公司继续对Java EE进行雪藏,那么“Java社区与整个行业都将面临着短期与长期风险。Java与Java EE已经成为全球大部分IT领域所普遍依赖的技术手段。”Java生态系统是在过去二十年中逐步建立完成的,其开放标准也得到了众多厂商的支持,“亦关乎到我们每个人的生计,”他解释称。如果没有持续注资与管理作为支撑,Rahman表示“Java生态系统中的各个部分都将随时间推移而不断弱化,而且整个IT领域都将在短期内受到影响。”

在报告这一事件的同时,相关媒体还试图与数十名熟知Java开发工作的前任与现任甲骨文公司员工取得联系。另外,其还接触了多位甲骨文客户,希望了解他们对此事的意见。然而截至目前尚未有任何确切结论传出,在大多数情况下受访者担心自己的言论可能被甲骨文方面的律师团抓到把柄。

另外,媒体方面还多次与甲骨文公司的媒体关系团队进行交涉,然而得到的回应除了语音助理之外再无其它,语音邮件与电子邮件也毫无回音。在联系到一名直接负责该平台的评论人员之后,对方的答复非常简单:“抱歉,不接受采访。”

Java开发者噩梦之四

甲骨文公司的贪婪天性早已经成为业界的笑柄。在2015年的JavaOne大会上,前任Sun Micosystems公司CEO Scott McNealy就在Java二十周年纪念活动中放出了一段视频,提出极为讽刺的“Java开发者的十二大噩梦”,而其中第四条正是“你热爱开源软件与分享精神,但却在给甲骨文干活。”

这一条令在场的Java开发人员们捧腹不已,但个中辛酸恐怕只有这些从业者才能体会。鉴于甲骨文公司以往在处理开源项目时的恶劣表现,特别是一路搞垮的众多技术成果,人们不禁要为Java的命运捏一把汗。就在JavaOne大会结束后不久,甲骨文公司的表现就印证了开发者们的担忧——其在实质上停止了推出Java的下一企业版本,而Java SE 9作为下一代核心版本的发布日期也被延后至2017年。

视频长2分25秒,建议在Wi-Fi环境下打开。前任Sun Microsystems公司董事长兼CEO Scott McNealy在去年十月召开的JavaOne大会上向Java开发者们公布了一系列坏消息。

甲骨文方面长久以来一直坚持扮演着技术大反派的角色,特别是在收购一Sun Microsystems并获得了其下各开源软件的所有权之后。从交易公布的那一刻开始,很多人就担心Sun公司执着于推动开源项目发展的精神会被破坏殆尽,最终成为甲骨文实现供应商锁定的另一种手段。而包括XML标准联合缔造者Tim Bray在内的多位Sun公司内部开源人才也在收购完成前选择离职。

然而事实证明大家的担忧并非空穴来风。甲骨文公司很快榨干了Sun旗下各开源方案的剩余价值,并迅速叫停了OpenSolaris操作系统的升级工作。在过去三年当中,甲骨文公司通过一系列举措对那些无法实现盈利或者主要由开源社区负责支持的项目进行了打压:

甲骨文与开源项目间的恩怨纠葛

2009年12月,MySQL缔造者Ulf Michael “Monty” Widenius发起请愿活动,要求欧盟监管机构阻止甲骨文收购MySQL的持有方Sun公司。Widenius预测称,甲骨文公司一旦完成收购,将很快对MySQL中的部分组件进行闭源。

2010年1月,甲骨文公司完成对Sun Microsystems的收购。

2010年2月,甲骨文公司将OpenSolaris移出产品路线图。

2010年3月,开源负责人Simon Phipps离开Sun/甲骨文公司。

2010年4月,Java之父James Gosling离开甲骨文公司。他随后将该公司形容为“对道德的挑战”。

2010年8月,甲骨文公司发布备忘录,告知员工OpenSolaris将被中止,而Solaris与ZFS则被“关闭”;OpenSolaris理事会被解散;OpenSolaris与ZFS“完全开放”fork版本Illumos启动;多位MySQL技术团队成员跳槽前往Rackspace公司,加入MySQL另一fork版本Drizzle的开发项目。

2010年9月,OpenOffice.org社区成员考虑到OpenSolaris的开发前景与甲骨文对开发者规模的缩减而建立The Document基金会,旨在针对甲骨文旗下品牌开发LibreOffice fork。基金会成立后,他们曾邀请甲骨文加入成为其成员。

2010年10月,甲骨文公司以“利益冲突”为由要求部分The Document基金会成员离开OpenOffice.org项目,同时拒绝加入该组织;LibreOffice正式启动并以fork形式进行开发;甲骨文公司对原Sun Grid Engine高性能计算平台进行闭源,同时将开源维护人员转移至Open Grid Scheduler项目。(四个月后,整个Grid团队离开甲骨文并加入Univa。)

2010年12月,Apache基金会在甲骨文公司拒绝将Apache技术兼容套件许可纳入Java的Apache Harmony开源实现方案之后,决定辞去Java社区进程执行董事职务。

2011年1月,甲骨文公司注册“Hudson”商标,即开源Java持续集成服务器平台的名称(社区投票将该项目重新命名为‘Jenkins’)。甲骨文公司此后继续内部开发自己的“Hudson”项目。

2011年4月,甲骨文公司停止对OpenOffice.org与OracleOpenOffice的开发。两个月之后,该公司将代码捐赠予Apache。

2011年9月,甲骨文公司宣称将发布MySQL的专有扩展版本,且该项目将不再以完全开源形式出现,而选择“开放内核”模式。

2013年6月,甲骨文公司将Berkeley DB的开源版本许可由BSD类公共许可切换为Affero GPL许可,其要求用户将自身应用的源代码提供给任何通过网络与之联系的对象,同时在代码中遵循GPL v.3或者APGL许可。此举被广泛视为一种威胁行为,意味着甲骨文要求客户购买其商用许可来构建自定义应用,而这无疑给Berkeley DB造成了致命打击。

视频长64分3秒,建议在Wi-Fi环境下打开。Joyent公司的Bryan Cantrill向Larry Ellison大唱颂歌——前者目前负责Illumos,OpenSolaris的一套fork版本。

夺取所有权

即使大规模削减开源项目投入力度,甲骨文公司仍然在为Java提供资金。事实上,作为独立企业运营的Sun公司在其最后阶段已经无力维护Java项目,甲骨文的介入则让其重新恢复了生机。

“Java SE其实真的很不错,”Eclipse基金会执行理事、前任甲骨文公司副总裁兼Java社区进程(简称JCP)执行委员会成员Mike Milinkovich表示。“我们多年来一直停滞在Java 6时代,甲骨文方面接过了火炬并将其传递至Java 7与Java 8,不久的未来还将出现Java 9。我认为他们在重构建这套平台并立足于Sun的开发基础加以改进方面做出了卓越的贡献。”

至少到目前为止,对Java SE最新版本的开发投入仍在继续——即Java SE 9,代号为Jigsaw项目。这一迭代版本将对Java运行时进行模块化改造,同时使其更易于对接嵌入式设备。“Java SE9版本的重要性是毋庸置疑的,”Milinkovich解释道。“因此,大家至少不应对甲骨文公司在Java SE身上的投入与领导能力有所非议。”

不过除了这部分投入之外,甲骨文公司也对Java的发展议程加以直接控制。甲骨文公司员工几乎接掌了与Java相关的全部提议规范,同时为OpenJDK的开发提供了大多数人员供应——其属于Java SE平台核心的开源参考实现方案。“OpenJDK是一套开源社区,”Milinkovich表示。“但其并未实现供应商中立性,或者说无法在这方面与Apach或Eclipse相媲美。”

这种自上而下的控制已经引发了先前Java社区成员的广泛反对。作为Java的缔造者,2010年离开甲骨文的James Gosling在他的离职信中写道,“我能说的就是,在这里靠谱与诚实的行为只会受到抨击而非鼓励。”他随后在接受采访时表示,甲骨文公司的Java团队管理层不愿出让任何决策权。Gosling当时扮演的角色就像一位参加体育会展的退休球员,换言之而像是吉祥物而非核心技术人员。

几个月之后,甲骨文公司对Java开源命运的全面掌控让Apache基金会放弃了其在JCP EC中的席位。与当初的Sun公司不同,甲骨文方面拒绝向Apache Harmony开放Java虚拟机(简称NVM)出售技术兼容套件(简称TCK)。结果就是,甲骨文公司禁止Apache将其Harmony项目称为“Java”。

当时Magnusson正是Apache基金会在JCP的代表。他回忆称,甲骨文公司的决定确实出乎所有人的意料。“甲骨文方面直到收购Sun之前,都与我们站在同一阵营,”他解释道。“他们也是我们购买TCK的最大支持者之一。”

Apache基金会通过投票方式抨击了Java SE 7的规范设置,而这无疑挑战了甲骨文公司的领导权。Apache方面宣称,甲骨文公司违反了Java社区进程本身的执行章程。“甲骨文公司拒绝针对任何合理性及责任问题向欧盟委员会做出回应,”时任Apache市场营销与宣传副总裁的Sally Khudairi表示。

锁定

甲骨文公司不断否决着要求对Java授权方式做出变更的各类申请。在最新一轮尝试中,技术社区要求对JCP的结构进行重组,但却被甲骨文公司的律师们拒绝。该法务团队警告称,任何针对授权许可做出的变更都可能引发严重后果,而与此同时谷歌也正因此而麻烦缠身。

另外,甲骨文公司的OpenJDK开发者们也在极力阻止JCP对Java标准的治理。这群开发者们在未经JCP许可的前提下直接为该平台创建了一系列新型组件。JCP EC与部分OpenJDK社区的非甲骨文成员就此展开据理力争,因为他们担心JCP会最终被甲骨文架空为毫无实际掌控能力的傀儡。

“随着越来越多新的开发方案被纳入到OpenJDK这套开源项目中来,JCP在领导Java发展方面的价值已经被不断削弱,”Milinkovich指出。尽管他在JCP担任职务,但Milinkovich仍然认为这算不上什么“大事”。

“作为运营开源社区的参与者,我认为这方面工作的价值就在于开放,”他表示。“不过确实需要针对一部分问题思考解决办法,包括OpenJDK社区的角色、开源的未来发展以及标准层面的变化等等。”

除了JCP方面的担忧之外,关于Java EE的非议之声则更值得关注。群众的不满开始于甲骨文公司停止GlassFish的商用支持与内部开发——其为Java EE的开源版本,并曾作为该平台的参考实现方案。尽管失去了商用支持,Open Glassfish仍然曾经由甲骨文方面的员工进行推动。Java EE 7以及GlassFish开放方案随后于2013年6月12日推出。

而在接下来的一年中,Jave EE似乎也得到了推动——2014年年内,大部分活跃Java规范请求都集中在Java EE领域。在2014年的JavaOne大会上,甲骨文与JCP正式发布了Java EE 8。双方还设定了发展目标,其规范方针直接部署至2016年9月。

CEO对云计算全力以赴

2015年,甲骨文公司瞄准了其业务新支点,即云服务的销售力度,并计划从Java开发工作中划分出相当一部分预算——特别是Jave EE与GlassFish团队。就在那个时候,甲骨文公司正式宣布Java EE 8发展路线图被推迟到“2017年上半年”。

同年8月,Java EE团队由于数个开发项目存在问题而被直接叫停。甲骨文公司高管团队在探讨之后,认为数据库与中间件产品在2015年8月的当季度中营收表现不佳,并随后关闭了Java EE开发项目。甲骨文公司高管决定进一步推进自身云业务,同时辞退了原本负责开发事务的高级副总裁兼Java EE支持者Cameron Purdy。有报道称,这是因为Purdy强烈要求甲骨文方面恢复Java EE团队的资金投入。

Purdy并未对这一说法做出任何评论,不过在当时的一篇推文中,他开玩笑地表示甲骨文公司放他回家之后,他可以考虑参选美国总统。


此次裁员外加业务优先级的变动也直接体现在了各Java项目,特别是Java EE项目当中。此后得到解决的问题数量开始骤减,多数项目的代码提交量也大幅降低。Java Server Faces(简称JSF)的新规范号称直到2016年第一季度才能与广大用户见面,但事实证明其截至当下仍踪迹全无。

在同年4月的JCP执行委员会会议上,Java EE进度缺失被提入了议事日程。代表伦敦Java社区的Martijn Verburg表示,针对Java EE的工作早在上年11月份就已经告停。“就目前的情况看,甲骨文领导下的Java EE JSR明显已经没有了继续发展的迹象,”Verburg表示。在会议纪要中同时提到,“甲骨文公司的几位规范事务负责人也明确表示,他们无法再在JSR项目身上投入任何时间与精力,而是被分配到了其它项目当中。”

坚决不予回应

甲骨文方面坚决不予回应的态度“正对Java社区与生态系统造成严重的损害,”Verburg强调称。他同时补充道,“有关各方”正在积极讨论Java EE的未来发展并“考虑接管Java EE的领导工作”。由于缺少甲骨文方面的官方引导,各企业不得不利用自己的专有框架满足各实际需求,例如在Java社区中实现微服务支持能力。

“我们需要甲骨文公司给出的官方声明,”Verburg指出。委员会中的富士通公司代表Mike DeNicola也对此表示赞同。如果甲骨文公司一直不对JCP EC就Java EE提出的公开声明做出回应,那么其会“严重影响到甲骨文在JCP中的声誉,”DeNicola告诉我们。

来自甲骨文公司的JCP主席Patrick Curran表示,他“一定会将EC内部的态度与意见传达给甲骨文管理团队。”Curran同时建议称,“我们会等待并观望‘分裂集团’关于Java EE的最终决定”。

截至目前,甲骨文公司仍未发表公开声明。相关社区则对此感到非常无奈。甚至包括部分在JCP拥有代表的金融服务企业——例如瑞士信贷——也开始表示高度关切。Java EE护卫队(也是JCP会议上的主要‘分裂集团’代表)已经启动了Change.org抗议网站,意在收集来自技术人员的请愿意见。最近,在JCP执行委员会会议上,Verburg提出了已经愈发普遍的观点。甲骨文公司对于社交意见视若无睹的态度,已经基本证明“其不再关心Java生态系统的支持事务。”

Verburg指出,他的公司未来将不再使用Java EE,因为其无法随甲骨文中止项目发展所带来的隐患。而根据会议记要,Magnusson也指出“JCP EC成员已经公开声明称,他们不承诺在未来继续使用Java EE。”

然而,事件目前仍然处于僵持状态。甲骨文公司继续保持沉默,拒绝针对JCP的未来规划发表任何意见。缺少官方引导让Java EE社区不得不积极猜测甲骨文的意图,并被迫为最糟糕的结果做好准备。

Milinkovich认为,发生这一切的根源在于,甲骨文就是甲骨文。“甲骨文公司最擅长的手段——先不论其好坏——就是制定并坚守决策,”他指出。而由于甲骨文公司的巨大体量,这类决策恐怕要持续相当长的一段时间。“我可以想象,甲骨文方面内部正在就此进行研讨,我也希望在今年的JavaOne大会上,社区能够通过交流敦促其完成决策——因为我认为如果无法在JavaOne上给出任何与Java EE发展路线图相关的情报,相关领域将瞬间爆炸。”

游戏结束

甲骨文公司其实有着大量相当充分的理由以继续坚持对Java EE的控制——其中最重要的就是,甲骨文自身也有很多软件产品与服务依赖于Java EE。尽管Java EE并不像Java SE在甲骨文的发展战略中占有重要地位,但其仍然间接为超过七成的营收做出贡献,具体包括软件与支持许可销售。

Java EE护卫队的Rahman表示,他真心希望甲骨文方面能够回应该组织与整个社区提出的质疑。“需要强调的是,我们的努力从数周前才真正开始,”他指出。“在此之前,我们一直在尝试组织社区以及除甲骨文外的其它主要供应商,例如IBM与红帽。甲骨文公司应该还有很多时间跟余地来调整其行动方针。”

展望未来,该护卫队希望了解甲骨文公司是否还将继续作为Java EE的合作伙伴而存在。如果甲骨文方面选择退出,那么Rahman认为还会有其它厂商愿意接手Java EE。“JCP中的其它厂商,例如IBM与红帽,都能够承担起这份责任,”他表示。“这些厂商也都向甲骨文传达了目前状况的紧迫性,并表示问题需要尽快得到解决。他们也愿意帮助甲骨文收拾这堆烂摊子。”

然而也有不少人认为,甲骨文公司不可能针对目前的压力做出回应。“我认为他们的努力很难收到实际效果,”Magnusson坦言。“甲骨文公司绝不是那种愿意任他人摆布的企业。”

当然,甲骨文公司可能只是决定暂时搁置Java EE,而且不会让任何人夺走其所有权……但由此产生的影响将远远超出企业级Java社区。事实上,目前甲骨文对于Java项目的态度之所以受到广泛关注,是因为Java已经被视为最完美的物联网实现工具。

甲骨文公司目前最理想的选择,Rahman建议道,“就是将整套Java平台捐赠给Eclipse基金会、Apache、ECMA或者W3C这类组织。在那里,其它厂商以及技术社区都能够参与进来并推动其发展。”不过甲骨文公司真的会心甘情愿地将自家技术成果拱手让人吗?

Milinkovich对其可能性提出了质疑。“我认为甲骨文公司几乎不可能将Java交给其它组织进行自由开源,”他解释称。“这是因为甲骨文需要对其股东负责,而将一项价值数十亿美元的资产凭空进行开源是无法接受的。而且我们也不可能指望着一拍脑袋进行开源,Java面临的种种难题就能迎刃而解……这显然不切实际。事实上,具体解决方案应该更为细化,其核心内容不只是进行开源,而是考虑如何利用开源手段治理项目并满足技术社区的实际需求。”

考虑到甲骨文公司仍然需要Java企业资源支撑其云项目,可能其计划围绕内部云服务对Java企业版进行大规模调整。如果甲骨文公司不再允许JCP染指Java EE,那么该项目的最终命运也许会同LibreOffice一样。

而在最糟糕的情况下,甲骨文公司可能决定不再开发Java EE并拒绝任何企业或者组织接手该平台的后续开发。对于这样的情况,Magnusson提出了一个简单的问题:“甲骨文公司是否认为这种坐以待毙且鼓励竞争对手推出替代性方案的作法真的对自身有利?如果选择这种方式,竞争对手是否可能从中获得助益?换言之,其可不可以继续推动项目以实现对竞争对手的打压?”

鉴于甲骨文公司以往一直对竞争对手采取寸土必争的战略,因此这种“我没有、你也不能有”的决定倒并非全无可能。不过这也会对其现有业务产生重大影响,例如疏远了那些支持甲骨文内部部署软件业务的客户。而竞争对手则能够借此拿出足以吸引这部分受众的方案。“我很难想象IBM这类公司会如此对待客户,”Magnusson指出。

Java启示录

如果甲骨文公司仍然以消极方式应对这一切,那么推出速度已经相当缓慢的Java安全补丁将趋于停滞,这意味着Java EE组件将遭受安全漏洞的影响。数以千计的服务器与云应用都将最终尝到恶果,并不得不寻求Java servlets以及其它内置Java EE组件作为替代方案。Rahman表示,如果真的出现这样的情况,那么“作为最后的手段,已经有众多厂商在讨论如何在甲骨文公司与JCP缺席的情况下建立起多厂商Java API,”他解释道。“到那个时候,我们的组织将加入相关工作。”

出于这些原因的考虑,看起来甲骨文公司更可能会吸收其它Java社区进程组织的成员在Java EE的开发工作中充当“规范领导者”,同时继续保持自身对Java SE的掌控能力。“Java SE拥有极为出色的质量,”Magnusson表示。“其对生态系统有着强大的控制力,而且能够以不同的方式将SE资产转化为经济收益。”由于Java EE独立于Java SE核心之外单独起效,因此甲骨文公司仍然能够在IBM或者红帽等厂商接管Java EE规范制定权后继续保证对Java平台发展的总体控制能力。最终,甲骨文公司仍不会被排除在外。

Rahman认为,甲骨文公司也有着明确的财务理由来继续推进Java EE发展——特别是考虑到该平台能够帮助甲骨文方面获得云业务成功。“我认为掌握Java能够让甲骨文的云方案吸引更多开发者并获得客户与业界的信任,”他指出。“对于Java这类获得极大成功的技术方案的拥有者,将其引入云端简直就是种必然的结果。”

然而,说服甲骨文公司相信其中有利可图的过程也许相当困难。由于该公司正在与谷歌方面就知识产权问题进行诉讼,进一步推动项目发展可能会在法律层面给甲骨文对Java的索赔资格产生负面影响。而目前的请愿活动也因此很难起到什么实际效果。正如Sun公司前任首席开源官兼开源倡议前任总裁Simon Phipps在Twitter上所提到,“一切无法对营收产生影响的行为,都不可能得到甲骨文方面的重视。”

考虑到甲骨文公司的利润正不断上升,再加上该公司的两位联合首席执行官分别占据目前技术业界高管薪酬榜的冠、亚军,相信业界呼声很难吸引到其注意。换言之,在出现确凿的经济影响证据之前,Java EE仍将保持目前半死不活的状态。

本文翻译自:http://arstechnica.com/information-technology/2016/07/how-oracles-business-as-usual-is-threatening-to-kill-java/1/

 
Hacker时间 更多文章 编辑器之战: Vim的复仇 HTTP\/2使移动端媒体加载速度提升3-15倍 我们为什么不用SSH登录一切呢? Docker浅析——如何从Vagrant转向Docker Google的QUIC协议:从TCP到UDP
猜您喜欢 【推荐】一个五年开发者百度、阿里、聚美、映客的面试心经 Android Studio打包apk,aar,jar包 全栈 JavaScript 程序员的崛起 用一种有见地的方式分析大数据 每周阅读清单:Android 架构,小工具,Google 能访问了?