lixin的生活感悟 渴望每天都进步！ http://lixin.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 秒速5厘米 lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/114096  发表时间: 2007年08月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在各位圈友的推荐下特地看了新海诚的《秒速五厘米》，真的是很赞的片子。唯美而写实的画风，
贯穿全片的淡淡的忧伤，真让人回味久久。情节一点不复杂，远野贵树在学校里与同是转校生的
女孩蓧远明里成为了朋友，后来由于父亲工作变动，女孩再次转学。虽然分开在不同的城市中，两人
还是通过邮件保持了联系，原野发现自己对女孩的思念与日俱增，于是他准备了一封信，然后踏上了
去见女孩的长途电车。两人在凌晨时分风雪交加的站台终于重逢了。但是最终贵树并没有把哪封信交给明理
，他明白两人今后不会相守，“阻挡在两人前面的是庞大的人生，阻隔在他们中间的是广阔无际的时间”，
面对这些障碍两人无能为力。在相依偎着度过了一夜之后他又独自一人踏上回程的电车。随着
时间的推移，远野成为了一名软件工程师（Orz...）生活在大城市中，有一名相交多年的女友，但是稳定的
生活填补不了他的内心中的寂寞，他发现自己忘不了小时候哪个陪他一起看樱花、告诉他樱花每秒钟飘落五
厘米的小姑娘；过了这么多年，往日的回忆还是在脑海中不停地萦绕，繁忙地工作也不能让他停止在街
头巷尾寻找女孩的身影。在梦中他不止一次地回到十三岁那年，他与女孩重逢在风雪中的樱花树下，雪花纷
纷洒洒就如夏日里飘落的樱花，两人毫不犹豫地紧紧拥抱在一起。
情节的简洁，使这部片子看起更加地贴近生活，亮丽写实的画面、默默流露的情感不禁让人想起了自己读书
时的青葱岁月，哪些懵懂的日子，还有哪些没能实现的诺言。远野的坚持，让人感觉到了他纯净内心的力量；
只是对他成年后，略带颓废的生活有点看不过去；放下过去，微笑着拥抱新生活，我觉得才是对待爱情、对待
生活的更好的态度；也许这就是片尾远野转身时嘴角的哪丝微笑要传递给我们的。

秒速五厘米--再次推荐大家观赏！


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 19 Aug 2007 20:26:34 +0800 http://lixin.javaeye.com/blog/114096 http://lixin.javaeye.com/blog/114096 mysql的连接自动关闭问题 lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/109076  发表时间: 2007年08月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在工作中好几次遇见了mysql连接自动关闭的问题，最近系统中的一个模块又碰到了同样的“conection failed症状”。
由于使用了动态表，该模块并没有使用系统标配的sessionFactory，而是自己构建了一个单独的Hibernate sessionFactory
对动态表进行操作。开始时，我怀疑是不是多线程共用了session而导致的的session关闭问题，于是发起几位同事
一同测试了一下，发现不是这个原因；再详细问一下错误产生时的状况：应用启动很长时间后，只有一个人在操作也有
会出这个错。啊？一听到“应用启动很长时间之后才出现”，立马想起了mysql这个经典的“连接关闭”问题，立刻动手为
sessionFactory配了个c3p0连接池，并设置了c3p0定期检查数据库连接：
configuration.setProperty("idle_test_period","1800");
重启测试，问题解决。比较搞笑的是，mysql的启动参数中WaitTimeOut竟然和这个问题的出现有关系；这个参数默认设置是
八小时，于是应用启动八小时后才会出现connection failed问题；我们将WaitTimeOut设成很小之后，顺利地在几秒钟内重现了
这个Bug。对了别忘了：idle_test_period的值必须设得要比WaitTimeOut值小才管用。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 05 Aug 2007 07:09:21 +0800 http://lixin.javaeye.com/blog/109076 http://lixin.javaeye.com/blog/109076 AMD64上安装ubuntu所遇到的问题 lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/59367  发表时间: 2007年03月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在新配的AMD双核机上安装ubuntu，在光盘启动后，进入安装界面时报错
kernel panic-not syning:io-Apic+timer doesn't work:try using the 'noapic'
kernel parameter。
我google了一下这个错误，据说AMD64上都有这个问题，解决方案是
在启动加载kernel时, 需要noapic作为参数传递给kernel。请问该怎么加这个
启动参数？特别是在光盘启动安装时。。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 12 Mar 2007 21:10:16 +0800 http://lixin.javaeye.com/blog/59367 http://lixin.javaeye.com/blog/59367 提前几个小时祝各位javaeyer春节快乐，新年大吉！ lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/54721  发表时间: 2007年02月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

祝大家在新的一年里面：技术进步，爱情甜蜜，身体健康！
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 17 Feb 2007 14:12:46 +0800 http://lixin.javaeye.com/blog/54721 http://lixin.javaeye.com/blog/54721 下午很高兴地参加了BJUG与Agile China的活动 lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/52179  发表时间: 2007年02月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

