如果你自己不是一位程序员，该如何雇用程序员呢？你需要注意一下几点： 1. 他们有多坚持己见（固执）呢？ 询问他们有趣的编程主题（如Ruby或Python？）。从他们回答的语调和推理中，可以得到很多信息。在我们最近一期节目中 ，杰夫说：当人们对事情有强烈的见解，当他们可以大篇幅地谈论一些事情时，这就是一个很好的迹象，表明他们对这件事很有热情。 2.他们为开源项目做了多少贡献？ 看看他们的贡献。虽然你可能不是一个程序员，你仍可以知道他们是否写过一些代码。而事实上，一个人有所贡献，是一个良好的开端。事实上，一直在贡献意味 着他们正在使用这种工具，Jamis说。这就好比抓痒，就像他们接触到一些他们认为应该加以改进的程序，或接触到一个错误并且自己修复了那个错误。参 与程度对程序员是一个很好的鉴别标准。 3. 他们有多享受编程？ 他们不需要在自由时间的分分秒秒都去敲代码，但是你确实想看到一定程度的热情。Jamis说，与其说在业余时间编码本身是最重要的事情，不如说它展示了你热情的态度和有自己的见解。 4. 他们真的掌控工作？（Do they actually ship?） 了解他们如何管理自己的工作。软件通常出小错误了解他们如何避免这种情况。了解他们什么时候按时地完成了项目，并询问为什么这个项目是成功的。或 从延迟项目中吸取了什么经验教训。控制软件运行的能力是关键的，据杰瑞米说。他们是如何管理实际需要的任务并在一定的时间内完成，这是很重要的。 5. 他们掌握了什么？ 皮克斯（Pixar）公司的兰迪纳尔逊认为，能够掌控任何一件事意味着也能够掌控其他事。所以寻找那些掌控着一些事的人。候选人是一个优秀的厨师 吗？或山地车选手？还是其他什么人物？这是一个迹象表明他们也可以做您项目的主导者。那是一种即使其他登山者几乎马上就要到达山顶，仍感觉我将要先到 达山顶的感觉，尼尔森说。如果一个人在来到你工作场所之前都没有涉足，那么他成为工作的主导者的可能性也是很小的。 6. 他们的沟通能力如何？ 你对编程了解的越少，你越需要依靠一个人去解释程序进度。这就是无论什么职位都要聘请大作家的原因，这是个好主意。例如，这儿有杰夫解释的在计划方案内Basecamp API人员更新到其他项目的例子： 我只是对Basecamp 和Companies APIs的人员进行更新调整。 我们现在允许客户和公司员工去接触通过项目认识的人和公司。在此调整之前，公司员工和客户只能看到对方使用的特定的项目ID。没有办法让他们看到在项目过程中参与的所有人（例如，同事）。 例如，如果API用户发出的请求，一个是鲍勃，另一个是吉尔，那么/ people.xml文件将返回给鲍勃和吉尔。如果请求的用户是管理员， 那么帐户中的所有的人都能收到。 这同样适用于公司管理。 如果一个程序员既能够编码，又能讲非程序员能听懂的的话，那么很多事情是不太可能出问题的。（编注：上面这6点，是招聘官需要知道的注意事项。关于在聘用程序员或开发人员的时候，需要问哪些问题，可以参见《如何面试程序员？》这篇文章。） 试用 （Test drive ） 如果可以，摈弃全要或无用的决策模式。雇用一个全职员工是一个很大很困难的决定。为小项目聘请员工，让他们在空闲时间完成这些项目，这种方式更容易为双方所接受。《Getting Real》 中的浅尝辄止 一文中谈到： 在雇佣任何人之前，先给他们一个小项目来考虑。我们就会了解他们对待这个项目是如何沟通，工作的，等等。当他们设计或者编写的时候，就会给你带来很多发现。你会相当快的学习，无论氛围是否恰当。 可以用日程安排来坚持这种方式，即使只需要20或40小时，也比什么都没有要好。适合或者不适合，都会显现出来。如果没有，那就是双方想要先测试工作而隐藏了自己的问题与风险。 仔细考虑一下，你能提供什么，并且如何才能让你的职位尽可能的吸引人，这也是个不错的主意。壶里的蜜越多，才会有越多的蜜蜂飞进去。（恩，不管怎样， 可以肯定这不像一个东西放在那一样）在《Great Hackers / 伟大的黑客》中保罗点格雷厄姆提供了一份列表，关于如果吸引最优秀的程序员：优秀的开发工具、开源软件、带门的房间、一个感兴趣的问题和聪明的同事。如果 你有其中的任何一项或者全部，确保让潜在的雇员能够了解到。 自己动手？ 所有这些都会有所帮助，但是很显然，雇佣程序员最好的方法是你自己能至少了解一点编程。雇佣一份你从来没有做过的工作，真的是件很困难的事。因此，要在雇佣了那些人之后管理他们，格雷厄姆在他的《伟大的黑客》一书中有过如下讨论： 我看过关于如何管理程序员的一些文章。事实上有两种：一个是如果你是程序员，你该做什么，另一个是，如果你不是程序员，你该做什么。而第二种可以总结为两个字：放弃。 问题不在于日常管理。实际上，真正优秀的黑客（hacker）是自我管理的。问题是，如果你不是黑客（hacker），你就不会知道谁才是真正优秀的黑客（hacker）。 确定自己是否能在招聘员工之前了解一些编程技术。事实上，杰森在与DHH合作之前就已经开始学习PHP了。同样的，在我们当中有人学会如何配置服务器之前，37signals不会雇佣系统管理员。如此做来，你就会对寻找应聘者以及你想解决的问题有更深入的理解。 至于你在这过程中犯的错误，要记住，这就是真正的程序员的工作方式。运行迭代感觉就像永远反复的错误校正杰瑞米解释到。这听起来很令人泄气，但这却是允许的。该死，甚至测试驱动开发也是反复的错误校正。所以，建议你应该先从自己做起。 译文出处：伯乐在线 -职场博客 译文链接：http://www.jobbole.com/entry.php/588 原文作者：Matt文章推荐：关关 翻译：伯乐在线敏捷翻译组 -魏哲 本文转载自:http://www.jobbole.com/entry.php/588

