写代码的人

Archive for the ‘职场生涯’ Category

大牛是个双刃剑

对社区来说,大牛是个双刃剑。前段时间看到Robbin说过这么一句,引申想了些关于社区建设的问题。

虽然社区强调平等,但根据经验,影响力等因素,社区成员还是会有高端用户低端用户之分。而社区对新人的态度,也很符合组织管理中的蘑菇理论:“蘑菇 管理”是许多组织对待初出茅庐者的一种管理心态,初学者被置于阴暗的角落(不受重视的部门,或打杂跑腿的工作),浇上一头大粪(无端的批评、指责、代人受 过),任其自生自灭(得不到必要的指导和提携)。不知道有多少人还能回忆起自己作为新人刚加入社区时的心态?没有人搭理你,参与发表意见时被指责为菜鸟, 同样的话,你说没人当回事,但“牛人”一说,应者云集。

但即使被当成蘑菇,爱学习的新人们还是对牛人充满敬仰,而且,社区吸引新人的一个很重要因素就是那里牛人云集。唉,我得说,新人们也真得很欠扁,虽 然无数次被鄙视,仍然对鄙视TA们的人无限向往。所以和商业社会一样,号称开放平等的社区也会“嫌贫爱富”,更多精力和财力会投放在吸收高端用户上,因为这样才能带来更多的用户。

一些牛人们为什么会鄙视新人?我猜想可能是自我感觉太好了。

真正的牛人,往往是很谦虚的人,他/她知道得越多,就越发现自己不知道得东西很多。一个人的知识经验思维,类似一个圈,而圈的圆周是这个人能感受到 的未知世界,因此,了解越多,人会发现自己不知道的东西越多。有些人一辈子就困在自己的那个圈中,和其它圈子没有交集。这也没什么,每个行业都需要深入钻 研的人,但因此就嘲笑自己根本就不了解的另外一个圈,就有些井底之蛙了。曾看到过一篇文章,某个对JVM底层很有研究的人,就很看不起做企业流程软件的应 聘者。

中心化的社区里牛人受到的关注太多,无形中,他们的认识奠定了社区的整体氛围。但很可惜,不是每个被大家推崇的牛人,或者自认为牛人的人,就是社区 需要的牛人。当一个社区慢慢成为一小拨人在巩固自己的小圈子,排除不同政见人群,社区的成长也就停止了。很多新人,或者已经成长起来的新人,可能因为社区 的内容吸引而来,但会因不喜欢社区氛围而离开。一些社区,经常会出现劣币驱除良币的现象,简言之,话频,呱躁,好斗的家伙们会挤走惜言慎言,不喜欢争论的社区成员。

技术社区需要的牛人:有自己的专业积累,有开放的心态,喜欢交流,就事论事,不搞人身攻击。而对社区建设者来说,制定规则就是挽留这类人,让这类人来协助社区成长。

来自:http://blog.csdn.net/Adali/archive/2011/03/21/6264818.aspx

10大IT职位尊重程度排行榜

人们常常根据工作头衔来评判他人,这缺乏公平。国外媒体根据尊重程度评出了10个IT工作角色。

1: 系统分析师

系统分析师受尊重,是因为他在创建成功的系统时需具有多种角色的经验。

他们是自主,独立,待遇高,并且工作富有挑战性。他们赚取的荣誉来自他们的教育、知识和成就。因此排名列表顶部。

2: 程序员

程序员在嘈杂的社区,躲在一个安静的房间。“这是写AI代码的程序员!”,也许很多没有得到这样更多的认同,但是这个群体让我们使用多姿多彩的Web应用,创建虚拟文字,使计算机可以做N多的事情,从游戏到商业核心应用。使用有魔力的语言代码守护者,值得尊重。

3: 数据库管理员

如果你做过数据库工作,并幸运的是数据库管理员的角色,那么恭喜你。聪明的开发者晓得好的、有经验的DBA对于成功的项目至关重要。部分是艺术,部分是科学,DBA的技能对系统性能有着重要的影响。

4: 项目经理

项目经理的活儿不好做,他们要介入项目周期的所有阶段,受尊重在于他们的技术和管理技能。

这个角色不是给新手的,只有那些做过10年的项目经理的,才是真正的项目经理,才配得上这个称号。仅此一点,就就足以赢得其他项目组成员的高度尊重。

