11

Java的命运

作者:chenqiuge 分类:CTO视点, 架构实践 13 Comments »

文 / Peter Seibel  译 / 郝培强

本文是Common Lisp专家Peter Seibel对Google公司首席Java架构师Joshua Bloch的访谈,谈到他所遇到的最糟糕的Bug以及Java的命运。

最糟糕的Bug

Seibel:我们聊聊调试吧。你遇到的最糟糕的Bug是什么?joshua

Bloch:提起Bug我立马就想到了一个,这个Bug很严重,而且很搞笑。那是90年代初,我在匹兹堡的Transarc公司工作时。我在很紧的工期下提交了一个事务共享内存的实现。我在限期内完成了设计和实现,甚至还在过程中做出了几个可重用的组件。但是这么匆忙地写了很多新代码,我还是挺担心的。

为了测试这些代码,我写了一个叫做“乱撞”的很长的程序出来。它运行了大量的事务,每个事务又包含了嵌套的事务,嵌套到可以嵌套的最大深度。每个嵌套事务都可能会加锁,以递增的顺序读取共享数组里面的几个元素,对每个元素都加入点东西,保持数组中所有元素的和为0,还是不变量。这些事务要么提交,要么取消,如90%的提交,10%的取消,其他比例也可以。多个线程同步运行于这些事务之上,长时间地访问数组。因为我测试的是一个共享内存机制,所以我同时运行多个有多个线程的“乱撞”程序,每个有自己的进程。

在一般的并发级别下,“乱撞”轻松过关。但是当我真正调高并发级别时,我发现“乱撞”偶尔,仅仅是偶尔,无法通过一致性检查。我不知道这是怎么搞的。这只能是我的错,因为新代码都是我一个人写的。

我花了大约一个星期,痛苦地为每个组件写了彻底的单元测试,所有的单元测试都通过了。然后我为每个内部数据结构写了详细的一致性检查,这样我就可以在每次变化后调用这些一致性检查,直到测试失败为止。最后,我终于发现一个底层的一致性检查失败了,这个问题无法重现,但是某种程度上可以帮助我分析问题出在哪里。最后,我得出了确实的结论——我的锁根本不工作。两个事务锁定、读写同一个值的时候,产生了并发的读—修改—写回操作,而后一次写入毁掉了第一次的写入。

我编写了自己的锁管理器,所以我怀疑是它出了问题。但是锁管理器轻松地通过了测试。最后,我觉得问题不在锁管理器,而是它依赖的互斥体的实现!那时候操作系统还不支持多线程,我们需要写自己的多线程包。原来负责互斥体代码的工程师,不小心把我们的Solaris的线程实现中的lock和try-lock的汇编代码的标签弄混了。所以,每次你以为你在调用lock的时候,其实调用的是try-lock,反之亦然。也就是说当真的有争用发生的时候——在当年其实是很罕见的——第二个线程直接就进入了第一个线程的临界区,因为第一个线程也没有锁住。搞笑的是,这也就是说,整个公司几个星期都在运行没有互斥体的程序,而且谁都不知道。

阅读全文 »

标签:
阅读:24,929 次
10

文 / 李季

本文从数据隐私和数据隔离两个技术角度,对云计算中的数据安全进行了阐释和剖析。

与传统的软件架构相比,云计算在运营和支持方面的成本更低廉,同时又能够获得更快速的部署能力和近乎无限的伸缩性等收益。尽管如此,仍然有诸多企业在云计算和传统软件架构中选择了后者,原因很大程度上在于云计算中,有关企业数据的安全问题没有得到妥善解决。一些分析机构的调查结果显示,数据安全问题是企业应用迁移到云计算的最大障碍之一。