北京时间3月24日消息，据国外媒体报道，美国知名IT杂志eWeek网站今天撰文，称火狐4浏览器要优过微软IE9，并解释了其中的10大原因。 1、更好的设计 火狐4和IE9这两款浏览器的重大改进之一就是它们都具有了更好的设计。这两款浏览器都具备了简化的用户界面，有利于吸引更多的用户。但火狐4浏览器的设计 相对更好一些，看上去有点像Opera 11，有更好的菜单设计。总而言之，在实用性和外观吸引力等方面，火狐4浏览器的界面比IE9更胜一筹。 2、稳定性 微软已经多次强调，IE9是其史上最稳定的浏览器。但目前为止，火狐4浏览器似乎更加稳定，其中的一大关键原因就是火狐浏览器即使是出现插件情况下仍能够持 续工作，这些插件包括Flash，QuickTime，甚至是微软的Silverlight等。当然这并不意味着火狐4浏览器永远不会崩溃，但至少可以表 明其比IE9更加稳定。 3、支持多种操作系统 鉴 于Mac OS X用户的数量仍在不断增长，这些用户应当知道火狐4浏览器有一点与IE9大不相同，即它能够支持Mac OS X用户所喜欢的操作系统。另外，火狐4浏览器还支持Linux操作系统。或许更为重要的是，火狐4也可以兼容Windows XP等系统。而IE9却只兼容Windows Vista 和Windows 7。这对微软面议是个大问题，因为全球仍有55%左右的用户仍在使用Windows XP系统，从这个角度来看，火狐4浏览器又赢了一步。 4、微软的品牌问题 微 软目前面临的一大问题是应当努力克服此前多种旧版IE的失败问题。全球仍然有大量的用户不信任微软浏览器的安全与稳定性。而另一方面，Mozilla 却不面临这样的危机，因此也就不会担忧品牌影响问题。用户如果不信任微软IE9的安全性，那么就可能会选择其它的浏览器，例如火狐4。 5、没有速度优势 微软推出IE9时，一直在强调此浏览器的运行速度。但并非每位使用此浏览器的用户都认为IE9能够快速地加载网页。但从目前的测试结果来看，尽管火狐4浏览器的网页加裁速度也并非特别快，但其能够提供更多的功能和优势，这样一来，用户当然会选择火狐4，而不是IE9。 6、安全问题仍令用户担忧 微软在支持IE9的安全问题方面，已经做出了大量的工作，例如保护用户免受针对浏览器的恶毒软件攻击以及网站的漏洞攻击等。但是，IE9面世时间还不长，到目前为止，还没有足够多的用户下载此浏览器，因而也就无法考证它的具体安全性。当然这也并不是说IE9就没有安全性，相反可能还是微软至今为止最为安全的浏览器。鉴于微软系列浏览器过去存在的安全问题，以及IE9还未得到充分的检验，因此用户保持担忧心理也就不足为奇了。 7、火狐在附加组件方面更胜一筹 据 Mozilla方面称，火狐4浏览器支持20多万个附加组件。旧版火狐浏览器的用户都非常清楚，附加组件也是用户选择火狐浏览器的主要原因之一。火狐4浏 览器支持勿需重启动附加组件，这也就表明用户在安装了一个附件工具后，无需再重启浏览器就可以继续使用。鉴于火狐4浏览器具有大量的有用附件，因此该 浏览器就更值得用户下载使用了。 8、同步功能更加出色 火狐4浏览器已经为用户增加了更多的同步协作功能，例如同步使用书签、个人偏好、历史、密码等。这些功能方便，工作效果很好，这也可能是促使用户选择火狐4浏览器的另一大重要原因。 9、支持Web标准 Mozilla 认识到：支持整合的Web标准绝对是火狐4浏览器必需完成的要点之一。火狐4浏览器充分支持HTML5，包括WebM高清视频内容等。此外，火狐4浏览器 还支持3D图形、离线数据存储、专业排版、触摸屏界面，以及帮助创建更多视觉体验的Mozilla音频API等。总而言之，所有的这一切都会让用户感 觉到，火狐4将会带来非凡的体验。 10、未来更新 用户在评估浏览器时，重要的一点就是要决定哪一款浏览器能够更好地适应不断变化的网络世界。目前为止，火狐4浏览器似乎业已成为赢家。除了能够支持重要的 Web标准和具有新功能之外，Mozilla还经常对其浏览器进行更新，此举表明火狐4的推出还只是一个开始。在未来的几个月，估计火狐4浏览器还会进行 更多有价值的更新。 本文转载自: 腾讯科技 收藏此资讯

