Archive

Archive for June, 2012

Progress, Visualized

June 18, 2012 Leave a comment

Apt comparison by Ole Begemann.

from Daring Fireball http://oleb.net/blog/2012/06/progress/

Advertisements
Categories: GR Tags:

Free Web UI Libraries, Frameworks and Toolkits

June 17, 2012 Leave a comment

You can also gather details of all these Free Web UI frameworks and toolkits along with the libraries. You can see the examples and demos.

from Queness http://www.queness.com/community-news/11794/free-web-ui-libraries-frameworks-and-toolkits?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+queness+%28Queness+%7C+web+design+and+development+news%29

Categories: GR Tags:

如何管理和控制一个成长型的公司?

June 8, 2012 Leave a comment
知识工作需要新的管理策略和风格,这一事实从软件行业的历史来看是很明显的。软件项目一直很难管理,直至今天,仍然只有为数不多的软件团队,能够按照承诺的进度和接近计划的成本一致地交付高品质的产品。软件开发是涉及大规模知识管理的第一种技术,虽然软件工作一直是一个管理问题,但是过去它只涉及大多数公司的一小部分。现代企业需要面对的两个关键挑战:管理增长的规模和管理知识工作。

为什么组织需要硬性规定

随着组织机构的成长,它们必须建立一些硬性规定来帮助运营业务。这些硬性规定通常有着层次化的结构,根据制定好的规则和过程进行运作。虽然硬性规定常常被视为麻烦的、有害的,但除了最小的公司之外,它们都有存在的必要。然而,必须正确地构建和管理,否则将产生延迟和低效。原因在于,就像人体的疤痕组织一样,硬性规定提供了保护,但同时也限制了速度和灵活性。

硬性规定的基本目的是要自动处理业务的运营细节。在正确运行时,它们可以节约高级经理的时间,使他们专注于业务的核心部分。例如,硬性规定可以例行处理一些任务,如运营自助餐厅,保持场地的干净和舒适,处理工资单、账单和开销,管理其他的业务日常细节等。在这些领域的硬性规定管理风格很少对业务的核心领域产生影响。但是,硬性规定在涉及更关键的活动时,可能会带来麻烦。下面的例子说明了这种事情是如何发生的。

 软件危机

公司的软件工作一直以来就是麻烦,但现在它太大,与业务的关系太深,因此无法忽略。软件部门一直延迟交付程序,公司的许多产品因为软件问题而落后于进度计划。这个部门麻烦深重,所以副总裁炒掉了软件部主任,要布兰登取而代之。他的任务是让软件工作摆脱失控状态。

布兰登视察了最大的3个开发团队,发现没有人有好的计划或进度表。虽然每个人都在努力工作,但工作混乱而失控。布兰登决定取消所有原有的进度计划,并要求每个软件团队制作一份详细的工作计划。他将复查并批准这些计划,并亲自做出所有将来的承诺。在副总裁批准了这个恢复计划之后,布兰登向他的经理发出了一道指示,告诉他们为所有的项目制定详细的计划,并在60天内和他一起复查。在他拒绝了前几份计划之后,他的手下知道了需要的是什么,也知道了如何让计划大幅改进。然后布兰登基于复查并批准的计划,发布了一组新的承诺,开发团队开始按进度计划交付产品了。

只要布兰登能够复查所有建议的承诺并亲自检查支持计划的品质,他的复查系统就工作得相当不错。但是,随着组织机构的成长,复查需要太多的时间,所以他发起了一个员工复查系统。目标是关注他在计划中发现的最常见的问题:那些常常忽略掉的活动。例如,项目的一些成本可能没有包含在预算之内,关键的需求可能被忽略,测试、维护和现场支持可能遗漏。

针对这个问题,他先让所有关键部门的代表来复查每份计划,然后再把计划送给他。这种方法有效,他不再必须亲自从头到尾复查每一份计划。但大约过了一年,市场和支持团队意识到,他们拥有了以前从未有过的影响力。他们开始拒绝批准,直到他们的特殊需求得到满足。市场部门在一些讨好用户的需求上讨价还价,服务部门抗议延迟缺陷修复的数目,测试部门则力争他们需要的资源。在这些问题变得严重之前,布兰登已经得到了晋升,复查系统变成了正常业务中的障碍。新的主任没有意识到问题和导致问题的原因,所以他从没想过放弃或改变该复查系统。

