[PDF Download] Client server web apps with javascript and java rich scalable and restful 1st edition

Page 1


Visit to download the full and correct content document: https://textbookfull.com/product/client-server-web-apps-with-javascript-and-java-rich-s calable-and-restful-1st-edition-saternos-casimir/

More products digital (pdf, epub, mobi) instant download maybe you interests ...

Building RESTful Web Services with Java EE 8 Create modern RESTful web services with the Java EE 8 API Mario-Leander Reimer

https://textbookfull.com/product/building-restful-web-serviceswith-java-ee-8-create-modern-restful-web-services-with-the-javaee-8-api-mario-leander-reimer/

Building web and mobile ArcGIS Server applications with JavaScript Lewin

https://textbookfull.com/product/building-web-and-mobile-arcgisserver-applications-with-javascript-lewin/

RESTful Java Web Services A pragmatic guide to designing and building RESTful APIs using Java 3rd Edition Balachandar

https://textbookfull.com/product/restful-java-web-services-apragmatic-guide-to-designing-and-building-restful-apis-usingjava-3rd-edition-balachandar/

Server Side Swift with Vapor Building Web APIs and Web Apps in Swift 3rd Edition Raywenderlich.Com Tutorial Team

https://textbookfull.com/product/server-side-swift-with-vaporbuilding-web-apis-and-web-apps-in-swift-3rd-editionraywenderlich-com-tutorial-team/

Beginning iPhone and iPad Web Apps Scripting with HTML5 CSS3 and JavaScript 1st Edition Apers Chris Paterson Daniel

https://textbookfull.com/product/beginning-iphone-and-ipad-webapps-scripting-with-html5-css3-and-javascript-1st-edition-aperschris-paterson-daniel/

Practical Node.js: Building Real-World Scalable Web Apps Azat Mardan

https://textbookfull.com/product/practical-node-js-building-realworld-scalable-web-apps-azat-mardan/

Pro Apache NetBeans - Building Applications on the Rich Client Platform [ Java ] 1st Edition Ioannis Kostaras

https://textbookfull.com/product/pro-apache-netbeans-buildingapplications-on-the-rich-client-platform-java-1st-editionioannis-kostaras/

Building RESTful Web Services with PHP 7 Ahmad

https://textbookfull.com/product/building-restful-web-serviceswith-php-7-ahmad/

React js Essentials A fast paced guide to designing and building scalable and maintainable web apps with React js 1st Edition Fedosejev

https://textbookfull.com/product/react-js-essentials-a-fastpaced-guide-to-designing-and-building-scalable-and-maintainableweb-apps-with-react-js-1st-edition-fedosejev/