我不是《敏捷宣言》最早的签署者， 我甚至不是诸如TDD等敏捷实践的最早期采纳者。然而， 回望过去，我认为我是敏捷原则的早期采纳者， 即使当时我没有认识到这一点。 时间盒、增量式开发、持续集成、波浪式日程安排、 小石子式规划和报告、并行开发和测试等等这些实践， 我在很久之前就开始用了。多年来， 我们把这些实践跟敏捷联系在一起，因为它们确实很有成效。 我从来就不是命令与控制式项目管理的拥护者， 那样做不起作用。然而我过去担心敏捷会给不规范的工作提供借口。 回到2001年，敏捷的拥趸主要是开发人员。他们一直把 不要文档放在嘴边上，而不是这样的事实：修复缺陷的成本大幅下降，人们可以马上看到可以运行的软件， 测试人员从项目开始第一天就能真正加入到项目中来。没有这些， 我们当时听到的都是：你不用再写任何文档了，写一些卡片就成。 好吧，我们确实要写卡片，而且会与人谈话， 这样我们才能了解需求，而不是仅仅试着将写得不好、 没什么内容的文档，替换成信息含量丰富的人际交流。 到了2003年的时候，发生了一件有趣的事情。 我当时在为一个组织做评估，他们采取为期6周的迭代。 他们的迭代有作用，但成效不显著。我当时很清楚： 他们需要缩短迭代周期。 当我撰写报告的时候，我建议他们将迭代周期缩短为最长三周， 两周最好。我还觉得， 如果他们能够将特性的大小减到能在几天内完成的程度， 他们就可以得到更快的进度，而且能给别人演示。 我建议他们使用持续集成，放弃原来按阶段集成的方式。我还建议他们整合开发和测试团队，整合开发和测试活动。这时， 我已经变成了一个敏捷人士！ 到了2003年下半年，我开始撰写和讲演与敏捷有关的内容， 提到类似这样的观点：敏捷不是不按规范工作的借口， 相对其他软件开发生命周期，敏捷需要团队遵守更多纪律。 当然，我当时并不认为我是敏捷人士。我决定实验一些实践， 比如结对和TDD。当我还是个开发人员的时候， 我跟一些人们采取了紧密的一对一工作方式， 我那时并不知道这是不是结对。于是，在一次AYE会议上， 我和同事Keith Ray一起结对实践TDD；我明确了解到： 这就是我以前的工作方式。不过有一点， 相对于80年代我的那些同事们来说，Keith要友善多了。 到了2005年，Esther Derby和我结对编写了《门后的秘密:卓越管理的故事》 的最终一稿并付梓。是的，我们坐在一起， 使用一台电脑和一个键盘，轮换写稿和指导。是的， 我们在敲出第一个单词之前有很多问题需要回答。 你看，我们从2000年开始写这本书， 我们的第一稿用了好几年才写成。送审之后，我们的审读人说： 内容很棒，就是太枯燥。因此，我们又用了好几年来修订、重写， 并再次送审。审读人说：内容很棒，但是比第一版还要枯燥。 这下我们可麻烦大了。 Esther建议我们改变形式，还要结对写作。 我不记得我们中是谁建议在编写每章之前提出问题， 这就采取了测试驱动的方式，而且很有效。但是， 这个版本并没有花费我们两个人两年的时间， 我们用了6个星期就完成了草稿。而且，它一点也不枯燥！ 就算回到1994年，当时我刚刚开始教授项目管理， 我就让大家使用黄色即时贴和迭代式方法做日程安排，还告诉人们： 他们的日程安排方法取决于他们的软件生命周期。现在， 我将敏捷放在我的软件生命周期列表之中， 教给人们如何使用迭代日程安排来应对所有类型的软件生命周期。 到了2000年早期， 当从未尝试过敏捷的人们认为敏捷会为不规范工作提供借口时， 我开始担心。我对他们的经验表示怀疑，他们高傲地说： 他们不需要任何经验就能知道，没有文档的项目就是不规范。 我问他们能不能提供一些成功项目的例子。无一例外， 他们都提到自己的成功项目都使用了原型化方法（迭代的例子）， 还有功能特性（增量式开发）。 我解释说他们已经描述了敏捷的元素，而且跟他们说： 如果他们的客户需要文档，比如美国FDA或是其他监管机构， 他们才可能会写文档；听到这些，他们就对敏捷没有那么多敌意了。 还是有人不相信所有的项目都可以使用敏捷。我就是其中之一。 不是因为有些产品的开发还不能敏捷实践， 我就在硬件项目中用过敏捷方法，包括芯片设计项目。 不是这样的。不能用敏捷，是因为还是有人、 团队和组织无法接受敏捷带来的透明度。 顺序式流程让人们得以隐藏： 管理层可以藉此隐藏多任务以及缺少决策的现象， 这是管理债务的表现。在顺序式生命周期中，架构师可以隐瞒这样的事实： 在做出架构上的决策时，他们知道得不够多，没有足够的数据。开发人员可以避开缺陷和测试代码。顺序式生命周期让项目经理编制出甘特图童话， 并邀请其他人也相信其中的日程安排，这是一次编写， 永不阅读的日程，然后隐藏在这样的日程之后。顺序式生命周期让测试人员可以避开自动化测试， 即使这样做很有意义。 简而言之，对于所有我们已知的、能够提升代码质量、项目水平和技术水平的实践，顺序式生命周期让所有人避开它们。 等到我们愿意拥抱敏捷带来的透明度时，我们都在口头上谈论 变得敏捷（becoming agile），却没有将其视为一个系统 一种整体的工作方式。变得敏捷已经说得很多了，至于怎么做， 却言之甚少。 现在，在2010年，我扩展了自己在时间盒内对看板的使用， 而且在某些情况下用看板替代时间盒。 这是因为有些客户不愿意承诺在时间盒内完成工作， 而是愿意承诺完成某个特性或是缺陷修复， 这对我来说算是足够好了，更重要的是，这对他们很好。 回到2001年，我当时认为自己是个实干的人，现在我也这么看。 我希望工作有成效，我希望我的客户的工作有成效， 不管采取什么方法，只要是适合他们特定的环境。很多时候， 这意味着综合方法、时间和技术等多个方面。 我也许是偶然成为敏捷人士，但是我现在坚定地站在这个阵营。 对我来说，最重要的是看到人、产品和项目所处的环境和上下文， 然后帮助人们做出最佳决策，尽力转向有成效的敏捷。 关于作者 Johanna Rothman与企业一起，帮助他们改善产品研发的管理水平， 最大化管理和技术人员的生产力，提升产品质量。 Johanna是Agile2009大会的主席。 她还是下列书籍的作者。 《Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects》2008 Jolt生产力大奖获奖图书：《项目管理修炼之道》《门后的秘密:卓越管理的故事》Hiring the Best Knowledge Workers, Techies Nerds: The Secrets and Science of Hiring Technical People 她为Stickyminds.com和Gantthead. com的extreme project management撰写专栏文章，还在自己的网站jrothman.com上开了两个博客。她刚刚开始在http://www.createadaptablelife.com/上撰 写博客。Johanna还是Amplifying Your Effectiveness大会的主持人之一。 查看英文原文：The Accidental Agilist: A Personal Look Back at 10 Years of the Agile Manifesto 本文转载自: InfoQ 收藏此资讯

