朱雀的IT世界

每天进步一点点,努力做好自己

 

马大叔的一篇关于对动态语言的评价,主要针对JRuby、Groovy及其相对的一些实现,讲得很好,为准备学习这两种语言的我做了指导

Currently there's quite a debate raging over the relative merits of Groovy and JRuby as scripting languages running on the Java virtual machine. Curious minds want to know - which of these languages will win this upcoming language war? People want to know which language to pick for a project, or which language to commit to learn.

Perhaps the first thing to point out is that it's perhaps rather unfair to see this as a race between these particular two horses. Scripting has been available on the JVM for a long time. Jython, a Java implementation of Python, has been around for several years. There's plenty of other, more obscure languages, which I daren't mention for fear of offending all the ones I miss out.

JRuby has got a lot of attention due to the attention of the Ruby language generally - attention particularly ignited by the interest around Rails. We've seen a sharp spike of interest around Ruby and Rails work at ThoughtWorks, and JRuby adds an extra dimension since it allows people to deploy Rails applications using their existing Java infrastructure.

Groovy gets its attention because it, more than any other language, is designed to work seamlessly with the JVM, and got a lot of attention from an early JSR.

Personally I'd dropped Groovy from my radar a couple of years ago when its development seemed to bog down. With its 1.0 release and further interesting positive vibes from some of my colleagues I've started to pay attention again.

Lets begin by talking about similarities. Both JRuby and Groovy (and indeed Jython) are modern OO scripting languages. They combine the well-chosen terseness of scripting languages with good solid structures for building larger programs. As such they are suitable both for classical scripting and for writing larger programs. Both are comfortable with dynamic type checking, although Groovy does offer some static facilities too. Both support Closures which are an important feature for the greater expressiveness that people want from this kind of language.

The biggest difference between them is their broader platform philosophy. Groovy is designed to be a scripting language for Java. As much as possible its syntax tries to match the equivalent in Java. (Including such ugly things as the default fall-through in switch statements.) It also works with Java's class library directly, although it dynamically adds many methods to Java's classes, vital in order to make use of things like closures.

JRuby, however, is a Java implementation of the Ruby platform. Ruby can run directly on mainstream operating systems with a C runtime, and is starting to run on .NET's CLR. When you program in JRuby you primarily use Ruby's libraries which are implemented in Java, and may also use Java's libraries at your discretion. If you stick to Ruby's libraries, or at least wrap any foreign elements, you can run Ruby programs on the C, Java, or (in time) .NET runtimes. So you can use JRuby to both run Ruby programs on the JVM and as a language for scripting the JVM.

One of the big differences between JRuby and Jython is around the libraries. One of the tricky aspects of porting this kind of scripting language to the JVM is that these languages are usually closely intertwined with libraries implemented in C. Porting these libraries to Java involves rewriting the libraries in Java. Jython didn't do much of this, as a result many Python apps can't run in Jython. However the JRuby implementers decided from early on that their goal was to run Rails apps, as a result many libraries including all the Ruby standard libraries needed to be ported.

The fact that JRuby is a Ruby platform on the JVM means that in JRuby you have two kinds of objects - JRuby objects and Java objects. Although there are ways for the two to talk to each other and to convert there is a difference. There are times when you need to know whether you're dealing with a Java string or a JRuby string. With Groovy you don't have that boundary, there are just Java objects.

It's too early, or rather too difficult, to say if one language will win out. Both are pretty young, only just finding their feet on the JVM. On a more personal level, your choice has a lot to do with what you expect to do with it. If you are only interested in running on the JVM, then Groovy could well be the easier choice. You are working directly with Java's library and object model, and the syntax requires less getting used to. A strong reason to prefer Ruby is the fact that it lives in multiple implementations. Ruby is a tool you can use in a lot of other places. As a long time Rubyist, there's not much incentive for me personally to get heavily into Groovy, even though I actually like the language a lot from what I've seen of it.

Rails is an important factor. The Java world is hardly lacking in web frameworks, but Rails is widely liked by those who've used it. I've not got many reports yet about Grails (the Groovy knock-off) so can't give a firm opinion on that. But I can imagine that the ability to deploy web apps with Rails could be a major factor in making JRuby popular. Something else to look at is the growth of RSpec as a new spin on testing environments.

With any platform it's as important to consider the people involved in the community as much as any technical factors. Good people can overcome technical weaknesses quickly and a vibrant community is a potent source for big innovations. RubyPeople have formed a particularly strong community, which has already spawned things like Rails, Rake, and Rspec.

