On Plug-ins and Extensible Architecture
From Software Updates
Vol. 3, No. 2 - March 2005
by Dorian Birsan, Eclipse
In a world of increasingly complex computing requirements, we as software developers are continually searching for that ultimate, universal architecture that allows us to productively develop high-quality applications. This quest has led to the adoption of many new abstractions and tools. Some of the most promising recent developments are the new pure plug-in architectures.
What began as a callback mechanism to extend an application has become the very foundation of applications themselves. Plug-ins are no longer just add-ons to applications; today’s applications are made entirely of plug-ins. This field has matured quite a bit in the past few years, with significant contributions from a number of successful projects.
This article identifies some of the concepts around the foundation of pure plug-in architectures and how they affect various stakeholders when taking a plug-in approach. The intention is to discuss the general issues involved, but the article also presents some lessons learned from Eclipse (www.eclipse.org) to better illustrate some of the concepts.
MOTIVATION FOR PLUG-INS
Customers?requirements control the creation and deployment of software. Customers demand more and better functionality, they want it tailored to their needs, and they want it “yesterday.?Very often, large shops prefer to develop their own in-house add-ons, or tweak and replace existing functions. Nobody wants to reinvent the wheel, but rather to integrate and build on existing work, by writing only the specialized code that differentiates them from their competition. Newer enterprise-class application suites consist of smaller stand-alone products that must be integrated to produce the expected higher-level functions and, at the same time, offer a consistent user experience. The ability to respond quickly to rapid changes in requirements, upgradeability, and support for integrating other vendors?components at any time all create an additional push for flexible and extensible applications.
Down in the trenches, developers must deal with complex infrastructures, tools, and code. The last thing they need is to apply more duct tape to an already complex code base, so that marketing can sell the product with a straight face. The new plug-in architectures are very attractive to developers because they can focus on providing modular functionality to users. Anyone can quickly customize applications by mixing and matching the plug-ins they need, or write new plug-ins for missing functions. The price to pay for such flexibility is managing these plug-ins. We discuss this and other issues later in the article, and you can decide if it is worth the price.TRADITIONAL PLUG-INS VERSUS PURE PLUG-INS
Most people are familiar with traditional plug-ins, downloadable software bundles that extend the functionality of hosting applications such as Web browsers or text and graphical editors. They are not compiled into the application, but linked via well-defined interfaces and extension mechanisms. Most often, building a plug-in does not require access to the source code of the application. Plug-ins implement functions that the host application can recognize and activate when needed.
In the new pure plug-in architectures, everything is a plug-in. The role of the hosting application is reduced to a runtime engine for running plug-ins, with no inherent end-user functionality. Without a directive hosting application, what is left is a universe of federated plug-ins, all playing by the rules of engagement defined by the framework and/or by the plug-ins themselves.
To support composing a larger system that is not prestructured, or to extend it in ways you don’t foresee, the architecture must support the extensibility of plug-ins by plug-ins. In the absence of a hosting application, plug-ins themselves become hosts to other plug-ins by providing well-defined hook points where other plug-ins can add functionality. These hook points are commonly known as extension points. When a plug-in contributes an implementation for an extension point, we say that it adds an extension. Much like defining any contractual obligation, an extension model provides a structured way for plug-ins to describe the ways they can be extended and for client plug-ins to describe the extensions they supply.
In a simplified way, figure 1 illustrates the main structural difference between traditional and pure plug-in architectures.
PLUG-IN RUNTIME CONSIDERATIONS
As already mentioned, plug-ins are not stand-alone programs; their execution is orchestrated by a runtime engine. The plug-in runtime engine—let’s call it the kernel—is the core engine that is started when a user launches an application. At a minimum, the kernel must provide runtime support for the basic plug-in infrastructure by:
- Finding, loading, and running the right plug-in code.
- Maintaining a registry of installed plug-ins and the functions they provide.
- Managing the plug-in extension model and inter-plug-in dependencies.
Optionally, the kernel can supply other utility services, such as logging, tracing, or security. The user should also be able to turn off or remove parts of the application, or dynamically install new functions. For obvious reasons, it is desirable for the kernel to be small and simple, yet robust enough to build industrial-strength functionality on top of it, without many (or any) hacks.
To illustrate the basic workings of a plug-in environment, let’s take a behind-the-scenes look at the Eclipse plug-in runtime structure and control flow. While mostly known as a powerful Java integrated development environment, Eclipse is actually a universal plug-in architecture for creating “anything, but nothing in particular.?The runtime engine itself is implemented as a number of core plug-ins, except for a tiny bootstrap code. This code starts the core plug-ins to initialize the plug-in registry and the extension model and to resolve plug-in dependencies. Other than the core plug-ins, no other plug-in code is run at this time. All the needed plug-in metadata is read from the plug-in manifest files (plugin.xml and/or manifest.mf).
Once the initialization is complete, the runtime kernel is ready to run applications. The extension mechanism, shown in figure 2, kicks in and an entire application is built progressively, from inside out, as follows:
- The runtime core plug-in defines an applications extension point so that any plug-in can declare itself an application by contributing an extension to it.
- An applications extension must provide a concrete implementation for the extension point’s callback interface, IPlatformRunnable.
- Eclipse’s default applications extension is contributed by the IDE plug-in, by providing a concrete implementation class that, when called by the extension point handling code, creates the workbench graphical user interface and runs the event loop until it exits.
This workbench window looks like any standard application: it has menus, toolbars, views, and editors, and you can launch wizards, open preference dialogs, and so on. The basic workbench by itself, however, is just a frame for displaying visual parts and other user interface elements. Its power comes from the extension points (e.g., views, wizards, editors, action sets, help support) it defines, to which other plug-ins, or the workbench plug-in itself, can contribute extensions.
In general, the plug-in that defines an extension point is responsible for looking up its extenders (using the extension registry), instantiating the associated callback class, and invoking the appropriate interface methods. Under the covers, the runtime kernel is responsible for providing the extension registry lookup functionality, creating a class loader for the extender plug-in, loading it, and starting it. This ensures the extender plug-in is initialized and active before its classes are created and run.
Finally, it is worth noting that some extension points may require more than one callback interface and others do not require any. For example, the help system extension point toc is used for contributing documentation tables of contents and does not require any callbacks. When help is invoked, the help plug-in processes the toc extensions by creating a larger, integrated table of contents from all contributing plug-ins.
CONFIGURING AND DISCOVERING PLUG-INS
An important consideration when deploying a plug-in system is configuring and discovering the plug-ins. Unlike monolithic applications that are typically installed in one folder on a user’s machine, plug-in-based applications may have a higher degree of freedom for installation layout and plug-in discovery. This flexibility can also be a source of major headaches for installers and plug-in management.
Consider a multiuser shared installation where the entire product is installed by the central administrator on behalf of a community of users. The individual users do not need to perform any installation. They are simply given a local “shortcut?to invoke the shared installation (the shortcut can be in the form of a command-line invocation or a true desktop shortcut encapsulating the command-line invocation). If you’re like most users, you will want to install some other cool new features, especially when the third-party plug-in offerings are plentiful (and often free). Obviously, the new plug-ins, private to that user, cannot be installed in the read-only, shared install location, so the product should allow users to install and configure extra plug-ins in a location where they have more privileges.
Configuring only a subset of plug-ins for a particular user based on access criteria, such as user roles, adds more challenges. Other configuration issues arise in scenarios where a common set of plug-ins is shared by many applications running on the same machine, or where some plug-ins are not installed locally but run from a remote location (e.g., an application server provider).
In theory, the platform must find the available plug-ins on its own and gracefully cope with missing plug-ins or those that are dynamically coming and going. In practice, many solutions for these problems involve predefined files and directory locations for key configuration files or for the plug-ins themselves. More advanced plug-in systems offer pluggable configuration and plug-in discovery mechanisms. Usually some basic bootstrap code is run to start a configurator plug-in, which will then discover the other plug-ins based on its own strategy. For example, Eclipse provides an Update Manager configurator plug-in that picks up plug-ins from the eclipse/plugins folder, as well as from other local plug-in folders linked from the eclipse/links folder or dynamically added when users install new plug-ins to locations of their choice. Because the configurator is pluggable, anyone can plug in another configurator, which can provision and configure the plug-ins from a remote server.
CHALLENGING ISSUES
Pressured by time, budgets, or slick marketing claims, you may be tempted to adopt a pure plug-in architecture without being aware of its potential pitfalls. Alternatively, you might truly believe in Murphy’s law and therefore won’t use plug-ins because they’re doomed to fail, anyway. I tend to follow those who walk the middle road: if something can fail, then it first should be understood and then fixed. The rest of the article presents issues that are likely to pose some challenges when you employ plug-ins, and that will help you ask questions or provide answers when evaluating a plug-in architecture.
Installing and updating.Many modern products automatically detect when they are out of date with respect to available service or product version. Either on start-up, or as a result of an explicit update action, the products compare the current installation level against some network-based baseline. The product then automatically downloads required fixes or upgrades and applies them, often as part of the product execution. Additionally, users can, and most often will, install additional plug-ins from various sources to extend the functionality provided by their current application.
For plug-in-based applications, the installation and update process can be a real nightmare: on the one hand, there are the traditional installation issues that arise in any application—ability to roll back changes, migrate existing program data and preferences, or ensure the installation is not corrupted. On the other hand, because plug-ins may originate from various providers that are not related to each other, the resulting configuration has likely never been tested. This poses a number of interesting challenges that we address in the context of the other issues discussed in the next sections.
Security.Systems can never be too secure, and you need to pay particular attention to securing a system based on plug-ins. Since arbitrary plug-ins can be installed—for example, by downloading them from the Web—and are allowed unlimited access to the system they plug into, security in a plug-in environment must be carefully planned. On top of this, some plug-ins require support for executing custom install code during installation, so they can have control over some parts of their installation. To prevent software security accidents or failures, the plug-in framework must address the issues of downloading from third parties and controlling a plug-in’s access to other code and data. Supporting digitally signed plug-ins or secure connections helps, but it still relies on trusting the download source or the plug-in provider. Some programming environments, such as Java, offer built-in runtime security mechanisms that can be used effectively to close some of the security gaps.
The cold reality is that, unless you are careful about what you install, it is almost impossible to be confident that the installed plug-ins are not ill-intentioned. Of course, a pure plug-in architecture also means that even a well-intentioned plug-in with serious bugs can do as much damage as an ill-intentioned one when installed.
Concurrent plug-in version support. Without a doubt, managing concurrent plug-in versions and dependencies is one of those problems that can keep architects, developers, and installation folks awake at night. Most of you have probably experienced “DLL hell?at some point and will look with suspicion on something that has the potential of being a “plug-in hell.?
Any serious plug-in model defines some versioning scheme, but allowing multiple versions of a plug-in to be concurrently installed and executed is an issue that must be considered early on in the design, and it must be properly enforced by the install and update processes.
To illustrate the complexity of this area, let’s start by considering the scenario of an application suite that integrates two stand-alone plug-in products, each installed in a separate location. It is possible to have the same plug-in, at the same version or at different versions, installed in two locations. The runtime kernel must deal with the two plug-in instances by either running them both or dropping one. When both versions are running, and the plug-ins contribute user interface elements such as menus or preference pages, the result may be a very confusing interface, with duplicate menu entries or preference pages. There is more trouble: would the user need to be exposed to this anomaly? How would you update or uninstall these plug-ins?
The difficulty of the problem is amplified by the other important role plug-in versions play here: they are part of plug-in dependency specifications. Typically, a plug-in requires the functionality provided by other plug-ins, and very often there are strict criteria about what versions are required. For example, a plug-in may require a certain level of an XML parser contributed by another plug-in, or it may need to contribute an extension to a particular version of an extension point only. Version dependency can be in the form of a fixed version number such as 3.0.1, or as a range of versions—say, 3.0.1 or newer. Properly resolving plug-in dependencies at runtime is critical to the correct functioning of the application. Managing plug-in dependency graphs is also critical to ensure a consistent configuration state after installing or updating plug-ins, as well as for properly rolling back changes. The install/update process may need to abort installation of plug-ins that leads to an unresolved dependency, or search for and install the missing plug-ins. Either way, it is possible to end up with multiple versions of the same plug-in, so we’re back to the problem of managing concurrent versions.
There is no simple, general solution to managing concurrent versions of plug-ins. Eclipse has adopted a reasonable trade-off convention for concurrent plug-in versions: only versions of plug-ins that contribute code libraries but no plug-in extensions (no user interface contributions, no documentation, and so on) are allowed to coexist in the same runtime instance. For all the other plug-ins, the latest version is usually picked up, unless a configuration file precisely defines what to run. The main advantage of this approach is that it still allows various levels of the same code to coexist at runtime, but hidden to the end users, who will get a consistent user interface. The downside is that this will not cover all user scenarios, and that plug-ins are not treated uniformly as elsewhere in Eclipse. This special treatment of plug-ins is not just a runtime/install issue, but also something that developers and product packagers must consider.
Scalability, up and down. Another challenge of working with plug-in architectures is scalability. Just as the problems associated with multiple versions and dependencies can quickly escalate, so too can the sheer number of interacting plug-ins quickly become a problem. For example, when Eclipse was first designed, it was thought that a product, a large one for that matter, would consist of a few hundred plug-ins. A few releases later, some enterprise-class products built on Eclipse are known to have passed the thousand plug-in mark, so the platform goal has been revisited to support scaling between 5,000 and10,000 plug-ins.
When designing a plug-in system for scalability, developers must consider various mechanisms that make start-up faster and have a smaller memory footprint. A general principle of runtime is that the end user should not pay a memory or performance penalty for plug-ins that are installed but not used. A plug-in can be installed and added to the registry, but the plug-in will not be activated unless a function provided by the plug-in has been requested according to the user’s activity. In general, this requires support for plug-in declarative functionality. It is often realized in practice via plug-in manifest files, so no code has to be loaded for obtaining the function contributed by plug-ins. Caching of the plug-in registry and the plug-in manifests/declarations can reduce processing during start-up in subsequent application launches, improving response time. What is gained in performance and memory footprint, however, is lost in code complexity: more code needs to be written to cache the data and to synchronize the cache with changes in the installation configuration.
Scalability problems almost always surface during plug-in install/update operations. The larger the product, the larger the download size of patches and upgrades. For product upgrades, the download time can be improved by simply downloading only the plug-ins that changed. Another installation scalability problem can arise during an interactive install/update operation. Quite often plug-in boundaries are established for development reasons (such as function reuse) and present the wrong level of granularity in terms of what the user sees as the unit of function, and therefore as an installation unit. Considering that enterprise-level applications can scale up to hundreds and thousands of plug-ins, with complex dependencies, the user can be overwhelmed by various installation choices. A possible solution is to introduce a packaging and installation component that groups a number of plug-ins to offer a higher level of function. For example, in Eclipse, Update Manager does not install plug-ins directly; it processes features. Features are bundles of plug-ins and are considered deployment units with install/update semantics.
The other side of scalability is scaling down, so products can run on devices with limited resources, such as cellphones and PDAs. This usually means rethinking the core framework plug-ins to refactor them into smaller plug-ins, some of them optionally deployable, so that one can run with a minimal configuration.
OVERCOMING THE BUMPS
General discussion about plug-in architecture and design issues may not mean much for you or your company’s bottom line unless you’re a participant or plan to be one—either by creating a plug-in framework or developing plug-ins for fun and profit, or by using a plug-in-based application. Employing a plug-in framework is not without bumps, but they can be overcome with proper preparation.
While traditional plug-ins have been around for some time, the pure plug-in models have only recently emerged as robust, enterprise-level quality application development environments. As many major industry players are rapidly adopting plug-in technologies for their software lines, we can expect further research and development into improving the current architectures. Some of the areas that will receive increased focus will be:
?Security at all levels, including installation, update, and runtime.
?Performance: speed and low resource usage.
?Improved tools for development, testing, packaging, and deployment of plug-ins.
?Improved installation and updates, especially by merging changes without taking the system down.
?Remote management of various processes (provisioning, configuration, and so on).
?Convergence, compatibility, or interoperability of various plug-in frameworks.
?Wider range of deployment platforms (from desktop PCs and high-end servers to digital mobile phones and embedded devices).
Increasingly, much of this effort will be happening in the open source domain or standards bodies.
| DORIAN BIRSAN has been working at the IBM Toronto Labs for almost 10 years, leading a range of technical projects on application development tools and writing a number of patents in the field. He has played an active role in Eclipse since its inception, leading the user assistance and the update/install teams. Mathematician at heart, turned computer scientist, and later husband and father, he holds a B.Math. in computer science and combinatorics and optimization from the University of Waterloo, as well as an M.Sc. in computer science from the University of British Columbia, where he was a National Science and Engineering Research Council of Canada Fellow. |
Back to On Plug-ins and Extensible Architectures
|
|
]]>
http://www.cer.net 2003-04-07
11:36人民|?/a> |
作者：韩冰 |
g读MBAQ到底选洋的还是土的？北大国际MBA招生办主d黎说Q如果申请h希望未来成ؓ“国际h”，l济实力又比较强Q首选当然还是美国和Ƨ洲的名 校，像美国《商业周刊》评选的商学院。美国的商学院已l有癑ֹ历史Q其办学质量、师资、学生的素质和学院的理都不是国内商学院现在p比的。但国内商学 院的Z已经来了Q从2000qv受经媄响，国商学院学生的׃情况不好Q国际学生就业就更差Q连哈佛商学院毕业的国际学生在美都难d作。据可靠? 息，目前国的顶U商学院Q像芝加哥大学、沃商学院对国际学生的名额和助学金都做了严格限Ӟ目的是减国际学生，保证本国学生的就业，以保住在《商? 周刊》等排行榜上的地位。这也与今年哈佛商学院的中国毕业生全部回国，芝加哥大学等些一商学院的一批中国毕业生回国׃互ؓ例证?/p>
从投入出比看，上哈佛共需p10万美元。二商学院也要6?万美元，在美国的中国学生一般都会贷ƾ求学。而国际学生毕业后׃面窄Q还受到q贷的压力，D他们不去生型企业，只能去跨国公怸的咨询公司和金融公司Q这些公司目前提供的职位Ҏ不能满需求?br>
如果选择回国创业Q就需要对中国文化、风土h情都很了解。中国经发展如此迅速，在国??q_回国后很N上适应。所以创业这条\是艰隄路?br>
如果选择国内商学院，常规MBA一般需p10?2万元Q合1.5万美元。职班的Z不用辞职Q利用业余时间上译ְ行，投入更。从׃看，国
MBA虽然在跨国公司的职位竞争上不占优势，但在民营、国企大公司的就业机会就很多。另外，跨国公司人才本土化的q程也推动了国MBA的就业?br>
如果选择国内商学院，当然选一的为好。目前中Ƨ国际工商学院、北大国际MBA、北大光华管理学院、清华经学院、长江商学院都是公认的一商学院Q各有特炏V?br>
作ؓ甌人，可从三方面选择Q?br>
一是选择什么样的学生群?是来自外企圈q是来自国企?Q?br>
二是选择什么样的老师(是来自美国还是来自欧z?Q?br>
三是评(是否有学习方向，是否有本土案?。徏议申请h报名前先到自׃意的商学院进行实地考察Q到译֠试听之后再决定?br>
]]>
| http://www.cer.net2003-01-03
14:06新华|?/a> |
作者：姜帆 王攀 |
要读MBAQ对不同需求的考生来说Q选择也应是不一L。目前，在国内读MBAQ有5U可供选择的模式?/p>
W一U：参加全国联考，辑ֈ教育部和报考学校的分数U后入学。毕业颁发教育部承认的硕士学位和学历证书。这U考试要考高{数学和U性代敎ͼ考生 比较辛苦Q但学费相对低廉Q对工作l验的要求不是很严格。这U类型一般还分ؓ春季?׃)、秋季班(在职)和经贸班(有学历无学位){几U?/p>
W二U：各个学校l织的培训性质的工商管理教Ԍ入学不需要经q全国联考，学费较高Q但形式多样。包括EMBA(高理人员?、EDP(? 层经理培训课E?、MBA评研修班、短期培训班、论?以报告会形式展开){。后4U都没有考试Q不需推荐Q没有学位，对入学者工作经验的要求不严?/p>
W三U：中外合作办学Q毕业后发教育部认可的国外商学院的学位和文凭。北大、清华、复旦、南京大学、中山大学等都有此种形式Q其中最有名的是? 大中国经研I中心和国26所商学院合办的目。特Ҏp和工作经验要求较高，不考数学，可脱产或在职学习。理Z_学位在中两地都有效Q但学费 之高令h咋舌Q而且q是元?/p>
W四U：来自世界各地的大学来华办的从学士(BBA)到博?DBA)的各U工商管理的教育评。有名校的，也有一般的学校Q但无一例外Q国安不承认其学历学位?/p>
W五U：中欧工商理学院。该校的办学质量有很好的口碑Q毕业生很受企业青睐Q遗憄是学贚w常昂贵，国家q不承认学位。有人戏Uͼ“中Ƨ是那些p_好，p够多Q但又去不了哈佛的h的最好选择。?/p>
参加全国联考，是最为普遍的一U模式。根据教育部的规定，MBA联考报考h员必LQ研I生毕业后有2q以上工作经验者；大学本科毕业后有3q? 以上工作l验者；大专毕业后有5q以上工作经验者；q龄一般不过40周岁。各招生院校可在教育部规定的报考条件基上规定本校报考条件。MBA联考的U? 目ؓQ英语、数学、管理、语文与逻辑、政沅R前4Uؓl一命题Q每q上半年教育部MBA联考指导委员会公布ơ年考试大纲及核定教材，政治理论评各招生院 校单独命题、批南联考各U的内容每年都有所变化Q总趋势是向实跉|，l合性，灉|性的方向倾斜。死记硬背的概念、定义类的内容会逐渐减少Q而着重点考察 考生的理解能力、综合分析解决问题能力?/p>
联考分数达到报考院校的分数U后Q再通过录取评审委员会对甌材料的评价以及差额面试，考生才能入学?/p>
一些专业h士认为，目前的联考制度有待改q。在联考中考了高分的学生未必就有管理能力，而相当一部分有管理经验和理潜力的学生因为在分数U以 下就只能和MBA擦肩而过。南京大学MBA中心的桑U南MQ_“既要兼儡会公qI又要选拔具备理才能q种不可量化的资质的人才QMBA联考就成了? N择下不理想但不得不为的解决Ҏ。?br>
]]>
提问的智?/h1>
作者：
Eric Steven Raymond
Rick Moen
版权 © 2001 Eric S. Raymond
| 修订历史 | ||
|---|---|---|
| 修订?3.1 | 2004q?0?8?br> | esr |
| 文档‘Google 是你的朋友！? | ||
| 修订?3.0 | 2004q???br> | esr |
| 主要增加|页论坛应有的礼节内? | ||
译Q王?<yafrk@yahoo.com >
旉Q?004q?1??/div>
译文: 捷克?/a>
业w?/a>
爱沙?
亚语 法语 徯 希伯来语 匈牙利语 意大利语 日语 ?
兰语 俄语 西班牙语 瑞典?/a>
?
耛_?/a>.
如果你想复制、镜像、翻译或引用本文Q请参阅我的 复制ȝ.
许多目的网站在 如何取得帮助的部分链接了本文Q这没有关系Q也是我们想要的。但如果你是该项目生成此链接的网，请在链接附近显著位置注明?span style="font-style: italic;">我们不是此项目的服务部！?/span>
我们已经遭受没有此说明带来的痛苦Q不断受C些白痴的骚扰。他们认为既然我们发表了此文Q那么我们就有责任解决世上所有技术问题！
如果你因为需要帮助阅M本文Q然后带着可以直接从作者那取得帮助的印象离开Q你׃q成了那些白痴之一。不要向我们提问Q我们不会理? 的? 我们在这只是l你说明如何从那些真正懂得你软硬仉题的人那里取得帮助的ҎQ?9%的时间我们不会是那些人。除非你信此文作者是你遇到问题方面的? Ӟ 请不要打扎ͼq样大家都更开心一炏V?/p>
?黑客 的世界，你所提技术问题的回答很大E度上取决于你提问的方式与解x问题的难度，本文教你如何提问才更有可能得到满意的答复?/p>
开源程序的使用已经很广Q你通常可以从其它更有经验的用户而不是黑客那里得到回{。这是好事，他们一般对新手常有的毛病更容忍一炏V然，使用我们 ? l的Ҏ象对待黑客那样对待这些有l验的用P通常能最有效地得到问题的解答?/p>
W一仉要明白的事是黑客喜欢N和激发思考的好问题。假如不是这P我们也不会写本文了。如果你能提Z个有的问题让我们咀嚼玩呻I我们会感Ȁ 你? 好的 问题是种Ȁ׃C物Q帮助我们发展认知，揭示没有注意或想q的问题。在黑客中，“好问题Q”是非常真挚的赞许?/p>
除此而外Q黑客有遇到单问题就表现出敌视或傲慢的名壎ͼ有时候我们看hq对新手和愚蠢的家伙有条件反 式的无C|但ƈ不真正是q样?/p>
我们只是毫无歉意地敌视那些提问前 不愿思考、不做自p做之事的人。这Uhp旉无底z──他们只知道获取，不愿意付出，他们费了时_q些旉本可用于其它更值得回答的h? 更有? 的问题。我们将q种人叫做“失败?(loser)?(׃历史原因Q我们有时将“loser”拼为“lusers")
我们注意到许多h只想用我们写的YӞ他们对学习技术细节没有兴。对大多Ch而言Q计机只是U工P是种辑ֈ目的的手Dc他们要生活q且有更? 紧的事要做，我们承认q点Q也从不指望每个人都对这些让我们着qL技术问题感兴趣。不q，我们回答问题的风格是Z适应那些真正Ҏ有兴ƈ愿意d参与 问题解决? 人，q一点不会变Q也不该变。如果这都变了，我们׃在自p做得最好的事情上不再那么犀利?br>
我们(多数)是自愿者，从自q忙的生活中抽旉来回{问题，有时会力不从心。因此，我们会无情地滤除问题Q特别是那些看v来象是失败者的Q以 便更有效地把回答问题的时间留l那些“胜利者?/p>
如果你认U态度 令h憎恶、以施惠者自居或傲慢自大Q请查你的假设，我们q未要求你屈服──事实上，假如你做了该做的努力使之成ؓ可能Q我们中? 大多Ch非常乐意q等C你交ƈƢ迎你接Ux们的文化。试囑֎帮助那些不愿自救的hҎ们简直没有效率，不懂没有关系Q但愚蠢地行事不行?/p>
所以，你不必在技术上很在行才能吸引我们的注意Q但?span style="font-weight: bold; font-style: italic;">必须表现引导你在行的姿态──? 敏、思考、善于观察、乐于主动参与问题的解决。如果你 做不到这些你与众不同的事情Q我们徏议你付钱跟别人签商业服务合同Q而不是要求黑客无偿帮助?/p>
如果你决定向我们求助Q你不会xZ名失败者，你也不想被看成一个失败者。得到快速有效回复的最好方法是使提问者看h象个聪明、自 信的人，q且暗示只是y在某一特别问题上需要帮助?/p>
(Ƣ迎Ҏ文指正，可以徏议发?esr@thyrsus.com ? h意，本文不想成ؓ一般性的 |络CgA 指南Q我一般会拒绝那些与引出技术论坛中有用的回复不特别相关的徏?
在通过电子邮g、新ȝ或网论坛提技术问题之前，做以下事情：
-
试搜烦互联|以扑ֈ{案
-
试阅读手册以找到答?/p>
-
试阅读FAQ(常见问题)文档以找到答?/p>
-
试自己查或试验? 扑ֈ{案
-
试h懂行的朋友以扑ֈ{案
-
如果你是E序员，试阅读源代码以扑ֈ{案
提问Ӟ请先表述你已l做了上qC情，q将有助于徏立你不是寄生虫与费别h旉的印象。最好再表述你从?span style="font-weight: bold; font-style: italic;">学到的东?/span>Q我们喜? 回答那些表现从答案中学习的h?/p>
使用某些{略Q比如用Google搜烦你遇到的错误提示(既搜索网也查查讨论l?Q可能就直接扑ֈ了解决问题的文档或邮件列表线索。即使没有结 果，在电子邮件或新闻l张贴问题时提一句“我在Google中查q下列句子但没有扑ֈ什么有用的东西”也是g好事?/p>
准备你的问题Q彻底地思考。轻率的提问只能得到ȝ的回{，或者压Ҏ有。在提问Ӟ是表现出做q思考ƈ在努力解 决问题，你越有可能得? 实际帮助?/p>
注意别提错问题。如果提问基于错误的假设Q某黑客多半会一Ҏ”愚蠢的问题……“，一边用按照问题字面的无用答案回复你Qƈ且希望这U只 是得? ? 面回{而不是真正所需的经历给你一个教训?/p>
永远不要假设?span style="font-weight: bold; font-style: italic;">有资?/span>? 到解{。你没有q种资格Q毕竟你没有为此服务付费。如果你能够提出有内宏V有和Ȁ励思考的问题──那种毫无疑问能够向社 A献经验而不仅仅是消极地要求从别人那获取知识的问题，你将“挣到”答案?/p>
另一斚wQ表明你能够也乐意参与问题的解决是个很好的开端。“有没有 指个方向Q”、“我q还漏点什么？”、“我应该查哪些网站？”通常要比 “请l出我可以用的完整步骤”更Ҏ得到回复Q因Z表明了只要有指个方向你就很乐意完成剩下的q程?/p>
要对在哪提问留心Q如果你做了? qC情，多半会被一W勾销或被看成“失败者”：
-
张脓与论坛主题完全无关的问题
-
在面向高U技术问题的论坛上提非常 初浅的问题，或者反之?/p>
-
在太多不同的新闻l同时交叉张?/p>
-
l既非熟Z没有义务解决你问题的个h张脓你私人的电子邮g
Z护通信的渠道不被无 关的东西ҎQ黑客会除掉那些没有扑֯地方的问题，你不会想有这U经历的?/p>
所以第一步是扑֯论坛QGoogle与其它搜索引擎还是你的朋友，可以用它们搜索与你遇到困隄软硬仉题最相关的项目的|站。那 里通常都有目的FAQ列表、邮件列表及其文档的链接。如果你的努?包括阅读FAQ)都没有结果，q些邮g列表是最后能取得帮助 的地斏V项目的|站也许q有报告臭虫的流E或链接Q如果是q样Q去看看?/p>
向陌生的人或论坛发送邮件极有可能是在冒险。譬如，不要假设一个富含信息的|页的编写者想充当你的免费NQ不要对? 的问题是否会受到Ƣ迎做乐 观的 估计──如果? 不确定，向别处发或者根本别发?/p>
在选择|页论坛、新ȝ或邮件列表时Q不要太怿名字Q先看看FAQ或者许可书以明你的问? 是否与其主题相关。张贴前先翻d有的? 子可 ? 帮助你感受一下那里行事的方式。事实上Q张贴之前在新闻l或邮g列表中搜索与你问题相关的关键词是个很好的LQ也许就扑ֈ{案了。即使没有，也能帮助? 整理 ? 更好的问题?/p>
别象机关枪似的一ơ性“扫”所有的帮助? 道，那就象大嚷大叫ƈ使h不快。一个一个地来?br>
弄清楚你的主题！最典型的错误之一是在某种致立于跨Unix和Windowsq_的语a、库或工L论坛中提关于操作pȝE序接口的问题。如果你? 明白Z么这是大错，最好在搞清楚概念前什么也别问?/p>
一般来_在仔l挑选的公共论坛中提问比在私有论坛中提同L问题更容易得到有用的回复。有许多理由支持q一点，一是看潜在的回复者有多少Q二是看 ? 坛的参与者有多少Q黑客更愿回{能启发多数人的问题?br>
可以理解Q老练的黑客和一些流行Y件的作者正在收到超Z们承受能力的不当消息。就象那根多出来可以压垮骆D的稻草一P你的 加入也可能会使情况走向极端──已经好几ơ了Q一些流行Y件的作者退Z对其软g的支持，因ؓ伴随而来的涌向其Uh邮箱的大量无用消息变得无? 忍受?/p>
本地的用Ll或者你所用的Linux发行版也许正在宣传新手取得帮助的|页论坛或IRC(互联|中l聊? (在非p国家Q新手论坛很可能q是邮g列表)Q这? ? ? 是开始提问的好去处，其是当你觉得遇到的也许只是相对单或者一般的问题时。经q宣传的IRC通道是个公开邀h问的地方Q通常可以得到实时的回复?/p>
事实上，如果出问题的E序来自某发行版(q很常见)Q在E序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问，(否则)目的黑客可能仅?
回复“用我们?/span>代码?/p>
在Q何网论坛张贴之前，先看看是否有搜烦功能。如果有Q就试试用问题的几个关键词搜索一下，也许有帮助。如果在此之前你已做q全面的|页搜烦
(你应该这样做)Q还是再搜烦一下论坛，搜烦引擎最q也许还没有索引此论坛的全部内容?/p>
通过|页论坛或IRC频道提供目的用h持有增长的趋势，电子邮g交流则更多地为项目开发保留。先在网论坛或IRC中寻求与目相关的帮
助?/p>
当某目存在开发者邮件列表时Q即使你信谁能最好地回答问题Q也要向列表而不是其中的个体提问。检查项目的文档和主，扑ֈ目的邮件列表ƈ? 用它。采用这U策略有几个好理由：
-
M向单个开发者提的够好的问题也对整个目l有益。相反，如果你认q问题Ҏ个项目组来说太愚蠢，q也不能成ؓ打扰 单个开发者的理由?/p>
-
向列表提问可以^衡开发者的负担Q单个开发?特别是项目领?也许太忙以至于无法回{你的问题?/p>
-
大多数邮件列表有历史文档q被搜烦引擎索引Q其它h可以通过|页搜烦扑ֈ你的问题和答案而不用再ơ在邮g列表中发问?/p>
-
如果某些问题l常被问刎ͼ开发者可以利用此信息改进文档或Y件本w以使其更清楚。如果只是私下提问，没有h能看到最常见问题的完? 场景?/p>
如果一个项目既有“用户”也有“开发者?或“黑客?邮g列表或网论坛，而你又不摆弄那些代码Q向“用户”列表或论坛提问。不要假设自己在开? 者列表中会受? q，那些人多半会遭受你的噪音q扰?/p>
然尔Q如果你信你的问题不一般，而且在“用户? 列表或论坛中几天都没有回复，可以试试“开发者”列表或论坛。徏议你在张贴前最好先暗暗地观察几? 以了解那的行事方?事实上这是参与Q何私有或半私有列表的好主?
如果你找不到一个项目的邮g列表Q而只能查到项目维护者的地址Q只向其发信。即便在q种情况下，也别假设(目)邮g列表不存在。在你的电子? 件中陈述你已 l试q但没有扑ֈ合适的邮g列表Q也提及你不反对自q邮g转发l他?许多为，即没什么秘密，Uh电子邮g也不应该被公开。通过允许你的电? 邮g ? 发他人给 了相应h员处|你邮g的选择)?br>
在邮件列表、新ȝ或网论坛中Q主题是你在五十个或更少的字W以内吸引有资格的专家注意的黄金ZQ不要用诸如“请帮我?更别提大写的“请? 我！Q！Q”，q种主题的消息会被条件反式地删?之类的唠叨浪Ҏ会。不要用你痛苦的深度来打动我们，相反Q要在这点空间中使用明扼要的问题 描述?/p>
使用主题的好惯例是“对象──偏差?式的描述)Q许多技术支持组l就是这样做的。在“对象”部分指明是哪一个或哪一l东西有问题Q在“偏差”部? 则描qC期望 ? Z一致的地方?/p>
愚蠢Q?/span>-
-
救命啊！我的W记本视频工作不正常Q?/p>
明智Q?/span>
-
XFree86 4.1扭曲鼠标光标Q某昑֍MV1005型号的芯片组
更明智：
-
使用某显卡MV1005型号芯片l的XFree86 4.1的鼠标光标被扭曲
~写“对象──偏差”式描述的过E有助于你更具体地组l你的问题。是什么被影响了？仅仅是鼠标光标或者还有其它图形？只在XFree86中出玎ͼ? 只是在其4.1版中Q是针对某显卡？或者只是其MV1005型号的芯片组Q一个黑客只需描一眼就能够立即明白什么是你遇到的问题Q什么是你自q问题?/p>
更一般地Q想象一下在只显CZ题的文档索引中查找。让你的主题更好地反映问题，可以使下一个搜索类似问题的够在文档中直接找到答案的U烦而不? 再次张脓提问?/p>
如果你想在回复中提问Q确保改变主题以表明你是在问一个问题，一个主题象“re: 试”或“re: 新臭虫”的消息不太可能引v_的注意。同 Ӟ回复中与新主题不甚相关的引用内容尽量删?/p>
对于列表消息Q不要直接点d?按钮)来开始一个新的线索，q将限制你的观众。有些邮仉ȝ序，比如muttQ允许用hU烦排序q过折叠U? 索来隐藏消息Q? q样做的人永q看不到你发的消息?/p>
仅仅改变主题q不够。mutt和其它邮仉ȝ序还要检查主题以外的其它邮g头信息，以便为其指定U烦Q所以宁可发一 个全 新的邮g?/p>
在网论坛，因ؓ消息与特定的U烦紧密l合q且通常在线索之外不可见Q好的提问方式略有不同，通过回复提问q不要紧(一些论坛甚至不允许? 回复中出现分ȝ主题Q而且q样做了基本上没有h会去?。不q通过回复提问本n是令h怀疑的做法Q因为它们只会被正在查看? U烦的hd。所以，除非你只惛_该线索当前活跃的人群中提问，q是另v炉灶比较好?/p>
以“请向……回复”来l束问题多半会你得不到回答。如果你觉得花几U钟在邮件客L讄一下回复地址都麻烦，我们也觉得花几秒? 考虑你的问题更麻烦。如果你的邮件客LE序不支持这样做Q换个好点的。如果是操作pȝ不支持所有这U邮件客LE序Q也换个好点的?/p>
在网论坛，要求通过电子邮g回复是完全无C的Q除非你信回复的信息也许是机密?而且有h会ؓ了某U未知的原因只让你而不是整个论坛知道答 ?。如? 你只是想 在有人回复线索时得到电子邮g提醒Q可以要求论坛发送。几乎所有论坛都提供诸如“留意本U烦”、“有回复发送邮件”的功能?/p>
l验告诉我们Q粗心与草率的作者通常也粗心与草率地思考和~程(我敢打赌)。ؓq些_心与草率的思考者回{问题没有什么好处，我们宁可? 旉花在其它地方?/p>
清楚、完整地表达你的问题非常重要。如果你觉得q样做麻烦，我们也觉得注?你的问题)ȝ。花炚w外的_֊斟酌一下字句，用不着太僵与正式──事实 上，黑客文化很看重能准确C用非正式、俚语和q默的语句。但它必d准确Q而且有迹象表明你是在思考和? 注问题?/p>
正确地拼写、用标点和大小写，不要“its”淆ؓ“it's”，“loose”搞成“lose”或者将“discrete”弄? “discreet”?span style="font-weight: bold;">不要全部用大?/span>Q这会被看成无礼的大声嚷? (全部写也好不到哪去Q因Z易阅诅RAlan Cox[注：著名黑客QLinux内核的重要参与者]也许可以q样做，但你不行 )?/p>
一般而言Q如果你写得象个半文盲似的傻子，多半得不到理睬。如果象个小孩似Cؕ写ؕ画那l对是在找死Q可以肯定没Z理你(或者最? 是给你一大堆指责与挖??/p>
如果在非母语论坛中提问，你的拼写与语法错误会得到有限的宽容，但懒惰完全不会被容忍(是的Q我们通常看得出其中的差别)。同Ӟ除非你知道回复? 使用 的语aQ请使用 p书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在互联|上p是工作语aQ用p书写可以你的问题不? 阅读p直接删除的可能降到最低?/p>
如果你h为地问题搞得难以阅读，它多半会被忽略，Z更愿L懂的问题Q所以：
-
使用文本而不是HTML(文本标注语a) ( 关闭HTML q不?
-
使用MIME(多用途互联网邮g扩展)附g通常没有问题Q前提是真正有内?譬如附带的源文g或补?Q而不仅仅是邮件客LE序 ? 成的模板(譬如只是消息内容的拷??/p>
-
不要发送整D只是单行句子但多次折回的邮?q得回复部分内定w常困?。设想你的读者是?0个字W宽的文本终端阅读邮Ӟ 讄你的行折回点于80列?/p>
-
但是Q也不要? M固定列折回数?譬如直接传送的? 志文件或会话记录)。数据应该原样包含，使回复者确信他们看到的与你看到的东西一栗?/p>
-
在英语论坛中Q不要?Quoted-Printable' MIME~码发送消息。这U编码对于张贴非ASCII语言可能是必ȝQ但很多邮g代理E序q不支持。当它们分断Ӟ那些文本中四处散? ? ?20”符h隄也分散注意力?
-
永远不要? 望黑客们阅读使用闭的专用格式编写的文档Q诸如微软公司的Word或Excel文g{，大多数黑客对此的反应p有h还在冒热气的猪 _倒在你门口时你的反应一栗即使他们能够处理，他们也很厌恶q么做?/p>
-
如果你从使用视窗的电脑发送电子邮Ӟ关闭微Y愚蠢的“聪明引用”功能，以免在你的邮件中到处散布垃圾字符?
-
在网论坛，勿滥用“表情符号”和“html”功?当它们提供时)。一两个表情W号通常没有问题Q但花哨的彩色文本們于? 你是个无能之辈。过滥地使用表情W号、色彩和字体会你看来象个傻W的姑娘。这通常不是个好LQ除非你只是Ҏ而不是有用的回复更有兴趣?/p>
如果你用图形用L面的邮g客户端程?如网景公司的Messenger、微软公司的Outlook或者其它类似的)Q注意它们的~省配置不一 定满些要求。大多数q类E序有基于菜单的“查看源码”命令，用它来检查发送文件夹中的消息Q以保发送的是没有多余杂质的U文本文件?/p>
-
仔细、清楚地描述问题的症?
-
描述问题发生的环?LQ操作系l，应用E序QQ何相关的)Q提供销售商的发行版和版本号(如：“Fedora Core 2”、“Slackware 9.1”等)
-
描述提问前做q的研究及其理解?
-
描述提问前ؓ定问题而采取的诊断步骤?
-
描述最q对计算机或软g配置的Q何相x变?
最大努力预黑客会提到的问题，q提前备好答案?/p>
Simon Tatham写过一叫 如何有效报告臭虫 的文章，我强烈推荐各位阅诅R?/p>
你应?写得)准确且有内容Q简单地一大堆代码或数据“們ր”在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让E序崩溃Q尝 试将其裁剪得小好?/p>
臛_有三个理由支持这炏V第一Q让别h看到你在努力化问题你更有可能得到回复。第二，化问题你更有可能得?span style="font-style: italic; font-weight: bold;">有用?/span>回复。第三，在提U臭? 报告的过E中Q你可能自己找C解决问题的方法或权宜之计?/p>
当你在一个Y件中遇到问题Q除非你?
常、非?/span>的有ҎQ不要动辄声U找C臭虫。提C：除非你能提供解决问题的源代码补丁Q或者对前一版本的回归测
?
表现Z正确的行为，否则你都多半不够完全信。对于网和文档也如此，如果?声称)发现了文档的“臭虫”，你应该能提供相应位置的替代文本?/p>
CQ还有许多其它用hl历你遇到的问题Q否则你在阅L档或|页搜烦时就应该发现?你在报怨前已经做了q些Q?a title="Before You Ask">是吧Q?。这也意味着很有可能是你弄错了而不是Y件本w有?
题?/p>
~写软g的h通常非常辛苦C它尽可能完美。如果你声称扑ֈ了臭虫，也就暗示他们做错了什么，而这几乎M使h不快──即你是对的Q?
在主题中嚷嚷“臭虫”也是特别不老练的?/p>
提问Ӟ即你私下非常确信已l发C个真正的臭虫Q最好写得象?span style="font-weight: bold; font-style: italic;">?/span>?
错了什么。如果真的有臭虫Q你会在回复中看到这炏V这么做的话Q如果真有虫子，l护者就会向你道歉，qL你弄
怺然后Ơ别Z个道歉要强?/p>
有些人明白他们不应该_鲁或傲慢地行事q要求得到答复，但他们退到相反的低声下气的极端，“我知道我只是个什么也不是、什么也不懂的失败者， 但……”。这既人困C没有帮助Q当伴随着对实际问题含p的描述时还特别令h反感?/p>
别用低灵长cd物的{略费大家的时_相反Q尽量清楚地表述背景事实和你的问题，q比低声下气更好地摆正了你的位置?/p>
有时Q网论坛设有单独的初学者提问区域，如果你真的认为遇C初浅的问题，到那d是了Q但一样别低声下气?/p>
告诉黑客你认为是什么导致了问题是没有用?如果你的诊断理论是了不v的东西，你还会向他h咨询求助吗？)。所以，保只是告诉他们问题的原? 症状Q而不是你的解释和理论Q让他们来解释和诊断。如果你认ؓ陈述你的猜测很重要，清楚地说明这只是你的猜测q描qCؓ什么它们不起作用?/p>
愚蠢Q?/span>-
-
我在~译内核时接q遇到SIG11错误Q怀疑主板上的某根电路丝断了Q找到它们的最好办法是什么？
- 明智Q?/span>
-
我组装的电脑(K6/233 CPU、FIC-PA2007L(威盛Apollo VP2芯片l?、Corsair PC133 SDRAM 256Mb? ?最q在开?0分钟左右、做内核~译旉J地报SIG11错，但在?0分钟内从不出问题。重启动不会复位旉Q但整夜x会。更换所有内存未解决? 题，相关的典型编译会话日志附后?/p>
刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以，记录中应准确地描qC及电脑在崩溃之前都做了些什么。在命o行处理的 情况下，有会话日?如运行脚本工L成的)q引用相关的若干(?0)行记录会非常有帮助?/p>
如果崩溃的程序有诊断选项(?v详述选项)Q仔l考虑选择q些能在记录中增加排错信息的选项?/p>
如果你的记录很长(如超q四D?Q也许在开头简q问题随后按旉先后|列详细q程更有用。这样做Q黑客在M的记录时q道该查哪些内容了?/p>
如果你想弄清楚如何做某事(而不是报告一个臭?Q在开头就描述你的目标Q此后才描述为此采取的措施所遇到的问题?/p>
l常有这U情况，L技术帮助的人在脑袋里有个更高层面的目标Q他们在自以辑ֈ目标的特定道路上被卡住了Q然后跑来问该怎么赎ͼ? 没有意识到这条\本n有问题，l果要费很大的劲才能通过?/p>
- 愚蠢Q?/span>
-
我怎样才能让某囑ŞE序的颜色拾取器取得十六q制的RGB|
- 明智Q?/span>
-
我正试图用自己选定数值的颜色替换一q图片的颜色表，我现在唯一知道的方法是~辑每个表槽Q但却无法让某图形程序的颜色拑֏器取得十六进 制的RGB倹{?/p>
W二U提法是明智的，它得徏议采用更合适的工具完成d的回复成为可能?/p>
黑客们认为问题的解决q程应该公开、透明Q此q程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被更正。同Ӟ作ؓ 回复者也因ؓ能力和学识被其它同行看到而得到某U回报?/p>
当你要求U下回复Ӟ此过E和回报都被中止。别q样做，?span style="font-weight: bold; font-style: italic;">回复?/span>来决定是否私下回{──如果? 真这么做了，通常是因Z认ؓ问题~写太差或者太肤浅 ? 至于对其它h无意义?/p>
对这条规则存在一条有限的例外Q如果你信提问可能会导致大量雷同的回复Ӟ那么“给我发电子邮gQ我ؓ组归纳q些回复”将是神奇的句子。试? 邮 件列表或新闻l从z水般雷同的回复中解救出来是非常有礼貌的──但你应信守诺a?/p>
漫无辚w的问题通常也被视ؓ没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的?假如只是因ؓ他们承担了大多数工作的话)Q这? ? 对于? 有限制的旉无底z极其反感，所以他们也們于讨厌那些O无边际的问题?/p>
如果你明了惌回复者做的事(如指Ҏ向、发送代码、检查补丁或其它)Q你更有可能得到有用的回复。这可以使他们集中精力ƈ间接地设定了他们为帮 助你需要花费的旉和精力上限，q很好?/p>
要想理解专家生活的世界，可以q样设想Q那里有丰富的专长资源但E~的响应旉。你暗中要求他们奉献的时间越，你越有可能从q些真正懂行也真正很 忙的专家 那里得到回答?/p>
所以限定你的问题以使专家回{时需要付出的旉最──q通常q与化问题不一栗D个例Q“请问可否指点一下哪有好一点的X解释Q”通常? 比“请解释一下X”明智。如果你有什么代码不q行了，通常请别人看看哪有问题比叫他们帮你改正更明智?/p>
黑客们善于发现“家庭作业”式的问题。我们大多数人已l做了自q家庭作业Q那?span style="font-weight: bold; font-style: italic;">该你做的Q以便从其经历中学习。问一 下提C没有关p，但不是要求完整的解决Ҏ?/p>
如果你怀疑自qC一个家庭作业式的问题，但仍然无法解冻I试在用L论坛?作ؓ最后一?在项目的“用户”邮件列表或论坛中提问。尽? 黑客们会看出来，一些高U用户也总会给你提C?/p>
抵制在求助消息末֊上诸如“有帮我吗？”或“有没有{案Q”之cd语义上无M意义东西的诱惑。第一Q如果问题描q还不完_q些? 加的东西最多也只能是多余的。第二，因ؓ它们是多余的Q黑客们会认些东西烦人──很有可能用逻辑上无误但打发人的回复Q诸如“是的，你可 以得到帮助”和“不Q没有给你的帮助?/p>
一般来_避免提“是或否”类型的问题Q除非你惛_?“是或否”类型的回答?/p>
q是你自q问题Q不要我们的。宣U“紧急”极有可能事与愿q：大多数黑客会直接删除q种消息Q他们认是无C和自私C囑־到即时与Ҏ的关 照?/p>
有一点点局部的例外Q如果你是在一些知名度很高、会佉K客们Ȁ动的地方使用E序Q也许值得q样d。在q种情况下，如果你有期限压力Q也很有CD 地提到这点，Z也许会有_的兴快一点回{?/p>
当然Q这是非常冒险的Q因为黑客们对什么是令hȀ动的标准多半与你的不同。譬如从国际I间站这样张贴没有问题，但代表感觉良好的慈善或政d 因这样做几乎肯定不行。事实上Q张贴诸如“紧急：帮我救救q个毛绒l的v豹！”肯定会被黑客回避或光火Q即使他们认为毛l绒的小v很重要?/p>
如果你觉得这不可思议Q再把剩下的内容多读几遍Q直到弄清楚了再发脓?/p>
CD一点，使用“请”和“谢谢你的关注”或者“谢谢你的意见”，让别人明白你感谢他们无偿花时间帮助你?/p>
坦率地说Q这一Ҏ有语法正、文字清晰、准、有内容和避免用专用格式重?同时也不能替代它?。黑客们一般宁可读有点唐突但技术鲜明的? 虫报告，而不是那U礼貌但含糊的报告?如果q点让你不解Q记住我们是按问题能教我们些什么来评h一个问题的)
然尔Q如果你已经谈清楚了技术问题，客气一点肯定会增加你得到有用回复的Z?/p>
(我们必须指出Q本文唯一受到一些老黑客认真反对的地方是以前曾l推荐过的“提前谢了”，一些黑客认隐含着事后不用再感谢Q何h的暗C。我们的 ? 先说 “提前谢了”，事后再对回复者表C感谢。或者换U方式表达，譬如用“谢谢你的关注”或“谢谢你的意见??/p>
问题解决后向所有帮助过的hq加一条消息，让他们知道问题是如何解决的ƈ再次感谢。如果问题在邮g列表或新ȝ中受到广泛关注，在那里追加此消息? 较恰当?/p>
最理想的方式是向最初提问的U烦回复此消息ƈ在主题包含“已解决”、“已搞定”或其它同样意思的明显标记。在人来人往的邮件列表里Q一个看见线? “问题X”和“问题X-已解决”的潜在回复者就明白不用再浪Ҏ间了(除非他个得“问题X”有?Q因此可以用此时间去解决其它 问题?/p>
你追加的消息用不着太长太复杂，一条简单的“你好──是网U坏了！谢谢大家──比尔”就比什么都没有要强。事实上Q除 非解决问题的技术真正高深，一条简短而亲切的ȝ比长大好。说明是什么行动解决了问题Q用不着重演整个排错的故事?/p>
对于有深度的问题Q张贴排错历史的摘要是适当的。描q问题的最l状态，说明是什么解决了问题Q在?span style="font-weight: bold; font-style: italic;">之后才指明可以避免的弯\。应避免? 弯\部分应放在正的解决Ҏ和其它ȝ材料之后Q而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字Q那样你会交到朋友的?/p>
除了有礼貌、有内容以外Q这U类型的q帖帮助其他h在邮件列表、新ȝ或论坛文档中搜烦到真正解决你问题的方案，从而也让他们受益?/p>
除上q而外Q此c追帖还让每位参与协助的人因问题的解册生一U满x。如 果你自己 不是技术专家或黑客Q相信我们，q种感觉对于你寻求帮助的老手和专安帔R要。问题叙q到最后不知所lL令h沮的，黑客们痒 痒地渴望看到它们被解冟뀂“挠痒痒”ؓ你挣到的好报对你下ơ再ơ张贴提问非帔R常的有帮助?
考虑一下怎样才能避免其他人将来也遇到cM的问题，问问自己~一份文档或FAQ补丁有没有帮助，如果有的话就补丁发l维护者?/p>
在黑客中Q这U行为实际上比传l的CD更重要，也是你善待他赢得声誉的方式Q这是非常有价值的财富?/p>
有一个古老而神圣的传统Q如果你收到了“RTFM”的回复Q发信h认ؓ你应该去“读读该ȝ手册”。他多半是对的，去读一下吧?/p>
RTFM有个q轻的亲戚，如果你收到“STFW”的回复Q发信h认ؓ你应该“搜搜该ȝ|络”。他多半也是对的Q去搜一下吧?更温和一点的说法? “Google 是你的朋友！?
在网论坛，你也可能被要求去搜烦论坛的文档。事实上Q有人甚臛_能热心地Z提供以前解决此问题的U烦。但不要依赖q种好心Q提问前应先搜烦 一下文 档?/p>
通常Q叫你搜索的人已l打开了能解决你问题的手册或网，正在一边看一Ҏ键盘。这些回复意味着他认为：W一Q你要的信息很容易找到。第二，自已? 要比别h喂到嘴里能学得更多?/p>
你不应该觉得q样p冒犯了，按黑客的标准Q他没有不理你就是在向你表示某种敬Q你反而应该感谢他热切地想帮助你?/p>
如果你看不懂回复Q不要马上回发一个要求说明的消息Q先试试那些最初提问时用过的同样工?手册、FAQQ网c懂行的朋友{?试着搞懂? 复。如果还是需要说明，展现你已l明白的?/p>
譬如Q假如我告诉你：“听h象是某输入项有问题，你需要清除它”，接着是个不好的回帖：“什么是某输入项Q”? 而这是一?span style="font-weight: bold; font-style: italic;">?/span>的跟帖：“是 的， 我读了手册，某输入项只在-z?p开关中被提刎ͼ但都没有提及清除某选项Q你指的是哪一个还是我弄错了什么？?/p>
很多黑客圈子中看似无C的行ؓq不是存心冒犯。相反，它是直接了当、一刀见血式的交流风格Q这U风格对于更x解决问题而不是别h感觉舒服而? 的h 是很自然的?/p>
你如果觉得被冒犯Q努力^静地反应。如果有人真的做了过格的事，邮g列表或新ȝ或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了Q那么你发火? 象的a? 可能在黑客社Z看v来是正常的，?span style="font-weight: bold; font-style: italic;">?/span>? 被视为有错的一方，q将伤害C获取信息或帮助的Z?/p>
另一斚wQ你会偶而真的碰到无C和无聊的言行。与上述相反Q对真正的冒犯者狠狠地打击、用犀利的语言其驛_体无完肤都是可以 接受的。然，在行事之前一定要非常非常的有Ҏ。纠正无C的aZ开始一场毫无意义的口水战仅一U之隔，黑客们自p撞地线情况q不鲜见。如果你是新 手或外来者，避开q种莽撞的机会不高。如果你 惛_到的是信息而不是消时光，q时最好不要把手放在键盘上以免冒险?/p>
(有些人断a很多黑客都有d的自闭症或阿斯伯格综合症Q一定缺^滑hcȝ会“正常”交往所需的脑电\。这既可能是真也可能是假。如果你自己不是 黑客Q兴? 你认为我 们脑袋有问题q能帮助你应付我们的古怪行为。只这么干好了Q我们不在乎。我?span style="font-weight: bold; font-style: italic;">喜欢我们现在q个样子Qƈ且一般都? 临床诊断有相当的怀疑?
在下一节，我们会谈到另一个问题，当你行ؓ不当时会受到的“冒犯?/p>
在黑客社区的论坛中有那么几次你会搞砸──以本文详q或cM的方式。你会被CZ是如何搞砸的Q也许言语中q会带点颜色?/p>
q种事发生以后，你能做的最p的事莫q于哀嚎你的遭遇、宣U被口头d、要求道歉、高声尖叫、憋h、威胁诉诸法律、向光L怨、忘了关马桶盖等 {。相 反，你该q样dQ?br>
熬过去，q很正常。事实上Q它是有益健康与恰当的?/p>
C的标准不会自q持，它们是通过参与者积极?span style="font-weight: bold; font-style: italic;">公开地执行来l持的。不要哭嚎所有的 批评都应该通过U下的邮件传送，q不是事情运作的方式。当有h批评你的 一些主张或者其看法不同Ӟ坚持声称个h被侮׃毫无用处Q这些都是失败者的态度?/p>
也有其它的黑客论坛，受太高礼节要求的误导Q要求参与者禁止张贴Q何对别h帖子挑毛病的消息Qƈ被告知“如果你不想帮助用户闭嘴”。有思\的参? 者纷U? ? 开 的结果只会它们变成了毫无意义的唠叨与无用的技术论坛?/p>
是夸张的“友谊?以上q方?q是有用Q挑一个?/p>
CQ当黑客说你搞砸了，q且(无论多么_)告诉你别再这样做Ӟ他正在ؓ兛_你和他的C而行动。对他而言Q不理你q将你从他的生活中o除要 Ҏ? 多。如果你无法做到感谢Q至要有点严Q别大声哀嚎，也别因ؓ自己是个有戏剧性超U敏感的灵魂和自以ؓ有资格的新来者，指望别对待脆弱的洋娃娃 那样对你?/p>
有时候，即你没有搞?或者只是别人想象你搞砸?Q?有些Z无缘无故地攻M本h。在q种情况下，报怨倒是真的会把问题搞砸?/p>
q些找茬者要么是什么也不懂但自以ؓ是专家的不中用家伙，要么是试你是否真会搞砸的心理学家。其它读者要么不理睬Q要么用自己的方式对付他们? q些找茬者在l自己找ȝQ这点你不用操心?/p>
也别让自己卷入口水战Q大多数口水战最好不要理睬──当然是在你核实它们只是口水战、没有指Z搞砸的地方，而且没有巧妙地将问题真正的答案藏于其 ? (q也 ? 可能?之后?/p>
下面是些典型的愚蠢问题和黑客不回{它们时的想法?/p>
- 问： 我到哪可以找到程序或X资源Q?
- 问： 我怎样用X做YQ?/a>
- 问： 如何配置我的shell提示Q?/a>
- 问： 我可以用Bass-o-matic文g转换工具AcmeCorp文档转ؓTeX格式 吗？
- 问： 我的{E序、配|、SQL语句}不运行了
- 问： 我的视窗电脑出问题了Q你能帮忙吗Q?/a>
- 问： 我的E序不运行了Q我认ؓpȝ工具X有问?/a>
- 问： 我安装Linux或X遇到困难Q你能帮忙吗Q?/a>
- 问： 我如何才能破解超U用户口?盗取频道操作员的Ҏ/查看某h的电子邮Ӟ
| 问： | |
| {： |
在我扑ֈ它的同样地方Q笨旦──在网|索引擎上。上帝啊Q难道还有h不知道如何?Google 吗？ |
| 问： | |
| {： |
如果你想做的是YQ提问时别给出可能ƈ不恰当的Ҏ。这U问题说明提问者不但对X完全无知Q也对要解决的Y问题p涂Q还被特定Ş势禁 锢了思维。等他们把问题弄 好再说?/p> |
| 问： | |
| {： |
如果你有_的智慧提q个问题Q你也该有够的智慧?RTFMQ? 然后自己L?/p> |
| 问： |
|
| {： |
试试q道了。如果你试过Q你既知道答案，又不用浪Ҏ的时间了?/p> |
| 问： |
|
| {： |
q不是一个问题，我也没有兴趣ȝ你有什么问题──我有更要紧的事要做。看到这U东西，我的反应一般如下：
|
| 问： |
|
| {： |
是的Q把视窗垃圾删了Q装个象Linux或BSD的开源操作系l吧?/p> 注意Q如果程序有官方的视H版或与视窗有交?如Samba)Q你可以问与视窗电脑相关的问题，只是? 寚w题是pH操作系l而不是程序本w造成的回复感 到惊Ӟ? H一般来说太差，q种说法一般都成立?/p> |
| 问： |
|
| {： |
你完全有可能是第一个注意到被成千上万用户反复用的pȝ调用与库文g有明昄L人，更有可能的是你完全没有根据。不同凡响的说法需 要不同凡响的证据Q? 当你q样 声称Ӟ你必L清楚而详的~陷说明文档作后盾?/p> |
| 问： |
我安装Linux或X遇到问题Q你能帮忙吗Q?/p> |
| {： |
不行Q我需要亲手操作你的电脑才能帮你排错，d当地的Linux用户l寻求方便的帮助(你可以在 q里 扑ֈ用户l列? 注意Q在为某一Linux发行版服务的邮g列表或论坛或本地用户l织中提关于安装该发行版的问题也许是恰当的。此Ӟ应描q问题的准确 l节。在此之前，先用 “linux”和所?/span>被怀 疑的g(为关键词)仔细搜烦?/p> |
| 问： |
|
| {： |
惛_q种事情说明你是个卑劣的家伙Q想让黑客教你做q种事情说明你是个白痴?/p> |
最后，我将通过举例来演C提问的智慧。同L问题两种问法Q一U愚蠢，另一U明智?/p>
愚蠢Q我在哪能找到关于Foonly
Flurbamatic讑֤的东西？-
-
q个问题在乞求得?STFW 式的回复?/p>
明智Q我用Google搜烦q“Foonly
Flurbamatic
2600”，但没有找C么有用的Q有谁知道在哪能扑ֈq种讑֤的编E信息？-
-
q个人已l搜索过|络了，而且听v来他可能真的遇到了问题?/p>
愚蠢Q我不能~译某项目的源代码，它ؓ什
么这么破Q?/span>-
-
他假设是别h搞砸了，太自大了?/p>
明智Q某目的源代码不能在某Linux
6.2版下~译。我M常见问题文档Q但其中没有与某Linux相关的问题。这是编译时的记录，我做错了什么吗Q?/span>-
-
他指明了q行环境Q读了FAQQ列Z错误Q也没有假设问题是别人的q错Q这家伙值得注意?/p>
愚蠢Q我的主板有问题Q谁能帮我？-
-
某黑客对此的反应可能是：“是的，q需要帮你拍背和换尿布吗Q”，然后是敲下删除键?/p>
明智Q我在S2464L上试qX、Y?
ZQ当它们都失败后Q又试了A、B和C。注意我试C时的奇怪症Ӟ昄某某东西正在做某某事情，q不是期望的。通常
在Athlon MPL上导致某某事情的原因是什么？有谁知道我还能再试点什么以定问题Q?/span>
-
相反圎ͼq个人看来值得回答。他展现了解决问题的能力而不是坐{天上掉馅饼?/p>
在最后那个问题中Q注意“给我一个回复”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别?/p>
事实上，最后那个问题基本上源于2001q?月Linux内核邮g列表(lkml)上的真实事gQ是?Eric)当时提了那个问题Q我发现 Tyan S2462 L有神U的L现象Q邮件列表成员给我提供了解决此问题的关键信息?br>
通过q种提问方式Q我l了别h可以咀嚼玩味的东西。我设法使之对参与者既L又有吸引力，也表明了对同行能力的敬q请他们与我一起协商。? q告? 他们我已l走q的弯\Q我q表明了对他们宝贉|间的重?/p>
事后Q当我感谢大家ƈ评论q次良好的经历时Q一个Linux内核邮g列表的成员谈刎ͼ他认为ƈ不是因ؓ我的名字在列表上Q而是因ؓ我正的提问方式 ? 得到了答 案?/p>
黑客们在某种斚w是非怸留情面的_英分子。我想他是对的，如果我表现得象个不劳而获的寄生虫Q不我是谁都会被忽略或斥责。他整个事件作? 对其? ? 提问的指导直接导致了本文的编写?/p>
如果得不到回{，请不要认为我们不惛_你，有时候只是因为小l成员的不知道{案。没有回复不{于被忽略，当然必须承认从外面很隄Z者的差别?/p>
一般来_直接问题再张脓一ơ不好，q会被视为毫无意义的骚扰?/p>
q有其它资源可以L帮助Q通常是在一些面向新手的资源中?/p>
有许多在U与本地用户l织Q虽然它们自׃~写M软gQ但是对软g很热心。这些用L通常因互助和帮助新手而Ş成?/p>
q有众多大小商业公司提供{支持服务(U帽与Linuxcare是两家最出名的，q有许多其它?。别因ؓ要付炚w才有支持感到沮丧！毕竟Q如 果你车子? 汽垫烧了，你多半还得花钱找个修理店把它弄好。即使Y件没׃一分钱Q你M能指望服务支持都是免费的?/p>
象Linuxq样行的YӞ每个开发者至有一万个以上的用P一个h不可能应付这么多用户的服务要求。记住，即你必MҎ能得到支持，也比 你还得额外花׃软g要少得多(而且对封闭源代码软g的服务支持与开源Y件相比通常q要贵一点，也要差一?
态度和善一炏V?/span>问题带来的压力常使h
昑־无礼或愚蠢，其实q不是这栗?/p>
对初犯者私下回复?/span>寚w些坦诚犯?
之h没有必要当众iQ一个真正的新手也许q怎么搜烦或在哪找FAQ都不知道?/p>
如果你不定Q一定要说出来！一个听
h权威的错误回复比没有q要p，别因为听h象个专家好玩q别h乱指路。要谦虚和诚实，l提问者与同行都树个好榜样?/p>
如果帮不了忙Q别?
?/span>不要在具体步骤上开玩笑Q那样也怼毁了用户的安装──有些可怜的呆瓜会把它当成真的指令?/p>
探烦性的反问以引出更多的l节。如
果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题{变成好问题，别忘了我们都曾是新手?/p>
管寚w些懒虫报怨一声RTFM是正当的Q指出文档的位置(即只是做个Google关键词搜?会更好?/p>
如果你决意回{，l?
出好的答案?/span>当别人正使用错误的工h不当
的方法时别徏议笨拙的权宜之计Q应推荐更好的工P重新l织问题?/p>
帮助你的C从问题中
学习?/span>当回复一个好问题Ӟ问问自己
“如何修改相x件或FAQ文档以免再次解答同样的问题？”，接着再向文档l护者发一份补丁?/p>
如果你的是在研I一番后才做出的回答Q?span style="font-weight: bold; font-style: italic;">?
C的技巧而不是直接端出结果?/span>毕竟“授
Z|不如授h以渔”?/p>
Powered by MessageSoft SMG
SPAM, virus-free and secure email
http://www.messagesoft.com
]]>
Eclipse 最早来源于Object Technology International (OTI)?994q开发的产品 IBM VisualAge for SmalltalkQ?996q又发布了IBM Visual Age for Java 。以上品都是用Smalltalk写的Q完全用Java~写的IDE则是后来推出的IBM VisualAge Micro Editionq一产品Q这也是Eclipse的主要基Q但q一产品对第三方lg的支持不够。后来经q一个小规模专家团队的研IӞ在ȝq去开发经验的 前提下，提高了IDE的可扩展性，其品就是Eclipse?001q?1月Eclipse开源项目正式徏立，2005q??4日的最新正式发布版本是 Eclipse3.0.2Q稳定版本是Eclipse3.1M5。插件L(据不完全l计)U?42个，涉及软g开发的Ҏ面面。插件分cd下：Bug Tracker (6)、Code Generation (13)、Code mngt (73)、Database (44)、Deployment (18)、Documentation (26)、Editor (16)、Electronics (1)、Entertainment (36)、Graphics (5)、J2EE development platform (35)、Languages (43)、Middleware (6)、Mobile/PDA (12)、Modelling (16)、Network (11)、News (7)、Obsolete (3)、Patterns (4)、Profiling (12)、Project management (4)、Research (3)、Rich Client (5)、Safety-critical (2)、SCM (20)、Snipets (2)、Snipets/Modelling (1)、Source Code Analyzer (21)、Team (6)、Testing (25)、Tomcat (5)、Tools (51)、Tutorial (33)、UI (31)、UI components (9)、UML (20)、Utility (27)、Web (39)、Web Service (19)、XML (32)?br>
]]>
March 2005
Discussion
Overview
The cost impact to a company of a failed project can be severe indeed. The impact on the reputation of the project manager can be disastrous.
Software project management is not easy, and it requires considerable skill to successfully manage the many different risks that conspire to de-rail a project:
Numerous methodologies are available for mitigating these risks ?PRINCE2, RUP, DSDN, eXtreme programming ?and these have helped to some extent.
This document introduces the 3D?methodology ?a set of best practices and quality tools developed by BuildMonkey, which can be summarised as.
De-risk. Deploy. Deliver.
In any software project, deployment is a milestone on the project plan that is usually associated with payment ?or staged payment. Through the course of development, any number of problems can arise to derail efforts to reach this milestone.
The 3D?methodology and supporting toolset is based on many years of experience at the sharp end of projects, understanding what has worked and what has not, and the lessons learned from each.
Competent practitioners, and experienced project staff, will find resonance with many of the contents of this document and may find themselves saying ?em>this is just common sense? This is certainly true, but the main problem with common sense is that it is not as common as people think it is.
This document, and the 3D?methodology, is an attempt to bring that common sense together in a single location, as a coherent set of best practices supported by proven tools to help you to release on-time, on-budget, with no defects.
The Problem To Be Solved
No methodology has yet focused on the component that all development projects share ?the build.
One of the reasons for this is that the term “build?is interpreted differently by different people:
- The development team sees it as compilation and assembly;
- The integration team see it as the bringing together of all of the components in the application in a format suitable for release;
- The deployment team see it as something which produces the artifacts that they have to install and configure;
- The testing team see it as something which produces the artifacts that they have to test;
- The Project Manager sees it as an opaque step that nobody is entirely responsible for;;
- The end customer should not see it at all;
The BuildMonkey view is that the build is the combination of processes and technology that take software from design to deployment ?_where the return on investment starts to be seen.
It is clear that a methodology is required to de-risk development projects and to standardise use of the term “Build Management?
Best Practice: ?em>Build Management?encompasses everything from compilation, all the way through to release to the customer.
No Release, No Revenue
Any Finance Director knows that development is just an activity that needs to be tolerated in order to produce something that will deliver a return on investment.
It may sound strange, but a large number of software developers do not appreciate and embrace this basic truth. This is in part due to their closeness to the application being constructed.
A common problem faced by development projects is therefore that it is the software developers who manage the build. This creates a situation where the build is focused on the needs of development, and is not geared towards releasing the output of coding such that business value can be realised.
Build Management should therefore focus on the end result of development ?a return on investment ?and ensure that all of the inputs to the process are incorporated in pursuit of this goal:
Best Practice: Focus on the end, and accommodate the inputs
Software Tools Are Only Part of the Answer
Software projects are a complex set of interdependent people and teams and can be likened to a convoy of ships. A convoy has to move at the rate of the slowest ship. Increasing the speed of a single ship in the convoy will not increase the speed of the convoy ?it will simply increase the amount of wasted capacity in the speeded-up ship.
Speeding up the slowest ship will, however, have a positive effect since the whole convoy can now move faster.
Many Project Managers try to improve productivity by implementing some degree of automation in development projects ?particularly in the area of the build ?and often purchase ?em>magic bullet?build software that provides this.
Simply using automated build software does not improve productivity any more than the example above improves convoy speed - as it only increases the speed of a single ship in the convoy.
There is no point in speeding up development, if the target production infrastructure cannot keep pace ?this just increases the inefficiency. A lot of organisations make this mistake ?highly agile development processes trying to feed into considerably less agile deployment processes. The result is inefficiency, waste and over-run.
Before considering using an automated build tool it is essential to ensure that the inputs to, and outputs from, the build can cope with the improved build speed. It is imperative to ensure that the processes and technology employed are geared towards taking the project to a successful conclusion ?on-time and on-budget.
Best Practice: Don’t rely on software tools alone, they may solve symptoms whilst creating problems elsewhere
Configuration Management Best Practices
Software Configuration Management (SCM) is a relatively mature discipline with much written about methodologies and techniques, and these will not be recreated here.
We will focus instead on leveraging the SCM repository, and the facilities that it offers, to further the goals of the project rather than to consider SCM in its own right.
It All Starts Here
The SCM repository - how it is managed and used ?is the keystone of good build management and successful delivery of projects.
The SCM repository is the slave of the project, not the other way round. It should be solid and reliable, yet flexible enough to accommodate the needs of new projects. Project Managers should not have to retrofit their planning to accommodate an inflexible SCM setup.
If used correctly, the SCM repository will enhance productivity, and minimize risk, through being able to provide exactly what the project ?and project management ?require. If used incorrectly, it can cause delay and slippage through having to do things inefficiently further down the chain.
Best Practice: The SCM repository is the slave of the project, not the other way round.
Configuration Management is not Version Control
Most software developers regard the SCM repository as a massive storage area where they simply check versions in and out ?a common cause of problems.
Simply checking things into an SCM repository is not Configuration Management any more than karaoke is opera.
A well-maintained SCM repository is so much more than version control, and should provide:
- The ability to recreate any identified baseline, at any time;
- Meaningful statistics on what is changing, when and by whom;
- Management information, such as ?em>how many new defects were introduced by the refactoring of component ‘X??/li>
In order to be truly effective in a project, the SCM repository should store all of the artifacts that form part of a baseline or a release.
Source CodeMost development projects simply store the code that is being developed and their use of the SCM repository is no more sophisticated than this.
DataMost applications nowadays are not just source code. Take the example of a modern computer game ?the vast majority of the code base is made up of artifacts other than code such as audio clips, pictures and movie clips.
Database Structure and ContentsWhere an application relies on a database this database will have a schema and structure that may change from release to release ?this schema must be captured.
There will normally also be seed data for the database which should be considered as part of the baseline.
Application ConfigurationIn a large distributed application, the software being developed will sit atop a number of pieces of software (e.g. application servers, web servers and message queues).
The configuration of these underlying applications have an effect on the quality ?or otherwise ?of the software being developed and should, therefore, be considered part of the baseline for a release.
Environment ConfigurationThe underlying environment and infrastructure is a key component of the project, particularly in the case of distributed applications.
Such banal considerations as DNS zone files, user account information and system parameters have to be considered as some of the moving parts which affect the application and therefore be placed under configuration control.
This is of particular importance when there is more than one environment involved in the project (e.g. a development environment and a separate test environment) since the question of ?em>are these environments the same??crops up again and again.
Best Practice: Everything that can be changed, and affect the behaviour of the application, is a candidate for configuration control
The Point of Labelling
It is a common misconception that simply applying labels, or tags, to the SCM repository creates a baseline but this is only partly true without corresponding records of:
- What label has been applied;
- When that label has been applied;
- Why it has been applied (i.e. what milestone, or other external event, the label is associated with);
The use of a naming convention for labels can deceive even further. For example, a project that uses a date-based labeling convention (dd_mm_yyyy) will have several labels of the form (03_05_2004, or 09_06_2004) and will reasonably assume that they have some kind of record of the baseline on those dates.
But what was happening in the project on those dates? Was the 03_05_2004 label applied immediately before a release to test, or immediately after?
Best Practice: Labels should be used to identify and inform about events in the project
Don’t Label If There Is No PointThis may seem like stating the obvious, but there should be a reason for a label being applied ?the whole purpose of labeling is to identify some event in the development cycle that may need to be re-visited.
To this end, labels can be divided into two categories:
- Point-in-time
Associates particular versions with a particular calendar date, or other event that is fixed in time (e.g. MONTH_END_JAN_2004, or RELEASE_1_0_1); - Point-in-process
Associates particular versions with events in the project that may recur at a later stage (e.g. LATEST_RELEASE, or CURRENTLY_IN_UAT);
Best Practice: Every label should have a point, whether point-in-time or point-in-process
Management Information
The job of the Project Manager, ultimately, is to bring the project to a successful conclusion. If this were an easy task that happened by default, then there would be no need for a Project Manager.
In order to be able to do this job well, a Project Manager needs information. He needs to know what is going on in the project ?who is doing what, who is working on which components, and a wealth of information can be obtained from a well-managed SCM repository:
- What is changing in the environment ?what has changed since a given point in time or how often particular elements are changing;
- Who is changing things in the environment;
- Why things are changing in the environment;
Of course, the final item in the list requires that committers are using descriptive comments to indicate why they are marking a particular change. A well-managed SCM repository should enforce this.
Best Practice: The SCM repository should provide meaningful, and accessible, management information
Build Best Practices
As explained at the beginning of this document, the term “build?means different things to different people. The most common interpretation is the one used by developers, where the term “build?describes the compilation and assembly step of their development activities but this narrow interpretation is a common cause of problems and over-runs, on development projects.
Building is not Compiling
At the outset of the project, the Project Manager will ask the question ?em>how long to set up the build??and a developer ?thinking of compilation and assembly ?will answer something like ?em>1 day?/em> ?a task and duration which is then duly marked on the project plan and development begins.
Later in the project, when it is time to start deploying and testing the application, this “build?needs to be refactored to accommodate the deployment and test tasks. In doing so, it turns out that the way the application is being assembled is not conducive to it being deployed or tested correctly ?so the compilation and assembly staged need to be refactored as well.
In the meantime, the development team sits on its hands whilst the “build?is refactored to accommodate the needs of the project ?valuable time is lost whilst the deadline continues to advance.
Best Practice: Know what will be required of the build before starting to write the scripts
Don’t Throw Out The Baby With The Bathwater
From a build perspective, projects with similar architecture (both in terms of the team and the application) will have similar attributes. There will obviously be some changes required, but these will tend to follow the 80/20 rule to a large degree.
For example, a web application that is being developed by an in-house team and that will be deployed to a Tomcat servlet container and Oracle database will follow largely the same steps and require largely the same deployable artifacts.
A good SCM repository will enable the latest versions of boiler-plate build scripts for such an application to be found. These can be used almost off-the-shelf ?meaning that development can start apace without having to wait on the build to be constructed for similar applications .
Best Practice: Well-crafted builds are re-usable and should be re-used
The Architecture Drives The Build<
Following on from the previous section, it should be clear that the architecture of what is being developed ?and the structure of the team(s) developing it ?will dictate how the build should look.
There is little value to be gained in trying to retrofit build scripts for a computer game (developed by 12 people all in the same room) into a project to produce a large J2EE application with development occurring at six different sites around the world.
Best Practice: Well-crafted builds are flexible, but a “one-size-fits-all?approach can be costly
Management Information
There are a number of people who need information that the build can provide:
- The Project Manager needs to track overall progress against defined milestones ?number of outstanding defects, whether a committed release date will be met etc;
- Development leads need to be sure that the code is of the quality that they require ?test reports, bug analysis patterns, code metrics, document and UML generation etc;
- The deployment team need to know that the artifacts will work in their target environment, and that the environment is as the application expects it to be. They also need to know whether two (or more) environments are ?em>the same?
- The test team need to have confidence that they are testing against a known baseline, and whether defects that they see have been rectified in development (or whether they are re-appearing after already being fixed);
- Everybody needs to be able to communicate effectively using the same language, and have a common terminology for release versions ?particularly if there are multiple threads of development;
A good build infrastructure will provide all of the above information, and more besides.
Best Practice: The build should tell all project participants what they need to know
Deployment Best Practices
Considering that it is generally an important milestone on a project plan, normally resulting in payment or a staged payment, deployment is one of the most overlooked areas of software development.
The normal course of events is:
- Release artifacts are created;
- Some installation and release notes are cobbled together in the form of a README;
- The deployment team work frantically to install and configure the application ?the testing team (or, worse still, the customer) are idle and unproductive in the meantime;
- Some symptoms are found which are suspected to be application defects;
- The development team blame the environment;
- The deployment team blame the application;
- Repeat (5) and (6) ad nauseam.
When a documentation team are also considered - responsible for creating documentation that the end user will need to install, configure and use the application ?the situation becomes even more difficult.
This situation can be avoided by planning for deployment from the beginning. Deployment is an inevitable part of software development, yet it always seems to take people by surprise.
Best Practice: Know that deployment is inevitable, and incorporate it into the automated processes
Deployment Is Not Installation
As part of normal development activities, artifacts are installed into sandbox environments ?and test environments ?many times. But this is not deployment, this is installation.
In order to get an application into its production environment, be that an internal environment or on hosted-infrastructure, a number of hurdles must be overcome:
- The application must pass UAT;
- The application must be installed and configured correctly:
- All pre-requisites for the application must be satisfied;
- The end customer must accept the handover;
Deployment is that point in the life of an application where it starts to produce a return on investment. ?em>Launch? ?em>Go-live? ?em>Release? ?em>First Customer Shipment?are all phrases which describe the same event.
Best Practice: Deployment is the point where an application starts to provide a return on the development investment.
The Environment Is a Refactorable Component
This point cannot be stressed enough, particularly in large distributed applications.
Every application, large or small, has a runtime environment in which it operates. In a simple desktop application, this is a standalone machine (such as a PC). In larger applications, this will be a combination of machines (e.g. an application server and a database) operating together to provide the runtime environment.
In either case, the application expects certain facilities to be available from the runtime environment and will function incorrectly ?or cease to function ?if these are not present .
The environment itself, whether standalone or a network, contains many moving parts that can be independently configured. IP addresses, or hostnames, can be changed. User privileges can be modified or revoked. Files and directories can be removed. Each of these can have an effect on the way that the application behaves.
In an environment that is owned and managed internally this can be bad enough. In an environment that is owned and managed by an external third party, and where project success is contingent upon successful UAT in that environment, this can be disastrous.
Best Practice: Be able to identify whether the deployment environment is as prescribed, and ?em>fit for deployment?/p> Environment Verification Testing
One of the most common questions that arises in development projects containing more than one environment is, simply, ?em>are these environments the same??and its answer can be elusive.
It is essential to be able to answer that question ?quickly and accurately ?so that any perceived defects in the application can be categorised as ?em>defect?or ?em>environmental?
This ability becomes particularly poignant where on or more of the environments are owned by different teams, or organisations.
Best Practice: Be able to prescribe what the deployment environment should look like, and have a capability to test it quickly.
Regression TestingThe environment, as explained earlier, is a refactorable component. It can be changed, and parts can be moved or deleted. However, unlike application code, changes may need to be made to the environment in response to external events (e.g. hardware failure, or security policies).
Applications, particularly complex ones, use regression tests to ensure that observed behaviour after a change is exactly as it was before the change was made. The same should be true of the environment.
Best Practice: Automated regression tests for the environment that will compare observed behaviour both before and after changes are made.
For example, suppose that a number of operating system patches or service packs are applied to an environment where the application has been, or will be, deployed. How are these tested? Do you wait for users, or testers, to start calling to say that there are problems?
Or do you make sure that you know what problems have been introduced before your users do?
Configuration ManagementAs stated earlier, the SCM repository should be used to store any artifact that can be changed and that may have an effect on the environment.
It may not seem obvious, but some of the most obscure environmental changes can cause an application to fail:
- Hostname resolution;
- Non-existent user or group accounts;
- IP and network connectivity;
- Existence, or otherwise, of files and directories ;
- Application or operating system configuration files;
It is essential that these environmental variables be placed under configuration control and able to be identified as part of a baseline.
Best Practice: Environmental artifacts that are not part of the application should be part of the baseline
Automate, Automate, Automate
Every single task that is performed as part of a development project ?throughout the entire lifecycle ?can be placed into one of two categories:
- Tasks which require some form of human judgment;
- Tasks which do not;
Tasks which fall into the first category can use some degree of automation, but should stop and wait for human intervention wherever judgment is required.
Tasks in the second category should be automated. There is no value in having expensive resources employed to do mechanical or repetitive tasks that a computer could do more quickly, accurately and consistently.
Best Practice: Automate anything that does not require human judgment
A note of caution - it may be tempting to think that automation will increase productivity on its own, but this is not necessarily the case. Automating an inefficient process will simply magnify its inefficiency ?as explained in the section on Software Tools are Only Part of the Answer.
This, and it is worth repeating, is a common error ?to assume that automated build software alone will improve productivity.
Best Practice: Do not automate inefficient processes, or you will only maximize the inefficiency
About BuildMonkey
BuildMonkey is a division of Nemean Technology Limited - a leading technical innovator specialising in Agile Deployment and build management.
We have over a decade of experience in helping clients increase productivity in their build, integration and test cycles. We have a track record of massively reducing costs and defects through process automation and proven methodologies.
Formed in 1999, and profitable every quarter, we invented the discipline of BuildMaster - we are the original and the best.
We provide specialist Build Management products and services - when all you do is Build Management, you get pretty good at Build Management. Our world-class Professional Services staff are the best in their field, complemented by original software products of the finest quality.
We aim to be the leading provider of Build Management products and services in the UK by providing excellent service to our customers, and by empowering Software Project Managers to aim for release on-time, on-budget, with no defects.
About the Author
John Birtley has been a specialist in Configuration and Build Management since 1994 with a focus on deployment - particularly the packaging and installation of developed applications. He has worked for a number of blue-chip organisations including Sun Microsystems, Hewlett Packard, Sony and Ericsson in the transition from development to deployment. BuildMonkey was launched in January 2004, to package and commoditise this cumulative experience under the title of "Agile Deployment". He lives in Southampton, where dogs and children conspire to take what little spare time he has.
]]>
Flier Lu问到CLR Loader?/span>Java Class Loader有什么不一栗要回答q个问题不容易，因ؓ我对Java一H不通。但既然问题提出来了Q打肿脸来充胖子也得回答啊?/span>
于是今天下午我在google上逛了一圈，找了些关?/span>Java Class Loader的文章看了看。我的结论是Q和Java Class LoadercM的东东，?/span>CLR里是不存在的?/span>
单的_CLR里不存在一个类gJava.Lang.ClassLoader的东ѝ所以你无法实现你自qCLR Loader?/span>CLR里只有一?/span>LoaderQ那是CLR Loader。当ӞCLR提供了自q特的方式让你做动态装载。你所拥有的自由度是远?/span>Java要大得多?/span>
下面是具体分析?/span>
我对Java Class Loader的理解主要是从这两篇文章里来的?/span>
“Inside Class Loader?by Andeas Schaefer (http://www.onjava.com/lpt/a/4337) ?/span> “The basics of Java Class Loaders?by Chuck McManis (http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth_p.html)。我看了?/span>JVM Spec。但是我觉得不如上面两篇文章清楚?/span>
先说Java里的Type吧?/span>Java里的Type是Class ?/span>Class是Namespace + class name. Class通过Class Loader来装载的?/span>System Class Loader~省的话只在CLASSPATH中寻?/span>Class。如果你要在CLASSPATH之外转蝲Class的话Q你需要自qClass Loader。如果两?/span>Class有相同的名字Qƈ且在同一?/span>Class Loader里，那么它们pJVM认ؓ是相同的Q可以互相赋倹{如果有一个不一L话，它们p认ؓ是不一L。互相赋g发生ClassCaseException。换句话_Class name + Class Loader是一?/span>Type的独特的ID?/span>
Java的这个模型有很多问题。首先它?/span>Class name做ؓType?/span>ID。两?/span>Class如果有同L名字Q但是实际内容不一L话，如果它们被同一?/span>Class Loader装蝲Q?/span>JVM会认为它们是同一?/span> Type。这个太搞笑了。结果就?/span>Class Loader必须要有一些特别的办法来管?/span>Class name。一般的办法是加一个前~Q比如说Class?/span>URL。如?/span>Namespace理不好的话Q很Ҏ是安全漏洞。这是ؓ什?/span>JVM Spec里提?/span>Class Loader必须要让Parent Class Loader先搜?/span>ClassQ再自己L。而且Class loader必须要保?/span>Class resolution的结果，q样下次Class resolution的时候，Class loader会返回同Ll果?/span>Java Class Loader有太多的限制Q同时又有太多的责Q?/span>
另一个问题是׃n问题。如果同一?/span>Class被两个不同的Class Loader装蝲的话Q?/span>JVM认ؓq两?/span>Class不是同一?/span>TypeQ不能互相赋倹{结果就?/span>Class无法׃n。被不同Class Loader装蝲?/span>Class无法直接对话。直接对话会产生linkage错误。它们只能间接对话，比如通过InterfaceQ或者共同的Base Class?/span>
q有一个问题是Versioning。因?/span>Java?/span>Type里只有名字，所以当你看C?/span>Type的时候，你无法知道它是第一版，q是W二版。所以如果你需要第二版Q但?/span>Class loaderl你装蝲了第一版的时候，祷吧。也怸帝能救你?/span>
现在回过头来看看CLR的模型?/span>CLR?/span>Type包括两部分：Class name + Assembly Name?/span>Class name是和 Java?/span>TypecM的东西，是namespace?/span>Assembly?/span>Java没有的东ѝ?/span>Assembly Name的属性包?/span>Name, Version, Culture, PublicKey(Token)?/span> 如果两个Assembly有一个属性不一P那么它们p为是不一L。两?/span>Type如果有同LClass nameQ但?/span>Assembly Name不一L话，它们也认为是不一L?/span>
CLR?/span>Type引用L包括Class name ?/span> Assembly Name的。所?/span>CLR在寻找一?/span>Type的时候，主要是寻?/span>Assembly。找CAssembly之后Q?/span>CLR看看q个Assembly里有没有q个Class。有的话׃事大吉，没有的话是TypeLoadException?/span>
CLR区别Type主要?/span>Assembly?/span>Assembly?/span>PublicKey(Token)。别人无法冒充你。所以象Java里的namespace的问题就不存在了?/span>Assembly有自qVersion。你要第二版的时?/span>CLR不会装蝲W一版给你。所以象Java Class Loader那样的限Ӟ责Q和问题都不存在了。从q个角度上讲Q这正是Z?/span>CLR里没有象Java Class Loader那样的东ѝ?/span>
但ƈ不是说你׃能动态装载了Q而是说你动态装载的时候就不用考虑那些垃圾了?/span>
关于׃n的问题，因ؓ没有了你自己?/span>Class loaderQ所以Q?/span>Type都可以直接对话。同LType也不会因?/span>Class Loader不一栯被认ؓ不一栗?/span>
CLR Loader有自q规则怎么LAssembly。它先看GACQ再看你的程序目录。都没有的话它还有一?/span>AssemblyResolveEvent去问你，看你能不能提供。如果你要动态装载的话，你有Assembly.Load, Assembly.LoadFrom, Assembly.LoadFile, Assembly.Load(byte[])。你可以提供privateBinQ你也可以提?/span>codebase hint。你q能?/span>policy。MQ你想从哪找Q就可以d找。细节问题我׃多说了。你可以ȝMSDNQ?/span>Suzanne?/span>BlogQ?/span>Alan?/span>BlogQ和我的英文Blog.
l论Q?/span>CLR Loaderq比Java Class Loader要Secure, Powerful and Flexible?/span>
]]>
Java C#
byte code IL(字节码，中间语言)
jvm.dll mscrolib.dll,mscrojit.dll(虚拟?
JRE CLR(q行环境)
JDK .Net Framework(开发框?
package assembly(cdQ程序集)
一、关于类库的版本理问题
Java和C#代码q行要依靠其q行环境(JRE,CLR)和运行环境带的基cd(C#UCؓ配g或者程序集Assembly)Q此外还会有一些第三方? cd或者自己开发的cd。如果运行环境版本不一_或者引用的cd版本不一致都会带来程序不能正常运行。比如一个JavaE序是在JDK1.2上开发，? 果在JRE1.4上运行，一般情况下可以向下兼容Q但也有例外Q有些GUIE序在JDK1.4上面q行l果很可能会不同?
JRE的版本管?
Java的解军_法是每个E序自己携带一套JRE?
我的机器上已l被安装了好多套JRE和JDK?JDK包括了同版本的JREQ此外还包括有编译器和其它工?Q它们分别是Q?
BEA Weblogic Server 7.0 自带一?JDK1.3.1_02
我下载了一套最新的JDK1.4.1_02
JBuilder9自带一套JKD1.4.1_02
Oracle8.1.7自带一套JRE1.1.7
Ration Rose自带一套JDK1.3
DreamWeaver自带一套JDK1.3
6套JREQ每套JRE都被各自安装C同的目录Q不会互相媄响。当在控制台执行java.exeQ操作系l寻找JRE的方式如下：
先找当前目录下有没有JRE
再找父目录下有没有JRE
接着在PATH路径中找JRE
注册表HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\ 查看CurrentVersion的键值指向哪个JRE
最常用的是在PATH路径中找JREQ一般情况下Q自qE序q行之前都会先在批处理文仉面时设|PATHQ把自己用的JRE攑ֈPATH路径最前面Q所以肯定会q行自己带的JREQ不会造成版本混ؕ?
.Net Framework的版本管?
.Net Framework被固定安装在C:\Winnt\Microsoft.NET\Framework\v版本号\目录下，听说刚发行的.Net Framework1.1已经?.0做了很多改进Q也许在旧版本的.Net Framework开发的E序在往新版本上面迁Uȝ时候需要部分修攏V?
JRE的基cd
JRE自带的基cd主要是JRE\lib\rt.jarq个文gQ包括了Java2q_标准版的所有类库。和JRE的版本一致?
.Net Framekwork的核心类?
.Net Framekwork的核心类库被攄在C:\Winnt\assembly\gac\目录下，按照不同的名U空间放在不同目录中Q不像JRE打成了一个包。ƈ且可以同时存在不同的版本Q例如：
某类?.0版本 C:\Winnt\assembly\gac\名称\1.0\名称.dll
某类?.1版本 C:\Winnt\assembly\gac\名称\1.1\名称.dll
q样做，虽然很灵z，可以随时把类库更新到最新的状态，但是很容易带来版本管理的复杂度，造成版本不一致?
JREcd的查找方法和版本理
JRE中由ClassLoader负责查找和加载程序引用到的类库，基础cdClassLoader会到rt.jar中自动加载，其它的类库， ClassLoader在环境变量CLASSPATH指定的\径中搜烦Q按照先来先到的原则Q放在CLASSPATH前面的类库先被搜刎ͼJavaE序? 动之前徏议先把PATH和CLASSPATH环境变量讑֥QOS通过PATH来找JREQ确定基cdrt.jar的位|，JRE? ClassLoader通过CLASSPATH扑օ它类库。但有时候会出现q样的情况，希望替换基础cd中的cdQ那么也可以单的通过- Djava.endrosed.path=...参数传递给java.exeQ于是ClassLoader会先于基cd使用 java.endrosed.path参数指定路径的类库。因此Java的版本管理是非常单有效的Q也许很原始Q不q很好用Q简单就不容易出错?所? 我很奇怪Eric RamondZ么批评Java的类库管理机Ӟ他还居然批评Java的接口，令h怀疑他对Java的了解程?
.Net Framework的类库管理机?
.Net Framework的类库管理机制相当强大和复杂Q分为私有类库和׃ncd?
U有cd放在exeE序当前路径下，或其相对路径中，只有当前E序可见?
׃ncd需要在GAC(Global Assembly Cache)中注册，注册q程比较复杂Q首先要用工L成公开/U有密钥对，然后l合密钥和类库版本号q编Q最后用工h册到GAC中好以后,会被攑֜ "C:\Winnt\assembly\gac\cd的名U空间\版本号\"目录下，不同的类库版本在注册的时候会按照版本号分开攄Q?
某类?.0版本 C:\Winnt\assembly\gac\名称\1.0\名称.dll
某类?.1版本 C:\Winnt\assembly\gac\名称\1.1\名称.dll
也就是可以同时存在一个类库的n个版本，至于在程序中用哪个版本，在程序的配置文g中声明，CLR会根据声明来调用相应的版本的cd。我觉得.Net实现 Ҏ未免太复杂了一些，所有共享类库都塞到一个系l目录下Qƈ且同一个类库还有n个版本，来.NetW三方开发的cd逐渐丰富h以后Q?Netcd 的GAC也会来庞大，会不会也搞得和Windows注册表一样难以维护？软g发布到服务器上的时候，cd要再注册一ơ，服务器会逐渐形成一个庞大的? 状的GACQGAC里面存放着lg的n个版本。试想经q一D|间之后，C:\Winnt\assembly\gac\目录会越来越庞大Q有的组件甚xn 个版本都攑֜那里Q你又不敢随便删除，不知道是不是有程序需要用，我不明白MSZ么要把这么简单的事情搞到q么复杂Q?
lg所qͼJava的版本管理方式简单而有效，C#的版本管理方式功能强大，不过是不是太复杂了？会不会搞成第二个注册表一L东西Q?
二、虚拟机启动和加载类库的方式
Java的虚拟机启动和加载类?
在Console执行java.exe xxx命o以后Q如前所q的LJREQOS扑ֈJRE目录Q根据java.exe的传递参敎ͼ选择加蝲Server版的jvm.dllq是Client版的jvm.dllQ然后加载jvm.dllQ把控制权交ljvm.dll?
接下来，jvm.dllq行初始化，分配内存{等动作Q然后在CLASSPATH路径中寻找classQ找到class以后Q寻找class中的E序入口 点Main函数Q然后从Main函数执行E序Q在执行q程中，使用ClassLoader动态加载一pd引用到的cR当调用到nativeҎӞ jvm.dll告诉OS在JRE\bin目录下寻找某某DLL文gQ调入内存，于是实现了JNI调用?
.Net的虚拟机的启动推?
我对.Net的虚拟机的启动过E还一知半解，自己写了一些例E，q且用内存工h观察，推测.Net的运行机Ӟ先来抛砖引玉Q请熟悉Windowsq_~程的朋友指教?Net?个目录中的文件在执行的时候会被加?
1、C:\WINNT\Microsoft.NET\Framework\v版本号\
该目录下的mscorlib.dll,mscorrsn.dll,mscorwsk.dll,mscorjit.dll是核心DLLQ大概是q行虚拟机的 必要文gQ其中mscrolib.dll是入口点。此外，该目录下q有一?Net的System名称I间的ILcdQ与C:\Winnt\ assembly\gac\相应目录下的ILcd完全一Pq些是最核心的基cd?Net的编译器Q检查器{等工具软g也在该目录，推测System 名称I间的核心类库之所以在q个目录下copy一份是因ؓ作ؓ.Net的编译器{工LU有cd之用?
2、C:\Winnt\assembly\gac\
该目录下攄.Net׃ncdQ如前所q?
3、C:\Winnt\assembly\nativeimages_.Net版本号\
在该目录下也有一些以System名称I间开头的核心cdQ推是MSZ加快CLR的执行效率把核心cdq行本地化，~译为native image的同名DLL。可以观察到该目录下的同名DLL文gQ比GAC目录下的同名DLL文g体积大，可能是因为link底层DLL库的~故?
某核心类?C:\Winnt\assembly\nativeimages_.Net版本号\名称I间\.Net版本号_散列码\名称.dll
另外值得注意的地Ҏ有两个mscorlib.dll
1、C:\WINNT\Microsoft.NET\Framework\v版本号\mscrolib.dll (1.88MB)
2、C:\WINNT\assembly\NativeImages1_v版本号\mscorlib\版本号__散列码\mscrolib.dll (3.07MB)
mscrolib.dll (1.88MB)q是一个IL码的版本Q所以映了一个native的版本的mscrolib.dll (3.07MB)Q来加快CLR的速度?
当IL的exeE序被双L行时QOS LoaderdE序Q识别出是ILQ根据IL内部的引用定义，加蝲mscorlib.dllQ而mscorlib.dll也是ILQ内部引用C:\ winnt\system32\mscoree.dllQ于是再加蝲mscoree.dllQ然后把控制权交lmscoree.dllQ? mscoree.dll接着加蝲mscrorsn.dllQmscrowsk.dllQmscrojit.dllQؓ了加快mscorlib.dll的调 用，加蝲mscorlib.dll的native image版本Q然后由mscorlib.dll接管控制?不知道这两个mscorlib.dll是如何来上管ILQ下qnative code的？)最后寻找IL码程序的入口点Main函数Q开始执行程序，在执行过E中Q用Class Loader动态加载一pd引用到的c，在当前\径下Q在׃ncd的GAC中查扄{?
q里和jvm.dll不同的一ҎQjvm.dll加蝲的基cd和加载其它类库方式完全一P全部都是字节码的class。而mscrolib.dll 加蝲以System名称开头的核心cd的时候，使用了“不正当竞争手法”。mscrolib.dll从GAC中加载共享核心类库之后，又C:\Winnt \assembly\nativeimages_.Net版本号\名称I间\ 目录下加载了核心cd的native版本Q这样一来，自然CLRq行h要快多了。特别是囑Ş囑փcd全部都有native映射版本Q所以CLR上运? GUI焉能不快Q?
ҎCLR和JRE的加载过E，比较不同的地Ҏmscorlib.dll和System核心cd都有一个native imageQ可能这是CLRq行速度比较快的一个主要原因吧?
分析完以后有一个特别明昄感受QJava的底层运行机制设计的特别单，?Net的底层运行机制设计的特别复杂。但是在企业层刚好相反，J2EE设计的特别复杂，?Net却设计的特别单，真是有意思！
Java的底层机制设计虽然简单，但是很健壮，.Net设计使得它的CLR速度快，cd理功能强大Q但是不是比Java更优UQ还要等以后慢慢看了?br>
REQ?br>
我查了一下?Net Essential》这本书Q上面提到这L说法?
MS更新了Windows各个版本的OS LoaderE序Q得OS Loader可以识别.Net PE格式的exe文gQ当执行Windows Native PE格式的exe文g的时候，OS Loader按照以往的方式加载系lDLL。如果是.Net PE格式的exe文gQOS Loader加蝲mscorlib.dllQ然后把控制权交lmscorlib.dll?br>
]]>
]]>
]]>
 |
| 国Uq《时间机器》剧?/td> |
澛_利亚U学家保|hl斯的科学研I包括黑z、量子场论、宇宙v源、意识的本质和生命v源等诸多涉及人类和宇宙本源的问题。他曄带领一个研 I小l，得出光速在变化的结论；他曾l写q不关于时间的书；如果他设想的一切都成ؓ现实Qh可以回到q去见一见自q老爷爗老奶Ӟ也可以到未来看一 看自q重孙子、重孙女Q关于时I的基本定义p改写Q物理学的根基就会动摇。
“有限时间旅行”肯定可?/b>
人类乐于梦想Q也盼望知晓q去和未来。若要将历史和命q活生生地展现在我们面前Q时间旅行似乎是个最为简便的Ҏ。然而，旉机器的制造仍然停 留在qL阶段Q而即便是qLQ也多生于说家和电媄Ҏ师的手中Q少有h知科学家Ҏ间机器的具体构想。保|hl斯是n誉世界的理论物理学家Q他军_ 当第一个吃螃蟹的hQ尝试制造时间机器，哪怕只是“理Z的制造”?/p>
要制造时间机器首先需要弄清楚的问题是Q你惛_到过去还是飞到未来。在戴维斯看来，在时间中到未来旅行是很容易的Q如果你接近于光速运动或者n处强大的引力ZQ会感到旉逝得比其他h更缓慢——你q入了他们的未来?/p>
飞向未来的旅行又叫“有限时间旅行”。保|hl斯在《怎样刉时间机器》的开头非常肯定的提出Q“有限时间旅行”是可行的，但回CQ何时代的“无限时间旅行”只是“有可能可行”?/p>
虫洞Q回到过ȝ关键
爱因斯坦的相对论允许q一旅行发生在特定的时空l构里：一个旋转的宇宙Q一个旋转的׃Q以及非常著名的虫洞——一条诏I空间和旉的隧道。也是_只要能够建造一个稳定的虫洞Q就可以跨越旉和空间。那么，到底什么是虫洞Q它和黑z有什么联pdQ?/p>
在斯蒂芬·霍金的《时间简双Ӏ里有这L解释Q虫z是q接宇宙遥远区域间的时空l管Q它可以把^行的宇宙或者婴儿宇宙连接v来，q提供时间旅行的可能性。而黑z是时空的一个区域，那里引力是如此之强，以至于Q何东西，甚至光都不能从该处逃逸出来?/p>
在戴l斯的计划里Q徏造一个虫z要?步：
W一步，L或徏立一个虫z，开辟一个隧道用来连接太IZ两个不同的区域?/p>
W二步，使虫z稳定下来。由量子产生的负能量Q虫z便允许信号和物体安全地I越它。负能量会抵制虫z变为密度无I大或接q无I大。换句话_它阻止了虫洞演变成黑z?/p>
W三步是牵引虫洞。一艘具有高度先q技术的太空船将虫洞的入口互相分d。如果两个端口都攄在空间中合适的地方Q那么时间差保持恒定状态? 假设q一差值是10q_一名宇航员从一个方向穿虫z，他将跛_10q后的未来，反之Q宇航员若是从另一方向I越虫洞Q他蟩?0q前的过厅R?/p>
旉机器的悖?/b>
假如技术上的诸多难题都被克服了Q时间机器的生会打开充满悖论的潘多拉盒子。对于这些，戴维斯也表现Z丝忧虑。他_“我本h不打把? 描述的时间旅行和其它控制自然的行为区分开来。所有的技术都在以某种方式q预自然。在一些科qd说里Q有人通过回到q去而改变了现状。这U事出现在小说里 当然无伤大雅Q但如果发生在现实中会带来严重的伦理问题。谁l你回到q去改变历史的权利？?/p>
既然q去、现在和未来紧密联系Q过去能影响现在Q那么现在媄响过d逻辑上也说得通。如果不能想q什么就q什么，人好不容易有了在旉中穿梭的自由Q却又失M行动的自由，眼睁睁看着历史从nҎq，却无力改变什么，岂不是一个巨大的损失Q?/p>
ҎQ戴l斯l出的解x案是“多宇宙”理论——世界不是只有一个，而是有许多^行的世界。你回到q去Q但那不是你自己的世界，而是和你的历史相似的世界。这P即便你打M自己的母Ԍ她在那个世界也的死了，但当你回到未来时Q她依然zd好好的?/p>
q种xq乎疯狂Q但除了戴维斯外q有许多著名物理学家怿有^行世界的存在。在《时间简双Ӏ里Q霍金这栯Q解x间旅行的其他可能的方法是
选择历史假想。其思想是，当时间旅行者回到过去，他就q入和历史记载不同的另外的一个历史中厅R这P他们可以自由地行动，不受和原先的历史怸致的U?
束。如果这P回到q去和做一场梦又有什么区别？
]]>