有多少次你曾经听到一些公司的领导说，公司之所以成功是因为拥有优秀的人才？你在演讲里听过，在采访里、书里、公司的宣传资料上读到过。听起来很对 很好、很谦虚、很有风度。他们说的很正确，但他们没有说出故事的全部。 在这些访谈里、书里，这些人没有告诉你的事情是 我读了不少这些东西 优秀的公司也许在很多事情上都很优秀，但他们并非都总是招 募到正确的人。这使它们处在跟其它的公司相同的处境(也许几率会小些)。这是一个鲜为人知的小秘密：即使是优秀的公司也不得不解雇一些不能出活的员工。你 很少听到这样的消息，因为解雇员工不会产生好的公共关系形象。并不是说这看起来不好、不仁慈。但这确实会给人留下一个负面的印象。 这些年来在用人上的失误经常让我困惑：我究竟错在哪里？我怀疑我是否是唯一一个为这种事情而困惑挣扎的人。我精心经营着我的公司，面对着所有因为没有掌握到最好的招募、培训和管理员工的方法而带来的不良后果。这里所写的就是我最终学到的一些经验。 如果你想创办一个优秀的公司 给客户优秀的服务、优秀的产品，让员工愉快和一个好的盈利，你时不时的就需要去招募。招到了谁？一个经过殚精竭虑的培训、指导、忠告后仍然不能干活的人。 一个如果10分为满分只能得到大概6分的人 但正是这6分让人棘手。他们并不是很差，但确实不够好。 你怎么看出他们只有6分？你了解他们。你甚至喜欢他们。他们看起来有能力，但总感觉不那么可靠。他们经常犯错误，他们对人不好，他们很马虎，他们不 能很好的把个人时间和工作时间区分开，他们不太诚实，他们不承担责任，他们拖拉，对同事不友好。这真正的考验是：如果他们辞职，你内心深处的反应是什么？ 松了口气？我想这说明了一切。 对于所有的这些有问题人，这有一个度的考量。有人痛苦的面对很多这样的人，有人对其中的一两个人非常的不爽。根据同其它的几个企业老板交流的结果， 我可以告诉你，大多数的老板都会留下一些6分的人(甚至4分或5分)。他们承认挣扎于是否解雇他们的想法中。当然他们是有权利的。老板留下这些人，因为这 能让这些人高兴些。可问题是，经常事与愿违。 这些老板努力使公司更上一层楼，让公司更盈利或只是守住市场份额。可问题是，开除员工不是件有趣、轻松、高兴的事情。事实上，这可能是当老板最 难做的一种事情。大多数情况下，这些人都还是挺好的，他们努力工作，只是不太胜任。问题就在于该怎么办？在一本书中我看到过各种合理化建议(好像是一本如 何管理小公司的书)。人们都很困惑；我也很困惑。你很难在做一个好老板和做一个好人之间选择。 我曾经给一大批保险经纪人做一个讲座。讲座之前，组织者让我和这些经纪人坐在一个圆桌旁讨论公司运营问题。一位女士说她的公司现在正在发展阶段，她 新招聘了一批销售人员去扩大业务。我问她如果6个月后一个销售人员明显没有任何业绩，会炒了他吗？她不加思索的脱口而出，我需要考量一下对我个人的影 响！ 就好象是解雇一个不能干活的人会破坏了她的名声。 我对是否把一些不能干活的人留在身边这种事情思考了很久。这种做法对于其他员工不太公平，同样对客户也不公平。坐一个只有6分的飞行员开的飞 机，你的感觉是怎样？你能放心一个只有6分的护士照看你医院里的老妈妈吗？还有修你的车刹的修理工，负责你的保单内容的保险经纪人等。 有些5分的员工在更换岗位后也许会达到9分(可能就在你的公司里)。如果你真的想经营一个优秀的公司，你必须把合适的人放在合适的位置上。有些人也 许会提问说：你怎么有权利下这些论断 但如果这事牵涉到你，那这不仅是你的权利，而且是你的义务。而且，以我个人一个拥有102名员工的公司的经验，我可以告诉你，如果员工能各司其职，各施所 长，企业经营就变得容易多了。 人们经常问我为什么有时间写这些博客文章。这是因为我有优秀的读者！ 本文转载自: 外刊IT评论http://www.aqee.net/

