Download Full Version ebookmass - Visit ebookmass.

com

Building Modern Business Applications: Reactive

Cloud Architecture for Java, Spring, and
PostgreSQL 1st Edition Peter Royal

https://ebookmass.com/product/building-modern-business-
applications-reactive-cloud-architecture-for-java-spring-
and-postgresql-1st-edition-peter-royal-2/

OR CLICK HERE

DOWLOAD NOW

Discover More Ebook - Explore Now at ebookmass.com

 Instant digital products (PDF, ePub, MOBI) ready for you
Download now and discover formats that fit your needs...

Building Modern Business Applications: Reactive Cloud

Architecture for Java, Spring, and PostgreSQL 1st Edition
Peter Royal
https://ebookmass.com/product/building-modern-business-applications-
reactive-cloud-architecture-for-java-spring-and-postgresql-1st-
edition-peter-royal/
ebookmass.com

Beginning Spring Boot 3: Build Dynamic Cloud-Native Java

Applications and Microservices - Second Edition K. Siva
Prasad Reddy
https://ebookmass.com/product/beginning-spring-boot-3-build-dynamic-
cloud-native-java-applications-and-microservices-second-edition-k-
siva-prasad-reddy/
ebookmass.com

Beginning Cloud Native Development with MicroProfile,

Jakarta EE, and Kubernetes: Java DevOps for Building and
Deploying Microservices-based Applications 1st Edition
Tarun Telang
https://ebookmass.com/product/beginning-cloud-native-development-with-
microprofile-jakarta-ee-and-kubernetes-java-devops-for-building-and-
deploying-microservices-based-applications-1st-edition-tarun-telang/
ebookmass.com

The Kingdom of God Has No Borders: A Global History of

American Evangelicals Melani Mcalister

https://ebookmass.com/product/the-kingdom-of-god-has-no-borders-a-
global-history-of-american-evangelicals-melani-mcalister/

ebookmass.com
Handbuch Schlafmedizin Thomas Pollmächer

https://ebookmass.com/product/handbuch-schlafmedizin-thomas-
pollmacher/

ebookmass.com

Purchasing and supply chain management Seventh Edition

Arjan J. Weele

https://ebookmass.com/product/purchasing-and-supply-chain-management-
seventh-edition-arjan-j-weele/

ebookmass.com

Inside Vanguard 1st Edition Charles D. Ellis

https://ebookmass.com/product/inside-vanguard-1st-edition-charles-d-
ellis/

ebookmass.com

ChatGPT For Dummies Pamela Baker

https://ebookmass.com/product/chatgpt-for-dummies-pamela-baker/

ebookmass.com

A Very Grumpy Valentine's Day (Wolf Valley: A Very Grumpy

Holiday Book 1) Shaw Hart

https://ebookmass.com/product/a-very-grumpy-valentines-day-wolf-
valley-a-very-grumpy-holiday-book-1-shaw-hart/

ebookmass.com
African Entrepreneurship 1st ed. Edition Leo-Paul Dana

https://ebookmass.com/product/african-entrepreneurship-1st-ed-edition-
leo-paul-dana/

ebookmass.com
Peter Royal

Building Modern Business Applications

Reactive Cloud Architecture for Java, Spring, and
PostgreSQL
Peter Royal
Sherman Oaks, CA, USA

ISBN 978-1-4842-8991-4 e-ISBN 978-1-4842-8992-1

https://doi.org/10.1007/978-1-4842-8992-1

© Peter Royal 2023

This work is subject to copyright. All rights are solely and exclusively
licensed by the Publisher, whether the whole or part of the material is
concerned, specifically the rights of translation, reprinting, reuse of
illustrations, recitation, broadcasting, reproduction on microfilms or in
any other physical way, and transmission or information storage and
retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed.

The use of general descriptive names, registered names, trademarks,

service marks, etc. in this publication does not imply, even in the
absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general
use.

The publisher, the authors, and the editors are safe to assume that the
advice and information in this book are believed to be true and accurate
at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, expressed or implied, with respect to the
material contained herein or for any errors or omissions that may have
been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.

This Apress imprint is published by the registered company APress

