2013c语言编程软件下载中文版年3月编程语言排行榜：有毒的Java(1)

2013年3月12日，Tiobe公布了新一期编程语言排行榜。Java依旧是占据第一的位置，C语言紧随其后。值得注意的Objective-C持续发力，已经占到了第三的位置。咋一看榜单，前5条中C#下滑最快，从第3名下降到第五名。而其他语言都与之前没有变化。
最近一段时间，关于Java安全性的新闻层出不穷。被伤害的不光是普通计算机用户，甚至还包括苹果公司、美国政府。此次安全风波波及面之广，恐怕是Oracle始料未及的。
1.黑客利用网页漏洞进行攻击
据国外安全研究机构称，当前的Java版本中包含了一个严重的安全漏洞，可能导致电脑在访问带有恶意代码的特定网页时被感染。Window系统中的所有主流浏览器都可能被利用并感染，其中也包括Chrome。该漏洞也存在于苹果最新的Mountain Lion操作系统。
为此，苹果不得不单独发布Java相关更新，以保证Mac用户的安全性。素以跨平台性强著称的Java，也让所有运用他的人无处可藏。
2.Java安全机制
Java早期的安全框架强调的是通过验证代码的来源和作者，保护用户避免受到下载下来的代码的攻击。Java安全模型的前三个部分——类加载体系结构、class文件检验器、Java虚拟机（及语言）的安全特性一起达到一个共同的目的：保持Java虚拟 机的实例和它正在运行的应用程序的内部完整性，使得它们不被下载的恶意代码或有漏洞的代码侵犯。相反，这个安
全模型的第四个组成部分是安全管理器，它主要用于保护虚拟机的外部资源不被虚拟机内运行的恶意或有漏洞的代码侵犯。这个安全管理器是一个单独的对象，在运行的Java虚拟机中，它在对于外部资源的访问控制起中枢作用。
Java签名/证书机制，可以保障使用者，安全地调用外部提供的jar，防止你信任的jar被篡改。首先，Java的签名，必须是基于jar包的。也就是说，你必须将你要提供的class，打包到jar里。然后，通过Java 提供的签名工具（jarsigner）对jar包进行签名，发布。
签名原理：使用非对称算法，生成一对公钥/私钥。
3.Oracle应对Java漏洞危机
甲骨文软件质量保证经理Eric Maurice透露，五个漏洞中有四个存在于桌面系统的Java Web Start应用和浏览器Java小程序中。其中三个被通用漏洞评分系统评为10级，这是很严重的事情：如果Java运行在Windows XP这种默认以管理员身份运行的系统，那么黑客能够利用这些漏洞完全损害系统的保密性，完整性和可用性;在Linux或者Salaris这类以非管理员权限运行的系统中情况会好一些。安全研究人员对剩下的一个漏洞也做出过说明，该漏洞影响服务器部署的Java安全套接字扩展(JSSE)，基于Lucky Thirteen攻击SSL/TLS实现。
新的Java 6 _update41可以从甲骨文网站下载，而不是Java，目前必须手动下载。但Java 6 安装程序的更新功能会提示用户下载并安装Java 7 _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, 4th Dimension/4D, ABC, Agilent VEE, Alice, Apex, AutoIt, AutoLISP, bc, C shell, CL (OS/400), Clipper, Clojure, Dart, Dylan, ECMAScript, Eiffel, Emacs Lisp, F#, Go, Groovy, Icon, IDL, Inform, Informix-4GL, J, JScript.NET, Ladder Logic, 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-14 10:08 小林 51CTO 我要评论() 字号：T | T
在国外软件企业中，几乎将近半企业是已采用敏捷方法进行开发，随着近年来受软件外包和外企的带动，敏捷开发在中国也出现了日渐普及的态势，如腾讯，IBM等等内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然，因此，51CTO记者采访了AdMaster（精硕科技）首席布道师程显峰，讲解了敏捷开发在团队中的实践以及发展现状。
AD： 2013大数据全球技术峰会低价抢票中

无论是在软件或者管理行业敏捷开发已成为众多高效开发团队的制胜之道。敏捷开发可以说是在开发中面临迅速变化需求中的一种快速开发能力。当然，敏捷不仅是简单的快速，而是在开发过程中短周期的不断改进、提高和调整；当然也不仅仅是一个版本只做几个功能，而主要的是突出重点。
在国外软件企业中，几乎将近半企业是已采用敏捷方法进行开发，随着近年来受软件外包和外企的带动，敏捷开发在中国也出现了日渐普及的态势，如腾讯，IBM等等内部几乎所有的开发团队都在实施敏捷方法。敏捷开发的流行绝非偶然，因此，51CTO记者采访了AdMaste
r（精硕科技）首席布道师程显峰，讲解了敏捷开发在团队中的实践以及发展现状。
简介：程显峰，毕业于悉尼大学，《MongoDB权威指南》译者，MongoDB中文社区创始人。Emacs使用者，Ruby写手，Scheme爱好者。AdMaster首席布道师，负责团队建设，人员培训，新技术普及，还有一些公司技术PR的工作。
以下是相关的采访实录：
敏捷在项目中的实践
记者：有些人认为敏捷开发并不适用于水平一般的程序员或团队，您是怎么认为的？
程显峰：至于敏捷开发是不是用这种程序团队，特别适合训练有素的团队，反过来说，如果不是一个训练有素的团队，实施传统软件工程也会失败，所以我觉得基本的要求是跟原来的一些要求基本一致的，包括沟通能力、协调能力，对于项目变动的控制能力都是一样的，包括传统软件开发当中讲的项目可控，整个项目可复制，同样的资源配比还可以复制这个项目，如果原来的项目这些做得比较好的话实施敏捷项目就会容易一些。
记者：很多人为了编写易变更的代码，在采用敏捷时，抛弃许多习惯用法，由你的经验出发，如何去看待这个问题？
程显峰：从我在实施的过程中第一点需要强调的就是大部分跟传统的软件工程还是一样的，现在异化的部分过于被强调了，搞得大家以为是完全新的、不一样的东西，传统软件包括需求管理、进入控制、质量管理、测试体系，这些东西在敏捷里也都要体现、都要实施，而且要求可能还会更高，并不是把一些传统的东西抛弃掉了，既没有进入管理又没有版本控制，几个人一商量就定了敏捷，这是完全的一种误解，而且还是要好的工程基础才能实施。
记者：所以传统的方法对于程序员的要求还是比较高的吧？敏捷这样的功能经过修改之后就可以推出一个小的版本？
程显峰：并不是说推出小版本就要降低难度，这是没有因果关系的，小的版本即使推送上去，如何保证这个小的版本是对的？你也需要大版本的方法，比如软件测试、进入控制、需求管理，这些东西都得有，你采用控制好它，虽然你推得比较快，看上去可能是一个一个的，如果你要是推的没有章法的话一样也是乱套的，不是你想要的东西，也会造成大量的浪费，我是这么觉得的。对于一个失败的项目就要说出失败的原因，这才是解决失败项目的办法，敏捷的方法不是，这个逻辑就是有问题的，我觉得这个没什么好说的。
记者：对于一个失败的软件项目来说，您认为敏捷方法是它的救星吗？
程显峰：其实我觉得敏捷的方法不是任何失败项目的救星，这是肯定的。至于失败这个事情，看上去可能是分工的原因，深层次可能是不交流、不沟通的原因。敏捷比较注重强调沟通互动这些方面，它是有强调这些东西，如果你的问题恰巧是由于不沟通导致的，采用了敏捷的方法可能会有极大的改善，但也非常取决于实施的人和分析的效果。好多人说敏捷就是一个筐，什么东西都可以往里面扔，实际上也确实有点这个样子。
我觉得敏捷的方法更多的是注重发现问题的框架，就是能让你更快地发现问题、暴露问题。至于怎么解决问题，原来能解决的就能解决，要是原来解决不掉，谁也帮不了你。如果原来你有沟通问题，但是很长时间才能暴露出来，这个东西能让你在短时间内暴露出来，那么就有助于解决这个问题。很多人为了编写易变更代码采用敏捷。
记者：想要做到敏捷开发，每个团队都要经历这样一个转型期，那么在转型期还需要每个团队根据自身的不同，出合理有效的解决方法。你们团队的是如何来解决的？
程显峰：每个团队都要经历一个转型期，我是倾向于比较温和地对团队进行改进，实施的东西尽量不要让团队有一个明显的转型期，比如版本控制，原来的版本控制提交的力度、上线的流程就是这样，我会给大家介绍一个新的系统，但是并不会太影响大家的工作，适应起来
又很快，这样的改进效果是比较立竿见影的，而且影响又是很小的，我特别喜欢的改进是这样的，这种改进不是偶尔一次才会用到的，我特别喜欢这种改进，就是你天天都会用到的，我特别喜欢那种天天都是这么调，但是每天都能省一分钟的。
大家可能都觉得敏捷特别神奇，每天能省百分之二十的时间，现在我还没发现这种现象，我不喜欢这种东西，如果不是特别想省百分之二十的时间的话就不会让大家经历一个转型期，比如你告诉大家一个技巧，每天能省两分钟，这种东西大家天天用的话实际积累下来的效果才是比较明显的，你要是教给大家一个方法，比如能省二十分钟，实际上这种方法看上去是非常漂亮，但它不是什么场景都能用得到，所以我就不太喜欢这样的方法。现在有一部分也不用敏捷，我也不太愿意教那个部分，就是每天早上例会的时候站在那里说一通。我也跟他们讲过，他们有的话可以，没有也OK，有些东西我的要求就比较死，比如上线的流程、可控性，我在这个方面的要求就比较死，开不开会对于我的项目没有什么影响，但是上线的流程就不一样，我要往回退的话就要花成本。
对于小的团队来讲真的是可有可无的，因为团队的人都坐在一起工作，未必需要一个站到板子上的形式。现在有人把形式看得很重，本来例会是很简单的，五分钟就开完了，但是吵起
来了，开不完，因为一般都是开早会，吵完以后心情就不好，所以效率就下来了，这也是很正常的，但是你不要想着漂亮的东西，我对漂亮的东西感觉都不实用。
记者：会不会因为不吵这个架把错误带到真正开发的过程中？

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。