最近很多网友问我同样的问题，那就是J-Hi与其它的平台类产品有什么区别？它有哪些独特的特点。实际在我看来J-Hi与目前任何其它平台类的产品的出发点或称之为初宗都是相同的，那就是想解决如何使开发更快速、更高效，如何降低项目的成本（不只是快速开发所带来的成本降低，也包括项目的管理成本）。 最近很多网友问我同样的问题，那就是J-Hi与其它的平台类产品有什么区别?它有哪些独特的特点。实际在我看来J-Hi与目前任何其它平台类的产品的出发点或称之为初宗都是相同的，那就是想解决如何使开发更快速、更高效，如何降低项目的成本(不只是快速开发所带来的成本降低，也包括项目的管理成本)。 总的来说，目前市场上的平台类产品所采用的核心技术无非两种，一种是模型驱动(后台有一个模型引擎来负责解析与计算这些业务模型从而得到预期的运算结果);另一种是代码生成(按照定义的模型通过生成器生成全部源文件)。从技术本身来看，这两种技术都不算什么新鲜东西，只是随着计算机运算能力的提高，相关技术的不断成熟，使这两种技术应用于业务开发平台成为可能，因此单纯从技术先进性来看，那我觉得都没有什么在技术可以称道的地方。反之，平台它是多种技术的融合体，尤其是业务开发平台不只包括技术本身还会包含一些通用的业务以及一些开发工具。因为这些的差异，就形成了各类平台产品的差异性。在此让我们来分析一下J-Hi Java快速开发平台自身的特点(即与其它平台的不同之处)： 快速的按需动态搭建 目前平台支持的框架有：webwork、struts2、spring、hibernate、ibatis2、ibatis3，对于这些框架您可以通过可视化(J-HI Studio，eclipse插件)的方式随意组合，通过工程创建向导，自动化的按照你所选择的框架快速的动态搭建起开发工程。我们之所以将J-Hi做成多框架动态搭建，主要是考虑到不同企业的开发团队对技术的倾向性会有很大差别，比如对于ORM有的人就喜欢hibernate，而有的人就觉得hibernate太强硬，喜欢用半自动化的ibatis。J-Hi基于这个目的为开发者提供了更多的可选择性。在此要注意对于平台多框架的集成并不象一般意思上的集成(即几个框架拼接在一起就可以象appfuse一样)，因为平台的集成还要包括很多通用业务并且与数据库表是有关系的(一般搭建多框架是没有业务的所有的东西都要由你亲自去开发，而平台会有很多的业务已经预留在平台中)。举个例子：比如安全管理，这是平台的一个通用业务包括角色、权限等。在切换到不同的框架比如struts或webwork;hibernate或ibatis时，平台的底层要自动的适应这种变化，这是有一定的创新点的J。当然我们以后还会集成更多、更优秀的框架在平台之中，比如SpringMVC，SpringJDBC等等，在数据库端我们也会再多支持一些数据库，当然集成数据库也不是传统意义上的只是一个数据库连接，而是针对不同的数据库差异会做不同的方言，不同的数据库脚本还要有相应的生成模板等等。 因此你会发现快速按需动态搭建，并不是传统意义上的多框架集成那么简单，而是对应每一种框架(数据库)平台都会提供一套完整的解决方案。总之多框架集成对于J-Hi来说，是牵一发而动全身的事情，变动一个框架，包括每一个页面，每一个java类，每一个配置文件都要随之而动态的变化。因此它是系统级的工程而非简单的多个框架拼接。 完整而系统的生成方案 代码生成或生成器这实际上在十年前就已经有的东西，无论是实现原理还是具体的工具都不是新鲜事物。J-Hi之所以将代码生成也算作自己的特色，是因为它的完整性与系统性。从完整性来看，J-Hi的生成是一套含盖从数据库底层一直到页面端全部的解决方案，包括数据库表;权限、菜单、多语言等相关基础数据;java类文件;JSP、js文件;相关配置文件等等，因此保证了生成即可运行，从单元体上来看生成文件是完整的，是可独立运行的。从系统性来看，生成的文件是随着你选择的框架不同而不同的，生成的基础是随着框架与数据库的差异而随需变化，系统的解决了生成器的僵硬性，从而灵活的适应开发环境。因此J-Hi的生成方案是系统的，是适应不同框架与数据库的生成方案的。 平台到底生成了些什么? 组件化 在软件世界里组件这个概念真是千差万别，每个系统与工具软件对组件都有各自不同的定义。尤其在Java世界里更是如此，小的从一个页面元素一直到大的一个业务功能系统，在各自的领域都会给它们定义为组件。按照《计算机百科全书》给组件的定义：是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依赖关系、可独立部署、可组装的软件实体。由此定义我们来谈一下J-Hi Java快速开发平台对组件的理解与解决方案。 实际上说到底无非是对组件颗粒的划分问题，在不同的条件与环境下组件的作用与功能会有很大差异，其次在定义组件时要保证功能的相对独立并且可组装可部署，由此J-Hi将组件根据用途与范围的不同划分为如下四类组件类型：技术组件、实体组件、业务组件、系统组件，它们之间的关系是逐级递进，互为基础的。 在我们在深入探讨之前，先来简单的解释一下上图中各种组件类型之间的关系。比如一个OA系统我们就可以把这理解为一个系统组件，而多个系统组件(仓储系统、人力系统等)可以动态搭建更大的应用系统(ERP)。每个系统组件下会有多个业务组件，例如在OA系统下会有报销单、会议管理等多个业务组件。因为大部分业务组件之间一般都是松藕合的，所业务组件可以无缝的迁移到其它的系统组件中，即实现业务组件可复用性。而在一个业务组件下会有一个或多个实体组件够成，我们还以报销单业务组件为例，在报销单最少会有报销单及报销单明细两个实体组件，一个实体您可以理解成与数据库对应的一张表，实体之间可以继承、一个实体可以有多个子实体。但实体不仅仅是数据库表，它包括从页面到数据库表之间的全部代码实现同时包括CURD所有操作的功能单元。对于实体组件我们会在后面详细讨论。最后是技术组件，在J-Hi中技术组件可以说是一个抽象的概念，一个技术组件就是一个技术功能单元，它可能是一套生成模版，一个框架的支持，一套API(比如对短信、全文检索的支持等) 实体组件：J-Hi将一个实体组件定义为一个集合单元，它不仅仅包括数据库表还包括对该数据库表的基础操作(增、删、查、改);包括前端的展示面页;包括该实体的权限、菜单、配置信息;还包括它与其它实体的交互操作。当然一个实体组件颗粒度还是太小，还不能完整的描述一个业务功能。但实体组件相对来说有一定的独立性，可以集成一个集合单元，J-Hi就是以实体组件为基础实现更大粒度的集成，从而实现对一个完整业务的描述。 业务组件：实际上一个业务组件J-Hi将它对应于一个服务，服务可以认为是一个业务功能模块，用以描述完整的业务模式，具体相对的业务独立性。在服务内代码间是高聚集的，因为一个服务就是一套完整的业务，在设计服务时应尽最大限度的降低服务与服务之间的藕合度。因为在这个样一个理论基础上去设计，就可以实现业务组件无缝的在各系统之间的可移植性。因为组件的定义还要可以独立的组装与部署，因此我们开发平台的附属性产品Hi平台产品集成工具，它主要是由发布器与部署器组成，以更方便的实现业务组件的迁移 开发发布器与部署器的目的就是通过可视化的方式，实现跨数据库数据与跨应用系统的业务组件迁移。可以将业务组件看作一个独立的业务单元，可以无缝的集成于任何以J-Hi平台开发的项目中去。从而真正达到随需组合，动态搭建实际的业务系统，真正的实现业务组件的复用，降低不必要的重复开发。 系统组件：从业务功能上来看系统组件不过是多个业务组件的拼接，更大一级的业务封装。理论上系统组件与系统组件之间应满足绝对的隔离性，即使是有通信，应该也是通过第三方来进行数据交互(常用的解决方式有两种一种是中间数据库;第二种是webservice)。但如果是基于平台开发，这种无谓的工作量可以降低很少，甚至可以不需要第三方的交互技术。只要保证两个系统间的通信接口就要以轻松实现。系统组件的迁移也可以通过发布器与部署器来实现。 技术组件：从技术角度来看，J-Hi与其它的技术组件差别不大。无非是基于平台再开发一些技术组件，比如对 SpringMVC、SpringJDBC、DB2数据库等的支持，页面端也会再集成象DWZ或simpleframework，我们也会再提供更多的页面端的生成模版，以此类推，平台的技术组件会在技术的不同层面进行扩展。但与其它的技术组件不同之处在于，实现类似于插件一样的可插拔，随需织入。 原文地址：http://developer.51cto.com/art/201103/248412.htm

