2006年04月11日

        最好不要在程序里面将一些exception catch住进行自主处理,对于那些在spring 配置文件中被声明为“忽略处理”的exceptions,自行处理问题不大,但其他的exceptions,必需交给spring去管理。初学者如果碰到transaction似乎并没起作用时,最好先检查下是否有一些exception被catch住自行处理了。

2006年03月19日

        出现 “严重: Error listenerStart”错误的解决,通常是部署不完整,比如classes没有生成等。因此,碰到这个问题时,建议首先检查一下部署的目录下的内容是否完整。举个例子来说,在eclipse里使用jsf plugin时,会自动临时部署到一个叫.deployable的目录,有时这个目录下的内容会出现不完整的情况,需要小心。

Enviroment:  DB2 8.1

        使用DB2的时候,添加远程数据库instance到local的操作步骤,
选择“配置助手”,再从menu上选择“使用向导来添加数据库”,选“手工配置数据库的连接”,其他主要步骤如下:







这里“服务名”不知道的话可以留空。




这种配置方式比选择“添加系统”要容易些,后者需要了解更多的参数。

         在项目开发过程中,有时会出现一些奇怪的问题。
 
        有时候有的代码从道理上明明应该可以执行到的,但就是不过去。在这种情况下,如果在这段代码里随便加句把输出语句或者其他的无关痛痒的语句,就能神奇的执行了。
        在调试状态下,碰到上述情况,死活就执行不进去,但也不会报错。如果仔细观察会发现,设的调试的breakpoint旁边没有一个小“钩”,这也表明它不是active的,所以没法调到这地方。这种情况目前好像在websphere和jboss作为应用服务器时都出现过,但是否跟app一定有关似乎没法解释得通。这时候不妨就反常规的试下,往往会收到效果。
 

在eclipse 3.1里开发web应用时,当使用“Open Type Hierarchy”时,有时会出现命名有source files,但还是出现class文件不是java文件,即使在同一工程里。这当然不是希望看到的。希望看到的应该是尽量出现源码而不是class文件。

经仔细查看发现,是build path里设置了“web app liabries”的缘故,“web app liabries”不仅包括jar文件,还默认指到了class文件忙碌,这就是出现class文件而不出现javasource文件的原因。因此可以弃用“web app liabries”来解决这个问题。

2006年01月15日

作为项目领导者:

今天知道下一个工作日的todo list,是为了让项目组成员在下一个工作日伊始就明确知道当天要做什么。

本周知道下周将要做什么,是为了让项目组成员对新的一周要做的事有个全局的概念。本周结束前应该有了下周的详细的计划;本周结束前应该有了下周的除项目计划外初步的todo list。

对可预见的可能发生的问题不要等它发生了再去做后续处理,而是要考虑好如果发生了,将怎么做。比如知道下周要做某件事但还没制定计划,某个技术难题,某资源尚不具备等。

        领导在下属面前永远没有理由趾高气昂。任何的威信不是吓出来的,也不是吹出来的。领导领导一个团队,他有理由去尽量了解直接下属团队里的每一位成员。一个对自己的团队一直不甚清楚的领导,或许算不上是一个好领导。

        深入下属,你可以更多的了解你的下属。比如你会了解到谁表现更抢眼些,谁常常会碰到了一些问题又不知如何解决,谁会容易发牢骚和抱怨,谁更有方法,谁做事更有弹性;

        深入下属,拉近了你和下属的距离。有的下属很害怕上司,特别是刚毕业的大学生。在你深入下属尽力去了解你的下属的同时,你的下属对你有了也更多的了解。这是双向的,多一份了解,无形中已经多了一份沟通。

        在项目开发当中,常常会碰到几个部门或者几个team之间需要协作的情况,特别是存在资源依赖的情况。在同一个组内也常常会因工作的分工而出现这种情况。

        存在着协作,就存在这协作同步问题。比如开发组基于研发组的成果进行开发,研发组基于预研需求组出具具体的预研需求。在这些依赖当中,越靠前、越底层的依赖显得越重要,俗话说“上梁不正下梁歪”,建房还得先建根基,并且根基得夯实。这个游戏规则意味着提供那些比较偏底层的artifact的部门/team似乎要承担着更多的责任。但在实际的项目开发当中,不可避免的会出现依赖的资源不总是令人很满意,甚至一般满意都达不到。这时候如果怨声载道,其实是无济于事的做法,甚至严重的会影响部门/team间的已有的“感情”。

        俗话说,“理解他人,理解自我”。更多的时候是要去理解兄弟部门的“处境”,尝试去“理解”他们提供的“服务”为什么不让你满意。这样你才会提出一些建设性的建议或方案。兄弟部门做的是不好,但不可否认的是他们付出了劳动,他们也曾有努力,我们应该首先让他们感觉到尊重他们的劳动,然后在此基础上给出我们的建议。一个协作团队被否定了哪有被肯定了更容易沟通呢?更何况说生产力。所以,还是多一些肯定为好。

       建议在向兄弟部门提出改进意见后并得到了他们的切实落实后,以正式的方式表示下感谢,比如,发送email。最好不要用msn直接发一个message过去就了事。有谁喜欢自己的劳动不被认可呢?一个小小的email感谢邮件会让对方感到最大的宽慰,感觉到劳动被接受和认可。

        永远相信每一位下属,作为领导者,要具有开阔的心胸,有容乃大。

        团队里的下属成员的能力因其经验、学习、领悟等能力的差异而常常表现出一定的差异。但是,作为团队的领导者,重要的并不是发现了这个差异,而是去发现每一个人的长处并灵活运用到工作当中去。当一个下属的长处能与工作结合起来时,你会发现你的下属工作变得更加轻松、容易,从而有了起劲和激情,结果也将让你更加满意。

        作为一个领导者,当下属做得不当或不妥时,不应是用自己的权力去批评下属,而应该以一个帮助者的身份去尽量地帮助下属,去正确的、行之有效的引导。你的一点真心的帮忙换来的将是你的下属的工作成就感的点滴积累。这是一个双赢的做法。何乐而不为呢?

<UL>…</UL>

用布告列表条目创建非排序列表。结束标识是可选的。

主要属性有:TYPE=disc|square|circle 它用于指明布告的形状COMPACT 以紧凑形式格式化列表条目。

 

<LI>…</LI>

定义一个列表中的一项内容。结束标识是可选的。

         TYPEA | a | I | i |1在一个有序列表中列表项所有的记数类型或者改变无序列表的项目符号(圆盘形,方形,圆圈形)

         value="…"在一个有序列表中显示在列表项之前的数字。

<LI> 常跟<UL>连用

 

<P>…</P>

用于定义一个段落。结束标识是可选的。主要属性有ALIGN=LEFT|CENTER|RIGHT,用来控制对齐方式(left, right, center, justify)

 

 

<CODE>…</CODE>

标识显示时的代码碎片,以程序代码形式格式化文本。必需有结束标识。

 

<B>…</B>

使文本以粗体显示。必需有结束标识。

 

 

<I>…</I>

使文本以斜体显示。必需有结束标识。

 

{@link FacesContext}

生成一个链接。