Client-Server Web Apps with JavaScript and Java by

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 alsoavailableformosttitles(http://my.safaribooksonline.com).Formoreinformation,contactourcorporate/ institutional sales department: 800-998-9938 or corporate@oreilly.com

Editors: Simon St. Laurent and Allyson MacDonald

ProductionEditor: Kristen Brown

Copyeditor: Gillian McGarvey

Proofreader: Amanda Kersey

April 2014: First Edition

RevisionHistoryfortheFirstEdition:

2014-03-27: First release

Indexer: Judith McConville

CoverDesigner: Karen Montgomery

InteriorDesigner: David Futato

Illustrator: Rebecca Demarest

See http://oreilly.com/catalog/errata.csp?isbn=9781449369330 for release details.

NutshellHandbook,theNutshellHandbooklogo,andtheO’ReillylogoareregisteredtrademarksofO’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.Wherethosedesignationsappearinthisbook,andO’ReillyMedia,Inc.wasawareofatrademark 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.

ISBN: 978-1-449-36933-0

[LSI]

4. Java Tools.
6. Java Web API Servers.

7.

13.

14. Conclusion.

A.JRuby IRB and Java API.

B.RESTful Web API Summary.

C.References.

Index.

TableofContents | ix

Preface

There are only two hard things in Computer Science: cache invalidation and naming things.

Whilecacheinvalidationisnotadifficultyencounteredwhenwritingabook,choosing a suitable title is. The title of this book is intended to represent a broad area of changes inwebdevelopmentthathaveresultedinanewapproachtodesigningwebapplications.

Ofcourse,manyaspectsofwebdevelopmentcanbeconsiderednew.Developersscram‐ble to keep up with enhancements to desktop browsers, new mobile device clients, evolving programming languages, the availability of faster processors, and an increas‐ingly discerning audience of users with growing expectations about usability and in‐teractivity. These changes require developers to continually innovate when coming up with solutions for their specific projects. But many of these solutions have broader implications and are not isolated to any particular project.

Therefore,Ichose“client-server”asthetermwhichinmanywayscapturesthechanges to web development that have occurred in response to these innovations. Other de‐scriptions of modern development practices currently in vogue don’t adequately rep‐resent the problem domain. Web application development is associated with desktop browsers, but excludes the increasingly relevant area of mobile applications.

The terms Single Page Application and Single Page Interface have been used to distin‐guishmodernwebapplicationsfromearlierstaticwebsites.Thesetermscorrectlyiden‐tify modern sites as far more dynamic and interactive than their predecessors.

However, many modern dynamic applications are made up of multiple pages rather than a single page. The focus in these terms is on the page, the client portion of an application. They make no specific statement about corresponding server-side devel‐opment. There are JavaScript frameworks that are also associated with highly dynamic pages (such as Angular, Ember, and Backbone), but these are also concerned with the xi

clienttier.Iwantedthetitleofthisbooktoencompassmorethanfront-endinnovations and to recognize the corresponding server-side design and web service messaging.

The method of communication captured by the popular acronym REST (Representa‐tional State Transfer) does suggest the web service messaging style. But the definition of REST as specified by its author Roy Fielding is very limiting. On his blog, Fielding listsspecificrestrictionstoRESTthatarecommonlyviolatedinso-calledRESTfulAPIs. And some even question whether a JSON API can be truly RESTful due to the fact that it does not satisfy all of the constraints associated with the style of architecture. There isacontinuumbywhichRESTservicescanbedescribed;sothatanAPIcanbedescribed asRESTfulonlytothedegreethatitadherestotheconstraints.RESTdoesincludeclientserverasoneofitsconstraints,andtheverbandURLnamingconventionsarecertainly applicable.

So a JavaScript client consuming messages from a pragmatic “RESTful” API is a signif‐icant part of the method of development. What about the server component?

JavaEnterpriseEdition(JEE)includestheJAX-RSAPI,whichusesJava’sflavorofREST (which is not inherently strict) and is demonstrable using the Jersey reference imple‐mentation. But limiting to JAX-RS web application development ignores frameworks and alternate JVM language solutions that are available and particularly appealing for quick prototypes.

And so crystallizing the intentions of a book in a simple, catchy title is not an easy task. Fortunately, James Ward did a presentation at OSCON 2012 in which he described the development of “Client-Server Web Applications with HTML5 and Java.” He listed the benefits of a method of web application development that is increasingly popular, a method that I have been involved with in recent years on various projects. And the phrase “client-server” is the key to understanding what this method is. It captures the fundamental architectural changes that include aspects of the terms listed above, but represents the distinct partitioning between the client and server and considers each of the roles significant.

A client-server architecture of web applications requires a shift (in some cases seismic) inthewayprogrammerswork.Thisbookwaswrittentoenabledeveloperstodealwith this revolution. Specifically, it is intended to provide a proper perspective in building the latest incarnation of modern web applications.

Who Is This Book For?

This book is written for web application developers who are are familiar with the Java programminglanguage,aswellasHTML,JavaScript,andCSS.Itisgearedtowardthose who“learnbydoing”andprefertoseeandcreatespecificexamplesofnewtechnologies and techniques integrated with standard tools. If you want a better understanding of xii | Preface

recent developments in JavaScript and how the language and its development process compare with those of Java, this book is for you.

A bit of a balancing act is evident as you read this book. On the one hand, the most important thing you can take away is a sense of the “big picture”—the influences and trends causing a shift in the technologies in use. On the other hand, technologies are often best understood by seeing specific examples. If you are interested in an overview of how these technologies actually fit together, you will benefit from this book.

Mygoalinwritingthisistohelpyoutomakeinformeddecisions.Gooddecisionsresult in the right technologies being used on new projects. They allow you to avoid pitfalls caused by mixing incompatible technologies or having the wrong expectations about the implications of a given decision. They help you to step into projects in process and better support existing code. In short, informed decisions will make you a more pro‐ductiveprogrammer.Theyhelpyoumakeeffectiveuseofyourtimeinresearchingareas of specific interest in your work now and in the future.

How This Book Is Organized

Chapter1providesageneraloverviewoftheclient-serverwebapplicationarchitecture. Itdiscussesthehistoryofwebdevelopmentandprovidesajustificationfortheparadigm shift in development. This leads into the next three chapters that will describe the tools used in the development process.

Chapter 2 describes JavaScript and the tools used in JavaScript development.

Chapter 3 introduces web API design, REST, and the tools used when developing RESTful applications over HTTP.

Chapter 4pertains to Java and other software that’s used in the remainder of this book.

The next section of the book discusses higher-level constructs (such as client libraries and application servers) and how these provide separation and allow for rapid devel‐opment.

Chapter 5 describes major client-side JavaScript frameworks.

Chapter 6 addresses Java API servers and services.

Chapter 7 discusses rapid development practices.

Chapter 8 delves into API design in greater depth.

Withanunderstandingoflibrariesandaprocessforspeedydevelopmentofprototypes, the next several chapters apply these to specific projects using various JVM languages and frameworks. The next two chapters use lightweight web servers and microframe‐works instead of traditional Java web application packaging and servers.

Chapter 9 provides an overview of a project using jQuery and Jython. Preface | xiii

Chapter 10 documents the development of a project using JRuby and Angular.

The final chapters detail projects using traditional Java web application servers and libraries.

Chapter11looksattherangeofpackaginganddeploymentoptionsavailableintheJava ecosystem.

Chapter 12explores virtualization and innovations emerging from the management of large server environments.

Chapter 13 draws attention to testing and documentation.

Chapter14wrapsupwithsomefinalthoughtsonrespondingtothetumultuouschanges to Internet-related technologies and software development.

Appendix A describes how to explore and manipulate Java classes interactively.

Conventions Used in This Book

The following typographical conventions are used in this book: Italic

Indicates new terms, URLs, filenames, and file extensions.

Constant width

Usedforprogramlistings,aswellaswithinparagraphstorefertovariables,method names, and other code elements, as well as the contents of files.

Constant width bold

Highlights new code in an example.

Constant width italic

Shows text that should be replaced with user-supplied values.

This element signifies a tip, suggestion, or general note.

This element indicates a warning or caution.

| Preface

Code Examples

Projects and code examples in this book are hosted on https://github.com/javajavascript/client-server-web-apps. You can view them online or download a .zip file for local use. The assets are organized by chapter.

The code examples provided in this book are geared toward illustrating specific func‐tionality rather than addressing all concerns of a fully functional application. Differ‐ences include:

• Production systems include greater refinement of selected data types, validation rules, exception handing routines, and logging mechanisms.

• Mostproductionsystemswillincludeoneormorebackenddatastores.Tolimitthe scope of discussion, databases are not accessed in most of the examples.

• The modern web application includes a large amount of infrastructure geared to‐ward mobile device access and browser compatibility. Again, unless these are the specific topic of discussion, responsive design is eschewed for a more minimal design.

• The practice of some degree of unobtrusive JavaScript to separate CSS and Java‐Script from HTML is a generally accepted best practice. In the examples in this book,theyarefrequentlycommingledbecauseallaspectsofagivenapplicationcan be immediately apprised by viewing a single file.

• Unit tests and testing examples are only included when they are directly related to the topic under discussion. Production systems would include far greater test cov‐erage and extensive testing in general.

That said, this book is intended to help you get your job done. In general, you may use thecodeinthisbookinyourprogramsanddocumentation.Youdonotneedtocontact us for permission unless you are reproducing a significant portion of the code. For example, writing a program that uses several sections of code from this book does not requirepermission.SellingordistributingaCD-ROMofexamplesfromO’Reillybooks doesrequirepermission.Answeringaquestionbycitingthisbookandquotingexample code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title,author,publisher,andISBN.Forexample:“Client-ServerWebAppswithJavaScript and Java” by Casimir Saternos (O’Reilly). Copyright 2014 EzGraphs, LLC., 978-1-449-36933-0.”

Ifyoufeelyouruseofcodeexamplesfallsoutsidefairuseorthepermissiongivenhere, feel free to contact us at permissions@oreilly.com

Preface | xv

Long Command Formats

Code displayed inline will be adjusted to be readable in this context. One convention used is that of backslashes to allow newlines in operating system commands. So for instance, the following commands are equivalent and would execute the same way in a bash session. (Bash is a standard operating system shell that you see when accessing a Linux server or Mac OS X at the command line.)

ls -l *someVeryLongName*

...

ls -l \ *someVeryLongName*

ThesameconventionalsoappearsinothersettingswhereOScommandsareused,such as Dockerfiles.

Similarly,JSONstrings,beingvalidJavaScript,canbebrokenuptofitonmultiplelines:

o={"name": "really long string here and includes many words"}

// The following, as expected, evaluates to true.

JSON.stringify(o)=='{"name":"really long string here and includes many words"}'

// The same string broken into multiple lines is equivalent.

// So the following statement also evaluates to true.

JSON.stringify(o)=='{"name":' + '"some really long ' + 'JSON string is here' + ' and includes many, many words"}'

Safari® Books Online

Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

Technology professionals, software developers, web designers, and business and crea‐tiveprofessionalsuseSafariBooksOnlineastheirprimaryresourceforresearch,prob‐lem solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organi‐zations,governmentagencies,andindividuals.Subscribershaveaccesstothousandsof books,trainingvideos,andprepublicationmanuscriptsinonefullysearchabledatabase from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐ogy,anddozensmore.FormoreinformationaboutSafariBooksOnline,pleasevisitus online

xvi | Preface

How to Contact Us

Every example in this book has been tested, but occasionally you may encounter prob‐lems.Mistakesandoversightscanoccurandwewillgratefullyreceivedetailsofanythat you find, as well as any suggestions you would like to make for future editions. Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international or local)

