DOCSLIB.ORG

Developing a Common Web Interface to Various Verification Tools

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Developing a Common Web Interface to Various Verification Tools Developing a common web interface to various verification tools Bachelor's Thesis Report Roland Meyer [email protected] Supervised by: Malte Schwerhoff Prof. Dr. Peter M¨uller ETH Z¨urich July 27, 2012 Abstract This Bachelor's thesis introduces Tuwin, a system that allows a user to try out a command-line based tool, e.g. a verification tool or a program analyzer, online, without having to install it. This is achieved by giving such tools a common web interface similar to Microsoft Research's rise4fun [1], such that users can execute the tools from their browsers. The system consists of three parts; a central server, a graphical web interface and a number of remote web applications, the tool hosters, where each of them hosts a tool. A user can send input data such as source code to the server which redirects it to the corresponding tool hoster. The tool hoster executes its tool with the user's input and eventually returns its output through the server to the user. All communication between the three components uses standard HTTP/1.1 and messages are JSON [2] or MIME encoded. The server relies on a database for logging and both the server and the tool hoster are configurable through a configuration file. Through this file the tool hoster supports features such as user-selectable command-line parameters, multiple output files of different types, e.g. images or PDF files, or syntax highlighting the input text. Contents 1 Introduction 2 1.1 Motivation . .2 1.2 Goals . .2 1.3 Outline . .3 2 System Overview 3 3 User interface 4 3.1 Admin page . .7 4 Execution Example 8 5 Implementation 10 5.1 User Interface . 10 5.2 Tool Hoster . 11 5.2.1 Configuration . 12 5.2.2 Languages . 16 5.2.3 Examples . 16 5.2.4 Options . 17 5.2.5 Results . 18 5.3 Tuwin Server . 20 5.3.1 Configuration . 21 5.3.2 Database . 22 5.3.3 Permalinks . 22 5.4 Error handling . 23 5.4.1 Error messages and classes . 23 5.4.2 Logging and displaying errors . 24 6 Communication Protocol 25 7 Quality Assurance 28 7.1 Project management . 28 7.2 Documentation . 28 7.3 Testing . 28 7.3.1 Unit tests . 28 7.3.2 Stress tests . 28 7.3.3 UI compatibility . 31 7.4 Security . 31 8 Conclusions 31 8.1 Future Work . 32 8.2 Acknowledgments . 33 A Database tables 36 B List of Error Codes 39 1 1 Introduction 1.1 Motivation Many research groups in computer science develop various tools such as code verifiers, compilers or program analysers. These tools are often not officially released, i.e., they are not available in a stable major version since they are under constant development. There may be frequent or unforeseen changes to the APIs, and dependencies and build processes may not be thoroughly documented. This can make it difficult for people interested in using these tools as they have to keep track of the latest version and find out how to build and use it, or they might not even be allowed to install the tool due to legal issues. 1.2 Goals The goal of this Bachelor's thesis was to develop a web service that would allow an interested user to find a command-line based tool and use it without having to download and install it on his/her own computer. The web service should work in a similar way to Microsoft Research's rise4fun [1]. The user interface should be easy to understand and easy to use, such that a user could find a tool, enter their code and run it with just a few clicks. A tool developer should be able to add his/her tool to the service with as little effort as possible. The system should be configurable such that it can adapt well to many different tools. A tool developer should have the possibility to provide example input code to their users as well as to allow them to use command-line parameters. Tools that produce multiple output files should be supported. The communication in the system should use a well-defined protocol. Output from a tool should be displayed to the user as soon as it is available, i.e., intermediate results have to be visible. All user input and output from the tools, as well as errors, should be logged in a centralized way to allow debugging. The web service was to be implemented in the Scala programming lan- guage [3] and the implementation was to be well-documented and thoroughly tested to facilitate future maintenance. Security and performance were no key issues but were considered throughout the course of the project. 2 1.3 Outline The product of this Bachelor's thesis is called the Tuwin system or Tuwin for short. It stands for Tool Use Without Installation. Section 2 gives an overview of the Tuwin system and explains its components. Section 3 shows screenshots of the user interface and explains how it is used. Section 4 shows an execution example to give an impression of how the components com- municate and section 5 discusses implementation details. Section 6 explains the Tuwin communication protocol in detail and is followed by section 7 dis- cussing quality assurance and finally section 8 which concludes the report with a brief discussion about future work. 2 System Overview The Tuwin system consists of three conceptual components; the user inter- face, the server and the tool hosters (figure 1). Communication Communication (HTTP and JSON) (HTTP and JSON) Config file Tuwin Server Tool Hoster A UI Config file Tool Hoster B Config file Database Config file Tool Hoster C Figure 1: The components of Tuwin The Tuwin tool hoster is a web application of which a developer can install an instance on his computer and configure it to use a tool that he/she developed and installed on the same machine. In this way the tool hoster provides a web interface to that tool, allowing external users to feed input to it and receive back output. There may be a large number of tool hosters in the system, one for each tool. The Tuwin tool hoster is a sample implementation of a tool hoster, designed to be as generic as possible, but tool developers are not bound to use it. Instead they may want to use their own implementation which behaves according to the communication protocol. The Tuwin server is the central unit. It serves as a mediator between the users and the tool hosters by providing a user-friendly web interface 3 (see section 3). The server redirects user requests to the corresponding tool hosters and monitors the execution there by polling. It relies on a database to log input, output, and errors. Even though it may be a bottleneck, there are a number of reasons why the server is used as a middle-man. By not letting the user interface communicate directly with the tool hosters the server can ensure that all communication with the tool hosters correspond to the protocol. This is both a security measure as well as a measure of making sure that the logging works correctly. It also adds flexibility because tool hosters can be exchanged without the users noticing. The communication between the three components uses standard HTTP and JSON [2] encoded messages, as well as file downloads. Both the server and the tool hosters are configured through a JSON encoded configuration file. In this report the terms tool hoster and (Tuwin) server may refer to the components as such or to the computers they are running on. The user interface or UI is part of the server but is treated as a separate component because its code is executed on the client, i.e., the user's computer. When a user enters the Tuwin server's URL in their browser they are presented with a list of all registered tools (figure 2). Upon clicking a tool from this list they are redirected to an editor page (figure 3) where they can enter their input. Once they click the \Run" button this input is sent to the server using its HTTP interface. The term HTTP interface refers to a component's set of HTTP paths used for communication and is not to be confused with the user interface. The server forwards the request to the tool hoster's HTTP interface and the tool hoster executes its tool using the user's input. In order to know when the execution is finished, the server repeatedly polls the tool hoster to find out about the current execution status. The user interface code does the same with the server. As soon as output is available on the tool hoster, the server fetches it and stores it locally. The user interface code then fetches the output from the server and displays it to the user. In this report output is referred to as a result (file) or multiple result files. 3 User interface The first thing users see when they access the Tuwin service in their browsers is the tool selection page (figure 2). It contains a list of available tools and each tool is presented as a clickable box with its name and description inside. On top of these boxes there is an input field which can be used to filter the tools. 4 Figure 2: Screenshot of the tool selection page When the user selects a tool from the list they are taken to the editor page (figure 3).
Load more