数据安全意指通过一些技术或者非技术的方式来保证数据的访问是受到合理控制,并保证数据不被人为或者意外的损坏而泄露或更改。从非技术角度上来看,可以通过法律或者一些规章制度来保证数据的安全性;从技术的角度上来看,可以通过防火墙、入侵检测、安全配置、数据加密、访问认证、权限控制、数据备份等手段来保证数据的安全性。由于传统软件和云计算在技术架构上有着非常明显的差异,这就需要我们用不同的思路来思考两种架构下有关数据安全的解决方案。下面我从技术角度探讨一下云计算的数据安全。

阅读全文 »

标签:
阅读:19,593 次
09

文 / Marty Cagan  译 / 刘雁 潘希颖 黄捷文

Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享,谈到了产品管理与产品营销的区别与合作关系,最后总结了导致产品失败的常见原因。marty

产品管理与产品营销的区别

业界权威指出市场上多达九成的产品未能实现既定目标,因而是失败的。即使你的产品不在此列,我依然觉得大多数产品构思拙劣、尚不成熟,可用性差、毫无价值的产品随处可见。

导致产品失败的因素很多,我会尝试从不同角度分析其原因。但我一直认为,最根本的原因是公司对产品经理的职责界定不清,担任这项工作的人缺乏专业训练。我一直在思考这个问题,因为它触及了产品经理的核心工作职责。

产品经理的工作是从细节上定义开发团队开发什么产品。市场营销的职责是对外宣传产品。两项工作天差地别。

为理清职责,我坚持为每款产品指派一名专职的产品经理,负责定义产品(将产品需求和用户体验设计相结合)。然而我发现企业常常会陷入以下三种误区。

由市场营销人员定义产品:由产品营销经理或所谓的“产品经理”负责收集高层产品需求,然后直接交给开发团队开发。这种方式忽略收集详细产品需求的步骤,回避探索(定义)产品的艰难决策过程,也绕开了用户体验设计。

两人分担定义产品的工作:定义产品的工作分给两人完成,产品营销人员负责高层商业需求,“产品经理”负责低层产品需求。

一人兼任两项工作:产品营销人员兼任产品经理的工作(有些公司称这类人为产品经理,有些公司还是叫营销人员)。

下面分别讨论这三种情况及其引发的问题。

由市场营销人员定义产品

这种情况很容易辨认。这类“产品经理”可以为产品团队提供市场营销资源、制作数据表格、培训销售队伍、为产品命名和定价,但是一旦涉及定义产品的具体工作,他们就无能为力,只能袖手旁观。我推荐大家工作之余看看呆伯特(Dilbert)系列漫画,作者用了大量笔墨描绘这类“产品经理”。

这类“产品经理”或许擅长市场营销,但是对详细定义有价值的、可用的、可行的产品往往束手无策。除非他们不但具备营销技能,还掌握管理产品的方法,那么产品还有成功的机会,否则只能寄希望于其他人(比如主程序员、交互设计师、公司高管)挺身而出,担起真正意义上的产品管理工作。然而,更常见的情况是产品从一开始就因此陷入了麻烦。

我第一次接触产品管理工作时,遇到的就是这种棘手的情况,从而导致我以前对产品经理没什么好感。幸亏后来遇到一位贵人,他让我明白了产品经理的真正职责。从那时起,我就开始强调产品经理的作用,并致力于重新定义产品经理的工作职责。

两人分担定义产品的工作

没人单独负责管理产品,这种情况也很常见。产品营销人员(有时被称为“业务责任人”或“商务产品经理”)负责收集高层业务需求;产品经理(在敏捷开发团队中也被称为“技术产品经理”或“产品责任人”)负责收集低层产品需求。

问题在于两个人都不是真正的产品责任人,没人对最终的产品负责。而且这种模式是基于错误的观点,即认为可以脱离具体需求(尤其是脱离用户体验)定义高层需求。

这种模式让产品经理的工作蜕变成制作各类文档,不但令人沮丧,而且限制创新思维,很难做出成功的产品。

大公司由于业务部门较多,很容易陷入这种管理产品的模式,它们常常为此苦恼,却找不到原因。 阅读全文 »

