DOCSLIB.ORG

Script Insight: Using Models to Explore Javascript Code from the Browser View

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Script Insight: Using Models to Explore Javascript Code from the Browser View Script InSight: Using Models to Explore JavaScript Code from the Browser View Peng Li and Eric Wohlstadter University of British Columbia {lipeng,wohlstad}@cs.ubc.ca Abstract. As Web programming standards and browser infrastructures have matured, the implementation of UIs for many Web sites has seen a parallel increase in complexity. In order to deal with this problem, we are researching ways to bridge the gap between the browser view of a UI and its JavaScript implementation. To achieve this we propose a novel JavaScript reverse- engineering approach and a prototype tool called Script InSight. This approach helps to relate the semantically meaningful elements in the browser to the lower-level JavaScript syntax, by leveraging context available during the script execution. The approach uses run-time tracing to build a dynamic, context- sensitive, control-flow model that provides feedback to developers as a summary of tracing information. To demonstrate the applicability of the approach we present a study of an existing open-source Web 2.0 application called the Java Pet Store and metrics taken from several popular online sites. Keywords: Reverse-Engineering, Software Maintenance, Rich Internet Applications, JavaScript. 1 Introduction The user interface (UI) is a key aspect of most Web sites. As Web browser programming standards such as JavaScript and the W3C Document Object Model (DOM) have matured, the implementation of UIs for many sites has seen a parallel increase in complexity. These rich Web applications have the advantage of providing a seamless and interactive experience for end-users. However, these applications also require more development effort to build and maintain than older Web UI. As the Web has become more interactive and complex, we are researching a more interactive, model-based approach for Web application reverse-engineering and debugging. Most existing work on modeling of UI-intensive Web applications focuses on development but not specifically maintenance and debugging. For example, [1] introduces a framework for the integration of presentation components in mashup applications. Trigueros et al. present a model driven approach, the RUX-Model, for the design of rich Internet applications [2]. Valderas et al. introduce an approach to support the coordinated work between Web UI designers and analysts during the development of a Web application [3]. In [15], Rossi et al. use a model-driven approach to transform conventional Web applications into rich Internet applications M. Gaedke, M. Grossniklaus, and O. Díaz (Eds.): ICWE 2009, LNCS 5648, pp. 260 – 274, 2009. © Springer-Verlag Berlin Heidelberg 2009 Script InSight: Using Models to Explore JavaScript Code from the Browser View 261 by applying refactoring at the model level. Meliá et al. propose a model-driven development methodology which extends a traditional Web modeling methodology for use with the Google Web Toolkit [16]. Some research in software maintenance and reverse-engineering has been used for testing of Ajax applications [14], but not specifically for interactive debugging, as we focus on in this paper. As with any complex software development task, creating a user interface requires an iterative cycle of design and implementation. Starting with an initial design, an interface would first be prototyped and then refined over several cycles into a final product. At each stage, some design decisions may need to be reconsidered and the implementation adjusted accordingly. The UI might even evolve after the release of an application in order to fix bugs or add new features. After each cycle, developers can determine the quality of the current application by executing the implementation and evaluating the UI appearance and functionality in a Web browser. If they notice anything wrong with the browser view of the UI, they would need to map the problem back to some part of the implementation, to enact the appropriate change. Unfortunately, reversing engineering a rich interactive Web page and mapping the appearance or behavior of some element in the Web page to the corresponding implementation can be quite difficult. This is because today’s Web UI are stateful and reactive. Their appearance and behavior vary over time based on mutations of state made from JavaScript. This problem is exacerbated by the fact that a developer working on the UI might not have written the original code for all parts of the Web site. In that case, they may need to dig through unfamiliar code to try and reverse- engineer the source. This process is especially difficult since code for some systems on the Web is poorly documented. As described by Hassan et al. [4], “Currently, [code] inquiries can only be answered by scanning the source code for answers using tools such as grep, consulting documentation, or asking senior developers.” In order to deal with this problem, we are researching an interactive approach to bridge the gap between the browser view of a UI and the JavaScript piece of the implementation. This is motivated by the fact that the browser view is usually easy to understand and semantically meaningful, unlike the implementation code. We want to help developers use the live UI as an entry-point into the lower-level implementation details. To achieve this, we propose a novel JavaScript tracing approach. To a first approximation, when a change is made by a script statement to a visual DOM attribute (e.g. color, height, etc...), we record a link between the effected browser element and the code responsible. The intuition is that a developer can now easily navigate through the code by hyperlinking directly from browser elements. However, a basic implementation of this approach is vulnerable to two problems. First, mapping semantically meaningful events, such as the mutation of a visual attribute directly to a location in the source code (e.g. a statement) may not be helpful, because that one statement might be reused for several different purposes in the execution of the script. For example, informing a developer that an attribute was changed in a “setter” method for that attribute provides little useful information. The “setter” method could be called many times in the execution of a script, in different contexts, for a variety of different purposes. 262 P. Li and E. Wohlstadter For this reason we are researching the use of context-sensitivity to help provide a mapping. A context-sensitive approach captures not only the execution of individual statements, but also the state of the call stack, which can help distinguish between multiple executions of the same statement. Second, the visual behavior of a Web page (e.g. the way widgets are animated) is often achieved by a set of coordinated DOM attribute mutations. For example, a button’s appearance may change to reflect the button is active when a panel is closed, and change again to reflect it is inactive when the panel is open. The changes to the button appearance and panel appearance have a causal relationship. If a developer wants to change the widget animation they may need to make coordinated changes to several DOM nodes. For this reason we are researching the use of a custom control- flow model, the DOM mutation graph (DMG), that developers can use to leverage their understanding of these causal relationships, seen in the browser view, in mapping from the browser view to script source code. To demonstrate our approach of using this DMG to explore script code, we present a study of an existing open-source Web 2.0 application called the Java Pet Store [9] and metrics taken from several popular online sites. We show how this model is used to understand animation effects in the application which require coordinated changes to several page elements. The metrics taken from other pages provide evidence supporting the need for context-sensitivity in Web application reverse-engineering. The rest of the paper is organized as following: Section 2 presents a motivating example and an overview of our approach, Section 3 presents technical details, Section 4 presents metrics from online sites, Section 5 presents a further detailed example, and in Section 6 we give related work and we conclude in Section 7. 2 Motivating Example and Approach Overview In order to motivate our approach, we use a case-study of an existing open-source Web application called Java Petstore 2.0 (henceforth, JPS). This online pet store offers the end-user several interactive widgets to control the application, as shown in Figure 1. Here we see the “Catalog Browser” page from which the end-user can browse prospective pets. This one page alone makes use of 1232 lines of JavaScript code spread across 3 files. Running down the left-side of the page is an accordion bar. This widget is a stylized tree-view for browsing categories of pets and their respective sub-categories (e.g. the specific kinds of cats). The table rows for the categories interactively expand/ deflate to reveal/hide sub-categories when the mouse cursor is positioned/removed from a category name. This “accordion” animation requires JavaScript programming to mutate the DOM in an event loop. In Figure 1, the “Cats” row is expanded and the other categories remain deflated. Consider the perspective of a front-end developer who would like to make changes to this Web page. They have to remember or understand how the 1232 lines of code is mapped to elements of the page and their behavior. In the original JPS, each accordion row is expanded and deflated at a constant speed. Here we consider a change task where a front-end developer wants to change the animation to accelerate at a decreasing/increasing rate when a row is expanding/ deflating. During the task the developer is confronted with three problems. Script InSight: Using Models to Explore JavaScript Code from the Browser View 263 Fig.
Load more