虽然布兰登的复查系统的最初目的值得称赞,但它已变成一个硬性规定,像许多这样的过程一样,它很快就被误用了。硬性规定者常常在他们狭窄的权力范围内拥有相当的权力,但他们的要求可能非常过分,甚至不合理。根本问题就在于,布兰登使用了一个硬性规定,作为强迫他的手下正确完成工作的机制。

让知识员工遵守确定的过程,这是一种代价高昂而又常常低效的方式。虽然这通常有效,但也让那些经常视野狭窄的员工拥有更多权力,凌驾于知识员工之上。这导致了延迟,限制了工程师创新的能力,让他们几乎不能很快地完成任何事情。同时,人们很快忘记了为什么当初要建立硬性规定,于是它就变成了低效率的仪式。也许最糟糕的结果就是,这样的硬性规定告诉知识员工,管理层不相信他们可以正确地完成他们的工作。虽然确保知识员工正确地完成工作是非常重要的,但硬性规定是一种代价高昂的手段。下面的例子展示了一个小而快速成长的公司如何应对它的成长问题。

 Quarksoft的故事

当奎塔 (Cesar Montes de Oca Vazquez)和瑞卡多(Ricardo Vidrio Delgadilllo)在墨西哥的蒙特雷科技(Tecnológico de Monterrey)大学开始他们的工程师生涯,做了约6年的软件工程师时,他们决定去美国的卡内基·梅隆大学大学(CMU)攻读软件工程硕士学位。在CMU,他们使用了SEI最新的软件工程方法TSP来完成他们的课程项目,并开始相信使用一个确定的、得到测量的知识工作过程是更好的软件开发方法,强过他们在墨西哥看到过的任何方法。

在从CMU毕业后,他们意识到他们拥有了独特的技能,可以帮助他们组建一家公司。通过利用TSP在墨西哥建立第一家软件公司,他们相信他们可以比其他公司做得更好,能够非常成功。在2000年,他们开始成为软件咨询师,然后在20015月,他们组建了Quarksoft。虽然当时他们还没有客户,但他们从11个员工开始,这些员工接受了TSP方法的培训。他们直到9月才找到第一个客户,但他们一起维持着这家公司,并让它缓慢成长。到了2004年,他们有了50名工程师,到了2006年,工程师人数达到了70。然后他们赢得了一些大合同,到了2009年年末,他们有了315名员工。

因为他们的员工使用的软件方法要求工程师在工作中收集并使用数据,所以该公司就能够建立一个精确、有效的管理系统。他们也让工程师团队自己制订自己的计划,以满足管理层的项目要求。在管理层复查并批准了团队的计划之后,工程师就有责任管理他们的承诺,有责任向管理层报告项目的状态,并在需要帮助处理风险或问题时找到管理层。

开发人员对他们自己的工作感到负有责任,行为就像他们是管理团队的一部分。因为他们制订自己的计划并确定自己的过程,所以他们有动力去遵守这些计划和过程。他们也很快学会了利用过程数据来评估他们的工作,测量项目的状态,并决定如何最好地实现业务目标和技术目标。为了帮助团队完成他们的工作,管理层建立了一个现场指导系统,指导项目启动和团队运作。结果是团队确实遵守了他们确定的过程和计划,所以几乎不需要一个硬性规定系统来强制实现标准的公司过程。

这种管理风格带来了一致的非凡团队表现,也为公司带来了快速增长的业务量。公司还获得了两个重要的墨西哥行业大奖。在2008年,DellAmerican Express都将Quarksoft评为该国最具创新的公司。在2009年,《CNN Expansion》杂志将它评为墨西哥十大最具创新公司之一。

 Quarksoft的管理系统

根据软件行业中大多数公司在成本和进度方面的糟糕表现来判断,软件工程是一门很难掌握的技术。然而,即便在这个复杂的领域,奎塔和瑞卡多也建立了一个盈利的公司,向客户提供高品质的产品和服务。这种非凡表现的首要原因就是奎塔和瑞卡多采用的公司管理风格。这种工作方式带来的业务上的好处可以从4个方面来描述:精确的数据、训练有素的团队、承诺负责制和品质。

精确的数据

