Abstract: The techniques described herein provide software testing that may concurrently process a user request using a live version of software and a shadow request, which is based on the user request, using a shadow version of software (e.g., trial or test version, etc.). The live version of software, unlike the shadow version, is user-facing and transmits data back to the users while the shadow request does not output to the users. An allocation module may vary allocation of the shadow requests to enable a ramp up of allocations (or possibly ramp down) of the shadow version of software. The allocation module may use allocation rules to dynamically initiate the shadow request based on various factors such as load balancing, user attributes, and/or other rules or logic. Thus, not all user requests may be issued as shadow requests.

Abstract: Computer applications may generate event data based on a large volume of different types of record data. Described herein are systems, methods and devices for providing website recommendations using the event data. In one example, using the event data, a computing node generates the website recommendations within a designated amount of time after the generation of the record data.

Abstract: This disclosure is directed in part to testing of different versions of software or software components (software versions) and analyzing results of use (e.g., user interaction) of the different software versions. The techniques described herein provide software testing that varies the allocation to enable a ramp up of allocations to/from another software version. The allocation module may use allocation rules to assign requests to each software version based on various factors such as load balancing, user attributes, past user assignment, and/or other rules or logic. An analysis of the different software versions may include an analysis of system performance resulting from operation of each software version. An analysis may determine attributes of each user and then allocate the user to a software version based on at least some of the determined attributes.

Abstract: Computer applications may generate a large volume of different types of record data. In one example, the large volume of record data may represent millions of different processes occurring every second. Described herein are systems, methods and devices for generating parsed data based on the large volume of record data. The parsed data may be consumed by computing nodes within a designated amount of time from the generation of the record data.

Abstract: The techniques described herein provide software testing that may concurrently process a user request using a live version of software and a shadow request, which is based on the user request, using a shadow version of software (e.g., trial or test version, etc.). The live version of software, unlike the shadow version, is user-facing and transmits data back to the users while the shadow request does not output to the users. An allocation module may vary allocation of the shadow requests to enable a ramp up of allocations (or possibly ramp down) of the shadow version of software. The allocation module may use allocation rules to dynamically initiate the shadow request based on various factors such as load balancing, user attributes, and/or other rules or logic. Thus, not all user requests may be issued as shadow requests.

Abstract: Computer applications may generate event data based on a large volume of different types of record data. Described herein are systems, methods, and devices for enabling a computing node to implement new functions for dynamically consuming the event data. In one example, the computing node may implement a new function using an expression language, without modifying predefined hard coded functions.

Abstract: Technologies are described herein for incorporating streaming and/or sampling in real-time log analysis. Representative samples of log data are extracted from the log files on a number of monitored hosts and streamed in real-time to log processors for processing. The log processors accumulate and process the representative samples of log data, and track a data completeness value representing an indication of a proportion of total log data represented by the representative samples received. The representative samples of log data are merged and collated. Estimated metrics are calculated from the merged and collated representative samples and the data completeness, and the estimated metrics are published to consumers in near real-time.

Abstract: A location data structure represents a location in a number of different ways, and may include a map view scale appropriate for rending the map. A map view data structure contains sufficient information to derive a number of independent descriptions of a map view. A route data structure may be used at any point in the route calculation and rendering process, and includes a locations field that includes the two-end points of the route, a calculated route data field representing a calculated route between the two end-points, an options field that specifies the options used or to be used to calculate the route, a driving directions field that represents driving directions for the route, and an identity data field that specifies whether the route data structure is a request to calculate a route, a response to a route calculation request, or a rendering request.

Abstract: A method and system for generating driving directions composes computer-based instructions that emulate a human driving perspective. Language-based instructions guide a driver along a route that encompasses a sequence of roads and intersections. An algorithm applies rules based on human perception to route components. The algorithm diagnoses road name changes so that instructions are clear and concise. The algorithm analyzes road and intersection geometry at confusing areas, such as road forks, roundabouts, ferry crossings, cloverleaf interchanges, and ramps, to generate instructions that conform to a driver's natural perspective. The algorithm analyzes the configuration of an intersection with respect to a driver's field of view to compose a clear and concise instruction. When appropriate, the algorithm produces compound instructions for adjacent intersections.

Abstract: A location data structure represents a location in a number of different ways, and may include a map view scale appropriate for rending the map. A map view data structure contains sufficient information to derive a number of independent descriptions of a map view. A route data structure may be used at any point in the route calculation and rendering process, and includes a locations field that includes the two-end points of the route, a calculated route data field representing a calculated route between the two end-points, an options field that specifies the options used or to be used to calculate the route, a driving directions field that represents driving directions for the route, and an identity data field that specifies whether the route data structure is a request to calculate a route, a response to a route calculation request, or a rendering request.