Will either matter to Java? After all Jython's been around for a long time without making a huge impact on the JVM. Tool support is frankly pathetic for any of these languages when you compare it to what you have for Java at the moment.

I think we're actually at an inflection point with Java. Until recently the Java cry was One VM and OneLanguage. (As opposed to the CLR which was one VM and many languages, providing they're C# or VB.) This seems to be changing as people realize the limitations of Java and begin to seek out different capabilities. It's likely the future will see multiple languages closely integrated within the JVM.

There are plenty of people who dislike the hype around Rails and Ruby. But even if you dislike Ruby, the hype has led to a resurgence of interest in new languages. I doubt if the interest in Groovy would be anywhere near as great as it is if it wasn't for this hype, nor would Jython be awaking from its slumbers. The ruby/rails hype has also generated interest in other exotic JVM languages. The really nice thing here is that the JRuby people have been encouraging their dynamic rivals - recognizing that the point here is to encourage multi-lingual inter-operability and innovation.

posted @ 2007-11-29 09:34 朱雀 阅读(405) | 评论 (0)编辑 收藏

以前很困惑用Java 写的程序如何做成windows 服务,这里有一篇讲如何将tomact 程序做成windows 服务的,可以参考下

1:设置环境变量CATALINA_HOME=E:"tomcat5.5
2:设置CLASS_PATH 为CLASS_PATH=.;C:"java"jdk1.5.0_06"lib"dt.jar;C:"java"jdk1.5.0_06"lib"tools.jar;%CATALINA_HOME%"bin"bootstrap.jar

3:设置PATH中为C:"java"jdk1.5.0_06"bin;E:"tomcat5.5"bin;

4:添加服务命令:service.bat install Tomcat5
   运行完命令后就可以在服务中看到 Apache Tomcat5 然后可以自行改为手动或自动启动。
   注:如果使用tomcat5.exe安装名字为'Tomcat5'的服务可以运行以下命令:
    tomcat5 //IS//Tomcat5 --DisplayName="Apache Tomcat 5"  --Install="C:"Program Files"Tomcat"bin"tomcat5.exe" --Jvm=auto --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop

5:移除服务命令:tomcat5 //DS//Tomcat5

posted @ 2007-11-27 10:11 朱雀 阅读(872) | 评论 (0)编辑 收藏

一些有关GWT 和 Spring 可以整合在一起的文章

http://blog.digitalascent.com/2007/11/gwt-rpc-with-spring-2x_12.html

http://gwt-widget.sourceforge.net/?q=node/39

先记下来,有空好好研究研究

posted @ 2007-11-14 21:23 朱雀 阅读(1281) | 评论 (1)编辑 收藏

找了一个月的工作,今天有些收获,写写心得,总结一下,为了将来的生活更美好

找工作是一个体力脑力都需要很大挑战的事情,需要提前做好充分的准备。从整体来讲最终的结果是靠长年的积累来取得好的结果,但是随机性处处存在,实力不是决定因素。因此,做好充分的准备是有必要的:
1、要好好准备你的简历,中英文都需要,而且越能体现你的特长越好,把你的优势写在最前。简历意味着你是否能进笔试,没有这个啥都没有
2、在中国,找工作笔试很重要,听说在发达国家,找工作都是靠面试,而在中国,在这样一个庞大的人群中,笔试却成为最重要的一个环节。除非你的Java或者C#强到足以说,我能靠这些找到一份理想的工作不成问题的情况。否则,你还是需要准备C、C++,而且越是偏题,越是怪题,越要仔细留意。例如c中的sizeof()函数,是我见过笔试最多出现的,但是你在工作中会用到多少呢?所以说中国的应试教育甚至影响到了找工作,不过人还是要先适应环境才能改变环境的。推荐一本书《程序员面试宝典》这本书的确很有用,如果你不想好好再学C或者C++(和我一样,狂汗)的话,这本书足够你应付一些疑难杂症了了。还要准备算法,例如一些树和图的算法,是最经常考的
3、平时要敢于说话,要敢于表达自己。找工作一定不要害羞。怕什么?你自己如果真有实力,那展现出来就好啦,没什么比一个好的单位找到一个好的人才更令他们开心的了,既然是这样,你还怕什么啊?当然,你要是没实力,那就另当别论了,万一装腔作势被拆穿,结果很可怕。所以简历中,绝对不要写自己不熟悉的东西。在找工作前,要找一些能代表你技术实力的项目,最好提前做ppt,多试着演讲几次。还有我在找工作的时候遇到过有人让我当场演示写程序,尤其是有些公司会邀请你去参与他们的项目中去,那么,你如果会用快捷键,那是一件能加很多分的技能
4、实习能加很多分。实习的人,找实习单位的工作非常的容易,或许是人情分吧,不过这也没办法。我为了导师的项目,放弃了实习机会,的确很可惜,但是也没什么好后悔的,做人么,坦坦荡荡一些
5、不要怕被好的公司拒掉,你要坚信一点,你很优秀,拒掉是他们的损失。而且,相信自己,是金子总会发光,关键是你自己不能放弃自己,那样什么都没有。既然你喜欢这一行,你喜欢创造的感觉,那么就快乐的工作下去吧
6、别心急,锅底有肉,总有很好的工作留在最后面,据说11、12月份有很多工作单位录人不够会很着急,那么你就很容易找到工作啦,所以,别急么
7、第一份工作并没有你想象中的那么重要,关键是要在工作中积累自己,这才是最重要的,只要你不停的提高自己的实力,你想钱会少么?所以,别那么在意得失,要做一个聪明的糊涂蛋  