要遵守TSP方法,工程团队和所有团队成员就要收集精确的数据,包括花的时间,生产的产品规模,以及引入和消除的缺陷。让工程师完整而准确地收集他们的工作数据是较大的挑战。即使拥有像他们一样的经验,Quarksoft的经理仍然称之为关键领域,需要不断注意和强调。但是,有了来自TSP团队的详细状态报告,经理就能够精确地、反应迅速地管理业务。工程师收集的数据涵盖他们所有的项目工作,他们每天都收集这些数据。有了这些精确的状态信息,团队就能够每周准确地报告成本和进度计划的进展。管理层于是就能够随时知道工作的进度,并能够立即响应项目的问题,或在需要变化时快速调整业务计划。

训练有素的团队

大多数执行官和高级经理都会同意团队很重要,但他们一般相信他们的手下已经在执行很好的团队协作实践。然而,Quarksoft遵循一个确定的过程来建立团队,指导并培训团队遵守他们的详细计划和运作过程。具体TSP过程是如何做的将在后续章节中介绍,其目标就是建立一个团结一致的项目团队,理解工作所处的业务背景,在工作方式上训练有素。这确保了所有工程师都理解他们的工作任务的原因,并感觉到有责任遵守他们确定的过程和计划。这也给他们授权,让他们成为创业者,像管理团队的成员一样做事。当他们对改进业务有想法,或者看到需要改变或修复的事情时,他们就可以自行改变,或将问题提交到相应的管理层。

通过鼓励团队参与和自管理,Quardsoft利用了员工的创造性。这让他们能够进行快速、创新的改进,并帮助他们培养未来的经理和领导者。这也在很大程度上消除了硬性规定的需要,而许多其他组织机构需要通过硬性规定来强制开发团队遵守业务纪律。然而,Quardsoft的管理层确实建立了一个硬性规定,用于检查过程数据的收集、管理和使用。就像财务数据一样,他们发现对于运营一个企业来说,及时、完整和精确的过程数据是很重要的,对于管理和改进盈利能力也很重要。

承诺负责制

也许Quardsoft的管理系统中最重要的元素就是它处理承诺的方式。在开始每一个项目时,执行官或经理负责项目的启动,与市场或客户代表一起,向工程团队解释公司在这项工作上的目标,以及客户为什么想要它。工程团队然后花几天时间制订一份工作计划,并向同一个管理小组介绍其计划。在这个决定性的启动会议上,工程团队请求批准计划,或针对任何需要更改的地方进行协商。

这个承诺过程称为TSP启动(TSP launch),它引导受过适当培训的团队制订完整而实际的计划。然后,有了合理的精确计划和全心投入的团队,成员们就有动力去做任何事情,以实现承诺。虽然所有的开发项目都会遇到让人吃惊的情况和问题,但如果这些问题能够立即意识到并加以关注,它们通常就能很快解决。因此,QuarksoftTSP团队很少不能兑现他们的交付承诺。

因为Quarksoft的大部分业务都是固定费用的合同,所以让团队制订他们自己的计划似乎有些冒险。但是,根据大量历史项目表现的数据,管理层就有了一个良好的基础,来制订和管理对客户的承诺。像在许多其他行业一样,他们意识到与客户进行合同谈判时,主要考虑是竞争和业务价值。虽然工程成本很重要,但它应该主要用于估计项目的盈利能力和风险水平。当管理层决定了最佳价格和交付日期后,团队的挑战就是确保管理层为他们提供足够的资源,以满足进度计划的需要,同时让所有团队成员为共同利益而努力。

品质

Quarksoft管理层将工程品质放在了第一位。他们这样做是因为,他们发现最高品质的项目通常是利润最高的。由于保证了工作品质,返工成本在开发成本中降到了最小。但对于知识工作来说,一致的高品质工作只能通过受过适当培训并且积极主动的人来实现。Quarksoft的管理层也发现,要一致地实现他们的进度计划承诺,他们必须在项目需要时提供有适当技能的、受过培训的人力资源。而且,由于所有TSP团队使用共同的过程,收集并使用相同的过程测量指标,因此,团队成员在项目间调动也相对容易一些。

因为员工的主动性、技能和培训是控制公司利润的主要因素,所以Quarksoft的管理层投入了大量的时间和精力,激励、招募、培训和培养员工。为了管理这些领域并确保每个项目都有技能和能力合适的骨干,他们让研发副总裁负责招聘、培训和人员培养。培训与个人培养计划也是每个经理的重要职责之一。

Quarksoft的执行官团队

