好见地。题外话，如何反乙肝歧视

那么多公司公然违反劳动法歧视乙肝携带者雇员（哪怕已勤恳工作了几年），我建议立法如下：

由于乙肝被解雇者（或者应聘通过以后，最后一道体检关口被卡者），去劳动局举报，只要公司不能举证其解雇不是理由充分且完全和乙肝无关，则罚款若干元（10000元-10万元），然后提成30%或70%给举报者。举报只凭劳动合同和公司要求体检的结果。

辅助规定是，公司必须先发应聘成功通知（offer），才能要求去体检。

实际上根本就应该取消体检，法律有规定的行业除外！这才是根本之道



作者：吴稻子　回复日期：2007-11-13　12:43:22　
　　写得很好。
　　我也是搞技术的，电子方面，我也打算再过几年自己创业，很可能也是从饭店做起。谢谢楼主提供这个文章。
　　看到这里，我有如下感慨：
　　楼主老公犯了大错，是导致楼主失败的主要原因。这个错误就是没有选好人。用亲人也要量才适用，楼主老公的亲人品性如此，的确根本就不要考虑使用。亲人用的得当，确实可以同心协力做好，但是用得不好各种关系极其不好处理，楼主老公的亲人品性如此，用之大忌大忌啊！
　　楼主也犯了错误，楼主的错误在于管得过多。楼主是做人力资源的，应该知道一句话“疑人不用，用人不疑”。“疑人不用”楼主已经做不到了，因为楼主的老公已经铁定的定下来了，此时已经是一个烂摊子。那么楼主可以努力做到“用人不疑”，也就是我撒手不管了，NND，我把这钱给你去弄了，大不了亏光了，我自己打工去，眼不见为静（你不要说，你老公要你帮忙不让你走哦，我相信你铁了心不管了，应该还是可以走的开的。我把钱都给你，你放手去干，我对你的革命事业前途不看好，我去打工贴补家用还不行吗？你成功了，我也高兴；你亏了，就买个教训啦，还能怎么着？）这个方法虽然看似有点消极，其实是一种很聪明的做法，也是唯一使事情好一点点的正确的做法。为什么？因为在开张之前，你就应该会明白，你和他们会处不来的。而你不是一个看着不顺心的事情可以不说来的人，有什么一定会说（连包装袋几毛钱的事情都要理论一下），而说出来只会使事情更糟糕，关系更不协调。就算你某个事情忍着不说了，其实你内心非常的愤懑。所以不管你有没有说出来，你开店期间，相信心情一定是一种很愤怒，很郁闷的心态（你现在回想开店的日子，可能印象最深的还是心里那呼呼的怒火吧^-^）,大姐，长期的郁闷会容易衰老哦，还会闷坏身体，更严重的是你这么做一点效果也没有！！。所以你掺和进来，对你其实一点好处也没有，那时去打工强多了，是不？你对很多事情插手，对你自己没好处，反过来，对其他人有好处吗？其实你这么做，不仅自己遭罪，其他人也遭罪。他们的做法和路线是错了，但是他们做毕竟有自己的想法，虽然是错的，也是一个想法吧，把这个想法做完了，也总有点效果吧。你这么一掺和，得，他们的想法贯彻得不彻底（或者贯彻得不爽），他们错误的想法的效果也没体现出来，你“正确的想法”（你也没经验不一定正确）的效果也没出来。还怎么办好事情呢？你什么事情都管，又都没效果，只会使你们的团队束手束脚，影响关系和谐。所以你那时不加入，走开一步是最聪明，最正确的做法。楼主是否反省否？
　　从文中看出，楼主也是一个有思想有个性的人，所以才会不时的表示处自己的看法（呵呵，虽然一个团队有且只有一个说话的人就够了）。在这里我希望楼主是一个坚强的人，NND，哪里跌倒就从哪里爬起来！好好调整心态，忘记那痛苦的开饭店的经历，从那里爬起来，这样当你回首往事的时候，就不会再有痛苦

好书待读：

统计，改变了世界

第一章就提到《女士品茶

《随机性》一书也不错

IT经验网：数据仓库经验

一、为什么要推动data warehouse

自然演化体系会带来很多的问题：