707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/client-server-web-apps-js.

To comment or ask technical questions about this book, send email to bookques tions@oreilly.com.

Formoreinformationaboutourbooks,courses,conferences,andnews,seeourwebsite at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments

Thank you to the following people:

• Meg, Ally, Simon, and the gang at O’Reilly for the opportunity to write this book.

• My brother Neal Saternos and Dr. James Femister for the early suggestions from days gone by that I might be able to do the “programming thing.”

• Michael Bellomo, Don Deasey, and Scott Miller for their time and expertise as technical reviewers.

• Charles Leo Saternos for taking a break from Lua game development to do some fine image and design work.

• CalebLewisSaternosforinspirationinperserverence(earlymorningrunanyone?) and editorial work.

• David Amidon for the first opportunity to work as a software developer and Doug Pelletier for first the opportunity to develop Java web apps.

Preface | xvii

• Allthefolksthatheadeduptheprojectsthatinspiredthisbook,includingmanagers Wayne Hefner, Tony Powell, Dave Berry, Jay Colson, and Pat Doran, and chief software architects Eric Fedok and Michael Bellomo.

• GeoffreyGrosenbachfromPluralSight,NatDunnfromWebucator,CarolineKvit‐ka(andothersfromOracleandJavaMagazine)fortechnicalwritingopportunities over the past several years that led to the current one.

• My parents Leo and Clara Saternos for bringing me up in a loving household that included a Radio Shack Color Computer when having a PC at home was still a novelty and my sister Lori for reminders of important things that have nothing to do with programming.

My love and thanks to my wonderful wife Christina and children Clara Jean, Charles Leo, Caleb Lewis, and Charlotte Olivia for the consistent love, support, patience, and inspiration while this project was underway.

Finally, J.S. Bach serves as a creative inspiration on many levels. Not the least of which is the dedication that would appear at the beginning of his works—and so I say with him, Soli Deo Gloria.

xviii | Preface

CHAPTER

1

Change Begets Change

The entrepreneur always searches for a change, responds to it, and exploits it as an opportunity.

What kinds of changes encourage developers to adopt a client-server approach? Shifts in user behavior, technology, and software development process are the significant forces that have driven developers to change their patterns of design. Each of these factors, in a unique and significant way, makes established patterns obsolete. Together they have encouraged related innovations and a convergence in practice despite the absence of enforcement or mandated standardization.

Web users have changed. In the early days of the Web, users were satisfied with static pages and primitive user interfaces. The modern web user has come to expect a highperformance, interactive, well-designed, dynamic experience. These higher expecta‐tions were met with an explosion in new technologies and expansion of web browser capabilities.Today’swebdeveloperneedstousetoolsandadevelopmentapproachthat are aligned with the modern web scene.

Technology has changed. Browsers and JavaScript engines are faster. Workstations and laptops are far more powerful, to say nothing of the plethora of mobile devices now being used to surf the Web. Web service APIs are the expectation for a modern web application rather than a rare additional feature. Cloud computing is revolutionizing the deployment and operation of web applications.

Software development has changed. The now popular “Agile Manifesto” values:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

It is now possible to quickly spin up web applications that prove—at least on a small scale—theviabilityofagiventechnology.Thereistremendousvaluetoprototyping.As Fred Brooks, author of The Mythical Man Month (Addison-Wesley Professional), fa‐mously stated: “Plan to throw one away; you will, anyhow.” A prototype can allow for early customer or end user interaction that helps solidify requirements early in the process. It is no longer an insurmountable task to write a functional web application in a matter of minutes.

Web Users

Modern web application users have well-defined expectations about how they will be able to interact with a web application:

• Web applications will be available across multiple platforms.

• They will provide a consistent experience across devices.

• They will respond with little or no latency.

The Gartner group claims that in 2014, the personal cloud will replace the PC at the center of users’ digital lives. There are many implications for web app development. Usersaremoretechnologicallysavvyandhavehighexpectationsforsiteresponsiveness. They are less passive than in previous years and instead are interactive and engaged. Websites need to be designed in a way that suggests no limitations in the ability of a browser to mimic native application experience.

Users expect an application to be exposed in various ways and available in different situations.Responsivedesignandsupportformultiplebrowsers,platforms,anddevices arethenewnorm.TheuseofJavaScriptlibrariesandframeworksisessentialtosupport the wide variety of target clients.

The New York Times recently reported on the impatience of web users. Among its findings: a company’s website will be visited less often than that of a close competitor if itisslowerbymorethan250milliseconds.Performanceneedstobeakeyconsideration in web application development.

2 | Chapter1:ChangeBegetsChange

