日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | ||||||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 | |||
| 12 | 13 | 14 | 15 | 16 | 17 | 18 | |||
| 19 | 20 | 21 | 22 | 23 | 24 | 25 | |||
| 26 | 27 | 28 | 29 | 30 | 31 | ||||
搜索标题
最新评论
统计信息
- 访问量: 2994
- 日志数: 24
- 建立时间: 2007-01-15
- 更新时间: 2008-03-25
我的最新日志
-
RUP和IPD流程的优缺点
2008-3-25
RUP的过程改进,倡导针对不同类型项目进行适当的裁剪,实际上这也是一种灵活适应的方式、随需而变的思想。我对此是理解并赞同的,但是我对RUP却一直保持一种相对谨慎的态度。
对于RUP来说,首先,我认为它过于理想化和理论化,RUP 是过程组件、方法以及技术的框架,你可以将其应用于任何特定的软件项目,由用户自己限定 RUP 的使用范围。对于各种类型的软件项目,RUP并未给出具体的自身裁减及实施策略,总有些无依据可循的感觉。你既可以说它能解决任何问题,也可以说它什么都不是;其次,RUP从本质来说还是一个强调设计和规范的软件方法,从这个角度来讲,与传统的瀑布模型没有太大差别,它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预测的软件项目开发中,面临着各种紧急需求、面临着时间压力,沿用RUP是很难应付自如的。但是在另一方面,RUP强调对知识的收集、整理和加工定义,强调在软件开发的时候要有好的体系结构。所以它还是很有利于知识的积累和共享的。
相比RUP ,敏捷方法如XP则更为灵活,倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟通取代详尽的文档,强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法,这里有很多的东西是未知的,知识只存在于两个地方:开发者的头脑和最后的代码。对于项目管理者来说,他们会认为敏捷开发方法弱化了知识管理的概念,而实际上敏捷开发注重的是最有价值的知识的积累和沉淀。
如何灵活应对各种项目风险、如何最大化优先满足用户价值、又如何能够有效的控制项目开发过程、如果做好项目过程中的知识管理,是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调RUP裁剪,实际上我认为RUP不仅仅是需要自身的裁剪,还需要学会融合。在RUP裁剪的同时,适宜的融合敏捷开发的各种实践。不要认为RUP与XP是矛盾的,其实不然,它们具有不同的原理、具有不同的应用领域。在 RUP 中融合了 XP 技术时,才会得到过程的正确量,既满足了项目所有成员的需要,又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队,其中用户是团队的一部分,那么 XP 完全可以胜任。对于团队越来越分散,代码量越来越大,或者构架没有很好定义的情况,您需要做一些其他工作。在用户交互具有"契约"风格的项目中,仅有 XP 是不够的。RUP 是一个框架,可以从 RUP 出发,在必要时以一组更健壮的技术来扩展 XP。
RUP最佳实践包括:
1. 迭代开发: RUP的开发过程建立在一系列迭代之上,每次迭代都有一个固定的时间限制(例如四个星期),称为"时间盒",每次迭代结束的时候都发布一个稳定的小版本,该版本是最终系统的子集。"时间盒"是迭代开发中的关键概念:它意味着迭代周期的期限是固定的,如果目标没有完成,则放弃本次迭代的需求,而不是延长迭代的时间。
2. 管理需求
3. 使用基于组件的构架
4. 可视建模
5. 持续的质量验证
6. 控制变更
关于RUP阶段的一个简洁和准确的描述:
1.初始-开发系统的业务用例;要求探索少量但是重要的需求(大约10%),以便获得范围、关键风险的尺度,并且决定是否进入细化阶段。
2.细化-迭代地构建核心体系结构和解决技术风险。构建体系结构意味着真正的编程、集成及测试-这不是纸上谈兵或者丢弃原型。细化阶段,我们需要迭代地详细地探索大部分需求(大约80%),同时实现系统的核心风险部分。在整个细化阶段需求都可能是变化的,通过不断的"反馈-适应"循环,评估已实现的部分。
可以看到,这与传统的瀑布风格的需求定义不同,其大部分需求是在开发核心体系结构的同时细化得到的,并且其从实际的开发中得到反馈。我们也能够以此为据来决定是否继续此项目。
3.构造-迭代地构建细化阶段没有做的元素;迭代地集成和进行质量保证;准备部署。由于大部分需求的不稳定性已经在细化阶段澄清,所以在构造阶段需求的变化较少。
4. 发布-完成&beta测试,确定版本,部署系统。RUP规则推荐"迭代周期的长度是2-6周"。 迭代开发和RUP的本质是采取小步骤,对于可能不完美的实现,迅速集成,质量保证,测试,及时获得反馈,然后根据反馈,调整需求、设计和实现。小步骤、反馈和调整是核心概念。
迭代方法允许我们边学边走;随着迭代的进行,我们得到越来越多的真实的需求,更加客观的风险,以及完成该项目的更加准确的能力估计。简言之,经验使我们成为更好的计划者。
12 个 XP 实践包括:
有计划的开发:通过结合使用优先级"故事"和技术估算,确定下一版本的功能
小版本:以小的增量版本经常向客户发布软件
隐喻:隐喻是一个简单、共享的"故事"或描述,说明系统如何工作
简单设计:通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除
测试驱动开发:用户编写测试内容以对"故事"进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容
重构:这是一项简化技术,用来移除代码中的重复内容和复杂之处
结对编程:团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动,另一个人同时审查代码的正确性和可理解性
集体代码所有权:任何人都拥有所有的代码。这就意味这每个人都可以在任何时候变更任何代码
持续集成:每天多次创建和集成系统,只要任何实现任务完成就要进行
每周 40 个小时:程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的
现场客户:一名真实的客户全时工作于开发环境中,帮助定义系统、编写测试内容并回答问题
编码标准:程序员采用一致的编码标准证
RUP与XP的融合,是各自特点的相互补充,也是软件开发方法的平衡之道。而对软件技术平衡的思考也可以说是技术成熟的开始吧。
最后,再阐明我对软件项目开发的理解。在软件项目开发过程中,应该能够识别、分析不同软件项目的特点,采用相对适合的开发实践来适应软件开发过程,保证对软件开发的有效支持,以便能够创造出&ldquo足够好的&rdquo软件。而这个足够就是对进度、成本、质量之间的平衡,最大化满足客户需要的实现。 -
CMMI 5能创造些什么 看富士通的软件过程改善历
2008-2-28
眼下,CMM似乎正褪去曾经笼照在它身上的神圣的光环。就连UML之父Ivar Jacobson博士游历中国之时,也不忘提醒他的中国同行:谨防掉入CMM陷阱。从这个角度看,富士通南大软件技术有限公司(FNST)正式通过软件行业内最高级别CMMI 5认证,似乎并不是一件值得关注的事情。但如果我们把历史翻回到二战刚刚结束之时的日本,我们一定会对这样一个事实表示惊异:二战结束初期,日本在工业基础极为低下的条件下,仅仅用了四年时间,就把曾是劣质产品代名词的日本产品,打造成了把美国同类产品打得在地上翻滚挣扎的生力军。造就这个奇迹的只有两个字——品质。
因此,如果我们还原CMMI的本来面目,把它当作是提高品质的有力手段时,FNST的CMMI 5认证之路就有理由值得我们关注了。而如果我们进一步反思日后这场竞争中美国产品重机关报崛起的原因,就不难发现美国绝地反击的法宝——态度。美国人不仅重新认识了造就日本产品奇迹的戴明博士,而且将品质管理上升到了经营管理的最高层次。基于对这种态度所起的作用的认识,我们就更应该下番功夫去研究一下FNST的CMMI 5认证之路了。
品质无泪
提起富士通公司,中国国内几乎到了无人不晓的地步,但提起它的软件业务,却没有几个人能说得清,通过富士通南大软件技术有限公司总经理北冈正治的介绍,我们了解到这源于富士通公司在中国国内的分公司众多。
北冈先生介绍说:“富士通是全球第三大IT及服务公司、全球前五大服务器和PC机生产商、世界第二大企业用硬盘驱动器的制造商和第四大移动硬盘制造商。三十年来,富士通在中国共设立了38家公司;其中,富士通直接投资的与软件开发相关的公司就有四家。FNST是唯一一家面向服务器基础软件的研发机构,主要业务涉及Linux服务器平台、服务器中间件、服务器硬件验证、嵌入式软件和系统应用软件。”从这简单的几句话中我们不难看出南大富士通公司的技术开发难度有多高。无论是围绕服务器平台的整体的软件开发,还是底层的硬件测试与验证,再到存储/网络/CPU的管理与服务器中间件和应用系统,所涉及的技术都非常基础。由此我们也不难想见,在这样一家需要建立高水平的开发团队才能应对的软件企业实施CMMI,确实不是一件容易的事情。
谈起选择CMMI的原因,FNSTCMMI过程改善委员会执行主席蔡志旻先生这样介绍道:“与CMMI类似的模型还有很多,而FNST之所以最终选择了CMM/CMMI模型,是站在提高软件开发品质、成为一流软件企业、提高顾客满意度的角度上综合考虑的。”
事实上,FNST自1999年成立之初就导入了富士通为了提高软件产品的开发能力和产品质量,日本富士通株式会社长期积累而形成的一套行之有效的方法和技术使得FNST是在一个高标准的基础上实施CMM认证的。从2002年下半年开始导入CMM模型进行品质改善和过程改善,一年以后FNST就通过了“软件过程成熟度(CMM3级)论证”,并获得证书。
FNST取得了一个良好的开端,这意味着已经取得了成功的一半。这个良好开端还表现在FNST在CMM认证之初,就采取了一些正确的做法。
CMM/CMMI模型只是给出了为了进行过程改善,"要做什么",而需要组织把抽象的CMMI概念和目标具体化。在这个过程中,FNST没有让过于偏向理论论述的国内咨询公司参与进来,而是自己选择了“What to Do(CMMI书籍)=》Why to Do(软件工程典籍)=》How to Do(建立公司规范)=》Do it!”这样一条改进之路。真正做到让开发人员理解蕴涵再CMMI相关PA(Practice Area)规定之后的软件工业界三十年来的经验之精髓然后再在实际工作中运用这些经验方法。
要达到品质无泪的境界,全员参与是必不可少的一个环节。值得一提的是,富士通是一家有着追求优异品质传统的公司。富士通品质保证本部长木村弘正这样介绍说:“出于让各分公司都要按照同样优秀的标准提供高品质产品的需求,富士通公司很早就成立了品质保证部。富士通公司内部有一个共识,这就是一个细节上的小失误,也会带来很大的问题。富士通公司的产品线很长,涵盖了软、硬件的各个方面,在软件开发过程中,确实不存在能完美解决所有问题的银弹,但从上而下的帮助可以让各个公共司都按照正确的流程来办事,而细节则由他们自己把握。”就细节问题,FNST技术管理课SQA(品质保证)主任王毅峰介绍说:“FNST实施过程改善,是应开发人员之需,而并非是管理层单方面的意志决定一切的。这避免了常见的过程改善误区:规范的制订者并不是规范的实际执行者;开发者无法从过程改善中受益。”
尽管有了一个好的开端,但FNST的高层领导并不敢松懈,2003年的顾客满意度调查数据表明,2003年8月的顾客满意度得分在满分100分的条件下,FNST的得分只有43.02。蔡志旻先生对这个成绩做了注解:“这表明用户用不用你的产品要依他们的心情而定,还远没有达到离不开你的境界。”
合于术数
中国人爱把成功的步骤归纳为修身、齐家、治国、平天下,而修身的要旨则可归纳为“法于阴阳,合于术数”,这种思想恰好也和CMMI 4级认证的定量管理不谋而合。在从已定义的三级向已管理的四级的转化过程中,对软件开发实施定量管理,对于整个世界软件业界而言都是个具有挑战性的课题,原因就在于软件开发的不可重复性。但对FNST,这却又是一个必须要迈过去的坎。
对这个问题,蔡志旻先生道出了其中的秘密:“与传统制造业相比,软件开发的定量数据的精确性要低很多。其次,数据的收集是件极其耗费时间的工作,而且容易出错。最后,软件开发的数据不能用于评判开发人员的工作。针对这三个难题,我们开发了SPIF(Software Process Integrated Framework)可视化项目管理辅助平台,实现数据的一次录入和处处使用,抓住品质,规模和生产率,日程三个对象实施定量管理,明确定量管理的意义,明确数据判断和分析的方法,特别是如何根据数据来把握开发状况,运用数据来调整下一步的开发活动。”
2004年12月,FNST通过了CMM4级认证,成为南京地区首家通过此认证的软件企业。难能可贵的是,FNST此时并没有把自己的经验作为独门武功珍藏起来,而是利用SPIF工具去帮助其他软件企业。包括江苏金智软件、苏州方舟公司等国内公司,都曾受益于SPIF工具及FNST积累的经验,并与移软公司,金鹰公司,趋势公司等进行了广泛的交流。而此时FNST的客户满意度得分也已提高到了60.60。然而,此时的FNST的业务百分之百地来自于富士通集团本部,面对来自印度等地区关联公司的竞争,FNST并没有让提高品质的工作就此止步。
问题背后的问题
富士通公司在给一家欧洲大型航空公司的订票呼叫中心实施IT整体解决方案时,富士通支持人员发现新业务流程实施之后,呼叫中心接到了很多的电话投诉。富士通支持人员并没有通过“简单地培训服务中心接待人员技能、增加接待人员数量”等表面措施来缓解这个现象,而是通过将电话投诉的内容进行详细的分类和分析,发现大多数投诉的内容集中在“电子机票无法打印”的问题上。再深入分析下去,了解到问题的根源在于印刷票据的打印机出现故障。于是在富士通支持人员的建议下更换了打印设备,大幅度地提高了机票打印的可靠性和效率。在很短的时间内,就使服务中心同期内接到的电话投诉量下降了80%。
对此案例,CMMI过程改善委员会成员王晶先生介绍,当某件事情的执行过程中出现问题的时候,如果只是简单的“头痛医头、脚痛医脚”,采取治标不治本的措施来消除问题的表象,那么会出现类似问题的隐患仍然可能在将来爆发。在问题发生时,为了采取改善措施来消除问题产生的根源以避免今后同样发生,我们必须连问几个“为什么”,以找到导致问题出现的根本原因并消除它,即解决“问题背后的问题”。这种方法称之为“根本原因分析法。”
在FNST,根本原因分析法甚至从2002年就开始在各个项目组得到应用。在面向CMM 4尤其是面向CMMI 5的改善活动,FNST重点在解决“处理交货后产生的质量缺陷”以及“分析客户满意度调查反馈的客户最不满点”的问题上,充分地使用了“根本原因分析法”,在找到问题的根本原因所在后,将改善方法应用到在后续开发环节中,尽可能提前监测到类似缺陷来避免问题的再次发生。较大程度地改善了产品的品质,提高了顾客满意度评价
2006年4月13日,FNST正式通过了CMMI Level 5的审查,成为江苏省内注册的首家通过该级别认证的的外资企业。而此时的顾客满意度得分,也预计将在2005年4月的72.67分的基础上提高于80分。另一个指标更明显地反映出了CMMI给FNST带来的变化:以PGRelief产品为例,在与FNST成立不久的2000年,产品交付后每千行程序的缺陷率相比,2003年通过CMM3时下降为92%,2004年通过CMM4后下降为35%,到实施CMMI5的2005年底则下降为2000年缺陷率的9%。软件产品不能按照交付的现象也已得到了根本杜绝。
快乐工作,共享成长
按照挖掘“问题背后的问题”这一思路去分析,问题也就不可能不出现。蔡志旻先生显然认同这一观点,他说:“通过了CMMI 5并不是公司提高品质的终点,FNST的新目标是在原先“人人参与,日日改善”的基础上,提出了“快乐工作,共享成长”的新口号,在2009年公司成立十周年之际,成为世界一流的软件开发公司。以产品交付后缺陷率这一指标来说,我们要达到富士通本部的世界先进水平。”
在采访过程中,北冈先生经常需要闭目休息一会儿,由此可见喜欢在业余时间练二胡的他为提高品质的活动付出了多大的心力,再看到蔡志旻、王晶、王毅峰等人匆忙的背影,我们不难想见FNST把品质摆在了一个什么样的地位上。然而,现在非常多的CEO在品质和利润发生冲突时,会毫不迟疑地选择后者。关于这二者的差异,被誉为是“美国最著名的质量管理家”的克劳士比曾做过这样的注解:未来10年,将有更多的产品及公司会因缺乏质量管理而不是因财源短缺而彻底失败。那些醒得早的人,即可掌握市场;那些迟疑过久的人,只能为人作嫁家。克劳士比的话同样道出了CMMI5的真正价值所在,也许我们这个时候更想看到CMMI5在接下来的时间里,为富士通南大软件技术有限公司创造的价值究竟会达到一个什么样的数字。 -
转行晋升,准备好了吗?
2008-1-23
现代社会,“跳槽”已经成为时尚,“转行”也日趋流行。“跳槽”与“转行”逐渐地被看成是个人能力高、社会网络广、挑战意识强、身份地位上升的标志。与“跳槽”相比,“转行”意味着跨越不同的专业领域,掌握不同的职业技能,乃至要求完全不同的思维方式。
一般而言,转行包括两种情况,如果所转的行业与原来从事的工作有某种程度的关联性,则可视之为小转行;如果转到风马牛不相及的一个全新行业,那就是大转行。小转行也好,大转行也罢,凡是转变就存在风险。独之秀职业顾问认为,若要确保转行成功的最大可能性,分析转行成功人士的经历,总结成功的经验是必不可少的。
一、剖析自我——认清自己的优势和不足
无论做任何事,自我认知都是确保成功的重要因素。假如对自身的强项弱项都不清楚,也不知道自己的职业竞争力在何处,那么职业人在选择工作和转行时,只能是盲目跟风或者跟着感觉走,让感觉主宰自己的职业前途。这些优势是否足以帮助我在新的行业站稳脚跟?我的弱点在哪里?有什么方法可以尽快提升?
职业在自我剖析的过程中,除了要对自身个性、能力、价值取向等方面进行分析外,还要对以前职业的含金量做准确评估,因为这决定了你职业发展下一步的合适位置在何处。
二、找准职业方向
职业人转行大多数是因为之前的找工作的时候没有找准职业定方和发展方向,才会出现现在要转行的情况。找准职业定位是避免盲目转行最重要的一条。要先行挖掘自己的职业气质、职业兴趣、职业能力结构等方面的因素,找到自己的职业潜力集中在哪个领域,只有找准方向才能最大限度地开发和发掘自己的潜力。同时,职业人也要考虑新职业能给你带来多大的发展前景。
三、分析目标行业的现状及发展趋势
行业环境与行业整体气候与个人的发展息息相关。转行前,职业人要主动、全方位地了解目标行业现状和前景。朝阳行业一般都比较有前景,包含很多的机遇与挑战,但同时这也说明,朝阳行业发展的不成熟与不健全,欲进入这些行业的职业人必须做足各方面的准备。相对成熟的行业,发展相对平稳。夕阳行业,就不必考虑了。
俗话说隔行如隔山,不能仅仅靠报纸或者杂志介绍,比较理想的做法是向目前已在该行业供职的朋友打听,以便获得可靠消息,打听的内容包括升迁制度、薪资状况等各个方面,多多益善,或者请专家为您做相应的分析。
四、找到最佳的转型切入点
确定要转行之后,还要找到一个切入点,这是决定你能否走稳走对转行第一步的关键。选择切入点其实就是选择企业和岗位。在综合分析了自身的优势劣势以及目标行业的状况之后,确定自己适合在什么样规模、什么样性质、类型的企业发展。以自身的能力来看,选择什么样的岗位是最合适的等。找准切入点不是件容易的事情,这需要你对新行业的知识与技能有足够的准备,对企业的用人制度、招聘流程、岗位要求等都了然于心,利用身边的一切资源。
五、果断行动
年龄越大,在原有领域走得越远,转行的难度也就越大。一旦确定了必须转行,那就不要再犹豫,因为等待、观望的时间越长,付出的代价也就越大。这个时候,独之秀职业顾问建议不妨可以换个角度思考问题,把这一切都看作是投资,你并不是在换工作,而是在对一新领域进行投资,捷足先登者自然收益越大。
六、卧薪尝胆——适应期避免患得患失
患得患失得不偿失。独之秀职业顾问认为,转行不同于跳槽,跳槽可以为新企业在短时间内创造价值,而转行的人往往需要一段的适应期,卧薪尝胆,而缺少耐心、没有放平心态会使许多转行者半途而废。
在进入一个全新的领域后,每个人都会出现“环境适应综合症”,因为除了自己周围攻的一切都是新的,而自己不能改变什么,只能改变自己以适应环境和工作。这段过渡期对于转行的人来说也是异常难熬的。尤其是对于“大转行”的人而言,转行就像另选树干,有一个退下来的过程,在这一过程中,收入的减少和职位的降低在所难免,但只要方向正确,这一现象只是暂时的,超越旧有职位与薪水也只是时间问题。反之,如果半途而废,其代价也是惨痛的,即使想要再转回原行业,是否还有空缺或获得原来的报酬和地位就很难讲了。(完) -
跳槽:莫撞法律红灯
2008-1-20
《劳动合同法》已经实施,跳槽者当掌握相关法律,履行个人义务,方能不撞法律红灯,确保跳槽无忧。
红灯一未提前通知即炒老板鱿鱼
辞职是劳动者的权利,但辞职不等于可以随意走人。根据《劳动合同法》的规定,劳动者辞职途径有三:其一是与用人单位协商一致,解除劳动合同;其二是提前30日以书面形式通知用人单位,或者在试用期内提前3日通知用人单位,解除劳动合同;其三是在用人单位未履行法定义务,如未按照劳动合同约定提供劳动保护或者劳动条件、未依法为劳动者缴纳社会保险费时,随时解除合同。
劳动者解除劳动合同,无需说明理由,与用人单位解除劳动合同相比,劳动者解除劳动合同的权利受到法律的特殊保护。但是,特殊保护不等于毫无约束,在未与用人单位协商一致,且用人单位又没有违背《劳动合同法》规定义务的情况下,劳动者应当提前30日以书面形式通知用人单位,方可解除劳动合同。如果劳动者未提前通知即炒了老板的鱿鱼,即属违约,违约则当承担相应的违约责任,白白地掏一笔“辞职费”。
红灯二未炒老东家即签约新东家
除了非全日制用工外,劳动者不能建立多重劳动关系。职场中,劳动者在寻求到新东家,做好跳槽准备后,往往面临两难选择:如果先与老东家解除劳动合同,则担心新东家临时变卦,拒绝录用,或不兑现诺言,打压工资待遇;如果未与老东家解除劳动合同,则难以与新东家直接签订劳动合同,即便签了也可能因身兼二职,分身乏术,未能完成老东家或新东家的工作任务,而承担相应的违约责任。
先炒老东家,有待业风险;不炒老东家,有法律风险。在待业风险和法律风险间,不少劳动者选择后者,虽然规避了待业风险,但因脚踏两条船,与不同用人单位建立了双重劳动关系,也往往承担了相应的法律责任。
跳槽时,能否既规避待业风险又避免法律风险呢?回答是肯定的。一般来说,从洽谈新东家到办理离职手续,再到与新东家签订劳动合同,常常需要一两个月甚至更长时间。其间,为防止新东家出尔反尔,劳动者可与新东家先签一份“录用协议书”,明确劳动者与原单位依法解除劳动关系后,用人单位将录用该劳动者,并对工资报酬、工作岗位、违约责任等予以约定。待双方正式签订劳动合同时,再依据该协议约定的要件签订劳动合同。如此,万一新东家违约,跳槽者可搬出协议,请求法律支持。
红灯三提前解约却拒付培训费用
法律赋予了劳动者辞职的权利,一般情况下,劳动者提前解除劳动合同无须支付违约金,但在特定情形下,劳动者提前解约应当向用人单位支付违约金。《劳动合同法》第22条规定:“用人单位为劳动者提供专项培训费用,对其进行专业技术培训的,可以与该劳动者订立协议,约定服务期。劳动者违反服务期约定的,应当按照约定向用人单位支付违约金。违约金的数额不得超过用人单位提供的培训费用。用人单位要求劳动者支付的违约金不得超过服务期尚未履行部分所应分摊的培训费用。”
根据前述规定,对于约定服务期的劳动合同,如果劳动者提前解约,应当支付违约金,而违约金数额的多少取决于服务期尚未履行部分所应分摊的培训费用。需要特别提醒的是,用人单位并不能随意约定服务期。只有劳动者享受了用人单位的培训费用,用人单位才可以在劳动合同中约定服务期,进而约定劳动者提前解约应向用人单位支付违约金。
跳槽时,如果劳动合同中约定了服务期,而该约定又合法有效,劳动者应当恪守诚信,主动支付违约金,因为即便拒付培训费用,也可能落个输了官司又赔钱的后果。当然,劳动者也要睁大自己的“慧眼”,要看清劳动合同中是否约定了服务期,是否约定了违约金,更要看清自己是否享受了用人单位的特殊待遇,切莫稀里糊涂地向用人单位支付“莫须有”的违约金,带来不必要的损失。
红灯四解除合同却忘记保密义务
劳动合同解除后,对于掌握商业秘密的劳动者,还可能在一定时期内负有保密义务。《劳动合同法》第23条规定:“用人单位与劳动者可以在劳动合同中约定保守用人单位的商业秘密和与知识产权相关的保密事项。对负有保密义务的劳动者,用人单位可以在劳动合同或者保密协议中与劳动者约定竞业限制条款,并约定在解除或者终止劳动合同后,在竞业限制期限内按月给予劳动者经济补偿。劳动者违反竞业限制约定的,应当按照约定向用人单位支付违约金。”
劳动合同解除后,负有保密义务的劳动者应当依据劳动合同,自觉接受竞业限制。职场中,有不少劳动者或者因为无知,或者受利益诱惑,在解除劳动合同后,忘却自己的保密义务,在给原用人单位带来损失的同时,也将自己推上了被告席,甚至赔上了高额违约金。
跳槽后,劳动者应当诚信履行保密义务,切莫为了新东家的蝇头小利而违反竞业限制,给自己带来巨大的经济风险。当然,跳槽者也要把握好竞业限制人员的范围和竞业限制的期限。根据《劳动合同法》的规定,竞业限制的人员限于用人单位的高级管理人员、高级技术人员和其他负有保密义务的人员,竞业限制的期限最长不得超过二年。劳动者如果不属于竞业限制人员,即便劳动合同中有竞业限制的约定,也当主张约定无效;劳动者更要牢记竞业限制的期限,在竞业限制期限到期时,如期跳出竞业限制。 -
HTTP错误大全
2008-1-17
HTTP错误大全
HTTP 400 - 请求无效
HTTP 401.1 - 未授权:登录失败
HTTP 401.2 - 未授权:服务器配置问题导致登录失败
HTTP 401.3 - ACL 禁止访问资源
HTTP 401.4 - 未授权:授权被筛选器拒绝
HTTP 401.5 - 未授权:ISAPI 或 CGI 授权失败
HTTP 403 - 禁止访问
HTTP 403 - 对 Internet 服务管理器 的访问仅限于 Localhost
HTTP 403.1 禁止访问:禁止可执行访问
HTTP 403.2 - 禁止访问:禁止读访问
HTTP 403.3 - 禁止访问:禁止写访问
HTTP 403.4 - 禁止访问:要求 SSL
HTTP 403.5 - 禁止访问:要求 SSL 128
HTTP 403.6 - 禁止访问:IP 地址被拒绝
HTTP 403.7 - 禁止访问:要求客户证书
HTTP 403.8 - 禁止访问:禁止站点访问
HTTP 403.9 - 禁止访问:连接的用户过多
HTTP 403.10 - 禁止访问:配置无效
HTTP 403.11 - 禁止访问:密码更改
HTTP 403.12 - 禁止访问:映射器拒绝访问
HTTP 403.13 - 禁止访问:客户证书已被吊销
HTTP 403.15 - 禁止访问:客户访问许可过多
HTTP 403.16 - 禁止访问:客户证书不可信或者无效
HTTP 403.17 - 禁止访问:客户证书已经到期或者尚未生效 HTTP 404.1 -
无法找到 Web 站点
HTTP 404- 无法找到文件
HTTP 405 - 资源被禁止
HTTP 406 - 无法接受
HTTP 407 - 要求代理身份验证
HTTP 410 - 永远不可用
HTTP 412 - 先决条件失败
HTTP 414 - 请求 - URI 太长
HTTP 500 - 内部服务器错误
HTTP 500.100 - 内部服务器错误 - ASP 错误
HTTP 500-11 服务器关闭
HTTP 500-12 应用程序重新启动
HTTP 500-13 - 服务器太忙
HTTP 500-14 - 应用程序无效
HTTP 500-15 - 不允许请求 global.asa
Error 501 - 未实现
HTTP 502 - 网关错误
用户试图通过 HTTP 或文件传输协议 (FTP) 访问一台正在运行 Internet 信息服务 (IIS) 的服务器上的内容时,IIS 返回一个表示该请求的状态的数字代码。该状态代码记录在
IIS 日志中,同时也可能在 Web 浏览器或 FTP 客户端显示。状态代码可以指明具体请求是否已成功,还可以揭示请求失败的确切原因。
日志文件的位置
在默认状态下,IIS 把它的日志文件放在 %WINDIRSystem32Logfiles 文件夹中。每个万维网 (WWW) 站点和 FTP 站点在该目录下都有一个单独的目录。在默认状态下,每天都会在
这些目录下创建日志文件,并用日期给日志文件命名(例如,exYYMMDD.log)。
HTTP
1xx - 信息提示
这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个 1xx 响应。 • 100 - 继续。
• 101 - 切换协议。
2xx - 成功
这类状态代码表明服务器成功地接受了客户端请求。 • 200 - 确定。客户端请求已成功。
• 201 - 已创建。
• 202 - 已接受。
• 203 - 非权威性信息。
• 204 - 无内容。
• 205 - 重置内容。
• 206 - 部分内容。
3xx - 重定向
客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请求服务器上的不同的页面,或通过代理服务器重复该请求。 • 302 - 对象已移动。
• 304 - 未修改。
• 307 - 临时重定向。
4xx - 客户端错误
发生错误,客户端似乎有问题。例如,客户端请求不存在的页面,客户端未提供有效的身份验证信息。 • 400 - 错误的请求。
• 401 - 访问被拒绝。IIS 定义了许多不同的 401 错误,它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示,但不在 IIS 日志中显示: • 401.1 - 登录失败。
• 401.2 - 服务器配置导致登录失败。
• 401.3 - 由于 ACL 对资源的限制而未获得授权。
• 401.4 - 筛选器授权失败。
• 401.5 - ISAPI/CGI 应用程序授权失败。
• 401.7 – 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
• 403 - 禁止访问:IIS 定义了许多不同的 403 错误,它们指明更为具体的错误原因: • 403.1 - 执行访问被禁止。
• 403.2 - 读访问被禁止。
• 403.3 - 写访问被禁止。
• 403.4 - 要求 SSL。
• 403.5 - 要求 SSL 128。
• 403.6 - IP 地址被拒绝。
• 403.7 - 要求客户端证书。
• 403.8 - 站点访问被拒绝。
• 403.9 - 用户数过多。
• 403.10 - 配置无效。
• 403.11 - 密码更改。
• 403.12 - 拒绝访问映射表。
• 403.13 - 客户端证书被吊销。
• 403.14 - 拒绝目录列表。
• 403.15 - 超出客户端访问许可。
• 403.16 - 客户端证书不受信任或无效。
• 403.17 - 客户端证书已过期或尚未生效。
• 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
• 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
• 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
• 404 - 未找到。 • 404.0 -(无) – 没有找到文件或目录。
• 404.1 - 无法在所请求的端口上访问 Web 站点。
• 404.2 - Web 服务扩展锁定策略阻止本请求。
• 404.3 - MIME 映射策略阻止本请求。
• 405 - 用来访问本页面的 HTTP 谓词不被允许(方法不被允许)
• 406 - 客户端浏览器不接受所请求页面的 MIME 类型。
• 407 - 要求进行代理身份验证。
• 412 - 前提条件失败。
• 413 – 请求实体太大。
• 414 - 请求 URI 太长。
• 415 – 不支持的媒体类型。
• 416 – 所请求的范围无法满足。
• 417 – 执行失败。
• 423 – 锁定的错误。
5xx - 服务器错误
服务器由于遇到错误而不能完成该请求。 • 500 - 内部服务器错误。 • 500.12 - 应用程序正忙于在 Web 服务器上重新启动。
• 500.13 - Web 服务器太忙。
• 500.15 - 不允许直接请求 Global.asa。
• 500.16 – UNC 授权凭据不正确。这个错误代码为 IIS 6.0 所专用。
• 500.18 – URL 授权存储不能打开。这个错误代码为 IIS 6.0 所专用。
• 500.100 - 内部 ASP 错误。
• 501 - 页眉值指定了未实现的配置。
• 502 - Web 服务器用作网关或代理服务器时收到了无效响应。 • 502.1 - CGI 应用程序超时。
• 502.2 - CGI 应用程序出错。application.
• 503 - 服务不可用。这个错误代码为 IIS 6.0 所专用。
• 504 - 网关超时。
• 505 - HTTP 版本不受支持。
常见的 HTTP 状态代码及其原因
• 200 - 成功。 此状态代码表示 IIS 已成功处理请求。
• 304 - 未修改。 客户端请求的文档已在其缓存中,文档自缓存以来尚未被修改过。客户端使用文档的缓存副本,而不从服务器下载文档。
• 401.1 - 登录失败。 登录尝试不成功,可能因为用户名或密码无效。
• 401.3 - 由于 ACL 对资源的限制而未获得授权。 这表示存在 NTFS 权限问题。即使您对试图访问的文件具备相应的权限,也可能发生此错误。例如,如果 IUSR 帐户无权访问
C:WinntSystem32Inetsrv 目录,您会看到这个错误。 有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章:
187506 INFO: IIS 4.0 的基础 NTFS 权限
• 403.1 - 执行访问被禁止。 下面是导致此错误信息的两个常见原因: • 您没有足够的执行许可。例如,如果试图访问的 ASP 页所在的目录权限设为“无”,或者,试图执行的
CGI 脚本所在的目录权限为“只允许脚本”,将出现此错误信息。若要修改执行权限,请在 Microsoft 管理控制台 (MMC) 中右击目录,然后依次单击属性和目录选项卡,确保为
试图访问的内容设置适当的执行权限。
• 您没有将试图执行的文件类型的脚本映射设置为识别所使用的谓词(例如,GET 或 POST)。若要验证这一点,请在 MMC 中右击目录,依次单击属性、目录选项卡和配置,然后
验证相应文件类型的脚本映射是否设置为允许所使用的谓词。
• 403.2 - 读访问被禁止。验证是否已将 IIS 设置为允许对目录进行读访问。另外,如果您正在使用默认文件,请验证该文件是否存在。 有关如何解决此问题的其他信息,请单
击下面的文章编号,查看 Microsoft 知识库中相应的文章:
247677 错误信息:403.2 Forbidden:Read Access Forbidden(403.2 禁止访问:读访问被禁止)
• 403.3 - 写访问被禁止。 验证 IIS 权限和 NTFS 权限是否已设置以便向该目录授予写访问权。有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识
库中相应的文章:
248072 错误信息:403.3 Forbidden:Write Access Forbidden(403.3 禁止访问:写访问被禁止)
• 403.4 - 要求 SSL。禁用要求安全通道选项,或使用 HTTPS 代替 HTTP 来访问该页面。如果没有安装证书的 Web 站点出现此错误,请单击下面的文章编号,查看 Microsoft 知
识库中相应的文章:
224389 错误信息:HTTP 错误 403、403.4、403.5 禁止访问:要求 SSL
• 403.5 - 要求 SSL 128。禁用要求 128 位加密选项,或使用支持 128 位加密的浏览器以查看该页面。如果没有安装证书的 Web 站点出现此错误,请单击下面的文章编号,查看
Microsoft 知识库中相应的文章:
224389 错误信息:HTTP 错误 403、403.4、403.5 禁止访问:要求 SSL
• 403.6 - IP 地址被拒绝。您已把您的服务器配置为拒绝访问您目前的 IP 地址。 有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文
章:
248043 错误信息:403.6 - Forbidden:IP Address Rejected(403.6 - 不可用:IP 地址被拒绝)
• 403.7 - 要求客户端证书。您已把您的服务器配置为要求客户端身份验证证书,但您未安装有效的客户端证书。 有关其他信息,请单击下面的文章编号,查看 Microsoft 知识
库中相应的文章:
190004 错误 403.7 或“Connection to Server Could Not Be Established”(无法建立与服务器的连接)
186812 PRB:错误信息:403.7 Forbidden:Client Certificate Required(403.7 禁止访问:要求客户端证书)
• 403.8 - 站点访问被拒绝。您已为您用来访问服务器的域设置了域名限制。有关如何解决此问题的其他信息,请单击下面的文章编号,查看 Microsoft 知识库中相应的文章:
248032 错误信息:Forbidden:Site Access Denied 403.8(禁止访问:站点访问被拒绝 403.8)
• 403.9 - 用户数过多。与该服务器连接的用户数量超过了您设置的连接限制。 有关如何更改此限制的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文
章:
248074 错误信息:Access Forbidden:Too Many Users Are Connected 403.9(禁止访问:连接的用户太多 403.9)
注意:Microsoft Windows 2000 Professional 和 Microsoft Windows XP Professional 自动设置了在 IIS 上最多 10 个连接的限制。您无法更改此限制。
• 403.12 - 拒绝访问映射表。 您要访问的页面要求提供客户端证书,但映射到您的客户端证书的用户 ID 已被拒绝访问该文件。 有关其他信息,请单击下面的文章编号,以查看
Microsoft 知识库中相应的文章:
248075 错误信息:HTTP 403.12 - Access Forbidden:Mapper Denied Access(HTTP 403.12 - 禁止访问:映射表拒绝访问)
• 404 - 未找到。 发生此错误的原因是您试图访问的文件已被移走或删除。如果在安装 URLScan 工具之后,试图访问带有有限扩展名的文件,也会发生此错误。这种情况下,该
请求的日志文件项中将出现“Rejected by URLScan”的字样。
• 500 - 内部服务器错误。 很多服务器端的错误都可能导致该错误信息。事件查看器日志包含更详细的错误原因。此外,您可以禁用友好 HTTP 错误信息以便收到详细的错误说明
。 有关如何禁用友好 HTTP 错误信息的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
294807 如何在服务器端禁用 Internet Explorer 5 的“显示友好 HTTP 错误信息”功能
• 500.12 - 应用程序正在重新启动。 这表示您在 IIS 重新启动应用程序的过程中试图加载 ASP 页。刷新页面后,此信息即会消失。如果刷新页面后,此信息再次出现,可能是
防病毒软件正在扫描 Global.asa 文件。 有关其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
248013 错误信息:HTTP Error 500-12 Application Restarting(HTTP 错误 500-12 应用程序正在重新启动)
• 500-100.ASP - ASP 错误。 如果试图加载的 ASP 页中含有错误代码,将出现此错误信息。若要获得更确切的错误信息,请禁用友好 HTTP 错误信息。默认情况下,只会在默认
Web 站点上启用此错误信息。有关如何在非默认的 Web 站点上看到此错误信息的其他信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
261200 显示 HTTP 500 错误信息,而不显示 500-100.asp 的 ASP 错误信息
• 502 - 网关错误。 如果试图运行的 CGI 脚本不返回有效的 HTTP 标头集,将出现此错误信息。
HTTP错误大全.doc
(2008-01-17 10:22:39, Size: 49 kB, Downloads: 0) -
告诉你真实的韩国及对华情结!
2007-11-17
近年来,韩流滚滚,中国不少媒体也不客观报道,把韩国描绘成为一个继承儒家传统最好的国度,韩国人如何有血性、如何爱国,韩国是如何的俊男美女,恨不得拜倒在韩国的石榴裙下。国内韩流日盛,国内媒体对韩国的报道也非常多,当然几乎都是充满赞颂之词,再加上精美的韩国影视歌曲的轮番轰炸,这让大多数不了解韩国的中国人对韩国产生了相当的好感。
但真正的韩国如何呢?与韩流相对,最近网上出现了不少揭露“真实”韩国的文章,可惜有的年代久远,有些又非常极端,充满个人感情,但他们大部分内容在我看来是比较真实的。我本不想挑起与邻国的矛盾,但国内媒体对韩国的过分吹捧和韩国媒体对中国的极端歪曲实在形成了太鲜明的反差,让我有点看不过去,所以这里结合我和所认识的朋友们在韩国的经历来谈谈我眼中的韩国,希望能去伪存真。文章比较长,请耐心看,然后明眼的看官自行判断。
1. 韩国从建国起对中国的侮辱史
50年转眼一挥间,1945年日本败亡,朝鲜终于又迎来了独立。可惜南北在不同势力的支持下不能统一成立政府。50年代朝鲜战争爆发,38线成了天堑沟壑,中国自然在韩国人眼中成了十恶不赦,阻止“大韩民族”统一的罪魁祸首(在此引用韩国人原话)。
韩国政府成立之后,接连颁发排斥华商的禁令,包括“仓库封锁令”、“外币使用规模限制令”等等,这便是华商受难的开始。接着,自由党和朴正熙政权两次进行“货币改革”,偏爱现金的华商更受到致命性打击,很多华商因此变得一贫如洗。1961年,韩国政府颁布“外国人拥有土地禁止法”,1971年制定“外国人土地取得及其管理法”,规定华人一家只能拥有一间房屋、一家商店,连炸酱面售价也受到严格管制的情况下,华商便成了走投无路的一群。70年代初,原本有12万人口的华商锐减到只剩下2万人。唐人街遍布世界各地(包括日本),唯独韩国没有。“炸酱面”“赤匪”“中国奴”等韩语中专门针对中国人的侮辱性名称也出现了,直至现在我在韩国BBS上还经常看到,频率之高让我非常愤怒。最近惊闻韩国庆祝“韩国炸酱面”诞生100周年,鉴于韩国人试图盗取“活字印刷术发明权”,考证出“西施可能是韩国人”,“孔子可能是韩国人”等等劣迹,我挺怕它们有朝一日说炸酱面也是韩国的发明。这就比较讽刺了,因为当年“炸酱面”是它们对中国人的一种侮辱称谓呢。
2. 韩国的电视节目
我为了提高自己的韩国语水平,每天坚持阅读韩国新闻,刚去韩国时每天都抽出点时间看韩语节目。后来我统计了一下,每天都能看到不少关于中国的消息,当然,几乎都是负面的,如果有说中国好的,那八九不离十最后都要表达这样一个意思,“中国如此发展会对韩国造成威胁”。不仅是新闻,一次在娱乐节目中看到过这样的场面:采访一个刚从中国回来的韩国女艺人,主持人问她中国如何,她笑嘻嘻的把中国批判一番,什么脏呀,烂呀,穷呀之类的,在场的观众也非常受用,台上台下笑成一片。对于很多韩国人来说,嘲笑中国是最能增强它们“民族自豪感”的事情了,于是它们乐于找出中国的各种弱点来嘲笑,新闻媒体也非常愿意配合民众的这种心理,想方设法挖出这些东西来供国民消遣。所以我有时很纳闷,它们的记者怎么能找到这么多反映中国贫穷落后的新闻,如果我是个没去过中国的韩国人,那么百分之百我会觉得中国是个可怕的国家,对中国不可能有一点好感。
3.韩国焚烧中国国旗
有了这样的媒体,这样的教育,韩国人对中国的反感和狂妄自大就很容易理解了。有网络文章说在韩国繁华的明洞街头出现过“中国人谢绝”的条幅,这个我相信,因为我曾经见过照片,而且不止一个中国朋友告诉我在韩国商店遭到营业员歧视的事。别说在韩国,就连在青岛,在北京望京,不也发生过韩国人店谢绝接待中国人的情况吗?04年高句丽历史事件闹得最厉害的时候我恰巧在韩国,我看见过韩国人焚烧中国国旗,在中国大使馆前示威,以至当时我有种想立刻逃离韩国的想法。后来在街上也遇到过不少宣传,讲东北甚至山东古代都是“三韩”的领土,我只能置之不理。
4. 韩国迫切的去中国化
至于剩下的所谓“儒家传统”,只是中国媒体的想当然罢了。韩国人是不会承认的,它们很早以前就开始做的就是割断所谓“韩民族”文化和中华文化的联系,也就是,“去汉化”。汉城改“首尔”的闹剧刚刚过去,这不,几个韩国议员又开始张罗把“汉江”改为“韩江”了。在韩国,“中医”被改名成“韩医”,并被作为高丽医学而拼命向世界宣传推广。针灸也被认为是韩国人发明的,我没看过大长今,不知道里面是不是存在歪曲,但朝鲜日报分明是报道了这个“发现”,并找到了个法国人作证,宣称要纠正世界人民的错误认识,把针灸重新还给韩国。“活字印刷术”也被认为是韩国人先发明,这与中国学者发生了争论,韩国专门建立了印刷术博物馆,把中国在“印刷术”方面的功绩完全抹去,只片面夸大宣传自己,并邀请各国客人免费参观,并经常在国际场合进行宣传。我有幸被邀参观过那个博物馆,我只能承认他们在这方面的确做的非常好,“谎言重复一百遍就成了真理”,韩国人用这种方式“虚构”真理非常在行。
5.韩国对中国的文化剽窃
我在韩国被多次问到:“中国有没有中秋节,中国有没有春节”之类的,不要笑,这其中很多是名牌大学博士,以至于我后来实在厌烦了答他们:“农历是中国人发明的,所有农历节日中国都有。”还有个韩国名校博士一次和我讨论,信誓旦旦的说甲骨文应该是从朝鲜半岛传到中原的,并引用了一些韩国学者的“论据”,遇到这样的事我都懒得争辩了,真希望他在国际学术会上做这个报告,也给西方人看看韩国学者的“风采”。后来我看了篇韩国学者的文章,乖乖,连大禹治水用的“神书”都是朝鲜半岛传过来的,对韩国学者的学术能力我简直找不到语言形容了,惊如天人。要知道韩国直到15世纪才有自己的文字,韩国建国后为了“去汉化”才禁止使用汉字的,它们的学者“参考”的史书几乎都是用汉字写成的中国史书,它们以前还根本没有文字记录的历史呢。
5.你们中国有63层的建筑吗?
我在一个韩国华人论坛上看到一篇文章,讲的是一些在韩国的中国人常常遇到的问题,当时我觉得很有意思,因为和我遇到过的几乎一模一样,看来大家都差不多。在此摘抄转载一下,我就懒得打字了。。。
A 你父母是干什么的? 来韩国的都是中国的有钱人吧!
B 中国有面包么?中国也有方便面吗?中国也有苹果吗?中国也有练歌房(卡拉ok) 么?中国也有台球厅么?中国也过春节呀!中国也有网吧?中国人也用手机吗?
C 这个比较诡异:中国人洗澡么?
为什么会问这个问题呢?因为前几年有一个去过中国的韩国人写了篇文章讲中国人如何不讲究个人卫生,夏天身上散发恶臭,结果被韩国好多网站和报纸都转载了,(我已经说过,韩国媒体是非常喜欢这类文章的,韩国民众也是非常乐意通过这类文章来满足自己“民族自豪感”的),非常出名,大概韩国人对中国人卫生状况不良的印象由此而来。。。
D 针对朝鲜族朋友的,一般会问:“你们是不是都很想来韩国当韩国人呀?你们希不希望从中国独立”之类的问题,说到朝鲜族,感觉韩国人有两个标准,只要是在国际上得了奖或者出了名,那不管是中国朝鲜族还是韩裔美国人,那统统都叫“在外同胞”,要大肆宣传一番;不过要是中国朝鲜族在韩国作奸犯科之类的被抓住了,那媒体首先强调的是那个罪犯是中国人。
E 韩国人在带领人参观的时候很喜欢问:"中国也有这么高的建筑吗?""中国也有地铁吗?转述两个好玩的例子(不是我亲身经历,虽然我也遇到过上述两个问题):
“一次韩国朋友带领我们去汉城市内观光,参观了他们全国最高最自豪的“63大厦"(不太高,就63层),结果问我们:中国也有这么高的建筑吗?我们平时被他的类似问题已经折磨得受不了了,一哥们就说:没有,韩国的这建筑世界第一高。。。那韩国人听了想了想,说:美国有更高的,我们这个大概只是亚洲第一吧。。。”
“还有一次,韩国友人带我们去汉城的一个市内公园玩,大家都知道韩国国小,能在汉城搞出块还不算小的地方种点花草树木就很不得了了,所以就礼节性的赞扬了一下,结果一韩国人自豪的不行,问我们:北京也有这样的市内公园吗?我们一哥们回答:我们有颐和园,比这个大。。。那家伙听了顿时不说话了,他再孤陋寡闻,颐和园的大名还是知道的,最近中国旅游广告比较多。。。”
原文作者最后一段写的很好:
“看了之后有什么感受,是不是很不爽?其实韩国人的这些表现也提醒了我们,现在中国正在变强大,越来越多的外国人来到中国,其中也不乏那些来自相对落后国家的人们,我们在和这些外国人接触的时候会不会也出现韩国人这种“暴发户“心态呢?为了满足自己的虚荣心而提些弱智的问题,虽然别人当场不说,但对中国整个的印象肯定会受到影响。。。所以大家都应该反思一下,有则改之,不要让别人也觉得我们泱泱大中华的国民和韩国人一样小肚鸡肠,狂妄无知。”
6.韩国与中国的领土之争
说到韩国和中国的领土争端,相信不少中国人都要哑然失笑,隔着个海,还有领土争端?正如我在前面已经提到,韩国经过几十年的教育,现在韩国人一致认为,“高句丽”是它们“韩民族”的祖先,“高句丽历史”是韩国历史。04年由于中国的“东北工程”将高句丽史列为中国史一部分曾引发了中韩外交冲突,在媒体的推波助澜下,韩国国内的反华情绪非常高涨。至于真相如何,我这里就不深入讨论了,把工作留给学者,有兴趣的看官可以去查查相关资料。
但那些绑着写有“还我河山”四个鲜红大字布条的韩国人时常会成群结队出现在吉林吉安,延边,或者长白山。我看了朝鲜日报做的调查,居然过半的韩国年轻人赞成“夺回”“满洲(东北)和间岛(吉林延边)”。还是那句话,“谎言重复一百遍就成了真理”,韩国在高句丽问题上已经完成了发动群众的工作,而中国人大概很少有人知道高句丽,说不定还有不少人赞成韩国的观点,却不知道这个争端关系到了东北的归属。
如果高句丽历史争论只是做秀,为将来做准备的话,那么延边和黄海领土争端已经摆在面前。
中国与朝鲜和韩国存在着黄海大陆架的争议。中国主张按自然延伸原则划界(对待日本也是如此,因为我们的大陆架延伸更远),但韩国主张按中间线原则划界。这样,中韩双方便产生了6万平方公里的争议区。具有讽刺意味的是,韩国在黄海上对于中国主张中间线原则,而在东海上对于日本却主张采用自然延伸原则,完全没有原则性,只希望两边都占便宜。1991年5月至8月间,韩国在没有与中国达成协议的情况下,连续在中方黄海水域进行石油钻探活动,遭到强烈抗议。2004年7月,韩国还联合日本,在中国东海中方一侧的大陆架进行石油钻探,也遭到中国的抗议。
此外,中韩两国在东海还有12万平方公里的争议区。中国主张按自然延伸原则与其划界,而韩国则主张按和划分黄海大陆架相同的中间线划分东海大陆架,两线之间便形成了12万平方公里的争议区。1974年1月30日,韩国与日本政府签订东海《共同开发大陆架协定》,开发石油和天然气等。中国政府曾发表声明,指出上述协定是非法的、无效的。
韩国汉城市议会2005年10月24日召开第159次临时会议,制定了所谓的旨在“废除《间岛条约》”的决议案,决议案认为“间岛原是韩国领土”,因中国清朝与日本签约而被“割让”。决议案称,此举从国际法上看“违背当事人的意志”,所以韩国认为中日之间签署的《间岛条约》“根本无效”。又称,国际法认为,即使条约有“不妥之处”,在签定一百年(2009年)之后,通常也被视为有效。因此,决议案认为韩国政府应该为“找回”间岛及时向国际法院提起诉讼。
“间岛”,原名“垦岛”(因大批朝鲜移民越界垦殖而名),系图们江北岸吉林省延边地区和龙县光霁峪前的一处滩地,自古系中国领土。清政府与朝鲜政府曾多次勘定国界,确定该地为中国领土。
后来日本捏造所谓“间岛悬案”,并且恶意歪曲所谓的“间岛”范围,将纵十里、宽一里的滩地,扩大到“海兰河以南、图们江以北,宽约二三百里,长约五六百里之地”,即中国延吉、汪清、和龙、珲春四县地区,妄图一举侵吞这些地方。经过中国官员和学者的多方努力,最终挫败了日本的这一侵略图谋。1909年9月4日中日双方代表在北京签订《中韩界务条款》,即所谓的“间岛协约”。
可以看出,韩国和中国是确实存在领土争端的,但中韩政府目前比较务实,特别是中国现在面临日美的压力,又要和平崛起,所以对以上的争端都做了最低调的处理。韩国政府也不敢造次,所以中韩间至今没有发生什么大的冲突。但韩国媒体向来有煽风点火,制造反华情绪的“光荣传统”,再加上其教育部门的作用,现在几乎所有的韩国人都认为中国“侵占”了它们的领土,其险恶用心不能不察。
7. 韩国人的特性总结
最后总结一下“大韩民族”的特性,在我看来,韩民族和日本民族是最相似的,特别是经过50年日本殖民统治,它们的共同点相当多。
(1),国土狭窄,自然资源贫乏,严重依赖国外市场。日本好歹有30万平方公里的土地,韩国只有不到10万。经济都是外向型,原料基本靠进口,日本历史上强盛时走上了武力扩张之路。
(2),单一民族,排他性非常强,狭隘民族主义盛行。日本右翼分子让中国人愤怒,但韩国更加狭隘极端的民族主义却时常让我冒冷汗,真庆幸它们至今仍然分裂,没有强大的实力。
(3),为了“民族自豪感”,不惜篡改历史。记得有文章说日本人考古作假,让人鄙视。不过后来见了韩国人的“考古”,我倒觉得至少日本人还想着去做假证据,韩国人甚至把这一步都省了,还把成果出来大肆宣传。我不知道日本是不是也搞“去汉化”,但韩国搞得也太离谱了一点。
(4),没有继承到儒家的真髓,形成了自己独特的文化。儒家强调“仁”,这很难和日本帝国主义联系到一起。而韩国的那种社会风气和韩国人的诸多品行也难和“仁”和“礼”联系到一起。所以说它们皮毛和架子是继承了,而且比我们做的还要“儒家”,但真正理解了吗?我看未必。
(5),韩日战后经济发展模式基本一致,当然是韩国照搬日本经验和体制。所以韩国精英们对日本是相当推崇的,几乎达到了言必称日本的地步。至于国内大肆宣扬的“反日”,抱歉,我在韩国还真没感觉出来,身边的韩国人全套日本电器,倒是咱们几个“穷苦”中国人买了比较廉价的韩国产品支援了他们的三星LG。韩国国产车确实满街跑,日本车很少,不过去江南的富人区看看那里lexus也不少,原因很简单,贸易保护嘛,价高老百姓买不起。这里说句题外话,国内的车市,现在奇瑞吉利几个越卖越好,真高兴,这才是咱们的中国企业,不要贸易保护,和合资,外资企业硬碰硬,这样成长起来才有竞争力,我看好中国汽车。
8. 最后:从韩国认清我们的民族之路
韩国人完全可以正确面对历史,从现在开始扎扎实实建立自己的本民族文化。但是,他们不是这样,极力否认中华文化对韩国的影响,其实中国政府和人民从来没有把自己的文化强加给他们。他们这样,是自己的掩耳盗铃,此地无银三百两。
有一次,我对韩国同事说,你们何必呢,中国又没有强加说韩国文化发源于中华汉族,你们极力否认,这不是不打自招吗?
韩国对美国军队驻扎在自己的国土;对韩国的青年作为美国的炮灰派去伊拉克;对历史上曾经受日本的欺负凌辱;对朝鲜半岛的分裂;对曾经是中国的附属国,基本没有自己的本民族文化,感到深深的自卑和屈辱。我在韩国期间,电视报道,一个韩国人在伊拉克被当地民族激进分子作为人质,经过几天,最后被杀害,电视全程报道跟踪了这样一个事件。
恰好后来中国福建的民工也被伊拉克当地民族激进分子作为人质,经过中国政府的斡旋和全力营救,福建民工被安全释放,这件事情,更在韩国人内心激起涟漪,感到自己民族的悲哀和国家的弱小。
所以,综观韩国的历史,我们就不难理解韩国人偏执的爱国情怀,这其中有非常深刻自卑和狭隘心理。
我们要爱国,但是,绝对不是学习韩国这样的态度。
本来,韩国人如果能够庄敬自强,正视本民族的优劣,奋发图强,完全可以取得世人的尊重。
但是,他们选择了另外的思维,阿Q精神,粉饰自己的历史,粉饰自己的文化,粉饰自己的现实生活,在对外输出的文化节目上粉饰和包装,俊男美女。
本来这是一件小事情,但是当一个国家民族,津津乐道,满足于这样的表象;以为依靠几个明星就是横扫中国和亚洲,就是一种畸形现象了。
所以,现在的韩国人,以嘲笑和蔑视中国,来平衡自己的畸形变态心理,以贬低中国证明自己的优越,而这种现象是发生在韩国的主流媒体上,发生在韩国知识精英阶层上,不是发生在一般的平民百姓身上,所以就不得不让我深思。
中国有古语:知耻而后勇,有容乃大。所以有历史上强盛的中国,中华文化容纳、同化了历史上的很多民族,使中国成为一个多元的各民族并存的国家。
我们不要妄自菲薄,走出去看看,你们会发现,今天的中国政府,今天的中国人民,在走一条走向富强的、有尊严的康庄大道。
虽然这条道路不平坦,虽然我们有很多的不足,虽然我们现在的环境还不够清洁,政治不够民主,百姓不够富裕。但是你们可以看看20年前的韩国、台湾和新加坡,他们那时候有什么清洁、民主。
国家的发展需要一个过程,需要我们的自尊自爱,和奋发图强。
今天的中国,正视自己的不足,正在卧薪尝胆,我们为自己是中华民族的一员而自豪。
当然,我们完全木必要刻意地去诋毁或者丑化他们,历史、现实究竟是什么样子,大家都很清楚。贴这篇帖子也并不是想反对韩国什么的,只是让大家对韩国有一个正确的认识。
大家都是理智的,对吧?
PS:篡改历史和武力侵略同等罪名,无耻之徒! -
什么是敏捷开发?
2007-11-07
敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷开发是全新理论吗?答案莫衷一是。细心的人们可以发现,敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发,这两种在任何一本软件工程教材中都会被提到的方法,在敏捷开发模式中扮演了很重要的角色。再向前追溯,我们还也可见到瀑布式与快速原型法的影子,也许还有更多。
改善,而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华,去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,”Fowler介绍,“这种非常短的循环,使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”
也许是因为时间关系,Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验,拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。
然而,我们不得不面对的现实却是,模式与方法的优化并不意味着问题的终结。作为一种开发模式,敏捷开发同样需要面对众多挑战。
大项目的拆分意味着更多子项目的出现,协调这些同步或异步推进的子项目,合理的资源调配都将变得更加复杂。另外,在当前项目和项目组普遍“增容”的情况下,遇到的问题同样成倍增长。人的重要性被提到了更高的高度,而缺乏有效协调手段,减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时,也相应引发了几乎同样多的问题。
敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论,他采取了"敏捷方式"组建团队:Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5~7名IT人员,其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外,还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训,具备相关的技能。
每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导),他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段,团队人员密切合作,开发有规律地停顿--在9周开发过程中停顿3~4次,以评估过程及决定需求变更是否必要。在Capital One,大的IT项目会被拆分成多个子项目,安排给各"敏捷团队",这种方式在"敏捷开发"中叫"蜂巢式(swarming)",所有过程由一名项目经理控制。
为了检验这个系统的效果,Bailar将项目拆分,从旧的"瀑布式"开发转变为"并列式"开发,形成了"敏捷开发"所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行"冲刺"--每个冲刺始于一个启动会议,到下个冲刺前结束。
在Bailar将其与传统的开发方式做了对比后,他感到非常兴奋--"敏捷开发"使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。"不过,有些需求不能用敏捷开发来处理。" Bailar承认,"敏捷开发"也有局限性,比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。此外,他觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。尽管描述需求一直是件困难的事,但经过阵痛之后,需求处理流程会让CIO受益匪浅。
敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:
·个体和交互 胜过 过程和工具
·可以工作的软件 胜过 面面俱到的文档
·客户合作 胜过 合同谈判
·响应变化 胜过 遵循计划并提出了以下遵循的原则:
·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
·即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
·经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
·在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
·围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
·在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
·工作的软件是首要的进度度量标准。
·敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
·不断地关注优秀的技能和好的设计会增强敏捷能力。
·简单是最根本的。
·最好的构架、需求和设计出于自组织团队。
·每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。敏捷设计就是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净及富有表现力。请记住,敏捷开发人员不会对一个庞大的预先设计应用那些原则和模式。相反,这些原则和模式被应用在一次次的迭代中,力图使代码以及代码所表达的设计保持干净。
-
职场最受欢迎的十大技能
2007-11-05
一个人掌握何种技能取决于他的兴趣、能力和聪明程度,也取决于他所能支配的资源以及制定的事业目标,拥有过硬技能的人有更多的工作机会。但是,由于经济发展前景不确定,掌握对你的事业有所帮助的技能显得尤为重要。最受雇主欢迎的十种技能。
一、解决问题的能力
每天,我们都要在生活和工作中解决一些综合性的问题。那些能够发现问题、解决问题并迅速作出有效决断的人行情将持续升温,在商业经营、管理咨询、公共管理、科学、医药和工程领域需求量骤增。
二、专业技能
现在,技术已经进入了人类活动的所有领域。工程、通讯、汽车、交通、航空航天领域需要大量能够对电力、电子和机械设备进行安装、调试和修理的专业人员。
三、沟通能力
所有的公司都不可避免地面临内部雇员如何相处的问题。一个公司的成功很多时候取决于全体职员能否团结协作。因此,人力资源经理、人事部门官员和管理决策部门必须尽量了解职员的需求并在允许的范围内尽量予以满足。
四、计算机编程技能
如果你能够利用计算机编程的方法满足某个公司的特定需要,那么你获得工作的机会将大大增加。
五、信息管理能力
信息是信息时代经济系统的基础,掌握信息管理能力在绝大多数行业来说都是必须的。系统分析员、信息技术员、数据库管理员以及通信工程师等掌握信息管理能力的人才将会非常吃香。
六、理财能力
随着平均寿命的延长,每个人都必须仔细审核自己的投资计划以保证舒适的生活以及退休后的生活来源。投资经纪人、证券交易员、退休规划者、会计等职业的需求量也将继续增加。
七、培训技能
现代社会一天产生和搜集到的数据比古代社会一年的还要多。因此,能够在教育、社区服务、管理协调和商业方面进行培训的人才的需求量逐年增加。
八、科学与数学技能
科学、医学和工程领域每天都在取得伟大的进展。拥有科学和数学头脑的人才的需求量也将骤增,以应对这些领域的挑战。
九、外语交际能力
掌握一门外语将有助于你得到工作的机会。现在热门的外语是英语、日语、韩语、法语和德语。
十、商业管理能力
在经济飞速发展的今天,企业管理人员能够掌握成功运作一个公司的方法是至关重要的。
这方面最核心的技能一方面是人员管理、系统管理、资源管理和融资的能力;另一方面是要了解客户的需要并迅速将这些需要转化为商机。 -
HR更关注应聘者跳槽思维:多次"跳"更值得信赖
2007-10-19
通常情况下,负责招聘的HR最担心的是花高薪把能人挖来后,对方干不了多久就走人。因此,大多数HR对多次跳槽者都心怀警惕。但不少用人单位不再紧盯应聘者的跳槽次数,而是关注其“跳槽思维”——在他们看来,冷静、理性、有规划的多次跳槽者,其实更值得信赖。
在大型综合招聘会上,某中型民营企业人事主管冯先生介绍,眼下该公司空出的中高级岗位较多,都是面向有经验的求职者。因此,在招聘过程中,如何在跳槽者中“淘金”至关重要。
面试中有名求职者小马,大学毕业2年不到,却已换了3份工作。“单从简历上看,该应聘者的跳槽频率并不低,但是不是就说明其职业稳定度不高呢?”冯先生表示,他在翻看对方简历后认为,小马的几次跳槽目标明确,职业轨迹清晰。
小马的专业是物流,第一份工作是在一家私营企业做物流助理,负责一些简单的行政工作,工作半年不到,由于老板是夫妻两个,在行政管理上常出现公私不分的情况,因此小马跳槽到一家民营企业的武汉办事处,担任对外联系工作,一年后,再次离职,到一大型物流公司担任普通职员。
冯先生表示,从小马先后两次的离职及叙述中,他认为小马对自己的职业定位较清楚,知道自己应该往什么方向努力。“类似这种离职的人,是在变化中寻求稳定,在几次离职换工作中,提高自身的能力,同时也提升了个人职业竞争价值。”这样的人,没理由不用。
但同样是高频率跳槽者,还有一种人,并不清楚自己需要什么样的工作,更不明白自己的职业目标在哪里,东家西家到处乱跳。“这样的人我们一概拒绝。要熟悉某个行业,至少需要半年的时间,那种还没有看清楚就贸然下结论说自己不适合这份工作的人,其实是对自己的不负责任,企业当然不会聘用。” -
有关的多线程测试
2007-10-11
Junit和许多开源软件项目集成在一起,但是Junit执行多线程的单元测试有一些问题。这篇文章介绍Junit的一个扩展类库———GroboUtils,这个类库被设计为来解决这些问题,并且使在Junit中进行单元测试成为可能。对Junit和线程有一个基本的理解是有好处的,但对于本篇文章的读者来说不是必需的。介绍
如果你已经在一个开源的Java项目上工作,或者读了许多有关“极限编程”和其它“快速开发模式”的书籍,那么,你很有可能已经听说过有关Junit的事情。它是由Erich Gamma和Kent Beck编写的,Junit是一个Java的自动测试的框架,它允许你为你的软件定义的“单元测试”———不管是测试程序还是功能代码,通常都是基于方法调用方法的。Junit能在很多方面帮助你的开发团队———在一些文章中已经包含了很多这方面的介绍。但从一个开者到另一个开发者,Junit实际上只专箸于两件事:
1、它强制你使用自己的代码。你的测试代码只是作为你的产品代码的客户端,从客户端的描述所获得的对你的软件的了解,能够帮助你标识出在API中的错误以及怎样改进代码,使其最终达到可以使用的目的。
2、它会给你对软件中改变带来信心,如果你的测试用例被中断,你就是立刻知道错误。在一天工作结束的时候,如果测试提示是绿色的,则代码是正确,你可以自信的检查它。
但是Junit不是解决所有软件测试中问题,第三方的扩展类库,例如HttpUnit,JwebUnit,XMLUnit等,已经认识到这些框架中不足,并且通过添加功能弥补不足,这些不足之一就是Junit不包含多线程的单元测试。
在这篇文章中,我们会看到一个很少有人知道的解决这个问题的扩展类库。我们通过建立Junit框架开始,并且运行一个例子来展示Junit在线程没试中的不足。在我们认识了Junit在线程测试方面的不足之后,我们通过一个使用GroboUtils框架的例子来讨论GroboUnitls
线程回顾
对于那些不熟悉线程的人来说,在这一点上是非常不安的(一点都不夸大),离开你的系统,我们将对线做一个简单的介绍。线程允许你的软件有多个任务,也就是说可以同时可做两件事情。
在Khalid Mugal和Rolf Rasmussen的书(A Programmer's Guide to Java Certification)中,对线程做了下面这样的简短描述:
一个线程是一个程序中的可执行单元,它是被独立执行的。在运行时,在程序中的线程有一个公共的内存空间,因此,能够共享数据和代码;也就是说,它们是轻量级的。它也共享正在运行程序的进程。
Java 线程使运行时环境异步,它允许不同的任务同时被执行。(p.272)在web应用程序中,许多用户可能同时发请求给你的软件。当你写单元测试对你的代码进行压力测试时,你需要模拟许多并发事件,如果你在开发健壮的中间件,这样做是尤其重要的。对于这些组件,使用线程测试是一个好的想法。
不幸的是,Junit在这方面是不足的。
有关Junit和多线程测试的问题
如果你想验证下列代码,你需要下载并安装Junit。按着指示去做,以便能够在Junit的网站能够找到它。不要过分追求细节,我们将简要的介绍Junit是怎样工作的。要写一个Junit的测试,你必须首先创建一个扩展于junit.framework.TestCase(Juint中的基本测试类)的测试类。
Main()方法和suite()方法被用启动测试。无论是从命令行还是IDE集成开发环境窗口,必须确保junit.jar在你的CLASSPATH环境变量里指定。然后为BadExampleTest.Class类编译运行下列代码:
import junit.framework.*;
public class BadExampleTest extends TestCase {
// For now, just verify that the test runs
public void testExampleThread()
throws Throwable {
System.out.println("Hello, World");
}
public static void main (String[] args) {
String[] name =
{ BadExampleTest.class.getName() };
junit.textui.TestRunner.main(name);
}
public static Test suite() {
return new TestSuite(
BadExampleTest.class);
}
}运行BadExampleTest来验证所建立的每一件事情的正确性。一旦,main()被调用,Junit框架将自动的执行任意一个用“test”开关命名的方法。继续并试着运行测试类。如果你正确的做了每一件事,它应该在输出窗口打印出“Hello World”。
现在,我们要给程序添加一个线程类。我将通过扩展java.lang.Runnable接口来做这件事情。最后,我们将改变策略,并且扩展一个使线程自动创建的类。
在DelayedHello的构造器中,我们创建一个新的线程并且调用它的start()方法。
import junit.framework.*;
public class BadExampleTest extends TestCase {
private Runnable runnable;
public class DelayedHello
implements Runnable {
private int count;
private Thread worker;
private DelayedHello(int count) {
this.count = count;
worker = new Thread(this);
worker.start();
}
public void run() {
try {
Thread.sleep(count);
System.out.println(
"Delayed Hello World");
} catch(InterruptedException e) {
e.printStackTrace();
}
}
}public void testExampleThread()
throws Throwable {
System.out.println("Hello, World"); //1
runnable = new DelayedHello(5000); //2
System.out.println("Goodbye, World"); //3
}
public static void main (String[] args) {
String[] name =
{ BadExampleTest.class.getName() };
junit.textui.TestRunner.main(name);
}
public static Test suite() {
return new TestSuite(
BadExampleTest.class);
}
}testExampleThread()方法实际上称不上是一个测试方法,实际上,你想使测试自动化,并且不想把检查结果输出到控制台,但是,这里却是这样的,因此,这一点示范了Junit是不支持多线程的。
注意:testExampleThread()方法执行三项任务:
1、 打印“Hello,World”;
2、 初始化并起动一个支持打印“Delayed Hello World.”线程;
3、 打印“Goodbye,World”。如果你运行这个测试类,你会注意到一些错误。TextHellWorld()方法像你期望的那样运行和结束。它没有发出任何有关线程的异常,但是你却不会接受到来自线程的返回信息。注意,你不会看到“Delayed Hello World”。为什么?因为线程还在激活状态的时候,Junit已经执行完成。问题发生在下面这行,使线程执行结束的时候,你的测试不能反映出它的执行结果。这个问题行是在Junit的TestRunner中。它没有被设计成搜寻Runnable实例,并且等待这些线程发出报告,它只是执行它们并且忽略了它们的存在。因为这个原因,几乎不可能在Junit中编写和维护多线程的单元测试。
进入GroboUtils
GroboUtils是Matt Albrecht编写的一个开源项目,它的目标是扩展Java的测试可能性。GroboUtils被发布在MIT许可下,这使它可以很友好的包含到其它的开源项目中。
Grobo TestingJUnit 子项目
GroboUtils被列入与同类测试方面有关的试验的子项目。这篇文章的焦点集中在Grobo TestingJUnit 子项目,它为Junit引入了一个支持多线程测试的扩展类库。(这个子项目还引入了集成测试和严重错误的概念,但是这些特征超出了这篇文章所讨论的范围。)
在GroboTestingJUnit子项目内是BroboTestingJUnit-1.1.0-core.jar类库,它包含了MultiThreadedTestRunner和TestRunnable类,这两个类是对Junit进行扩展处理多线程测试所必须的。
TestRunnable类
TestRunnalbe类扩展了junit.framework.Assert类并且实现了java.lang.Runnable接口。你可以在你的测试类内定义TestRunnable对象做为内隐类。虽然,传统的线程类实现一个run()方法,但是你的嵌套TestRunnable类必须实现runTest()方法来替代run()方法。这个方法将被MultiThreadedTestRunner类在运行时调用,因此你不应该在构造器中调用它。
MultiThreadedTestRunner类
MultiThreadedTestRunner是一个允许把异步运行的线程数组放入Junit内一个框架。这个类在它的构造器中接受一个TestRunnable实例的数组做为参数。一旦建立了这个类的一个实例,它的runTestRunnables()方法就应该被调用开始执行线程测试。
和标准的JunitTestRunner不一样,MultiThreadedTestRunner将等待,直到所有的线程执行终止退出。这样就强制Junit在线程执行任务的时候进行等待,从而巧妙的解决了我们前面提出的问题。让我们来看一下GroboUtils和Junit是怎样集成的。
编写多线程测试
现在把上面例子中的内隐类扩展自net.sourceforge.groboutils.junit.vl.TestRunnable包,我们必须像下面这样来重写runTest()方法。
private class DelayedHello
extends TestRunnable {
private String name;
private DelayedHello(
String name) {
this.name = name;
}
public void runTest() throws Throwable {
long l;
l = Math.round(2 + Math.random() * 3);// Sleep between 2-5 seconds
Thread.sleep(l * 1000);
System.out.println(
"Delayed Hello World " + name);
}
}
这时,我们全然不用创建工作线程。MultiThreadedTestRunner将在底层做这件事情,你重写runTest()方法来替实现run()方法,runTest()方法被后面的MultiThreadedTestRunner类调用———我们自己不会调用它。
一旦TestRunnable被定义,我们必须定义新的测试用例。在我们的testExampleThread()方法中,我们实例化了几个TestRunnable对象,并且把它们添加到一个数组中。然后,示例化MultiThreadedTestRunner类,把TestRunnable对象数组做为参数传递给这人类的构造子函数。现在,我们有了一个MultiThreadedTestRunner类的实例,我们就可以调用它的runTestRunnables()方法来执行测试。
MultiThreadedTestRunner(和Junit中的TestRunner不一样)在继续执行之前,将等待每一个线程运行终止。它也为通过构造器传递给它的每个TestRunnalbe对象创建工作线程并且调用异步的start()方法。这就意味着你没有必要通过创建你自己的线程来跳过这个障碍———MultiThreadedTestRunner会为你做这件事。下面是ExampleTest的最终版:
import junit.framework.*;
import net.sourceforge.groboutils.junit.v1.*;
public class ExampleTest extends TestCase {
private TestRunnable testRunnable;
private class DelayedHello
extends TestRunnable {
private String name;
private DelayedHello(
String name) {
this.name = name;
}
public void runTest() throws Throwable {
long l;
l = Math.round(2 + Math.random() * 3);
// Sleep between 2-5 seconds
Thread.sleep(l * 1000);
System.out.println(
"Delayed Hello World " + name);
}
}
/**在你的测试用例中使用MultiThreadedTestRunner,
* MTTR需要一个TestRunnable对象做为它的构造器的参数* MTTR创建以后,调用runTestRunnables()方法来运行它
*/
public void testExampleThread()
throws Throwable {//实例化 TestRunnable 类
TestRunnable tr1, tr2, tr3;
tr1 = new DelayedHello("1");
tr2 = new DelayedHello("2");
tr3 = new DelayedHello("3");//把实例传递给 MTTR
TestRunnable[] trs = {tr1, tr2, tr3};
MultiThreadedTestRunner mttr =
new MultiThreadedTestRunner(trs);
//执行MTTR和线程
mttr.runTestRunnables();
}
/**
* 标准的 main() 和 suite() 方法
*/
public static void main (String[] args) {
String[] name =
{ ExampleTest.class.getName() };
junit.textui.TestRunner.main(name);
}
public static Test suite() {
return new TestSuite(ExampleTest.class);
}
}
上面的例子中,每个线程将会在你发出测试指令后,在2到5秒之间向你返回它们的输出,它们不仅按时间显示,而且是以一个随机的顺序来显示。这个单元测试只有所有的线程都执行完成后才会结束。由于外加了MultiThreadedTestRunner,所以Junit继续执行测试用例之前,必须耐心的等待TestRunnables执行完成它们的工作,做为可选项,你可以为MultiThreadedTestRunner的执行分配最大的执行时间(这样以便你脱离线程,而不挂起测试)。
要编译运行ExampleTest,你必须在你的CLASSPATH环境变量中指定junit.jar和GroboUtils-2-core.jar两个类库的位置。这样你就会看到每人线程以随机的顺序来输出 “Delayed Hedllo World”
结束语
写一个多线程的单元测试不用感到苦脑,GroboUtils类库为编写多线程的单元测试提供了一个清晰简单的API接口,通过把这个类库添加到你的工具包中,你就可以把单元测试扩展到模拟繁重的WEB网络通讯和并发的数据库处理,以及对你的同步方法进行压力测试。


