不妨也来谈谈我的程序员气质观,或者说是特征观。 首先还是对技术的兴趣。兴趣永远是最好的老师,若能保持对行业技术的足够敏感度,那么相信技术这一关能轻松过去。当然,兴趣不是说三天打鱼两天晒网型的,而是意味着无数个日夜的思考和求索的精神动力。 有了兴趣就像有了永动机,但方向在哪里?如何运用这不息的发动机的能量?所以就有了自己的方向或者说专业细化的判断,说的更肉麻一点就是职业目标云云,诸如某某架构师,啥啥项目经理等等,在到达这个目标之前需要掌握哪些技能和经历等等,这些就是具体要积累的东西了。 目标有了,也知道要做的事情的内涵了,剩下的就是科学的方法论了。在我们十几年的中国式学习过程中,老师们通常 ...
数据集成是许多大型企事业单位扩展新业务应用的基础。下面简单谈谈我对数据集成软件产品的一些想法。 数据从源流到目标,一般是由一个称之为“任务”的角色来完成。“任务”接受传给它的关于源、目标以及投递之物这些信息,并准备工作。而任务A和兄弟任务B,C之间还有可能需要同步交互来协同完成整个事情,因此就有了状态任务,比如A,B,C都有两个状态:未完成、已完成,A-B-C必须得在前者完成之后才能执行自己,这样后续的任务就必须能够获知前面任务的状态信息。进一步来说,假如一两个状态信息还不足以支撑业务需求的话,那么就有了引入工作流概念的必要了。工作流引擎掌控着所有任务的状态信息,它主宰着所有任务的生命。那么, ...
HashMap经常在我们的应用程序中出现,它把key与value通过hash code映射起来,并存放到table中。在日常应用中,如果有这样的场景,就是基于HashMap封装成一个LinkedList,那么如何实现link的特性,还真是值得想想。在此先买个关子,欢迎大家积极参与讨论。
曾几何时,BI的先驱们为我们描绘出了光明灿烂的“智能”美景,那是一副多么诱人的“海市蜃楼”阿!然而时间和事实告诉幼稚的洗礼者,一切还只是完成了一半,另一半还在遥远的天际。 BI实施成功与否,在于它的前期实施是否对企业的后期管理决策产生影响,比如丰田美国公司在实施Essbase+oracle套件之后,很快在后期的实施过程中发现了一个管理上的漏洞,并及时纠正过来,从而帮助公司提升了业绩。反观国内的实施过程,实施单位在BI项目实施完之后,并没有带来管理决策上的影响,所谓的仪表盘、指标体系等等仅仅停留在“噱头”层面,BI的实施没有产生闭环。是该反思管理者没有重视BI的影响力,还是BI本身没有规划实施 ...
quartz是一个按照设定的时间规则来调度作业的调度器,比如可以设定每30s启动一个Job,但如果Job在30s内还未完成,那么quartz默认情况下还是按照设定的周期启动新的Job线程。 有这样一个应用场景,两个表结构相同的数据库A和B,A是一个实时交易的业务系统数据库,需要把A中的数据完全准实时的复制到B中。同时,交易表中存在一个时间戳字段,同步任务是每次按照这个时间戳来作增量同步的,即先在B中select max(col_timestamp)得到当前最大时间戳,再到A中获取大于该时间戳的数据集,最后再insert到B中。 在该场景下,如果前一个线程还未结束写的动作(比如一共1000条 ...
2008-01-07

Hibernate与大字段的持久化

关键字: hibernate
hibernate对于大字段的支持依赖于数据库的实现。 经常遇到这样的问题,如在oracle下如何把超过4000byte的字符串保存到数据库中,而varchar2的最大长度是4000。看了大半天hibernate对clob的支持,觉得太繁琐了,经过同事的实验,发现仅仅需要将oracle中该字段直接手工alter为clob,而在hibernate中对该字段的映射不变,直接设置为string类型,对于过去为varchar即可,长度保留为4000(似乎不限)。至于原因,应该是oracle的驱动在这方面作的很强大,自动将clob类型解析为hibernate的string。 在mysql下,只需要将 ...
2007-12-26

艺术软件

关键字: 软件 艺术
软件之与这个世界,两者有可比较性吗?我觉得两者存在惊人的相似之处。 从最初的计算机的起源,它就是用来模拟人脑,处理大批量的科学运算,于是计算机就有了个“电脑”的称呼。 再到上个世纪七十年代初软件工程的提出,它也是基于现实世界中的建筑与土木工程管理来的。 回到我们当前广泛采用的J2EE开始世界,类似情况就更多了。大到Spring、Hibernate这些在项目中经常扮演举足轻重的角色,小到Log4J、C3P0等等,这些都是专注于软件世界的一个特定领域问题。 一个亘古不变的真理是,“简单总是最有效最强大的”。昨天去七星滑雪场晃悠了一整天,从不会到两小时后敢于从中场的高斜坡上滑下,我印证了这样 ...
2007-12-22

风险规避

关键字: 风险
项目开发过程中,由于客户的需求变更或客户对系统分析存在不同解释的时候,不同的方案便会从客户方或者项目组内部涌现出来,作为系统分析师或者架构师又或项目经理(决策者),如何谨慎取舍,规避风险,以保障项目能平稳进行、并在期限内完成呢? 首先的一点还是,决策者的技术功底,当然如果技术功底不够深厚的话那么成为一名决策者的可能性也不大了。其次,是沟通能力,甚至说一个人的气质(很难表达,但暂且用这个词吧)。能把自己的思路淋漓尽致的表达出来,理直气壮的表达出来,这一点很重要,事实上不是好的设计方案没有想到,而是提出者或许根本就对自己的方案没有足够的勇气和信心去推销,而被埋没,如果是这样的话岂不是很无奈很可叹 ...
2007-12-15

集群——一个相对的概念

关键字: 集群
集群——一个非绝对的概念。 初次接触集群的开发人员一般都很好奇,怎么集群这么牛比,能动态同步应用上下文(亦或称之为session复制)!但事实并非完全如此,所谓集群、负载均衡,这些都是一个相对的说法而已,它们也是通过许多策略组合在一起,以到达某种程度上的同步效果。 待续...
你说的是目前业内现状的一种,但我要提醒的是这并不是全部。 从团队建设的角度来说,虽然一般的开发人员水平有限,但正是沟通——通过沟通,能把知识从一个人的头脑传播到整个团队,这是提高开发效率的好途径。 其次,让每一个团队成员了解项目的整个全貌,这样使得他有意识的认识到自己在作哪一部分,这样不仅能提高他本分工作的效率,也能在必要的时候参与到其他人的工作中,避免了分工不均或者因为人员流动而造成的混乱。
tigers
搜索本博客
最近加入圈子
存档
最新评论