Recommended publications
  • Interaction Between Web Browsers and Script Engines
    IT 12 058 Examensarbete 45 hp November 2012 Interaction between web browsers and script engines Xiaoyu Zhuang Institutionen för informationsteknologi Department of Information Technology Abstract Interaction between web browser and the script engine Xiaoyu Zhuang Teknisk- naturvetenskaplig fakultet UTH-enheten Web browser plays an important part of internet experience and JavaScript is the most popular programming language as a client side script to build an active and Besöksadress: advance end user experience. The script engine which executes JavaScript needs to Ångströmlaboratoriet Lägerhyddsvägen 1 interact with web browser to get access to its DOM elements and other host objects. Hus 4, Plan 0 Browser from host side needs to initialize the script engine and dispatch script source code to the engine side. Postadress: This thesis studies the interaction between the script engine and its host browser. Box 536 751 21 Uppsala The shell where the engine address to make calls towards outside is called hosting layer. This report mainly discussed what operations could appear in this layer and Telefon: designed testing cases to validate if the browser is robust and reliable regarding 018 – 471 30 03 hosting operations. Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Elena Boris Ämnesgranskare: Justin Pearson Examinator: Lisa Kaati IT 12 058 Tryckt av: Reprocentralen ITC Contents 1. Introduction................................................................................................................................
    [Show full text]
  • Defensive Javascript Building and Verifying Secure Web Components
    Defensive JavaScript Building and Verifying Secure Web Components Karthikeyan Bhargavan1, Antoine Delignat-Lavaud1, and Sergio Maffeis2 1 INRIA Paris-Rocquencourt, France 2 Imperial College London, UK Abstract. Defensive JavaScript (DJS) is a typed subset of JavaScript that guarantees that the functional behavior of a program cannot be tampered with even if it is loaded by and executed within a malicious environment under the control of the attacker. As such, DJS is ideal for writing JavaScript security components, such as bookmarklets, single sign-on widgets, and cryptographic libraries, that may be loaded within untrusted web pages alongside unknown scripts from arbitrary third par- ties. We present a tutorial of the DJS language along with motivations for its design. We show how to program security components in DJS, how to verify their defensiveness using the DJS typechecker, and how to analyze their security properties automatically using ProVerif. 1 Introduction Since the advent of asynchronous web applications, popularly called AJAX or Web 2.0, JavaScript has become the predominant programming language for client-side web applications. JavaScript programs are widely deployed as scripts in web pages, but also as small storable snippets called bookmarklets, as down- loadable web apps,1 and as plugins or extensions to popular browsers.2 Main- stream browsers compete with each other in providing convenient APIs and fast JavaScript execution engines. More recently, Javascript is being used to program smartphone and desktop applications3, and also cloud-based server ap- plications,4 so that now programmers can use the same idioms and libraries to write and deploy a variety of client- and server-side programs.
    [Show full text]
  • Typescript-Handbook.Pdf
    This copy of the TypeScript handbook was created on Monday, September 27, 2021 against commit 519269 with TypeScript 4.4. Table of Contents The TypeScript Handbook Your first step to learn TypeScript The Basics Step one in learning TypeScript: The basic types. Everyday Types The language primitives. Understand how TypeScript uses JavaScript knowledge Narrowing to reduce the amount of type syntax in your projects. More on Functions Learn about how Functions work in TypeScript. How TypeScript describes the shapes of JavaScript Object Types objects. An overview of the ways in which you can create more Creating Types from Types types from existing types. Generics Types which take parameters Keyof Type Operator Using the keyof operator in type contexts. Typeof Type Operator Using the typeof operator in type contexts. Indexed Access Types Using Type['a'] syntax to access a subset of a type. Create types which act like if statements in the type Conditional Types system. Mapped Types Generating types by re-using an existing type. Generating mapping types which change properties via Template Literal Types template literal strings. Classes How classes work in TypeScript How JavaScript handles communicating across file Modules boundaries. The TypeScript Handbook About this Handbook Over 20 years after its introduction to the programming community, JavaScript is now one of the most widespread cross-platform languages ever created. Starting as a small scripting language for adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both frontend and backend applications of every size. While the size, scope, and complexity of programs written in JavaScript has grown exponentially, the ability of the JavaScript language to express the relationships between different units of code has not.
    [Show full text]
  • Learn Javascript
    Learn JavaScript Steve Suehring Copyright © 2012 by Steve Suehring All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. ISBN: 978-0-7356-6674-0 1 2 3 4 5 6 7 8 9 LSI 7 6 5 4 3 2 Printed and bound in the United States of America. Microsoft Press books are available through booksellers and distributors worldwide. If you need support related to this book, email Microsoft Press Book Support at [email protected]. Please tell us what you think of this book at http://www.microsoft.com/learning/booksurvey. Microsoft and the trademarks listed at http://www.microsoft.com/about/legal/en/us/IntellectualProperty/ Trademarks/EN-US.aspx are trademarks of the Microsoft group of companies. All other marks are property of their respective owners. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred. This book expresses the author’s views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its resellers, or distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by this book. Acquisitions and Developmental Editor: Russell Jones Production Editor: Rachel Steely Editorial Production: Dianne Russell, Octal Publishing, Inc.
    [Show full text]
  • Concrete Types for Typescript
    Concrete Types for TypeScript Gregor Richards1, Francesco Zappa Nardelli2, and Jan Vitek3 1 University of Waterloo 2 Inria 3 Northeastern University Abstract TypeScript extends JavaScript with optional type annotations that are, by design, unsound and, that the TypeScript compiler discards as it emits code. This design point preserves programming idioms developers are familiar with, and allows them to leave their legacy code unchanged, while offering a measure of static error checking in annotated parts of the program. We present an alternative design for TypeScript that supports the same degree of dynamism but that also allows types to be strengthened to provide correctness guarantees. We report on an implementation, called StrongScript, that improves runtime performance of typed programs when run on a modified version of the V8 JavaScript engine. 1998 ACM Subject Classification F.3.3 Type structure Keywords and phrases Gradual typing, dynamic languages Digital Object Identifier 10.4230/LIPIcs.ECOOP.2015.999 1 Introduction Perhaps surprisingly, a number of modern computer programming languages have been de- signed with intentionally unsound type systems. Unsoundness arises for pragmatic reasons, for instance, Java has a covariant array subtype rule designed to allow for a single polymor- phic sort() implementation. More recently, industrial extensions to dynamic languages, such as Hack, Dart and TypeScript, have featured optional type systems [5] geared to ac- commodate dynamic programming idioms and preserve the behavior of legacy code. Type annotations are second class citizens intended to provide machine-checked documentation, and only slightly reduce the testing burden. Unsoundness, here, means that a variable an- notated with some type T may, at runtime, hold a value of a type that is not a subtype of T due to unchecked casts, covariant subtyping, and untyped code.
    [Show full text]
  • Visual Studio “Code in Strings”
    VisCis: Visual Studio “Code in Strings” Paul Roper School of Business and Computer Technology Nelson Marlborough Institute of Technology Nelson, NZ [email protected] When developing web applications using Visual Studio .NET SQL and Javascript. This code is ignored by Visual there are times when the programmer is coding either SQL or Javascript within text strings. Consequently such code is never Studio, and consequently can be the source of run- checked for correct syntax before it is run. As far as Visual time errors. The writer wanted to see if another Studio is concerned, the contents of a string are irrelevant. As program could extract this “code in strings” and syn- long as the code is inside matching quotes, it is simply a valid string. tax check it at edit-time, potentially saving devel- There is an irony here in that Visual Studio is a sophisticated oper time and frustration. tool with powerful features for developers such as highlighting syntax errors as lines are typed. However, the SQL and 1.1 SQL in ASP.NET program code Javascript code inside strings is just as prone to errors as any other code but these errors are only discovered at run time. In SQL instructions have long been part of web terms of time taken to find and fix, they probably consume application code (Java, ASP, PHP etc). Both stu- relatively more time per lines of code than the VB or C# code that is thoroughly checked at edit-time. Both SQL and Javascript dents and experienced developers frequently expe- are necessary for any non-trivial web application although the rience problems with the syntax of embedded SQL use of stored procedures in MSSQL removes SQL code from particularly unmatched quotes, inadvertent use of a program code.
    [Show full text]
  • Formally Verifying Webassembly with Kwasm
    Formally Verifying WebAssembly with KWasm Towards an Automated Prover for Wasm Smart Contracts Master’s thesis in Computer Science and Engineering RIKARD HJORT Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2020 Master’s thesis 2020 Formally Verifying WebAssembly with KWasm Towards an Automated Prover for Wasm Smart Contracts RIKARD HJORT Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2020 Formally Verifying WebAssembly with KWasm Towards an Automated Prover for Wasm Smart Contracts RIKARD HJORT © RIKARD HJORT, 2020. Supervisor: Thomas Sewell, Department of Computer Science and Engineering Examiner: Wolfgang Ahrendt, Department of Computer Science and Engineering Master’s Thesis 2020 Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: Conceptual rendering of the KWasm system, as the logos for K ans Web- Assembly merged together, with a symbolic execution proof tree protruding. The cover image is made by Bogdan Stanciu, with permission. The WebAssembly logo made by Carlos Baraza and is licensed under Creative Commons License CC0. The K logo is property of Runtime Verification, Inc., with permission. Typeset in LATEX Gothenburg, Sweden 2020 iv Formally Verifying WebAssembly with KWasm Towards an Automated Prover for Wasm Smart Contracts Rikard Hjort Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg Abstract A smart contract is immutable, public bytecode which handles valuable assets. This makes it a prime target for formal methods. WebAssembly (Wasm) is emerging as bytecode format for smart contracts.
    [Show full text]
  • Intro to Javascript
    1 Intro to Javascript CS380 Client Side Scripting 2 CS380 Why use client-side programming? 3 PHP already allows us to create dynamic web pages. Why also use client-side scripting? client-side scripting (JavaScript) benefits: usability : can modify a page without having to post back to the server (faster UI) efficiency : can make small, quick changes to page without waiting for server event-driven : can respond to user actions like clicks and key presses CS380 Why use client-side programming? 4 server-side programming (PHP) benefits: security : has access to server's private data; client can't see source code compatibility : not subject to browser compatibility issues power : can write files, open connections to servers, connect to databases, ... CS380 What is Javascript? 5 a lightweight programming language ("scripting language") used to make web pages interactive insert dynamic text into HTML (ex: user name) react to events (ex: page load user click) get information about a user's computer (ex: browser type) perform calculations on user's computer (ex: form validation) CS380 What is Javascript? 6 a web standard (but not supported identically by all browsers) NOT related to Java other than by name and some syntactic similarities CS380 Javascript vs Java 7 interpreted, not compiled more relaxed syntax and rules fewer and "looser" data types variables don't need to be declared errors often silent (few exceptions) key construct is the function rather than the class "first-class" functions are used in many situations contained within a web page and integrates with its HTML/CSS content CS380 Javascript vs Java 8 + = CS380 JavaScript vs.
    [Show full text]
  • Preview Javascript Tutorial
    About the Tutorial JavaScript is a lightweight, interpreted programming language. It is designed for creating network-centric applications. It is complimentary to and integrated with Java. JavaScript is very easy to implement because it is integrated with HTML. It is open and cross-platform. Audience This tutorial has been prepared for JavaScript beginners to help them understand the basic functionality of JavaScript to build dynamic web pages and web applications. Prerequisites For this tutorial, it is assumed that the reader have a prior knowledge of HTML coding. It would help if the reader had some prior exposure to object-oriented programming concepts and a general idea on creating online applications. Copyright and Disclaimer Copyright 2015 by Tutorials Point (I) Pvt. Ltd. All the content and graphics published in this e-book are the property of Tutorials Point (I) Pvt. Ltd. The user of this e-book is prohibited to reuse, retain, copy, distribute or republish any contents or a part of contents of this e-book in any manner without written consent of the publisher. We strive to update the contents of our website and tutorials as timely and as precisely as possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt. Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our website or its contents including this tutorial. If you discover any errors on our website or in this tutorial, please notify us at [email protected] i Table of Contents About the Tutorial ............................................................................................................................................
    [Show full text]
  • Book Reviews Elizabbeth Zwicooky, with Mark Laksmourine
    Book Reviews ELIZABbETH ZWICOOKY, WITH MARK LAksMOURINE Team Geek: A Software Developer’s Guide to This is not a story I was part of, and it’s before I came to Working Well with Others Silicon Valley, so in some sense it’s not a world I know . And Brian W . Fitzpatrick and Ben Collins-Sussman yet, at the same time, it is the world I knew then (a time when O’Reilly, 2012 . 160 pp . we saved the foam that one of our computers came in because ISBN 978-1-449-30244-3 it was handy for sleeping on when you had been programming too long and needed a nap) . Furthermore, it is also the world of the most recent startup I was at . Having the stories told by The Developer’s Code: What Real Programmers Do the participants gives this a sense of truth that most tales of Ka Wai Cheung computing history don’t possess . Pragmatic Bookshelf, 2012 . 141pp . This came in (reprinted) for review right around the time ISBN 978-1-934356-79-1 Steve Jobs died, and I put off looking at it partly because of These make a nice pair; each is the programmer’s equivalent the noise at the time . Although Steve Jobs appears, this is not of a glossy management book, with simple, good advice well a book about him, and it depicts him with the full complexity packaged . Simple ideas are easy to read and easy to believe in of feelings that people had at the time . and sadly very, very hard to implement .
    [Show full text]
  • Javascript Elements Client-Side Scripting Why Use Client
    Client-side scripting JavaScript Elements • client-side script: code runs in browser a"er page is sent back from server – often this code manipulates the page or responds to user actions Copyright 2012 Marty Stepp, Jessica Miller, and Victoria Kirst 2 Why use client-side programming? What is JavaScript? • PHP already allows us to create dynamic web pages. Why • a lightweight programming language ("scripting language") also use client-side scripting? • • Client-side scripting (JavaScript) benefits: used to make web pages interactive – – usability: can modify a page without having to post back to the server insert dynamic text into HTML (ex: user name) (faster UI) – react to events (ex: page load user click) – efficiency: can make small, quick changes to page without wai?ng for – get information about a user's computer (ex: browser type) server – perform calculations on user's computer (ex: form validation) – event-driven: can respond to user ac?ons like clicks and key presses • a web standard (but not supported identically by all • Server-side programming (PHP) benefits: browsers) – security: has access to server's private data; client can't see source code – compa7bility: not subject to browser compa?bility issues • NOT related to Java other than by name and some syntactic – power: can write files, open connec?ons to servers, connect to databases, ... similarities Copyright 2012 Marty Stepp, Jessica Miller, and Victoria Kirst Copyright 2012 Marty Stepp, Jessica Miller, and Victoria Kirst 3 4 Short History of JavaScript JavaScript and JAVA
    [Show full text]
  • The Past, Present, and Future of Javascript Where We’Ve Been, Where We Are, and What Lies Ahead
    The Past, Present, and Future of JavaScript Where We’ve Been, Where We Are, and What Lies Ahead Dr. Axel Rauschmayer The Past, Present, and Future of JavaScript Axel Rauschmayer Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo The Past, Present, and Future of JavaScript by Axel Rauschmayer Copyright © 2012 Axel Rauschmayer. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editor: Mac Slocum Cover Designer: Karen Montgomery Production Editor: Melanie Yarbrough Interior Designer: David Futato Illustrator: Robert Romano Revision History for the First Edition: 2012-07-20 First release See http://oreilly.com/catalog/errata.csp?isbn=9781449339968 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Past, Present, and Future of JavaScript and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
    [Show full text]