好啦,今天就写到这吧,我现在也能想到这么多啦,加油吧

posted @ 2007-10-26 21:21 朱雀 阅读(764) | 评论 (1)编辑 收藏

Java 历代版本记

JDK 1.1.4 Sparkler 宝石 1997-09-12
JDK 1.1.5 Pumpkin 南瓜 1997-12-13
JDK 1.1.6 Abigail 阿比盖尔--女子名 1998-04-24
JDK 1.1.7 Brutus 布鲁图--古罗马政治家和将军 1998-09-28
JDK 1.1.8 Chelsea 切尔西--城市名 1999-04-08

J2SE 1.2 Playground 运动场 1998-12-04
J2SE 1.2.1 none 无 1999-03-30
J2SE 1.2.2 Cricket 蟋蟀 1999-07-08

J2SE 1.3 Kestrel 美洲红隼 2000-05-08
J2SE 1.3.1 Ladybird 瓢虫 2001-05-17

J2SE 1.4.0 Merlin 灰背隼 2002-02-13
J2SE 1.4.1 grasshopper 蚱蜢 2002-09-16
J2SE 1.4.2 Mantis 螳螂 2003-06-26

J2SE 5.0 (1.5.0) Tiger 老虎 2004-10

J2SE 6.0 (Beta) Mustang 野马 2006-04

posted @ 2007-10-03 11:45 朱雀 阅读(253) | 评论 (0)编辑 收藏

已经百度三面了,不知道结果如何,写写面试心得

百度的面试是这样的
一面的时候考察技术细节和IT知识。从深度和广度上同时考察一个应聘者的能力。同时问一些技术问题,考察应聘者解决技术问题的能力
二面的时候主要考察的项目经验、团队协作、IT知识方面的一些能力。一般不会涉及到具体问题的细节。同时还考察的应聘者未来的学习计划等等。有点综合实力考察的味道了。
三面一般很短,考察一些解决问题的能力和一些项目经验(在我的印象中,人家不都说三面涉及到具体实质问题了么,比如说薪资啥的,咋还问我这些呢)。

个人感觉面试的时候不要慌张,把最真实的你展现给对方,如果有的问题真的没有考虑到,那么就说你现在想不出来。如果你真的做过很多项目,再加上平时又很注重了解最新的IT知识,那么一般他们的问题都不会难倒你。

个人有一点想法,就是有些人几年如一日的努力,找工作的时候就会很轻松。有些人只有在找工作的时候压力才会很大。这些其实大家都明白,但是做到就很难。

帖一个好的找工作帖子http://club.it.sohu.com/itmain.php?b=zz0049&c=69&a=51434

posted @ 2007-09-24 11:40 朱雀 阅读(2719) | 评论 (3)编辑 收藏

第一次笔试的经验

前天参加了校内百度招聘的笔试,应聘的职位是Web开发工程师
今天很多同学都收到了面试的通知,我没收到,看来很有可能是被鄙视了,总结下经验吧
1、看来当前Web 开发工程师大都注重考察Ajax的知识,尤其是有关XMLHttpRequest和浏览器相关这一块,所以要是下一次应聘这个职位,我可是要好好准备一下的,还有有关JavaScript的一些内容,这些东西都在考察的范围之内。
2、估计这次的失败和我潦草的字体和卷面有关,看来以后不能把卷子当草稿纸用了,哈哈
3、要准备些有关正则表达式的知识
4、最好在笔试的时候带自己的一份简历去,这样很直接,而且考虑很周到