1、数据可信性（两个部门提供的数据是不一样的，让管理者无所适从）；

a、时间的基准不一；b、算法差异；（认知不一致）c、无公共的起始数据源

要靠推动data warehouse使各部门之间对相同元素认知、定义和算法一致或者趋于一致；

2、报表的生产率的问题；由于oltp的单项系统导致数据的分散性和相同元素定义不一致所致；

3、oltp的系统中无法保留很久的历史数据；单项系统之间保留的历史数据时间范围不一致； 无法满足dss分析的需要；

4、oltp的单项系统中对维表的关键栏位的更改很少有记录；（如：客户的业务员的变更问题）

5、面向应用的设计无法满足面向主题的分析的需求；oltp和dw对后台设计要求的重点不同，oltp主要在意的是update和insert，而dw主要在意的是select；

6、因为决策的需求大多是“灵光一现”的，是“前无古人”，“后无来者”的，是启发式的，而非固定式的；

7、分散的系统导致业务行为不可控，dw能够对各地的业务行为进行事后的监控；（如：产品代号，折让的问题）；

8、dw能够把user从复杂的统计工作中解放出来，从而提升企业的管理，让user有时间从事对企业更有益的事情。还可以精简企业的人员；

9、降低企业获取信息的费用；提高企业的决策速度，加快企业对市场的反应能力；

10、没有dw，IT部门总是处在鞭梢的位置，总是在被动的响应状态；（因为主管感兴趣的事情总是不时的变化的）；

11、可以透过dw来观察公司的新的政策或者新的行销活动给公司带来的变化；(事件映射)

12、dw是EIS和数据挖掘的基础；

二、推动以前IT人员要有的观念

1、首先满足用户的需求，再在用户使用过程中去引导用户朝正确的方向走；

2、老板看的投资回报；

3、永远比user考虑的明细；因为管理是一步步精细的；

4、dw是反复才能建成的，所以dw的版本要不停的迭代开发；

5、olap 软件可以是dw的组成部分，但不是必选的，大多的olap的软件数据库是多维的，从dw中把资料刷新至多维的数据库中会比较慢，但对多维的数据库查询起来速度必二维的速度快的多；所以是要根据user需求来进行合理的选择；

6、前端的展现工具一定要有向上和向下钻取的功能；

三、和老板沟通的观念

1. dw不可能满足所有的需求，Data warehouse 项目同样需要界定边界；

2. 同样的资料，角度不同（如财务，销售，市场，管理），结果就不一致，所以允许差异的存在，但差异要在可解释的范围内； 通过定义不同的规则来玩这个游戏；

3. 问题的关键不在工具的好坏，而在于资料的可信度，原始数据和业务行为的规范；

4. 业务术语的定义和解释应由专门的单位来处理，从而保证集团自上至下的对术语定义的一致性；

（如销售业务行为中“铺货率”的定义）

5. 企业高层的支持非常重要；

6. 公司内的oltp系统数据是动态的，总是在变的，所以dw中的数据也会随之变化，dw中昨天看到的数据 和今天看到看到的不一样，不要大惊小怪；

7. dw是用来做趋势分析、预测和提供数据挖掘的，对数据的要求不是非常精确，所以千万不要拿dw中的数据来计算sales的奖金；

8. 集团上下对为什么要推动dw及dw的作用的认知一致是非常重要的；

9. 最终用户专业化，要花很多的时间对end user进行培训，提高user的认知，最终的目标是user自己设计报表；当然是在前端，而不是在“厨房”(后台)中；

10． 软件选择宜横向联合，强强联手，不是一家的软件可以搞定一切的；

四、dw设计模式和方法

1．dw应建立在RDBMS(关系型数据库)中，而dm可以建立在一个RDBMS或者MDDB(多维数据库)中；

2．dm采用星型设计是原则，雪花模型是可选的；

3．dw的设计模式和oltp的设计模式不一样的，oltp的设计模式是以需求为驱动的，而dw的设计模式是以数据为驱动（分析处理为驱动）的；

4．面向主题的设计，数据从操作型的环境流入dw中时，数据必须是集成的，而不仅仅是将数据扔到dw中；

5．一次开发一个主题的原则；

6．在dm中逆规范化的设计是必要的，以空间的冗余换取响应速度的加快；

