ITPub博客

平常开小组例会时，大家提及最多的就是测试环境版本管理，经常听到某个功能的程序被其它更新文件覆盖，导致测试无法进行。开发人员经查找原因后，发现文件被其它人覆盖。这种原因引起的程序无法跑通是让开发人员比较懊恼，不仅担误测试时间和进度，也影响开发人员工作心情。这个问题确实挺复杂，在目前客观的软件作坊环境下还真难解决，特别是对于行业软件维护性项目。以下环境所说，也基于运维式项目。目前环境分为开发环境，测试环境，大版本测试环境，UAT环境，升级接收环境。解释下，开发环境主要是面向开发组，测试环境主要是面向测试

转发一篇同事在wiki上的文章，关于Java高精度计算"BigDecimal" 类。如果我们编译运行下面这个程序会看到什么？ public class Test{ public static void main(String args[]){ System.out.println(0.05+0.01); System.out.println(1.0-0.42); System.out.println(4.015*100); System.out.println(123.3/100); }}; 你没有看错！结果确实是 0.060000000000000005 0.5800000000000001 401.49999999999994 1.2329999999999999 Java中的简单浮点数类型float和double不能够进行运算。不光是Java，在

对于很多新保险公司，相对老三家而言，有很多劣势，如没有人员优势，没有规模优势，没有品牌支持等。但最大的好处是年轻，没有历史包袱，可以在一个新的平台上进行建设。对it系统来说，数据一开始就是采用集中的方式，没有各种垃圾和不完整的数据。但对于一家老公司来说，有各种各样的系统，数据库可以可能还在各地市。[@more@]近日从朋友了解到，某公司在进行完数据省集中后，也开始建立远程操作的平台，目的是实现总公司与各省市公司的数据连通，能在总公司层面更好的管理各省市业务操作。转发链接如下：http://2006m8017070051.itpub.n

去年是不停的做各地保监局见费出单，今年粤保监和河南保监局都发了手续费跟单的管理通知。估计这两个试点之后，其它省市都会效访。其中河南保监局要求做到"跟单，跟渠道，跟卡，跟账"，即每一张保单的手续费支付都要同业务来源相关联，且可以在系统中查询并能自动生成报表。4月27日广东省保监局下发了《关于印发<广东省保险行业手续费结算管理办法（试行）>的通知》。通知要求在6月1日之前驻广东各保险公司应对业务、财务系统进行改造，能够实现代理手续费的跟单、跟渠道、跟人并能系统即时计提应付手续费，实现系统自动生

保险合同由投保客户和保险公司双方共同签订，是确认投保人和保险公司各自权利和义务的法律文书。在保险合同中会涉及一些保险的专有名词。其中几个关键日期经常引起误解。如观察期，空白期等。[@more@]空白期　　保险空白期是相对于保险合同生效期间而言。《保险法》第十三条规定:“投保人提出保险要求,经保险人同意承保,并就合同的条款达成协议,保险合同成立。保险人应当及时向投保人签发保险单或者其他保险凭证,并在保险单或者其他保险凭证中载明当事人双方约定的合同内容。”　　从《合同法》的角度分析,保险合同的成立要经过要约和承诺

在保险公司运维项目中，经常会开发一些新产品，以满足市场需要。但对于it系统来说，有好多需求要素是比较通用的，可以通过调查问卷的方式发给业务部门进行确认，对运维开发商，也可以起到减轻工作量，避免过多沟通成本。摘录部分新险种开发调查要素:[@more@]险种名称，险类，适用范围 ，全公司范围 ，分公司范围，某分公司名称单证格式：投保单格式，保单格式，是否套打或全打，是否有其它单证适用条 款，投保险别 保单标的：将保单标的进行分类主要是为了分类进行管理 保费计算：是否有费率表; 费率浮动范围 保费计算公式（参考计算公式：