5: 系统管理

系统管理员授予访问权限的“关卡”任务,但是这个群体的工作还是容易被忽视,即使是IT专业人士。”不幸的工作“的是他们所做的就是系统对一个用户赋予权限,失去其他系统管理员的爱戴。

6: IT经理

不同于其他的行业,经理应该在榜首。IT经理受到影响的是他们没做什么”实际的事儿“。IT经理赚取尊重是他们在职业阶梯上的晋升,当然同时也缺乏技术能力。这可能不公平,但IT经理还是缺乏认同。另外,雇员相信他们的经理对他们的工作有总体思路,但是缺乏对他们工作细节的了解。

7: 网络管理

“因为他的原因,导致我不能访问Facebook或者Twitter?”“他是不是阅读了我的邮件?”等,网络管理员似乎获得不了任何的爱戴。

8: 报表专员

报表专员,看似一个华而不实的教士,系统调出数据,生成图表,…

如果你将差的数据图表传给你的经理,你可以利用这句老话“不要杀我,我只是一个使者!“

9: 技术员

当硬件或系统发生紧急情况时,低水平的技术员将遇到麻烦。如果是高水平的技术员能很快搞定,那么这是“英雄的一天”。但更经常的情况是,用户只需要技术人员来修复他们的系统。

高压力、低薪酬、常处于“危机”时刻的技术员,引不起更多的关注和威信。

10: 服务台分析师

服务台分析师是为人们解答各类问题,但是不能从客户或者其他IT专家那里获得尊重。电话铃响时,几乎总是不满意的客户打来的。他们的表现衡量与那个铃声与通话直接挂钩。获得尊重?难呀。

原文:http://www.techrepublic.com/blog/10things/10-it-positions-ranked-by-prestige/2347

来自:http://www.oschina.net/news/16389/top-10-it-jobs

 

Reid Hoffman:创业十规则

LinkedIn 的创始人和执行主席 Reid Hoffman 在西南偏南互动讨论上(SxSW)做了主题演讲“创业者怎样创造未来”,阐述了他关于互联网行业创业和 Web 3.0 产品的观点,并举出十条他认为创业者应该遵循的规则。

Reid Hoffman 本人的职业生涯起步于苹果和富士通的产品管理,后来在 PayPal 任执行副总裁,2003 年合作创办了 LinkedIn — 商务社交网站的先锋。除了丰富的行业经历,他本人还是硅谷最成功的超级天使投资人之一,先后参与或促进的投资包括 Facebook,Zynga,Flickr,Digg, Last.fm等八十多起。他的观点不仅很好地解释了硅谷目前的机遇现状,也从侧面反映出投资人的喜好。

1. 尝试“突破性变革”

“这项产品必须是能改变行业的东西。” 怎么判断你的创意是否足够有变革性呢?Hoffman 说,这项产品应该价值 10 美元,而只收取 1 美元。例如 Skype 等 VoIP 取代了原本昂贵的长途通话服务。有足够变革性的产品才有机会创造新的生态系统。

2. 目标远大

和第一条规则的精神相通,Hoffman 认为没有宏伟的愿景就不可能改变行业。他的另一个主张是,通常运营一个小公司和一个大公司所要花的精力是相同的,与其创建一个飘摇不定的小公司,不如尝试创建一个大公司来改变行业。

3. 创建关系网

Hoffman 说这不是指将你的公司与社交网站结合,而是建立一个身边的关系网。周围的每一个人都有可能成就我们,从投资人、董事会成员到你的初创员工、指导者,每个人都很重要。创建这样一个关系网、让人认识到你的价值,能带来众多机遇,扩张公司规模。

4. 为机遇和挫折做准备

创业者经常会遇到各种机遇,把握机遇并适时调整计划的能力是很重要的。有时候一个意想不到的惊喜就能让公司平步青云。例如 PayPal 最初仅仅专注于移动平台,有一天创始人发现有大批用户来自 eBay。一开始团队觉得非常奇怪,“为什么这些 eBay 用户会来用我们的产品?这太糟糕了。” 后来他们意识到才意识到 PayPal 面临的机遇——成为在线商务的支付工具。

5. 变通地坚持自我