Technology

Javawebapplicationdevelopersaretypicallyfamiliarwithserver-sidedynamiccontent. J2EE and JSP have been refined into JEE and JSF. Projects such as Spring provide ad‐ditionalcapabilitiesgearedtowardserver-sidedevelopment.Thismodeofdevelopment made a great deal of sense in the early days of the Web, when web pages were relatively static, servers were relatively fast, JavaScript engines were slow, and there were few libraries and techniques to address browser incompatibilities.

Bywayofcontrast,amodernclient-serverapproachinvolvesaserverlargelyresponsible for providing access to resources (typically communicated as messages in XML or JSON) in response to client requests. In the old server-driven approach, the browser requested an entire page and it was generated (along with relevant data) for rendering in the browser. In the client-server approach, the server initially serves pages with little data. The pages make asynchronous requests to the server as the user interacts with it and the server simply responds to these events with messages that cause the current page to be updated.

Initial web development efforts consisted of the creation of static HTML sites. Later, these sites were augmented with dynamic content using server-side processing (CGI, Java Servlets). Subsequently, more structured language integration emerged using server-sidetemplating(ASP,PHP,JSP)andMVCframeworks.Morerecenttechnologies continue in the same tradition and provide additional abstractions of one sort or another.

Based upon a desire to shield developers from design concerns and the underlying architectureoftheWeb,component-basedframeworkshaveemerged.Taglibrarieswere an early innovation, and now a component-based approach has been widely adopted in several popular frameworks:

• Java Server Faces (JSF), an XML-based templating system and component frame‐work with centralized configurable navigation.

• The Google Web Toolkit is another component framework that leverages the abil‐ities of Java programmers by letting them focus on Java coding with little need to directly modify HTML, CSS, or JavaScript.

Each of these frameworks has its place and has been used successfully in production systems. But like many solutions that try to hide underlying complexities, their usage is problematic in situations where you need greater control (such as the ability to inte‐gratelargeamountsofJavaScript)oryoudonotconformtotheframeworkassumptions (for instance, availability of server sessions). This is because these solutions attempt to hide the fundamental architecture of the Web, which uses an HTTP request-response protocol following the client-server computing model.

Browser innovations also led to a shift of responsibility from the server to the client. In thelate1990s,MicrosoftdevelopedtheunderlyingtechnologiesthatledtoAjax(aterm coined on February 18, 2005 by Jesse James Garrett). Ajax is an acronym for “asyn‐chronous JavaScript and XML,” but is more generally applied to various technologies used to communicate with the server within the context of a given web page. This allowedsmallmessagestobesent,whichmadebetteruseofbandwidthwhendesigning JavaScript-basedwebapplications.Browserperformancehasincreasedsignificantlydue to processor improvements and optimizations to JavaScript engines, so it has made sensetooffloadmoreworkfromtheservertothebrowser.Userinterfaceresponsiveness has evolved to a new level of sophistication.

Mobile device browsers have also provided an additional incentive to further isolate client-side code from the server. In some cases, a well-designed application leveraging responsive design principles can be created. If this is not an option, a single consistent API available for all device clients is very appealing.

RoyFielding’sdoctoraldissertationin2000ledJavaEE6tonewAPIsthatdeviatedfrom thepreviouscomponent-basedtrajectory.JAX-RS(JavaAPIforRESTfulWebServices) and Jersey (a “production quality reference implementation”) are designed to create applications reflecting a client-server architecture with RESTful communications.

Software Development

In the past, setting up a new Java project was a rather monumental task. A vast array of configuration options made it tedious and error-prone. Very little was automated, as theassumptionwasthateachprojectwouldhaveuniquecharacteristicsthatdevelopers would want to account for to meet their specific requirements.

Later influences led to innovations that made setting up a project much simpler. “Con‐ventionoverconfiguration”wasaninfluentialmantraoftheRubyonRailscommunity. Maven and other Java projects also chose sensible defaults and target easy setup for a subset of popular use cases.

The availability of scripting languages on the JVM makes it possible to speed develop‐mentbybypassingthesomewhatrigoroustypecheckingofJava.LanguageslikeGroovy, Python(Jython),andRubyarelooselytypedandconstructedinamannerthatrequires less code to accomplish equivalent functionality. So-called microframeworks like Sina‐tra or Play provide minimal Domain Specific Languages (DSLs) to quickly write web applications and services. And so today, it is a trivial task to set up a minimal set of web services in a development environment.

Thefailureofenoughlarge-scalewaterfall-stylesoftwareprojectshasalsomadeitclear that there are many advantages to producing a small-scale version of the final product. A prototype (or prototypes) of the final product can serve many purposes:

• Verify technical foundation of the project

• Create constructs that bridge disparate technologies to be used together

• Allow end user interaction to clarify intended usage and user interface design

• Allow system designers to clarify the interfaces and data structures to be passed between systems

• Allow programmers to work on different parts of the application in parallel

Prototypes have numerous benefits:

• They are a specific, tangible asset representing the final system to be designed. As such, they incorporate information that is otherwise stored in design documents, diagrams,andotherartifacts(andfrequentlyinmoreinformallocationslikeemail and people’s memories of water-cooler conversations).

• Prototypes are concrete implementations. As such, they present the requirements inamuchmoretangibleform.Thiscanleadtoabetterunderstandingoftheextent andqualityoftherequirementsgathered,andcansuggestareaswherethereisneed of clarification.

• Prototypescanimmediatelyexposepotentialpointsoffailurethatarenotapparent before attempting a specific implementation.

• The preceding benefits can lead to better estimates and scheduling due to a more comprehensive understanding of what is intended.

Prototyping can be leveraged extensively in client-server web application development because of the clear and unambiguous separation between the client and server. Pro‐totypes of the server can be provided to the client developers (and vice versa) while development proceeds in parallel. Or if development is not proceeding in parallel, server-side calls can be quickly stubbed out so that client-side code can be developed.

What Has Not Changed

The fundamental nature of the Web (a client-server architecture transmitted over HTTP) has not changed.

New technology does not change everything. High-level programming languages have notremovedtheneedtounderstandoperatingsystemspecifics.Object-relationalmap‐ping frameworks have not removed the need to understand relational databases and SQL. In like manner, there have been consistent attempts to ignore the underlying ar‐chitecture of the Web in an effort to emulate the experience of desktop applications.