刚看到消息说，东南融通宣布合并国内保险IT服务领域的领军企业尚洋信德。呵呵，这下保险软件开发商可以拼一下啦。转发凤凰网如下：日前，中国第一家在纽交所上市的软件企业、金融IT综合解决方案提供商东南融通（NYSE：LFT）宣布合并国内保险IT服务领域的领军企业尚洋信德。两家公司合并之后，在保险IT解决方案市场的整体市场份额将居国内第二位，同时也进一步巩固东南融通在金融IT综合服务领域的领先地位。IDC的研究报告显示，合并前东南融通自身保险业务在中国保险IT解决方案市场中的整体份额位居第4位，在保险管理类解决方案市场位居第1

上海平台商业险集中解决方案，主要目标是由信息平台、保险公司、精友实现三方连通，实现机动车商业险统一车价，商业险保费计算和浮动系数计算。目前第一阶段主要是针对车价统一、浮动系数计算和商业险理赔进行改造。后续考虑商业险保费由平台计算。后面的这个保费计算，估计阻力会很大。看了方案，此次商业险集中主要变化在两方面，一方面是投保模块平台增加车价的查询，另一方面投保模块平台增加浮动系数的计算。相应的批改也要变化，但批改流程，没有明确的说明。详细如下：1[@more@] 投保查询接口增加，出厂日期、初次登记日期、车辆类

去年北京奥运之后，为持续保证空气质量，在2008年10月11日至2009年4月10日试行按车牌尾号每周停驶一天，限行范围为五环路以内道路（含五环路），限行时间为6时至21时，首次停驶车牌尾号规定：星期一至星期五分别为1和6、2和7、3和8、4和9、5和0（含临时号牌；机动车牌尾号为英文字母的按0号管理）。停驶的机动车减征停驶期间的交强险保费，平台处理方式同奥运减免。平台要改造，5.5系统上线，保证尾号限行交强险保费减免。1、 在查询交强险保费时(投保查询)时，接受信息平台返回数据中的”历史保单限行标志”数据项，由原业的两位代码变为

摘录一篇文章，是关于投保人知情权。现在保监会对各保险公司的条条框框越多啦。像去年各地的见费出单、航意险出单进系统、外网赔案状态查询、呼叫中心报案建设等。今天还得到一个消息，说*地保监要求管理起各保险公司车型价格，要统一用精友的车型库。呵呵，感觉这个管得有太深入。。。也不知道是否考虑过商务上的，实际各地保险公司的业务情况等。不过这样也好，至少事情多啦，我们it民工有饭吃。保监会29日在京举行2009年一季度例行新闻发布会，保监会新闻发言人袁力表示，保监会要求保险公司在制度上、流程上、技术上以最大的限度、付出

5.1开始，北京保监局能在各保险公司业务系统中查询到航协保单，以避免目前市场上航意险假保单的情部。与航联系统对接，能实时从航联出票系统提取数据。数据信息包括，被保险人姓名、被保险人证件号码、航班号、航程。一般，保险金额为60万元，保费为20元。系统改造涉及中航信、航联、代理和保险公司多方，相对来说外部接口比较多，变化和不确定性也更多。系统基本处理思路：1、 通过航协提供的接口，每间隔一段时间向航联平台发送请求，返回数据流2、 通过本地服务，将返回的数据流解析并保存到中间库中3、 通过定时程序，每天晚上将

最近项目组要求使用PMD工具，通过自定义规则来检查代码，接录部分文档内容如下：PMD介绍PMD是一种开源分析Java代码错误的工具。与其他分析工具不同的是，PMD通过静态分析获知代码错误。也就是说，在不运行Java程序的情况下报告错误。PMD附带了许多可以直接使用的规则，利用这些规则可以找出Java源程序的许多问题，例如：® 潜在的bug：空的try/catch/finally/switch语句® 未使用的代码：未使用的局部变量、参数、私有方法等® 可选的代码：String/StringBuffer的滥用® 复杂的表达式：不必须的if语句、可以使用while循环完成