JavaScript 编程语言作为最流行的客户端脚本语言，深受Web开发人员爱戴。JavaScript语法灵活，简单易懂，对代码的格式的要求也相对松散。也正因为如此，JavaScript 的编码规范也往往被轻视，开发过程中修修补补，最终也就演变成为后续维护人员的恶梦。为了此种恶梦不再发生，IBM高级软件工程师王丹丹对JavaScript 编程语言的编码规范进行了总结，现转载于此，供大家学习。全文如下： 对于熟悉C/C++或Java语言的工程师来说，JavaScript显得灵活，简单易懂，对代码的格式的要求也相对松散。很容易学习，并运用到自己的代码中。也正因为这样，JavaScript的编码规范也往往被轻视，开发过程中修修补补，最终也就演变成为后续维护人员的恶梦。软件存在的长期价值直接与编码的质量成比例。编码规范能帮助我们降低编程中不必要的麻烦。而 JavaScript代码是直接发送给客户浏览器的，直接与客户见面，编码的质量更应该受到关注。 本文浅谈JavaScript编程中关于编码规范的问题，分析其中缘由。希望引起更多Web 开发人员对JavaScript编码规范问题的关注和对软件产品质量问题的重视。 前言 提及C/C++和Java编码规范，相信许多工程师并不生疏。但说到 JavaScript 语言的编码规范，也许您会忍俊不禁。JavaScript 不是语法很灵活吗？变量随时用随时可以声明；语句结束符可以不要；字符串和数字也可以相加；参数多一个少一个也不会报错。没错，当您从 C/C++ 和 Java 严格的语法规定之下，转向 JavaScript 语言，会觉得自由了很多，轻松了很多。语法松散是 JavaScript 重要的特征。它灵活易懂，给开发人员带来了很多方便，但如果编写过程中不注意，代码的调试成本和维护成本则会无形地增加。 JavaScript 编码会随应被直接发送到客户端的浏览器，代码规范不只是代码质量的保证，也影响到产品的长期信誉。希望 JavaScript 编程语言的规范问题也能同样引起更多朋友的关注。 JavaScript 编码规范建议 本文就JavaScript 编码过程中涉及的排版、命名、声明、作用域、及一些特殊符号的使用等方面，根据个人在学习工作中的总结，给出自己的一些建议，并分析其中缘由，以供参考。 JavaScript 文件引用 JavaScript 程序应该尽量放在 .js 的文件中，需要调用的时候在 HTML 中以 script src=filename.js 的形式包含进来。JavaScript 代码若不是该 HTML 文件所专用的，则应尽量避免在 HTML 文件中直接编写 JavaScript 代码。因为这样会大大增加 HTML 文件的大小，无益于代码的压缩和缓存的使用。 另外，script src=filename.js 标签应尽量放在文件的后面。这样会降低因加载 JavaScript 代码而影响页面中其它组件的加载时间。 代码排版 行长度 每行代码应小于 80 个字符。如果代码较长，应尽量选择换行，下一行代码应缩进 8 个空格。这样可以使代码排版整齐，减轻阅读代码的疲劳感。换行缩进 8 个空格可以和代码段的缩进 4 个空格区分开，以增强代码的可阅读性。 行结束 JavaScript 语句应该以分号结束。但大多数浏览器允许不写分号，只要在本应是分号的地方有一个换行符就行。但是如果代码行较长需要换行的时候，有哪些注意事项呢？换行应选择在操作符和标点符号之后，最好是在逗号','之后，而不要在变量名、字符串、数字、或')' ']' '++' '--'等符号之后换行。 这样可以有效的防止拷贝、粘贴而引起的错误，并可有效地增强代码的可阅读性。请见清单 1，代码的输出符合我们的期望。但就写法而言，对 valueB 的赋值语句是在变量 valueA 之后进行的换行，这很容易被误解为 valueB=ValueA，给阅读造成障碍。而对 valueC 的复制语句是在'+'之后进行的换行，就容易理解的多。这也是本文所提倡的换行方式。 清单 1. 行结束的位置 script language=javascript var valueA = 1; var valueB = valueA ///bad +1; var valueC = valueB + ///good valueA; alert(valueB); //output: valueB=2 alert(valueC);//output: valueC=3 /script 缩进 关于缩进的问题，不只是 JavaScript，几乎所有的语言编写的时候，都会提及缩进的问题。缩进几乎是代码编写规范的第一课，是代码可阅读性判断的直接因素。 代码缩进的好处是不言而喻的，但是对于如何缩进，则没有标准而言。最受欢迎的是方便使用 TAB 键缩进，也有些喜欢用 2 个、4 个、8 个空格进行缩进。这样缩进风格不一，也同样给代码的阅读带来障碍。 本文提倡用 4 个空格来进行缩进，并在同一产品中采用同一种缩进标准。不支持用 TAB 键进行缩进。这是因为直到现在还没有统一的标准来定义 TAB 键所代替的空白大小，有些编辑器解析为 4 个空格大小，有些则解析为 8 个。因而用不同的编辑器查看代码，可能造成格式混乱。当然 TAB 简单易用，为解决这个问题，建议在设置开发环境时，将编辑器里的 TAB 快捷键重新设置为 4 个空格。据了解 Eclipse, Vi, Nodepad++，Editplus, UltraEdit 等流行的编辑器，均提供了此功能。 注释 代码中的注释很重要，自然也是毋庸置疑的。通常我们会强调代码中注释数量的多少，而轻视了对注释质量的提高。编码是及时添加注释，会给后续代码的维护人员带来很大的便利。但是如果注释不注意更新，或者由于拷贝、粘贴引起的错误的注释，则会误导阅读人员，反而给阅读带来障碍。 除了注释要 及时更新外，我们还应对注释的内容要特别关注。注释要尽量简单、清晰明了，避免使用含混晦涩的语言，同时着重 注释的意义，对不太直观的部分进行注解。请见清单 2。 清单 2. 有意义的注释 script language=javascript //following section is used to initialize golbal variables (good) var valueA = 0; //initialize valueA to be sero (bad) var valueB = 1; ... //call f1 function after waiting for 50 seconds. (good) setTimeout(f1,50000); //set timeout to be 20s (copy error) ... /script 这样的注释方式在 JavaScript 代码中经常见到。initialize valueA to be sero 这样的注释有什么用呢？难道阅读程序的工程师从var valueA = 0;复制语句中看不出来么？set timeout to be 20s这条注释，不只是因拷贝、粘贴引起的时间大小的错误，同时也误导了程序员对这条语句的理解。setTimeout() 函数的作用并非是设置函数执行的超时时间，而是等待一定时间后执行所调用的函数，害人匪浅呀。这样的注释内容宁可删掉。 此外，JavaScript 的注释有两种// 和/* .... */，建议//用作代码行注释，/* .... */形式用作对整个代码段的注销，或较正式的声明中，如函数参数、功能、文件功能等的描述中。 标识符命名 JavaScript 中的标识符的命名规则： 以字母、下划线'_'或美元符号'$'开头 允许名称中包含字母，数字，下划线'_'和美元符号'$' 区分大小写 变量、参数、成员变量、函数等名称均以小写字母开头，构造器的名称以大写字母开头。下划线'_'开头的变量一般习惯于标识私有 / 局部成员。而美元符号'$'开头的变量习惯于标识系统相关，比如系统进程等。应避免用下划线'_'或美元符号'$'来命名标识符。尽可能地降低代码的阅读负担。 声明 变量的声明 尽管 JavaScript 语言并不要求在变量使用前先对变量进行声明。但我们还是应该养成这个好习惯。这样可以比较容易的检测出那些未经声明的变量，避免其变为隐藏的全局变量，造成隐患。 在函数的开始应先用 var 关键字声明函数中要使用的局部变量，注释变量的功能及代表的含义，且应以字母顺序排序。每个变量单独占一行，以便添加注释。这是因为 JavaScript 中只有函数的 {} 表明作用域，用 var 关键字声明的局部变量只在函数内有效，而未经 var 声明的变量则被视为全局变量。我们来看下清单 3。 清单 3. 局部变量声明 script language=javascript var valueA = a; var valueB = b; function f1() { var valueA = c; alert(valueA=+valueA); //output: valueA=c valueB = d; alert(valueB=+valueB); //output: valueB=d } f1(); alert(valueA=+valueA); //output: valueA=a alert(valueB=+valueB); //output: valueB=d /script 从上例的输出惊奇地发现，用 var 声明过的变量 valueA 和没有声明的变量 valueB 是有区别的。特别需要注意的是，在函数内部用 var 声明的变量为局部变量，这样可以有效地避免因局部变量和全局变量同名而产生的错误。 函数的声明 函数也应在调用前进行声明，内部函数应在 var 声明内部变量的语句之后声明，可以清晰地表明内部变量和内部函数的作用域。 此外，函数名紧接左括号'('之间，而右括号')'和后面的'{'之间要有个空格，以清楚地显示函数名以其参数部分，和函数体的开始。若函数为匿名 / 无名函数，则 function 关键字和左括号'('之间要留空格，否则可能误认为该函数的函数名为 function。 清单 4. 内部函数声明 script language=javascript var innerA = 1; function outF() { var innerA = 2; function _inF() { alert(valueA=+innerA); } _inF(); } outF(); //output: valueA=2 _inF(); //error: innerF is not defined /script 从清单 4 的输出可以看出，inF() 函数仅在 outF() 函数的内部生效，局部变量 innerA 对内部函数的作用域生效。这样的编码方式使得变量和函数的作用域变得清晰。 语句 对于简单语句而言，需要提及的仍然是分号必要性，同时，一行最多有一个语句。如果一个赋值语句是用函数和对象来赋值，可能需要跨多行，一定切记要在赋值语句末加上分号。 这是因为 JavaScript 中，所有表达式都可以当语句，遇换行符时会解析为表达式的结束，此时不规范的换行和分号的丢失，可能引入新的错误。 对于复合语句，if, for, while, do, switch, try catch 等代码体，函数定义的函数体，对象的定义等都需要放在花括号'{}'里面。 '{' 应在行末，标志代码块的开始。 '}' 应在一行开头，标志代码块的结束，同时需要和'{'所在行的开始对齐，以表明一个完整的复合语句段。这样可以极大地提高代码的可阅读性，控制逻辑能清晰地表现出来。 被包含的代码段应该再缩进 4 个空格。 即使被包含的代码段只有一句，也应该用花括号'{}'包含。尽管不用花括号代码也不会错，但如若需要增加语句的话，则较容易因花括号遗漏而引起的编译错误或逻辑错误。 return语句在使用时也需慎重，如果用表达式的执行作为返回值，请把表达式和 return 放在同一行中，以免换行符被误解析为语句的结束而引起返回错误。return 关键字后若没有返回表达式，则返回 undefined。构造器的默认返回值为 this。 清单 5. return 表达式 script language=javascript function F1() { var valueA = 1; var valueB = 2; return valueA + valueB; } function F2() { var valueA = 1; var valueB = 2; return valueA + valueB; } alert( F1() ); //output: 3 alert( F2() ); //ouput: undefined /script 在清单 5 中显示了因返回表达式没有和 return 关键字放在同一行而引起的返回错误，需重视。 特殊符号 空白符 适当的空白行可以大大提高代码的可阅读性，可以使代码逻辑更清晰易懂。同时，在表达式中适当的留空白，也会给代码的阅读带来方便。 关键字的后面如有括号，则最好在关键字和左括号'('之间留空白，如 for, if, while 等。而函数名和括号之间则不宜留空白，但若是匿名函数，则必须在 function 和左括号'('之间留空白，否则，编辑器会误认为函数名为 function。 在表达式中，二元运算符 ( 除左括号'('，左方括号'['，作用域点'.') 和两个操作数之间最好留空白。一元运算符（若不是词 typeof 等）和其操作数之间不宜留空白。 逗号','的后面需要留空白，以显示明确的参数间隔，变量间隔等。 分号';'之后通常表明表达语句的结束，而应空行。在 for 的条件语句中，分号之后则应该留空白。 { } 和 [ ] 在 JavaScript 中，如需定义空对象和空数组，通常很自然地想到用 new Object() 和 new Array() 的方法。其实花括号'{}'和方括号'[]'可以直接用来定义一个空对象和一个空数组。这种书写方法可以使代码看起来简单易懂。 == 和 === 判断逻辑等在代码里太平常的不过事情了，但 JavaScript 与其他熟知的编程语言不同的是，除了可以使用两个等号'=='来作判断以为，还可以使用三个等号'==='来进行逻辑等判断。两者的不同是'=='作逻辑等判断时，会先进行类型转换后再进行比较。'==='则不会。因而，'=='进行的判断结果可能产生偏差。'!='与'!=='的区别亦是如此。本文提倡尽量使用'==='来进行逻辑等的判断，用'!=='进行逻辑不等的判断。 清单 6. === 的使用 script language=javascript var valueA = 1; var valueB = 1; if ( valueA == valueB) { alert(Equal); } else { alert(Not equal) } //output: Equal if ( valueA === valueB) { alert(Equal); } else { alert(Not equal) } //output: Not equal /script 清单 6 中，valueA 和 valueB 两个变量的值显然是不相等的，起码 valueA 是个字符串，而 valueB 是一个数字。但用'=='进行判断是，程序却输出相等的字样。这是因为编译器对两个变量进行比较时，因为他们的类型不同，而自动地将 valueB 转换成字符串，而后再和 valueA 进行比较的。用'==='得到的判断结果正和预期的结果相符。 + 加号'+'也同样是程序员所熟知的操作符之一。JavaScript 和其他编程语言不同的是，在 JavaScript 中，'+'除了表示数字值相加，字符串相连接以外，还可以作一元运算符用，把字符串转换为数字。因而如果使用不当，则可能与自增符'++'混淆而引起计算错误。这一点，在清单 7 中可以清楚地看出。 清单 7. 巧用 + 号 script language=javascript var valueA = 20; var valueB = 10; alert( valueA + valueB); //ouput: 2010 alert( valueA + (+valueB)); //output: 30 alert( valueA + +valueB); //output:30 alert( valueA ++valueB); //Compile error /script 总结 本文就 JavaScript 代码的排版、命名、声明、语句、和一些特殊字符的使用等方面，谈了自己对 JavaScript 编程规范的建议。此外，还有许多方面需要深入了解研究，如 with, eval 语句和 this 对象的使用等等。我们在认识其普遍性的同时也需要注意其特殊性，在编写代码时多用心留意，以创造更多更优质的程序代码。 作者简介 王丹丹，IBM 中国系统与技术中心软件工程师，自从 2006 年加入IBM，一直从事 Web 系统设计和开发工作，有五年 PHP 应用程序设计开发经验。 原文链接：http://www.ibm.com/developerworks/cn/web/1008_wangdd_jscodingrule/?ca=drs-tp4608