Medium Specificity

Medium specificity is a term that appears in aesthetics and modern art criticism but which can be applied to technology as well. It indicates the “appropriateness” of a given artistic subject to be presented by a given medium. The idea has been around for cen‐turies. Gotthold Ephraim Lessing states in his Lacoon:

[B]odies, with their visible properties, are the legitimate subjects of painting. [A]ctions are [therefore] the legitimate subjects of poetry.

The Limits of Poetry and Painting

Its application in modern art is usually to challenge traditional limits that appeared in the arts. Technology is a creative activity, but our primary concern is working systems, not abstract beauty. The idea of medium specificity is important in that, if you ignore theunderlyingnatureofaplatform,theresultingsystemwillneverperforminanoptimal manner or will not work at all. This has become painfully obvious in many areas of technology. The goal of this book is to promote web application design strategies that are aligned with the way the Web itself is designed. Such applications operate well be‐cause they work within the Web’s fundamental constraints rather than ignoring them.

The Nature of the Web

The essence of the Web has not changed. It is still made up of servers that serve HTML documents to clients via the HTTP protocol. See Figure 1-1.

A client-server web architecture more closely maps to the underlying architecture of the Web itself. Although not technically protocol-specific, REST was developed based uponandinconjunctionwithHTTP.RESTessentiallydefinesconstraintsontheusage ofHTTP.Itseekstodescribeawell-designedwebapplication:areliableapplicationthat performs well, scales, has a simple elegant design, and can be easily modified (Figure 1-2).

6 | Chapter1:ChangeBegetsChange

Figure 1-1. HTTP request and response

Figure 1-2. REST request and response

In fact, to more accurately emphasize the challenges in the modern web environment, we need to consider multiple devices and cloud deployments. See Figure 1-3

Figure 1-3. Multiple devices and cloud deployments

The specific area of “medium specificity” that has been ignored in web development in general (and in component frameworks in particular) is the stateless, client-server na‐ture of the Web itself.

Server-Driven Web Development Considered Harmful

Just because a given feature is available does not mean that it should be used. In many cases, a server-driven, component-based approach to web development should be re‐placedwithaclient-serverone.Server-drivenapproachesobscurethenatureoftheWeb itself, which is a client-server technology built on the HTTP protocol. Ignoring or ob‐scuring the fundamental underlying architecture of the Web makes development, de‐bugging, and support of software systems more difficult. The intention, to make the Websomehowsimpleroreasiertounderstand,breaksdownratherquicklyinanynon‐trivialsystemwherethereneedstobeaclearunderstandingwhatfunctionalityisavail‐able and how the system actually works.

Considered Harmful

In 1968, Edsger W. Dijkstra published a letter entitled “Go To Statement Considered Harmful.” Besides being of interest because it made a considerable impact on reducing the use of the goto statement in structured programming, it introduced the phrase “considered harmful” into hacker culture. Tom Christiansen argued against program‐ming in csh. Douglas Crawford published a blog post entitled “with Statement Consid‐ered Harmful”. The phrase has appeared in many other settings as well, and despite the amusingly self-referential “‘Considered Harmful’ Essays Considered Harmful” by Eric A. Meyer, the phrase continues to appear.

Although “Considered Harmful” attention articles are not always of equal merit, the theme arises out of a valid recognition that just because a language feature or technical solution is available, does not mean it is a great general purpose, long-term solution.

Why Client-Server Web Applications?

There are a number of advantages to a client-server approach to web development.

Code Organization/Software Architecture

Thereareclearadvantagestobeingabletodecouplelogicalsectionsofcodeandpromote higher cohesion both in the original construction and ongoing support of any system. The clear separation between client and server tiers makes for manageable, modular sections of code. In addition, data and display markup can be more clearly separated. ThedatacanbedeliveredinJSONratherthaninline.Thisisconsistentwiththemodern JavaScript notion of unobtrusive JavaScriptwhere a page’s behavior, structure, and pre‐sentation are separated.

Flexibility and code reuse are a logical outcome of good code organization. There is flexibility at many stages in the application life cycle when sections of code can be de‐veloped in relative isolation (APIs can be exposed, mobile device clients created, new versions of sections of the application tested and released independently). Code reuse is more likely when there are clear components. At minimum, the same RESTful APIs can be used to serve data to a wide variety of browsers and mobile devices.

Componentapproachestendtointroducebrittlecouplingandarelessadaptable.There is no way to plug in a different frontend easily.

Flexibility of Design/Use of Open Source APIs

Component-based approaches include tightly integrated server-side code that requires specificJavaScripttechnology.TheyalsogenerateHTMLandCSSthatlimitstheoptions

available from a design and behavior perspective. A distinct client running JavaScript can take advantage of the latest libraries that ease browser compatibility, standardize DOM manipulation, and provide complex widgets.

Prototyping

Prototyping works well with client-server web applications due to the clear separation between tiers. As previously mentioned, prototypes can test and verify initial ideals. They help clarify vague notions and facilitate clear communication regarding require‐ments.Theycaninspireandgeneratenewideasaspeopleinteractwithsomethingmore concretethanalongtextdescriptionoraseriesofpictures.Badideasandinconsistencies can be quickly recognized and eliminated. Used correctly, prototypes can save time, money, and resources and result in a better final product.

Developer Productivity

Besides the ability to prototype either the client portion or the server component (or both),workcanbesplitclearly,anddevelopmentcanprogressinparallel.Theseparation allowssectionsofcodetobebuiltinisolation.Thispreventstheproblemincomponent approaches where a server build is required every time a page is changed during de‐velopment. Development tasks require less time and effort, changes are less complex, and troubleshooting is simplified.

Thisisespeciallyevidentwhenaneedarisestoreplace,upgrade,orrelocateserver-side code. Such changes can be done independently, without affecting the client. The only limitationisthattheoriginalinterface,specificallytheURLandmessagedatastructure, must remain available.

Application Performance

User experience is greatly impacted by the perceived performance of a page in the browser.FasterJavaScriptenginesallowtheclienttoperformcomputationallyintensive operations so server workload can be effectively offloaded to the client. Ajax requires relatively small amounts of data to be retrieved when needed so full page reloads can occur infrequently and less data is sent in the intervening requests. Users perceive a snappier, more immediate response as they interact with an application.