标签:
阅读:15,210 次
09

刘龙龙美国国家标准与技术局(NI ST)所草拟的一份说明,可能是对云计算基 本概念解释的最佳范例。其实它的主要内容只有很少的一页半,但是里面的许多专有名词还是需要进一步去了解才能体会。事实上,依照目前云计算的进展,它是不需要特别去定义或规范的, 只要代表着一个通用的示意名词就行;一步步来,不用急着把自己绑住。回想50年代的计算器以及程序员工作都 是极少数人才能接触到的领域,可是从80年代开始,个人计算机出现、微软窗口操作系统称霸、亚洲地区大量生产制造计算机等等因素促成IT应用的普及率迅速提升。这30年来,从个人计算机→网络→服务→云计算的进步模式,是一种持续发展的技术与应用。这些名词强调的是概念或模式,而不是严谨的定义(学校里学生考试时另当别论)。当然,现在一般人对于个人计算机与网络的认识与经验是比较多的,而相对之下对于服务与云计算的概念就比较陌生。

如果从参与者角色的扮演来看云计算,也许会更清楚一些。假设角色是简单地分成:一般的用户(或消费 者)、程序员、想要赚钱的企业或老板三种,而每个人都可以尝试扮演这些角色。从使用者来看,他们不会对技术 细节有太多的兴趣,可是会想要知道自己从云里面到底能得到什么样的服务,然后再算算价钱是不是划得来。比如 说,一个人家里的个人计算机已经是一两万块钱人民币的 高档货,上头什么软件都装得差不多了,而且网络带宽也很充裕,参加社交网络活动也很积极;那他可能想不出云计算会对他有什么特别的帮助(因为他不需要云里面提供 的服务就很方便)。因此,云计算所提供的服务一定要能带给使用者比他用他现有的基本设备与网络带宽所能获得的效益更多、更好(或他原来根本做不到的事情),才会产生吸引力。这大致也说明了云计算所标榜的On Demand 与非云的On Premises之间差异的基本概念。

阅读全文 »

阅读:10,036 次
08

yahoo云计算架构副总裁经常有人问,Yahoo准备转向云吗?我们的回答是,不,我们已经是云了。 Yahoo不会提供Amazon或者 Google那样的公共云平台。但是,我们早就开始向数以亿计的用户提供个人云服务了:邮 箱、照片、金融服务等等。我们称之为个人云。

更重要的是 ,当业界目前更多地将云计算视为降低成本、节约能源手段的时候(这些当然也非常重要),在Yahoo,云计算已经成为一种关键性的创新驱动力。

作为全球最大的互联网公司之一,Yahoo正面临着巨大的技术挑战。公司自身拥有庞大的网络资产,超过9千万网页,6亿用户(仅Yahoo邮件就有超过3亿的用户),成百个关注点和背景各异的产品和服务,每天要通过分析一千 亿以上各种各样的事件:登录、提醒、广告点击、文章点击、论坛发贴、上传图片、打标签、购物车……每天的流量数据以PB计算,存储数据量更是以数百PB的速度增加 ……

怎样才能在如此大规模的平台上,快速从海量数据中提取有价值的信息,将最受欢迎的内容提供给对其最感兴趣的用户,满足各种各样个性化的使用模式?怎样在这种规模的平台上,将停运时间降至最低(在Yahoo,即使是短时的停运,损失都将高达数百万美元),满足用户不断变化的需求,提供更好的用户体验?怎样优化Yahoo的 现有产品与服务,提升广告商的满意度,从而提高公司的 收益?

阅读全文 »

标签:
阅读:13,691 次
08

张大志某次针对211高校计算机系同学的就业讲座后,一位女同学提问:“研发领域女生工作机会比较少。如果我像男同学般要求自己,能有更多的机会吗?能不被歧视吗?”我的观点是: 不要主动寻求歧视,我们总能找到自己的位置。