3月9日消息，据台湾媒体报道，谷歌才刚宣布修正Android应用商店的程序错误，又有研究机构传出这些程序错误可能导致黑客散布恶意软件以控制用户设备的消息。 信息安全公司Duo Security创办人兼首席技术官Jon Oberheide表示，Android应用商店自今年年初发表以来，黑客极有可能透过诈骗的方式，让用户点选恶意链接，接着以远程遥控的方式安装任意程序在受害者的手机里。Jon Oberheide认为在一般网站上相当普遍的XSS漏洞也会出现在智能型手机软件上，由于目前在手机端并无任何确认安装程序的选项，这些程序安装的需求几乎是百分之百被手机所接受，这也让黑客可以在不惊动使用者的状况下安装恶意软件。而这些被安装至受害者手机的恶意软件可以启动任何Android的功能，包括各式各样的犯罪行为。 Jon Oberheide认为谷歌应该建立一个让用户在手机上确认安装软件需求的功能，会比目前远程自动安装的机制来得好。 Google于上周宣布将从Android应用商店移除58个恶意软件并将透过远程控制的方式从已安装的26万台Android设备中移除，就在同时，资安公司Duo Security发表XSS漏洞的消息。 移动安全业者Lookout也发表更多与恶意软件DroidDream相关的讯息，该公司表示，这个恶意软件就像僵尸病毒(zombie agent)一样，会偷偷的安装第二个程序以将设备相关讯息传送至外面的服务器。Lookout发布一个免费的扫描软件供用户检查是否受此恶意软件感染。Lookout也提醒受感染的用户恢复出厂设置并无法完全消灭恶意软件，必须使用谷歌的kill switch工具来完成。 原文链接：http://news.ccidnet.com/art/1032/20110309/2328831_1.html