Therearemanybenefitstostatelessdesignthateasethelivesofdevelopersandsupport staff.Resourcesdedicatedtosessionmanagementcanbefreedup.Thissimplifiesloadbalancing and configuration that would otherwise be required. Servers can be easily addedtoaccommodateincreasedloadallowingfor horizontal scalability.Thisreplaces the unwieldy process of hardware upgrades traditionally used to increase throughput and performance.

Another random document with no related content on Scribd:

a young man son off to school in his stead, feeling vaguely thankful that I should have until Christmas to get used to the thought of him before having to see him again.

Shortly afterward I returned to the White House and to the routine of a social season. The Cabinet officers having all gone to their respective homes we gave the Cabinet Dinner with all its accustomed formalities, then came musicals, luncheons, small dinners, teas and parties of various sorts until near the end of the year when I introduced my daughter to society.

Helen had gone out in Washington and had attended my entertainments during the winter of 1909 whenever she had been at home from college and when I was ill had even acted as hostess in my place at a dinner we gave for Prince and Princess Fushimi of Japan, but she had never “come out,” so I gave two parties early in the winter of 1910 in honor of her début.

We began with an afternoon At Home, for which, as my daughter says she “got all the flowers there were in Washington,” and later I gave a ball on the night of December 30th, when the East Room was filled with hundreds of young people clamouring for “just one more dance” until two o’clock in the morning.

The New Year’s Reception was followed in quick succession by the Diplomatic, Congressional, Judicial and other state functions; the winter passed like a dream; the Garden Party season was upon us; then came the greatest event of our four years in the White House, our Silver Wedding.

Twenty-five years married and all but a single year of it spent in the public service. It did not seem unfitting to me that this anniversary should be spent in the White House or that we should seek to make it an event not to be forgotten by anybody who happened to witness it. I thanked the happy fate that had given me a summer wedding-day because I needed all outdoors for the kind of party I wanted to give. That silver was showered upon us until we were almost buried in silver was incidental; we couldn’t help it; it was our twenty-fifth anniversary and we had to celebrate it.

I am not going to try to remember or to take the trouble to find out how many invitations we issued. I know there were four or five

thousand people present and that a more brilliant throng was never gathered in this country.

It was a night garden party with such illuminations as are quite beyond description. Every tree and bush was ablaze with myriads of tiny coloured lights, the whole stately mansion was outlined in a bright white glow; there were strings of bobbing, fantastic lanterns wherever a string would go; the great fountain was playing at its topmost height in every colour of the rainbow; while on the gleaming point of the Monument and on the flag stretched in the breeze from the staff on the top of the White House shone the steady gleam of two searchlights.

My husband and I received the almost endless line of guests under a large tree about midway between the South Portico and the fountain; the entire house was thrown open and was filled constantly with people seeking the refreshment tables laid in the dining rooms and vestibule. I have a right to be enthusiastic in my memory of that party because without enthusiasm it could not have been given at all. And why should not one be frankly grateful for success?

With the passing of another season, in no way different from those that went before, I come to the end of my story. There is another story to tell, longer and fuller, but it does not belong to me. It belongs to the man whose career has made my story worth the telling.

After Mr. Taft was renominated, or rather after the second convention in Chicago when the Republican party was divided, I began to make plans for the future in which the White House played no part. I stopped reading the accounts of the bitter political contest because I found that the opposition newspapers made so much more impression on me than those that were friendly to my husband that I was in a state of constant rage which could do me no possible good.

Mr. Taft had never been subjected to bitter criticism and wholesale attack until his term in the Presidency and I suppose I had formed a habit of thinking that there was nothing to criticise him for except, perhaps, his unfortunate shortcoming of not knowing much and of caring less about the way the game of politics is played. Such criticism of him as Mr. Bryan’s supporters were able to create for their use in 1908 amounted to nothing. His record of twenty years’ uncriticised service stood, and he stood on it. I think we both avoided much perturbation after we became convinced of the unfairness and

injustice of much that was said by hostile newspapers, by not reading it. Mr. Taft took much satisfaction from those words of Lincoln’s which Mr. Norton, his Secretary, had photographed and placed in a frame on his office desk:

“If I were to try to read, much less answer, all the attacks made on me this shop might as well be closed for any other business. I do the very best I know how—the very best I can; and I mean to keep on doing so until the end. If the end brings me out all right, what is said against me won’t amount to anything. If the end brings me out wrong, ten angels swearing I was right would make no difference.”

I wanted him to be re-elected, naturally, but I never entertained the slightest expectation of it and only longed for the end of the turmoil when he could rest his weary mind and get back into association with the pleasant things of life. Fortunately we are a family that laughs. Both Mr. Taft and the children manage to get some fun out of almost everything, and I and my matter of factness have afforded them lifelong amusement. They like now to tell a story about me which doesn’t impress me as being particularly funny.

During the last campaign I was at Beverly alone a good part of the summer, but when Mr. Taft did join me for short intervals he brought Republican Headquarters with him, more or less, and a few political supporters were sure to follow for consultation with him.

There was one good old enthusiastic friend who had always supported him and who was then making a valiant fight in his behalf. And he had faith that they would win. He assured me they would win. He told me how they were going to do it, pointing out where Mr. Taft’s strength lay and telling me how kindly the people really felt toward him.

“Mrs. Taft, you mark my word,” said he, “the President will be reelected in November!”

“Well,” said I, “ you may be right, but just the same I intend to pack everything up when I leave Beverly, and I shall take the linen and silver home.”

At a dinner given by the Lotos Club in New York, just ten days after Mr. Wilson’s election in 1912, Mr. Taft said:

“The legend of the lotos eaters was that if they partook of the fruit of the lotos tree they forgot what had happened in their country and were left in a state of philosophic calm in which they had no desire to return to it.

“I do not know what was in the mind of your distinguished invitation committee when I was asked to attend this banquet. They came to me before election. At first I hesitated to accept lest when the dinner came I should be shorn of interest as a guest and be changed from an active and virile participant in the day’s doings of the Nation to merely a dissolving view. I knew that generally on an occasion of this sort the motive of the diners was to have a guest whose society should bring them more closely into contact with the great present and the future and not be merely a reminder of what has been. But, after further consideration, I saw in the name of your club the possibility that you were not merely cold, selfish seekers after pleasures of your own, and that perhaps you were organised to furnish consolation to those who mourn, oblivion to those who would forget, an opportunity for a swan song to those about to disappear....