下午非常高兴地参加了BJUG与Agile China联合举办的活动。地方很远，
不幸迟到了半小时。不过还好两个session的大部分都听到了。第一个
是乔梁介绍agile在实际项目中的应用，乔梁在他的项目中并没有采用全
套的敏捷方法，而是有选择地采用了一些:每日构建、单元测试，快速迭
代等等。让我映像深刻的是每日十五分钟的短会，每个人站在工位上简
短地汇报自己昨天做了什么，遇到了什么问题，今天准备做什么。通过这
样的交流，PM会对项目的状态有个准确地把握。第二个session是冰云主
讲的BA in agile。BA指得是Business analyst，这对我来说是个很新鲜的
词，冰云的原话我不太记得了，在这里写一点我自己的理解，BA的主要职
责是挖掘客户需求并将其转化为一个个写在卡片上的的user story.以下是一
个user story的句式as a..I want...so that..。 user story写完后，交给程序员
开发。最后QA根据user story来进行测试。我个人觉得BA的工作与现在公司
中的应用设计师&界面设计师&功能设计师有点像，带有一定的设计职责。
呵呵，中间休息时间和冰云闲聊了一阵，发现他非常善于交流，也许这也是
ThoughtWorks敏捷编程的一个标志吧。
本来这次去以为会有技术方面的专题，结果两个session全是方法学上的，
不过收获还是很大的，TDD，单元测试等敏捷方法都是值得程序员学习的，
它们可以极大的提高个人工作效率。总而言之，参加这种活动还是很值得，
这么多人无私地和你分享思想，下次也一定不能错过呀！

在结尾重复一下敏捷编程的原则：个体与交流>>过程与文档


注:user story的来源是process modeling或domain modeling。
user story的编写规则：INVEST(I - Independent
N - Negotiable,V - Valuable,E - Estimable,S - Small,T - Testable)
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 04 Feb 2007 20:05:04 +0800 http://lixin.javaeye.com/blog/52179 http://lixin.javaeye.com/blog/52179 问个貌似很简单的问题，关于在Spring下运行关于Quartz的单元测试 lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/51616  发表时间: 2007年02月01日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

通过在Spring配置文件中配置了以下各个bean以后，如何在Junit的testcase中使quartz运行起来？
在setup()方法中，已建立了applicationContext。我试图通过显式调用SchedulerFactoryBean.start()
方法来运行quartz，没有成功。 
<beans>
	<description>This  is a start! </description>
	<bean id="testSpring" class="com.test.app.TestSpring">

	</bean>
	
	<bean id="exampleJob" class="org.springframework.scheduling.quartz.JobDetailBean">
		<property name="jobClass" value="com.test.app.ExampleJob"/>
		<property name="jobDataAsMap">
			<map>
				<entry key="nameofjob" value="leexin's TEST!"/>
			</map>
		</property>
	</bean>
	
	<bean id="simpleTrigger" class="org.springframework.scheduling.quartz.SimpleTriggerBean">
		<property name="jobDetail" ref="exampleJob"/>
		<property name="startDelay" value="10000"/>
		<property name="repeatInterval" value="500000"/>
	</bean>
	
	<bean id="quartzScheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
		<property name="triggers">
			<list>
				<ref bean="simpleTrigger"/>
			</list>
		</property>
	</bean>

</beans>

本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 01 Feb 2007 15:06:18 +0800 http://lixin.javaeye.com/blog/51616 http://lixin.javaeye.com/blog/51616 偶然的感悟 lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/41321  发表时间: 2006年12月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

刚刚在robbin的博客看到了他的一些小时候照片，也不禁想起了自己的
小时候。时间过的真快呀；还没有整明白怎么回事，时间已经把成长的
压力带到了面前。在工作后才明白什么是自己所要追求的，才明白自己想

要过什么样的生活，才明白了目标的所在，才明白时间才是真正宝贵的东西。


我认为生命的壮美就在勇敢地与风浪搏斗，在于为实现自己的理想而自强不息；

厉兵秣马，枕戈而旦，并不是宗教式的狂热，而是对自己心中信念的坚持。是的，

生活就是这样，你可以选择整日嘻嘻哈哈、在网游中开心每一分钟；也可以选择

找到自己的目标，并为之付出不懈的努力。


希望一切都顺利，我会努力的。


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 28 Dec 2006 22:39:32 +0800 http://lixin.javaeye.com/blog/41321 http://lixin.javaeye.com/blog/41321 JDK1.5[转载] lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/22718  发表时间: 2004年11月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

I have been writing JDK 5.0 code for over six months now, so I thought I would take some time to reflect on my experience and draw a few conclusions on the features that were introduced.

Enhanced for loop
The undisputed winner. I can't even begin to describe how good it feels to use the new for loop everywhere (well, almost everywhere). I mentally cringe the few times when I am forced to use the old for loop, typically when I need the index or that I want the Iterator to be visible outside the loop.