北京时间3月5日消息，据国外媒体报道，此前曾有消息报道谷歌开发无人驾驶汽车拍摄街景，该消息日前在刚刚召开的2011年度加州科技、娱乐和设计大会(TED Conference)上得到证实，谷歌在大会上宣布，公司即将推出带有自动驾驶功能的汽车。 近日，谷歌爱好者在美国搜索引擎技术网站Search Engine Land播放的一段录像中目睹了这款无人驾驶汽车的芳容，经改装的丰田普锐斯轿车装有谷歌公司研发的导航设备，在一块不大的停车场也能操控自如。 这种无人驾驶汽车所用到的设备包括摄像机、雷达感应器和激光设备等，车载电脑能识别交通灯，识别人行道和障碍物等，并模拟人的智力对相应交通状况做出正确反应。 谷歌在大会上还透露，如果路况很好，公司开发的这款自动驾驶汽车的驾驶速度可以达到每小时40英里（约为64公里），目前已经安全行驶了至少14万英里，在此期间，从未发生过因失控而伤及人畜的事件。 谷歌称，这种无人驾驶的测试车辆即使在路况不佳的太浩湖(Lake Tahoe)蜿蜒曲折的小路上行进也未遇到过麻烦，在太平洋海岸公路(Pacific Coast Highway)上更是自由驰骋。 目前尚不知道这种汽车是否会商业化量产销售，不过可以肯定的是，它可以让汽车爱好者尽享无人驾乘的乐趣.