“The Presidency is a great office to hold. It is a great honour and it is surrounded with much that makes it full of pleasure and enjoyment for the occupant, in spite of its heavy responsibilities and the shining mark that it presents for misrepresentation and false attack.... Of course the great and really the only lasting satisfaction that one can have in the administration of the great office of President is the thought that one has done something permanently useful to his fellow countrymen. The mere enjoyment of the tinsel of office is ephemeral, and unless one can fix one’s memory on real progress made through the exercise of presidential power there is little real pleasure in the contemplation of the holding of that or any other office, however great its power or dignity or high its position in the minds of men.

“I beg you to believe that in spite of the very emphatic verdict by which I leave the office, I cherish only the deepest gratitude to the American people for having given me the honour of having held the office, and I sincerely hope in looking back over what has been done that there is enough of progress made to warrant me in the belief that real good has been accomplished, even though I regret that it

has not been greater. My chief regret is my failure to secure from the Senate the ratification of the general arbitration treaties with France and Great Britain. I am sure they would have been great steps toward general world peace. What has actually been done I hope has helped the cause of peace, but ratification would have been a concrete and substantial step. I do not despair of ultimate success. We must hope and work on.”

THE END

TRANSCRIBER’S NOTES

1. Silently corrected obvious typographical errors and variations in spelling.

2. Retained archaic, non-standard, and uncertain spellings as printed.

*** END OF THE PROJECT GUTENBERG EBOOK RECOLLECTIONS OF FULL YEARS ***

Updated editions will replace the previous one—the old editions will be renamed.

Creating the works from print editions not protected by U.S. copyright law means that no one owns a United States copyright in these works, so the Foundation (and you!) can copy and distribute it in the United States without permission and without paying copyright royalties. Special rules, set forth in the General Terms of Use part of this license, apply to copying and distributing Project Gutenberg™ electronic works to protect the PROJECT GUTENBERG™ concept and trademark. Project Gutenberg is a registered trademark, and may not be used if you charge for an eBook, except by following the terms of the trademark license, including paying royalties for use of the Project Gutenberg trademark. If you do not charge anything for copies of this eBook, complying with the trademark license is very easy. You may use this eBook for nearly any purpose such as creation of derivative works, reports, performances and research. Project Gutenberg eBooks may be modified and printed and given away—you may do practically ANYTHING in the United States with eBooks not protected by U.S. copyright law. Redistribution is subject to the trademark license, especially commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE

PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the free distribution of electronic works, by using or distributing this work (or any other work associated in any way with the phrase “Project Gutenberg”), you agree to comply with all the terms of the Full Project Gutenberg™ License available with this file or online at www.gutenberg.org/license.

Section 1. General Terms of Use and Redistributing Project Gutenberg™ electronic works

1.A. By reading or using any part of this Project Gutenberg™ electronic work, you indicate that you have read, understand, agree to and accept all the terms of this license and intellectual property (trademark/copyright) agreement. If you do not agree to abide by all the terms of this agreement, you must cease using and return or destroy all copies of Project Gutenberg™ electronic works in your possession. If you paid a fee for obtaining a copy of or access to a Project Gutenberg™ electronic work and you do not agree to be bound by the terms of this agreement, you may obtain a refund from the person or entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only be used on or associated in any way with an electronic work by people who agree to be bound by the terms of this agreement. There are a few things that you can do with most Project Gutenberg™ electronic works even without complying with the full terms of this agreement. See paragraph 1.C below. There are a lot of things you can do with Project Gutenberg™ electronic works if you follow the terms of this agreement and help preserve free future access to Project Gutenberg™ electronic works. See paragraph 1.E below.

1.C. The Project Gutenberg Literary Archive Foundation (“the Foundation” or PGLAF), owns a compilation copyright in the collection of Project Gutenberg™ electronic works. Nearly all the individual works in the collection are in the public domain in the United States. If an individual work is unprotected by copyright law in the United States and you are located in the United States, we do not claim a right to prevent you from copying, distributing, performing, displaying or creating derivative works based on the work as long as all references to Project Gutenberg are removed. Of course, we hope that you will support the Project Gutenberg™ mission of promoting free access to electronic works by freely sharing Project Gutenberg™ works in compliance with the terms of this agreement for keeping the Project Gutenberg™ name associated with the work. You can easily comply with the terms of this agreement by keeping this work in the same format with its attached full Project Gutenberg™ License when you share it without charge with others.

1.D. The copyright laws of the place where you are located also govern what you can do with this work. Copyright laws in most countries are in a constant state of change. If you are outside the United States, check the laws of your country in addition to the terms of this agreement before downloading, copying, displaying, performing, distributing or creating derivative works based on this work or any other Project Gutenberg™ work. The Foundation makes no representations concerning the copyright status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project Gutenberg:

1.E.1. The following sentence, with active links to, or other immediate access to, the full Project Gutenberg™ License must appear prominently whenever any copy of a Project Gutenberg™ work (any work on which the phrase “Project Gutenberg” appears, or with which the phrase “Project

Gutenberg” is associated) is accessed, displayed, performed, viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is derived from texts not protected by U.S. copyright law (does not contain a notice indicating that it is posted with permission of the copyright holder), the work can be copied and distributed to anyone in the United States without paying any fees or charges. If you are redistributing or providing access to a work with the phrase “Project Gutenberg” associated with or appearing on the work, you must comply either with the requirements of paragraphs 1.E.1 through 1.E.7 or obtain permission for the use of the work and the Project Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is posted with the permission of the copyright holder, your use and distribution must comply with both paragraphs 1.E.1 through 1.E.7 and any additional terms imposed by the copyright holder. Additional terms will be linked to the Project Gutenberg™ License for all works posted with the permission of the copyright holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project Gutenberg™ License terms from this work, or any files containing a part of this work or any other work associated with Project Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute this electronic work, or any part of this electronic work, without prominently displaying the sentence set forth in paragraph 1.E.1 with active links or immediate access to the full terms of the Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary, compressed, marked up, nonproprietary or proprietary form, including any word processing or hypertext form. However, if you provide access to or distribute copies of a Project Gutenberg™ work in a format other than “Plain Vanilla ASCII” or other format used in the official version posted on the official Project Gutenberg™ website (www.gutenberg.org), you must, at no additional cost, fee or expense to the user, provide a copy, a means of exporting a copy, or a means of obtaining a copy upon request, of the work in its original “Plain Vanilla ASCII” or other form. Any alternate format must include the full Project Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying, performing, copying or distributing any Project Gutenberg™ works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or providing access to or distributing Project Gutenberg™ electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you derive from the use of Project Gutenberg™ works calculated using the method you already use to calculate your applicable taxes. The fee is owed to the owner of the Project Gutenberg™ trademark, but he has agreed to donate royalties under this paragraph to the Project Gutenberg Literary Archive Foundation. Royalty payments must be paid within 60 days following each date on which you prepare (or are legally required to prepare) your periodic tax returns. Royalty payments should be clearly marked as such and sent to the Project Gutenberg Literary Archive Foundation at the address specified in Section 4, “Information