7．遵循给“用户想要的东西，然后用户才能告诉你需求是什么”的发现模式来开发，成功的关键在于结构设计人员和dss分析人员（user）之间的反馈循环, 迭代开发的模式；

8．开发流程：首先应建立企业数据模型（描述企业的信息需求，明确了企业主要的主题域，不一定是企业已有的东西，不考虑任何的技术问题）→ 分解至中间层模型→ 定义记录系统（数据源的定义） → 设计数据仓库→ 设计oltp与dw之间的接口；

9．5％的dss处理的需求在原子层，95％的在概要层；（查询分离的设计）；

10．从fact表开始设计，然后开始设计dimension表；维表的设计要逆规范化，事实表的设计要3nf；

11．弹性的设计（建立规则库，通过规则解析引擎解释规则至最小的粒度的设计）

12．资料可信度的设计；

13．规则库和规则转换设计；

14．各地的对相同的栏位定义不一致（如：有的地方用0和1表示男女，有的地方用m和f表示男女）没有关系，但dw中的定义要一致，通过清洗程式转换成dw中的规则；

15．有限的使用的代理健；

16．有限的使用外健来保证参照完整性；可以使用procedure检查；

17． Slowly changing dimension（慢速变化维）表的处理：不要使用oltp系统中的business key（业务健）作为维表的primary key（主健），而使用代理健，当慢速变化维的关键栏位发生变化时，不要update原来的记录，而插入一条新的记录；这样能够dw不会出现错误而且可以跟踪维的历史；

18．字段级映射（field level mapping）一定要建立;

19．集团总部dw的资料可以回流至各分公司的数据库中，这样可以灵活的处理需求，一致的需求，总部处理，特殊需求，各地处理；

20．dw中无论是fact table还是dimension table，强烈建议给每条记录加上时间戳；

五、粒度的选择

1、资料的粒度级别需要权衡，采用多重粒度的设计；在磁盘允许的情况下，建议尽可能的按最细粒度存储数据；因为dw中存储的粒度越细，dw回答问题的能力就越强； 要先估算事实表的行数（一年内的最少行数和最多行数乘以字段长度）

2、对于不活跃的数据可以分离（至磁带或者备份的磁盘上）；减轻dw刷新和管理的难度；

3、dw的特性之一，表现为汇总数据还是细节数据是由观察者的不同角度决定的；

六、dw的安全

1、根据user的不同的权限看到的数据也不一样；

2、数据库放在内网的是原则；

3、通过profile限制并行的用户数；

4、在brio server中限制帐号一个月不使用者封帐号（更改密码为当天的日期）；

5、装载阶段限制ip和user登陆（通过trigger）；

七、dw 性能增强方案和oracle的技术的运用

1、可以使用的技术有：materialized view（物化视图），星型查询，专用大回退段, QUERY REWRITE(查询重写),partition table，organization index table（索引组织表），PARALLEL（并行）

2、充分的index，建立必要的概要表（summary table），大表必须分区，query rewrite和mv均可大大提高dw

的性能；

3、小技巧：加载前drop一些index以提高加载的性能，加载完毕后重建index；还可以通过view来实现和简化查询重写；

4、oracle优化模式rbo和cbo的选择：建议尽量使用cbo；

5、作为数据仓库的后台数据库，oracle的安装方式和init参数的是有别于oltp系统的后台的数据库；

6、加载阶段和访问阶段采用不同的参数设置来启动db；

7、访问阶段使db只读，减少db的本身的管理损耗；

8、由于dw特性，不用在数据块上保留很多的自由空间用于以后的记录的更新和插入；

9、修改os的参数，如：加大os的串行预读参数，异步io，甚至修改cpu的时间片；

10、磁盘阵列的选择：条件允许的情况下建议raid01；

八、规则库的定义和设计

1、业绩公式规则；

2、单位对资料可信度影响的权数的规则；

3、业绩归属的定义；

4、上级组织在不同的角度是不同的（如：财务和销售）

九、dw运用的％

2％的bpm、kpi的管理；3％的数据挖掘；15％的数据分析；80％的report；

十、让我头疼的几个问题及解决方法

