编程语言排行榜.docx
- 文档编号:23249141
- 上传时间:2023-05-15
- 格式:DOCX
- 页数:19
- 大小:523.90KB
编程语言排行榜.docx
《编程语言排行榜.docx》由会员分享,可在线阅读,更多相关《编程语言排行榜.docx(19页珍藏版)》请在冰豆网上搜索。
编程语言排行榜
2013年3月编程语言排行榜:
有毒的Java
(1)
2013年3月12日,Tiobe公布了新一期编程语言排行榜。
Java依旧是占据第一的位置,C语言紧随其后。
值得注意的Objective-C持续发力,已经占到了第三的位置。
咋一看榜单,前5条中C#下滑最快,从第3名下降到第五名。
而其他语言都与之前没有变化。
最近一段时间,关于Java安全性的新闻层出不穷。
被伤害的不光是普通计算机用户,甚至还包括苹果公司、美国政府。
此次安全风波波及面之广,恐怕是Oracle始料未及的。
1.黑客利用网页漏洞进行攻击
据国外安全研究机构称,当前的Java版本中包含了一个严重的安全漏洞,可能导致电脑在访问带有恶意代码的特定网页时被感染。
Window系统中的所有主流浏览器都可能被利用并感染,其中也包括Chrome。
该漏洞也存在于苹果最新的MountainLion操作系统。
为此,苹果不得不单独发布Java相关更新,以保证Mac用户的安全性。
素以跨平台性强著称的Java,也让所有运用他的人无处可藏。
2.Java安全机制
Java早期的安全框架强调的是通过验证代码的来源和作者,保护用户避免受到下载下来的代码的攻击。
Java安全模型的前三个部分——类加载体系结构、class文件检验器、Java虚拟机(及语言)的安全特性一起达到一个共同的目的:
保持Java虚拟机的实例和它正在运行的应用程序的内部完整性,使得它们不被下载的恶意代码或有漏洞的代码侵犯。
相反,这个安全模型的第四个组成部分是安全管理器,它主要用于保护虚拟机的外部资源不被虚拟机内运行的恶意或有漏洞的代码侵犯。
这个安全管理器是一个单独的对象,在运行的Java虚拟机中,它在对于外部资源的访问控制起中枢作用。
Java签名/证书机制,可以保障使用者,安全地调用外部提供的jar,防止你信任的jar被篡改。
首先,Java的签名,必须是基于jar包的。
也就是说,你必须将你要提供的class,打包到jar里。
然后,通过Java提供的签名工具(jarsigner)对jar包进行签名,发布。
签名原理:
使用非对称算法,生成一对公钥/私钥。
3.Oracle应对Java漏洞危机
甲骨文软件质量保证经理EricMaurice透露,五个漏洞中有四个存在于桌面系统的JavaWebStart应用和浏览器Java小程序中。
其中三个被通用漏洞评分系统评为10级,这是很严重的事情:
如果Java运行在WindowsXP这种默认以管理员身份运行的系统,那么黑客能够利用这些漏洞完全损害系统的保密性,完整性和可用性;在Linux或者Salaris这类以非管理员权限运行的系统中情况会好一些。
安全研究人员对剩下的一个漏洞也做出过说明,该漏洞影响服务器部署的Java安全套接字扩展(JSSE),基于LuckyThirteen攻击SSL/TLS实现。
新的Java6_update41可以从甲骨文网站下载,而不是J,目前必须手动下载。
但Java6安装程序的更新功能会提示用户下载并安装Java7_update15。
这一切都在甲骨文的计划中。
甲骨文之前在网站上宣布,将启动自动更新帮助Windows32位系统用户完成升级。
甲骨文将加快其对Java的修补速度。
Maurice说,“甲骨文会继续加快Java更新发布速度,特别是帮助解决桌面系统浏览器的Java运行环境安全,以重树安全信誉。
”
其实这次Java漏洞危机并不是第一次,之前2010年也有报道宣称Java漏洞会影响Windows运行安全。
各位用户还是尽量及时更新自己的Java,作为开发语言中举足轻重的语言,Java的安全性还是值得信赖的。
您所在的位置:
开发>行业新闻>2013年3月编程语言排行榜:
有毒的Java
(2)
2013年3月编程语言排行榜:
有毒的Java
(2)
前10名编程语言走势图
20到50名语言排行
下面是第50到100的编程语言排名
(Visual)FoxPro,4thDimension/4D,ABC,AgilentVEE,Alice,Apex,AutoIt,AutoLISP,bc,Cshell,CL(OS/400),Clipper,Clojure,Dart,Dylan,ECMAScript,Eiffel,EmacsLisp,F#,Go,Groovy,Icon,IDL,Inform,Informix-4GL,J,JScript.NET,LadderLogic,LPC,MEL,MUMPS,NATURAL,Oberon,OCaml,Occam,OpenCL,Oz,Pike,Q,REXX,S,sed,Simula,Smarty,SPARK,VBScript,VHDL,WebDNA,xBase,XSLT
专访程显峰:
敏捷在团队中的实践与发展现状
(1)
您所在的位置:
开发>项目&管理>专访程显峰:
敏捷在团队中的实践与发展现状
(1)
专访程显峰:
敏捷在团队中的实践与发展现状
(1)
2013-03-1410:
08小林51CTO我要评论()字号:
T|T
在国外软件企业中,几乎将近半企业是已采用敏捷方法进行开发,随着近年来受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯,IBM等等内部几乎所有的开发团队都在实施敏捷方法。
敏捷开发的流行绝非偶然,因此,51CTO记者采访了AdMaster(精硕科技)首席布道师程显峰,讲解了敏捷开发在团队中的实践以及发展现状。
AD:
2013大数据全球技术峰会低价抢票中
无论是在软件或者管理行业敏捷开发已成为众多高效开发团队的制胜之道。
敏捷开发可以说是在开发中面临迅速变化需求中的一种快速开发能力。
当然,敏捷不仅是简单的快速,而是在开发过程中短周期的不断改进、提高和调整;当然也不仅仅是一个版本只做几个功能,而主要的是突出重点。
在国外软件企业中,几乎将近半企业是已采用敏捷方法进行开发,随着近年来受软件外包和外企的带动,敏捷开发在中国也出现了日渐普及的态势,如腾讯,IBM等等内部几乎所有的开发团队都在实施敏捷方法。
敏捷开发的流行绝非偶然,因此,51CTO记者采访了AdMaster(精硕科技)首席布道师程显峰,讲解了敏捷开发在团队中的实践以及发展现状。
简介:
程显峰,毕业于悉尼大学,《MongoDB权威指南》译者,MongoDB中文社区创始人。
Emacs使用者,Ruby写手,Scheme爱好者。
AdMaster首席布道师,负责团队建设,人员培训,新技术普及,还有一些公司技术PR的工作。
以下是相关的采访实录:
敏捷在项目中的实践
记者:
有些人认为敏捷开发并不适用于水平一般的程序员或团队,您是怎么认为的?
程显峰:
至于敏捷开发是不是用这种程序团队,特别适合训练有素的团队,反过来说,如果不是一个训练有素的团队,实施传统软件工程也会失败,所以我觉得基本的要求是跟原来的一些要求基本一致的,包括沟通能力、协调能力,对于项目变动的控制能力都是一样的,包括传统软件开发当中讲的项目可控,整个项目可复制,同样的资源配比还可以复制这个项目,如果原来的项目这些做得比较好的话实施敏捷项目就会容易一些。
记者:
很多人为了编写易变更的代码,在采用敏捷时,抛弃许多习惯用法,由你的经验出发,如何去看待这个问题?
程显峰:
从我在实施的过程中第一点需要强调的就是大部分跟传统的软件工程还是一样的,现在异化的部分过于被强调了,搞得大家以为是完全新的、不一样的东西,传统软件包括需求管理、进入控制、质量管理、测试体系,这些东西在敏捷里也都要体现、都要实施,而且要求可能还会更高,并不是把一些传统的东西抛弃掉了,既没有进入管理又没有版本控制,几个人一商量就定了敏捷,这是完全的一种误解,而且还是要好的工程基础才能实施。
记者:
所以传统的方法对于程序员的要求还是比较高的吧?
敏捷这样的功能经过修改之后就可以推出一个小的版本?
程显峰:
并不是说推出小版本就要降低难度,这是没有因果关系的,小的版本即使推送上去,如何保证这个小的版本是对的?
你也需要大版本的方法,比如软件测试、进入控制、需求管理,这些东西都得有,你采用控制好它,虽然你推得比较快,看上去可能是一个一个的,如果你要是推的没有章法的话一样也是乱套的,不是你想要的东西,也会造成大量的浪费,我是这么觉得的。
对于一个失败的项目就要说出失败的原因,这才是解决失败项目的办法,敏捷的方法不是,这个逻辑就是有问题的,我觉得这个没什么好说的。
记者:
对于一个失败的软件项目来说,您认为敏捷方法是它的救星吗?
程显峰:
其实我觉得敏捷的方法不是任何失败项目的救星,这是肯定的。
至于失败这个事情,看上去可能是分工的原因,深层次可能是不交流、不沟通的原因。
敏捷比较注重强调沟通互动这些方面,它是有强调这些东西,如果你的问题恰巧是由于不沟通导致的,采用了敏捷的方法可能会有极大的改善,但也非常取决于实施的人和分析的效果。
好多人说敏捷就是一个筐,什么东西都可以往里面扔,实际上也确实有点这个样子。
我觉得敏捷的方法更多的是注重发现问题的框架,就是能让你更快地发现问题、暴露问题。
至于怎么解决问题,原来能解决的就能解决,要是原来解决不掉,谁也帮不了你。
如果原来你有沟通问题,但是很长时间才能暴露出来,这个东西能让你在短时间内暴露出来,那么就有助于解决这个问题。
很多人为了编写易变更代码采用敏捷。
记者:
想要做到敏捷开发,每个团队都要经历这样一个转型期,那么在转型期还需要每个团队根据自身的不同,找出合理有效的解决方法。
你们团队的是如何来解决的?
程显峰:
每个团队都要经历一个转型期,我是倾向于比较温和地对团队进行改进,实施的东西尽量不要让团队有一个明显的转型期,比如版本控制,原来的版本控制提交的力度、上线的流程就是这样,我会给大家介绍一个新的系统,但是并不会太影响大家的工作,适应起来又很快,这样的改进效果是比较立竿见影的,而且影响又是很小的,我特别喜欢的改进是这样的,这种改进不是偶尔一次才会用到的,我特别喜欢这种改进,就是你天天都会用到的,我特别喜欢那种天天都是这么调,但是每天都能省一分钟的。
大家可能都觉得敏捷特别神奇,每天能省百分之二十的时间,现在我还没发现这种现象,我不喜欢这种东西,如果不是特别想省百分之二十的时间的话就不会让大家经历一个转型期,比如你告诉大家一个技巧,每天能省两分钟,这种东西大家天天用的话实际积累下来的效果才是比较明显的,你要是教给大家一个方法,比如能省二十分钟,实际上这种方法看上去是非常漂亮,但它不是什么场景都能用得到,所以我就不太喜欢这样的方法。
现在有一部分也不用敏捷,我也不太愿意教那个部分,就是每天早上例会的时候站在那里说一通。
我也跟他们讲过,他们有的话可以,没有也OK,有些东西我的要求就比较死,比如上线的流程、可控性,我在这个方面的要求就比较死,开不开会对于我的项目没有什么影响,但是上线的流程就不一样,我要往回退的话就要花成本。
对于小的团队来讲真的是可有可无的,因为团队的人都坐在一起工作,未必需要一个站到板子上的形式。
现在有人把形式看得很重,本来例会是很简单的,五分钟就开完了,但是吵起来了,开不完,因为一般都是开早会,吵完以后心情就不好,所以效率就下来了,这也是很正常的,但是你不要想着漂亮的东西,我对漂亮的东西感觉都不实用。
记者:
会不会因为不吵这个架把错误带到真正开发的过程中?
程显峰:
会,所以我们要让在实际的工作当中发挥,其实例会也不是吵架的会,还有很多的会可以发现这个问题,比如通过Review,可以有各种各样的方法去发现,不用拘泥于这种形式上的东西。
其实最难改变的往往是那些小的习惯,比如他就愿意用这个手指头去敲键盘,但是这可能会影响他的效率,他不愿意改。
这种习惯的话改的阻力反而比较小,你让他去开个例会他觉得耽误时间,但是要让他改这个的话他可能会改。
你想他要敲多少?
天天可能都要去敲,这种感觉可能是持续的。
记者:
这种其实是属于比较个性化的调整,每个人的使用习惯不一样,有些人可能喜欢用这个手按着,有些人喜欢用那个手按着,你要主动发现各个人在工作当中需要调整的地方?
程显峰:
我一致认为团队就是一个泯灭个性的过程,而且这一点我是非常讲究的,包括编辑器的使用习惯和配色都有强烈要求,不像别的看上去那么自由,坐在哪里无所谓,但是你用电脑的方式必须是我规定好的。
没有一个共同基础的团队根本就不叫有团队,总有一些东西是有共同基础的,而且一些高效的团队很可能所有的东西都是共同基础,就像特种兵出去打仗,一个手势就得去杀人,你还能问这个是什么意思?
就像我们用别人的电脑,或者在团队当中用其他人的电脑,那些配色习惯都是一样的,我们沟通交流起来就会非常容易。
现在新人如果不配色,直接就卡掉,新人培训就不合格,所以必须要有配色,包括快捷键的使用,不能人家给你一套代码你还慢吞吞的,这会非常影响别人的心情。
因为有些忽悠师天天都去忽悠各种敏捷方法,但又不注重工程实践,不注重观察细节,所以就做不到。
他们不会注重这种实践,比如咱俩是木匠,我天天使完的刀子随手一扔,天天你给我收拾,你也不愿意,虽然我是大牌,但是你也不愿意,这种工作才是能省很多时间的,你说好我也说好,大家都用一个工具箱,这样才能省下很多时间。
我就觉得能省时间的话,就是在任何层面上都是节约和避免浪费的表现,我是这么觉得。
专访程显峰:
敏捷在团队中的实践与发展现状
(2)
记者:
刚才提到你特别关注的除了工作规范和开发规范上的细节,还有就是发布流程?
程显峰:
是这样的,发布流程实际上就像互联网团队的一个核心,就是有一个标志,如果我拿到一个需求,最后到发布有多长时间,这是看整个团队效率的标志性衡量,而且现在很多人都讲敏捷,其实软件度量是一门学问,究竟度量什么大家非常有争议,我感觉我这边没有太多争议,所有的度量尺度都用时间,因为时间是比较公正的,没有差别的,比如你用代码行数,大家就会说了,代码行数不是一个标准尺度啊,你用C写的五百行和用Java写的五百行到底能不能衡量?
你说我用时间,我这里的一秒和美国的一秒是一样的,没有差别,所以所有的东西都应该用时间来衡量,很多东西都可以转化成时间,比如上线效率就可以转化成时间,拿到一个需求到最后推上线就是一个标准的时间,你能在多短的时间之内完成这个事情?
这是你团队效率的一个提升。
还有一个非常重要的提升,就是当你发现线上的东西有问题,多长时间能回退到上一个版本?
我们可以在秒级之内回去,就是一分钟之内退回去,这是整个团队开发效率的一个显著管理,如果你做不到这一点的话,比如你已经发现Bug了,第二天才能把这个更正,其中的时间全部都浪费了,而且对于一个线上系统就是损失。
我是讲比较实在的东西,对于开发系统的把控必须要特别严,怎么才能把控上线的这些东西呢?
就是要把上线的过程和开发的过程、测试的过程全都紧密地联系在一起,是一个整体,而不是把它们割裂。
包括很多传统企业这个方面做得也非常好,并不是敏捷独有的,所有的东西我坚信都不是敏捷独有的,对于优秀的工程实践来讲都是通用的,整个过程都是非常好、非常快的。
记者:
在敏捷方法流程中具体实践的有极限编程(XP)和Scrum等等,Scrum目前团队用的是比较多的,对于极限编程不知道您有没有了解,据我了解很多团队用过Scrum的都不喜欢极限编程的实践方式,能说说您的观点吗?
程显峰:
Scum只是一个简单的沟通框架,所以大家的接受程度会比较高,只是规定了你该在什么时候沟通,该在什么时候反思,早上起来应该怎么跟大家交流,抽张扑克牌估算一下这个东西,Scum只是一个实施框架。
极限编程是大量工程实践的集合,比如极限编程里讲TCB,它是具体让你操作的,比如咱俩就在一块,它是一种具体的工程实践,就是这么做的,具体工程实践大家反感就比较大了,因为跟他以前的做法不一样,而且问题的关键在于实施这种东西最重要的是有一个人带一个人去实施,两个人都不会你就在那儿极限编程,这个太扯了,根本一点用都没有,这种东西就是师傅带徒弟。
比如结对编程,两个人都没结对过,你在那儿结对。
比如本来是一个大锯,你在这边我在那边,大家都没使过这个锯,咱俩就商量这个锯到底怎么拿,所以时间长了以后没有效果,大家马上就对这个不看好,然后就失败了,他们不能带来效果,一般这种东西在成熟的公司里面,他们是极限编程。
就像结对这种最简单了,总共有两种,一种是师傅带徒弟,就是一个Mentor,一个是徒弟在这里学,Mentor一开始会给你演示所有的编程,你就在后面看,Mentor可能会给你提问,等过了一阵你来,Mentor在后面观察你、指导你,然后让你干这些。
这是带新手非常有用的招,很快就能把新手培养出来。
另外一种就是两个人的水平差不多,就是互相干活,一个人负责设计,另一个人负责实现,这是真正的Pair工程模式,那个是教学模式,你就要求两个人合作很长时间,比如我说的设计他不懂,这就玩完了,没法在一起了。
关于你说的极限编程,两个人没在一起合作过,或者两个人都没搭档过,你还在电脑上干自己的,后面的人就特别没意思,没有互动没有交流,这就完了,好多工程实践都是这样的,是跟你平时的编程方法不一样导致的。
这跟大家多数的东西都不冲突,只是原来要开会,现在也要开会,现在规定好了什么时间开什么会,只是轻度地改变了你的东西,所以实施起来非常容易,大家的认可度也非常高,某种程度上见效又比较快,因为它能发现一些具体流程上的问题,比如沟通的障碍、理解需求有问题,或者节拍上有问题,有的部门太快了有的部门太慢了,他们能发现这些问题。
我是觉得这个数据比较难以衡量,因为衡量有意义的必须是在某种固定的场景下,比如对于我这里来讲,我可能会要求程序员开发一个标准模块,或者是条形化的实践,我会这样去衡量,但是对于别人来讲,这个他可能不太Care,就是从实施的角度来讲,你可以看一下王晓明给华为和腾讯做的,你可以看看他的,我对怎么度量这个事情想的不是很多,我是比较相信主观看法的,因为我在实施的过程中是跟他们在一起工作的,不需要用那些数据来告诉我他们已经进步了,他们做外部咨询的就比较Care这个事情,因为他们需要给那些老板写报告,我不太需要这个东西,我对其它的产品负责就可以了。
记者:
当一个敏捷团队工作时,有时透明化的流程会暴露出机构中的问题,而这些问题又被称为敏捷开发流程的过失。
在整个行业中,您们开始遇到这种情况了吗?
敏捷开发会使行业的缺点逐步暴露,从而在各方面招致一些与敏捷开发对抗的反对意见吗?
程显峰:
是这样的,按照我的理解,我觉得暴露问题是个好事,暴露问题就说明这不是一套有效的方法。
为什么丰田要做单件流的系统呢?
因为任何一个环节出了问题,马上就要停掉工作,他是可以以最快的速度发现问题、解决问题,为什么是一键而不是两键呢?
因为一键可以发现的更及时,要求生产线上的所有环节都能严格匹配,有稍微不匹配的地方马上就会跳出来,如果它是一种发现问题的话,我觉得这种很好,不发现才是问题,发现问题不好吗?
我觉得非常好。
当然,你肯定会遭到反对意见,这个我觉得是实施的人应该想清楚的事情,实施什么会遭到反对意见,或者不实施什么会遭到反对意见。
记者:
在实施当中有没有过这样的情况?
程显峰:
肯定会有,这个可以来自于各个方面,但是你要实施的话就要清楚,比如老板什么时候会反对?
不出效益的时候会反对,所以刚开始实施的时候不会去做那些影响步骤的问题,你要先见效,有很多方法可以先见效,但是很多人都不知道,你要实施那些先见效的,这对树立信心、树立威望都是非常有帮助的,你不能一开始就挽起袖子说要怎么干,没有获得之前这些事情是做不了的,我们团队刚开始还好,有些团队你要实施敏捷,或者实施某些具体工程实践的话会有挑刺的,这就跟你实施人员的素质有关了,比如你能说服他就说服,要是说服不了他的话你也没法实施。
比如讲故事,有的人去实施版本控制,他就说要用分步式的传统模式,有些人就说为什么要用分步的?
那么你做一个版本宏观动作,我用这个做一个,我们比一下。
因为技术这个东西很好衡量,大家一看就都明白,它不比了,就实施吧。
你要有手段和信心去实施这个东西,而且你要知道对手是什么,如果你控制不住这个局面的话,以后实施的时候会有各种各样的东西,比如实施测试,测试的好处你有没有给团队看到?
你自己都不会测试,也带来不了什么好处,你就说服不了团队去做这种事情。
比如这里是有框架层面的东西,我特别愿意实施工程实践,因为我对工程实践的把控力特别强,你要是反对我这些东西,我有很多理由去说服你,而且非常容易见效,你要很快地赢得工程技术人员的信任,反而是你实施这个项目大家会很嘀咕,大家会觉得这个家伙到底写没写过代码?
是不是只会这些?
因为它不涉及到任何技术细节,工程实践就不一样了,你说代码这么写不合适,那你就得说出不合适的道理,你要那么设计的话就是一种技术的对抗。
其实遭到反对意见不光是敏捷遇到,干什么事情没有反对意见?
没有反对意见的事大家早就做了,也不需要其他人。
记者:
其实我想了解你们开发的反对意见。
程显峰:
在我看来大部分的意见其实是一种固有思维的反应,就是他们固有模式的一种反应,以及固有的工作习惯不愿意改变的反应。
问题是这样的,他是没有见到你要实施这种东西的好处的前提下会跳出来反对,你要做的事情是要证明这种东西会给他带来利益,比如刚才说的那种,你用你的版本控制,我用我的版本控制,你自己本身有非常丰富的经验,你看到别人那么做就能很清楚地知道这样做肯定是简单或者容易,他才不比了,要是知道自己一定会赢的话肯定会比,肯定是他实施的新东西对他来讲是有好处的,但是他又不愿意付出改变的成本,又不愿意让大家明确地见到这种好处。
因为团队的人要是都知道这种好处你就没法演下去了,所以很多事情要把它透明化,就是不存在那种边边角角的东西。
当然,阻力是各种各样的,最好的方式就是把这些东西都透明化,这些程序员相对来说还是非常讲道理的,因为跟机器打交道多了,有一说一有二说二,思维方式还是比较客观公正的,不会说这些东西明明是效率高的却跟你说不行,一般不会有这种情形。
记者:
目前国内出现了很多敏捷教练的角色,敏捷的教练需要具备什么样的素质?
程显峰:
我个人觉得不管你具备什么样的素质,你要能和开发团队打成一片,要能赢得开发团队的尊重才能做得下去,否则你天天讲,人家不信你,其实你什么事都做不了,你可以不懂技术,但是开发团队都很信你,这也OK,但是开发团队一般都有一种倾向,就是技术沙文主义,不懂技术的人是不能打交道的,你要是想真正在这个团队里混下去的话就得跟他们打交道。
不同的团队当然不一样了,比如华为有敏捷实施的红头文件。
记者:
这种规范开发人员的工作习惯,优化他们的习惯,教他们一些工程方法,这跟CTO的职能有什么区别?
技术部门的Leader职能跟它有什么区别?
程显峰:
比如丹峰就负责技术架构设计运营,我就负责培训,发现团队的问题并整合这些看上去非常琐碎的事情,还有一些其它培训方面的事情,他们是思变,是想着怎么去打这个仗,我是像个教官一样想着怎么提高他们的战斗力,他们只想怎么用这些人,然后是打哪儿,这是他们要管的事情,我是教他们怎么使用武器,让他们训练有素,学会配合这些常规性的事情。
专访程显峰:
敏捷在团队中的实践与发展现状(3)
敏捷与管理的发展现状
记者:
对于未来几年敏捷开发的发展,您希望看到哪些新方向?
有何建议?
程显峰:
发展方面的问题我还真不知道,还是觉得有点落后,这个还需要积累吧,很长时间才会有一些改进,国内技术上落后的已经比较少了,反而是管理上落后的非常非常多。
比如Facebook的崛起,大家都看到它用的是什么技术,很少有人看到Facebook在壮大的时候立马就从e-Bay挖了一个人给他们做工程方面所有的事情,他们从很早期的时候就从e-Bay挖了一个高管去做所有工程化的东西,很早就做了,非常有远见,这些事情很少有人知道。
Facebook每年开了什么会,开
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 编程 语言 排行榜