about donations to the Project Gutenberg Literary Archive Foundation.”

• You provide a full refund of any money paid by a user who notifies you in writing (or by e-mail) within 30 days of receipt that s/he does not agree to the terms of the full Project Gutenberg™ License. You must require such a user to return or destroy all copies of the works possessed in a physical medium and discontinue all use of and all access to other copies of Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of any money paid for a work or a replacement copy, if a defect in the electronic work is discovered and reported to you within 90 days of receipt of the work.

• You comply with all other terms of this agreement for free distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™ electronic work or group of works on different terms than are set forth in this agreement, you must obtain permission in writing from the Project Gutenberg Literary Archive Foundation, the manager of the Project Gutenberg™ trademark. Contact the Foundation as set forth in Section 3 below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend considerable effort to identify, do copyright research on, transcribe and proofread works not protected by U.S. copyright law in creating the Project Gutenberg™ collection. Despite these efforts, Project Gutenberg™ electronic works, and the medium on which they may be stored, may contain “Defects,” such as, but not limited to, incomplete, inaccurate or corrupt data, transcription errors, a copyright or other intellectual property infringement, a defective or damaged disk or other

medium, a computer virus, or computer codes that damage or cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGESExcept for the “Right of Replacement or Refund” described in paragraph 1.F.3, the Project Gutenberg Literary Archive Foundation, the owner of the Project Gutenberg™ trademark, and any other party distributing a Project Gutenberg™ electronic work under this agreement, disclaim all liability to you for damages, costs and expenses, including legal fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH

1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you discover a defect in this electronic work within 90 days of receiving it, you can receive a refund of the money (if any) you paid for it by sending a written explanation to the person you received the work from. If you received the work on a physical medium, you must return the medium with your written explanation. The person or entity that provided you with the defective work may elect to provide a replacement copy in lieu of a refund. If you received the work electronically, the person or entity providing it to you may choose to give you a second opportunity to receive the work electronically in lieu of a refund. If the second copy is also defective, you may demand a refund in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS

OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied warranties or the exclusion or limitation of certain types of damages. If any disclaimer or limitation set forth in this agreement violates the law of the state applicable to this agreement, the agreement shall be interpreted to make the maximum disclaimer or limitation permitted by the applicable state law. The invalidity or unenforceability of any provision of this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation, the trademark owner, any agent or employee of the Foundation, anyone providing copies of Project Gutenberg™ electronic works in accordance with this agreement, and any volunteers associated with the production, promotion and distribution of Project Gutenberg™ electronic works, harmless from all liability, costs and expenses, including legal fees, that arise directly or indirectly from any of the following which you do or cause to occur: (a) distribution of this or any Project Gutenberg™ work, (b) alteration, modification, or additions or deletions to any Project Gutenberg™ work, and (c) any Defect you cause.

Section 2. Information about the Mission of Project Gutenberg™

Project Gutenberg™ is synonymous with the free distribution of electronic works in formats readable by the widest variety of computers including obsolete, old, middle-aged and new computers. It exists because of the efforts of hundreds of volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the assistance they need are critical to reaching Project

Gutenberg™’s goals and ensuring that the Project Gutenberg™ collection will remain freely available for generations to come. In 2001, the Project Gutenberg Literary Archive Foundation was created to provide a secure and permanent future for Project Gutenberg™ and future generations. To learn more about the Project Gutenberg Literary Archive Foundation and how your efforts and donations can help, see Sections 3 and 4 and the Foundation information page at www.gutenberg.org.

Section 3. Information about the Project Gutenberg Literary Archive Foundation

The Project Gutenberg Literary Archive Foundation is a nonprofit 501(c)(3) educational corporation organized under the laws of the state of Mississippi and granted tax exempt status by the Internal Revenue Service. The Foundation’s EIN or federal tax identification number is 64-6221541. Contributions to the Project Gutenberg Literary Archive Foundation are tax deductible to the full extent permitted by U.S. federal laws and your state’s laws.

The Foundation’s business office is located at 809 North 1500 West, Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up to date contact information can be found at the Foundation’s website and official page at www.gutenberg.org/contact

Section 4. Information about Donations to the Project Gutenberg Literary Archive Foundation

Project Gutenberg™ depends upon and cannot survive without widespread public support and donations to carry out its mission of increasing the number of public domain and licensed works that can be freely distributed in machine-readable form

accessible by the widest array of equipment including outdated equipment. Many small donations ($1 to $5,000) are particularly important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws regulating charities and charitable donations in all 50 states of the United States. Compliance requirements are not uniform and it takes a considerable effort, much paperwork and many fees to meet and keep up with these requirements. We do not solicit donations in locations where we have not received written confirmation of compliance. To SEND DONATIONS or determine the status of compliance for any particular state visit www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states where we have not met the solicitation requirements, we know of no prohibition against accepting unsolicited donations from donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot make any statements concerning tax treatment of donations received from outside the United States. U.S. laws alone swamp our small staff.

Please check the Project Gutenberg web pages for current donation methods and addresses. Donations are accepted in a number of other ways including checks, online payments and credit card donations. To donate, please visit: www.gutenberg.org/donate.

Section 5. General Information About Project Gutenberg™ electronic works

Professor Michael S. Hart was the originator of the Project Gutenberg™ concept of a library of electronic works that could be freely shared with anyone. For forty years, he produced and

distributed Project Gutenberg™ eBooks with only a loose network of volunteer support.

Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition.

Most people start at our website which has the main PG search facility: www.gutenberg.org.

This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.

Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.