Hadoop中的集群配置和使用技巧
本文介绍了Hadoop如何配置分布式框架运行环境,同时特别讲解了其中的一些细节。Hadoop可以单机跑,也可以配置集群跑,这里主要重点说一下集群配置运行的过程。本文是Hadoop入门实践三部曲的第二部。
- Java,
作者 Vikas Hazrati译者 李剑 发布于 2008年3月26日 下午4时2分
Sam Bayer在精益开发组中发起了一个很有意思的讨论,参与者们都在试图找到发奖金的最佳方式。另一个关键问题是,团队怎样自己推选出他们的领军人物来,比如一步一步给所有人都进行测试和QA工具培训的QA,或者严守自动化流程纪律,经常改进整体生产力的开发人员。Adrian Howard认为,通过个人绩效评估发奖金往往都会影响生产力,我们应该避免这种做法。它会成为团队内部冲突的主要因素,让一个运作良好的团队很快分崩离析。按照他的观点来看,一旦按照个人绩效来发奖金,那人们就会把个人目标凌驾于团队目标之上。
有两种方式,第一种是每个人得到X%的工资作为奖金,另一种是整个团队得到$X平均分配。不过很多人都对这种方案表示不满。有些人认为,把奖金平均分配就是明显的吃大锅饭,这对多干活的人是不公平的,会让他们情绪低落,效率降低;这种做法代价太大。而另一种做法也欠妥,按百分比来算,只会让工资越多的人拿得奖金也越多。假设A的工资是100K,B是50K,奖金是5%,那就是A拿5K,B拿2.5K。
Mike Cohn说到过这样一种情景,团队拿到了一笔很大的奖金,被告知他们自行分配。他们会想办法让大家的意见达成一致,但是这个过程会在团队内部造成巨大的难以修复的裂痕。最后他们能够做到的就是平均分配,尽管很多人会认为它不公平。让他们自行分配导致的冲突,会让大多数人觉得还不如一开始没有这笔钱呢。到现在为止讨论组内好像还没有得出最好的分配方案。在某些团队内可以生效的方案,也许放到其他团队中就会造成混乱。但是,貌似大多数人都赞同这一点:给敏捷团队发奖金就如同在刀尖上跳舞。
1、给“指标”发奖金应该比给人发奖金强吧(当然怎么选择指标也是一个问题)。 2、老手的价值应该在工资上体现出来,奖金我觉得应该偏向新人一点。 3、如果完全黑箱作业,会不会反而好一点?
其实奖金和工资一样,是工作带来的收入。既然目前的公司中工资都是不透明的,那么奖金也可以不透明。没有人会有意见。一旦奖金公开了,其后果与工资公开是一样的。这样看的话,奖金的分配根本就不应该公开,除非这个公司的工资是公开的。
小团队发奖金应该适当透明。 大团队黑箱操作,是必然的。
不患寡,患不均(公平、合理)。但要达到"均",何其难也。
1,写测试: Assert(solution.NobodyIsUnhappy());
2,写代码通过测试.
3,如果发现永远无法通过测试,修改测试: Assert(solution.HappyPeople.Count > solution.UnhappyPeople.Count);
4,写代码通过测试.
5,如果发现永远无法通过测试,修改测试: Assert(solution.HappyPeople.Count > 0);
6,写代码通过测试.
负面情绪是会扩散的,有一个人不爽,受影响的可不止一个人。 所以你那后两种方案都是很危险的。
同意
在发奖金的时候千万不要忘了发奖金的目的,如果因为发奖金而搞的众说纷纭,而且团队崩溃,那就很不爽了。如果真是为了提高士气,建议可以参考一下有些团队使用的象征性奖励法,小学生用的那个大红花有时就挺有用的:)但同时也建议团队让成员的薪水能够高到奖金多少对他们都没有太多意义的程度,这种情况下精神奖励才更加凑效。
本文介绍了Hadoop如何配置分布式框架运行环境,同时特别讲解了其中的一些细节。Hadoop可以单机跑,也可以配置集群跑,这里主要重点说一下集群配置运行的过程。本文是Hadoop入门实践三部曲的第二部。
Ruby的开放类(Open Classes)功能强大,但很容易被误用。这篇文章关注于怎样减少使用开放类的风险,介绍了一些其他可替代的类似方法,并分析了其他语言如何实现类似的功能。
在本文中,Stefan Tilkov讲解了一些经常出现在自称“符合REST式设计”的应用中的反模式(比如:全部采用GET或POST,忽视缓存及响应代码,误用cookies,忘记超媒体与MIME类型,以及破坏自描述性等),并给出了避免这些反模式的对策。
Hadoop是Apache开源组织的一个分布式计算开源框架,在很多大型网站上都已经得到了应用,如亚马逊、Facebook和Yahoo等等。本文是Hadoop入门实践三部曲的第一部,主要讲述了What和Why的问题。
本文结合37 Signals公司在开发Basecamp等产品时的实践,介绍了实用最小主义开发方法。实践证明,尤其是在开发Web应用时,这一方法非常有效。根据作者的观察,Google现在之所以那么成功,其所遵循的软件开发哲学和最小实用主义非常类似。
在今年5月份的网侠大会上,InfoQ中文站有幸与国内OSGi的先锋林昊(BlueDavy)在一起探讨了OSGi的相关话题,包括它的优势、复杂度以及Java下的实现等等。
Robert Pickering在F#的第三篇文章中,他继续着上次的话题,不过这次他要关注的是异步工作流(Asynchronous Workflows),以及在使用这个特性后获得的性能改善。虽然这篇文章是关于F#的,但是这样的知识对于所有的.NET语言都是适用的。
8 条回复
回复