Media, LLC, part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY
10004, U.S.A.
To Tricia, without whose support over the years I wouldn’t have arrived
at a place where this book could happen.
Introduction
One of the first jobs I had was at a consulting firm where we were
assisting a client in how to modernize their software. The client had a
successful business selling and supporting a domain-specific ERP
(Enterprise Resource Planning) system. It dated back to the 1970s with
code written in BASIC-2C targeting the Wang minicomputer. When I
entered the picture in the late 1990s the software was running on
Windows via an emulator, its text-based interface trapped in a window.
The owner of the firm did not want to get locked into a proprietary
platform again. In a very forward-thinking move, we were explicitly
asked to create a web-based user interface and a Java-based backend.
As we incrementally migrated modules from the old system to the
new one, we received user feedback around the usability of the new
interface. The text-based interface of the old system allowed power
users to quickly navigate around. The new graphical interface did not
initially have the same capabilities. We added extensive keyboard
shortcuts to make navigation easier, but the nature of the interface
prevented us from matching the experience of the old system. Existing
users valued the system as it was, while new customers were enticed by
the new web-based interface.
This was an enlightening experience for me, how deeply the nature
of my work affected the work of others, and how attached people can
be to the familiar. I was attached to the familiar. While the new system
we created used technologies and techniques that were more modern
than what the old system used, the paradigms were fundamentally the
same. In the two decades since I worked on that system, again the
technologies and techniques have changed, but the same paradigms live
on. As I made this observation and introspected the work I had done, I
came to realize that there are other ways to build systems. That’s what
this book is about.
I start this book by defining and scoping business applications, and
then my perspectives on the status quo. The next part discusses
architectural precepts that I believe are appropriate for forward-
looking systems and why business applications should be built with
them in mind. Business applications encode business rules, and
business rules can change over time. Understanding each of these is
important, and I dedicate a chapter to each. The third part of this book
is my proposal for a modern business application architecture. I
describe my self-imposed constraints and the principles that the
architecture aims to uphold. The architecture is described in detail, but
from a conceptual and data flow perspective. The architecture may be
implemented in your desired language. It has technological
requirements, but you can choose implementations you are the most
comfortable working with. There are production systems using this
architecture, and the final part is about the implementation choices I
made. The final chapter is about additions that can be made to the
architecture as well as alternate means of implementation. My goal is to
show that the architecture is really a starting point for systems, not the
end state. Your systems will have their own lives and need to grow in
ways that are unique to their environments.
You don’t need to know any specific computer languages to
understand this book. A familiarity with building systems is valuable,
but also not required. I describe the what, not the how, as I believe the
former will be more durable over time. As I learned early in my career,
implementation decisions change, but paradigms endure.
Thank you for taking the time to read this book. I hope that my
reasoning resonates with you. I would love to hear your stories of how
you have taken the ideas from this book and applied them to your work.
—Pete
Any source code or other supplementary material referenced by the
author in this book is available to readers on GitHub
(https://github.com/Apress). For more detailed information, please
visit http://www.apress.com/source-code.
Acknowledgments
The ideas in this book are an amalgamation of concepts I have
encountered over my career, many of whose attribution is lost to time. I
value everyone that takes the time to write and share knowledge with
others, knowing that they will never fully understand the reach that
they have.
To John Caruso and Gary Foster, for without your support and trust
early on in my career trajectory I would not have been here. To Paul
Hammant, for being a source of ideas, inspiration, and encouragement.
To all my friends from the Apache Software Foundation, especially the
early Avalon and Cocoon communities, for being unknowing mentors
and shaping how to think about problems. To Snehal Chenneru and
Michael Li, for without your help and support we never would have
built the system this book is about.
Practicing the art of Brazilian jiu-jitsu has shaped my perspectives
on continuous learning, humility, and problem solving. To my teachers,
Andre, Sandro, and Chris, your methods for sharing knowledge have
shaped mine.
This book would not exist if it were not for Jonathan Gennick
reaching out to me and asking me if I had ever thought about writing a
book. You had the vision that there was something worth sharing in a
more durable form than a conference talk. You and your team at Apress
helped bring this book to fruition.
Trish, Poppy, and Pickles, thank you for your support while I spent
nights and weekends writing. You are the best.
Table of Contents
Part I: Business Applications
Chapter 1:​What Is a Business Application?​
Business Software
Domain Specific
How It Is Used
Measuring Importance
“Modern”
Summary
Chapter 2:​The Status Quo (and How It Came to Be)
Business Application Architectures
The Status Quo
Green Screen
Rich Client
Web Applications
The Rise of Consumer Applications
Concurrent Practices
Agile
Test-Driven Development
Continuous Integration and Delivery
Observability
Summary
Part II: Design Prerequisites
Chapter 3:​What Is a Reactive System?​
What Is Reactive?​
Reactive Manifesto
 Responsive
Resilient
Elastic
Message Driven
Composing a Reactive System
Summary
Chapter 4:​Why Build Business Applications As Reactive Systems?​
Business Expectations
Developer Expectations
Property Alignment
Responsive
Resilient
Elastic
Message Driven
Summary
Chapter 5:​What Is a Business Rule?​
Thinking About Business Rules
Categorizations
Data at Rest
Side Effects
Derivable Data
Summary
Chapter 6:​Managing Time
Answering “What Happened?​”
Tracking Changes
Why Did That Happen?​
 Events
Commands
Understanding Time
Serialization of Time
Eventual Consistency
Bitemporality
Business Rule Changes
Summary
Part III: Design
Chapter 7:​Constraints and Principles
Constraints
From REST to a Graph
Falcor
GraphQL
Why GraphQL
Being Real-Time
Principles
Never Forget
Message Driven
Read/​Write Separation
Partial Availability
Design Flexibility
Modularity
Testability
Amenability to Change
Summary
Chapter 8:​High-Level Data Flow
Event Sourcing and CQRS
Thinking in GraphQL Schemas
Scalars and Enums
Objects
Lists
Input Objects
Interfaces and Unions
Queries and Subscriptions
Mutations
Combining GraphQL + ES + CQRS
Summary
Chapter 9:​Command Processor
What It Is, and Is Not
Requirements
Composing the Core Loop
Handling Failures
Infrastructure
Application
Enforcing Business Rules
How to Test
Testing the Command Processor
Testing Your Code
Summary
Chapter 10:​Command Generator
Interaction with GraphQL
 From Input Arguments into a Command
Appending to the Command Log
Returning the Mutation Result
Commands and Other Required Data
Handling Failures
Optimistic Locking
Timeouts
Testing the Command Generator
Command Submission
Command Creation
Summary
Chapter 11:​Event Materializer
Defining the View Model
Event Materializer Behavior
Transactions
Consistency
Multiple Sources
Evolving the View Model
Communicating Changes to Others
GraphQL Subscriptions
Other Side Effects
Managing Failure
Testing
Summary
Chapter 12:​Testing, Monitoring, and Observability
Key Components
 Command Processor
Command Generator
Event Materializer
Composed Data Flow
Testing the Composed System
Introducing Property-Based Testing
Using Property-Based Testing
Using Example Tests
Observability
Monitoring Production Systems
Practice Using Tools
Summary
Chapter 13:​Required Technologies
Design Review
Constraints and Principles Recap
GraphQL
Real-Time Updates
Never Forget
Message Driven
Read/​Write Separation
Partial Availability
Design Flexibility
Modularity
Testability
Amenability to Change
Required Technologies
 Append-Only Log
Pub/​Sub Messaging
Distributed Locking
Database
Summary
Part IV: Implementation
Chapter 14:​Building with Modern Spring, Java, and PostgreSQL
Required Technologies via PostgreSQL
Advisory Locks
LISTEN and NOTIFY
Schemas
Append-Only Log
Java and the JVM
GraphQL-Java
Spring Boot
Project Reactor
R2DBC
jqwik
Putting It All Together
Summary
Chapter 15:​Expansion Points and Beyond
Design Flexibility and Amenability to Change
Multiple Command Processors
Command Processor State Caching
Parallel Event Materialization
Command and Event Logs As GraphQL Subscriptions
 Using GraphQL for Inter-Process Communication
Federated GraphQL
Outsourcing Distributed System Problems
Bitemporal Materialized Views
Conclusion
Index
About the Author
Peter Royal
is a practicing software developer with
over 20 years of experience. A common
thread has been working on business
applications, whether they are tracking
legal casework, domain-specific ERP
suites, or financial trading and risk
management. He enjoys building tools
for his colleagues, working with them to
meet their needs, and providing
solutions that bring joy rather than
frustration. He has come to appreciate
pragmatic architectures and
development practices that enable
systems to thrive for the long term. He
currently resides in Los Angeles, CA, with his wife, daughter, and cat.
About the Technical Reviewer
Alexandru Jecan
is a software engineer and author. He is working at Deutsche Bank as
Assistant Vice President in the area of investment banking. Alexandru
also speaks at programming conferences across Europe and the United
States.
Alexandru is the author of the book Java 9 Modularity Revealed
(Apress) and the technical reviewer of the books Java Program Design
(Apress) and Jakarta EE Recipes (Apress).
His book Java 9 Modularity Revealed was featured during the
keynote speech by Mark Reinhold at the JavaOne Conference 2018 in
San Francisco.
Alexandru lives with his wife Diana and his daughters Melissa and
Mia in Berlin and is currently studying for the Project Management
Certification.
You can reach Alexandru at alexandrujecan@gmail.com.
Part I
Business Applications
© The Author(s), under exclusive license to APress Media, LLC, part of Springer
Nature 2023
P. Royal, Building Modern Business Applications
https://doi.org/10.1007/978-1-4842-8992-1_1

1. What Is a Business Application?

Peter Royal1
(1) Sherman Oaks, CA, USA

“Modern Business Application” is a vague and imprecise term,

conjuring up differing mental images for each individual. Before we
embark upon our journey of building one, I need to ensure that you
have an understanding of what I mean.
In this chapter I will introduce what a “Modern Business
Application” is, for the purposes of this book. The progression of the
book follows with the desired properties for business applications, how
those properties can be manifested into the design of a system, and
finishing with a discussion on implementation.
I feel a critical aspect in developing successful business software is
understanding the business. The corollary for this book is
understanding what a business application is, in order to understand
what we will be building.

Business Software
In 2001, Watts S. Humphrey started off his book entitled Winning with
Software: An Executive Strategy1 with a chapter on “Why Every
Business Is a Software Business.” Ten years later, in 2011, Marc
Andreessen wrote a piece2 for The Wall Street Journal entitled “Why
Software Is Eating the World.” Fast-forward to 2019, and Microsoft’s
CEO Satya Nadella reaffirmed3 Watts’ declaration with “Every Company
Is Now a Software Company” during a discussion at the Mobile World
Congress.
The increasing reliance that businesses place on software had been
anticipated and has come to pass. Nearly all businesses rely on some
form of “Commercial Off The Shelf ” (COTS) software, even as the
“shelf” is now commonly an “… as a service” offering.
Each business is unique, and their software needs reflect that.
However, “software” is a broad term. This book is about a specific type
of software, “applications.” An “application” (or “app”) is software for
end users, whether they are a business’s employees or customers.
While all businesses benefit from software that is customized for how
they operate, the incremental value to the business relative to what’s
available as COTS generally results in developers such as you and I
working for larger organizations.
Let’s break down the attributes that will comprise our definition of
“Business Application.”

Domain Specific
A business can be said to operate within a given industry. Industries are
very broad domains , such as finance, manufacturing, entertainment,
etc. At a certain size, they generally partition themselves into internal
functional areas, or departments, such as sales, marketing, accounting,
etc. While there are commonalities in a given department across all
industries, the combination of industry and department yields many
unique values, as no two businesses conduct themselves in an identical
fashion. In fact, the way a business internally organizes itself can be an
important differentiator. Having an internal organization that’s
different from its peers can be a competitive advantage.
This is our area of focus, applications that are tailored toward
specific departments. Some departments, such as accounting, have
enough similarity across domains to support third-party vendors.
Often, such software will have the ability to be customized to adapt it to
the unique specifics of a business. However, this comes with risks, as a
critical component of a department’s operation is now in the hands of a
third party. This relationship has been recognized by financiers, some
of whom acquire these vendors and slow improvements in the software
in order to collect lucrative support fees, as without the software the
business would falter.
A mitigation to that risk is for a business to hire or contract
software developers such as yourself to create these applications.
Having full control of the application allows the business to control its
future . This is the basis for “every company being a software company.”
What once may have been a competitive advantage has now morphed
into table stakes.

How It Is Used
Within this departmental domain , our business applications are ones
that act as a source of truth for the department. The application is both
the “system of record,” in addition to the “system of engagement.” It is
the system that users interact with for data entry, as well as being the
authoritative store for that data. In very large corporations, there may
be a single corporate-wide system (an Enterprise Resource Planning
system,4 or ERP) that is the system of record, delegating the system of
engagement to other systems. Those systems are far larger than the
ones we are focusing on.
The most straightforward way to capture data into a system of
record is to make it a job requirement for employees to use the system.
Or, in the case of a customer-facing system , being the only way to
interact with the business. It is important to have empathy for the users
of these systems. As software developers, if there are annoyances with
the tools we use daily, in many cases we can modify our tools to remove
what’s frustrating. For users of business applications where usage of it
is a condition of performing their job, they do not have that luxury. The
responsibility to ensure that using an application is, as a minimum,
pleasant, falls to us. With information captured into an application, the
business is then able to use the data in pursuit of its goals.
Data is not captured in a vacuum. Without structure, data can be
worse than meaningless, creating additional confusion. Based on the
business's current objectives, a structure for data can be devised, a
model. The rigidity of this model can have a direct impact on the
business’s ability to adapt to changes in the future. If a change in the
business requires a change in this model, the application that houses
this model must then be updated for the business itself to change.
Writing software in a manner that is amenable to change is valuable
and can be under-appreciated. There is a balancing act between doing
exactly what is required vs. generalizing based on what could change in
the future. However, there are techniques that, to a degree, can side-
step this balancing act by taking a different path entirely. We will
discuss this more in Chapter 4.
Business applications enforce processes and workflows. These
workflows describe the activities that must be taken based on data in
the system, without prescribing who performs them. By formalizing
them into an application, adherence to them is increased or guaranteed.
We are focusing on applications that allow users to collaborate on
workflows. Our business applications are multiuser systems.
Collectively, requirements on the structure of data and the
processes by which the data is modified are known as business rules.
We will explore business rules in depth in Chapter 5.

Measuring Importance
As engineers, our view of an application’s importance is often based on
how it is used. An application that is frequently used and/or manages
large amounts of data is important. These two dimensions are conflated
when referring to the “scale” of an application. The larger the scale, the
larger the importance. That may not be the business’s perspective,
however. Instead, it is the criticality of the application to the continued
operation and success of the business’s operations.
For purposes of this book, our data volume sweet spot is what I like
to refer to as “medium-sized data” (as a play on the “big data”
nomenclature that swept over tech in the early part of this century).
Medium-sized data fits in the storage capacity of a single server,
although multiple servers may be used for resiliency. The data may also
fit entirely in memory, something that is increasingly true as system
capacities increase, and the changing nature of storage systems. Think
gigabytes, not terabytes.
As our business applications are targeted at end users, its access
frequency will be at human-scale speeds. The number of users will be
the driving factor in the overall number of requests, which will likely be
measured in requests per minute rather than second. This has
implications on how we observe the behavior of our systems; the
sparser the requests, the trickier it becomes to use metrics to monitor
its behavior. Is the system unavailable, or is it a quiet period for users?
This is explored in Chapter 12.
An application that is important to the business must be available
for use when the business requires it. There will likely be periods of
time for the business in which the unavailability of the application
would be disastrous. An application’s sole purpose could be to assist
users during these critical periods, as the formalization of the business
processes performed with the application helps ensure they are
performed as intended.

“Modern”
Modern is an adjective that will ultimately date whatever uses it. In
using this label, we are certainly declaring that our techniques are more
up to date than others. Computing capabilities have grown by leaps and
bounds in the past two decades. It isn’t that older techniques become
invalid. Rather, increased compute and storage capacity have made new
techniques viable. Techniques that may have only lived on a whiteboard
are now able to be put into production use.
This is our modern, more akin to modern tools than modern art. In
time, with your help, they will become the new status quo. There will
certainly be techniques in the future that beget reuse of the modern
label again, but such is the cycle of progress.
The techniques I describe and advocate for in this book are not
novel. I am making the case that not only is it entirely feasible to use
them but doing will lead to software applications that are better suited
for the current moment and into the future.
“Cloud Computing ” is an intriguing trend that both abstracts
developers from the physical machine and can demand increased
mechanical sympathy with the machine as a mechanism for controlling
costs. It is easier than ever to provision compute resources, and
inattention to the resources in use can invert the value proposition for a
business.
 I discuss this in concrete terms in Chapter 4. The techniques I will
describe open up the possibility of managing consumed resources in
closer concert with what is required at the time, even if it isn’t acted
upon. Similar to how I explain how to make an application’s logic
amenable to change, the same principle is extended to the resources
required for operation.

Summary
The business applications this book referred to can be described thusly:
Tailored to a specific domain
Bespoke work, either performed by employee-developers or
consultants
Usage by employees is mandatory
Multiuser
Data entry and decision support are core functions
A source of truth for the business
Value is derived from workflow and decision analysis automation
Medium-sized data
Criticality is due to importance to the business
Modern is in relation to current development practices, which I
discuss in the next chapter.

Footnotes
1 https://www.informit.com/store/winning-with-software-an-
executive-strategy-9780201776393

2 https://a16z.com/2011/08/20/why-software-is-eating-the-
world/

3 https://www.satellitetoday.com/innovation/2019/02/26/micros
oft-ceo-every-company-is-now-a-software-company/
4 An ERP is a system that facilitates organizational-wide management of processes
and data. They are frequently composed of modules that relate to facets of the
business such as inventory management, purchase orders, and accounting. They are
highly customizable to the needs of the business.
© The Author(s), under exclusive license to APress Media, LLC, part of Springer
Nature 2023
P. Royal, Building Modern Business Applications
https://doi.org/10.1007/978-1-4842-8992-1_2

2. The Status Quo (and How It Came to

Be)
Peter Royal1
(1) Sherman Oaks, CA, USA

Now that we have established a definition of a business application, I’m

going to discuss my perspective on the status quo and how it has come
to be. It is based off of my observations of the industry over the past
two decades, from the mid-1990s to the present day in 2021.
In this chapter I will describe the practices that I’ve observed in my
career, and how I feel they may be improved. This will be a Java Virtual
Machine (JVM) centric view, as that’s where I’ve spent the majority of
my career. That may be true for you, or could be, depending on where
you are in your career arc. Let’s dive in!

Business Application Architectures

While business application architectures have changed in the past 20
years, they have also largely remained the same. As developers, our
systems repeat the same fundamental interaction patterns, albeit
implemented with the technologies of the day. It is important to
understand the past in order to understand the opportunities ahead.

The Status Quo

A “modern” business application likely presents itself as a web-based
user interface. If it is recent enough it may be a single-page application,
one where data is loaded in the background, and the page itself is
dynamically rewritten. This is usually only window dressing. If you look
closer, the page is probably firing off HTTP requests to a backend,
passing JSON payloads back and forth. HTTP verbs will be used to
coarsely describe the intended action, GET for retrieval, DELETE for
removal, PUT to create, and POST to update. Perhaps there is some
thought to the URL schema, such as a version number, but probably not.
It’ll be a flat namespace of endpoints, like a bunch of functions in an
unorganized namespace.
If you ask the developers what type of API they’ve created, they’ll
call it a “REST API,” even though it’s far from it. Slinging underspecified
JSON back and forth with HTTP verbs isn’t exactly what Roy Fielding
described when he coined the term. I like to describe these APIs as
“colloquial REST.”
There are many frameworks, such as Rails, Django, and Spring, that
assist with the mechanics of exposing the HTTP request to developers,
such that a developer only needs to specify the URL, HTTP method, and
the shape of the payload.
Once received, the request will undergo the appropriate validations
and then an object-relational mapping (ORM) framework will be used
to ultimately store or retrieve data from a relational database. The ORM
framework is probably Hibernate, as it has garnered the lion’s share of
attention since its debut in 2001.
Relational databases are the workhorses of business applications,
and for good reasons. The quality of software layers that exist between
the database and the user means nothing if the database isn’t capable of
reliably storing and retrieving data. Relational databases have a well-
specified and standardized mechanism for interacting with them, the
Structured Query Language, SQL . As difficult as it may be to introduce
any new technology into a business, it is even more difficult to
introduce a new primary data storage system. As our business
applications are important to the business, this leads to risk aversion
around the choice of data store. This is why the choice of data store is
not something I’m proposing innovating upon. I’ve been using
PostgreSQL for a large part of my career, and it has always worked, and
continues to be improved. It is why I’m advocating for using PostgreSQL
as part of this book. If you have a different preferred database, continue
to use that. You have hard-won operational knowledge that is worth
retaining.
The schema used in the database is probably mostly reasonable,
depending on the nature of the changes the business has asked upon
the software over its lifetime, as well as the number of developers that
have worked on it. One thing that is very likely to be true is that the
application mutates data in place. As data changes, what it used to be is
gone. Sometimes, there’s an explicit business requirement for an
“undelete” operation or tracking changes to specific fields. As this
requires extra development work, it is usually omitted unless explicitly
called out.
As a pithy summary, a “modern” business backend in Java is
underspecified JSON exchanged via a colloquial REST API that mutates
data in place in a relational database via Hibernate.

Green Screen
The first business applications I was exposed to were “green screen”
applications. The term was a throwback to terminals that were
connected to a central computer with multiple displays and keyboards
(terminals), rather than networking computers. The terminals were
often green CRT screens (thus the name) and had limited functionality.
They could display text from the central computer, relay input back, and
perhaps printing functionality. If you’ve configured a terminal in Linux,
you may have seen references to these devices in potential values for
the TERM environment variable such as vt100.
As personal computers became common, hardware terminal
emulators were replaced by software terminal emulators running
under Windows, the common desktop operating system at the time.
This is where I was exposed to them, applications that the business
depended upon that were more important than the lifecycle of the
hardware that they were originally developed for. Hardware terminals
had been replaced with desktop software, and central computers with a
local area network.
Some of these systems are still in active use. They are written in
languages that are now considered legacy, such as COBOL or RPG .
Rewriting these systems in another language is a large effort and
introduces risk to the business. Being an economic decision, the
business risk due to errors in a migrated system is mitigated by
continuing to use the old system and managing the risk of staffing the
teams that maintain them. If you squint your eyes hard enough, you can
view the manner in which these systems render output in a terminal as
a baroque text-based protocol. There are products that take this
approach and allow the creation of web-based user interfaces for them.
I am mentioning these applications as they are true “thin client”
architectures. The client devices, terminals , could do little more than
input and output. There were no facilities to run logic “client side” on
terminals.

Rich Client
Popularized by Microsoft Access and Visual Basic (VB) , a Rich Client is
an application that is installed on a user’s machine and connects to a
central application over a local area network. In many situations, the
central application was a relational database. Local area networks
hadn’t yet standardized on TCP/IP, and creating custom protocols
wasn’t a straightforward task. A sufficiently complex system may have
used CORBA, a technology for performing method calls across
languages and machines. The simplest way to create a multiuser
application was to rely on a database server’s wire protocol and use it
as the server portion of an application.
Access and VB provided a visual experience for building user
interfaces. This allowed those with little traditional programming
experience to build simple applications to store and retrieve data.
Microsoft provided a robust set of built-in UI widgets along with third-
party vendors that sold widgets with additional functionality. Building
multiuser business applications was straightforward, and the results
behaved similarly to other desktop software. Being a discrete
application on a user’s machine also meant being able to directly
interact with other tools, such as Excel or Word.
However, there was a big catch for developers, distributing their
software. Applications weren’t a single file to install. Shared libraries
needed to be copied to particular locations on machines. If there were
conflicts, the results could be extremely difficult to debug. The term
“DLL hell” was coined to refer to this pain.
 Rich clients offered users an excellent experience. This came at the
cost of operational difficulties. The best user experience is worth
nothing if the software won’t run on your machine.
The Model-View-Controller (MVC) architectural pattern was an
insight on how to segregate responsibilities in graphical user interfaces.
Access and VB didn’t offer strict adherence to this pattern. The
relational database could be considered the model, and each display
window (a form in their parlance) was similar to a combined view and
controller.

Web Applications
Concurrent with rich clients, the web was invented. As the 1990s came
to a close, TCP/IP became the de-facto protocol for local area networks,
as it solved LAN communication in addition to internet access. This
opened the possibility of running a web server on the LAN with users
accessing an “intranet.”
While the initial user experience was poor in comparison to rich
clients , it simplified the lives of developers as there was no software to
install on users’ machines. Solving the operational pains of DLL hell was
of value to IT departments.
The first web applications were page-based, harkening back to the
document-centric view that the web started with. There were two
developments that I feel led to the floodgates of web applications.
The first was a pause in revisions of the HTML specification.
Through the 1990s the W3C released HTML 2, 3, and eventually 4.
HTML 4 was initially released in last 1997, with a final revision as 4.01
in late 1999. It was almost nine years until the process for HTML 5
began.
While this was a stagnation in the specification, it was also a period
of stability. I believe this stability provided a stable foundation to build
applications upon.
The second important development was what is now known as
XMLHTTPRequest , or XHR. This was a technique for communicating
with the web server without a full page reload, allowing web
applications to have interaction paradigms that began to mimic rich
clients . A proprietary feature of Microsoft’s Internet Explorer browser
allowed JavaScript running in the browser to access components
installed on the system through a technology known as ActiveX . This
was a descendant of the same technology, COM, that Visual Basic used
for its interface building. It was through this path that a component
Microsoft had developed as part of their Outlook Web Access (allowing
web-based access to a corporate email server) could be used on any
page. Once this technique was discovered, it became a de-facto
standard and was implemented in other browser engines.
With a stable specification and the ability to communicate with a
server in the background, it was possible to build business applications
that were “good enough” for daily use. Some business applications
would continue to demand rich clients , as their requirements could not
be met by a web-based application. However, if a web browser’s
capabilities were sufficient for an application, the operational ease of a
web application made it the simpler long-term choice.
Frameworks that assisted developers in writing the application
servers that backed these web-based applications converged upon the
MVC pattern for structuring themselves. The model is no longer the
database itself; it is an object model in the application server that’s
mapped to the database with an ORM . Code is organized into classes
named controllers, with their response payloads being views. This was
the genesis of the status quo that remains.
It is here that I believe web-based business applications have
stagnated. While there have been continuing developments in the web
that I discuss in the next section, by and large, the requirements of
many business applications have been satisfied. The way in which the
browser-side portion of an application is developed has changed, but
the underlying browser primitives they use have not.

The Rise of Consumer Applications

Through the 2000s, if you wanted to use a website, you had to use a
web browser on a desktop (or laptop) computer. This was the decade
where broadband Internet access at home increased rapidly. Along with
it was the “Web 2.0” movement that ushered in increased interactivity
on websites, something that was made possible by the availability of
XHR in browsers. Websites aimed at users flourished, and their
activities online expanded beyond the transactional interactions that
were similar to business applications.
 In 2007, a shockwave rippled through the technology industry
when Apple released the first iPhone. It allowed one to browse the web
on a handheld device with pages rendering the same as they would on a
desktop. Apple’s initial plans were to have all user-installable
applications be websites, but they backed away from that and allowed
developers to write native applications delivered via the App Store. A
new name for applications arrived, “apps.” Google’s Android mobile
operating system quickly matched what Apple had done with an app
store of their own.
This complicated the lives of UI developers targeting consumers.
Previously, they had to deliver a website that was functional on the
major desktop browser engines. Assumptions could be made around
the available input devices (keyboard and mouse), approximate screen
sizes, pixel density, and even the nature of their connection to the
internet (stable latencies and packet loss, even though bandwidth
varied due to broadband availability). With this mobile explosion, there
were a myriad of screen sizes, the mouse replaced with touch
interactions, a network with variable latency, and packet loss. There
was, at least, a common browser engine, Apple’s WebKit . One
deliverable, a desktop website , had morphed into four: a desktop
website, a mobile website , an iOS app, and an Android app. To help
limit the number of targets, some native mobile applications embedded
browser views to provide some of their functionality.
To allow mobile websites to have app-like capabilities, browser
innovation began again with the addition of new features. Web workers
allowed background execution, SSE for data pushed from the server,
and WebSockets for a persistent bidirectional connection.
There was a Cambrian Explosion in the JavaScript ecosystem of
frameworks making use of these new APIs, and overall streamlining of
the development experience. A new pattern for delivering data
emerged, GraphQL.
GraphQL provides a mechanism for an API caller to specify exactly
what data they wish to have returned. This was a valuable feature when
delivering data over a mobile network. It is a different paradigm from
the MVC-style APIs that came before. To help bridge between older web
APIs and the APIs desired by mobile clients, the Backend for the
Frontend (BFF) pattern emerged. This is a service that acts as an
adapter between existing APIs and the desired experience of the client.
Innovations in a user’s experience (UX) also took place. Mobile
device adoption accelerated after the iPhone and Android releases, and
an app’s ease-of-use became a valuable differentiator in the
marketplace. New paradigms were invented in apps and percolated
through the ecosystem (pull-to-refresh, not needing to refresh,
notifications, infinite scrolling, and social collaboration, to name a few).
Previously, the difference between a business application delivered
via the web and a consumer website was largely one of scale and
audience. With the advent of mobile, consumer websites weren’t mere
websites, they also had to deliver an app experience. The set of skills
needed to work on consumer experiences had expanded.
Thus, my assertion on the status quo. Prior to this mobile explosion,
business applications and consumer websites could largely be built in a
similar fashion. Why haven’t business applications kept pace? I have
some theories.
First, for new business applications , features that are common in
apps are now taken for granted, and thus not explicitly called out by
product managers when writing requirements, the same way that
business-specific features are. The refresh/reload button is my favorite
example here. Websites that automatically update their data have been
possible since the invention of XHR . As a UX paradigm, it wasn’t until
the mobile explosion that it became common. If the refresh button were
used, the browser may re-request assets that haven’t changed in
addition to the data that has. To streamline the experience, refresh
moved into the app, and eventually disappeared. Instead, the content is
kept up-to-date automatically. If a feature is invisible and omni-present,
it becomes easier to miss when explicitly enumerating requirements.
Second, a lack of developer experience. As the set of skills needed to
work on consumer experiences expanded, it creates a bifurcation in
skillsets. One may have needed exposure to systems that utilized new
browser capabilities to suggest their incorporation.
Finally, architectural impedance. It may not be straightforward to
“bolt on” a change stream in order to have live updating pages or
trigger notifications for a user. This gets to the heart of the remainder of
this book. I’ll be introducing a different way of building systems in the
third part of this book that solves this impedance and will hopefully set
a standard for the next phase of computing. The MVC pattern has
served us well, but there is another step forward we can take. As we
prepare to do so, there are other practices that are valuable to
incorporate into our work.

Concurrent Practices
The practices involved in delivering software have also been evolving. A
software architecture is more than how the pieces fit together, it’s also
how the pieces come together, how they are changed over time, how
they are validated, and how their production performance is evaluated.
In this section, I go over some practices that I believe are valuable for
the long-term success of an application.

Agile
When the agile manifesto1 was unveiled in 2001, it was a large shift in
the way in which delivering software was thought about on a wide scale
. I remember first reading it and it was as if a lightbulb had gone off in
my head. It succinctly describes some of the pressures that software
teams face and offers an extremely loose framework for thinking about
them.
The act of constructing software isn’t bound by the same physical
constraints as constructing physical objects. I believe it is important to
lean into that differentiation and use it to create better software.
Software is, ultimately, an arrangement of bits. We have constructed
fantastical systems to ease the process of arranging them just-so.
The point from the manifesto that stuck out to me the most was
being amenable to change. To change software is to spend time doing
so; there are no materials lost in the process. I have a strong belief that
a key principle in building a system is that it needs to be amenable to
change, and that will be reflected in what we build in the remainder of
this book.
The manifesto also speaks to the processes around making changes.
As mentioned in the first chapter, our business applications are a
bespoke creation for the business. It is important for developers to
view themselves as collaborators with the business, not contractors
(even if the actual relationship is via a consultancy).
The goal of a business application is to help the business, and the
agile manifesto describes how to approach those interactions.

Test-Driven Development
Test-driven development, or TDD , emerged from the agile practice of
eXtreme Programming, or XP. Ken Beck “rediscovered2” the technique
in the 1990s and wrote about it in his 1999 book Extreme Programming
Explained. 3
The crux of the idea is to write tests for functionality prior to
implementing the functionality itself. At first, the test should run and
fail, as the functionality hasn’t been implemented. From then on, the
goal is to make the test pass.
I’ve found this practice to be immensely valuable, as it puts me in
the position of being a consumer of my code prior to writing it. The act
of writing the test helps focus on what’s important from an API
perspective, and how the code should communicate with the rest of the
codebase. I feel it helps create code that is easier to maintain as well.
The act of writing a test before implementation somehow leads to a
more thoughtful design. That design is more amenable to future
change. I’m certain the fact that the code has tests helps maintainability,
as changes can be made with confidence. However, I’ve found that there
is a difference between code that had tests written prior to
implementation and tests after. Empirically, I’ve seen it work and have
become a believer in the practice . Tests need to be written regardless
to validate that code works, so why not write them first?

Continuous Integration and Delivery

Continuous Integration and Continuous Delivery, CI/CD , are two more
XP practices. They are distinct yet interrelated. When combined, they
formalize the delivery pipeline for software. CI has become a standard
practice. If your project utilizes a build server that compiles your
project and runs tests after code pushes, you are practicing CI. To move
into CD, the build server should also package the software up for
deployment, perhaps even automating the deployment itself.
 When practiced together, CI/CD allows you to push a change to your
repository, and without any additional manual intervention have it
running in your test environment. This can also be extended to promote
builds into production automatically, although most business
environments that I’ve worked in have preferred to have a human in the
loop for that part, even if it is the simple act of clicking a button.
I find value in these practices as they complete the feedback loop.
The test environment that exists on a build server is not the same as a
deployed environment. This “pipeline” approach for delivering the
software itself will be echoed in how we will be structuring the
internals of our modern business application . There is also an element
of a philosophical thought experiment here, akin to “If a tree falls in a
forest and no one is around to hear it, does it make a sound?” – “If the
software was changed but it was never deployed, was it ever really
changed?”. One refrain I will keep coming back to is that an application
should be amenable to change. Easily getting those changes into the
hands of users is crucial to this goal.

Observability
Observability is a trendy word. It comes from control theory, a measure
of how well the internal states of a system can be inferred from its
external outputs. In the late 2010s, it started to be applied to what
could be generally coined the “monitoring” space.
As software developers, we’ve always been practicing this. We use
the outputs of a system, such as log messages, to build an
understanding of what is taking place inside. In the simplest sense,
“practicing observability” means ensuring that your systems are
emitting enough information that you can reconstruct what they are
doing. This has always been a best practice, but I found
implementations to be ad-hoc and on a case-by-case basis.
Formalizing this practice has increased in importance as our
applications are increasingly not acting alone. They are a part of a
larger ecosystem of applications that power a business. There is value
in having applications emit these outputs in a common fashion, so
problems can be debugged across applications.
The value I’ve found in this practice has been changing my mindset
on how to approach debugging problems. Ideally, I do not want to have
to use a debugger, nor add print statements to figure out the cause of a
problem. I’ve tried to make it a goal to build systems such that they
naturally emit enough information to mentally work through what the
possible causes are, and then use a test to validate the hypothesis. It is
another practice that will seep into how your software is structured,
and how we will be structuring our modern business applications.

Summary
The manner in which business applications are architected hasn’t
substantially changed. The business and consumer applications were
similar until the introduction of the iPhone, which begat many changes
in consumer apps that haven’t had wide adoption in business
applications. Other development practices may have been incorporated
into your workflow, as they are somewhat orthogonal to an
application’s architecture.
I feel there’s an opportunity to fully incorporate technologies from
consumer apps and practices from agile into a modern business
application design.
In the next part of this book, I will further describe the desired
properties and features of our design prior to the design itself in the
third part.

Footnotes
1 https://agilemanifesto.org/

2 https://www.quora.com/Why-does-Kent-Beck-refer-to-the-
rediscovery-of-test-driven-development-Whats-the-history-of-
test-driven-development-before-Kent-Becks-rediscovery

3 ISBN13 978-0321278654
Part II
Design Prerequisites
Random documents with unrelated
content Scribd suggests to you:
The Project Gutenberg eBook of Peter Whiffle
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.

Title: Peter Whiffle

His life and works

Author: Carl Van Vechten

Release date: May 5, 2024 [eBook #73546]

Language: English

Original publication: United States: Alfred A. Knopf, 1922

Credits: Tim Lindell, Graeme Mackreth and the Online Distributed

Proofreading Team at https://www.pgdp.net (This file was
produced from images generously made available by The
Internet Archive)

*** START OF THE PROJECT GUTENBERG EBOOK PETER

WHIFFLE ***
Peter Whiffle
His Life and Works
BOOKS BY CARL VAN VECHTEN
INTERPRETERS
IN THE GARRET
THE MERRY-GO-ROUND
THE MUSIC OF SPAIN
THE TIGER IN THE HOUSE
MUSIC AND BAD MANNERS
LORDS OF THE HOUSETOPS
MUSIC AFTER THE GREAT WAR
PETER WHIFFLE: HIS LIFE AND WORKS
 Peter Whiffle

His Life and Works

Carl Van Vechten

New York Alfred · A · Knopf

MCMXXIII
 COPYRIGHT, 1922, BY

ALFRED A. KNOPF, Inc.

Published, April, 1922

Second Printing, April, 1922

Third Printing, May, 1922

Fourth Printing, June, 1922

Fifth Printing, July, 1922

Sixth Printing, August, 1922

Seventh Printing, October, 1922

Eighth Printing, March, 1923

Ninth Printing, July, 1923

Set up, electrotyped, printed and bound by the Vail-Ballou Co., Binghamton, N.Y.
Paper furnished by W.F. Etherington & Co., New York.

MANUFACTURED IN THE UNITED STATES OF AMERICA

 TO THE MEMORY OF

MY MOTHER,

ADA AMANDA FITCH VAN VECHTEN

 "'Tingling is the test,' said Babbalanja, 'Yoomy,
did you tingle, when that song was
composing?'
"'All over, Babbalanja.'"
Herman Melville: Mardi.
"We work in the dark—we do what we can—
we give what we have. Our doubt is our
passion, and our passion is our task. The rest
is the madness of art."
Dencombe: The Middle Years.
"Les existences les plus belles sont peut-être
celles qui ont subi tous les extrêmes, qui ont
traversé toutes les températures, rencontré
toutes les sensations excessives et tous les
sentiments contradictoires."
Remy de Gourmont: Le Chat de Misère.
"The man who satisfies a ceaseless
intellectual curiosity probably squeezes more
out of life in the long run than any one else."
Edmund Gosse: Books on the Table.
"O mother of the hills, forgive our towers;
O mother of the clouds, forgive our
dreams."
Edwin Ellis.
 Preface
So few people were acquainted with Peter Whiffle that the
announcement, on that page of the New York Times consecrated to
wedding, birth, and obituary notices, of his death in New York on
December 15, 1919, awakened no comment. Those of my friends
who knew something of the relationship between Peter and myself,
probably did not see the slender paragraph at all. At any rate none of
them mentioned it, save, of course, Edith Dale, whose interest, in a
sense, was as special as my own. Her loss was not so personal,
however, nor her grief so deep. It was strange and curious to
remember that however infrequently we had met, and the chronicle
which follows will give evidence of the comparative infrequency of
these meetings, yet some indestructible bond, a firm determining
girdle of intimate understanding, over which Time and Space had no
power, held us together. I had become to Peter something of a
necessity, in that through me he found the proper outlet for his
artistic explosions. I was present, indeed, at the bombing of more
than one discarded theory. It was under the spell of such apparently
trivial and external matters that our friendship developed and, while
my own interests often flew in other directions, Peter certainly
occupied as important a place in my heart as I did in his, probably, in
some respects, more important. Nevertheless, when I received a
notification from his lawyer that I had been mentioned in Peter's will,
I was considerably astonished. My astonishment increased when I
was informed of the nature of the bequest. Peter Whiffle had
appointed me to serve as his literary executor.
Now Peter Whiffle was not, in any accepted sense of the epithet, an
author. He had never published a book; he had never, indeed,
written a book. In the end he had come to hold a somewhat mystic
theory in regard to such matters, which he had only explained to me
a few moments before he died. I was, however, aware, more aware
than any one else could possibly have been, that from time to time
he had been accustomed to take notes. I was as familiar, I suppose,
as any one could be, with the trend of his later ideas, and with some
of the major incidents in his earlier life he had acquainted me,
although, here, I must confess, there were lacunæ in my knowledge.
Still, his testamentary request, unless I might choose to accept it in a
sense, I am convinced, entirely too flattering to my slender talents,
seemed to be inconsistent with the speculative idea which haunted
him, at least towards the end of his life. This contradiction and an
enlarging sense of the mysterious character of the assignment were
somewhat dispelled by a letter, dated June 17, 1917, which, a few
days after the reading of the will, his lawyer placed in my hands and
which indicated plainly enough that Peter had decided upon my
appointment at least two years and a half before he died. This letter
not only confirmed the strange clause in the will but also, to some
extent, explained it and, as the letter is an essential part of my
narrative, I offer it in evidence at once.
Dear Carl—so it read:
I suppose that some day I shall die; people do die. If there has been
one set purpose in my life, it has been not to have a purpose. That,
you alone, perhaps, understand. You know how I have always
hesitated to express myself definitely, you know how I have refrained
from writing, and you also know, perhaps, that I can write; indeed,
until recently, you thought I was writing, or would write. But I think
you realize now what writing has come to mean to me, definition,
constant definition, although it is as apparent as anything can be that
life, nature, art, whatever one writes about, are fluid and mutable
things, perpetually undergoing change and, even when they assume
some semblance of permanence, always presenting two or more
faces. There are those who are not appalled by these conditions,
those who confront them with bravery and even with impertinence.
You have been courageous. You have published several books
which I have read with varying shades of pleasure, and you have not
hesitated to define, or at any rate discuss, even that intangible,
invisible, and noisy art called Music.
I have begun many things but nothing have I ever completed. It has
always seemed unnecessary or impossible, although at times I have
tried to carry a piece of work through. On these occasions a
restraining angel has held me firmly back. It might be better if what I
have written, what I have said, were permitted to pass into oblivion
with me, to become a part of scoriac chaos. It may not mean
anything in particular; if it means too much, to that extent I have
failed.
Thinking, however, of death, as I sometimes do, I have wondered if,
after all, behind the vapoury curtain of my fluctuating purpose,
behind the orphic wall of my indecision, there did not lurk some
vague shadow of intention. Not on my part, perhaps, but on the part
of that being, or that condition, which is reported to be interested in
such matters. This doubt, I confess, I owe to you. Sometimes, in
those extraordinary moments between sleeping and awakening—
and once in the dentist's chair, after I had taken gas—the knots
seemed to unravel, the problem seemed as naked as Istar at the
seventh gate. But these moments are difficult, or impossible, to
recapture. To recapture them I should have been compelled to invent
a new style, a style as capricious and vibratory as the moments
themselves. In this, however, as you know, I have failed, while you
have succeeded. It is to your success, modest as it may appear to
you, that I turn in my dilemma. To come to the point, cannot you
explain, make out some kind of case for me, put me on my feet (or in
a book), and thereby prove or disprove something? Shameless as I
am, it would be inconceivable, absurd, for me to ask you to do this
while I am yet living and I have, therefore, put my request into a
formal clause in my will. After I am dead, you may search your
memory, which I know to be very good, for such examples of our
conversations as will best be fitted to illuminate your subject, which I
must insist—you, yourself, will understand this, too, sooner or later—
is not me at all.
When your book is published, I shall be dead and perhaps
unconscious. If, however, as I strongly suspect, some current
connects the life to be with the life that is, I can enjoy what you have
done. At the best, you may give others a slight intimation of the
meaning of inspiration or furnish guideposts, lighthouses, and bell-
buoys to the poet who intends to march singing along the highroad
or bravely to embark on the ships at sea; at the worst, I have
furnished you with a subject for another book, and I am well aware
that subjects even for bad books are difficult to light upon.
Salve atque Vale,

Peter.
This letter, I may say, astonished me. I think it would astonish
anybody. A profound and enveloping melancholy succeeded to this
feeling of astonishment. At the time, I was engaged in putting the
finishing touches to The Tiger in the House and I postponed
meditation on Peter's affair until that bulky volume could be
dispatched to the printer. That happy event fell on March 15, 1920,
but my anthology, Lords of The Housetops, next claimed my
attention, and then the new edition of Interpreters, for which I had
agreed to furnish a new paper, and the writing of this new paper
amused me very much, carrying my mind not only far away from
cats, which had been occupying it for a twelvemonth, but also away
from Peter's request. At last, Interpreters was ready for the printer,
but now the proofs of The Tiger began to come in, and I may say that
for the next three months my days were fully occupied in the
correction of proofs, for those of Lords of The Housetops and
Interpreters were in my garret when the proofs of The Tiger were not.
Never have I corrected proofs with so much concentrated attention
as that which I devoted to the proofs of The Tiger, and yet there were
errors. In regard to some of these, I was not the collaborator. On
Page 240, for instance, one may read, There are many females in
the novels of Emile Zola. My intention was to have the fourth word
read, felines, and so it stood in the final proof, but my ambition to
surmount the initial letter of Zola's Christian name with an acute
accent (an ambition I shall forswear on this present page), compelled
the printer to reset the line, so that subsequently, when I opened the
book at this page, I read with amazement that there are many
females in the novels of Emile Zola, a statement that cannot be
readily denied, to be sure, but still it is no discovery of which to
boast.
It was not until September, 1920, that I had an opportunity to
seriously consider Peter's request and when I did begin to consider
it, I thought of it at first only as a duty to be accomplished. But when I
began searching my memory for details of the conversations
between us and had perused certain notes I had made on various
occasions, visited his house on Beekman Place to look over his
effects and talk with his mother, the feeling of the artist for inevitable
material came over me and I knew that whether Peter had written
me that letter or not, I should sooner or later have written this book
about him.
There was another struggle over the eventual form, a question
concerning which Peter had made no suggestions. It seemed to me,
at first, that a sort of haphazard collection of his ideas and
pronunciamentos, somewhat in the manner of Samuel Butler's Note-
Books, would meet the case, but after a little reflection I rejected this
idea. Light on the man was needed for a complete understanding of
his ideas, or lack of them, for they shifted like the waves of the sea. I
can never tell why, but it was while I was reading William Dean
Howells's Familiar Spanish Studies one day in the New York Public
Library that I suddenly decided on a sort of loose biographical form,
a free fantasia in the manner of a Liszt Rhapsody. This settled, I
literally swam ahead and scarcely found it necessary to examine
many papers (which was fortunate as few exist) or to consult
anything but my memory, which lighted up the subject from obscure
angles, as a search-light illuminates the spaces of the sea, once I
had learned to decipher the meaning of the problem. What it is all
about, or whether it is about anything at all, you, the reader, of
course, must decide for yourself. To me, the moral, if I may use a
conventional word to express an unconventional idea, is plain, and if
I have not succeeded in making it appear so, then I must to some
extent blame you, the reader, for what is true of all books, is perhaps
truest of this, that you will carry away from it only what you are able
to bring to it.
 Chapter I
One of my friends, a lady, visited Venice alone in her middle age. It
was late at night when the train drew into the station, and it was
raining, a drizzly, chilling rain. The porter pushed her, with her bag,
into a damp gondola and the dismal voyage to the hotel began.
There were a few lights here and there but she had the impression
that she was floating down the Chicago River in a wash-tub. Once
she had reached her destination, she clambered unsteadily out of
the black barge, wobbled through a dark passageway, inhaling great
whiffs of masticated garlic, and finally emerged in a dimly lighted
lobby. At the desk, a sleepy clerk yawned as she spoke of her
reservation. Tired, rather cross, and wholly disappointed, she
muttered, I don't like Venice at all. I wish I hadn't come. The clerk
was unsympathetically explanatory, Signora should have visited
Venice when she was younger.
A day or so later, the lady recovered her spirits and even her sense
of humour for she told me the story herself and I have always
remembered it. The moment it passed her lips, indeed, I began to
reflect that I had been lucky to encounter the Bride of the Adriatic in
my youth. Paris, too, especially Paris, for there is a melancholy
pleasure to be derived from Venice. It is a suitable environment for
grief; there is a certain superior relish to suffering there. Paris, I
sometimes think, smiles only on the very young and it is not a city I
should care to approach for the first time after I had passed forty.
I was, as a matter of fact, in my twenties when I first went to Paris—
my happiness might have been even greater had I been nineteen—
and I was alone. The trip across England—I had landed at Liverpool
—and the horrid channel, I will not describe, although both made
sufficient impression on me, but the French houses at Dieppe
awakened my first deep emotion and then, and so many times since,
the Normandy cider, quaffed in a little café, conterminous to the
railroad, and the journey through France, alive in the sunlight, for it
was May, the fields dancing with the green grain spattered with
vermilion poppies and cerulean cornflowers, the white roads, flying
like ribbons between the stately poplars, leading away over the
charming hills past the red-brick villas, completed the siege of my not
too easily given heart. There was the stately and romantic
interruption of Rouen, which at that period suggested nothing in the
world to me but Emma Bovary. Then more fields, more roads, more
towns, and at last, towards twilight, Paris.
Railroads have a fancy for entering cities stealthily through
backyards and the first glimpses of Paris, achieved from a car-
window, were not over-pleasant but the posters on the hoardings,
advertising beer and automobile tires, particularly that of the Michelin
Tire Company, with the picture of the pinguid gentleman, constructed
of a series of pneumatic circles, seemed characteristic enough.
Chéret was dead but something of his spirit seemed to glow in these
intensely coloured affiches and I was young. Even the dank Gare
Saint Lazare did not dismay me, and I entered into the novel
baggage hunt with something of zest, while other busy passengers
and the blue porters rushed hither and thither in a complicated but
well-ordered maze. Naturally, however, I was the last to leave the
station; as the light outside deepened to a rich warm blue, I
wandered into the street, my porter bearing my trunk, to find there a
solitary cocher mounted on the box of his carious fiacre.
An artist friend, Albert Worcester, had already determined my
destination and so I gave commands, Hotel de la Place de l'Odéon,
the cocher cracked his whip, probably adding a Hue cocotte! and we
were under way. The drive through the streets that evening seemed
like a dream and, even later, when the streets of Paris had become
more familiar to me than those of any other city, I could occasionally
recapture the mood of this first vision. For Paris in the May twilight is
very soft and exquisite, the grey buildings swathed in a bland blue
light and the air redolent with a strange fragrance, the ingredients of
which have never been satisfactorily identified in my nasal
imagination, although Huysmans, Zola, Symons, and Cunninghame
Graham have all attempted to separate and describe them.
Presently we crossed the boulevards and I saw for the first time the
rows of blooming chestnut trees, the kiosques where newsdealers
dispensed their wares, the brilliantly lighted theatres, the sidewalk
cafés, sprinkled with human figures, typical enough, doubtless, but
who all seemed as unreal to me at the time as if they had been
Brobdingnags, Centaurs, Griffins, or Mermaids. Other fiacres, private
carriages, taxi-autos, carrying French men and French ladies,
passed us. I saw Bel Ami, Nana, Liane de Pougy, or Otero in every
one of them. As we drove by the Opéra, I am certain that Cléo de
Mérode and Leopold of Belgium descended the steps. Even the
buses assumed the appearance of gorgeous chariots, bearing
perfumed Watteauesque ladies on their journey to Cythera. As we
drove through the Tuileries Gardens, the mood snapped for an
instant as I viewed the statue of Gambetta, which, I thought at the
time, and have always thought since, was amazingly like the portrait
of a gentleman hailing a cab. What could more completely symbolize
Paris than the statue of a gentleman perpetually hailing a cab and
never getting one?
We drove on through the Louvre and now the Seine was under us,
lying black in the twilight, reviving dark memories of crime and
murder, on across the Pont du Carrousel, and up the narrow Rue de
Seine. The Quartier Latin! I must have cried aloud, for the cocher
looked a trifle suspicious, his head turned the fraction of an inch.
Later, of course, I said, the left bank, as casually as any one. It was
almost dark when we drove into the open Place, flanked by the
Odéon, a great Roman temple, with my little hotel tucked into one
corner, as unostentatiously as possible, being exactly similar to
every other structure, save the central one, in the Place. I shall stop
tonight, I said to myself, in the hotel where Little Billee lived, for,
when one first goes to Paris when one is young, Paris is either the
Paris of Murger, du Maurier, or the George Moore of the
Confessions, perhaps the Paris of all three. In my bag these three
books lay, and I had already begun to live one of them.
The patron and a servant in a long white apron were waiting,
standing in the doorway. The servant hoisted my trunk to his
shoulder and bore it away. I paid the cocher's reckoning, not without
difficulty for, although I was not ignorant of the language, I was
unaccustomed to the simplicity of French coinage. There were also
the mysteries of the pourboire to compute—ten per cent, I had been
told; who has not been told this?—and besides, as always happens
when one is travelling, I had no little money. But at length the
negotiations were terminated, not to the displeasure of the cocher, I
feel certain, since he condescended to smile pleasantly. Then, with a
crack of his whip, this enormous fellow with his black moustaches,
his glazed top-hat, and his long coat, drove away. I cast a long
lingering look after him, apparently quite unaware that many another
such teratological specimen existed on every hand. Now I followed
the patron into a dark hallway and new strata of delight. He gave me
a lighted candle and, behind him, I mounted the winding stairway to
the first floor, where I was deposited in a chamber with dark red
walls, heavy dark red curtains at the windows, which looked out over
the Place, a black walnut wash-hand-stand with pitcher and basin, a
huge black walnut wardrobe, two or three chairs of the same wood,
upholstered with faded brocade, and a most luxurious bed, so high
from the floor that one had to climb into it, hung with curtains like
those at the window, and surmounted by a feather-bed. There was
also another article of furniture, indispensable to any French
bedroom.
I gave Joseph (all men servants in small hotels in Paris are named
Joseph, perhaps to warn off prospective Potiphar's wives) his vail,
asked for hot water, which he bore up promptly in a small can,
washed myself, did a little unpacking, humming the Mattchiche the
while, changed my shirt, my collar and my necktie, demanded
another bougie, lighted it, and under the humble illumination afforded
by it and its companion, I began to read again The Confessions of a
Young Man. It was not very long before I was interrupted in the midst
of an absorbing passage descriptive of the circle at the Nouvelle
Athènes by the arrival of Albert Worcester, who had arranged for my
reception, and right here I may say that I was lodged in the Hotel de
la Place de l'Odéon for fifty francs a month. Albert's arrival, although
unannounced, was not unexpected, as he had promised to take me
to dinner.
I was sufficiently emphatic. Paris! I cried. Paris! Good God!
I see you are not disappointed. But Albert permitted a trace of
cynicism to flavour his smile.
It's too perfect, too wonderful. It is more than I felt or imagined. I'm
moving in.
But you haven't seen it....
I've seen enough. I don't mean that. I mean I've seen enough to
know. But I want to see it all, everything, Saint Sulpice, the Folies-
Bergère, the Musée de Cluny, the Nouvelle Athènes, the Comédie
Française, the Bal Bullier, the Arc de Triomphe, the Luxembourg
Gardens....
They close at sundown. My expression was the cue for him to
continue, They'll be open tomorrow and any other day. They're just
around the corner. You can go there when you get up in the morning,
if you do get up in the morning. But what do you want to do tonight?
Anything! Everything! I cried.
Well, we'll eat first.
So we blew out the candles, floated down the dark stairs—I didn't
really walk for a week, I am sure—, brushing on our way against a
bearded student and a girl, fragrant and warm in the semi-blackness,
out into the delicious night, with the fascinating indescribable odour
of Paris, which ran the gamut from the fragrance of lilac and mimosa
to the aroma of horse-dung; with the sound of horses' hoofs and
rolling wheels beating and revolving on the cobble-stones, we made
our way—I swear my feet never touched the ground—through the
narrow, crooked, constantly turning, bewildering streets, until we
came out on a broad boulevard before the Café d'Harcourt, where I
was to eat my first Paris dinner.
The Café d'Harcourt is situated near the Church of the Sorbonne on
the Boulevard Saint Michel, which you are more accustomed to see
spelled Boul' Mich'. It is a big, brightly lighted café, with a broad
terrasse, partially enclosed by a hedge of green bushes in boxes.
The hands of the clock pointed to the hour of eight when we arrived
and the tables all appeared to be occupied. Inside, groups of men
were engaged in games of checkers, while the orchestra was
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookmass.com