当奎塔和瑞卡多创建Quarksoft时,奎塔的兄弟卡洛斯(Carlos Montes de Oca Vazquez)接受了TSP培训,并加入一所大学,担任计算机科学教授。几年之后,Quarksoft有了相当的发展,所以奎塔和瑞卡多邀请卡洛斯加入公司,担任研发副总裁。于是他们组成了公司管理团队,包括首席执行官奎塔、首席运营官瑞卡多与研发副总裁卡洛斯。

因为他们都接受过TSP培训,所以他们决定按照知识工作团队的方式来管理公司办公室,每一个半月至两个月就复查并重新启动他们的管理计划。在这些重启计划的过程中,他们复查长期目标,并更新下一个计划周期的公司总体计划。他们也为下一计划周期制订详细的计划和目标,并指派执行官团队成员负责23个目标。在每周的状态会议上,他们复查目标的状态,对照计划来追踪表现,关注任何需要注意的问题。

因为他们在公司运营的所有方面都有精确的数据,所以Quardsoft的执行官团队尝试了多种方式来追踪、控制和指导业务。他们做事的方式反映在最近的财务管理、研发改进,以及人员评价和激励上。

财务管理

有了团队级的计划和报告,Quarksoft的执行官团队决定追踪每个工程项目的每月利润贡献。于是他们开发了EBITA。EBITA是一个广泛使用的公司指标,即税息及摊销前利润(Earnings Before Interest, Taxes, and Amortization)。 测量指标,来展示每个项目对公司利润的贡献。他们首先通过对照计划比较项目的进度和人工状况,以确定如何计算项目对EBITA的贡献,然后确定其他相关的直接或间接的开支,得到项目级的盈利能力全图。

通过每月追踪项目的EBITA,他们能够断定何时某些项目不如另一些项目盈利,也能知道原因。他们还发现,项目级的EBITA每月的变动范围在5%之内。虽然这样的精度水平比传统的按季度测量要好很多,但一个月间隔的EBITA报告不能够让他们及时地确定问题并避免问题。在许多项目中,晚一个月发现问题可能会导致巨大的额外开支。