1、由于是从分散的系统中抽取资料，所以各个公司相同的系统中基本资料中对基本数据定义可能会不一样；如：A这个产品代号在华东表示冰红茶，在华南可能表示冰绿茶；抽取至dw中的数据失去可比性；

我的对策：

a、如果是关键性的基本资料，在集团总部和各个公司建立一个公共系统（PUB），把各系统基本资料抽取出来，并规划出哪些栏位是总部必须要控管的，然后放入PUB系统在集团总部控管，所有系统的基本资料的总部控管栏位的来源只有从PUB系统中来，集团总部有修改和新增的权利，下属各公司只有查询的权利，下属各公司如要新增和修改必须至总部申请；对于非总部控管的栏位各公司可以自己更改；PUB系统的table资料定期的同步至各公司的数据库中；

b、如果是非关键性的基本资料，建立对照表翻译成dw中的定义；只不过抽取程序设计会麻烦一点；

2、业务的术语定义集团内没有共识；

如：华东区认为销售铺货率应该这样计算，而东北区认为应该那样计算，而集团总部又是一种说法；

我的对策：请集团的高层建立或者指定相关的权威部门协调各方并给出标准的定义；不要迁就于各分公司的不同的算法而客制出不同的报表，那样只会让各分公司看到的报表数据失去可比性且让各方因为数据的问题吵的不可开交；

3、由于lotp系统老化且分散在各分公司中，所以导致各分公司相同的系统其中的运行的逻辑会有差异，相同的table相同的栏位存储的数据计算规则不一致；

我的对策：没有什么好的方法，要修改老化的系统使大家一致不太实际；因为会牵涉的系统的太多，并且老的语言精通的人不多，如果修改不知道会发生不可预测的问题；

所以我只有请各公司了解自己的规则并填入我们规划的规则库，我们的抽取程序依照规则库中的规则来抽取，并且各分公司的规则更改时，也请他们更新规则库；

4、各分公司IT部门以前替各自分公司的开发的类似dw系统在使用并且数据可能会与总部的dw中数据不一致，各分公司对集团总部推的dw系统有抗拒心理；

我的对策：首先请集团的高层向各分公司做说服，并且向集团的高层申请“上方宝剑”，其次通过dw的资料回流至各分公司数据库，使各分公司的自己开发的类似的系统的数据源来源于dw中，这样就把集团总部和各分公司捆绑在一起；

5、dw中资料刷新的问题，因为oltp系统的可变性，导致抽取程序在从oltp系统中抽取资料时不知道应该扫描哪些资料，oltp哪些资料自上次抽取后被更新了(变化数据捕获的问题)；

我的对策：这个应该是所有的做dw项目均会碰到的问题；

a、如果抽取的table是比较小的table，在不影响可以oltp系统性能的情况下，可以在oltp的系统的table 上加入trigger来记录更新；抽取程序可以根据记录来只抽取更新的记录；如果加trigger有困难，每次把table的全部资料抽取回来也可；

b、上面的方法只能解决小部分的问题，大部分是要通过时间戳的比较，或者充分理解oltp系统的规则，如oltp系统不会更改多久以前资料，oltp系统是否有结转的概念，如果要更改已结转的资料是不是在什么地方有记录之类；根据具体情况具体解决；我现在负责的这个项目的销售这一块在oltp系统中有结转的概念，如果要更改已结转的资料必须要进行结转回复；所以我们在设计抽取程序时有一个抽取记录的table，用来记录该分公司的销售系统资料日期、该日是否已结转、抽取的次数等等；并且要求oltp系统中日结的程序加入，如果做日结回复必须update抽取记录的table其中的抽取次数为0；我们的抽取规则就是：抽取抽取次数为0的日期的资料，但未日结的资料不管次数为多少均抽取；抽取完毕后update该table相关栏位；

十一、其他

1、后台的程式执行出错时，log记录至table中；并自动发出mail通知相关的人；

2、执行成功，成功的记录至succmsg中

Leon对语义网的评论