研发领域给女性提供的职位少也许是个客观现象,有调查表明大学里相关专业的男女程序员比例与实际工作中的比例相当,说明大多数公司并不存在性别歧视的问题,更可能的原因是:学习计算机专业的女生本来就不多,相应的职位自然不会太多。

据说有些公司在招聘时会问“您最近有结婚打算吗?”、“是否有生孩子计划呢?”此类问题,明显暗示如果你打算结婚生子,那我们公司怕是不会考虑你了。对此我倒是建议女性不要委屈自己、告诉对方“我最近没这个打算”继而去迎合这种歧视。干脆不要考虑这样的企业。为人母是大多数女性人生非常重要的一部分,没必要因为工作而完全放弃自己的生活权利。更有些不靠谱的企业内部规定“女程序员不要”,遇到此种情况我们应该马上转身离开,不要主动寻求歧视。有如此规定的公司,即使是大企业、大公司也不必考虑。因为他们已经定下不要女性成为程序员,即使入职,以后发展机会也同样渺茫,身为女性根本没必要为证明什么而非要加盟这样的公司。

阅读全文 »

阅读:8,591 次
08

贾菡“妈妈快看,车车!”儿子高高举着刚用拼装玩具拼好的汽车,兴高采烈地跑过来向我展示他的新成果。“宝宝真棒,真好看!”我把视线从正在编写的方案标书中移到儿子手中的汽车上,狠狠的夸奖了他,其实是为了下面这句话:“宝宝乖,妈妈在工作,去客厅玩好吗?妈妈忙完了就跟宝宝一起玩。”其实我知道这是一个“空头支票”。说完起身关上房门,把儿子挡在门外,关门的一瞬间,儿子眼里充满了失望,但是很懂事的走开自己玩去了。不到2岁的他,已经很懂得在我工作的时候不去打扰,而我,亏欠他的太多。

混在IT业近10年之久,角色从一个小小的Web程序员变成IT主管,又成为售前工程师;而在家里,角色从单一的女儿,增加了妻子、儿媳、母亲……这些轨迹,看似男版女版都一样, 实际上女性要承担的可能更多。在一次与男同事聊天的时候,他们表示下班后宁愿在公司加班, 因为回家后事情太多,既要做家务又要照看孩子 ……想起刚生完孩子那段时间,因为每天早出晚归正好与孩子活动时间错过,以至于孩子对我越来越陌生,后来便毅然辞职在家陪孩子,直到他对母子关系的认知达到稳定的年龄阶段,我才又重新找工作。

阅读全文 »

阅读:7,863 次
08

liyb在WMware中国研发中心超过200名全职员工中,大概有20%的女性员工,具体到核心技术团队的女性编程人员,则只有10%。“女性不适合做程序员”这种传统观念在很大程度上 抑制了女性进入软件行业的积极性。但从女性工程师整体表现及公司对她们的各种评估上看,她们在能力上与男员工不相上下。对于一个公司来说,凡通过招聘标准入职公司的员工,皆是达到 公司要求的,而不存在明显的男女差别。

在我看来,只要对技术有足够的热情,把编程当做自己的兴趣爱好去追求;勇于探索新技术,不仅仅拘泥于工作所接触到的东西;具有很好的分析能力、团队协作能力的程序员均可以成为优秀的程序员。虽然女性在思维方式、生理、心理上与男性有所不同,但只要热衷于自己喜爱的,女程序员同样可以干得很出色。第一位女程序员Ada Lovelace就是一个很好的例子。

阅读全文 »

阅读:9,234 次
08

勇气和自信至关重要

pan在男性占据主导的软件行业中,女程序员往往更容易引人注意。如何让自己在众多男性同行中脱颖而出,并赢得他们的尊重?勇气和自信至关重要。

对于在男人堆中工作的女程序员们,需要有更多的勇气,并积极主动敢于进取。与同事们讨论问题时,要乐于表达自己的想法,它并不一定成熟,甚至可能遭到反驳,但只有提出来,同事们才能了解你的见解,在讨论中共同完善这个新的创意或解决方案。当面临挑战,要敢于主动接受,即使失败了,总结失败教训的过程也是自我提高的过程。