The code is much more readable and feels less cluttered with noise (e.g. indices when you don't need them or incrementation exposing the underlying implementation). This latter point was an unexpected benefit of the new loop, by the way. Imagine that you have:

String[] names = ...;
for (String name : names) {
// ...
}

and you decide that you want to change the type of names to a Collection. How do you modify your code?

List<String> names = ...;
for (String name : names) {
// ...
}
That's right, just one line. It doesn't get better than that.
Annotations

Obviously, I am partial to annotations since they are at the heart of TestNG but I am a firm believer that annotations are going to change the way we build software in Java. We have been relying for far too long on reflection hacks to introduce meta-data in our programs, and annotations are finally going to provide an excellent solution to this problem.

Also, I haven't felt the need to use some of the predefined annotations such as @Override, so I haven't formed an opinion on them yet.

It seems inescapable to me that in a couple of years, most of the Java code that we will be reading and writing will contain annotations.

Static imports
I hardly use them at all, except in my annotations type for Retention and Target. I am still not convinced that the original intent that motivated the addition of this feature (discourage the anti-pattern of implementing an interface to be able to reuse its constants without having to qualify them) justifies the introduction of a new language feature, but time will tell.

I guess that in some way, the use of an IDE in my day-to-day programming makes imports absolutely obsolete, so I can't really get myself to feel strongly about this feature anyway.

Variable-length arguments
I haven't had the need for this feature at all so far. It might come in handy once in a while but I'm really not convinced it warranted a change in the language.

Enums
While I definitely give Enums a theoretical nod of approval, I haven't really converted my code to them yet, and I haven't acquired the reflex to use them either. I believe that when I do, I'll be happy with the result and it will make my code a tad more robust.

Generics
I left the best for the end... but since this entry is getting a bit long, I will save the Generics discussion for tomorrow.

Autoboxing
I have stayed away from autoboxing so far, probably because I have a vague feeling of losing control of the performance of my code. I don't think it is justified, though, so autoboxing can come in handy and make your code a little bit more readable. I think I would encourage developers to flag their code when such autoboxing is happening, and I am pretty sure that IDE's will soon be able to do the same.

Generics
Where to start?

Well, first of all, nobody can dispute that Generics are a solid concept that tends to improve the robustness of your code. The reason why they are so usually controversial regardless of the language is because of their implementation. And for having been a member of the C++ committee for many years , I can definitely vouch for the difficulty of getting them right.

In a nutshell, I have this to say about Java generics: my code feels more robust, but it's harder to read.

So what's the problem?

Redundancy.

First of all, I have always had a hard time with the redundancy introduced by the necessity of casting in general. For example, instead of writing:

Map accounts = new HashMap(); // no generics
...
Account a = (Account) accounts.get("Cedric");

why can't I just write:

Map m = new HashMap(); // no generics
...
Account a = m.get("Cedric");

and let the compiler introduce a silent cast, since obviously, it's an object of type Account that I am trying to retrieve from the Map?
Obviously, Generics don't solve this problem entirely but they make a decent job at alleviating it somewhat. But they also make it worse in some other ways:

Map<String, List<Account>> accounts =
new HashMap<String, List<Account>>();

Ouch.
Not only is the code significantly harder to read, but it fails to obey the DRY principle ("Don't repeat yourself"). What if I need to change the value type of this map from List<Account> Collection<Account>? I need to replace all these statements everywhere in my code. While IDE refactoring will help, it's still an awful lot of code for a modification of this kind that hardly impacts the semantics of this code.

Admittedly, there is no nice way to avoid this syntax when you are creating a new object, but what I am driving at is that I think Generics would have been better off if typedefs had been introduced with them.

Or so I thought at first.

But after thinking about it more, I realized that typedefs were the wrong solution to the problem, because simply put, they don't add anything to the use of a separate class to define your complex Generic type.

class AccountMap extends HashMap<String, List&lAccount>> {
...
}

Except for the fact that you need to extend an implementation (HashMap, and not Map, obviously), this solution is probably better than introducing typedef, which has its own quirks.

I haven't gone to this trouble so far, but my recommendation would be: do it if you write the type more than three times (twice in the initialization and you use it more than once in your code).

Except for this little annoyance, I am quite happy with Generics overall and I particulary enjoy reading the TestNG Javadocs so nicely typed.

Conclusion
I am very happy with the new features of JDK 5.0 and I am quite proud to have had a chance to influence it with my participation in JSR 175 and JSR 201. Like all radical evolutions, not all of the new features will be popular with everyone, but as long as most developers find some of these features useful and that backward compatibility is preserved, I think JDK 5.0 is a very solid step toward more solid Java code.
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 11 Nov 2004 13:02:08 +0800 http://lixin.javaeye.com/blog/22718 http://lixin.javaeye.com/blog/22718 咳！ lix23 作者: lix23  链接：http://lixin.javaeye.com/blog/22717  发表时间: 2004年11月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我的blog!!hehe
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 11 Nov 2004 12:59:16 +0800 http://lixin.javaeye.com/blog/22717 http://lixin.javaeye.com/blog/22717