前段时间，携程的假保单事件动静整得挺大的，其实不光是航意险，车险、乘意险等都会有这样的问题，只不过航意险等之类的交通工具意外险假保单比例比较多。这类险种一般为短期险，赔付低，利润高，都是通过撕票方式出单。像平常过年回家，坐汽车回家买汽车票时，总是被附带上一张1元或2元的保险。这种撕票的方式，定额保单进行销售，不是通过系统的方式出单，也对假保单提供了土壤。前段时间，某保监局公布《关于规范中介渠道短期意外伤害保险业务的通知》，《通知》要求，各保险中介公司在经营随车票等一起出售的短期意外伤害保险时，均应

今天参加一个培训，是关于Wily监控如何理解各种指标的。现在随着业务规模逐步放大，客户的it建设也逐步上台阶。去年，客户逐步实施Itil服务管理，建立起一线、二线和三线处理事件和问题机制。同样，对系统可用性、稳定性也提出更高要求。目前，上Wily后，基本上可以做到24*7的监控关键系统，中间件的内存和线程使用情况，主机cpu使用率，sql后台响应时间、前台业务响应时间等。Wily会搜集各种数据(Agent和EM相互通信)，在这基础上，根据之前制定的指标，阈值，条件等，进行报警，显示黄灯、和红灯。对于红灯这种情况，可能就要特殊关注啦，

近日，客户这边来了一个新DBA。开始进行数据库优化工作。第一步先提出优化索引，第二步对财务报表做具体优化。对优化索引，提出如下建议，添加遗漏的索引，调整不合理的索引，尤其是与财务、报表相关符合索引。一些基本原则摘录如下：1、distinct值太少的列不要2、distinct值多的放前面3、表中有一定量数据。4、复合索引的部分条件列被使用，这部分条件列在复合索引中位置必须靠前。还有监控用户使用习惯，根据实际情况来定制系统查询条件，也要引导客户尽量使用有索引条件。当然实际性能以实际环境为准。要考虑插入和查询的性能平衡(插入

今天周末，刚和战友们在干锅居一起吃顿饭，主题是庆祝是规则引擎对核心业务改造顺利上线。饭店又是爆满，上海这地方真的有趣，只要是吃饭的地方，路段好点，都是要等位，真没发现有经济危机。对于这种类似项目性质的任务，有明确的deadline，大家干起来干劲总是很足，上线后，基本上没有bug出现，对于这种紧急任务确实也挺难得，这里真要感谢开发组、测试组、版本组各位同事的大力配合，谢谢。之所以用规则引擎，我想对于保险业务部门，最大的好处，核保规则可以自己配置。对我们开发来说，也有好处，那就是经常变化的业务需求终于可以不用

最近各地区保监局都要求提高车险承保理赔信息透明度，维护保险消费者的知情权，遏制恶意扩大损失保险骗取条款。有这样的业务需求，相应的it系统要提供这样的系统，能让被保险人通过保单号或车架号，能查询到承保信息和理赔信息。 目前基本上各家保险公司都有电子商务平台，有一个客户服务模块。在该客服平台，可能会有各种功能，如保单验真，客服中心查询、投保流程，理赔流程等。 根据各地保监的要求，在外网平台上要能实现在线理赔流程查询，能知道该案件处于在哪个理赔环节，是否已经赔款支付。通常各网站会要求被保险人输入保单号或

一直以来想开个博，记录自己平常工作和学习点点滴滴。一方面，通过文字的形成给自己的做个简单的总结，一方面也想通过这样的方式，与网上更多的朋友交流，提高自己，也希望自己能在网络大潮中给别人一点小帮助。自己一直以来从事财产保险软件开发及需求分析，以后争取在每晚写一篇或摘录一篇与财产保险系统相关软件开发的业务知识点。[@more@]