Software Mistakes and Tradeoffs: How to make good programming decisions

Software Mistakes and Tradeoffs
brief contents
contents
preface
acknowledgments
about this book
Who should read this book
How this book is organized
About the code
liveBook discussion forum
about the authors
Tomasz Lelek
Jon Skeet
about the cover illustration
1 Introduction
1.1 Consequences of every decision and pattern
1.1.1 Unit testing decisions
1.1.2 Proportions of unit and integration tests
1.2 Code design patterns and why they do not always work
1.2.1 Measuring our code
1.3 Architecture design patterns and why they do not always work
1.3.1 Scalability and elasticity
1.3.2 Development speed
1.3.3 Complexity of microservices
Summary
2 Code duplication is not always bad: Code duplication vs. flexibility
2.1 Common code between codebases and duplication
2.1.1 Adding a new business requirement that requires code duplication
2.1.2 Implementing the new business requirement
2.1.3 Evaluating the result
2.2 Libraries and sharing code between codebases
2.2.1 Evaluating the tradeoffs and disadvantages of shared libraries
2.2.2 Creating a shared library
2.3 Code extraction to a separate microservice
2.3.1 Looking at the tradeoffs and disadvantages of a separate service
2.3.2 Conclusions about separate service
2.4 Improving loose coupling by code duplication
2.5 An API design with inheritance to reduce duplication
2.5.1 Extracting a base request handler
2.5.2 Looking at inheritance and tight coupling
2.5.3 Looking at the tradeoffs between inheritance and composition
2.5.4 Looking at inherent and incidental duplication
Summary
3 Exceptions vs. other patterns of handling errors in your code
3.1 Hierarchy of exceptions
3.1.1 Catch-all vs. a more granular approach to handling errors
3.2 Best patterns to handle exceptions in the code that you own
3.2.1 Handling checked exceptions in a public API
3.2.2 Handling unchecked exceptions in a public API
3.3 Anti-patterns in exception handling
3.3.1 Closing resources in case of an error
3.3.2 Anti-pattern of using exceptions to control application flow
3.4 Exceptions from third-party libraries
3.5 Exceptions in multithread environments
3.5.1 Exceptions in an async workflow with a promise API
3.6 Functional approach to handling errors with Try
3.6.1 Using Try in production code
3.6.2 Mixing Try with code that throws an exception
3.7 Performance comparison of exception-handling code
Summary
4 Balancing flexibility and complexity
4.1 A robust but not extensible API
4.1.1 Designing a new component
4.1.2 Starting with the most straightforward code
4.2 Allowing clients to provide their own metrics framework
4.3 Providing extensibility of your APIs via hooks
4.3.1 Guarding against unpredictable usage of the hooks API
4.3.2 Performance impact of the hook API
4.4 Providing extensibility of your APIs via listeners
4.4.1 Using listeners vs. hooks
4.4.2 Immutability of our design
4.5 Flexibility analysis of an API vs. the cost of maintenance
Summary
5 Premature optimization vs. optimizing the hot path: Decisions that impact code performance
5.1 When premature optimization is evil
5.1.1 Creating accounts processing pipeline
5.1.2 Optimizing processing based on false assumptions
5.1.3 Benchmarking performance optimization
5.2 Hot paths in your code
5.2.1 Understanding the Pareto principle in the context of software systems
5.2.2 Configuring the number of concurrent users (threads) for a given SLA
5.3 A word service with a potential hot path
5.3.1 Getting the word of the day
5.3.2 Validating if the word exists
5.3.3 Exposing the WordsService using HTTP service
5.4 Hot path detection in your code
5.4.1 Creating API performance tests using Gatling
5.4.2 Measuring code paths using MetricRegistry
5.5 Improvements for hot path performance
5.5.1 Creating JMH microbenchmark for the existing solution
5.5.2 Optimizing word exists using a cache
5.5.3 Modifying performance tests to have more input words
Summary
6 Simplicity vs. cost of maintenance for your API
6.1 A base library used by other tools
6.1.1 Creating a cloud service client
6.1.2 Exploring authentication strategies
6.1.3 Understanding the configuration mechanism
6.2 Directly exposing settings of a dependent library
6.2.1 Configuring the batch tool
6.3 A tool that is abstracting settings of a dependent library
6.3.1 Configuring the streaming tool
6.4 Adding new setting for the cloud client library
6.4.1 Adding a new setting to the batch tool
6.4.2 Adding a new setting to the streaming tool
6.4.3 Comparing both solutions for UX friendliness and maintainability
6.5 Deprecating/removing a setting in the cloud client library
6.5.1 Removing a setting from the batch tool
6.5.2 Removing a setting from the streaming tool
6.5.3 Comparing both solutions for UX friendliness and maintainability
Summary
7 Working effectively with date and time data
7.1 Concepts in date and time information
7.1.1 Machine time: Instants, epochs, and durations
7.1.2 Civil time: Calendar systems, dates, times, and periods
7.1.3 Time zones, UTC, and offsets from UTC
7.1.4 Date and time concepts that hurt my head
7.2 Preparing to work with date and time information
7.2.1 Limiting your scope
7.2.2 Clarifying date and time requirements
7.2.3 Using the right libraries or packages
7.3 Implementing date and time code
7.3.1 Applying concepts consistently
7.3.2 Improving testability by avoiding defaults
7.3.3 Representing date and time values in text
7.3.4 Explaining code with comments
7.4 Corner cases to specify and test
7.4.1 Calendar arithmetic
7.4.2 Time zone transitions at midnight
7.4.3 Handling ambiguous or skipped times
7.4.4 Working with evolving time zone data
Summary
8 Leveraging data locality and memory of your machines
8.1 What is data locality?
8.1.1 Moving computations to data
8.1.2 Scaling processing using data locality
8.2 Data partitioning and splitting data
8.2.1 Offline big data partitioning
8.2.2 Partitioning vs. sharding
8.2.3 Partitioning algorithms
8.3 Join big data sets from multiple partitions
8.3.1 Joining data within the same physical machine
8.3.2 Joining that requires data movement
8.3.3 Optimizing join leveraging broadcasting
8.4 Data processing: Memory vs. disk
8.4.1 Using disk-based processing
8.4.2 Why do we need MapReduce?
8.4.3 Calculating access times
8.4.4 RAM-based processing
8.5 Implement joins using Apache Spark
8.5.1 Implementing a join without broadcast
8.5.2 Implementing a join with broadcast
Summary
9 Third-party libraries: Libraries you use become your code
9.1 Importing a library and taking full responsibility for its settings: Beware of the defaults
9.2 Concurrency models and scalability
9.2.1 Using async and sync APIs
9.2.2 Distributed scalability
9.3 Testability
9.3.1 Testing library
9.3.2 Testing with fakes (test double) and mocks
9.3.3 Integration testing toolkit
9.4 Dependencies of third-party libraries
9.4.1 Avoiding version conflicts
9.4.2 Too many dependencies
9.5 Choosing and maintaining third-party dependencies
9.5.1 First impressions
9.5.2 Different approaches to reusing code
9.5.3 Vendor lock-in
9.5.4 Licensing
9.5.5 Libraries vs. frameworks
9.5.6 Security and updates
9.5.7 Decision checklist
Summary
10 Consistency and atomicity in distributed systems
10.1 At-least-once delivery of data sources
10.1.1 Traffic between one-node services
10.1.2 Retrying an application’s call
10.1.3 Producing data and idempotency
10.1.4 Understanding Command Query Responsibility Segregation (CQRS)
10.2 A naive implementation of a deduplication library
10.3 Common mistakes when implementing deduplication in distributed systems
10.3.1 One node context
10.3.2 Multiple nodes context
10.4 Making your logic atomic to prevent race conditions
Summary
11 Delivery semantics in distributed systems
11.1 Architecture of event-driven applications
11.2 Producer and consumer applications based on Apache Kafka
11.2.1 Looking at the Kafka consumer side
11.2.2 Understanding the Kafka brokers setup
11.3 The producer logic
11.3.1 Choosing consistency vs. availability for the producer
11.4 Consumer code and different delivery semantics
11.4.1 Committing a consumer manually
11.4.2 Restarting from the earliest or latest offsets
11.4.3 (Effectively) exactly-once semantic
11.5 Leveraging delivery guarantees to provide fault tolerance
Summary
12 Managing versioning and compatibility
12.1 Versioning in the abstract
12.1.1 Properties of versions
12.1.2 Backward and forward compatibility
12.1.3 Semantic versioning
12.1.4 Marketing versions
12.2 Versioning for libraries
12.2.1 Source, binary, and semantic compatibility
12.2.2 Dependency graphs and diamond dependencies
12.2.3 Techniques for handling breaking changes
12.2.4 Managing internal-only libraries
12.3 Versioning for network APIs
12.3.1 The context of network API calls
12.3.2 Customer-friendly clarity
12.3.3 Common versioning strategies
12.3.4 Further versioning considerations
12.4 Versioning for data storage
12.4.1 A brief introduction to Protocol Buffers
12.4.2 What is a breaking change?
12.4.3 Migrating data within a storage system
12.4.4 Expecting the unexpected
12.4.5 Separating API and storage representations
12.4.6 Evaluating storage formats
Summary
13 Keeping up to date with trends vs. cost of maintenance of your code
13.1 When to use dependency injection frameworks
13.1.1 Do-it-yourself (DIY) dependency injection
13.1.2 Using a dependency injection framework
13.2 When to use reactive programming
13.2.1 Creating single-threaded, blocking processing
13.2.2 Using CompletableFuture
13.2.3 Implementing a reactive solution
13.3 When to use functional programming
13.3.1 Creating functional code in a nonfunctional language
13.3.2 Tail recursion optimization
13.3.3 Leveraging immutability
13.4 Using lazy vs. eager evaluation
Summary
index
A
B
C
D
E
F
G
H
I
J
L
M
N
O
P
R
S
T
U
V
W
Y
Z