他们当前的目标是改进项目级的EBITA追踪,变成一周一次。为了做到这一点,他们计划从团队每周的挣值(EarnedValueEV挣值(EV)是针对计划测量项目状态的一种标准方式。根据每个任务占全部计划项目工作的比例,每个任务都有一个值,当这个任务完全完成时,这个值就挣到了。这不适用于部分完成的任务。挣值是一个标准的TSP团队测量指标。 状态报告中导出项目的EBITA,并进行追踪。这是可能的,因为TSP团队使用每天的EV测量指标来管理他们自己的工作。他们每周向管理层报告EV的状态。这为执行官团队提供了数据,可以导出每周的EBITA项目指标,而且也指导团队快速地确定很小的当日进度延迟(这种延迟在开发项目中是很常见的),并进行恢复。有了这种级别的精确性,管理团队希望能够及时识别项目的EBITA问题并采取措施。

研发改进

在研发领域,卡洛斯首先考虑的是确保开发团队使用最新、最好的技术实践。这也是为什么他负责招聘、培训和个人培养的原因之一。他还有一个目标是让每个团队运作在CMMI<span style=

from 《程序员》杂志官网 http://www.programmer.com.cn/12029/

Categories: GR Tags:

稳定婚姻问题和Gale-Shapley算法

June 6, 2012 Leave a comment

文 / 顾森

什么是算法?每当有人问作者这样的问题时,他总会引用这个例子:假如你是一个媒人,有若干个单身男子登门求助,还有同样多的单身女子也前来征婚。如果你已经知道这些女孩儿在每个男孩儿心目中的排名,以及男孩儿们在每个女孩儿心中的排名,你应该怎样为他们牵线配对呢?

最好的配对方案当然是,每个人的另一半正好都是自己的“第一选择”。这虽然很完美,但绝大多数情况下都不可能实现。比方说,男1号最喜欢的是女1号,而女1号的最爱不是男1号,这两个人的最佳选择就不可能被同时满足。如果好几个男孩儿最喜欢的都是同一个女孩儿,这几个男孩儿的首选也不会同时得到满足。当这种最为理想的配对方案无法实现时,怎样的配对方案才能令人满意呢?

其实,找的对象太完美不见得是好事儿,和谐才是婚姻的关键。如果男1号和女1号各有各的对象,但男1号觉得,比起自己现在的,女1号更好一些;女1号也发现,在自己心目中,男1号的排名比现男友更靠前。这样一来,这两人就可能抛弃各自现在的对象——如果出现了这种情况,我们就说婚姻搭配是不稳定的。作为一个红娘,你深知,对象介绍得不好没关系,就怕婚姻关系不稳定。给客户牵线配对时,虽然不能让每个人都得到最满意的,但搭配必须得稳定。换句话说,对于每一个人,在他心目中比他当前伴侣更好的异性,都不会认为他也是一个更好的选择。现在,我们的问题是:稳定的婚姻搭配总是存在吗?应该怎样寻找?

一次失败的尝试

为了便于分析,我们下面做一些约定。我们用字母A、B、C对男性进行编号,用数字1、2、3对女性进行编号。我们把所有男性从上到下列在左侧,括号里的数字表示每个人心目中对所有女性的排名;再把所有女性列在右侧,用括号里的字母表示她们对男性的偏好。图1所示的就是2男2女的一种情形,每个男的都更喜欢女1号,但女1号更喜欢男B,女2号更喜欢男A。若按A-1、B-2进行搭配,则男B和女1都更喜欢对方一些,这样的婚姻搭配就是不稳定的。但若换一种搭配方案(如图2),这样的搭配就是稳定的了。

图1 一个不稳定的婚姻搭配图

可能很多人会立即想到一种寻找稳定婚姻搭配的策略:不断修补当前搭配方案。如果两个人互相都觉得对方比自己当前的伴侣更好,就让这两个人成为一对,剩下被甩的那两个人组成一对。

图2 一个稳定的婚姻搭配

如果还有想要私奔的男女对,就继续按照他们的愿望对换情侣,直到最终消除所有的不稳定组合。容易看出,应用这种“修补策略”所得到的最终结果一定满足稳定性,但这种策略的问题在于,它不一定存在“最终结果”。事实上,按照上述方法反复调整搭配方案,最终可能会陷入一个死循环,因此该策略甚至不能保证得出一个确定的方案来,如图3所示。

图3 应用“修补策略”可能会产生死循环

Gale-Shapley算法

1962年,美国数学家David Gale和Lloyd Shapley发明了一种寻找稳定婚姻的策略。不管男女各有多少人,也不管他们的偏好如何,应用这种策略后总能得到一个稳定的搭配。换句话说,他们证明了稳定的婚姻搭配总是存在的。有趣的是,这种策略反映了现实生活中的很多真实情况。

在这种策略中,男孩儿将一轮一轮地去追求他中意的女子,女子可以选择接受或者拒绝他的追求者。第一轮,每个男孩儿都选择自己名单上排在首位的女孩儿,并向她表白。此时,一个女孩儿可能面对的情况有三种:没有人跟她表白,只有一个人跟她表白,有不止一个人跟她表白。在第一种情况下,这个女孩儿什么都不用做,只需要继续等待;在第二种情况下,接受那个人的表白,答应暂时和他做情侣;在第三种情况下,从所有追求者中选择自己最中意的那一位,答应和他暂时做情侣,并拒绝所有其他追求者。

第一轮结束后,有些男孩儿已经有女朋友了,有些男孩儿仍然是单身。在第二轮追女行动中,每个单身男孩儿都从所有还没拒绝过他的女孩儿中选出自己最中意的那一个,并向她表白,不管她现在是否是单身。和第一轮一样,女孩儿们需要从表白者中选择最中意的一位,拒绝其他追求者。注意,如果这个女孩儿已经有男朋友了,当她遇到了更好的追求者时,她必须拒绝掉现在的男友,投向新的追求者的怀抱。这样,一些单身男孩儿将会得到女友,那些已经有了女友的人也可能重新变成光棍。在以后的每一轮中,单身男孩儿继续追求列表中的下一个女孩儿,女孩儿则从包括现男友在内的所有追求者中选择最好的一个,并对其他人说不。这样一轮一轮地进行下去,直到某个时候所有人都不再单身,下一轮将不会有任何新的表白发生,整个过程自动结束。此时的婚姻搭配就一定是稳定的了。

这个策略会不会像之前的修补法一样,出现永远也无法终止的情况呢?不会。下面我们将说明,随着轮数的增加,总有一个时候所有人都能配对。由于在每一轮中,至少会有一个男孩儿向某个女孩儿告白,因此总的告白次数将随着轮数的增加而增加。倘若整个流程一直没有因所有人都配上对了而结束,最终必然会出现某个男孩儿追遍了所有女孩儿的情况。而一个女孩儿只要被人追过一次,以后就不可能再单身了。既然所有女孩儿都被这个男孩儿追过,就说明所有女孩儿现在都不是单身,也就是说此时所有人都已配对。

图4 应用上述策略,三轮之后将得出稳定的婚姻搭配

接下来,我们还需要证明,这样得出的配对方案确实是稳定的。首先注意到,随着轮数的增加,一个男孩儿追求的对象总是越来越糟,而一个女孩儿的男友只可能变得越来越好。假设男A和女1各自有各自的对象,但比起现在的对象,男A更喜欢女1。因此,男A之前肯定已经跟女1表白过。既然女1最后没有跟男A在一起,说明女1拒绝了男A,也就是说她有了比男A更好的男孩儿。这就证明了,两个人虽然不是一对,但都觉得对方比自己现在的伴侣好,这样的情况绝不可能发生。

我们把用来解决某种问题的一个策略,或者说一个方案,或者说一个处理过程,或者说一系列操作规则,或者更贴切地说,一套计算方法,叫做“算法”。上面这个用来寻找稳定婚姻的策略就叫做“Gale-Shapley算法”,有些人也管它叫“延迟认可算法”。

Gale-Shapley算法的意义和应用

每个算法都有它的实际意义,能给我们带来很多启发。Gale-Shapley算法最大的意义就在于,作为一个为这些男女牵线的媒人,你并不需要亲自计算稳定婚姻匹配,甚至根本不需要了解每个人的偏好,只需要按照这个算法组织一个男女配对活动就可以了。你需要做的仅仅是把算法流程当作游戏规则告诉大家,游戏结束后会自动得到一个大家都满意的婚姻匹配。整个算法可以简单地描述为:每个人都去做自己想做的事情。对于男性来说,从最喜欢的女孩儿开始追起是顺理成章的事;对于女性来说,不断选择最好的男孩儿也正好符合她的利益。因此,大家会自动遵守游戏规则,不用担心有人虚报自己的偏好。

历史上,这样的“配对游戏”还真有过实际应用,并且更有意思的是,这个算法的应用居然比算法本身的提出还早10年。早在1952年,美国就开始用这种办法给医学院的学生安排工作,这被称之为“全国住院医师配对项目”。配对的基本流程就是,各医院从尚未拒绝这一职位的医学院学生中选出最佳人选并发送聘用通知,当学生收到来自各医院的聘用通知后,系统会根据他所填写的意愿表自动将其分配到意愿最高的职位,并拒绝掉其他的职位。如此反复,直到每个学生都分配到了工作。那时人们并不知道这样的流程可以保证工作分配的稳定性,只是凭直觉认为这是很合理的。直到10年之后,Gale和Shapley才系统地研究了这个流程,提出了稳定婚姻问题,并证明了这个算法的正确性。

这个算法还有很多有趣的性质。比如说,大家可能会想,这种男追女女拒男的方案对男性更有利还是对女性更有利呢?答案是,这种方案对男性更有利。事实上,稳定婚姻搭配往往不止一种,然而上述算法的结果可以保证,每一位男性得到的伴侣都是所有可能的稳定婚姻搭配方案中最理想的,同时每一位女性得到的伴侣都是所有可能的稳定婚姻搭配方案中最差的。受篇幅限制,我们略去证明的过程。

这个算法会有一些潜在的问题。刚才我们已经说了,对于每位女性来说,得到的结果都是所有可能的稳定搭配中最差的一种。此时,倘若有某位女性知道所有其他人的偏好列表,经过精心计算,她有可能发现,故意拒绝掉本不该拒绝的人(暂时保留一个较差的人在身边),或许有机会等来更好的结果。因而,在实际生活中应用这种算法,不得不考虑一些可能的欺诈与博弈。

这个算法还有一些局限。例如,它无法处理2n个人不分男女的稳定搭配问题。一个简单的应用场景便是宿舍分配问题:假设每个宿舍住两个人,已知2n个学生中每一个学生对其余2n-1个学生的偏好评价,如何寻找一个稳定的宿舍分配?此时,Gale-Shapley算法就不再有用武之地了。而事实上,宿舍分配问题中很可能根本就不存在稳定的搭配。例如,有A、B、C、D四个人,其中A把B排在第一,B把C排在第一,C把A排在第一,而且他们三人都把D排在最后。容易看出,此时一定不存在稳定的宿舍分配方案。倘若A、D同宿舍,B、C同宿舍,那么C会认为A是更好的室友(因为C把A排在了第一),同时A会认为C是更好的室友(因为他把D排在了最后)。同理,B、D同宿舍或者C、D同宿舍也都是不行的,因而稳定的宿舍分配是不存在的。此时,重新定义宿舍分配的优劣性便是一个更为基本的问题。

稳定婚姻问题还有很多其他的变种,有些问题甚至是NP完全问题,至今仍然没有(也不大可能有)一种有效的算法。在图论、算法和博弈论中,这都是非常有趣的话题。

作者顾森,网名Matrix67,北京大学中文系应用语言学专业学生,数学爱好者。2005年开办数学博客,至今已积累上千篇文章,已有上万人订阅。

 

 

 

from 《程序员》杂志官网 http://www.programmer.com.cn/12001/

Categories: GR Tags:

about:mozilla: Firefox update, Paper toys, Heatmap study and more…

June 5, 2012 Leave a comment

about:mozilla is a weekly round-up of news and contribution opportunities. Here’s what’s happening this week.

Browse the Web Faster and Easier
A new version of Firefox is available in more than 85 languages, and it comes with new features. Our favorite one is the New Tab page, which shows customizable thumbnails of your most frequently visited sites every time you open a new tab. The Home Page has also been redesigned to give you easy access to certain features by using one-click shortcuts. Check out more about the release and don’t forget to update.

Firefox Paper toys

Did you ever wish to adopt a little Firefox and have it sitting around on your desk? If so, we have great news for you. Viking Karwur, the community manager of Mozilla Indonesia, turned the Firefox mascot into five cute paper toys you can download and build together. Grab your scissors and glue and download a template from the paper toy website on the Mozilla wiki to get started.

Announcing the April Dev Derby winners
Last month, over twenty awesome HTML5 audio demos were shared in the April Dev Derby competition, and the judges have decided on three winners. The Buzz HTML5 audio demo, a small game, is on the first place, followed by a Read-Along demo and an API for good-looking visualizations. If you are a developer, feel free to get inspired and get a head start on a future derby where you can show what you can do without JavaScript or with the Camera API.

Firefox Heatmap Study 2012
As you may have heard, Firefox will get a redesign pretty soon. For that, we needed to know how frequently users interact with various elements in the interface. The study, which lasted for one week, resulted in some valuable information. The User Experience team put it into heat maps which answers some questions that are needed for the redesign. Check out the heatmaps in this blog post.

Responsive Mode and Layout View in Firefox 15
Although Firefox 13 has only been released today, Paul Roget is already working on two features that will be available in Firefox 15. Thanks to him, developers can see what their websites look like on mobiles or tablets by simply resizing the window in the responsive mode. Additionally, the layout view lets them visualize the size of an element in the inspector. You can even watch a video of it in his latest blog post.

Meet Some Mozillians
Mozilla says bonjour to Jared Wein, Peter La, Sarah Brubeck, Nikos Roussos and Élisabeth Laude. Read more about how these people are contributing to Mozilla.

Upcoming events
* June 6, Mountain View Creating Successful Add-ons
* June 8, Charlotte, NC SouthEast Linux Fest and Open Database Camp
* June 9, Taipei, Taiwan PyCon Taiwan 2012
* June 11, Paris, France Orange Partner Days
* June 11, Zagreb, Croatia FFWD.PRO
* See more on the Mozilla Community Calendar

Get Involved
These are just some of the available contribution opportunities. Learn more about other ways to get involved and find other Mozillians in our community who share your interests.

About about:mozilla
The newsletter is written by Mozilla’s contributor engagement team and is published every Tuesday. For more on what has been happening this week also checkout the Mozilla Project Meeting. If you have anything you would like to include in our next issue,
please contact: about-mozilla[at]mozilla[dot]com or send us a status message on mozilla.status.net or a tweet @aboutmozilla. You can also subscribe to the email version.

Have a good week folks and keep rocking the Web!

from Planet Mozilla http://blog.mozilla.org/about_mozilla/2012/06/05/firefox-update-paper-toys-heatmap-study-and-more/

Categories: GR Tags: