JavaEye技术网站创始人 范凯


JavaEye技术网站创始人 范凯

文章插图
范凯(JavaEye技术网站创始人)【JavaEye技术网站创始人 范凯】范凯先生是Java谘询专家,目前任JavaEye技术网站总经理.范凯是JavaEye网站创始人,2006年范凯决定使用ruby来开发JavaEye网站,在随后的三年时间里面,JavaEye网站作为中国最早的Ruby on Rails开发的网站,一直扮演着ruby在国内软体开发社区的布道者角色 。时至今日,JavaEye网站已经成长为一个每日PV超过100百万的软体开发入口网站,是中国规模仅次于CSDN的第二大软体行业专业网站 。
基本介绍中文名:范凯
国籍:中国
出生地:上海
职业:资深软体工程师
主要成就:JavaEye技术网站创始人
性别:男
个人经历范凯 先生是Java谘询专家,目前任JavaEye技术网站总经理.范凯是JavaEye网站创始人,2006年范凯决定使用ruby来开发JavaEye网站,在随后的三年时间里面,JavaEye网站作为中国最早的Ruby on Rails开发的网站,一直扮演着ruby在国内软体开发社区的布道者角色 。时至今日,JavaEye网站已经成长为一个每日PV超过100百万的软体开发入口网站,是中国规模仅次于CSDN的第二大软体行业专业网站 。个人观点来自范凯的个人部落格我的PHP,Python和Ruby之路因为看到一篇讨论PHP,Python和Ruby的程式语言讨论贴,就说说我的PHP,Python和Ruby之路吧:我2000-2001年用PHP用了两年,那还是第一次网际网路泡沫时期,到2001年后期,Servlet/JSP流行,然后我就发现:你说用PHP写的东西,都会被人鄙视 。当时我们其实也用Java了,只不过用Java写后端的讯息伫列 。2001年后期泡沫破灭,我跑去做企业套用,就主要写Java写了很多年,中间2003年开始做JavaEye网站,到2006年用Rails重写JavaEye之前的3年,用的是phpbb搭建的,所以PHP也断断续续一直用到了2006年 。
JavaEye技术网站创始人 范凯

文章插图
JavaEye以我2000-2006年总共六年多的使用体验来说,我对PHP真的是深恶痛绝之,但凡做一个稍微大一点的系统,代码就很容易失控 。2002年以后,我曾经一度以为PHP这个东西快死掉了,那个时候大家都言必称J2EE和.net了 。结果Web2.0之风袭来,大家又发现J2EE太重,PHP又死灰复燃了,我其实很诧异现在PHP居然又变得如此流行 。从技术上来讲,PHP是个很烂的东西,但它门槛低,易部署,普及率高,好找人,实在是网际网路时代的VB,打不死的小强 。Python我大概是04-05年迷恋了一年左右,研究过Zope,plone,后来还看过wxPython,曾经一度想用Python写JavaEye网站 。记得04年Rails出来之后,还很长一段时间被我深深鄙视过 。但后来我去杭州拜访potian,被他的Rails实践经验说服了,之后我和他以及其他人在JavaEye上面有一个很长的讨论贴,讨论Rails的运行机制,最后我又被他说服了 。然后我还不死心,研究和比较了Rails和Django,不得不死心了,后来还曾经几次想用Python,每次都死心的很彻底,现在就彻底不考虑Python了 。就算你不用Rails,作为一个程式设计师,我也强烈建议你学习一下Ruby,仅仅因为可以开拓你的思维就很值得了 。因为Ruby的语法很强大很好玩,是现代语言版本的smalltalk,算是很原汁原味的面向对象程式语言,你学习了Ruby以后,你就会发现,原来Java/C++所谓的面向对象就是TMD的山寨版本的面向对象,原来面向对象还可以这样玩阿 。PHP用一句话来总结就是:quick and dirtyPython用一句话来总结就是:quick and clean,but not convenient for web developmentRuby用一句话来总结就是:code for fun and quick for web补充一下吧:为什幺我当初用Rails来写JavaEye网站:在选择用什幺工具开发JavaEye网站的时候,唯一的指导标準就是:用最少的人力,最少的时间开发JavaEye网站,并且后期维护和持续升级,乃至重写的时候,代价最小 。首先排除Java和C#,代码太多太麻烦;其次排除PHP,项目一大,代码一多,代码的管理很成问题,PHP缺乏一个起码的包管理机制;当时重点考察Python和Ruby,因为有豆瓣的先例,开始很倾向于Python,而且我那个时候对Python比较熟悉,还曾经痴迷过一段时间的wxPython,对Zope和plone也有一些研究 。但后来比较了Rails和Django之后,就倾向于Rails了,差距实在太大了,而且当时Django很不成熟,在很早期的版本 。其实即便现在Django和Rails的差距也没有缩小过 。但让我最终下定决心的是potian在05年就大规模使用Rails的实际工程经验,我曾经去杭州就我比较质疑的问题当面请教过他,和他谈过以后,就决定用Rails了 。应该说,我当初用Rails的决定很英明!Java已经过时了吗在四年以前,当我开始鼓吹Hibernate,抨击EJB的时候,遭到的是群起而攻之的场面,但是不到一年之后,Hibernate已然得到了普及和大多数Java开发人员的认可;在三年以前,当我开始讚誉spring的时候,spring还面临着EJB3的阴影,以及EJB2对其不登大雅之堂的指责,然而不到一年的时间,spring已经成为绝大多数Java开发人员的首选;在两年以前,我极力希望宣传webwork,唱衰JSF,时至今日,webwork以Struts2.0的身份容登大雅之堂,而JSF还在靠厂商死挺着;而当一年之前我开始採用RoR开发JavaEye的时候,RoR的置疑之声还甚嚣尘上,但当我在今年初预言07年下半年RoR在国内会被广泛接受的时候,很多人已经笑不出来了;今年我预言些什幺呢?我觉得会是AJAX技术走出PC的时代,证据就是iphone,与此相关联的事情就是REST架构的流行 。但是这篇文章里面我想谈的却不是我预言的水平準不準,而是想谈Java真的会因为RoR的流行而过时吗?目前在web开发主要套用在两个大的领域,网际网路和企业套用,我们分别来看一下:一、网际网路领域网际网路领域第一大动态语言是PHP,第二第三分别是ASP和Java 。在中小型网际网路套用当中,PHP的王者地位不容动摇,但在大型套用当中,Java是目前主流的选择,特别是电子商务类型的套用,例如阿里巴巴就从早期的PHP转变到Java,从前的eachnet也是如此 。造成这样局面不是没有原因的:1.中小型网际网路网站强调开发速度,维护成本,以及入门快速和部署成本,PHP是最合适的选择;用Java则显得过于笨拙,开发慢,维护成本高,入门周期长,部署麻烦;RoR开发速度最快,维护成本最低,但是RoR入门速度没有PHP快,部署成本比PHP高 。因此中小型网际网路网站主流还是PHP,但RoR能够占据一定的份额 。2.大中型网际网路站强调稳定性,性能,大规模代码的组织能力,而开发效率则退居次要地位,有些套用如电子商务对事务有很高的要求,显然Java是最合适的选择;PHP的代码组织能力最差,RoR次之 。在网际网路领域,Java从来就不是主流,并且Java的适用领域和RoR不太重合 。我们甚至可以这样说,RoR现在在网际网路领域取代的是那些原本不适合用Java,但是被错误的选择了Java的项目 。二、企业套用领域目前企业套用领域第一大语言是Java,dotnet其次 。企业套用採用的技术和行业有很大关係:例如金融行业,电子政务行业一般只採用Java 。dotnet发展了6年尚且没有进入企业高端的套用,RoR在短期之内也很难取代Java的地位 。在企业套用领域,Java是主流,并且Java的适用领域和RoR也不太重合 。我们也可以这样说,RoR将来在企业套用领域要取代的是那些原本不适合用Java,但是被错误的选择了Java的项目 。至此,我想Java程式设计师大可以鬆一口气,RoR目前有哪些不适合的场合呢:1.对事务要求非常高的场合RoR还是很简单的单资料库事务控制,缺乏精细的事务控制功能,当然也不支持跨资料库的分散式事务 。因此对于事务要求严格的大型电子商务网站,部署複杂的分散式资料库场景显得力不从心 。当然也许有些plugin可以提供这些功能,但是从目前的功能完备性和成熟度来看,还不够 。2.处理大量遗留资料库的场合ActiveRecord的威力很大程度上来自约定,大量命名糟糕的遗留资料库会对RoR造成比较大的障碍 。3.庞大的项目团队,对开发速度要求低的场合例如日本外包项目,团队庞大,个体开发速度要求低 。但是对于代码规範要求严格的项目 。虽然RoR不会取代Java,但不意味着作为程式设计师的你可以固步自封 。即使在工作当中用不上RoR,多看一点新的技术,对于开阔个人视野也有很大的好处 。谈谈我为什幺要学习ruby on rails挺有意思的现象记得过去还没有创办JavaEye的时候,在技术社区里面推广Hibernate(也算不上是推广,只是和别人交流Hibernate),就有一大批人酸酸的跳出来说,你们今天学习这个明天学习那个框架,全都是跟风,这些框架都是浮云,真正JDBC这种基础知识才是实力的,我就用JDBC,我用的一直很好,我完全没有必要去学习Hibernate……每当看到这种话,我就觉得特别好笑,用一个我发明的说法叫做“牛逼哄哄的露怯” 。没有人逼你学习Hibernate,你不乐意关心Hibernate,那就继续用JDBC好了,这个世界从来都不是非黑即白的 。其实这种人的心态很有意思 。他一方面眼红人家学习新的技术,另一方面自己又不想花时间和代价去学习,所以恨不得所有的人都不要去学习新技术,这样他心里就感觉很安全了,正因为如此,他就总是要时不时跳出来打击一下别人,表面上很牛逼,其实虚弱的内心挣扎一览无余 。如果想把技术作为终身职业,那幺对于技术人员的起码要求就是不能固步自封,要始终以开放的心态接受新技术 。打好基础知识固然重要(重要到根本无需你一遍又一遍的祥林嫂),但是不接触新技术,新思路,新的理念,很快就会被淘汰掉 。当然学习新技术也不是盲目的什幺都学习,什幺流行学习什幺,而是根据自身的需要,有选择的学习 。例如Java Web框架有很多很流行的,Struts,Webwork,Spring MVC,Tapestry,JSF,主流的就有5个,盲目的学习者就是人家说什幺他就学什幺了 。而聪明的学习者应该对这些东西都去接触一下,从中选择一个值得自己投资时间成本去学习的框架 。例如对这五个框架我都涉猎过一遍,最终我把时间花在了Webwork上面,事实也证明我当初的投资是正确的 。我学习ruby on rails有很现实的需要,其实即便抛开现实的需要,我也认为如果有空,Java开发人员有必要学习一下,原因是:1、ruby语言和rails框架的社区力量正在以惊人的速度增长,甚至已经进入爆炸式繁荣的前夜,这不是昙花一现的现象,而是一个时代开始的象徵 。2.从我这段时间学习的情况来看,ruby语言有足够的学习深度,我原来以为自己一个很快速的上手,然后就很精通了,但是ruby不像PHP那种速食麵,其知识的广度和深度都让我感觉这是一个完整的知识体系 。也正因为如此,ruby生命力会很长 。3. ruby和rails是非常非常Unix-like的东西,经常和作业系统提供的功能有深度的依赖,这和Java这种不依赖作业系统,什幺基础设施都自己捲起袖子自己创造的理念相比,非常非常的不同 。这样做会带来一个很大的好处,很多在Java里面解决方案很複杂的问题,在ruby方案中就很简单可以搞定,相比之下,让Java显得颇为大而无当 。不过ruby和rails也树立起了一堵墙,这堵墙就是Unix作业系统,要学好我,你就先跨越Unix这堵墙吧 。呵呵,这也是为什幺rails core team清一色的MacOSX的原因了 。不过我觉得这是好事,我本人是Unix fans,乐意见到这种现象,况且凭藉我多年深厚的Unix功底,在ruby fans中,我又站在了一个很高的起点上领跑了 。想学好ruby吗?先在你的电脑上面安装MacOSX/ubuntu作为开发环境咯 。Ruby为什幺会受程式设计师的欢迎孟岩最近写了一篇部落格:Ruby 1.9不会杀死Python这篇文章很有点标题党的意思,所以在JavaEye论坛很快被水掉了,只好锁贴:但我个人对于孟岩的观点是不敢苟同的 。首先我并不同意所谓魔幻语言和简约语言的分类 。其实Martin Flower论述过这个问题,他是用“人性化接口”和“最小接口”来区分程式语言的风格化差异的 。其实不用我多说,Martin论述的挺充分了 。强把Ruby和C++归为魔幻一类,其实并不準确,因为Ruby的魔幻语法和C++相比,最大区别在于:C++的魔幻语法会导致代码的可读性变差,而Ruby的魔幻语法会导致代码的可读性大大提高 。不论是matz本人,还是整个Ruby社区,Rails社区诸多开源项目的作者,抑或整个Ruby和Rails开发者社区,在一个编程哲学问题上是高度统一的,这就是:强调程式设计师的快乐编程,追求人性化编程,在代码的可读性上面有偏执的追求,拒绝难以阅读的代码和难用的API 。也就是所谓的coding for fun! 所以你看无论是Rails,rake,rspec,甚至移植自lucene的ferret,都鲜明的体现出来这种特点,就是API简单好用,让你写的代码像英文文章,自然流畅,轻鬆愉快 。要是哪个Ruby框架的API複杂晦涩,在Ruby社区简直没法混,大家根本不买他的帐,这也是为什幺Ruby套用于DSL领域这幺热的根本原因 。对于ruby程式设计师来说,这种追求编程人性化的哲学理念会潜移默化影响程式设计师,让他不知不觉把代码的可读性越写越好 。对于程式设计师来说,谁不想coding for fun呢? 而当你品尝到了coding for fun的乐趣,又怎幺会轻易抛弃?所以Ruby受程式设计师欢迎的根本原因还是在于它是一种能给你带来编程乐趣的语言 。Ruby和Rails的缺点有人说,robbin你说了那幺多RoR的优点,你啥时候说说RoR的缺点阿?你说的缺点肯定比别人说的更客观 。没办法,为了表现出来我不是一个RoR粉,只好总结点缺点,以飨RoR黑子们:Ruby和Rails的一些缺点的总结:ruby的问题我觉得主要是:1.ruby本身的性能是比较差的,无法直接做一些计算密集型的任务比方说大量的分词运算、语料训练什幺的,用ruby写是不行的2.ruby的C扩展很难写正因为ruby性能差,所以很多情况下要依赖C写的底层库,但是写ruby的扩展C库是很困难的事情 。一方面没有特别多的资料介绍,你能参考的只有《Ruby Hacking Guide》,另外一方面Ruby是带有GC的语言,C又是没有GC的,所以如果你对ruby的GC机制没有特别清楚的了解情况下,写C扩展会出现意想不到的问题:比方说你写的程式逻辑没有任何问题,但是和ruby配合起来就会不定期的出现错误,这就是你C程式的某个赋值变数可能会被ruby GC以你意想不到的方式销毁 。3.ruby的C扩展库质量不高,容易出现记忆体泄漏问题正因为上面的原因,很多第三方的C扩展库质量不好,很容易出现记忆体泄漏问题,这是一个很头疼的问题,你很难定位,也很难解决,只能儘量避免使用第三方扩展C库 。Rails的问题我觉得主要是:1.特别容易出现命名冲突你自己写的代码里面给类增加的方法,动不动就和Rails给类扩展的方法名称冲突了 。这种错误很隐蔽,很难发现 。这也是ruby语言动态性带来的一个负面影响2.Rails每次升级API变动都比较大Rails升级是不太考虑向下兼容性的,所以每次升级的话,可能你很多代码都要改,更糟糕的是很多Rails外挂程式特别喜欢以hack rails的方式来扩展Rails功能,那幺Rails一升级,外挂程式的兼容性几乎肯定是不行的,这个是比较痛苦的事情 。3.Rails的view方面还是比较原始的erb拼接字元串方式,像JSP那样原始,没有一个类似Java的