创业者时常经历这样的两难局面:一方面,他们被告诫要坚持自己的创意和愿景,把指责和批评丢在一边,用公司之后的发展来反驳这些批评。另一方面,他们还被告诫,要懂得变通,根据数据和客户需要来调整自己的方案。Hoffman 指出,“创业的艺术是知道什么时候坚持,什么时候变通,两者结合。”

6. 产品发行越早越好

“发行得早到你会为自己在 1.0 版所犯下的错误感到羞愧。” Hoffman 说,“除非你是乔布斯”,否则你的产品肯定在某些方面不够完美。而往往创业者在产品发行、用户真正使用之前很难发现这些错误。只有产品发行之后,你才能听到人们的评价并知道需要做哪些改变。他举例,八年前他的合作伙伴希望等到添加“Contact Finder”功能之后再上线网站,他没有等待。而事实证明这项功能并非必需,八年后的 LinkedIn 也依然没有 “Contact Finder”。

7. 保持足够高的志向和目标,不过别摔得太惨

回溯了之前的几条经验,Hoffman 觉得有时候创业者也需要对不切实际的空想保持警惕。(译者注:自吞苦水翻译自 drink you own Kool Aid,Hoffman 用了一个九十年代流行的笑话,Kool Aid 这种果味饮料冲剂在当年政坛竞争时代表巨大的失败。)

8. 产品创意很重要,不过产品销售才是重中之重

如果产品不能被推广至百万乃至更多的用户,它就无足轻重。Hoffman 还拿一些初创公司开玩笑,这些公司号称“他们会在稍后加入社交功能” 而错失了社交功能本来可以带来的机遇。

9. 企业文化和员工从一开始就至关重要

谨慎选择你的合伙人、投资人、指导人非常重要,最初创业招聘的员工更是对公司影响深远。别忘了,招聘下一批员工的人就是你现在的雇员。

10. 这些创业规则不是自然法则,你可以打破他们

创业的精彩之处在于从无到有的“创”的过程。如果被人笑话你打破常规,走上前人失败的老路,没关系,也许你这次就成功了呢?

Hoffman 的演讲除了创业经验,还阐述了他对 Web 3.0 的观点。他认为移动平台固然是 Web 3.0 的发展潮流,不过数据才是下一轮互联网行业机遇的关键。具体来说,他认为 Web 1.0 是“搜索,找到信息数据”,Web 2.0 是“真实的用户身份”和“真实的社交关系”,而 Web 3.0 则会是“用户真实的身份和关系所产生的数量庞大的数据”。

目前在做数据信息处理的公司很多,例如 LinkedIn 能让用户找到有特定技能的用户、公司或需要特定技能的待聘职位;移动应用 Waze 通过分析你的位置和行进速度来判断当前的路况,给出交通状况建议;还有 Redfin,在线房地产交易网站,为购房者提供更多当地房地产市场以及他们看中的房子的信息。

当然,如此一来与信息共享相关的隐私保护就至关重要了。4chan 的创始人 Christopher Poole 和 网络明星 Felicia Day 都在 SxSW 上阐述了他们理念中匿名制的优势。Hoffman 则认为初创公司只需要遵循两个原则:

  • 永远别“伏击”用户。别在他们不知情的情况下收集或分析数据。
  • 数据的平等性不同。用户并不在意他们分享的全部信息,但是密码和信用卡号码这些更重要的信息才是需要注意的关键。

Hoffman 还发起了一个有趣的“自我指涉”活动,他希望通过社交网站的数据收集关于“社交网站数据能催生的有趣应用”的创意。如果你有兴趣,可以在 Twitter 上发表你的创意并加上标签 #web3,Hoffman 的团队会在之后制作信息图展示这些想法。

来自:http://www.ifanr.com/36441

 

我所经手过的最差代码

导读:本文出自知名技术专家Jacques Mattheij(ww.com的创始人)最近发表的博客《The worst program I ever worked on》,译文来自36氪,原名《我破解了那位程序员“最饿”的阴谋》。

文章内容如下:

曾经听说有些程序员会在自己编写的程序里做手脚以保住自己的饭碗不被抢走,没想到我自己还真的碰上这样的事了。

那是我的一份小工,一家公司解雇了自己的程序员后,让我帮忙把他们产生了故障的一个软件修正过来。我接下了这份工作,可没想到接下来的那段时间我就天天泡在一堆“食物”里了。

