stand·ard - [stan-derd]


  1. something established by authority, custom, or general consent as a model, example, or point of reference standard of the reasonable person>
  2. something established by authority as a rule for the measure of quantity, weight, extent, value, or quality
  3. the basis of value in a monetary system


  1. serving as a basis of weight, measure, value, comparison, or judgment.
  2. of recognized excellence or established authority: a standard reference on medieval history.


1125-75; ME < OF, prob. < Frankish *standord (cf. G Standort standing-point), conformed to -ard

Related forms


1, 3. gauge, basis, pattern, guide. Standard, criterion refer to the basis for making a judgment. A standard is an authoritative principle or rule that usually implies a model or pattern for guidance, by comparison with which the quantity, excellence, correctness, etc., of other things may be determined: She could serve as the standard of good breeding. A criterion is a rule or principle used to judge the value, suitability, probability, etc., of something, without necessarily implying any comparison: Wealth is no criterion of a person's worth.


  1. standard. (n.d.). Online Etymology Dictionary. Retrieved November 1, 2008, from website:
  2. standard. (n.d.). Merriam-Webster's Dictionary of Law. Retrieved September 17, 2010, from website:

Minimal Independent Deploy Unit (MIDU)

Moved to new wiki system at

PowerShell Code Style Guide

Moved to new Wiki Service:

Project Management

It is easy to just grab some materials and start hammering a new patio to a house or to open an integrated development environment (IDE) and begin writing code using all the advanced snippet libraries to create a new application. However, to build something complex such as a complete house, or solid application requires more work than most people, including developers, understand or even believe.

Solid high quality results only come with focused disciplined effort. The distinction between an amateur and professional in any field is the commitment to discipline. Success is 80% attention to details and 20% luck. Since luck is really the coalition of thousands of variables it is uncontrollable, but still semi-predictable. Ignoring what cannot be controlled project success is governed through good planning, organizing, and management. In other words the all the skills of Project Management being focused on a set of objectives resulting in the highest chance for success.

A project is any stated (or envisioned) goal which requires more than a couple of tasks, with a defined beginning, an optional due date, and a defined "done criteria" measurement. By definition a project is temporary in nature in contrast to normal business operations (which are repetitive, functional work to produce products or services.) In practice, the management projects is very different from the management of standard operations and therefore require specific techniques and tools.

Source Repository Layout Architecture Considerations

A survey of various source code management layouts is located in the Software Professional Tidbits book at Repository Layouts.

== General Layout Guidelines ==

* Don't introduce the product into the source layout. Products will change, as will the names of modules, the repository core building blocks should remain constant.
* Support versioning on modules. As modules and products develop there will be a need to attach versions to the each release of a given module and product.
* Shared code is treated like any other sub-system or module. It is okay to keep shared code alongside non-shared code.
* Keep interfaces separate from implementation.
* Individual module/component internal layout is more flexible and should fit the logical structure of the module or needs of the developer.

== Questions To Consider ==

* Should interfaces be packaged as separate modules? (e.g. product interfaces, domain interfaces)
* How should extension points be packaged?
* Is configuration shared across all modules or is it tied to a module?
* Where should shared XML schema definitions be kept?
* Is there a way to enforce the allowed module dependencies with the layout?
* What layers make sense for the given product?
* Are there any platform agnostic resource definitions? (e.g. queues)

== NOD Source Layout ==

The NOD source code repositories are driven by three primary elements, each one creating a branch level.

=== Repository Structure ===


== Top Level: Driven by Release Strategy ==

At the top level, the desired control of releases (public or private) is reflected in the branching strategy, and thus the source code version control repository structure.

== Mid Level: Driven by Product Line Strategy ==

The second level reflects the desired granularity of releases (major/minor at subsystem granularity, patches at module granularity) is reflected in the branching strategy. This results in the following requirements:

* Each subsystem will live within its own "codeline"
* Each codeline must be self-contained; i.e. no source or build level sharing across codelines
* Sharing across codelines is achieved by leveraging maven repositories and published binaries

Example: A product line such as the wiki module for Drupal might be called "Naturally Wiki" which when released into beta, and then 1.0, 1.1, and 2.0 would have branches like:


== Third Level: Driven by Product Architecture ==

The next level is driven by generic architectural design for the product line. The various components are individually named according to design but assigned a prefix according to the following guidelines:

* base-<base module> is a pseudo-subsystem consisting of services used by multiple subsystems. It is considered very desirable to only put things into base as a last resort, and for clearly identifiable and obvious shared subsystem-wide services such as Logging and Configuration. It is very easy to get trapped into a bad situation of poor logic definition if this is used merely to avoid code duplication. Base modules may either follow the normal pattern for a subsystem module, or use the subsystem structure itself in the case of more elaborate base projects.
* product-<product> are considered to be a possibly-fluid grouping of subsystems into an interestingly shippable entity. They contain end to end tests specific to its grouping of subsystems as well as example projects for assembling deployable solutions.
# application-<module>/application creates a MIDU (e.g. skinny WAR, JAR, or Python egg) and CONTAINS ALL assets needed for the application, which are also provided in a separate application components/sub-modules (see next).
# application-<module>/components creates a specific component module (e.g. a JAR) containing the code specific to the application.
# application-<module>/dependency a grouping (e.g. a POM) of all of the application's "external" dependencies so they may be referenced in an assembly project to be included in the distribution assembly. Both the application project and the distribution project depend on the dependency project.
* subsystem-<subsystem> are considered to be complete services that by themselves do to provide a complete solution, but are intended to be wired together to create unique solutions. Examples of a subsystem would be an access control list service, or a user contribution accumulation points system.
* subsystem-<subsystem>/configuration contains the configuration definition and default values for the subsystem.
* subsystem-<subsystem>/resources contains the resources for the named subsystem.
* subsystem-<subsystem>/test contains named directories for specific integration testing systems such as FitNesse.
* subsystem-<subsystem>/test/itest is a pseudo-module consisting of cross module xUnit integration tests within a subsystem. Such integration tests may depend on the presence of environmental resources such as running databases. For that reason, as well as for build speed, such tests should only be run if a Maven profile is explicitly enabled.
* subsystem-<subsystem>/interfaces/extension-<module> contains the Extension Point Interfaces for the subsystem. It produces a MIDU (jar, perl module, etc.) per interface that is expected to be available in all tiers.
* subsystem-<subsystem>/interfaces/integration-<module> contains the Integration Point Interfaces for the subsystem. It produces a MIDU (jar, perl module, etc.) per interface that is expected to be available in all tiers.
* subsystem-<subsystem>/plugins contains any custom plugins which are specific to the functionality provided by the subsystem and intended for use outside the subsystem.
* suite-<suite> are considered to be a possibly-fluid grouping of products into an interestingly shippable entity. They contain end to end tests specific to its grouping of products as well as example projects for assembling deployable solutions.
* tools/plugins contains IDE/Maven projects for custom plugins that used for the build and assembly automation, these are not specific to product functionality and may not have dependencies on product artifacts.

Python Coding Style

moved to new wiki service at