Recommended publications
  • Stable/Build) • --Port PORT - Set the PORT Number (Default: 8000)
    Pyodide Release 0.18.1 unknown Sep 16, 2021 CONTENTS 1 Using Pyodide 3 1.1 Getting started..............................................3 1.2 Downloading and deploying Pyodide..................................6 1.3 Using Pyodide..............................................7 1.4 Loading packages............................................ 12 1.5 Type translations............................................. 14 1.6 Pyodide Python compatibility...................................... 25 1.7 API Reference.............................................. 26 1.8 Frequently Asked Questions....................................... 50 2 Development 55 2.1 Building from sources.......................................... 55 2.2 Creating a Pyodide package....................................... 57 2.3 How to Contribute............................................ 64 2.4 Testing and benchmarking........................................ 74 2.5 Interactive Debugging.......................................... 76 3 Project 79 3.1 About Pyodide.............................................. 79 3.2 Roadmap................................................. 80 3.3 Code of Conduct............................................. 82 3.4 Governance and Decision-making.................................... 83 3.5 Change Log............................................... 85 3.6 Related Projects............................................. 95 4 Indices and tables 97 Python Module Index 99 Index 101 i ii Pyodide, Release 0.18.1 Python with the scientific stack, compiled to WebAssembly.
    [Show full text]
  • Javascript API Deprecation in the Wild: a First Assessment
    JavaScript API Deprecation in the Wild: A First Assessment Romulo Nascimento, Aline Brito, Andre Hora, Eduardo Figueiredo Department of Computer Science Federal University of Minas Gerais, Brazil romulonascimento, alinebrito, andrehora,figueiredo @dcc.ufmg.br { } Abstract—Building an application using third-party libraries of our knowledge, there are no detailed studies regarding API is a common practice in software development. As any other deprecation in the JavaScript ecosystem. software system, code libraries and their APIs evolve over JavaScript has become extremely popular over the last years. time. In order to help version migration and ensure backward According to the Stack Overflow 2019 Developer Survey1, compatibility, a recommended practice during development is to deprecate API. Although studies have been conducted to JavaScript is the most popular programming language in this investigate deprecation in some programming languages, such as platform for the seventh consecutive year. GitHub also reports Java and C#, there are no detailed studies on API deprecation that JavaScript is the most popular language in terms of unique in the JavaScript ecosystem. This paper provides an initial contributors to both public and private repositories2. The npm assessment of API deprecation in JavaScript by analyzing 50 platform, the largest JavaScript package manager, states on popular software projects. Initial results suggest that the use of 3 deprecation mechanisms in JavaScript packages is low. However, their latest survey that 99% of JavaScript developers rely on wefindfive different ways that developers use to deprecate API npm to ease the management of their project dependencies. in the studied projects. Among these solutions, deprecation utility This survey also points out the massive growth in npm usage (i.e., any sort of function specially written to aid deprecation) and that started about 5 years ago.
    [Show full text]
  • Javascript Client Guide
    JavaScript Client Guide Target API: Lightstreamer JavaScript Client v. 6.1.4 Last updated: 15/07/2014 Table of contents 1 INTRODUCTION................................................................................................................3 2 JAVASCRIPT CLIENT DEVELOPMENT.........................................................................................4 2.1 Deployment Architecture..................................................................................4 2.1.1 Deployment and Browsers................................................................................4 2.2 Site/Application Architecture.............................................................................5 2.3 The LightstreamerClient...................................................................................6 2.3.1 Using an AMD loader........................................................................................7 2.3.2 Using Global Objects........................................................................................9 2.3.3 Name Clashes................................................................................................10 2.3.4 LightstreamerClient in a Web Worker...............................................................11 2.3.5 The Node.js case............................................................................................12 2.4 The Subscription Listeners..............................................................................13 2.4.1 StaticGrid.......................................................................................................13
    [Show full text]
  • Prevent Jsdoc from Writting to File
    Prevent Jsdoc From Writting To File Anatole await pallidly if assonant Jamie dwining or doublings. Napoleon bolts his depurators remilitarizing vainly, but condyloid Tabby never lament so slantwise. Baking-hot and uliginous Torry unitings her propulsion snog while Douglas buffetings some retirers Tuesdays. Jsdoc comment log message object from file will be ignored if true, the same port files to gpudb instances of a function? Redirect output parameters can prevent jsdoc from writting to file you want for messages from response to search. Official documentation for addition project. No nulls will be generated for nullable columns. The new functionality is it is when accessing properties at once all have not only in scope objects and then. If a chain of an uppercase character from. Suggests any typing for a loan eligibility when no longer would be from an object can prevent unauthorized access control characters and! An application message, please sign speak for my weekly Dev Mastery newsletter below. The box of degrees the pasture is rotated clockwise. Used within another number of systematically improving health related status. This page to read and fetch the file to. Many different from jsdoc file to prevent execution. You from that can be an exception of information icon when introducing visual studio code blocks is synchronous, but in more we prevent jsdoc from writting to file is there any! There by some special cases that appear flat the whole framework. Linting rules for Backbone. Form Objects and Functions pane. Nothing in a point me know it could restrict it can prevent jsdoc? Optional parameters for a given client.
    [Show full text]
  • Vasili Korol
    Vasili Korol Senior Software Developer Odense, Denmark Age: 35 mob.: +45 20 68 50 23 Married, have son (born 2010) e-mail: [email protected] ​ Personal Statement ⚬ Strong IT skills (16+ years of versatile experience) ⚬ Background in physics research ⚬ Work effectively both as team member and leader ⚬ Enthusiastic and committed ⚬ Spoken languages: Russian (native), English (fluent), Danish (Prøve i Dansk 3 / level B2) ​ ​ ​ ​ Education 2006–2008: Master’s degree (with distinction) in applied physics. ​ 2002–2006: Bachelor’s degree (with distinction) in applied physics. Under- to postgraduate student at St. Petersburg State Polytechnical University, Faculty of Physics and Technology, Dept. of Cosmic Physics. The thesis “Search for possible space-time variations of the fine-structure constant and isotopic shifts” (a supervisor Prof. ​ M.G. Kozlov). ​ 1992-2002: School education in St. Petersburg, Russia and Belfast, UK (in 1993). Professional Career 2015 – Feb 2021: Software developer in the QuantBio research group at the University of ​ ​ ​ ​ Southern Denmark (SDU), Institute of Physics, Chemistry and Pharmacy (HPC section). I am the principal developer of VIKING, a service providing a web interface for configuring ​ ​ ​ and running scientific computational tasks on supercomputers. I designed the software architecture, developed the system core and coordinated the work of several developers. 2014 – 2015: Lead programmer (Perl) at Internet Projects LLC, russian informational portals subscribe.ru and sendsay.ru (St. Petersburg, Russia). ​ ​ ​ Worked with a team of developers on projects targeted at developing an API for news aggregation and content processing services. This involved integration with various online platforms (Facebook, Twitter, Vkontakte, LiveJournal, Google Analytics), web scraping and designing instruments for user publications at the portals and beyond.
    [Show full text]
  • Node.Js Application Developer's Guide (PDF)
    MarkLogic Server Node.js Application Developer’s Guide 1 MarkLogic 10 June, 2019 Last Revised: 10.0-1, June 2019 Copyright © 2019 MarkLogic Corporation. All rights reserved. MarkLogic Server Table of Contents Table of Contents Node.js Application Developer’s Guide 1.0 Introduction to the Node.js Client API ..........................................................9 1.1 Getting Started ........................................................................................................9 1.2 Required Software ................................................................................................14 1.3 Security Requirements ..........................................................................................15 1.3.1 Basic Security Requirements ....................................................................15 1.3.2 Controlling Document Access ..................................................................16 1.3.3 Evaluating Requests Against a Different Database ..................................16 1.3.4 Evaluating or Invoking Server-Side Code ................................................16 1.4 Terms and Definitions ..........................................................................................17 1.5 Key Concepts and Conventions ............................................................................18 1.5.1 MarkLogic Namespace .............................................................................18 1.5.2 Parameter Passing Conventions ................................................................18
    [Show full text]
  • Node.Js I – Getting Started Chesapeake Node.Js User Group (CNUG)
    Node.js I – Getting Started Chesapeake Node.js User Group (CNUG) https://www.meetup.com/Chesapeake-Region-nodeJS-Developers-Group Agenda ➢ Installing Node.js ✓ Background ✓ Node.js Run-time Architecture ✓ Node.js & npm software installation ✓ JavaScript Code Editors ✓ Installation verification ✓ Node.js Command Line Interface (CLI) ✓ Read-Evaluate-Print-Loop (REPL) Interactive Console ✓ Debugging Mode ✓ JSHint ✓ Documentation Node.js – Background ➢ What is Node.js? ❑ Node.js is a server side (Back-end) JavaScript runtime ❑ Node.js runs “V8” ✓ Google’s high performance JavaScript engine ✓ Same engine used for JavaScript in the Chrome browser ✓ Written in C++ ✓ https://developers.google.com/v8/ ❑ Node.js implements ECMAScript ✓ Specified by the ECMA-262 specification ✓ Node.js support for ECMA-262 standard by version: • https://node.green/ Node.js – Node.js Run-time Architectural Concepts ➢ Node.js is designed for Single Threading ❑ Main Event listeners are single threaded ✓ Events immediately handed off to the thread pool ✓ This makes Node.js perfect for Containers ❑ JS programs are single threaded ✓ Use asynchronous (Non-blocking) calls ❑ Background worker threads for I/O ❑ Underlying Linux kernel is multi-threaded ➢ Event Loop leverages Linux multi-threading ❑ Events queued ❑ Queues processed in Round Robin fashion Node.js – Event Processing Loop Node.js – Downloading Software ➢ Download software from Node.js site: ❑ https://nodejs.org/en/download/ ❑ Supported Platforms ✓ Windows (Installer or Binary) ✓ Mac (Installer or Binary) ✓ Linux
    [Show full text]
  • Writing Readable Code
    WRITING READABLE CODE “Any fool can write a code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler GENERAL GUIDELINES Writing clean and readable code is not hard, but it is very important toward the maintainability of your program. Readability is achieved by through experience and practiced intuition, but can be guided by key principles including: 1. Good variable names. Every variable should have an identier (name) that directly reflects what it represents. A variable that is describing the number of ducks in a pond might be called ducks or count but it shouldn't be called something like pancakes. Never name your variables as single letters (except for counters in for loops) or anything too abstract. 2. Function naming and responsibility. Make sure your functions also are named well represent what the function does. Every function should also have a single responsibility, something you could describe in a sentence or two. (This is called the SINGLE RESPONSIBILITY PRINCIPLE). 3. Proper formatting. Always maintain correct and consistent indentation, spacing, and location of curly braces, if required by the language. One of the most helpful motivations for clean and consistent formatting is to consider the perspective of the person trying to understand your code, making sure one could painlessly read and interpret your code's purpose through a consistent organization and hierarchal structure. 4. Clear documentation.You should provide clear documentation in all of your web development work, describing functions, key variables or constants, and any particularly complex sections of code. At the same time, your documentation should be client- focused, avoiding implementation details about how your programs are implemented (this latter point is especially relevant when working with function-based programming languages like JavaScript and PHP).
    [Show full text]
  • Minutes of the 42Nd Meeting of TC39, Boston, September 2014
    Ecma/TC39/2014/051 Ecma/GA/2014/118 Minutes of the: 42nd meeting of Ecma TC39 in: Boston, MA, USA on: 23-25 September 2014 1 Opening, welcome and roll call 1.1 Opening of the meeting (Mr. Neumann) Mr. Neumann has welcomed the delegates at Nine Zero Hotel (hosted by Bocoup) in Boston, MA, USA. Companies / organizations in attendance: Mozilla, Google, Microsoft, Intel, eBay, jQuery, Yahoo!, IBM; Facebook, IETF 1.2 Introduction of attendees John Neumann – Ecma International Erik Arvidsson – Google Mark Miller – Google Andreas Rossberg - Google Domenic Denicola – Google Erik Toth – Paypal / eBay Allen Wirfs-Brock – Mozilla Nicholas Matsakis – Mozilla Eric Ferraiuolo – Yahoo! Caridy Patino – Yahoo! Rick Waldron – jQuery Yehuda Katz – jQuery Dave Herman – Mozilla Brendan Eich (invited expert) Jeff Morrison – Facebook Sebastian Markbage – Facebook Brian Terlson – Microsoft Jonathan Turner – Microsoft Peter Jensen – Intel Simon Kaegi – IBM Boris Zbarsky - Mozilla Matt Miller – IETF (liaison) Ecma International Rue du Rhône 114 CH-1204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org PC 1.3 Host facilities, local logistics On behalf of Bocoup Rick Waldron welcomed the delegates and explained the logistics. 1.4 List of Ecma documents considered 2014/038 Minutes of the 41st meeting of TC39, Redmond, July 2014 2014/039 TC39 RF TG form signed by the Imperial College of science technology and medicine 2014/040 Venue for the 42nd meeting of TC39, Boston, September 2014 (Rev. 1) 2014/041 Agenda for the 42nd meeting of TC39, Boston, September
    [Show full text]
  • Packer: an Opinionated Framework for Using 'Javascript'
    Package ‘packer’ August 14, 2021 Title An Opinionated Framework for Using 'JavaScript' Date 2021-08-14 Version 0.1.1 Description Enforces good practice and provides convenience functions to make work with 'JavaScript' not just easier but also scalable. It is a robust wrapper to 'NPM', 'yarn', and 'webpack' that enables to compartmentalize 'JavaScript' code, leverage 'NPM' and 'yarn' packages, include 'TypeScript', 'React', or 'Vue' in web applications, and much more. License MIT + file LICENSE Encoding UTF-8 RoxygenNote 7.1.1 Imports fs, usethis, jsonlite, htmlwidgets, cli, assertthat, rprojroot, rstudioapi URL https://github.com/JohnCoene/packer, https://packer.john-coene.com BugReports https://github.com/JohnCoene/packer/issues Suggests testthat, covr, golem NeedsCompilation no Author John Coene [aut, cre] (<https://orcid.org/0000-0002-6637-4107>) Maintainer John Coene <[email protected]> Repository CRAN Date/Publication 2021-08-14 12:40:02 UTC R topics documented: add_plugin_clean . .3 add_plugin_eslint . .3 add_plugin_html . .4 add_plugin_prettier . .4 add_plugin_workbox . .4 apply_react . .5 1 2 R topics documented: apply_vue . .5 are_minified . .6 bundle . .6 checks . .7 engine . .7 engine_console . .8 jsdoc . .8 make_library . .9 mockup . .9 npm_console . 10 npm_fix . 10 npm_install . 10 npm_outdated . 11 npm_run . 11 npm_update . 11 put_precommit_hook . 12 put_recommended . 12 put_rprofile_adapt . 12 scaffold_ambiorix . 13 scaffold_extension . 14 scaffold_golem . 15 scaffold_input . 16 scaffold_leprechaun . 17 scaffold_output . 17
    [Show full text]
  • Client-Server Web Apps with Javascript and Java
    Client-Server Web Apps with JavaScript and Java Casimir Saternos Client-Server Web Apps with JavaScript and Java by Casimir Saternos Copyright © 2014 EzGraphs, LLC. 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]. Editors: Simon St. Laurent and Allyson MacDonald Indexer: Judith McConville Production Editor: Kristen Brown Cover Designer: Karen Montgomery Copyeditor: Gillian McGarvey Interior Designer: David Futato Proofreader: Amanda Kersey Illustrator: Rebecca Demarest April 2014: First Edition Revision History for the First Edition: 2014-03-27: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449369330 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Client-Server Web Apps with JavaScript and Java, the image of a large Indian civet, 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 author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Nicholas C. Zakas — «Maintainable Javascript
    Maintainable JavaScript Nicholas C. Zakas Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Maintainable JavaScript by Nicholas C. Zakas Copyright © 2012 Nicholas Zakas. 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: Mary Treseler Indexer: Lucie Haskins Production Editor: Holly Bauer Cover Designer: Karen Montgomery Copyeditor: Nancy Kotary Interior Designer: David Futato Proofreader: Linley Dolby Illustrator: Rebecca Demarest May 2012: First Edition. Revision History for the First Edition: 2012-05-09 First release See http://oreilly.com/catalog/errata.csp?isbn=9781449327682 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Maintainable JavaScript, the image of a Greek tortoise, 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. ISBN: 978-1-449-32768-2 [LSI] 1336581452 Table of Contents Introduction .
    [Show full text]