你很难想象这个程序的作者是个什么样的人,我真怀疑他是不是成天想着吃,因为他将这个程序中所有的函数和变量全部用食物的名字命名,Pizza’s(披萨),tomatoes(西红柿),pickles(泡菜),fruits(水果),vegetable(蔬菜)等各种估计只要是他能想到的食物的名字都被他用了进来。

不过我还是蛮佩服这家伙的,加密的非常漂亮不是吗,一般人还是难以看出这些食物中蕴藏的玄机的。于是我开始一点一点的为这些函数和变量重新命名以将其转变成有意义的表达。

虽说这项工作也并不是无法完成或者极难完成的那种,但是将其从毫无意义的表达变成有意义的表达还是一项非常繁琐的工作。此外比这些无意义的食物名称更加要命的是那家伙在程序里还用了许多种面条的名字使得本已混乱的程序变得更加晦涩难懂。最后我一步一步的将重命名的工作完成后,还改写了很大一部分的代码使其变得更加容易被理解和有效的执行。

我一直在想这家伙是先写完了该程序的原始代码后再将其打乱成了现在的这副模样,还是他一开始就直接敲出了这一堆毫无意义却又能有序执行的食物代码,如果真是直接敲出来的,那好家伙,他太牛了。

不过,最后,我在此还是要奉劝各位敲代码的一句,不要企图在代码里做手脚来保住自己的工作或者要挟什么,你知道的,这没有好结果。毕竟,敲出这一堆食物来的那位哥们还是失败了,不是吗?

原文链接:The worst program I ever worked on

译文链接:我所经手过的最差代码


项目管理杂谈-走还是留,是个问题!

每年到了3、4月份,就到了人才流动的高峰期,至于原因,这里就不谈了。这不,项目组中有人要离开了,在共同奋斗了几年后,突然有人要离开,虽有不舍,但人各有志,不可强留。

对于程序员跳槽,我总结了一下,一般来说,各项指标的重要程度如下图所示:

该跳槽影响示例图说明了如下问题:

1、薪水:薪水是第一位的,一般辞职或者是跳槽,都是为了薪水,毕竟我们国家不讲究归属感,而且社会福利等方面也没有达到能够让程序员衣食无忧的状态,许多人还是为了混口饭吃,解决温饱问题。而跳槽是普通程序员加薪的最快的手段。

2、职位:职位的提升也是程序员跳槽的一个重要指标,一般来说,刚进公司是基础性的职位,比如初级程序员,如果2、3年后还是该职位,且公司没有提升的打算,这个时候跳槽的话,一般会到高级程序员这个职位,同理,有些人会从高级程序员提升到项目经理、技术经理等。

3、稳定性也很重要,看看现在报考公务员的人数就知道了,很多人为了追求工作稳定,也会跳槽,这个时候,选择的对象是比较大的、比较稳的公司,尤其对于很多30几岁的程序员来说,为了老有所养、老有所依,追求稳定性的工作是其关注的重点,谁让我们生活的压力这么大呢。

4、人际关系:有时候的跳槽是由于项目组的人际关系比较复杂,有些程序员没有团队意识,导致项目组内矛盾不断,如果是这方面的问题,则要好好考虑了,即使跳槽也不会有好结果,到了其他公司还是一样。

上面从基本角度对几个重要因素做了说明,但其他的有时也可能是决定性的因素,比如说为了婚姻等而跳槽。跳有跳的好处,跳了之后,可能在薪水、职位等方面有所提高,或者有更大的发展空间。但也有不好的方面,比如,跳了之后,要去适应新环境,新的人际关系,重新建立人脉,如果跳的太频繁的话,给自己的职业信誉也带来影响,在我负责招聘时,如果简历上看到某个人一年一跳,这种人的简历我会立即扔进垃圾桶。再看留守,留守意味着坚持,留守的好处:在熟悉的环境中工作,有一帮相处融洽的兄弟姐妹,如果公司发展好的话,只要你的价值能够体现,提升是必然的;但如上所述,在短时间内,薪水或职位可能不会有太大的提升。另外,即使要走,也要等到把事情做成功之后再离开,而不是逃避。

