Abstract: A safety accessory for a tilting propulsion device or similar device is described. The safety accessory prevents the tilting propulsion device from pitching the user from the tilting propulsion device when mounting the tilting propulsion device. The accessory is attached to the tilting propulsion device and will come in contact with the ground if the tilting propulsion device pitches forward, stopping movement and allowing the user to regain his balance.

Abstract: Techniques for efficiently isolating software regressions are provided. A system test tool determines that a particular regression is present in a particular build of a software system, but not in a baseline build. Using historical data, the tool determines, for each of a plurality of intermediate builds between these two builds, a likelihood that that intermediate build introduced the particular regression. A particular intermediate build can be identified as a build to be tested. Here, the particular intermediate build comprises a plurality of layered putbacks, each of which putbacks comprises one or more code changes in the software system. The tool determines, for each putback, a likelihood that that putback introduced the particular regression. A particular putback in the plurality of putbacks may be selected as a putback to be tested. In some embodiments, the particular putback is the putback that has the greatest likelihood of introducing the particular regression.

Abstract: Techniques for efficiently isolating software regressions are provided. In one embodiment, it is determined that a particular regression is present in a particular build of a software system. A set of candidate code components that may have caused the particular regression is identified. In accordance with an order established based on historical data for the software system, one or more intermediate builds each involving some subsets of the candidate code components may be tested to identify a set of suspect code components that caused the particular regression. For each candidate code component that is not in the set of suspect code component, a likelihood factor associated with that candidate code component is decremented.

Abstract: System and method for batch-tuning multiple software components of an intelligent device. An intelligent device may include tunable components each associated with a tunable configuration file. A batch tuner may be used to generate batch configuration documents from the configuration files. The batch tuner may also be used to generate configuration files from a batch configuration document. In one embodiment, the batch configuration document and the configuration files are markup language documents. In one embodiment, an XML document type definition (DTD) may be used as the method of information exchange. In one embodiment, the batch tuner may use an API (e.g. DOM or SAX API) to access the batch configuration document and configuration files. In one embodiment, each component may be associated with an executable module conforming to the API, and the batch tuner may call the module for the component to generate the configuration file.

Abstract: Techniques for efficiently isolating software regressions are provided. In one embodiment, it is determined that a particular regression is present in a particular build of a software system. A set of candidate code components that may have caused the particular regression is identified. In accordance with an order established based on historical data for the software system, one or more intermediate builds each involving some subsets of the candidate code components may be tested to identify a set of suspect code components that caused the particular regression. For each candidate code component that is not in the set of suspect code component, a likelihood factor associated with that candidate code component is decremented.

Abstract: Techniques for efficiently isolating software regressions are provided. A system test tool determines that a particular regression is present in a particular build of a software system, but not in a baseline build. Using historical data, the tool determines, for each of a plurality of intermediate builds between these two builds, a likelihood that that intermediate build introduced the particular regression. A particular intermediate build can be identified as a build to be tested. Here, the particular intermediate build comprises a plurality of layered putbacks, each of which putbacks comprises one or more code changes in the software system. The tool determines, for each putback, a likelihood that that putback introduced the particular regression. A particular putback in the plurality of putbacks may be selected as a putback to be tested. In some embodiments, the particular putback is the putback that has the greatest likelihood of introducing the particular regression.

Abstract: A method is provided for checking a computer system configuration in which a first check file is provided (28). A second check file is compiled (34) from the computer system configuration. The first and second check files are compared against each other (36) and a computer system configuration is approved (38) in dependence on the result of this comparison. This process can take place at the point of manufacture or at a customer installation or both.

Abstract: A method is provided for checking a computer system configuration in which a first check file is provided (28). A second check file is compiled (34) from the computer system configuration. The first and second check files are compared against each other (36) and a computer system configuration is approved (38) in dependence on the result of this comparison. This process can take place at the point of manufacture or at a customer installation or both.

Abstract: System and method for batch-tuning multiple software components of an intelligent device. An intelligent device may include tunable components each associated with a tunable configuration file. A batch tuner may be used to generate batch configuration documents from the configuration files. The batch tuner may also be used to generate configuration files from a batch configuration document. In one embodiment, the batch configuration document and the configuration files are markup language documents. In one embodiment, an XML document type definition (DTD) may be used as the method of information exchange. In one embodiment, the batch tuner may use an API (e.g. DOM or SAX API) to access the batch configuration document and configuration files. In one embodiment, each component may be associated with an executable module conforming to the API, and the batch tuner may call the module for the component to generate the configuration file.