“Net”是将计算机连接起来的计算机网络，“Web”是将计算机上文档资源连接起来的超链接，而“Graph”是将这些文档资源内的things/people/places等等更小颗粒度的实体连接起来一种模型，语义网(Semantic Web)中的RDF、OWL等等技术是能够实现这些连接的一种方法(当然SW的技术同样可以实现Net和Web的模型，但它更大的用处在此)。Web以Net为基础，而Graph又以Web为基础。
在Tim的文章中，有三句话很精辟的刻画了这种Net --> Web --> Graph的变化
Net "It isn't the cables, it is the computers which are interesting"
Web "It isn't the computers, but the documents which are interesting".
Graph "It's not the documents, it is the things they are about which are important".
Simpler, more powerful. Obvious, really.

（来自w3china)

实证比猜疑重要

Action is the best exporation

这也是这二年工作中学到的很重要一点，不要猜想，用可以证实的东西，对比的手段，可信得多

〉破解野生华南虎照片之谜（迪派）”

我们同样相信，假定没有其他因素，参与鉴定虎照并确认老虎为真的知名动物学家和摄影家们，看到上面两幅照片的对比，并非浪得虚名的他们，对图像的视觉感受应该会比常人更强烈些，鉴定的结果也不可能不改写。因为我们所知道的是，这些级别很高的专家当时，并没有使用什么超出视觉感知的鉴定手段

Dell inspiron 1300电池问题

买前应该看看评论。。

this really frustrates me. I've only had the lap top for less than 4 months and already i have to get my battery replace. Dell should defiantly do something about this. Already there are 29 other bad reviews about this battery. We shouldn't have to pay another 129 dollars or evan yet another penny for a new battery.

5 of 5 people found this review helpful.

还算不错，电池灯变黄前用了快2年了。。。

好处：dell保留网站上不好的评论

坏处：这电池实在不怎么样。。

下次买东西不能相信Dell..吃一堑长一智。。Dell和Compaq口碑好像都矛盾很多，很多人说好很多人说不好。

ABRO胶

居然在此事之后，连Zabro这样的商标都看不顺眼？

都是钱闹的。。

中国应该发旅行证让他回国（不管英美法规），然后自己严审，或者直接接到领事馆进行领事保护，然后严审。。

然后提高国民收入，自己发展，别再妄想着通过做打工仔发财。

同时武力威胁，防止下次有人敢进入中国航空器抓人。。


唉，不太可能（严审），丢人。。造假都造不好，搞不定，自己还不藏好？


www.engin.brown.edu/courses/en100/IP/Abro.htm+hongwei+yuan+us+ABRO+Industries

www.2theadvocate.com/news/suburban/10517127.html

想起我们商住楼小卖部的送货老大爷

张永青反思“e国一小时”失败的原因

对象和数据类型不同

前2天还看别人出错，有人提醒，这次我也犯了数值比较的错误，比string内容是否相等的时候用==，结果老也不相等。。。

因为String是对象，比较内容只能用.equals()

如何打印出异常Exception的内容