员工跳槽了,对于项目组来说是个损失,下面从项目组的构成和项目的阶段分别谈谈。

项目组的构成方面:我把项目组人员分成两类:骨干成员(项目经理,高级程序员)、非骨干成员(普通员工)。骨干成员的跳槽对项目组的影响比较大,对于小公司来说,有时候甚至导致项目的终结。而非骨干成员的跳槽对于项目组影响不大,只要完成相关交接工作即可,就目前来看,非骨干成员还是供大于求的阶段。

项目阶段方面:把项目分为初期,中期,后期。初期阶段,处于需求分析、设计阶段,骨干成员的影响较大;中期,大量的工作是编码,这个时候,普通员工的作用也比较大,一个萝卜一个坑,走了之后需要有人顶上,否则会影响进度;后期,项目基本结束,代码工作量较少,只要不是烂摊子,如果完成相关的交接,则影响比较小。

以上对走与留做了个简单的分析,走与留需要程序员自己做出判断,要从各方面多做分析,权衡利弊后再做出决定,把自己的强项和弱点都力举出来,无论跳还是留,都要发挥自己的强项,不要把自己的弱项暴露在别人面前,否则可能陷入跳槽的怪圈,而形成跳槽的习惯,不利于自己的职业发展。当对自己的取舍都已经做出决定的时候,走还是留已经不是问题了。

 

 

好代码不值钱

导读: 原文来自geekm.ag 上一篇《 Good code is cheap code》,由国内整理编译《好代码不值钱》。作者认为好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式。

以下是文章内容:

 

当我跟做开发的同事说出这话时,他们的第一反应是一种惊愕,然后是将近一个星期的嘲笑,把它当作一个笑话来讲。当他们走近看我的表情、知道我是认真的时,才收敛一点。

当最初的惊愕消退后,他们会用一些这样的话来反驳:“好代码不廉价,好代码是采用经过数十年计算机科学研究和积累得出的最佳实践设计模式和方法论建立起来的精心制作的程序代码。”

我只好继续解释为什么他们给出的好代码的定义有问题的原因是(这是很多开发人员都忽视了的一个原因):知晓各种设计模式,框架,技术技巧只是事情的一方面,而知道何时该、何时不该应用他们才是更重要的问题。在不知道一种技巧方式如何能对系统的开发有帮助的情况下,这种模式方法极有可能成为一种开发的阻碍,而不是一种有益的帮助。

我还要解释说,我所说的“廉价的代码”是指这些代码只需要很少的人/天数就能开发出来,并不是说是由没有经验的开发人员、在很少的工资报酬下、用6个月封闭式、只有烤白薯和豆腐汤可吃的环境中开发出来的东西。

但是 … 设计模式毕竟是个好东西 … 不是吗?当然,但它们好在哪里?它们能提供什么好处?

  • 容易维护
  • 产品更健壮
  • 容易理解
  • 易于日后的改进提高
  • 更好的可跟踪性

你会发现所有的这些最终都落到一点上:从长期的角度看,它们能让你更快的做事情。这事情有可能是系统迁移,或是增加一个新功能,不论是什么,通过运用这些方法模式,你会在时间效率上获得实实在在的好处。

这么说,我们观点一致吗?

怎么说呢,让我给你们说个例子,我们看看实现它的几种方式。

系统

用PHP创建一个发邮件的表单,表单里有几个表单项,用邮件把这些数据发送给某个人。除此之外,表单里的内容还要存入MySQL数据库里。

现在,用什么方式实现它们最好?按照传统的说法,采用最好的实践设计模式,你可能会想到这些:

  • MVC
  • N-层设计,包括数据库抽象层
  • 对象关系映射(ORM)
  • 可能用到的框架
  • XML配置和相关模型
  • 等等.

我可以说,这简直是疯了,客户的这些需求完全可以用10几行代码、一个小时里(包括测试时间)完成,而且所有的那些方法模式所希望达到的效果(诸如可读性,可移植性,稳定性)都有了。如果使用上面列出的那些,反而真正的会达不到这个目标,使代码复杂化,难于理解和维护修改。

那现在,假设客户又来了,要求做一些改动,比如要增加一个管理员的界面。这样的话,你就胜利了,你已经实现了很多很有用处的东西;然而这是因为你在第一次开发这个系统时付出了很大的代价。我要向你声明的是,即使我现在把这些简单的代码进行重构,增加一些简单的业务层,也仍然比按你要求的那种过度技术化的初始实现方案要简单的多。

