Category: Tech.技术

The technologies related part of my blog posts. If you are a programmer or geek, I think you will only interested in this part of my blog.

Webwork 2.2 b5中datapicker的本地化使用方法

仅作为记录，尽量简明：
1、我使用Weblogic 8.1 SP5+Webwork 2.2 beta 5。2.2b5的Webwork已经完全转向使用jscalendar作为datapicker的js，而不是以前的tigracalendar，因为tigracalendar不支持国际化。Web项目使用FilterDispatcher，本应改可以将/webwork/*的请求拦截下来，但是它工做不正常。所以我把webwork.jar里面的\com\opensymphony\webwork\static目录拷贝到Web根目录，并将static目录重名名为webwork。
此时，你的Web根目录下面应有一个名为webwork的目录，里面有jscalendar、dojo、niftycorners这几个文件加，如果不需要其它的，可以只保留jscalendar一个目录。
2、在需要显示datapicker的地方使用如下标记<ww:datepicker name="ecoInf.turninDate" id="ecoInf.turninDate" template="datepicker.ftl" language="cn_utf8" format="%Y-%m-%d %H:%M:%S" showstime="true" />。
其中template完全可以不写。而name标明你的数据的来源。id是方便javascript访问所保留的，可以和name相同（如果有重复name，如经过iterator，则需要区别其id，保持id在html dom中唯一）。
showstime标明是否可以选择时间，可以是"true"，"false"，"24"，"12"。
language决定jscalendar使用的语言，参照下面说明。
3、language指定的语言其实就对应jscalendar/lang下面的语言文件，格式就是calendar-语言名.js，默认的中文使用的是zh。但是其实j2ee项目经常面对中文乱码问题，最佳解决方案就是统一使用UTF-8。但是calendar-zh.js正好不是UTF-8的，所以如果直接使用zh语言则datapicker没法正常工作。
我的解决方法是将webwork附带的jscalendar 1.0的lang里面的cn_utf8.js改名为calendar-cn_utf8.js，然后将language="cn_utf8"就工作正常了。
4、关于时间的显示格式。其实cn_utf8.js里面已经制定了时间的标准显示格式是%Y-%m-%d，符合我们的习惯。但是有时我们需要显示具体时间，参照他们网站的说明，使用format="%Y-%m-%d %H:%M:%S"，这个也符合我们的习惯。
发个牢骚：
本来奇简单。但是很奇怪/webwork/*居然不能在Weblogic下自动映射，我一会而去试验下Tomcat，还有就是js解析utf-8出错造成整个js没法工作，浪费了半天时间，唉。

eXtremeComponent在中文环境下的使用

不知道大家是否使用过eXtremeComponent，我刚才在java eye没有搜索到。
最早知道eXtremeComponent是从www.open-open.com，去年就在用了，感觉明显比display-tag要好用多了。
它使用jstl，所以与webwork集成也很方便，不象display-tag那样需要把hibernate返回的collection复制一遍再访问。

具体的使用方法参考官方网站好了：
官方网站在这里：
http://www.extremecomponents.org/extremesite/welcome.jsp
最新的版本是1.0.1-M4-A14，可以到这里下载：
http://www.extremecomponents.org/extremesite/public/download/
或者直接下载：
http://www.extremecomponents.org/extremesite/public/download/extremecomponents-1.0.1-M4-A14.zip
但是这个snapshot版本没有依赖lib和资源文件等，推荐去这里下一个完整版本备用，目前最新的Production Release包是eXtremeComponents-1.0.1-M3-with-dependencies.zip：
https://sourceforge.net/project/showfiles.php?group_id=108168
最新版本的说明书在这里，说明书用的doc book格式，写的也很清楚：
http://www.extremecomponents.org/extremesite/public/download/eXtremeComponents.pdf
很多人都对他使用的doc book声称doc感兴趣，spring和hibernate都用doc book，可是一般看不到源文件。作者很慷慨将doc book的源文件也分享了，是学习是学习使用doc book的好东西：
http://www.extremecomponents.org/extremesite/public/download/generate-docs.zip

资源就贴到这里，这里要提及作者Jeff Johnston人非常热情，论坛上四处可见他的身影，给他发信他也是每信必会、有求必应，承蒙他多次帮助。而且论坛中大家多次提及中文问题，他也很重视。

转入正题：
我贴一下一个例子：
 <ec:table
 items="ecoAttrs"
 action="/jgz/tjk/eco/listTjkAttByInfId.action"
 imagePath="${pageContext.request.contextPath}/css/table/zh_CN/*.gif"
 cellpadding="1"
 title="农村经济运行情况列表"
 locale="zh_CN"
 rowsDisplayed="30">
  <ec:export view="xls" fileName="jgz_zyjjzbwcqk.xls" tooltip="输出Excel文件"/>
  <ec:exportPdf fileName="jgz_zyjjzbwcqk.pdf" tooltip="输出PDF文件" headerColor="blue" headerBackgroundColor="red" headerTitle="密云县农村经济月份经济主要指标完成情况表"/>
  <ec:exportCsv fileName="jgz_zyjjzbwcqk.txt" tooltip="输出CSV文件" delimiter="|"/>
  <ec:row>
   <ec:column property="ofTown.name" title="乡镇名称"/>
   <ec:column property="ncJihua" title="农村计划"/>
   <ec:column property="ncWancheng" title="农村完成"/>
   <ec:column property="ncQunian" title="农村去年"/>
   <ec:column property="zongShouRuWCJH" title="完成计划%"/>
   <ec:column property="zongShouRuTB" title="同比+/-%"/>
  </ec:row>
 </ec:table>

其中ecoAttrs是一个collection，放入pojo。action里面写你这个页面的访问方法（如我的页面是一个action，其他的如.do或者.jsp什么的都可以）。rowsDisplayed是默认显示条数，它可以自动实现分页。
下面的三个<ec:export>是导出三种格式用的，不用的话可以不写（写了需要在web.xml配置相应的filter）。
<ec:column>里面放属性，property指向pojo的相应属性，而title是表头显示的信息，这个标签需要用<ec:row>包起来（1.0.1 m4以后）（抱歉pojo比较丑，出自同事之手）。

这里放一套我做的中文图标：
http://tiny.51.net/extremecomponent/zh_CN.rar
还有我该写了一下css，更适合使用中文，将字体该为%大小，可以定义.eXtremeTable里面的font-size，即影响所有eXtremeTable里面的字体大小，也方便写js来动态修改大小：
http://tiny.51.net/extremecomponent/extremecomponents.css

贴一下我在web.xml里面的配置：
<filter>
 <filter-name>eXtremeExport</filter-name>
 <filter-class>
  org.extremecomponents.table.filter.ExportFilter
 </filter-class>
</filter>

<filter-mapping>
 <filter-name>eXtremeExport</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>

<taglib>
 <taglib-uri>/extremecomponents</taglib-uri>
 <taglib-location>/WEB-INF/tld/extremecomponents.tld</taglib-location><!– 别忘了把那个tld拷贝到相应目录去 –>
</taglib>

其实，那个filter只是在使用<ec:export>的时候才需要，不过这个功能还是很有用的。

export里面的excel和pdf默认不支持中文，需要手工修改源码，excel的比较简单：
修改org.extremecomponents.table.view.XlsView.java（我指的是1.0.1-M4-A14的相应代码）
102行：
HSSFCell hssfCell = hssfRow.createCell(cellnum);
hssfCell.setEncoding(HSSFCell.ENCODING_UTF_16);（就是添加这一行）
122行：
HSSFCell cell = row.createCell(cellnum);
cell.setEncoding(HSSFCell.ENCODING_UTF_16);（就是添加这一行）
这个在使用UTF-8时工作正常。如果其他Unicode环境可以尝试HSSFCell.ENCODING_COMPRESSED_UNICODE。

编译后将对应.class放到WEB-INF/classes相应目录就可以了。

pdf view的比较麻烦，还没尝试，解决方法参照这个帖子：
http://extremecomponents.org/forum/viewtopic.php?t=139&highlight=chinese+filter
http://www-128.ibm.com/developerworks/cn/xml/x-ospdf/index.html

还有一小点：
升级到1.0.1-M4-A14以后两个图片改名了，如果用1.0.1-M3的对应gif则需要该如下两个文件名（我修改的那个ZH-CN已经重命名过了）：
searchArrow.gif -> filterArrow.gif
search.gif -> filter.gif

说的比较罗嗦，主要是想让和我一样的非常初级水平的朋友能够比较容易上手。其实eXtremeComponent的文档很不错，用那个上手其实更好，我仅抛砖引玉，各位大虾多多包涵。

Spring 2.0和给贫血模型充血

Spring 2.0 vs. the Anemic Domain Model
原来是因为老马骂了贫血模型为反模式，说冲血模型才是最好的，能够真正的OO。
不过Spring 2.0的概念被骂了个体无完肤。
本身，我的立场从来就没有站在OO这一边，我是真的无所谓的人，什么过程、OO、FP我都很认同，当然能优雅些是最好的。
看了以后就想到WQH前两天就已经推荐给我的ajoo写的充血模型的问题，我才意识到QH大师又走在我们前头了！
看了下javaeye上贫血/充血的讨论，才豁然开朗。
知道为什么冲突就对了。关键点还是在争吵OO，而OO在领域模型方面有时适合充血有时适合贫血，当然贫血居多，所以举起例子总是两边倒，没有定论。
还好，抽出重要部分，对于基本CRUD，那么绝对是贫血模型就好了。而对于有复杂计算的领域模型，我们要建立一个完备的OO的领域模型则需要充血。
这提醒了我们，充血的确是需要的。不过给Hibernate下的POJO（明显贫血到死）充血并不容易，所以才有了更多的文章讨论这个问题。
记录下来，大家有兴趣一起研究：
TSS：Spring 2.0 vs. the Anemic Domain Model
http://www.theserverside.com/news/thread.tss?thread_id=38047
Javaeye论坛：贫血就贫血,咂地？
http://www.hibernate.org.cn/viewtopic.php?p=100045&sid=df2163b2c94afbb6b214da6b3be42d73
ajoo在javaeye的conflunce上写的：怎样给马丁的充血域对象注射依赖
ajoo一文的后篇：http://www.javaeye.com/display/ajoo/Dependency+Injection+For+Rich+Domain+Model
对程序员透明的非aop方法解决rich domain object的依赖注射
http://www.javaeye.com/display/ajoo/Transparent+Dependency+Injection+For+Rich+Domain+Model
Codehaus上的一个解决方案：Dependency Injection For Rich Domain Objects
http://docs.codehaus.org/display/YAN/Dependency+Injection+For+Rich+Domain+Objects
老马写的批评贫血模型的檄文：AnemicDomainModel
http://www.martinfowler.com/bliki/AnemicDomainModel.html
Spring Blog上的原文：Spring 2.0 vs. the Anemic Domain Model
http://jroller.com/page/habuma?entry=spring_2_0_vs_the
我个人认为POJO还有DTO都是简单的VO，而VO就是VO，要区别于Real Object。我们的domain里面大都是VO而不是RO。Hibernate也是基于VO的，EJB3同样。所以RO应该说是理想OO下的东西，我们真正要用的时候，还是可以自己选择是否要实现这种复杂的东西的。但是不用RO则我们的程序就变得过程化。所以老马也认为这是头疼的事，但又不要解决，只能放到他的TODO list里面了，哈哈。
哈哈，但是看完Spring的那个Blog，感觉Spring 2.0做好了解决多向以来的模型的方法是很不错的，当然是由解决给贫血模型充血引发的，但是我认为它还能解决其它问题，所以感觉不错。但是Spring 2.0再次强调Aop的好处，也的确能看到，所以有时间还要学习一下AspectJ。
而这个问题ajoo说了IoC和Aop都可以解决，感觉各有道理。IoC方式感觉代码容易读懂，也合理。而Aop则代码有点牵强，当然使用起来感觉很爽，尤其和Lazy-init结合，对生存周期的控制有它读到的地方，而且想明白了用Aop+Annotation感觉也很清楚优雅。

关于事务的满脑袋酱子，解惑：本地、JTA、CMT

传统上J2EE有两种事务管理策略：全局或者本地事务
全局的由app server保证，如JTA。而本地则是针对某种资源的，如JDBC连接的事务。
其中，全局事务是为了保证多种事务资源的共同工作。但是如果是用本地的事务，则容器（app server）无法保证跨资源的事务。
JTA是一种全局的事务。但是JTA是笨重的，且JTA的事务一般需要通过JNDI获得，所以JNDI和JTA一般联用。而且JTA代码一般不能跨App server，会受限于某种特定的容器。
所以更好的方式是使用EJB CMT(Container Managed Transaction)，它的特点是使用声明性事务，而不是编码事务管理。
所以，虽然EJB天然结合了JNDI，但是并不受限于容器（声明性）。
但是CMT又依赖于JTA和App server环境（或者说支持EJB的App server，Tomcat这些Servlet容器就不行啦）。所以这种事务如果依赖于EJB或者EJB的装饰封装则要花不少资本投资App server（不是钱也至少要人，如JBoss）。
但是，我们还有更好的选择，如Spring，或者很多Aop实现，EJB3等等。
而本地的事务策略虽然实现容易，但是缺点显著。它不能在多资源间实现事务支持，并且这种事务对变成模型的侵入也很大（传统JDBC事务使用起来就是这样）。而且如JDBC连接也不能与其他JTA事务协同被管理。如你的JDBC和某个其它事务绑定（如两个JDBC Connection）起来，如果遇到一个失败你如何将两个rollback？（这个是我自己演绎的）
下面是广告：
Spring解决了这个问题。它提供了一个持续的模型，可以应用在大多数环境。也就是说你可以灵活的更换它支持的各种事务策略（你也可以自己扩展）。而且Spring两种方式的事务都支持（声明/编码），当然Spring推荐使用声明的（侵入小，灵活）。

MB，本来写了不少体会，结果倒霉没有保存，如果有时间我再考虑一下是否重写吧，损失惨重！

实验Webwork2.2与Spring的Auto-wire (2)

太长了，这是下半部分。

我做了一下小实验，以Webwork2的样例程序为例：

原先只在xwork.xml总进行了配置，Spring配置中无该bean。

<action

name="main" class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory">

<result name="success">/category-main.jsp</result>

</action>

1、 使用byType方式：这个没什么可说，只要类一样自动就可以匹配，并使用。

添加了Spring中的配置：

<bean id="main_action"

class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory"

singleton="false" />

2、 使用byName方式：在Spring中配置id=”xxx”，然后再xwork中配置name=”xxx”，可以自动匹配，可以使用。

修改了Spring配置如下：

<bean id="main"

class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory"

singleton="false" />

3、 然后删除xwork.xml配置中的class=”com.xxx.xxx”为class=””，依然可以工作。

修改了xwork.xml配置如下：

<action name="main" class="">

<result name="success">/category-main.jsp</result>

</action>

4、 然后再实验使用Spring中bean的name属性进行匹配，依然工作正常。

修改了Spring配置如下：

<bean id="main1" name="main"

class="com.opensymphony.webwork.example.ajax.actions.ActiveCategory"

singleton="false" />

所以，看起来name和id都可以用来auto-wire，所以id如果可以区分，用它来auto-wire就可以了，比较方便。

不过我个人有个疑问，在Spring中声明action是否要生明singleton=”false”？按理说应该false吧，可是我看例子中都没有声明。我记得Spring默认是singleton=”true”的，这是为什么？

实验Webwork2.2与Spring的Auto-wire(1)

前几天看到BJUG的朋友说最近大家都不写技术Blog了，我实在是没看什么东西，今天正好要搞Webwork2+Spring，体验了一下新版本的集成，做了点翻译，还顺道作了点小实验。

基于Spring 1.2.5 + Webwork 2.2 Beta3

1、中文参考是飞云小侠的——《WebWork2.2中结合Spring:"新的方式"》：

http://www.jscud.com/srun/news/viewhtml/4_2005_9/134.htm

2、英文参考是Webwork的Conflunce上的文章（不好意思，基本上是翻译这篇文章）：

Enabling Spring Integration：

http://wiki.opensymphony.com/display/WW/Spring

3、Other Spring Integration：

http://wiki.opensymphony.com/display/WW/Other+Spring+Integration

其中：

在webwork.properties中通过这条设置打开SpringObjectFactory：

webwork.objectFactory = spring

而修改autoWire的工作方式则通过这个设置：

webwork.objectFactory.spring.autoWire = type

autoWire其实就是webwork寻找Spring已经创建的bean的方式，有如下四种方式可以设置：

name

通过对Spring中的bean的name与你程序中的action的name属性进行匹配。系统默认使用这种方式（如果不写上面那句的话）。

type

通过在Spring中注册的bean中寻找与你程序中的action的name相同的属性来匹配。这需要保证Spring中一个类只能注册一次（即不允许部同名但同类的Spring配置）

auto

Spring试图自动检查最好的Auto-wire方式。

constructor

Spring会根据constructor的参数来匹配action。（webwork这里没有作更多说明，根据Spring的规则，这种方式应该与type类似，只不过这里不是匹配setter，而是匹配constuctor的参数。）

其实，看看Spring的相关书籍，其实这就是Spring的四种Auto-wire方式，分别对应：byName、byType、autodetect、constructor。可以参考Pro Spring的第4章的内容“Auto-Wireing Your Beans”。

然后说明了一下方式，配置了auto-wire以后每次都回试图通过Spring来匹配对象实例。如果Spring没有创建这个Bean，那么Webwork会自己创建它。同时，要在web.xml中注册Spring的Lisener来打开这个功能：

<listener>

<listener-class>

org.springframework.web.context.ContextLoaderListener

</listener-class>

</listener>

这里Webwork提出了一个提示：需要更多的ApplicationContext配置文件么？

如果使用了Spring的标准Listener来结合，那么可以除了aaplicationContext.xml还配置多个xml配置文件。可以通过下面的配置来实现，需要加到web.xml里面。

<!– Context Configuration locations for Spring XML files –>

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>

/WEB-INF/applicationContext-*.xml

/WEB-INF/spring-daos.xml

/WEB-INF/spring-actions.xml

</param-value>

</context-param>

这个可以参考Spring文档。

Spring中的配置样例

这里，你可以添加标准的Spring配置文件，在WEB-INF/applicationContext.xml。下面是一个例子：

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans default-autowire="autodetect">

<bean id="personManager" class="com.acme.PersonManager"/>

…

</beans>

从使用内建IoC转移到使用Spring

转移很容易。Spring的配置就如上所述。完成融合，你需要：

1、 将你的components的配置从components.xml适当转移到applicationContext.xml。然后就可以安全的删除components.xml了。

2、 从xwork.xml的拦截器栈（interceptor stack）中移除Component Interceptor。虽然不移除也无伤大雅，但是留下它已经是个冗余了。

Session Scope和Spring

Spring目前不支持session scoped components。不过计划在Spring 1.3 release中整合该功能。现在，你必须使用Spring Session Componnets Workarounds。

从Spring中初始化Actions

一般，xwork.xml指明了每个Actions的具体类。当使用SpringObjectFacotry（如上面配置的过程），意味着将通过Spring来创建action，然后来组装（wire）他们之间的依赖，根据设定的auto-wire行为。SpringObjectFactory将会应用所有的预处理工作，例如代理你的action的事物（transactions）、安全（security）、等等。这样不需要明确配置，Spring会自动装配它们。大部分应用中，这就是你所要做的全部工作，使你的actions的服务和依赖关系被执行。

我们强烈建议使用声明的方式来让Spring知道你的actions之间的依赖。这包括自动的装配具有相同的name的属性和bean（就是指byName的Auto-wring），或者byType的Autowire（这种情况下一个类型只能在Spring中注册一次）。或者还可以使用JDK5种的annotations来声明事物或者安全的配置，而不是通过applicationContext.xml，这样你就不需要在所有配置文件来维护它们了。

然而，有时你想让bean通过Spring自动管理。这很有用，例如，如果你想配置复杂的AOP或者Spring支持的技术到beans上，例如Acegi。这样，你需要将所有的配置写到applicationContext.xml里面，然后改变WebWork action中的class属性，使之与Spring中的bean name定义相同，代替原来使用的真实类名。

你的xwork.xml文件中的class属性会改变，就像下面这样：

<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.1.dtd">

<xwork>

<include file="webwork-default.xml"/>

<package name="default" extends="webwork-default">

<action name="foo" class="com.acme.Foo">

<result>foo.ftl</result>

</action>

</package>

<package name="secure" namespace="/secure" extends="default">

<action name="bar" class="bar">

<result>bar.ftl</result>

</action>

</package>

</xwork>

这里，你的Spring的applicationContext.xml中有一个名为“bar”的bean。注意com.acme.Foo这个action不需要修改属性，它会自动autowire的。

记住：这不是必须的。这只在这种情况才必须，你希望覆盖掉已经在Webwork中创建的action，并且需要通过Spring支持但不能自动实决定的拦截器和IoC来装饰它的时候。记住，Webwork的Spring继承只是标准的IoC，使用你指定的任何auto-wiring，甚至即使你没有显示的在Spring中映射action。所以一般来说你不需要这样做，但是如果需要的时候你最好知道这是如何实现的。

这段说的不太清楚，可能我翻译的不好。但是我理解它的意思是，可以不用修改class的名字，因为不修改它也会自动应用Spring的AOP和其它IoC功能，当然是根据auto-wire的匹配。但是如果需要特别的确定要从Spring中装饰后再使用这个action，那么可以把class的属性修改掉。

上班写Blog是一件很悠闲的事情

一个多月前，那个晚上，我写了一个Blog阐述我忐忑的心情，不知人生向什么方向发展了，同时对马上要工作有一种紧张感。
而后就是进入公司开始干活，发现原来挣钱也不是那么难。
而后就是十一去了沈阳-丹东-东港-本溪，吃了很多好吃的，还游览了不少没去过的地方。给我留下最重要印象的是，我的GF和我在一起真的很快乐，即使在满是乘客的火车上，一个眼神也能给我无比的温暖，这样的旅行虽然说不上丰富多彩，但是却依然经常在梦中重温。
十一回来后的工作就变得越发的繁杂，在公司也基本上熟了，每天喝水上厕所，还有干手底下的活。还好有朋友罩着，没有什么不舒服的，但是比起上学的随心所欲，这样的生活有点机械，我不喜欢，因为我喜欢每天上进。也就是那个谁谁谁说的，每天写Blog的时候会发现收获。
而后，在我们自己的Conflunce上面的打拼也基本上停止了，因为生活变得忙碌，主要是上半之前的一个小时和下班之后的数个小时的时间都非常零散，很难有效率用，所以没有时间看帖子，没有时间学习，没有时间看电影。还好，吃饭和给GF打电话的时间还是有的，否则这种生活就真的不快乐了。
而后，在公司，慢慢的活变多起来了，我也就忙起来了。当我终于接触到公司程序源码的时候，还是吃了一惊，因为使用的框架都很全面，可惜代码非常丑陋，很多地方完全就是反模式，为了麻烦而麻烦，真是想不通。把Struts+Hibernate用成这个样子真是难以理解。还好技术主管让我用自己的技术，只要快就可以。我就偷懒使用了大量JSP+Scriptlet，还好，虽然是去年在用的技术，现在用起来依然很顺手。
其实，最近忙活的事很多。山东有个朋友开网吧，我在北京这边寻价格、找人、定配置，虽然这都是我的老强项了，可是被夹在中间再受资金限制，这些事情运作起来就不那么顺滑了，凭空耗费了大量精力去解除两边的冲突。今天一个朋友评价山东这位朋友“该清楚的地方弄神秘，该通过诚信关系的地方却较真”，弄得我很不好做人。还好，忙活过这几天就好了。
同时，这周发生的最震撼的事情就是，我辞职了。虽然是意料之中，但是还有点留恋，这里离我家很近，可以方便在我爸妈身边，这样很快乐。可是公司改在9:30-18:00的作息时间我不习惯（当然这个并不是主要原因），再说下面的工作要去，这边的工作就要辞。虽然是男孩，但是也应该有点男人的魄力，很顺畅的辞职了。
我的爸爸妈妈对我很支持，他们说只要我快乐，随便我怎样他们都支持我。只是我要离开他们身边一段时间，谁都有点不舍。
GF的爸爸听到我辞职感觉很诧异，感叹现在的年轻人……，哎，我没觉得怎样，没钱怎么生活，如果现在的工作阻碍了我的发展，那么我就应该果断地选择离开，没什么留恋的。工作可以勤换，家人却不会变，他们的爱也不会变！所以换换工作又怎样。
想到上周开始在BJUG的Groups里面跟贴，虽然最近作的技术实践很少，但是眼睛还是盯着技术的发展的，我准备认真的学习一下Webwork，还有Javascript和Ajax，离开这里以后还要继续看。本来在公司一开始每天还有时间学习的，后来忙起来就不行了，我计算了一下，其实是可以的，只要利用好这些时间。
还有，感慨一下，每周在北京拥堵的交通上耗费的时间真多呀，总要赶很远的路去看GF，每次都要赶公车真是很苦，希望以后有个直达的什么什么车。现在花了第一个月工资的两倍办了张浩沙会所健身卡，上周和GF去体验了一下，这样的生活感觉会健康一些。以后有时间很想过去，可是路这么远，再快的车也不是办法呀，所以，终极的解决方案就是结婚。
在这里偷偷和我家宝贝说一声：你愿意嫁给我么？你什么时候嫁给我？什么时候能够不要我受长长的孤单行程的困扰？
嗯，越说越多，我现在很会跑题呀，哈哈哈哈哈哈

Java有些时候太Free了，也许这种左倾会成为麻烦，所以RoR之风又刮回来了，但是RoR其实也是个右派

恩，十一旅游回来，我们的单位在搬家，不得安宁。
今天抽空看了RoR中的表关系映射（many to one、one to many），使用has_one、belongs_to这样的限定，使用find_all等等那种RoR风格的自动反射的方法，真的很接近于自然语言，轻松舒适，非常优雅，而且节省时间。不过在改写我们的Level2项目的时候，发现需要改造的地方还是很多的，就是因为RoR的这个“约定优于配置”（Convention Over Configuration）的思想，很多地方我们都要手动制造遵从与约定的设计。比如Dish与Dishsort如果要映射，那么Dish里面就要有dishsort_id这样的字段，而不是dishtype……类似的情况很多。我的感想就是，如果系统是纯RoR实现，从头设计，那么用RoR会非常方便，而且可以得到震撼的结果。但是如果是遗留系统修改，或者是混合系统的开发，那么很多时候你就会感觉到约定带来的束缚是多么的不舒服。当初Java和.Net吵闹的时候就有很多JavaUser认为ASP.net里面的约定不爽……所以，我们只能说，Java有些时候太自由了，也许这种左倾会成为麻烦，所以RoR之风又刮回来了，但是RoR其实也是个右派。
真希望我们能走自己的路，自由欢快！

BTW：看看那个Free，中文的这个词还是个禁句，MSN真可怜，被GFW了。

intel和amd谁的cpu视频处理好

出于对Q3ACN一个讨论的回复。

视频……
你也不说清楚。
你说的视频压缩和视频是两码事。因为视频压缩属于单指令多数据流典型应用，也叫矢量运算，所以sse这样的指令扩展就很有用。但是怎么说AMD和Intel都不是矢量计算机，差距本质上不大，只不过AMD支持sse还是遮遮掩掩，受制于专利呀，所以优化后的程序Intel比较快。
但是关于视频渲染可就不是这个样子了，压缩器都是在具体平台通过编译器优化过的，所以AMD的超强浮点性能就体现出来了。你看现在那些大片不还都是AMD平台么（当然是因为性价比）。

Intel再牛也干不过专业硬件，视频压缩完全可以通过压缩卡来完成，绝对比CPU快。通用的干不过专用的。

前两天去听Java的一个会议。Jams Gosling（Java之父）在谈起下一代计算机的时候还在说，多内核是方向，低主频的集群会是好的解决方案。

我靠，太郁闷了，Struts这破玩意儿！

1、倒霉的Mysql-front，UTF-8支持太烂！！！！！！！
我这里凡是有中文的行，任何更新都回出错。以前是某些有中文的出错，看来中文支持肯定有问题。而且它的出错提示是德语的，真晕！！！
而且出错以后会奇怪的跳出新窗口，不停，必须用TaskManager关掉它。
我用phpMyAdmin就没有任何问题，很好用。
下午看看这个Mysql-front还有没有救药，如果不行就彻底抛弃。
2、我恨死Struts的ActionForm了！！！！！！！！
昨天我还只是觉得这个东西脱了裤子放屁，多此一举的利害。但是心想不过是浪费一些代码而已。
不过今天我继续发现，这个东西简直就是个隐藏的炸弹。
我本来没有在ActionForm里面写log做记录。心想如果里面发生了exception会抱错，因为我没有写try catch。但是后来我调试一个Action怎么都搞不定，明明在Action里面写了log，却怎么也不输出，我是异常郁闷！
大约浪费了两个小时后，我才明白，我这个Action调用了这个ActionForm，而ActionForm如果property匹配发生错误不会抱错的，也就是说如果那个request里面没有那个property它就会默认为null，而不报错。检查只发生在validate()方法，而这个方法非常恶心，如果发生了错误它会返回input的page，而不会报任何错误！（当然它存了ActionError在session）但是我却在log系统看不到，而且没有exception。就造成了程序中的一个黑洞，我什么都看不到。
而且ActionForm和input Page里面的html:text….那些标记的名称匹配非常费时，根本就不自动化，全部售动写非常容易出错，而且出错还有隐蔽性（没有的peroperty会null，前面说了），而又不能把所有null都到validate()检测，因为有些属性允许null，所以……
我快被ActionForm搞疯了！
所以，我越来越觉得Webwork2中那种Action和Model在一起的方式非常优秀，而且它使用了ongl，model的属性和前端页面通过命名规则自动绑定，省事多了。
所以，可以这么说，费了九牛二虎之力，ActionForm只能浪费时间和精力（Struts本意是使验证变得方便，容易测试），并且实际上测试起来非常困难，绝对是糟粕。记得有人说，既然Struts所有东西里都传了request、session这些东西，那么完全可以舍弃ActionForm，而把数据初始化写到Action里，如xxx=request.getParameter("xxx")，就和JSP里的Scriptlet一个样子，哈哈，不过这样Struts就不再是Struts了，只有形式了。如果伪需求要求必须用Struts，我们可以绕过（不用ActionForm，用request），或者小心点用。所以反过来说就是，我不想用这样的残废了。