public static void main(String[] args)
{
try{
TestZip t=new TestZip();
t.zip("c:\\test.zip","c:\\test");
t.unzip("c:\\test.zip","c:\\test2");
}
catch(Exception e){e.printStackTrace(System.out);}


public void zip(String zipFileName,String inputFile)throws Exception{
zip(zipFileName,new File(inputFile));
}
public void zip(String zipFileName,File inputFile)throws Exception{
ZipOutputStream out=new ZipOutputStream(new FileOutputStream(zipFileName));
zip(out,inputFile,"");
System.out.println("zip done");
out.close();
}



http://www.chinaunix.net/jh/26/106061.html

还是要看源代码，这是最大的example，找好合适地方开始看就行

终于明白过来了。。应该看protege自己的源代码。。这就是最大的sample..

不过protege一般人家看owl plugin的代码比较多吧。

楼主稍显浮躁了，很多东西在protege wiki里面


fwd:对Protege OWL API的一点粗浅认识

1、基于Protege OWL api的开发环境设置
Protege安装目录根目录下的所有JAR包，以及plugins\edu.stanford.smi.protegex.owl\目录下的所有JAR包导入构建路径即可。

2、它的API操作比较方便，而且说明好像多一点，基本每个方法都有一点说明，edu.stanford.smi.protegex.owl.swrl.util包中有很多实用的方法，如创建实例，取得实例，取得类等。
3、感觉使用SPARQL查询有点怪，主要看的是edu.stanford.smi.protegex.owl.model.query.SPARQLQueryResults里的方法，顺便看了一下这个类的源码，是调用Jena的方法实现的。
只是看了几个小时的一点认识，也不知道对不对，请大家指正

看SWRLOWLUtil.java的途中顺带找到了owlx目录中的一些实例程序：

javademoapplication.java

CreateSimpleWOLModel.java等好多。。


拿出探索H光盘一半的精神就够了！

NetBeans调试土办法

似乎是缺一个socket服务器无法调试，可以用jButton.setText("位置+变量值")的土办法调试

以及可以把图形元素放好位置，复制代码删除后，用myInit()来重新加入，这样可以避免难以用GUI完全定制元素的问题。。

protege core里用Cls类和Projecte类就可读出owl文件内容来，但是有点问题（有重复），改用owl api说明里的RDFSClass或OWLNamedClass又根本不显示，想debug step by step但是好像没有某个debug 的socket服务器无法调试，

决定采用OWLNamedClass。。“Unless you are explicitly working in RDF, you will most likely create OWL classes.”


现在用jButton1.setText("debug location and variable value")土办法来调试。。惨


发现了不能显示的原因是修改的时候经常顾此失彼，从Cls和.pprj文件换过来的时候忘了去掉一个显示入口的条件判断了。。。

Java编程偶得

用netbeans，发现经常卡在一些很基础的问题上。比如采用weka的类代码，却忘了类里的变量名和我用netbeans生成的变量的名字是不一样的，

java 破文档：replace(char oldChar, char newChar) ，害我以为不能用于替换字符串！！！！！！！！！！用了replaceAll却没注意其是用于“正则表达式”所以会自动加中括号！



用protege的示例代码，（自然）没有package申明，却出看似非常无关的Exception in thread "main" java.lang.NoClassDefFoundError错误。

早上就看到的东西，居然还是难了我一天。。哭，因为我觉得已经加过了。。

静态函数不能调用非静态函数

UML：用例图，类图，交互（顺序图，合作图，活动图，部署图

GoF

MVC模式，Front Controller模式

decorator模式：把多个小的pattern合并为模式？只有一个child，但是可以chain。在执行被装饰类的方法前，执行一段装饰代码 myDecorator implements Filter {}

Service to Worker模式：维护actions, views, controllers关系。可以把service理解为 front controller,work理解为page-specific action.其由dispatcher来调度worker和view.作为例子,work flow,其model是userbean(存用户名等数据），view是JSP页面，读model data, action作为command模式的实例.这里的front controller管理dispatchers,用他们来选择下一个view.
所以S2W将controller分为FC,dispatchers,actions，以便重用（比如把页面重用）

viewhelper模式用于加强JSP的重用性，在data和view间加一层，有时直接出html，有时作为intermediate数据模型

JSP: custom tag(some function that let page calling, HTML users can call any function without knowing details

XML：编程很容易联想到应该符合DOM文档对象模型，但有简化的SAX 简化Api 4 XML 用于取回几个简单对象。

DOM就用parser来解析文档

XML大小写敏感

SOAP：envelop, data encoding, RCP convention

JDBC has two layers:ap layer, driver layer (jdbc:msql://dbserver.eng:1112/bugreprts
APP layer has 3 main compo:resultet, statement(PreparedStatement for arguments,CallableStatements for SP) connection. Rowset 和 dittoresultset用于改进

顺手还发现了，为什么我的程序窗口突然启动是最小化，因为我把pack()给注释掉了，而我不知道pack有这么重要的设定size(又让layout manager继续管理）的功能
System.out.println("I am mad at zis");

>如果有读者遇到下列错误信息，请确认protege根目录下的所有jar包都被添加到lib里了。

Warning: Cannot set console log debugger handler.
Warning: IO exception getting logger. null
Exception in thread "main" java.lang.NoClassDefFoundError: com/jgoodies/looks/plastic/PlasticTheme
at edu.stanford.smi.protege.model.Project.(Unknown Source)
at edu.stanford.smi.protegex.owl.ProtegeOWL.createJenaOWLModel(Unknown Source)
at edu.stanford.smi.protegex.owl.ProtegeOWL.createJenaOWLModelFromURI(Unknown Source)