再说了,如果客户要求的只是在表单里增加一个属性,那你的N-层设计方案会让你痛苦不堪,因为你需要改动各个层,包括那些CRUD代码。

SCRUM

我发现Scrum能吸引我的最大一个原因是它能迫使你敏捷开发;它能迫使你在每个Sprint结束的时候把东西都实现、发布。它不会让你做出目前用不到的多余的东西;它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。

相反,在你需要的时候你才去重构。当然,这会有一定的风险,因为在实现某些功能上你会花去比当初已经做了一些基础工作的情况下要更长的时间。然而,产品开发就像是一个沙漠中四处漂移的沙丘,你永远不可能准确的知道一个产品在将来会做如何的改动。所有的你花在实现这些很有吸引力的各种模式上的时间很可能会成为一种完全的浪费。

复用性

有些人会指出,我所说的方式产生的代码不具有太多的复用性,不能在新开发的一些其它系统中使用。我对这个问题的回复就是,在根本不知道某些东西是否/如何/在哪将会被复用的情况下去设计一个可复用的东西,这就跟去实现一些你根本用不到的功能或你的应用里跟本用不到的功能一样愚蠢而糟糕。如果你有一个清楚的远见,知道什么地方会复用这些东西,这就不同了,因为你确实有一个内部的业务需求在指导你正确的开发方向。

我的最后的思考 …

  • 我想,如果
  • 了解你的设计模式,知道它们各自的好处(我一直认为,好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式);
  • 让你的代码廉价:
  • 当模式能够给你带来好处,而且为你省时时才去使用它们;
  • 如果不是这样就不要使用它们(例如:想想你最近的一次为什么要把系统迁移到一个不同的数据库上?);
  • 当框架能够帮你提高开发速度时才使用它们;
  • 在必要的时候重构,不要做一些超前性的开发;

你能按照这些指导原则做事,你会发现开发周期变短、实现的代码更简洁,易于调试,易于维护修改。

原文链接:Good code is cheap code

译文链接:好代码不值钱

来自:http://www.aqee.net/2011/03/16/good-code-is-cheap-code/

 

如何正确有效的管理开发人员(引)

我做了15年的开发经理。我曾荣幸地管理一些伟大的人 – 其中许多已成为终生的朋友。我也管理过一些我再也不想听到名字的人。在前进的道路上我遇到一些很好的导师,我也曾为一些伟大的经理、不知名的经理,一个精神病患者工作过。这些既有价值,也是具有挑战性的经历。为我工作过的同事,说我是个非常好的开发经理。

一路上,我认识了许多其他开发经理。我见过一些真正的优秀人才,很多差劲的经理。我很高兴在世界一流的公司-微软工作,也看到了一些开发经理因为他们的糟糕管理而被解雇。

管理开发者真的很难,为什么?因为软件开发本质上是一个创造性的活动,如音乐,美术,建筑,数学和写作。是的,是肯定的…强大的工程、软件开发的科学性。好的工程,科学的方法,可以让开发者更好。但是在一天结束时,编出好的软件是创造性的工作,管理有创意的人根本就是很难。

我们让开发者做两件事情:思考和创意。良好的思维与创新,不能被规定。80%的开发管理工作是让人们能够做到他们最好的思考,勇于创新,具有良好的时间连续性。它是不可能被规划,管理或安排的思维和创造力。

另外是”装运“工作。在某个时刻,我们需要发运我们的软件到使用者的手中。搬运工作可以被设计,策划,安排和管理。目前的挑战是使人们去思考和发挥创意是需要非常不同的技能,相比装运。

如果你想成为一个优秀的开发经理,那么你的首要任务是不能怠慢。在一些管理方面的怠慢就像一个高尔夫球员不能推杆。一个球员能够有超人的能量、长驱直入、以伟大的方式比赛,但是,不会推杆,那么会推杆的醉汉也能击败他。

这一系列文章是我对开发经理的建议,如何正确有效的管理开发人员。

我希望你喜欢这个系列文章,就像我喜欢写这样文章时一样。
最好的问候
– Foredecker

来自:http://www.oschina.net/news/16352