第一次没经验,是该好好总结下,就这样吧,希望明天会更好

posted @ 2007-09-16 17:47 朱雀 阅读(193) | 评论 (0)编辑 收藏

总结一下Spring MVC 中Validator 的使用

今天使用到Spring 验证的模块(Validator),稍微研究了一下,觉得不仅仅是书上讲的那么简单,在此总结下

介绍下Spring Validator 接口必须实现的方法
1、public boolean support(Class clazz);这个方法是要验证提交表单时对应的那个缓存数据的类(通常由Hibernate生成),这通常由代码编写者设定,一般不会有错
2、public void validate(Object target, Errors errors);注意,这里返回的反而不是boolean,这是因为Spring 在处理无法提交的表单使用的机制是例外机制,他会送出一个Errors,包装了对应的信息。通常使用的方法是由类ValidationUtils 提供的,该类提供了验证的几个方法,并包装了错误。这里包装后的错误会出现在Controller 中的BindException 中,可以用getMessage() 方法来得到信息,不过这个信息很原始,可以利用适当的字符串处理机制处理一下。

其实这里有一个更好的方法,就是混合使用<spring:bind>标签,这个标签可以把对应提交的form 对象和表单中相关名称的字段绑定,而且可以通过它的子属性打印出错误信息例如你可以嵌入<c:out value="status.errorMessage" />这样就会把该字段验证时失败的信息显示出来,非常容易和好用,建议大家可以使用  

当Validator 接口实现完毕后,要在配置servlet 的xml 文件中将对应的Controller 的validator 属性设置为你的Validator 接口实现类,这样,系统就会自动对你需要验证的模块进行验证了。

如果你还想锦上添花的话,不但可以使用Spring MVC 的验证机制,还可以用JavaScript 写一段富客户端的验证机制

嗯,差不多了,就总结到此吧

posted @ 2007-08-30 20:47 朱雀 阅读(5528) | 评论 (0)编辑 收藏

一个优秀的IT技术人员应该具备的素质和层次

一、快速的学习能力:短期内阅读先进的技术书籍、文档并能应用之
二、熟练运用工具、整合工具、利用工具改变现有工作,提高效率的能力
三、掌握信息获取的方便途径和方法:例如google、RSS、Blog等方式,可以让你最快捷的解决问题
四、高效、具有创新力的团队凝聚力,强的协作能力和管理能力
五、对于技术,尤其是新技术和其蕴含价值的敏感性
六、独立思考、创新的能力


个人认为要完全满足上述六条,不是一个很容易的过程,大致我的成长经历告诉我应该分为如下三个阶段
a、第一、二条是一个高级程序员应该具备的素质,绝大多数的人,现在都处以这个阶段,甚至还没有达到
b、第三、四条是一个优秀项目经理应该具备的条件,具有了一些管理的能力,并能及时跟进和解决问题
c、第五、六条是大师级别的能力了,对于技术的应用能发掘价值,能创造新的技术。这才是几万人中只能出现一个这样的人才。

看来我的路还远,嘻嘻,继续努力吧

posted @ 2007-08-17 17:21 朱雀 阅读(592) | 评论 (1)编辑 收藏

利用Spring Web MVC框架架构MIS系统的心得,Controller与Service相配合

Spring Web MVC是Spring框架自带的一个Web框架,它很好的结合了Spring本身的IoC和AOP的功能。是利用Spring开发Web系统的不二选择。
最初使用这种框架,我设计系统时对数据库的操作显得有些拙劣,对应一个数据库表的操作,我往往用多个Controller对应多个Service的模式,使其松耦合。但这样层次不清晰,可复用模块变差。导致系统很庞大,重复部分多,而且难于管理。
经过思考,结合重构的思想。我想到一个解决方案,这个解决方案是面向接口的,可以很方便的解决上述问题。基本思想是对应数据库中每个表,对其封装成一个 Service,而这个Service实现了一些通用的接口方法,对应模块的多个Controller都可以调用这个Service接口中的方法。这就把 Controller和Service从原来的紧耦合变成了松耦合的模式,增加了可复用性。

posted @ 2007-08-17 17:19 朱雀 阅读(686) | 评论 (0)编辑 收藏

仅列出标题
共3页: 上一页 1 2 3 下一页 

导航

统计

常用链接

留言簿(5)

随笔分类

随笔档案

搜索

最新评论

阅读排行榜

评论排行榜