大家往往觉得女性在职业生涯发展上存在天花板。其实,所谓的“职业生涯天花板”很大 程度上产生于个人主观意识。一旦认为有“天花板”高高在上,你也就主动放弃了向上发展的所有机会;反过来即便有“天花板”,但相信自身实力,勇于尝试不同的方式打破“天花板”,你就有机会走得更高。

阅读全文 »

阅读:14,234 次
07

文 / Marty Cagan 译 / 兰蔚 刘雁

Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享,谈到了成功产品遵循的十条规律以及产品团队的关键角色及其职责。专家介绍

20世纪80年代中期我还年轻,在惠普担任程序员,参与开发一款备受瞩目的产品。当时人工智能风靡一时,能进入业内最优秀的公司,加入一支出类拔萃的团队(许多同事后来成为业界的中流砥柱),我感到非常荣幸。我们的任务难度不小:为低成本的通用工作站开发软件。当时市场上都是软硬件结合的专用产品,每个用户的花费超过十万美元——鲜有人负担得起。

我们辛勤工作了一年多,牺牲了无数个夜晚和周末。一路走来,我们为惠普增添了不少专利,开发出符合惠普严格品质要求的产品;我们把产品翻译成多种语言,实现国际化;我们还培训销售团队,向媒体进行展示,收到了良好的反馈。产品发布,我们以为万事俱备,开始庆贺。

但问题出现了:没人购买我们的产品。

这款产品在市场彻底失败了。是的,它的技术让人耳目一新,媒体反馈也不错,可是人们并不需要它。面对这个结果,团队成员很沮丧。但我们很快开始反省:谁有权决定开发什么产品?他们怎么决定的?他们怎么知道产品有没有用?

我们年轻的团队汲取了深刻教训,我相信很多团队也从失败中得到了同样的教训:如果开发的产品没有市场价值,无论开发团队多么优秀也无济于事。我们认识到仅仅做出产品并不够,还要确认产品是有价值的、可用的、可行的。

追溯产品失败的根源,我发现决定开发什么产品的人是“产品经理”,他们通常隶属于市场部门,负责定义我们开发的产品。同时,我还发现当时惠普并不擅长产品管理。不仅是惠普,大多数公司不谙此道,即便是今天有些公司依然如此。

我暗下决心,除非知道产品是用户需要的,否则我再也不会盲目投入精力。

此后二十多年,我有幸参与开发多款高科 技产品。个人电脑兴起时在惠普工作;互联网 技术爆发时,在网景/美国在线公司任平台及工 具部门副总裁;电子商务风靡时,在eBay担任 产品管理及设计高级副总裁。当然,并非所有 产品都同样成功,但我可以自豪地说,没有一 款是失败的。有几款产品广受欢迎,在全球拥 有上千万的用户。

离开eBay不久,我接到一些产品公司的电 话,对方希望改善开发产品的方式。与这些公 司合作后,我发现他们的工作方式与优秀公司 差异很大。我意识到普及一流产品理念的工作 任重而道远。大多数公司都在使用过时且低效 的方式定义和开发产品。同时我发现无论是学 术机构(包括最好的商学院课程),还是那些 因循守旧、无法自拔的公司(像我工作过的惠 普),都对此无能为力。

我选择这个职业是想开发客户喜爱的、 体现真正价值的产品。我发现产品主管都想打 造让人眼前一亮的成功产品,可惜多数产品都 缺乏创意、寿命短暂。因此,我希望通过自 己的博客文章和著作《启示录:打造用户喜 爱的产品》(Inspired: How to Create Products Customers Love)分享优秀企业的成功经验,让 更多的产品赢得客户的厚爱。 阅读全文 »

标签:
阅读:25,420 次
preload preload preload
京ICP备06065162