loose coupling

95 results back to index

The Connected Company by Dave Gray, Thomas Vander Wal

A Pattern Language, Alan Greenspan, Albert Einstein, Amazon Mechanical Turk, Amazon Web Services, Atul Gawande, Berlin Wall, business cycle, business process, call centre, Clayton Christensen, commoditize, complexity theory, creative destruction, David Heinemeier Hansson, digital rights, disruptive innovation, en.wikipedia.org, factory automation, folksonomy, Googley, index card, industrial cluster, interchangeable parts, inventory management, Jeff Bezos, John Markoff, Kevin Kelly, loose coupling, low cost airline, market design, minimum viable product, more computing power than Apollo, power law, profit maximization, Richard Florida, Ruby on Rails, Salesforce, scientific management, self-driving car, shareholder value, side project, Silicon Valley, skunkworks, software as a service, South of Market, San Francisco, Steve Jobs, Steven Levy, Stewart Brand, subscription business, systems thinking, tacit knowledge, The Wealth of Nations by Adam Smith, Tony Hsieh, Toyota Production System, two-pizza team, Vanguard fund, web application, WikiLeaks, work culture , Zipcar

If the bar shuts down, people can still order food, and vice versa. Loose Coupling Loose coupling simply means that services agree to use a common set of rules about how to connect. So as long as a service follows the rules, it can update, change, or modify itself without having to worry about the impact on other services in the system. Web pages, for example, are loosely coupled, because one web page can link to another without knowing anything about the other page beyond its address and the rules for connection (which in this case is HTTP, the protocol common to most web pages). The opposite of loose coupling is tight coupling, where elements on both sides must be designed to complement and fit one another.

…

training versus learning, Freedom to Experiment, Freedom to Experiment learning fields, Learning Fields, Learning Fields, Diversity Matters Lehman, M.M., Agile Development Levy, Steven, Density Linden, Greg, Attractors Linux operating system, What is a Platform? Logitech (company), Net Promoter at Logitech–Net Promoter at Logitech, Net Promoter at Logitech loose coupling, Service Contracts, Loose Coupling, Most Companies are Not Built for Agility about, Service Contracts, Loose Coupling car example, Most Companies are Not Built for Agility Lusch, Robert F., Service-Dominant Logic M machines, The Company as a Machine–Closed and Open Systems, The Company as a Machine, The Company as a Machine, Closed and Open Systems, Closed and Open Systems, Closed and Open Systems as closed systems, Closed and Open Systems companies as, The Company as a Machine–Closed and Open Systems, The Company as a Machine, Closed and Open Systems, Closed and Open Systems purpose of, The Company as a Machine Mackey, John, It Takes Trust to Build Relationships Mailchimp (company), Strategy by Discovery management, Leading from the Edge, Managing the connected company, Management is a Support System, Designing the System–Rely on Peer-to-Peer Reinforcement Whenever Possible, Balance the Individual Freedom with the Common Good, Build Slack into Central Resources to Ensure Availability, Rely on Peer-to-Peer Reinforcement Whenever Possible, Rely on Peer-to-Peer Reinforcement Whenever Possible, Operating the System, Critical Values in Complex Adaptive Systems, Symptoms, Tuning the System–The Job of Managers, Tuning the System, Information Transparency, Density, Rate of Flow, Structural Change, The Job of Managers, The Job of Managers, The Job of Managers as support system, Management is a Support System designing system for, Designing the System–Rely on Peer-to-Peer Reinforcement Whenever Possible, Balance the Individual Freedom with the Common Good, Build Slack into Central Resources to Ensure Availability, Rely on Peer-to-Peer Reinforcement Whenever Possible, Rely on Peer-to-Peer Reinforcement Whenever Possible leadership versus, Leading from the Edge operating the system, Operating the System, Critical Values in Complex Adaptive Systems, Symptoms, Tuning the System purpose of, Managing the connected company role of, The Job of Managers tuning the system, Tuning the System–The Job of Managers, Information Transparency, Density, Rate of Flow, Structural Change, The Job of Managers, The Job of Managers maneuver warfare, Three Types of Strategy Marriott International, Connecting an Internal Group at Marriott–Connecting an Internal Group at Marriott, Connecting an Internal Group at Marriott mass marketing, product saturation and, An Age of Abundance–An Age of Abundance, An Age of Abundance, An Age of Abundance mass production, Interchangeable Parts–Conflicting Constraints Lead to Rigidity, Interchangeable Parts, Conflicting Constraints Lead to Rigidity standardization and, Interchangeable Parts–Conflicting Constraints Lead to Rigidity, Interchangeable Parts, Conflicting Constraints Lead to Rigidity Maverick (Semler), Democratic Management at Semco McCarthy, Patrick D., Freedom to Experiment, The Nordstrom Way McDonald’s (company), Reducing Variety–Absorbing Variety, Reducing Variety, Absorbing Variety, Support–Balancing the Needs of Constituents, Balancing the Needs of Constituents reducing variety, Reducing Variety–Absorbing Variety, Reducing Variety, Absorbing Variety support structure, Support–Balancing the Needs of Constituents, Balancing the Needs of Constituents McIntyre, Tim, Cascading Effects Can be Initiated by Employees McKelvey, Bill, The Red Queen Race, Adaptive Tensions Microsoft Corporation, What is a Platform?

…

service avatars, Service-Dominant Logic–Products as Job Descriptions, A Product is a Service Avatar, Products as Job Descriptions service contracts, Service Contracts about, Service Contracts service economy, The Great Reset, An Age of Abundance–An Emerging Service Economy, An Emerging Service Economy age of abundance and, An Age of Abundance–An Emerging Service Economy, An Emerging Service Economy great resets and, The Great Reset service networks, Service Networks service orientation approach, Service Orientation–Netflix, a City of Services, Service Orientation, Service Contracts, Loose Coupling, Netflix, a City of Services Service-Oriented Architecture (SOA), Standards services, Power in the Network, An Emerging Service Economy–Urbanization, Urbanization, Urbanization, Service-Dominant Logic, Service-Dominant Logic, Services are Co-created, Services are Co-created, A Process is Not a Service, Services are complex–Control at the Edge, Demands on Companies are Increasing in Volume, Velocity, Variety, Customers Introduce Complexity and Variability into Operations, Customers Resist Standardization, Control at the Edge, The One Judge of Service Quality, The Front Line is not a Production Line, Service Contracts, Composability, Loose Coupling–Netflix, a City of Services, Loose Coupling, Netflix, a City of Services co-created, Services are Co-created complexity of, Services are complex–Control at the Edge, Demands on Companies are Increasing in Volume, Velocity, Variety, Customers Introduce Complexity and Variability into Operations, Control at the Edge composability of, Composability connected customers and, Power in the Network describing in service contracts, Service Contracts difficulty keeping promises with, Customers Resist Standardization factors driving move toward, An Emerging Service Economy–Urbanization, Urbanization, Urbanization judging quality of, The One Judge of Service Quality, The Front Line is not a Production Line loosely coupling, Loose Coupling–Netflix, a City of Services, Loose Coupling, Netflix, a City of Services processes versus, A Process is Not a Service service-dominant logic, Service-Dominant Logic, Service-Dominant Logic, Services are Co-created shareholders, company purpose and, What is the Purpose of a Company?–How Profits Can Destroy Your Company, What is the Purpose of a Company?

Building Microservices by Sam Newman

airport security, Amazon Web Services, anti-pattern, business logic, business process, call centre, continuous integration, Conway's law, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, fail fast, fallacies of distributed computing, fault tolerance, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, Kubernetes, load shedding, loose coupling, microservices, MITM: man-in-the-middle, platform as a service, premature optimization, pull request, recommendation engine, Salesforce, SimCity, social graph, software as a service, source of truth, sunk-cost fallacy, systems thinking, the built environment, the long tail, two-pizza team, web application, WebSocket

If you’ve survived a failed SOA implementation, you may have some idea where I’m going next. But just in case you aren’t that (un)fortunate, I want you to focus on two key concepts: loose coupling and high cohesion. We’ll talk in detail throughout the book about other ideas and practices, but they are all for naught if we get these two thing wrong. Despite the fact that these two terms are used a lot, especially in the context of object-oriented systems, it is worth discussing what they mean in terms of microservices. Loose Coupling When services are loosely coupled, a change to one service should not require a change to another. The whole point of a microservice is being able to make a change to one service and deploy it, without needing to change any other part of the system.

…

Loose and Tightly Coupled Organizations In Exploring the Duality Between Product and Organizational Architectures (Harvard Business School), the authors Alan MacCormack, John Rusnak, and Carliss Baldwin look at a number of different software systems, loosely categorized as being created either by loosely coupled organizations or tightly coupled organizations. For tightly coupled organizations, think commercial product firms that are typically colocated with strongly aligned visions and goals, while loosely coupled organizations are well represented by distributed open source communities. In their study, in which they matched similar product pairs from each type of organization, the authors found that the more loosely coupled organizations actually created more modular, less coupled systems, whereas the more tightly focused organization’s software was less modularized.

…

With the right tools at our disposal, we can slay this beast. It’s All About Seams We discussed in Chapter 3 that we want our services to be highly cohesive and loosely coupled. The problem with the monolith is that all too often it is the opposite of both. Rather than tend toward cohesion, and keep things together that tend to change together, we acquire and stick together all sorts of unrelated code. Likewise, loose coupling doesn’t really exist: if I want to make a change to a line of code, I may be able to do that easily enough, but I cannot deploy that change without potentially impacting much of the rest of the monolith, and I’ll certainly have to redeploy the entire system.

Hands-On RESTful API Design Patterns and Best Practices by Harihara Subramanian

blockchain, business logic, business process, cloud computing, continuous integration, create, read, update, delete, cyber-physical system, data science, database schema, DevOps, disruptive innovation, domain-specific language, fault tolerance, information security, Infrastructure as a Service, Internet of things, inventory management, job automation, Kickstarter, knowledge worker, Kubernetes, loose coupling, Lyft, machine readable, microservices, MITM: man-in-the-middle, MVC pattern, Salesforce, self-driving car, semantic web, single page application, smart cities, smart contracts, software as a service, SQL injection, supply-chain management, web application, WebSocket

In the case of API design, affordance undoubtedly plays a crucial role, and it is an essential aspect of our API designs. Loosely coupled As the whole purpose of an API is to connect heterogeneous clients with the same backend code, it's inevitable that APIs should be as independent as possible and as loosely coupled as possible with the calling clients. In a loosely coupled design, APIs are independent, and modifications in one won't impact the operation of consumers. Within an API, the components get added, modified, or replaced. However, the loose coupling approach offers clients better flexibility and reusability of APIs while its elements are added, replaced, or changed. Having a loosely coupled architecture in REST API server designs facilitates the client and server as both follow and respect common semantics.

…

RESTful APIs are the most popular for API-enabled microservices. The services talk to one another through API calls. To craft and sustain business-critical and enterprise-grade applications, multiple microservices have to be blended together. Microservices are modular (loosely coupled and highly cohesive). The lightly- or loosely-coupled microservices do away the dependency-associated risks and drawbacks. On the other hand, the closely-related responsibilities of a software module are kept together. Each microservice implements a distinct business functionality and hence has a small code base. Therefore, it's easy and quick for service developers to bring in any desired changes.

…

PacktPub.com Contributors About the authors About the reviewers Packt is searching for authors like you Preface Who this book is for What this book covers To get the most out of this book Download the example code files Conventions used Get in touch Reviews Introduction to the Basics of RESTful Architecture Technical requirements Evolution of web technologies Learning about Web 3.0 Learning about web service architecture Discussing the web API Learning about service-oriented architecture Learning about resource-oriented architecture Resource-oriented design The benefits of ROA Beginning with REST REST architecture style constraints Beginning with client-server The client in client-server architecture The service in client-server architecture Understanding statelessness Advantages and disadvantages of statelessness Caching constraint in REST Benefits of caching Understanding the uniform interface Identification of resources Manipulation of resources Self-descriptive messages Hypermedia as the Engine of Application State Layered systems Code on demand RESTful service mandates Architectural goals of REST Summary Design Strategy, Guidelines, and Best Practices Technical requirements Learning about REST API and its importance Goals of RESTful API design Affordance Loosely coupled Leverage web architecture API designer roles and responsibilities  API design best practices API design principles Ubiquitous web standards Flexibility Granularity Optimized APIs Functionality Learning about unusual circumstances Community standardization API playgrounds RESTful API design rules Learning about Uniform Resource Identifiers URI formats REST API URI authority Resource modelling Resource archetypes URI path URI query HTTP interactions Request methods Response status codes Metadata design HTTP headers Media types and media type design rules Representations Message body format Hypermedia representation Media type representation Errors representation Client concerns Versioning Security Response representation composition Processing hypermedia JavaScript clients Summary Further reading Essential RESTful API Patterns Technical requirements Beginning with the installations Beginning with RESTful API patterns – part I Statelessness Content negotiation Content negotiation with HTTP headers URI templates Design for intent Pagination Discoverability Error and exception logging Unicode Summary Advanced RESTful API Patterns Technical requirements RESTful API advanced patterns Versioning Versioning through the URI path Versioning through query parameters Versioning through custom headers Versioning through content-negotiation Authorization Authorization with the default key Authorization with credentials Uniform contract Entity endpoints Endpoint redirection Idempotent Bulk operation Circuit breaker Combining the circuit pattern and the retry pattern API facade Backend for frontend Summary Further reading Microservice API Gateways Technical requirements About microservice architecture The prominent infrastructure modules in microservice-centric applications Service registry  Service discovery Composition/orchestration  Transformation  Monitoring  Load balancing and scaling  High availability and failover  HA and failover guidelines Governance  About API gateway solutions API gateways for microservice-centric applications The issues with microservice API gateways Security features of API gateways Prominent API gateway solutions Service mesh versus API gateway Summary RESTful Services API Testing and Security An overview of software testing  RESTful APIs and testing Basics of API testing Understanding API testing approaches API testing types Unit tests API validation tests Functional tests UI or end-to-end tests Load testing Runtime error detection tests Monitoring APIs Execution errors Resource leaks Error detection REST API security vulnerabilities Exposing sensitive data Understanding authentication and authentication attacks Understanding authorization and OAuth2 schemes Cross-site scripting Reflected XSS Stored XSS DOM XSS Cross-site request forgery Denial-of-service attack Distributed denial of service Injection attacks Insecure direct object references Missing function-level access control Man-in-the-middle attacks Common types of MITM attacks and protection measures Replay attacks and spoofing Causes of vulnerabilities API design and development flaws Poor system configuration Human error Internal and external connectivity Security tests Penetration tests or pen tests Importance of penetration tests Pen testing lifecycle Preparation, planning, and reconnaissance Scanning Gaining access Maintaining access Analysis Pen testing types for API testing White-box penetration testing Fuzz tests The life cycle of fuzz tests Fuzz testing strategy Mutation-based fuzz tests Generation-based fuzz tests Advantages and disadvantages of fuzz tests Back to API testing API test cases Essential aspects of API test cases and test case preparation API testing challenges Initial setup API schema updates for testing Testing parameter combinations API call sequence Validating parameters Tracking system integration API testing best practices API testing tools CQRS Summary Further reading RESTful Service Composition for Smart Applications Technical requirements Briefing RESTful microservices Demystifying the MSA style The advantages of microservices The emergence of cloud-native applications The growing ecosystem of IoT device services The changing application ecosystem Tending toward the API-driven world The Representational State Transfer service paradigm API design best practices Learning about service-composition methods Service orchestration and choreography Beginning with service orchestration The shortcomings of service orchestration Applying orchestration-based composition Beginning with service choreography The shortcomings of service choreography Applying choreography-based composition The hybridization of orchestration and choreography Another example of the hybridization of orchestration and choreography Choreography Service choreography using the message broker Service orchestration Service orchestration using BPMN and REST The hybridization – event-driven service orchestration Data management  Thinking in REST Discarding SQL join Eventual consistency Polyglot persistence Summary RESTful API Design Tips Technical requirements Beginning with APIs Learning about application programming interfaces APIs have become indispensable Learning about the major types of APIs Describing API platforms Creating API development platforms API-integration platforms Legacy integration API management platforms Demystifying the RESTful services paradigm Characterizing the REST architecture style REST Resource Representation Compression Idempotent REST APIs REST API design considerations Enumerating RESTful API design patterns Media types API security design patterns Whitelist allowable methods Summary Further reading A More In-depth View of the RESTful Services Paradigm Technical requirements Tending toward the software-defined and software-driven world Software-enabled clouds for the digital intelligence era The IoT applications and services Cloud-enabled applications Cloud-native applications Mobile, handheld, and wearable applications Transactional, operational, and analytical applications Knowledge visualization applications Social applications  Scientific and technical applications  Centralized and distributed applications Decentralized and intelligent applications with blockchain technology  Composite and multi-container applications  Event-driven applications  High-quality applications Resilient applications  The REST paradigm for application modernization and integration Application programming interfaces Public APIs for external integration and innovation Private APIs for internal purposes  APIs for IoT devices APIs for application integration Describing the RESTful services paradigm REST architectural constraints The advantages of REST Self-descriptive messages SOAP versus REST When to use REST versus SOAP Best practices for REST-based microservices The API-first approach Developing API-first Building services API-first Summary Further reading Frameworks, Standard Languages, and Toolkits Technical requirements Core features of a framework Spring Boot Core features of Spring Database integration with Spring data Messaging integration Extending Spring with auto-configuration Writing unit tests and integration test cases Benefits of Spring Boot Drawbacks of Spring Boot Beginning about Light 4j Core features of Light 4j Learning about Light Rest 4j Light-code-gen Choosing Light 4j over the rest Spark Framework Core features of Spark Framework Creating an API with fewer lines Benefits of Spark Drawbacks of Spark Dropwizard Overview Core features of Dropwizard Jetty for HTTP Jersey for REST Jackson Metrics Liquibase Other noteworthy features Benefits of Dropwizard Drawbacks of Dropwizard Understanding Go framework for the RESTful API An overview Gin-gonic Core features HttpRouter Http2 server push Multi-template Upload files Other noteworthy features Benefits of Gin-Gonic Drawbacks of Gin-Gonic Revel Core features Router Server engine Controllers Handlers Interceptors Filters Cache Other noteworthy features Benefits of Revel Drawbacks of Revel Python RESTful API frameworks Overview of Python Django Django Rest Framework Core features Web-browsable API Authentication Serialization and deserialization Other noteworthy features Benefits of the DRF Drawbacks of the DRF Flask Flask-RESTful Core features of Flask-RESTful Resourceful routing Restful request parsing Output fields Other noteworthy features Benefits of the Flask framework Drawbacks of Flask Frameworks – a table of reference  Summary Further reading Legacy Modernization to Microservices-Centric Apps Technical requirements A preview of containers and microservices Introducing the microservices architecture Why legacy modernization?

Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton, Manuel Pais

anti-pattern, business logic, business process, call centre, cognitive load, continuous integration, Conway's law, database schema, DevOps, different worldview, Dunbar number, holacracy, information security, Infrastructure as a Service, Internet of things, Jeff Bezos, Kanban, Kickstarter, knowledge worker, Kubernetes, Lean Startup, loose coupling, meta-analysis, microservices, Norbert Wiener, operational security, platform as a service, pull request, remote working, systems thinking, two-pizza team, web application

The authors also mention architectural approaches that help decouple such architectures: “Architectural approaches that enable this strategy [of supporting teams’ full ownership from design through to deployment] include the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units.”1 But when we want to move from a monolithic software system to more loosely coupled services, we must also consider how the new architecture will affect the teams involved. We need to take into account their cognitive capacity, their location, and their interest in the new services. Without taking into account the team angle, we risk splitting the monolith in the wrong places or even creating a complex system of interdependent services.

…

CONTENTS Figures & Tables Case Studies & Industry Examples Foreword by Ruth Malan Preface PART I TEAMS AS THE MEANS OF DELIVERY Chapter 1: The Problem with Org Charts Communication Structures of an Organization Team Topologies: A New Way of Thinking about Teams The Revival of Conway’s Law Cognitive Load and Bottlenecks Summary: Rethink Team Structures, Purpose, and Interactions Chapter 2: Conway’s Law and Why It Matters Understanding and Using Conway’s Law The Reverse Conway Maneuver Software Architectures that Encourage Team-Scoped Flow Organization Design Requires Technical Expertise Restrict Unnecessary Communication Beware: Naive Uses of Conway’s Law Summary: Conway’s Law Is Critical for Efficient Team Design in Tech Chapter 3: Team-First Thinking Use Small, Long-Lived Teams as the Standard Good Boundaries Minimize Cognitive Load Design “Team APIs” and Facilitate Team Interactions Warning: Engineering Practices Are Foundational Summary: Limit Teams’ Cognitive Load and Facilitate Team Interactions to Go Faster PART II TEAM TOPOLOGIES THAT WORK FOR FLOW Chapter 4: Static Team Topologies Team Anti-Patterns Design for Flow of Change DevOps and the DevOps Topologies Successful Team Patterns Considerations When Choosing a Topology Use DevOps Topologies to Evolve the Organization Summary: Adopt and Evolve Team Topologies that Match Your Current Context Chapter 5: The Four Fundamental Team Topologies Stream-Aligned Teams Enabling Teams Complicated-Subsystem Teams Platform Teams Avoid Team Silos in the Flow of Change A Good Platform Is “Just Big Enough” Convert Common Team Types to the Fundamental Team Topologies Summary: Use Loosely Coupled, Modular Groups of Four Specific Team Types Chapter 6: Choose Team-First Boundaries A Team-First Approach to Software Responsibilities and Boundaries Hidden Monoliths and Coupling Software Boundaries or “Fracture Planes” Real-World Example: Manufacturing Summary: Choose Software Boundaries to Match Team Cognitive Load PART III EVOLVING TEAM INTERACTIONS FOR INNOVATION AND RAPID DELIVERY Chapter 7: Team Interaction Modes Well-Defined Interactions Are Key to Effective Teams The Three Essential Team Interaction Modes Team Behaviors for Each Interaction Mode Choosing Suitable Team Interaction Modes Choosing Basic Team Organization Choose Team Interaction Modes to Reduce Uncertainty and Enhance Flow Summary: Three Well-Defined Team Interaction Modes Chapter 8: Evolve Team Structures with Organizational Sensing How Much Collaboration Is Right for Each Team Interaction?

…

Managing cognitive load through teams with clear responsibilities and boundaries is a distinguishing focus of team design in the Team Topologies approach. To achieve duly scoped, bounded responsibilities, natural—and relatively independent—system (sub)structure is sought to align teams to. This takes Conway’s law into account and leverages it to help maintain cohesive structures with clear boundaries and loose coupling (known as the reverse Conway maneuver, and described herein). If this was the extent of it, Team Topologies would be a useful elaboration of Conway’s paper, setting it in the current context. Of course, Team Topologies is even more than that. Notably, it identifies four team patterns, describing their outcomes, form, and the forces they address and are shaped by.

No Rules Rules: Netflix and the Culture of Reinvention by Reed Hastings, Erin Meyer

Airbnb, An Inconvenient Truth, Downton Abbey, Elon Musk, en.wikipedia.org, FedEx blackjack story, global village, hiring and firing, job-hopping, karōshi / gwarosa / guolaosi, late fees, loose coupling, loss aversion, out of africa, performance metric, Saturday Night Live, Sheryl Sandberg, Silicon Valley, Skype, Stephen Hawking, Steve Ballmer, Steve Jobs, subscription business, super pumped, tech worker, The last Blockbuster video rental store is in Bend, Oregon, work culture

In addition to high talent density (that’s the first condition) and a goal of innovation rather than error prevention (that’s the second), you also need to work (here comes the third) in a system that is “loosely coupled.” LOOSELY OR TIGHTLY COUPLED? I’m a software engineer and software engineers speak about “tight coupling” and “loose coupling” to explain two different types of system design. A tightly coupled system is one in which the various components are intricately intertwined. If you want to make a change to one area of the system, you have to go back and rework the foundation, which impacts not just the section you need to change, but the entire system. By contrast, a loosely coupled design system has few interdependencies between the component parts.

…

This brings us to the fourth and final precondition for leading with context. IS YOUR ORGANIZATION HIGHLY ALIGNED? If loose coupling is to work effectively, with big decisions made at the individual level, then the boss and the employees must be in lockstep agreement on their destination. Loose coupling works only if there is a clear, shared context between the boss and the team. That alignment of context drives employees to make decisions that support the mission and strategy of the overall organization. This is why the mantra at Netflix is HIGHLY ALIGNED, LOOSELY COUPLED To understand what this involves, let’s return to Downton Abbey, where your family members are waiting for their dinner.

…

That’s why software engineers like loose coupling; they can make a change to part of the system with no repercussions for the rest of it. The entire system is more flexible. Organizations are constructed a bit like computer programs. When a company is tightly coupled, big decisions get made by the big boss and pushed down to the departments, often creating interdependencies between the various areas of the business. If a problem occurs at the departmental level, it has to go back to the boss who oversees all of the departments. Meanwhile, in a loosely coupled company, an individual manager or employee is free to make decisions or solve problems, safe in the knowledge that the consequences will not ricochet through other departments.

The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2 by Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan

active measures, Amazon Web Services, anti-pattern, barriers to entry, business process, cloud computing, commoditize, continuous integration, correlation coefficient, database schema, Debian, defense in depth, delayed gratification, DevOps, domain-specific language, en.wikipedia.org, fault tolerance, finite state, Firefox, functional programming, Google Glasses, information asymmetry, Infrastructure as a Service, intermodal, Internet of things, job automation, job satisfaction, Ken Thompson, Kickstarter, level 1 cache, load shedding, longitudinal study, loose coupling, machine readable, Malcom McLean invented shipping containers, Marc Andreessen, place-making, platform as a service, premature optimization, recommendation engine, revision control, risk tolerance, Salesforce, scientific management, seminal paper, side project, Silicon Valley, software as a service, sorting algorithm, standardized shipping container, statistical model, Steven Levy, supply-chain management, systems thinking, The future is already here, Toyota Production System, vertical integration, web application, Yogi Berra

Databases that provide weaker consistency models often refer to themselves as NoSQL and describe themselves as BASE: Basically Available Soft-state services with Eventual consistency. 1.6 Loosely Coupled Systems Distributed systems are expected to be highly available, to last a long time, and to evolve and change without disruption. Entire subsystems are often replaced while the system is up and running. To achieve this a distributed system uses abstraction to build a loosely coupled system. Abstraction means that each component provides an interface that is defined in a way that hides the implementation details. The system is loosely coupled if each component has little or no knowledge of the internals of the other components.

…

With all components moving in lock-step, one delayed release will mean the components that are ready to move forward have to wait. If the components are loosely coupled, then each component can be tested independently and pushed at its own velocity. Problems are more isolated. The changed component may fail, in which case we know it is a problem with that component. The other components may fail, in which case we know that the changed component has introduced an incompatibility. Such a system works only when components are loosely coupled. For example, at Google the entire infrastructure is an ecosystem of small, loosely coupled services. Services are constantly being upgraded. It is not possible to ask the entire company to stop so that your system can be tested.

…

With this architecture, each subsystem is a self-contained service providing its functionality as a consumable service via an API. The various services communicate with one another by making API calls. A goal of SOAs is to have the services be loosely coupled. That is, each API presents its service at a high level of abstraction. This makes it easier to improve and even replace a service. The replacement must simply provide the same abstraction. Loosely coupled systems do not know the internal workings of the other systems that are part of the architecture. If they did, they would be tightly bound to each other. As an example, imagine a job scheduler service.

Principles of Web API Design: Delivering Value with APIs and Microservices by James Higginbotham

Amazon Web Services, anti-pattern, business intelligence, business logic, business process, Clayton Christensen, cognitive dissonance, cognitive load, collaborative editing, continuous integration, create, read, update, delete, database schema, DevOps, fallacies of distributed computing, fault tolerance, index card, Internet of things, inventory management, Kubernetes, linked data, loose coupling, machine readable, Metcalfe’s law, microservices, recommendation engine, semantic web, side project, single page application, Snapchat, software as a service, SQL injection, web application, WebSocket

Tightly coupled components indicates that the components are very constrained by the implementation details of the other. Loosely coupled components hide the components’ internal details away from others, restricting the knowledge between modules to a public interface, or programming language API, that other areas of the code can invoke. Figure 1.2 demonstrates the concepts of high cohesion and loose coupling within and across modules. Figure 1.2 Loose coupling and high cohesion are fundamentals of modular API design Web APIs extend these concepts by grouping related API operations together for high cohesion, while ensuring that the internal details are encapsulated to encourage a loosely coupled API design.

…

They hide the internal details of programming language, choice of web framework, the classes and objects of a system, and database design behind an HTTP-based API. Internal details, encapsulated behind the API design, encourage a loosely coupled API design that depends upon messages rather than underlying database design and models for communication. No longer does an organization need to understand all the internal implementations details, such as for a payment gateway. Instead, they only need to understand the operations that the API offers and how to use them to achieve the desired outcomes. High Cohesion and Loose Coupling High cohesion is a term used when the code within a module is all closely related to the same functionality.

…

Web API design builds upon these principles of software design, but with a broader audience that extends beyond the team or organization. The scope of communication expands beyond a single team or organization to developers all over the world. Yet, the same principles of software design apply to web-based API design: modularization, encapsulation, loose coupling, and high cohesion. While these may be subjects familiar to most developers, they are fundamental to API design and need review before approaching any API design process. Modularization Modules are the smallest atomic unit within a software program. They are composed of one or more source files that contain classes, methods, or functions.

Early Retirement Extreme by Jacob Lund Fisker

8-hour work day, active transport: walking or cycling, barriers to entry, book value, buy and hold, caloric restriction, caloric restriction, clean water, Community Supported Agriculture, delayed gratification, discounted cash flows, diversification, dogs of the Dow, don't be evil, dumpster diving, Easter island, fake it until you make it, financial engineering, financial independence, game design, index fund, invention of the steam engine, inventory management, junk bonds, lateral thinking, lifestyle creep, loose coupling, low interest rates, market bubble, McMansion, passive income, peak oil, place-making, planned obsolescence, Plato's cave, Ponzi scheme, power law, psychological pricing, retail therapy, risk free rate, sunk-cost fallacy, systems thinking, tacit knowledge, the scientific method, time value of money, Tragedy of the Commons, transaction costs, wage slave, working poor

Hence, employers can make the supply of labor more predictable by only offering full-time jobs, which makes employees unlikely to go home early, and tying in generous benefits, which makes employees unlikely to quit. A loosely coupled system is less likely to fail. Loosely coupled systems have slack. They're flexible and resilient. This means that they function within a range of parameters rather than at just a single value. While slack in the steering of a car is not preferred, it is preferred, for example, in large organizations where tight couplings can lead to bottlenecks if there is only one person in charge of approving a specific form. Personal finance is another area where loose couplings are desired. For instance, a person who bought less house than he could afford is less likely to lose his home if his income drops or the cost of living increases.

…

The purpose of an emergency fund or unemployment insurance is to cover unexpected expenses or lack of income for the amount of time it takes to find another job. An industrial example of a loosely coupled linear system is a mining operation, where miners carry their own rebreathers. Normally, a mine functions like an assembly line, but if one link fails, which would be catastrophic if everybody was hooked up to the same line of oxygen, it doesn't impact the entire line catastrophically. Mining operations are loosely coupled for precisely this reason! The principal financial difference between a salary man and a working man, as defined here, is the amount of fiscal coupling.

…

This is a framework of complexity where a person is skilled in more than just one area. It is, in a way, a contrarian approach to the contemporary idea of "one man-one specialization." It's an interlocking way of arranging one's life. In risk management parlance, one wants to transfer from a tightly coupled linear system of financed consumerism to a loosely coupled, complex system of the financially independent Renaissance man. Naturally, I do not expect everybody to like this philosophy. We typically tend to like philosophies that are already somewhat aligned with our personal values and talents. For example, books like this one, which first tell you that everything about our current society is wrong, and then try to offer an alternative, are mostly a reflection of the author's values rather than an absolute view.

Design Patterns: Elements of Reusable Object-Oriented Software (Joanne Romanovich's Library) by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

A Pattern Language, Donald Knuth, financial engineering, finite state, Ivan Sutherland, L Peter Deutsch, loose coupling, MVC pattern, yield curve

Tight coupling leads to monolithic systems, where you can’t change or remove a class without understanding and changing many other classes. The system becomes a dense mass that’s hard to learn, port, and maintain. Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems. Design patterns: Abstract Factory (87), Bridge (151), Chain of Responsibility (223), Command (233), Facade (185), Mediator (273), Observer (293). 7. Extending functionality by subclassing.

…

Interpreter (243) Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language. Iterator (257) Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Mediator (273) Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Memento (283) Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. Observer (293) Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

…

Interpreter (243) Given a language, define a represention for its grammar along with an interpreter that uses the representation to interpret sentences in the language. Iterator (257) Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Mediator (273) Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. Memento (283) Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. Observer (293) Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Data and the City by Rob Kitchin,Tracey P. Lauriault,Gavin McArdle

A Declaration of the Independence of Cyberspace, algorithmic management, bike sharing, bitcoin, blockchain, Bretton Woods, Chelsea Manning, citizen journalism, Claude Shannon: information theory, clean water, cloud computing, complexity theory, conceptual framework, corporate governance, correlation does not imply causation, create, read, update, delete, crowdsourcing, cryptocurrency, data science, dematerialisation, digital divide, digital map, digital rights, distributed ledger, Evgeny Morozov, fault tolerance, fiat currency, Filter Bubble, floating exchange rates, folksonomy, functional programming, global value chain, Google Earth, Hacker News, hive mind, information security, Internet of things, Kickstarter, knowledge economy, Lewis Mumford, lifelogging, linked data, loose coupling, machine readable, new economy, New Urbanism, Nicholas Carr, nowcasting, open economy, openstreetmap, OSI model, packet switching, pattern recognition, performance metric, place-making, power law, quantum entanglement, RAND corporation, RFID, Richard Florida, ride hailing / ride sharing, semantic web, sentiment analysis, sharing economy, Silicon Valley, Skype, smart cities, Smart Cities: Big Data, Civic Hackers, and the Quest for a New Utopia, smart contracts, smart grid, smart meter, social graph, software studies, statistical model, tacit knowledge, TaskRabbit, technological determinism, technological solutionism, text mining, The Chicago School, The Death and Life of Great American Cities, the long tail, the market place, the medium is the message, the scientific method, Toyota Production System, urban planning, urban sprawl, web application

These services are underpinned by a set of design principles that are based on previous paradigms and practices in software engineering, such as component-based design, interface-based programming and distributed computing. The most widely referenced service orientation principles are loose coupling, abstraction, composability, standardized service contract, reusability, autonomy, statelessness and discoverability (Erl et al. 2013; Barry 2003; Erl et al. 2014) (see Table 10.1). The service orientation principles form Table 10.1 Service orientation principles N Principle Brief explanation 1 Standardized service contract 2 Abstraction 3 Loose coupling Any service must provide a formal contract that describes the service and defines the data exchange details (Amirian et al. 2010a).

…

Services must be decoupled from their surrounding environment. In any software system, coupling is unavoidable. In fact, developers add value by implementing a system use case or a feature by coupling software functionality together. The loose coupling principle is about avoiding platform specific coupling. In other words, this principle means the interaction between services and users must be message-based. The principle of loose coupling is achieved through the use of service contracts that allow services to interact with the outside world via predefined parameters which are defined in the service contract. Sharing and analysing data in smart cities 129 4 Composability 5 Reusability 6 Autonomy 7 Statelessness 8 Discoverability A service can represent any range of logic from any types of resources, including other existing services.

…

They contend Data and the city 7 that such interoperability is best achieved through Service Orientation Principles (SOP) along with a new architecture, Organizational Service Layer, that uses polyglot binding. They detail three core SOP approaches, and their benefits and shortcomings, currently being utilized to share data and analysis (Web Services, RESTful services and Geoservices), as well detailing how four types of bindings can be used to provide loose couplings between backend implementation and other software applications. These bindings enable platform independency and agile and straightforward communication between systems, thus creating accessible, flexible, scalable and interoperable smart city platforms and more easily implementable city data portals, urban control rooms and city dashboards.

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services by Robert Daigneau

Amazon Web Services, business intelligence, business logic, business process, continuous integration, create, read, update, delete, en.wikipedia.org, fault tolerance, loose coupling, machine readable, MITM: man-in-the-middle, MVC pattern, OSI model, pull request, RFC: Request For Comment, Ruby on Rails, software as a service, web application

For situations like these, protocols such as Real Time Streaming Protocol (RTSP, www.ietf.org/rfc/rfc2326.txt), Real Time Transport Protocol (RTP, http:// tools.ietf.org/html/rfc3550), and Real Time Control Protocol (RTCP, http:// tools.ietf.org/html/rfc3605) are usually more appropriate than HTTP. Services and the Promise of Loose Coupling Services are often described as being loosely coupled. However, the definitions for this term are varied and cover a broad array of concerns. Coupling is the degree to which some entity (e.g., client) depends on another entity. When the dependencies are many, the coupling is said to be high or tight (e.g., high coupling, tightly coupled). Conversely, when the dependencies are few, coupling is considered to be low or loose (e.g., low coupling, loosely coupled). It is certainly true that web services can eliminate the client’s dependencies on the underlying technologies used by a service.

…

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 From Local Objects to Distributed Objects . . . . . . . . . . . . . . . . . . . 3 Why Use Web Services? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Web Service Considerations and Alternatives . . . . . . . . . . . . . . . . . . 7 Services and the Promise of Loose Coupling . . . . . . . . . . . . . . . . . . . 9 What about SOA? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 2: Web Service API Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

…

Martin Fowler http://martinfowler.com Foreword by Ian Robinson Distributed application development often starts well. And just as often it ends badly. Point, add web reference, click: That’s the sound of a developer pointing a loaded client at your carefully crafted service interface. By substituting tooling for design, we somehow turned all that loose coupling into plain irresponsible promiscuity; come release time, we all have to join the lockstep jump. In a more cautious era, we’d have just said: “No. Don’t distribute.” And in large part that advice still holds true today. A layer is not a tier. Blowing a threelayered application architecture out to distributed proportions is foolishness writ large, no matter how many open standards you implement.

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith by Sam Newman

Airbnb, business logic, business process, continuous integration, Conway's law, database schema, DevOps, fail fast, fault tolerance, ghettoisation, inventory management, Jeff Bezos, Kubernetes, loose coupling, microservices, MVC pattern, price anchoring, pull request, single page application, single source of truth, software as a service, source of truth, sunk-cost fallacy, systems thinking, telepresence, two-pizza team, work culture

Get into the habit of releasing changes to a single microservice into production without having to deploy anything else. From this, many good things will follow. To guarantee independent deployability, we need to ensure our services are loosely coupled—in other words, we need to be able to change one service without having to change anything else. This means we need explicit, well-defined, and stable contracts between services. Some implementation choices make this difficult—the sharing of databases, for example, is especially problematic. The desire for loosely coupled services with stable interfaces guides our thinking about how we find service boundaries in the first place. Modeled Around a Business Domain Making a change across a process boundary is expensive.

…

However, in my experience, the extra complexity associated with tracking the progress of a saga is almost always outweighed by the benefits associated with having a more loosely coupled architecture. Stepping aside from my own personal tastes, though, the general advice I give regarding orchestration versus choreography is that I am very relaxed in the use of orchestrated sagas when one team owns implementation of the entire saga. In such a situation, the more inherently coupled architecture is much easier to manage within the team boundary. If you have multiple teams involved, I greatly prefer the more decomposed choreographed saga as it is easier to distribute responsibility for implementing the saga to the teams, with the more loosely coupled architecture allowing these teams to work more in isolation.

…

Having to make changes across one or more independently deployable services, perhaps dealing with the impact of breaking changes for service contracts, is likely to be a huge drag. The problem with the monolith is that all too often it is the opposite of both. Rather than tend toward cohesion, and keep things together that tend to change together, we acquire and stick together all sorts of unrelated code. Likewise, loose coupling doesn’t really exist: if I want to make a change to a line of code, I may be able to do that easily enough, but I cannot deploy that change without potentially impacting much of the rest of the monolith, and I’ll certainly have to redeploy the entire system. We also want system stability because our goal, where possible, is to embrace the concept of independent deployability—that is, we’d like to be able to make a change to our service and deploy that service into production without having to change anything else.

The Architecture of Open Source Applications by Amy Brown, Greg Wilson

8-hour work day, anti-pattern, bioinformatics, business logic, c2.com, cloud computing, cognitive load, collaborative editing, combinatorial explosion, computer vision, continuous integration, Conway's law, create, read, update, delete, David Heinemeier Hansson, Debian, domain-specific language, Donald Knuth, en.wikipedia.org, fault tolerance, finite state, Firefox, Free Software Foundation, friendly fire, functional programming, Guido van Rossum, Ken Thompson, linked data, load shedding, locality of reference, loose coupling, Mars Rover, MITM: man-in-the-middle, MVC pattern, One Laptop per Child (OLPC), peer-to-peer, Perl 6, premature optimization, recommendation engine, revision control, Ruby on Rails, side project, Skype, slashdot, social web, speech recognition, the scientific method, The Wisdom of Crowds, web application, WebSocket

Basic execution of remote checkouts and builds has similar design constraints whether the build is being driven locally or remotely; collection of information about the build (success/failure, etc.) is primarily driven by client-side requirements; and tracking information by architecture and result involves the same basic requirements. Thus a basic CI system can be implemented quite easily using the reporting model. We found the loosely coupled model to be very flexible and expandable, as well. Adding new results reporting, notification mechanisms, and build recipes is easy because the components are clearly separated and quite independent. Separated components have clearly delegated tasks to perform, and are also easy to test and easy to modify. The only challenging aspect of remote builds in a CDash-like loosely-coupled model is build coordination: starting and stopping builds, reporting on ongoing builds, and coordinating resource locks between different clients is technically demanding compared to the rest of the implementation.

…

For example, if you wanted to update the message on the status line in Eclipse 3.x, the code would look like: getViewSite().getActionBars().getStatusLineManager().setMessage(msg); Eclipse 3.6 is built from components, but many of these components are too tightly coupled. To assemble applications of more loosely coupled components, Eclipse 4.0 uses dependency injection to provide services to clients. Dependency injection in Eclipse 4.x is through the use of a custom framework that uses the the concept of a context that serves as a generic mechanism to locate services for consumers. The context exists between the application and the framework.

…

The clients independently contain all configuration information and build context, coupled with a lightweight client-side library to help with VCS repository access, build process management, and the communication of results to the server. The reporting server is optional, and contains a simple Web interface, both for reporting on the results of builds and potentially for requesting new builds. In our implementation, the reporting server and results server run in a single multithreaded process but are loosely coupled at the API level and could easily be altered to run independently. This basic model is decorated with a variety of webhooks and RPC mechanisms to facilitate build and change notification and build introspection. For example, rather than tying VCS change notification from the code repository directly into the build system, remote build requests are directed to the reporting system, which communicates them to the results server.

Django Book by Matt Behrens

Benevolent Dictator For Life (BDFL), book value, business logic, create, read, update, delete, database schema, distributed revision control, don't repeat yourself, duck typing, en.wikipedia.org, Firefox, full text search, loose coupling, MITM: man-in-the-middle, MVC pattern, revision control, Ruby on Rails, school choice, slashdot, SQL injection, web application

See the comment in that file for a link to an up-to-date list of worldwide time zone options. URLconfs and Loose Coupling Now’s a good time to highlight a key philosophy behind URLconfs and behind Django in general: the principle of loose coupling. Simply put, loose coupling is a software-development approach that values the importance of making pieces interchangeable. If two pieces of code are loosely coupled, then changes made to one of the pieces will have little or no effect on the other. Django’s URLconfs are a good example of this principle in practice. In a Django Web application, the URL definitions and the view functions they call are loosely coupled; that is, the decision of what the URL should be for a given function, and the implementation of the function itself, reside in two separate places.

…

Simply put, MVC is way of developing software so that the code for defining and accessing data (the model) is separate from request-routing logic (the controller), which in turn is separate from the user interface (the view). (We’ll discuss MVC in more depth in Chapter 5.) A key advantage of such an approach is that components are loosely coupled. Each distinct piece of a Django-powered Web application has a single key purpose and can be changed independently without affecting the other pieces. For example, a developer can change the URL for a given part of the application without affecting the underlying implementation. A designer can change a page’s HTML without having to touch the Python code that renders it.

…

Furthermore, if we wanted to expose the current-date functionality at several URLs, we could easily take care of that by editing the URLconf, without having to touch the view code. In this example, our current_datetime is available at two URLs. It’s a contrived example, but this technique can come in handy: urlpatterns = patterns('', ('^hello/$', hello), ('^time/$', current_datetime), ('^another-time-page/$', current_datetime), ) URLconfs and views are loose coupling in action. We’ll continue to point out examples of this important philosophy throughout this book. Your Third View: Dynamic URLs In our current_datetime view, the contents of the page – the current date/time – were dynamic, but the URL (/time/) was static. In most dynamic Web applications, though, a URL contains parameters that influence the output of the page.

Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design by Diomidis Spinellis, Georgios Gousios

Albert Einstein, barriers to entry, business intelligence, business logic, business process, call centre, continuous integration, corporate governance, database schema, Debian, domain-specific language, don't repeat yourself, Donald Knuth, duck typing, en.wikipedia.org, fail fast, fault tolerance, financial engineering, Firefox, Free Software Foundation, functional programming, general-purpose programming language, higher-order functions, iterative process, linked data, locality of reference, loose coupling, meta-analysis, MVC pattern, Neal Stephenson, no silver bullet, peer-to-peer, premature optimization, recommendation engine, Richard Stallman, Ruby on Rails, semantic web, smart cities, social graph, social web, SPARQL, Steve Jobs, Stewart Brand, Strategic Defense Initiative, systems thinking, the Cathedral and the Bazaar, traveling salesman, Turing complete, type inference, web application, zero-coupon bond

Another major benefit of the unit tests was their remarkable shaping of the code design: they practically enforced good structure. Each small code component was crafted as a well-defined entity that could stand alone, as it had to be constructible in a unit test without requiring the rest of the system to be built up around it. Writing unit tests ensured that each module of code was internally cohesive and loosely coupled from the rest of the system. The unit tests forced careful thought about each unit’s interface, and ensured that the unit’s API was meaningful and internally consistent. Note Unit testing your code leads to better software designs, so design for testability. Time for design One of the contributing factors to Design Town’s success was the allotted development timescale, which was neither too long nor too short (just like Goldilocks’s porridge).

…

The leader must perform all changes to a SelectionKey’s interest set or else you get race conditions with the Selector, so we had to build a queue of pending SelectionKey changes that the leader thread would execute before calling select. Handling these tricky details led to quite a bit more coupling between the various objects than I initially expected. If we had been building a framework, this whole area would have needed much more attention to loose coupling. For an application, however, we felt it was acceptable to regard the collection of collaborating objects in the server as a cohesive unit. One particularly interesting effect showed up only when we ran a packet sniffer to see if we were really getting the maximum possible throughput. We weren’t.

…

The second advances the art and is a fine implementation strategy, but does not quite live up to the interoperability hype that has hounded it from the beginning. It complicates even simple interactions because its processes are influenced by the goal of solving larger interaction problems. The doc/lit style allows us to define a request in a structured package that can be forwarded on, amended, processed, and reprocessed by the loosely coupled participants in a workflow. Like an itinerant pearl, this message accretes elements and attributes as it is handled by intermediaries and endpoints in a potentially asynchronous style. We achieve horizontal scalability by throwing ever more message handlers at a tier. We can standardize interaction styles across partner and industry boundaries and business processes that cannot be contained by a single context.

Code Complete (Developer Best Practices) by Steve McConnell

Ada Lovelace, Albert Einstein, Buckminster Fuller, business logic, call centre, classic study, continuous integration, data acquisition, database schema, don't repeat yourself, Donald Knuth, fault tolerance, General Magic , global macro, Grace Hopper, haute cuisine, if you see hoof prints, think horses—not zebras, index card, inventory management, iterative process, Larry Wall, loose coupling, Menlo Park, no silver bullet, off-by-one error, Perl 6, place-making, premature optimization, revision control, Sapir-Whorf hypothesis, seminal paper, slashdot, sorting algorithm, SQL injection, statistical model, Tacoma Narrows Bridge, the Cathedral and the Bazaar, the scientific method, Thomas Kuhn: the structure of scientific revolutions, Turing machine, web application

Ease of maintenance. Ease of maintenance means designing for the maintenance programmer. Continually imagine the questions a maintenance programmer would ask about the code you're writing. Think of the maintenance programmer as your audience, and then design the system to be self-explanatory. Loose coupling. Loose coupling means designing so that you hold connections among different parts of a program to a minimum. Use the principles of good abstractions in class interfaces, encapsulation, and information hiding to design classes with as few interconnections as possible. Minimal connectedness minimizes work during integration, testing, and maintenance.

…

By identifying the core first, you can see which components are really add-ons and then extrapolate and hide improvements from there. Further Reading This discussion draws on the approach described in "On the design and development of program families" (Parnas 1976). Keep Coupling Loose Coupling describes how tightly a class or routine is related to other classes or routines. The goal is to create classes and routines with small, direct, visible, and flexible relations to other classes and routines, which is known as "loose coupling." The concept of coupling applies equally to classes and routines, so for the rest of this discussion I'll use the word "module" to refer to both classes and routines. Good coupling between modules is loose enough that one module can easily be used by other modules.

…

Size refers to the number of connections between modules. With coupling, small is beautiful because it's less work to connect other modules to a module that has a smaller interface. A routine that takes one parameter is more loosely coupled to modules that call it than a routine that takes six parameters. A class with four well-defined public methods is more loosely coupled to modules that use it than a class that exposes 37 public methods. Visibility. Visibility refers to the prominence of the connection between two modules. Programming is not like being in the CIA; you don't get credit for being sneaky.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann

active measures, Amazon Web Services, billion-dollar mistake, bitcoin, blockchain, business intelligence, business logic, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, data science, database schema, deep learning, DevOps, distributed ledger, Donald Knuth, Edward Snowden, end-to-end encryption, Ethereum, ethereum blockchain, exponential backoff, fake news, fault tolerance, finite state, Flash crash, Free Software Foundation, full text search, functional programming, general-purpose programming language, Hacker News, informal economy, information retrieval, Internet of things, iterative process, John von Neumann, Ken Thompson, Kubernetes, Large Hadron Collider, level 1 cache, loose coupling, machine readable, machine translation, Marc Andreessen, microservices, natural language processing, Network effects, no silver bullet, operational security, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, self-driving car, semantic web, Shoshana Zuboff, social graph, social web, software as a service, software is eating the world, sorting algorithm, source of truth, SPARQL, speech recognition, SQL injection, statistical model, surveillance capitalism, systematic bias, systems thinking, Tragedy of the Commons, undersea cable, web application, WebSocket, wikimedia commons

Gifford: “Information Storage in a Decentralized Computer System,” Xerox Palo Alto Research Centers, CSL-81-8, June 1981. [9] Martin Kleppmann: “Please Stop Calling Databases CP or AP,” martin.klepp‐ mann.com, May 11, 2015. [10] Kyle Kingsbury: “Call Me Maybe: MongoDB Stale Reads,” aphyr.com, April 20, 2015. [11] Kyle Kingsbury: “Computational Techniques in Knossos,” aphyr.com, May 17, 2014. [12] Peter Bailis: “Linearizability Versus Serializability,” bailis.org, September 24, 2014. [13] Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman: Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. ISBN: 978-0-201-10715-9, available online at research.microsoft.com. [14] Mike Burrows: “The Chubby Lock Service for Loosely-Coupled Distributed Sys‐ tems,” at 7th USENIX Symposium on Operating System Design and Implementation (OSDI), November 2006. [15] Flavio P. Junqueira and Benjamin Reed: ZooKeeper: Distributed Process Coordi‐ nation. O’Reilly Media, 2013. ISBN: 978-1-449-36130-3 [16] “etcd 2.0.12 Documentation,” CoreOS, Inc., 2015. 376 | Chapter 9: Consistency and Consensus [17] “Apache Curator,” Apache Software Foundation, curator.apache.org, 2015. [18] Morali Vallath: Oracle 10g RAC Grid, Services & Clustering.

…

A program can still read and write files directly if it needs to, but the Unix approach works best if a program doesn’t worry about particular file paths and simply uses stdin and stdout. This allows a shell user to wire up the input and output in what‐ ever way they want; the program doesn’t know or care where the input is coming from and where the output is going to. (One could say this is a form of loose coupling, late binding [15], or inversion of control [16].) Separating the input/output wiring from the program logic makes it easier to compose small tools into bigger systems. You can even write your own programs and combine them with the tools provided by the operating system. Your program just needs to read input from stdin and write output to stdout, and it can participate in data processing pipelines.

…

This setup is reasonable if the output from the first job is a dataset that you want to publish widely within your organization. In that case, you need to be able to refer to it Beyond MapReduce | 419 by name and reuse it as input to several different jobs (including jobs developed by other teams). Publishing data to a well-known location in the distributed filesystem allows loose coupling so that jobs don’t need to know who is producing their input or consuming their output (see “Separation of logic and wiring” on page 396). However, in many cases, you know that the output of one job is only ever used as input to one other job, which is maintained by the same team. In this case, the files on the distributed filesystem are simply intermediate state: a means of passing data from one job to the next.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann

active measures, Amazon Web Services, billion-dollar mistake, bitcoin, blockchain, business intelligence, business logic, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, data science, database schema, deep learning, DevOps, distributed ledger, Donald Knuth, Edward Snowden, end-to-end encryption, Ethereum, ethereum blockchain, exponential backoff, fake news, fault tolerance, finite state, Flash crash, Free Software Foundation, full text search, functional programming, general-purpose programming language, Hacker News, informal economy, information retrieval, Infrastructure as a Service, Internet of things, iterative process, John von Neumann, Ken Thompson, Kubernetes, Large Hadron Collider, level 1 cache, loose coupling, machine readable, machine translation, Marc Andreessen, microservices, natural language processing, Network effects, no silver bullet, operational security, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, self-driving car, semantic web, Shoshana Zuboff, social graph, social web, software as a service, software is eating the world, sorting algorithm, source of truth, SPARQL, speech recognition, SQL injection, statistical model, surveillance capitalism, systematic bias, systems thinking, Tragedy of the Commons, undersea cable, web application, WebSocket, wikimedia commons

[12] Peter Bailis: “Linearizability Versus Serializability,” bailis.org, September 24, 2014. [13] Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman: Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. ISBN: 978-0-201-10715-9, available online at research.microsoft.com. [14] Mike Burrows: “The Chubby Lock Service for Loosely-Coupled Distributed Systems,” at 7th USENIX Symposium on Operating System Design and Implementation (OSDI), November 2006. [15] Flavio P. Junqueira and Benjamin Reed: ZooKeeper: Distributed Process Coordination. O’Reilly Media, 2013. ISBN: 978-1-449-36130-3 [16] “etcd 2.0.12 Documentation,” CoreOS, Inc., 2015

…

A program can still read and write files directly if it needs to, but the Unix approach works best if a program doesn’t worry about particular file paths and simply uses stdin and stdout. This allows a shell user to wire up the input and output in whatever way they want; the program doesn’t know or care where the input is coming from and where the output is going to. (One could say this is a form of loose coupling, late binding [15], or inversion of control [16].) Separating the input/output wiring from the program logic makes it easier to compose small tools into bigger systems. You can even write your own programs and combine them with the tools provided by the operating system. Your program just needs to read input from stdin and write output to stdout, and it can participate in data processing pipelines.

…

This setup is reasonable if the output from the first job is a dataset that you want to publish widely within your organization. In that case, you need to be able to refer to it by name and reuse it as input to several different jobs (including jobs developed by other teams). Publishing data to a well-known location in the distributed filesystem allows loose coupling so that jobs don’t need to know who is producing their input or consuming their output (see “Separation of logic and wiring”). However, in many cases, you know that the output of one job is only ever used as input to one other job, which is maintained by the same team. In this case, the files on the distributed filesystem are simply intermediate state: a means of passing data from one job to the next.

A Demon of Our Own Design: Markets, Hedge Funds, and the Perils of Financial Innovation by Richard Bookstaber

affirmative action, Albert Einstein, asset allocation, backtesting, beat the dealer, behavioural economics, Black Swan, Black-Scholes formula, Bonfire of the Vanities, book value, butterfly effect, commoditize, commodity trading advisor, computer age, computerized trading, disintermediation, diversification, double entry bookkeeping, Edward Lorenz: Chaos theory, Edward Thorp, family office, financial engineering, financial innovation, fixed income, frictionless, frictionless market, Future Shock, George Akerlof, global macro, implied volatility, index arbitrage, intangible asset, Jeff Bezos, Jim Simons, John Meriwether, junk bonds, London Interbank Offered Rate, Long Term Capital Management, loose coupling, managed futures, margin call, market bubble, market design, Mary Meeker, merger arbitrage, Mexican peso crisis / tequila crisis, moral hazard, Myron Scholes, new economy, Nick Leeson, oil shock, Paul Samuelson, Pierre-Simon Laplace, proprietary trading, quantitative trading / quantitative finance, random walk, Renaissance Technologies, risk tolerance, risk/return, Robert Shiller, Robert Solow, rolodex, Saturday Night Live, selection bias, shareholder value, short selling, Silicon Valley, statistical arbitrage, tail risk, The Market for Lemons, time value of money, too big to fail, transaction costs, tulip mania, uranium enrichment, UUNET, William Langewiesche, yield curve, zero-coupon bond, zero-sum game

TIGHT COUPLING AND INTERACTIVE COMPLEXITY: AN X-RATED BEHAVIOR The greatest dangers arise when there is both interactive complexity and a tightly coupled system that does not provide the time to intervene. Tightly coupled systems are not limited to the sphere of rocket launches and industrial processes. A task as simple as making bread is tightly coupled; as the ingredients are mixed and the yeast is added, the timing and steps must follow in a fairly precise and controlled manner. Whereas a loosely coupled system provides time to improvise and come up with solutions, a tightly coupled system must be run and managed by the book. Simply put, a tightly coupled system provides no slack, in terms of either the time between steps, the ability to make on-the-fly alterations, or the opportunity to intervene.

…

Interactively complex systems require a decentralized approach that provides for creativity at the operator level in dealing with unanticipated failures. If a system is both interactively complex and tightly coupled, management is faced with a dilemma; neither centralized, codified management nor decentralized, adaptive management will work. A university is an example of an organization that is interactively complex but loosely coupled. It has many departments, each with a curriculum and a faculty that are only loosely controlled by the central administration. Students straddle across these departments, devising their own course schedules and activities. To graduate, a student navigates courses in the various departments based on a set of requirements dictated by the university.

…

There is plenty of time for a review of the requirements, for appeals for cases where a prerequisite is not offered, and for consideration of alternative classes or even new majors. There are makeshift approaches for dealing with missed classes or exams. Put another way, there is plenty of slack in the system (not to mention many slackers). Another example of a system that is complex but sheltered from catastrophic failure thanks to loose coupling is the hub-and-spoke system for airlines. This is a system that in theory adds efficiency, but in practice has become a questionable approach because of the feedback that propagates unavoidable failures. (I am referring to airline scheduling, not airline safety.) But there are plenty of options available and time to consider them—though that often leaves you cooling your heels in Atlanta.

The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion by John Hagel Iii, John Seely Brown

Albert Einstein, Andrew Keen, barriers to entry, Black Swan, business process, call centre, Clayton Christensen, clean tech, cloud computing, commoditize, corporate governance, creative destruction, disruptive innovation, Elon Musk, en.wikipedia.org, future of work, game design, George Gilder, intangible asset, Isaac Newton, job satisfaction, Joi Ito, knowledge economy, knowledge worker, loose coupling, Louis Pasteur, Malcom McLean invented shipping containers, Marc Benioff, Maui Hawaii, medical residency, Network effects, old-boy network, packet switching, pattern recognition, peer-to-peer, pre–internet, profit motive, recommendation engine, Ronald Coase, Salesforce, shareholder value, Silicon Valley, Skype, smart transportation, software as a service, supply-chain management, tacit knowledge, The Nature of the Firm, the new new thing, the strength of weak ties, too big to fail, trade liberalization, transaction costs, TSMC, Yochai Benkler

Most companies in fact spend considerable effort trying to eliminate exceptions—such as when an order bounces out of an automated order processing system because of a customer request for unusual financing terms, or for shipment of the order using an unanticipated delivery method. In pull platforms, the modules are designed to be loosely coupled, with interfaces that help users to understand what the module contains and how it can be accessed. Because of this loosely coupled modular design, pull platforms can accommodate a much larger number of diverse participants. In fact, pull platforms tend to have increasing returns dynamics—the more participants and modules the platform can attract, the more valuable the platform becomes.

…

Founded twenty-five years ago by a group of former IBM engineers, SAP has grown to become the fourth-largest software company in the world, creating the big company-wide software applications that today’s firms use to run most of what they do. The software industry started to go through a wrenching change earlier in this decade as it moved from large, complex, tightly integrated application software to much more loosely coupled modules of software embedded in service-oriented architectures. To its credit, SAP, whose success had been driven by the previous generation of software, embraced this next wave of software architecture, introducing its NetWeaver platform in early 2003—a nifty piece of software that fit on top of and around its existing enterprise applications, helping them talk to each other and to non-SAP applications.

…

She might help to shape this future by the actions she takes in the context of her product-development effort. She might start by defining an alternative view of how product-development efforts might be organized in the next couple of decades. This view might anticipate that products will be increasingly modularized and loosely coupled to encourage more active participation by customers and by component and subsystem providers in the product-development process. She could evangelize this view both within her company and with relevant potential participants in a product-development ecosystem. To support this view, she might create a leveraged product-development platform consisting of a collaborative workspace and various forms of design and analytical tools that accommodated participants from the outside who could contribute to the development of specific modules of the product.

Python Web Development With Django by Jeff Forcier

business logic, create, read, update, delete, database schema, Debian, don't repeat yourself, duck typing, en.wikipedia.org, Firefox, full text search, functional programming, Guido van Rossum, loose coupling, MVC pattern, revision control, Ruby on Rails, Silicon Valley, slashdot, SQL injection, web application

—Wesley Chun ❖ Table of Contents Introduction 1 Where Web Frameworks Come From 1 A Better Way 2 We’re Not in Kansas Anymore 2 Web Development Is Better with Python and Django 3 I: Getting Started 1 Practical Python for Django Python Skills Are Django Skills Getting Started: Python’s Interactive Interpreter Python Basics 7 7 8 10 Comments 10 Variables and Assignment 10 Operators Python Standard Types 11 11 Object Boolean Values 12 Numbers 12 Numeric Operators 13 Numeric Built-in and Factory Functions 14 Sequences and Iterables 14 Lists 17 Strings 19 Sequence Built-ins and Factory Functions 25 Mapping Type: Dictionaries 26 Standard Type Summary 28 Flow Control 28 Conditionals 29 Loops 29 Exception Handling 30 The finally Clause 31 Throwing Exceptions with raise 32 Files 33 Functions 34 Declaring and Calling Functions 34 Functions Are First-Class Objects 36 Anonymous Functions 38 *args and **kwargs 40 Decorators 42 Object-Oriented Programming 44 Class Definitions 44 Instantiation 45 Subclassing 46 Inner Classes 46 Regular Expressions 47 The re module 47 Searching Versus Matching 48 Common Gotchas 48 Single-Item Tuples 48 Modules 48 Mutability 50 Constructor Versus Initializer 52 Coding Style (PEP 8 and Beyond) 53 Indent Four Spaces 53 Use Spaces and Not Tabs 53 Don’t Write Single-Line Suites on the Same Line as the Header 54 Create Documentation Strings (aka “docstrings”) 54 Summary 2 Django for the Impatient: Building a Blog 55 57 Creating the Project 58 Running the Development Server 59 Creating the Blog Application 61 Designing Your Model 62 Setting Up the Database 62 Using a Database Server 63 Using SQLite 63 Creating the Tables Setting Up the Automatic admin Application 64 65 Trying Out the admin 66 Making Your Blog’s Public Side 70 Creating a Template 70 Creating a View Function 71 Creating a URL Pattern Finishing Touches 72 73 Template Niceties 73 Date-Based Ordering 74 Timestamp Formatting Via a Template Filter 75 Summary 75 3 Starting Out 77 Dynamic Web Site Basics 77 Communication: HTTP, URLs, Requests, Responses 78 Data Storage: SQL and Relational Databases 78 Presentation: Rendering Templates into HTML and Other Formats 79 Putting It All Together 79 Understanding Models, Views, and Templates 79 Separating the Layers (MVC) 79 Models 80 Views 81 Templates 81 Overall Django Architecture Core Philosophies of Django 82 82 Django Tries to Be Pythonic 84 Don’t Repeat Yourself (DRY) 84 Loose Coupling and Flexibility 84 Rapid Development 85 Summary 86 II: Django in Depth 4 Defining and Using Models Defining Models Why Use an ORM? 89 89 89 Django’s Rich Field Types 91 Relationships Between Models 93 Model Inheritance 97 Meta Inner Class 100 Admin Registration and Options 101 Using Models 102 Creating and Updating Your Database Using manage.py 103 Query Syntax 104 Utilizing SQL Features Django Doesn’t Provide 112 Summary 5 URLs, HTTP Mechanisms, and Views URLs Introduction to URLconfs 116 117 117 117 Replacing Tuples with url 119 Using Multiple patterns Objects 119 Including Other URL Files with include 120 Function Objects Versus Function-Name Strings 121 Modeling HTTP: Requests, Responses, and Middleware 122 Request Objects 123 Response Objects 125 Middleware 126 Views/Logic 127 Just Python Functions 128 Generic Views 128 Semi-generic Views 130 Custom Views 131 Summary 133 6 Templates and Form Processing Templates 135 135 Understanding Contexts 135 Template Language Syntax 136 Forms Defining Forms 142 142 Filling Out Forms 147 Validation and Cleaning 149 Form Display 150 Widgets 152 Summary 154 III: Django Applications by Example 7 Photo Gallery 159 The Model 160 Preparing for File Uploads 161 Installing PIL 162 Testing ImageField 163 Building Our Custom File Field 164 Initialization 166 Adding Attributes to the Field 167 Saving and Deleting the Thumbnail 168 Using ThumbnailImageField 169 Setting Up DRY URLs 169 The Item App’s URL Layout 172 Tying It All Together with Templates 173 Summary 179 8 Content Management System 181 What’s a CMS?

…

You want to write your code in a real programming language; one that is powerful, clean, mature, and extensively documented.You want it to have a great standard library and a huge selection of high-quality third-party packages for whatever needs arise, from generating a CSV or a pie chart to scientific computations or image file processing. You want a framework that has a vibrant, helpful community of users and developers; one that is designed to function smoothly as an integrated stack, but whose components are loosely coupled, so you can make substitutions if circumstances require. In short, you want Python, and you want Django.We wrote this book to help you learn and use Django in real-world settings as easily, quickly, and smartly as possible. We’re Not in Kansas Anymore Django was originally written by Adrian Holovaty and Simon Willison at World Online, the Web arm of a family-owned media company in Lawrence, Kansas.

…

Although DRY can be easy to apply to simple situations such as the previous example, it’s also one of the hardest commandments to adhere to strictly all the time; there are many places where it conflicts with other idioms, Pythonic and otherwise, where tradeoffs must be made. However, it is a worthy goal to strive toward and one which becomes easier with experience. Loose Coupling and Flexibility Django is a full-stack Web framework in the sense it provides all necessary components for a dynamic Web application: database access, request framework, application logic, templating, and so forth. However, an effort has been made to ensure that users’ options are Core Philosophies of Django left open: You can use as much or as little of Django as you need and can replace components with other tools as you see fit.

Erlang Programming by Francesco Cesarini

cloud computing, fault tolerance, finite state, functional programming, higher-order functions, loose coupling, revision control, RFC: Request For Comment, social bookmarking, sorting algorithm, Turing test, type inference, web application

With both operating systems, you can otherwise move to the directory by using the cd(Directory) command in the Erlang shell. Once in the directory, you compile the code using c(Module) in the Erlang shell, omitting the erl suffix from the module name. If the code contained no errors, the compilation will succeed. Large Erlang systems consist of loosely coupled Erlang modules, all compiled on a standalone basis. Once you have compiled your code, look at the source code directory and you will find a file with the same name as the module, but with the .beam suffix. This file contains the byte code that you can call from any other function. The .beam suffix stands for Björn’s Erlang Abstract Machine, an abstract machine on which the compiled code runs.

…

A service can be specific, such as the storage provided by a distributed filesystem or database, or more general, as in a distributed operating system that provides all the facilities of a general-purpose OS across a network of computers. Distribution can be seen in tightly coupled parallel processors, but more clearly in the loosely coupled grids of e-science systems. Erlang provides distributed programming facilities so that Erlang systems can be run across networked Erlang nodes. Take an installation of Ejabberd, an Erlang open source Jabber-based instant messaging (IM) server. Its implementation is distributed across a cluster of two or more Erlang nodes.

…

Supervisors, denoted in illustrations as squares, monitor their children, both workers and other supervisors, creating what is called a supervision tree (see Figure 12-1). Supervision trees are packaged into a behavior called an application. OTP applications not only are the building blocks of Erlang systems, but also are a way to package reusable components. Industrial-grade systems consist of a set of loosely coupled, possibly distributed applications. These applications are part of the standard Erlang distribution or are specific applications developed by you, the programmer. Do not confuse OTP applications with the more general concept of an application, which usually refers to a more complete system that solves a high-level task.

Real-World Kanban by Mattias Skarin

call centre, continuous integration, Great Leap Forward, Kanban, loose coupling, pull request

. • Reduce total costs, not just IT costs. Fast feedback Adapt your products to make them fit for your purpose by learning quickly through continuous feedback. Decision speed Keep up with market pace by detecting weak signals and doing something about them. Modular design Employ product design using loosely coupled modules. Experimental culture Shift culture from "No, it’s not the way we do it around here" to "Cool, how can we find out whether it works?" using small experiments. It starts with your management team. I have met people who push the above buttons either intuitively or out of experience. The trouble with intuition is that it’s not transferable or teachable.

…

report erratum • discuss Improve the Organization with Long-Term Thinking • 19 Adopt Modular Design We can do several things to build flexibility into our technology. One thing we can do to both give us a faster time to market and reduce the number of late surprises is to modularize our products with loosely coupled dependencies. Modularizing products can help you simplify them by clarifying the exact purpose and function of each module. It allows you to control your dependencies instead of being controlled by them. It helps reduce the ripple effect. As you can see in the following figure, a small change in a product with unknown or hard dependencies can quickly ripple through the architecture.

Extreme Teams: Why Pixar, Netflix, AirBnB, and Other Cutting-Edge Companies Succeed Where Most Fail by Robert Bruce Shaw, James Foster, Brilliance Audio

Airbnb, augmented reality, benefit corporation, Blitzscaling, call centre, cloud computing, data science, deliberate practice, Elon Musk, emotional labour, financial engineering, future of work, holacracy, inventory management, Jeff Bezos, job satisfaction, Jony Ive, karōshi / gwarosa / guolaosi, loose coupling, meta-analysis, nuclear winter, Paul Graham, peer-to-peer, peer-to-peer model, performance metric, Peter Thiel, sharing economy, Sheryl Sandberg, Silicon Valley, social intelligence, SoftBank, Steve Jobs, TED Talk, Tony Fadell, Tony Hsieh, work culture

Creating the right context supports how Netflix wants to operate in what it calls a highly aligned but loosely coupled organization. The company insists that people be in agreement about the environment in which they operate and their overall goals but have the freedom to do what is needed for them and the company to be successful.16 Netflix describes this as follows: Highly Aligned means. . . . Strategy and goals are clear, specific, and broadly understood Team interactions are focused on strategy and goals, rather than tactics Large investment in management time required to be transparent, articulate, and perceptive Loosely Coupled means . . . Minimal cross-functional meetings except to get aligned on goals and strategy Trust between groups on tactics without previewing/approving each one—so groups can move fast Leaders reaching out proactively for ad-hoc coordination and perspective as appropriate—occasional post-mortems on tactics necessary to increase alignment17 The emphasis on setting context in Netflix was born of a near-death experience.

…

Herrin, Jessica, on hiring highly aligned hiring process at Airbnb cultural fit in at Pixar at Zappos holacracy Holbrook, Richard, on conflict House of Cards (television show) Housman, Michael Hsieh, Tony on culture on customer service as founder of Zappos influence of, at Zappos ideas conflict about generation of IDEO incremental innovation ingroups innovation at Airbnb at Google incremental at Netflix at Whole Foods Inside Out (film) internal competition Ives, Jony, on results vs. relationships Jobs, Steve communal culture created by as founder of Pixar legacy of on results Kahn, Matthew, on military desertion karoshi Lasseter, John on Disney Animation and Pixar as founder of Pixar on supporting employees loosely coupled loyalty, to teams Ma, Jack on culture on ethics on finding right people as founder of Alibaba leadership of on obsession on playful culture Mackey, John Appalachian Trail hiked by on building teams as founder of Whole Foods on teams on transparency Maner, Jon Mayer, Marissa, on priorities McCord, Patty, on performance measurement Mead, Margaret, on change men, expectations for Michaud, Jon Microsoft military loyalty Minor, Dylan missions, non-financial Motorola Musk, Elon, as visionary leader Musk, Justine NASA Nemeth, Charlie Nest Labs Netflix accountability at autonomous culture at changing priorities at context setting at cultural fit at culture at experimentation with priorities at future of incremental innovation at personnel management by relationships and results at self-imposed limitations on transparency at Net Promoter Score (metric) New York Times Nike Notes, at Pixar obsession benefits and risks of in building teams as characteristic of extreme teams characteristics of companies with with culture definition of and grit at Patagonia at Pixar risks of with societal impact of company as team vs. personal trait with work at Zappos Onward (Howard Schultz) origins stories, of companies outcomes, for key priorities Patagonia “all in” culture at cultural fit at culture at ingroups at obsession at relationships at self-imposed limitations on shift to organic cotton at Perez, William performance metrics for evaluation of teams for individuals and teams at Zappos Personal Emotional Connection (metric) personal trait, obsession as personnel management at Nest Labs at Netflix at Pixar Pixar collaboration at communal culture at conflict at cultural fit determined at culture at Disney Animation under leadership of emotional support at experimentation with priorities at future-forward focus of hiring process at obsession at performance evaluation at personnel management by teams at work reviewed at playful culture plussing postmortems, at Pixar power issues priorities at Airbnb in building teams as characteristic of extreme teams context setting for development of priorities, (cont.)

Social Life of Information by John Seely Brown, Paul Duguid

Alvin Toffler, business process, Charles Babbage, Claude Shannon: information theory, computer age, Computing Machinery and Intelligence, cross-subsidies, disintermediation, double entry bookkeeping, Frank Gehry, frictionless, frictionless market, future of work, George Gilder, George Santayana, global village, Goodhart's law, Howard Rheingold, informal economy, information retrieval, invisible hand, Isaac Newton, John Markoff, John Perry Barlow, junk bonds, Just-in-time delivery, Kenneth Arrow, Kevin Kelly, knowledge economy, knowledge worker, lateral thinking, loose coupling, Marshall McLuhan, medical malpractice, Michael Milken, moral hazard, Network effects, new economy, Productivity paradox, Robert Metcalfe, rolodex, Ronald Coase, scientific management, shareholder value, Shoshana Zuboff, Silicon Valley, Steve Jobs, Superbowl ad, tacit knowledge, Ted Nelson, telepresence, the medium is the message, The Nature of the Firm, the strength of weak ties, The Wealth of Nations by Adam Smith, Thomas Malthus, transaction costs, Turing test, Vannevar Bush, Y2K

It always risks, however, binding people too tightly to process, cutting them off from Page 115 their ''lateral" resources, blinding the organization to improvisation and new ideas, which may enter organizations along the lines of these peer groups. Practice suffers from the opposing dangerof allowing itself to evolve too independently and so become too loosely "coupled" to the organization. The balancing act, as we shall see, requires developing coupling loose enough to allow groups to develop their own new knowledge, but tight enough to be able to push that knowledge along the lines of process. The idea that all that matters here is information woefully underestimates the challenges involved, which are ultimately, as we shall see, challenges of organization, knowledge, and innovation.

…

Information can travel across vast networks with great speed and to large numbers but nonetheless be assimilated in much the same way by whomever receives it. By contrast, there is relatively little reciprocity across such network; that is, network members don't interact with one another directly to any significant degree. When reach dominates reciprocity like this, it produces very loosely coupled systems.39 Collectively, such social systems don't take action and produce little knowledge. They can, though, share information relating to the members' common practices quite efficiently. Communities of Practice Lave and Wenger's notion of communities of practice, which we mentioned earlier, focuses on subsections of these larger networks Page 143 of practice.

…

The Information Society 12: 343 63. Ward, Mark. 1998. "Wired for Mayhem." New Scientist [Online] 159 July). Available: http://www.newscientist.com/ns/980704/nwired.html. Warnock, Mary. 1960. Ethics since 1900. London: Methuen Books. Weick, Karl E. 1976. "Educational Organizations as Loosely Coupled Systems." Administrative Science Quarterly 21: 1 19. Wellman, Barry. 1988. "The Community Question Reevaluated." In Power, Community, and the City, edited by Michael Peter Smith, 81 107. New Brunswick, NJ: Transaction Books. Wells, H. G. 1902. Anticipations of the Reaction of Mechanical and Scientific Progress upon Human Life and Thought.

Other People's Money: Masters of the Universe or Servants of the People? by John Kay

Affordable Care Act / Obamacare, Alan Greenspan, asset-backed security, bank run, banking crisis, Basel III, Bear Stearns, behavioural economics, Bernie Madoff, Big bang: deregulation of the City of London, bitcoin, Black Monday: stock market crash in 1987, Black Swan, Bonfire of the Vanities, bonus culture, book value, Bretton Woods, buy and hold, call centre, capital asset pricing model, Capital in the Twenty-First Century by Thomas Piketty, cognitive dissonance, Cornelius Vanderbilt, corporate governance, Credit Default Swap, cross-subsidies, currency risk, dematerialisation, disinformation, disruptive innovation, diversification, diversified portfolio, Edward Lloyd's coffeehouse, Elon Musk, Eugene Fama: efficient market hypothesis, eurozone crisis, financial engineering, financial innovation, financial intermediation, financial thriller, fixed income, Flash crash, forward guidance, Fractional reserve banking, full employment, George Akerlof, German hyperinflation, Glass-Steagall Act, Goldman Sachs: Vampire Squid, Greenspan put, Growth in a Time of Debt, Ida Tarbell, income inequality, index fund, inflation targeting, information asymmetry, intangible asset, interest rate derivative, interest rate swap, invention of the wheel, Irish property bubble, Isaac Newton, it is difficult to get a man to understand something, when his salary depends on his not understanding it, James Carville said: "I would like to be reincarnated as the bond market. You can intimidate everybody.", Jim Simons, John Meriwether, junk bonds, light touch regulation, London Whale, Long Term Capital Management, loose coupling, low cost airline, M-Pesa, market design, Mary Meeker, megaproject, Michael Milken, millennium bug, mittelstand, Money creation, money market fund, moral hazard, mortgage debt, Myron Scholes, NetJets, new economy, Nick Leeson, Northern Rock, obamacare, Occupy movement, offshore financial centre, oil shock, passive investing, Paul Samuelson, Paul Volcker talking about ATMs, peer-to-peer lending, performance metric, Peter Thiel, Piper Alpha, Ponzi scheme, price mechanism, proprietary trading, purchasing power parity, quantitative easing, quantitative trading / quantitative finance, railway mania, Ralph Waldo Emerson, random walk, reality distortion field, regulatory arbitrage, Renaissance Technologies, rent control, risk free rate, risk tolerance, road to serfdom, Robert Shiller, Ronald Reagan, Schrödinger's Cat, seminal paper, shareholder value, Silicon Valley, Simon Kuznets, South Sea Bubble, sovereign wealth fund, Spread Networks laid a new fibre optics cable between New York and Chicago, Steve Jobs, Steve Wozniak, The Great Moderation, The Market for Lemons, the market place, The Myth of the Rational Market, the payments system, The Wealth of Nations by Adam Smith, The Wisdom of Crowds, Tobin tax, too big to fail, transaction costs, tulip mania, Upton Sinclair, Vanguard fund, vertical integration, Washington Consensus, We are the 99%, Yom Kippur War

Paradoxically, attempts to increase resilience by incorporating many layers of safety provision may make the system less robust by increasing its complexity. An assembly line is complex but not interactively complex – it depends on a linear sequence of events in which each step logically follows the preceding one. Such a process may be tightly or loosely coupled. The moving belt of the traditional car plant’s assembly line demonstrates tight coupling, while the normally leisurely production of a book from manuscript to publication is loosely coupled: no one is surprised at the author’s late delivery, nor is the production process upset. Robust systems are typically linear. From time to time I send a parcel via UPS to our house in France. Through the company’s tracking system I can follow the movements of the package.

…

The UPS delivery system, although complex, is linear rather than interactive in its complexity, and loosely coupled. When on one occasion a parcel failed to arrive, it was easy and quick to establish that the consignment had left Paris but not arrived in Nice and then to discover that a heavy snowfall in central France had blocked the Autoroute du Soleil. When the drifts and stranded vehicles were cleared, the package reached Lyons two days later and agents adapted to delayed delivery. The linearity of the system permitted rapid identification and isolation of the problem; the loose coupling permitted rapid recovery. A similarly linear financial system is one in which intermediaries deal with end-users rather than each other.

Heat Wave: A Social Autopsy of Disaster in Chicago by Eric Klinenberg

carbon footprint, citizen journalism, classic study, deindustrialization, digital rights, fixed income, gentrification, ghettoisation, informal economy, Intergovernmental Panel on Climate Change (IPCC), Jane Jacobs, longitudinal study, loose coupling, mass immigration, megacity, New Urbanism, Oklahoma City bombing, postindustrial economy, smart grid, smart meter, social distancing, The Chicago School, The Death and Life of Great American Cities, The Structural Transformation of the Public Sphere, urban renewal, War on Poverty

In Normal Accidents, sociologist Charles Perrow (1984, 4, 9) documents the risks of tight coupling in organizations that use advanced technology to produce hazardous materials, since the complex chains of causality make it difficult to predict the impact of any particular problem. Political organizations, which often have to react to crises, often suffer from the opposite problem, because loose coupling slows their responsiveness. Karl Weick has made the most comprehensive assessments of the organizational problems stemming from loose coupling. For a relatively recent reconceptualization of the loose coupling literature, see Orton and Weick (1990). 27. In the 1990s a number of structural changes altered the conditions for city service delivery. While cuts in federal social support and public assistance programs and the declining political power of cities left urban centers like Chicago with meager resources for addressing concentrated and advancing poverty and deprivation (Jargowsky 1997; Wacquant 1996; Weir 1998), the professionalization of city government workers and the importation of flexible managerial strategies from the private sector (Eig 1999; Hambleton 1990; Seidenstat 1996), the outsourcing and privatization of state programs (Seidenstat 1996), the increasing political competition for and reliance on grants from private foundations to support public assistance programs (Alexander 1998), and the transformation of citizens into consumers of public goods (Osborne and Gaebler 1992) imposed a new set of pressures on government administrators, employees, and the people they serve. 28.

…

Excess mortality associated with three Los Angeles September heat spells.” Environmental Research 3:277–84. Orloff, Ann Shola. 1993. The politics of pensions: A comparative analysis of Britain, Canada, and the United States, 1880–1940. Madison: University of Wisconsin Press. Orton, J. Douglas, and Karl Weick. 1990. Loosely coupled systems: A reconceptualization. Academy of Management Review 15:203–23. Osborne, David, and Ted Gaebler. 1992. Reinventing government: How the entrepreneurial spirit is transforming the public sector. New York: Plume. Palecki, Michael, Stanley Changnon, and Kenneth Kunkel. 2001. The nature and impacts of the July 1999 heat wave in the Midwestern U.S.: Learning from the lessons of 1995.

Howard Rheingold by The Virtual Community Homesteading on the Electronic Frontier-Perseus Books (1993)

"hyperreality Baudrillard"~20 OR "Baudrillard hyperreality", Alvin Toffler, Apple II, bread and circuses, Brewster Kahle, Buckminster Fuller, commoditize, conceptual framework, disinformation, Do you want to sell sugared water for the rest of your life?, Douglas Engelbart, Douglas Engelbart, Electric Kool-Aid Acid Test, experimental subject, General Magic , George Gilder, global village, Gregor Mendel, Hacker Ethic, Haight Ashbury, Howard Rheingold, HyperCard, intentional community, Ivan Sutherland, John Gilmore, John Markoff, Kevin Kelly, knowledge worker, license plate recognition, loose coupling, Marshall McLuhan, megaproject, Menlo Park, meta-analysis, Mitch Kapor, Morris worm, multilevel marketing, packet switching, Panopticon Jeremy Bentham, profit motive, RAND corporation, Ray Oldenburg, rent control, RFC: Request For Comment, Ronald Reagan, Saturday Night Live, Steve Jobs, Steve Wozniak, Steven Levy, Stewart Brand, technoutopianism, Ted Nelson, telepresence, The Great Good Place, The Hackers Conference, the strength of weak ties, urban decay, UUNET, Whole Earth Catalog, Whole Earth Review, young professional

We kept concluding that simple, corny, all-powerful love was the only way to make a community work when it is diverse, thus guaranteeing friction, and at the same time committed to free expression, which can and does get out of hand. A core of people must flat-out believe in the possibility of community and keep coming back to that amid the emotional storms in order for the whole loosely coupled group to hold together at all. When you complicate the situation with the real-life courtships and marriages and divorces and affairs and breakups that tend to happen to the same cohort of people when they stay in touch over a number of years, you have an atmosphere that can get overheated at times.

…

The word anarchy is frequently used to describe Usenet, not in the sense of chaotic and disorganized, but in the sense that the whole enterprise of moving all these words from all these people to all these other people is accomplished with no central governing hierarchy on either policy or technical levels. This grew directly out of the way Usenet postings were designed to be passed around the loosely coupled UUCP network. From the beginning, there was no emphasis on a central organization. All you had to do to join Usenet was to obtain the free software, find a site to feed you News and take your postings, and you were in 26-04-2012 21:44 howard rheingold's | the virtual community 11 de 35 http://www.rheingold.com/vc/book/4.html action.

…

When I next visited Paris, I followed leads provided by Landaret and my other friends who had been involved in French telecommunications, and talked with some of the people who were involved in the fateful decision to adopt the chat services that surfaced in Gr‚tel to the national Minitel system. Landaret, however, had more to say about the significance of what they had learned over the past ten years. "Because our system was set up to study the way people use these services, we could perform social experiments," Landaret explained. As the system evolved, it became a very loosely coupled collection of different information services and communications forums. Many people stayed in only one or two different domains, Landaret and his colleagues discovered, but a small number of people seemed to move ideas very swiftly from one group 26-04-2012 21:45 howard rheingold's | the virtual community 10 de 22 http://www.rheingold.com/vc/book/8.html to another.

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities by Justin Schuh

address space layout randomization, Albert Einstein, Any sufficiently advanced technology is indistinguishable from magic, bash_history, business logic, business process, database schema, Debian, defense in depth, en.wikipedia.org, Firefox, information retrieval, information security, iterative process, Ken Thompson, loose coupling, MITM: man-in-the-middle, Multics, MVC pattern, off-by-one error, operational security, OSI model, RFC: Request For Comment, slashdot, SQL injection, web application

Your review should identify design components that are inadequately documented or exceptionally complex. You see examples of this problem throughout the book, especially when variable relationships are tackled in Chapter 7, “Program Building Blocks.” Loose Coupling Coupling refers to the level of communication between modules and the degree to which they expose their internal interfaces to each other. Loosely coupled modules exchange data through well-defined public interfaces, which generally leads to more adaptable and maintainable designs. In contrast, strongly coupled modules have complex interdependencies and expose important elements of their internal interfaces.

…

See IPSs (intrusion prevention systems) INVALID_HANDLE_VALUE, NULL, compared, 632-633 invocation DCOM objects, 735-736 UNIX programs, 565-572 direct invocation, 565-570 indirect invocation, 570-572 IP (Internet Protocol), 831-832 addresses, 832-833 maintaining state with, 1029-1030 addressing, 833-834 checksum, 843 fragmentation, 853-863 overlapping fragments, 858-862 pathological fragment sets, 855-858 processing, 854-855 header validation, 836-844 IP packets, 834-836 options, 844-851 source routing, 851-853 subnet, 832 IPC (interprocess communications), Windows NT, 685 COM (Component Object Model), 725-754 DDE (Dynamic Data Exchange), 697 desktop object, 690-691 impersonation, 688-689 mailslots, 705-706 messaging, 689-698 pipes, 698-705 redirector, 686-688 RPCs (Remote Procedure Calls), 706-724 security, 686-689 shatter attacks, 694-697 window station, 690 WTS (Windows Terminal Services), 697-698 IPSs (intrusion prevention systems), 88 host-based IPSs (intrusion prevention systems), 83 IRIX, 460 ISAKMP (Internet Security Association and Key Management Protocol), 948 encryption vunerabilities, 971-972 headers, 949-952 payloads, 952-956 certificate payloads, 963-964 certificate request payloads, 964 delete payloads, 969-971 hash payloads, 964-965 identification payloads, 961-963 key exchange payloads, 959, 961 nonce payloads, 965-966 notification payloads, 966-968 proposal payloads, 956-958 SA (security association) payloads, 956 signature payloads, 965 transform payloads, 959 vendor ID payloads, 971 ISAPI (Internet Server Application Programming Interface), 1010 ISAPI filters, 71 IsDBCSLeadByte( ) function, 454 iterative process, application review, 98-99 J Jaa, Tony, 685 Java Database Connectivity (JDBC), 1106 Java servlets, 1014, 1105-1106 configuration settings, 1112-1113 cross-site scripting, 1110-1111 file access, 1107-1108 file inclusion, 1108-1109 inline evaluation, 1110 JSP file inclusion, 1109-1110 shell invocation, 1108 SQL injection queries, 1106-1107 threading, 1111-1112 Web server APIs versus, 1106 Java Virtual Machine (JVM), 6 JavaScript Object Notation (JSON), 1085 JavaServer Pages (JSP), 1013-1014, 1106 file inclusion, 1109-1110 JDBC (Java Database Connectivity), 1106 Johanson, Eric, 1060 Johnson, Nick, 459 JSON (JavaScript Object Notation), 1085 JSP (JavaServer Pages), 1013, 1106 file inclusion, 1109-1110 jump locations, signals, 788-791 junction points, Windows NT files, 676-680 arbitrary file accesses, 678-680 race conditions, 680 TOCTTOU (time of check to time of use), 680 JVM (Java Virtual Machine), 6 K kernel Linux, probing, 569 UNIX, 461 kernel files, UNIX, 511 Kernel Object Manager (KOM), 627 Kernel Probe Vulnerability in Linux 2.2 listing (10-1), 569 key exchange payloads, ISAKMP (Internet Security Association and Key Management Protocol), 959, 961 keys, Windows NT registry key squatting, 682-684 permissions, 681-682 predefined keys, 681 kill bit, Active X controls, 752 kill( ) function, 786 Kirch, Olaf, 545 Klima, Vlastimil, 48 KOM (Kernel Object Manager), 627 Koziol, Jack, 168 Krahmer, Sebastian, 606, 877 Kuhn, Juan Pablo Martinez, 885 L Lai, Xuejia, 48 languages (programming), C, 203-204 arithmetic boundary conditions, 211-223 binary encoding, 207-208 bit fields, 205 bitwise shift operators, 236-237 byte order, 209 character types, 205 data storage, 204-211 floating types, 205 function invocations, 237-238 implementation defined behavior, 204 integer types, 205-206 macros, 288-289 objects, 205 operators, 271-277 order of evaluation, 282-283 pointers, 277-282 precedence, 287-288 preprocessor, 288-289 signed integer boundaries, 220-223 standards, 204 structure padding, 284-287 switch statements, 237 type conversion vunerabilities, 246-270 type conversions, 223-246 types, 204-207 typos, 289-296 unary operator, 236 unary + operator, 235 unary - operator, 235 undefined behavior, 204 unsigned integer boundaries, 213-218, 220 Last Stage of Delirium (LSD), 188 Last-Modified header field (HTTP), 1019 layer 1 (physical), network segmentation, 84 layer 2 (data link), network segmentation, 84-85 layer 3 (network), network segmentation, 85 layer 4 (transport), network segmentation, 85-87 layer 5 (session), network segmentation, 87 layer 6 (presentation), network segmentation, 87 layer 7 (application) enterprise firewalls, 894 network segmentation, 87-88 layering, stateful inspection firewalls, 911-913 layers multiple encoding layers, 444-445 network segmentation, 84-87 LD_LIBRARY_PATH environment variable (UNIX), 607 LD_PRELOAD environment variable (UNIX), 607 Le Blanc, David, 50 leaks, file descriptors, UNIX, 582-587 Leblanc, David, 235, 647-648, 736 Lebras, Gregory, 1100 Leidl, Bruce, 885 length calculations, multiple calculations on same input, 367-369 Length Miscalculation Example for Constructing an ACC log listing (7-33), 362 length variables, DNS (Domain Name System), 996, 998-1000, 1002 Lenstra, Arjen, 48 levels, impersonation, IPC (interprocess communications, 688-689 libraries, 499-500 UNIX, 510 Lincoln, Abraham, 167 linked lists auditing, 321-326 circular linked lists, 322 doubly linked lists, 322 singly linked lists, 322 linking objects, vunerabilities, 607-608 links UNIX files, 515-525 hard links, 515, 522-525 soft links, 515-522 Windows NT files, 676-680 hard links, 676 junction points, 676-680 Linux, 459-460 capabilities, 492-494 do_mremap( ) function, vunerabilities, 342-343 environment strings, 594 file system IDs, 491 kernel probes, vunerabilities, 569 teardrop vunerability, 325 Linux do_mremap( ) Vulnerability listing (7-26), 342 Linux Teardrop Vulnerability listing (7-14), 325 List Pointer Update Error listing (7-13), 324 listings 5-1 (Function Prologue), 174 5-2 (Off-by-One Length Miscalculation), 175 5-3 (Off-by-One Length Miscalculation), 181 5-4 (Overflowing into Local Variables), 197 5-5 (Indirect Memory Corruption), 199 5-6 (Off-by-One Overwrite), 200 6-1 (Twos Complement Representation of -15), 209 6-2 (Integer Overflow Example), 215 6-3 (Challenge-Response Integer Overflow Example in OpenSSH 3.1), 216 6-4 (Unsigned Integer Underflow Example), 217 6-5 (Signed Integer Vulnerability Example), 221 6-6 (Integer Sign Boundary Vulnerability Example in OpenSSL 0.9.6l), 222 6-7 (Signed Comparison Vulnerability Example), 247 6-8 (Antisniff v1.0 Vulnerability), 250 6-9 (Antisniff v1.1 Vulnerability), 251 6-10 (Antisniff v1.1.1 Vulnerability), 252 6-11 (Antisniff v1.1.2 Vulnerability), 253 6-12 (Sign Extension Vulnerability Example), 254 6-13 (Prescan Sign Extension Vulnerability in Sendmail), 256 6-14 (Sign-Extension Example), 258 6-15 (Zero-Extension Example), 258 6-16 (Truncation Vulnerability Example in NFS), 260 6-17 (Truncation Vulnerabilty Example), 260 6-18 (Detect_attack Small Packet Algorithm in SSH), 261 6-19 (Detect_attack Truncation Vulnerability in SSH), 262 6-20 (Comparison Vulnerability Example), 266 6-21 (Signed Comparison Vulnerability), 267 6-22 (Unsigned Comparison Vulnerability), 267 6-23 (Signed Comparison Example in PHP), 269 6-24 (Sizeof Misuse Vulnerability Example), 271 6-25 (Sign-Preserving Right Shift), 273 6-26 (Right Shift Vulnerability Example), 273 6-27 (Division Vulnerability Example), 274 6-28 (Modulus Vulnerability Example), 275 6-29 (Pointer Arithmetic Vulnerability Example), 281 6-30 (Order of Evaluation Logic Vulnerability), 283 6-31 (Order of Evaluation Macro Vulnerability), 283 6-32 (Structure Padding in a Network Protocol), 284 6-33 (Example of Structure Padding Double Free), 286 6-34 (Example of Bad Counting with Structure Padding), 286 7-1 (Apache mod_dav CDATA Parsing Vulnerability), 298 7-2 (Bind 9.2.1 Resolver Code gethostans( ) Vulnerability), 300 7-3 (Sendmail crackaddr( ) Related Variables Vulnerability), 304 7-4 (OpenSSH Buffer Corruption Vulnerability), 307 7-5 (OpenSSL BUF_MEM_grow( ) Signed Variable Desynchronization), 311 7-6 (Uninitialized Variable Usage), 313 7-7 (Uninitialized Memory Buffer), 314 7-8 (Uninitialized Object Attributes), 314 7-9 (Arithmetic Vulnerability Example), 317 7-10 (Arithmetic Vulnerability Example in the Parent Function), 318 7-11 (Type Confusion), 320 7-12 (Empty List Vulnerabilities), 322 7-13 (List Pointer Update Error), 324 7-14 (Linux Teardrop Vulnerability), 325 7-15 (Simple Nonterminating Buffer Overflow Loop), 328 7-16 (MS-RPC DCOM Buffer Overflow Listing), 329 7-17 (NTPD Buffer Overflow Example), 329 7-18 (Apache mod_php Nonterminating Buffer Vulnerability), 331 7-19 (Apache 1.3.29/2.X mod_rewrite Off-by-one Vulnerability), 332 7-20 (OpenBSD ftp Off-by-one Vulnerability), 333 7-21 (Postincrement Loop Vulnerability), 334 7-22 (Pretest Loop Vulnerability), 335 7-23 (Break Statement Omission Vulnerability), 337 7-24 (Default Switch Case Omission Vulnerability), 338 7-25 (Ignoring realloc( ) Return Value), 341 7-26 (Linux do_mremap( ) Vulnerability), 342 7-27 (Finding Return Values), 344 7-28 (Ignoring Return Values), 345 7-29 (Unexpected Return Values), 347 7-30 (Outdated Pointer Vulnerability), 351 7-31 (Outdated Pointer Use in ProFTPD), 354 7-32 (Sendmail Return Value Update Vulnerability), 356 7-33 (Length Miscalculation Example for Constructing an ACC log), 362 7-34 (Buffer Overflow in NSS Library’s ssl2_HandleClientHelloMessage), 365 7-35 (Out-of-Order Statements), 366 7-36 (Netscape NSS Library UCS2 Length Miscalculation), 367 7-37 (Integer Overflow with 0-Byte Allocation Check), 370 7-38 (Allocator-Rounding Vulnerability), 372 7-39 (Allocator with Header Data Structure), 372 7-40 (Reallocation Integer Overflow), 373 7-41 (Dangerous Data Type Use), 374 7-42 (Problems with 64-bit Systems), 375 7-43 (Maximum Limit on Memory Allocation), 376 7-44 (Maximum Memory Allocation Limit Vulnerability), 377 7-45 (Double-Free Vulnerability), 379 7-46 (Double-Free Vulnerability in OpenSSL), 380 7-47 (Reallocation Double-Free Vulnerability), 383 8-1 (Different Behavior of vsnprintf( ) on Windows and UNIX), 394 8-2 (Dangerous Use of strncpy( )), 396 8-3 (Strcpy( )-like Loop), 400 8-4 (Character Expansion Buffer Overflow), 401 8-5 (Vulnerable Hex-Decoding Routine for URIs), 404 8-6 (If Header Processing Vulnerability in Apache’s mod_dav Module), 404 8-7 (Text-Processing Error in Apache mod_mime), 406 8-8 (Embedded Delimiter Example), 409 8-9 (Multiple Embedded Delimiters), 410 8-10 (NUL-Byte Injection with Memory Corruption), 413 8-11 (Data Truncation Vulnerability), 415 8-12 (Data Truncation Vulnerability 2), 415 8-13 (Correct Use of GetFullPathName( )), 416 8-14 (GetFullPathName( ) Call in Apache 2.2.0), 417 8-15 (Directory Traversal Vulnerability), 420 8-16 (Format String Vulnerability in WU-FTPD), 423 8-17 (Format String Vulnerability in a Logging Routine), 424 8-18 (Shell Metacharacter Injection Vulnerability), 426 8-19 (Example of Dangerous Program Use), 428 8-20 (SQL Injection Vulnerability), 431 8-21 (SQL Truncation Vulnerability), 433 8-22 (Character Black-List Filter), 435 8-23 (Character White-List Filter), 436 8-24 (Metacharacter Vulnerability in PCNFSD), 437 8-25 (Vulnerability in Filtering a Character Sequence), 437 8-26 (Vulnerability in Filtering a Character Sequence #2), 438 8-27 (Hex-encoded Pathname Vulnerability), 441 8-28 (Decoding Incorrect Byte Values), 443 8-29 (Return Value Checking of MultiByteToWideChar( )), 452 8-30 (Dangerous Use of IsDBCSLeadByte( )), 454 8-31 (Code Page Mismatch Example), 455 8-32 (NUL Bytes in Multibyte Code Pages), 456 9-1 (Privilege Misuse in XFree86 SVGA Server), 478 9-2 (Incorrect Temporary Privilege Relinquishment in FreeBSD Inetd), 487 9-3 (Race Condition in access( ) and open( )), 526 9-4 (Race Condition from Kerberos 4 in lstat( ) and open( )), 529 9-5 (Race Condition in open( ) and lstat( )), 529 9-6 (Reopening a Temporary File), 542 10-1 (Kernel Probe Vulnerability in Linux 2.2), 569 10-2 (Setenv( ) Vulnerabilty in BSD), 576 10-3 (Misuse of putenv( ) in Solaris Telnetd), 597 13-1 (Signal Interruption), 791 13-2 (Signal Race Vulnerability in WU-FTPD), 802 13-3 (Race Condition in the Linux Kernel’s Uselib( )), 821 16-1 (Name Validation Denial of Service), 931 16-2 (Certificate Payload Integer Underflow in CheckPoint ISAKMP), 954 lists auditing, 321-324, 326 data ranges, 324, 326 duplicate elements, 323 empty lists, vunerabilities, 322-323 linked lists, 322 pointer updates, errors, 323-324 list_add( ) function, 757 list_init( ) function, 757 little-endian architecture, bytes, ordering, 209 loading DLLs, 656-658 Processes, Windows NT, 654-655 local namespaces, Windows NT, 629 local privilege separation socket, OpenSSH, 161 Location header field (HTTP), 1019 lock matching, synchronization objects, 781-783 LOCK method, 1022 log files, UNIX, 510 logic business logic, 1041 presentation logic, 1040-1041 login groups, UNIX, 461 logon rights, Windows NT sessions, 638 longjmp( ) function, 788-791 looping constructs, auditing, 327-336 loops data copy, 330 posttest loops, 334-335 pretest loops, 334-335 terminating conditions, 327-334 typos, 335-336 loose coupling, software design, 33 loosely coupled modules, 33 Lopatic, Thomas, 895, 903, 907-911 lreply( ) function, 423 LSD (Last Stage of Delirium), 188 lstat( ) function, 528-531 M %m format specifier, 423 MAC (Media Address Control), 84 Macros, C programming language, 288-289 magic_quotes option (PHP), 1105 mail spools, UNIX, 509 mailslot squatting, 706 mailslots, Windows NT, IPC (interprocess communications), 705-706 Maimon, Uriel, 897 maintaining state, 1027-1029 client IP addresses, 1029-1030 cookies, 1036-1038 embedding state in HTML and URLs, 1032-1033 HTTP authentication, 1033-1036, 1056-1057 Referer request header, 1030-1031 sessions, 1038-1039, 1049-1052 security vulnerabilities, 1051-1052 session management, 1052-1053 session tokens, 1053-1056 stateful versus stateless systems, 1027 maintenance, SDLC (Systems Development Life Cycle), 13 major components, 50 make_table( ) function, 216 malicious input, tracing, 113-114 malloc( ) function, 341, 371 man-in-the-middle attacks, 162 management, sessions, 1052-1053 mapping CLSIDs to applications, 728 Max-Forwards header field (HTTP), 1019 Maximum Limit on Memory Allocation listing (7-43), 376 Maximum Memory Allocation Limit Vulnerability listing (7-44), 377 McDonald, John, 571, 903, 907, 911 McGraw, Gary, 168 Media Address Control (MAC), 84 Mehta, Neel, 203, 895, 967 memory, 0 bytes, allocating, 370-371 memory blocks, shared memory blocks, 201-202 memory buffers, unitialized memory buffers, 314 memory corruption, 167 assessing, 196-202 buffer overflows, 168-169 global overflows, 186 heap overflows, 183-186 off-by-one errors, 180-183 process memory layout, 169 SHE (structured exception handling) attacks, 178-180 stack overflows, 169-178 static overflows, 186 protection mechanisms, 189-190 ASLR (address space layout randomization), 194 function pointer obfuscation, 195-196 heap hardening, 191-193 nonexecutable stack, 193 SafeSEH, 194-195 stack cookies, 190-191 shellcode, 187-189 memory management, auditing, 362 ACC (allocation-check-copy) logs, 362-369 allocation functions, 369-377 allocator scorecards, 377-379 double-frees, 379-385 error domains, 378-379 memory pages, nonexecutable memory pages, 193 memset( ) function, 199 message queues, 614 Message-Id header field (HTTP), 1019 messaging, Windows NT, IPC (interprocess communications), 689-698 metacharacter evasion, 441-445 Metacharacter Vulnerability in PCNFSD listing (8-24), 437 metacharacters, 387, 407-408 embedded delimiters, 408-411 filtering, 434-445 character stripping vunerabilities, 437-439 escaping metacharacters, 439-440 insufficient filtering, 436-437 metacharacter evasion, 441-445 format strings, 422-425 formats, 418 NUL-byte injection, 411-414 path metacharacters, 418-422 file canonicalization, 419-420 Windows registry, 420-422 Perl open( ) function, 429-431 shell metacharacters, 425-429 SQL queries, 431-434 truncation, 414-418 UNIX programs, indirect invocation, 570-571 metadata, 407 methods CONNECT, 1021 COPY, 1022 DELETE, 1020 GET, 1023, 1026 LOCK, 1022 MKCOL, 1022 MOVE, 1022 OPTIONS, 1021 POST, 1025-1026 PROPFIND, 1022 PROPPATCH, 1022 PUT, 1020 SEARCH, 1022 SPACEJUMP, 1021 TEXTSEARCH, 1021 TRACE, 1021 UNLOCK, 1022 Microsoft Developer Network (MSDN), 626 Microsoft Windows Internals, 4th Edition, 654 MIDL (Microsoft Interface Definition Language) DCOM (Distributed Component Object Model), 738-740 RPCs (Remote Procedure Calls), 708 misinpreterpeting return values, 346-350 Misuse of putenv( ) in Solaris Telnetd listing (10-3), 597 mitigating factors, operational vunerabilities, 76 mitigation, threats, 61 MKCOL method, 1022 mkdtemp( ) function, 543 mkstemp( ) function, 542-543 mktemp( ) function, 539, 541 Model component (MVC), 1045 Model-View-Controller (MVC), 1044-1045 modular artihmetic, 214 modules analyzing, CC (code comprehension), 114-116 loosely coupled modules, 33 strongly coupled modules, 33 Modulus Vulnerability Example listing (6-28), 275 mount points, UNIX, 463 MOVE method, 1022 MS-RPC DCOM Buffer Overflow Listing listing (7-16), 329 MSDN (Microsoft Developer Network), 626 MTA (mulitthreaded apartment), COM (Component Object Model), 729 multibyte character sequences, interpretation, 455 MultiByteToWideChar( ) function, 451-452, 456-457 Multics (Multiplexed Information and Computing Service), 460 Multiple Embedded Delimiters listing (8-9), 410 multiple encoding layers, 444-445 multiple-input test cases, code audits, 143 Multiplexed Information and Computing Service (Multics), 460 multiplication overflows, Intel architectures, 218, 220 multiplicative operators, 243 multithreaded apartment (MTA), COM (Component Object Model), 729 multithreaded programs, synchronization, 810-825 deadlocks, 823-825 PThreads API, 811-813 race conditions, 816-823 starvation, 823-825 Windows API, 813-815 Murray, Bill, 25 mutex, 756 mutex objects, Windows NT, 766 mutexes, PThreads API, 811-812 MVC (Model-View-Controller), 1044-1045 my_malloc( ) function, 371 N N-tier architectures, 1041, 1043 business tier, 1042-1044 client tier, 1042 data tier, 1042-1043 MVC (Model-View-Controller), 1044-1045 Web tier, 1042-1045 name servers, DNS (Domain Name System), 986-987 name squatting, 630 Name Validation Denial of Service listing (16-1), 931 named pipes UNIX, 511 Windows NT, 698-699 names, DNS (Domain Name System), 993-996 namespaces (Windows NT) global namespaces, 629 local namespaces, 629 objects, 629-632 collisions, 630-631 Vista object namespaces, 631 narrowing integer types, 227-228 NAT (Network Address Translation), 88 National Institute for Standards and Technology (NIST), 44 navigating code, 109 external flow sensitivity, 109-110 tracing, 111 NCACN (network computing architecture connection-oriented protocol), RPCs (Remote Procedure Calls), 707 NCALRPC (network computing architecture local remote procedure call protocol), RPCs (Remote Procedure Calls), 708 NCDAG (network computing architecture datagram protocol), RPCs (Remote Procedure Calls), 707 .NET Common Language Runtime (CLR), 6 .NET Developer’s Guide to Windows Security, The, 637 NetBSD, 460 netmasks, 833 Netscape NSS Library UCS2 Length Miscalculation listing (7-36), 367 Netscape Server Application Programming Interface (NSAPI), 1010 Network Address Translation (NAT).

…

Principles of Software Design The number of software development methodologies seems to grow directly in proportion to the number of software developers. Different methodologies suit different needs, and the choice for a project varies based on a range of factors. Fortunately, every methodology shares certain commonly accepted principles. The four core principles of accuracy, clarity, loose coupling, and strong cohesion (discussed in the following sections) apply to every software design and are a good starting point for any discussion of how design can affect security. Accuracy Accuracy refers to how effectively design abstractions meet the associated requirements. (Remember the discussion on requirements in Chapter 1.)

Chaos Engineering: System Resiliency in Practice by Casey Rosenthal, Nora Jones

Amazon Web Services, Asilomar, autonomous vehicles, barriers to entry, blockchain, business continuity plan, business intelligence, business logic, business process, cloud computing, cognitive load, complexity theory, continuous integration, cyber-physical system, database schema, DevOps, fail fast, fault tolerance, hindsight bias, human-factors engineering, information security, Kanban, Kubernetes, leftpad, linear programming, loose coupling, microservices, MITM: man-in-the-middle, no silver bullet, node package manager, operational security, OSI model, pull request, ransomware, risk tolerance, scientific management, Silicon Valley, six sigma, Skype, software as a service, statistical model, systems thinking, the scientific method, value engineering, WebSocket

Maybe they added redundancy, maybe scaling automation, maybe architectural design patterns. That didn’t matter. What did matter is that the problem got solved somehow, quickly, and with immediately appreciable results. This reinforces the “highly aligned, loosely coupled” tenet of Netflix’s culture. Chaos Monkey forced everyone to be highly aligned toward the goal of being robust enough to handle vanishing instances, but loosely coupled as to how to solve this particular problem since it doesn’t suggest the solution. Chaos Monkey is a management principle instantiated in running code. The concept behind it seemed unique and a bit wonky, so Netflix blogged about it.

…

Management didn’t tell individual contributors (ICs) what to do; instead, they made sure that ICs understood the problems that needed to be solved. ICs then told management how they planned to solve those problems, and then they worked to solve them. High performance teams are highly aligned and loosely coupled. This means that less effort needs to be put into process, formal communication, or task management if everyone shares the same goal across teams. This interesting dynamic is part of what contributed to Netflix’s high-performance culture, and it had an interesting consequence in the development of Chaos Engineering.

Saturn's Children by Charles Stross

augmented reality, British Empire, business process, false flag, gravity well, indoor plumbing, invisible hand, Isaac Newton, Kuiper Belt, loose coupling, phenotype, Pluto: dwarf planet, plutocrats, theory of mind

Table of Contents Title Page Copyright Page Epigraph part one - INNER SYSTEM Learning Not to Die Telemus and Lindy Silent Movie Gainful Employment The Ghosts of Mars Small Bodies, Loosely Coupled Whores de Combat Dinosaurs and Rapists Coin-Operated Boy Controlling Interest part two - OUTWARD BOUND On the Run Sex and Destiny A Question of Ownership Evil Twin Revising My Opinions Long-Lost Sibs Interview with the Domina Think of England epilogue Titles by Charles Stross SINGULARITY SKY IRON SUNRISE ACCELERANDO THE ATROCITY ARCHIVES GLASSHOUSE HALTING STATE SATURN’S CHILDREN THE BERKLEY PUBLISHING GROUP Published by the Penguin Group Penguin Group (USA) Inc. 375 Hudson Street, New York, New York 10014, USA Penguin Group (Canada), 90 Eglinton Avenue East, Suite 700, Toronto, Ontario M4P 2Y3, Canada (a division of Pearson Penguin Canada Inc.)

…

“I’m—” She pauses: “I’m sorry, Kate. I should not have suspected you, but I had to be sure. The enemy is not above using your kind as couriers.” She reaches out to me, and I shove her hand away with carefully calculated anger, narrowing my achingly oversized eyes at her. If only you knew ... Small Bodies, Loosely Coupled WHEN THINGS GO wrong in space, they tend to go wrong with very little warning. This time it’s an exception. We’re on day eighty-eight of the cruise. After a stormy argument and a sulky three-day cooling-off period, I allowed Granita to woo me back into her web, where her submissive contrition and shameless self-abasement went a long way to assuaging my indignation.

…

In fact, I’m beginning to wonder if I need to break out the zero-gee kit (bungee cords are your friends; free-fall sex without restraints is a fast track to dents and dings). “Freya,” he says, and it comes out like an actual attempt at conversation, rather than quasi-verbal passion punctuation. “Freya, we need to talk.” “Mm-hmm? So talk already.” I sway above him. We’re loosely coupled, held together only by our intromissive interface, but every time he speaks, it sends waves of pleasure through me. “What’s the big news?” “Juliette never, never . . .” I feel his hands on my thighs, pushing me tighter against him, and I moan quietly. “Well, no.” I’m not sure why she never, never—if she was around someone as Creator-like as Jeeves for that long, the thought must have crossed her mind—but I’m sure she had her reasons.

Kill It With Fire: Manage Aging Computer Systems by Marianne Bellotti

anti-pattern, barriers to entry, business logic, cloud computing, cognitive bias, computer age, continuous integration, create, read, update, delete, Daniel Kahneman / Amos Tversky, data science, database schema, Dennis Ritchie, DevOps, fault tolerance, fear of failure, Google Chrome, Hans Moravec, iterative process, Ken Thompson, loose coupling, microservices, minimum viable product, Multics, no silver bullet, off-by-one error, platform as a service, pull request, QWERTY keyboard, Richard Stallman, risk tolerance, Schrödinger's Cat, side project, software as a service, Steven Levy, systems thinking, web application, Y Combinator, Y2K

When two separate components are dependent on each other, they are said to be coupled. In tightly coupled situations, there’s a high probability that changes with one component will affect the other. For example, if a change to one code base requires a corresponding change to another code base, the two repositories are tightly coupled. Loosely coupled components, on the other hand, are ones where changes made to one component don’t necessarily affect the other. Tightly coupled systems produce cascading effects. One change creates a response in another part of the system, which creates a response in another part of the system. Like a domino effect, parts of the system start executing without a human operator telling them to do so.

…

Figure a minimum of three people per service. For the purposes of this discussion, a service is a subsystem that has its own repository of code (although Google famously keeps all its source code in a monolith repository), has dedicated resources (either VMs or separate containers), and is assumed to be loosely coupled from other components of the system. The minimum on-call rotation is six people. So, a large service with a team of six can have a separate on-call rotation, or two small services can share a rotation among their teams. People can, of course, be on multiple teams, or the same team can run multiple services, but a person cannot be well versed in an infinite number of topics, so for every additional service, expect the level of expertise to be cut in half.

An Elegant Puzzle: Systems of Engineering Management by Will Larson

Ben Horowitz, Cass Sunstein, Clayton Christensen, data science, DevOps, en.wikipedia.org, fault tolerance, functional programming, Google Earth, hive mind, Innovator's Dilemma, iterative process, Kanban, Kickstarter, Kubernetes, loose coupling, microservices, MITM: man-in-the-middle, no silver bullet, pull request, Richard Thaler, seminal paper, Sheryl Sandberg, Silicon Valley, statistical model, systems thinking, the long tail, web application

(This is yet another paper that makes me wish TLA+ felt natural enough to be a commonly adopted tool.) “The Chubby Lock Service for Loosely-Coupled Distributed Systems” Distributed systems are hard enough without having to frequently reimplement Paxos or Raft. The model proposed by Chubby is to implement consensus once in a shared service, which will allow systems built upon it to share in the resilience of distribution by following greatly simplified patterns. From the abstract: We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance.

Industrial Internet by Jon Bruner

air gap, autonomous vehicles, barriers to entry, Boeing 747, commoditize, computer vision, data acquisition, demand response, electricity market, en.wikipedia.org, factory automation, Google X / Alphabet X, industrial robot, Internet of things, job automation, loose coupling, natural language processing, performance metric, Silicon Valley, slashdot, smart grid, smart meter, statistical model, the Cathedral and the Bazaar, web application

Combined with steering-wheel, speed, GPS, and accelerator-pedal readings, a sensor-driven rain indication could warn a driver that he’s moving too fast for road conditions, or help him improve his fuel economy by moderating his acceleration habits. Machines built nightly The Web brought about the end of the annual software release cycle.[7] Provided as a loosely-coupled service on the Internet, software can be improved and updated constantly. The industrial internet will bring about a similar change in the physical world. Some of the value of any machine is in its controls. By replacing controls regularly, or running them remotely and upgrading them every night like a Web service, machines can be constantly improved without any mechanical modifications.

Site Reliability Engineering: How Google Runs Production Systems by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

"Margaret Hamilton" Apollo, Abraham Maslow, Air France Flight 447, anti-pattern, barriers to entry, business intelligence, business logic, business process, Checklist Manifesto, cloud computing, cognitive load, combinatorial explosion, continuous integration, correlation does not imply causation, crowdsourcing, database schema, defense in depth, DevOps, en.wikipedia.org, exponential backoff, fail fast, fault tolerance, Flash crash, George Santayana, Google Chrome, Google Earth, if you see hoof prints, think horses—not zebras, information asymmetry, job automation, job satisfaction, Kubernetes, linear programming, load shedding, loose coupling, machine readable, meta-analysis, microservices, minimum viable product, MVC pattern, no silver bullet, OSI model, performance metric, platform as a service, proprietary trading, reproducible builds, revision control, risk tolerance, side project, six sigma, the long tail, the scientific method, Toyota Production System, trickle-down economics, warehouse automation, web application, zero day

This dynamic can lead to both over-reliance on the service, when users incorrectly believe that a service will be more available than it actually is (as happened with Chubby: see “The Global Chubby Planned Outage”), and under-reliance, when prospective users believe a system is flakier and less reliable than it actually is. The Global Chubby Planned Outage Written by Marc Alvidrez Chubby [Bur06] is Google’s lock service for loosely coupled distributed systems. In the global case, we distribute Chubby instances such that each replica is in a different geographical region. Over time, we found that the failures of the global instance of Chubby consistently generated service outages, many of which were visible to end users. As it turns out, true global Chubby outages are so infrequent that service owners began to add dependencies to Chubby assuming that it would never go down.

…

It can be tempting to combine monitoring with other aspects of inspecting complex systems, such as detailed system profiling, single-process debugging, tracking details about exceptions or crashes, load testing, log collection and analysis, or traffic inspection. While most of these subjects share commonalities with basic monitoring, blending together too many results in overly complex and fragile systems. As in many other aspects of software engineering, maintaining distinct systems with clear, simple, loosely coupled points of integration is a better strategy (for example, using web APIs for pulling summary data in a format that can remain constant over an extended period of time). Tying These Principles Together The principles discussed in this chapter can be tied together into a philosophy on monitoring and alerting that’s widely endorsed and followed within Google SRE teams.

…

Modularity Expanding outward from APIs and single binaries, many of the rules of thumb that apply to object-oriented programming also apply to the design of distributed systems. The ability to make changes to parts of the system in isolation is essential to creating a supportable system. Specifically, loose coupling between binaries, or between binaries and configuration, is a simplicity pattern that simultaneously promotes developer agility and system stability. If a bug is discovered in one program that is a component of a larger system, that bug can be fixed and pushed to production independent of the rest of the system.

Does Capitalism Have a Future? by Immanuel Wallerstein, Randall Collins, Michael Mann, Georgi Derluguian, Craig Calhoun, Stephen Hoye, Audible Studios

affirmative action, blood diamond, Bretton Woods, BRICs, British Empire, business cycle, butterfly effect, company town, creative destruction, deindustrialization, demographic transition, Deng Xiaoping, discovery of the americas, distributed generation, Dr. Strangelove, eurozone crisis, fiat currency, financial engineering, full employment, gentrification, Gini coefficient, global village, hydraulic fracturing, income inequality, Isaac Newton, job automation, joint-stock company, Joseph Schumpeter, junk bonds, land tenure, liberal capitalism, liquidationism / Banker’s doctrine / the Treasury view, loose coupling, low skilled workers, market bubble, market fundamentalism, mass immigration, means of production, mega-rich, Mikhail Gorbachev, military-industrial complex, mutually assured destruction, offshore financial centre, oil shale / tar sands, Ponzi scheme, postindustrial economy, reserve currency, Ronald Reagan, shareholder value, short selling, Silicon Valley, South Sea Bubble, sovereign wealth fund, Suez crisis 1956, too big to fail, transaction costs, vertical integration, Washington Consensus, WikiLeaks

The alternatives are either a noncapitalist system that would nonetheless continue the hierarchical and polarizing features of capitalism, or a relatively democratic and a relatively egalitarian system. Possibly several world-systems will emerge from the transition. Calhoun also argues that more loosely coupled systems may develop to deal with disruptions from external threats as well as the internal risks of capitalism. This runs against the widely shared assumption that the world has become irreversibly global. Yet, once again, what theory supports this ideological contention? The twentieth century thinkers and political leaders of all persuasions proved to be wrong in their ideological conviction that there was a single road to the future, as passionate advocates of capitalism, communism, and fascism argued and attempted to impose.

…

Infrastructural systems on which capitalism depends, like communications networks or energy supplies, could also be disrupted, possibly by political actors. For all these reasons, what has been a process of ever-tighter global integration may be partially reversed. Coping with disruptions may depend on more loosely coupled systems with different bases for resilience. Capitalism could decline without collapsing, simply organizing less of economic activity as alternative systems organize more. Growth could slow. This could happen globally or, more likely, unevenly by country and region. The ever-tighter integration of global markets that capitalism has driven might be slowed or reversed, with differently organized systems in different settings.

The Personal MBA: A World-Class Business Education in a Single Volume by Josh Kaufman

Albert Einstein, Alvin Toffler, Atul Gawande, Black Swan, Blue Ocean Strategy, business cycle, business process, buy low sell high, capital asset pricing model, Checklist Manifesto, cognitive bias, correlation does not imply causation, Credit Default Swap, Daniel Kahneman / Amos Tversky, David Heinemeier Hansson, David Ricardo: comparative advantage, Dean Kamen, delayed gratification, discounted cash flows, Donald Knuth, double entry bookkeeping, Douglas Hofstadter, Dunning–Kruger effect, en.wikipedia.org, Frederick Winslow Taylor, George Santayana, Gödel, Escher, Bach, high net worth, hindsight bias, index card, inventory management, iterative process, job satisfaction, Johann Wolfgang von Goethe, Kaizen: continuous improvement, Kevin Kelly, Kickstarter, Lao Tzu, lateral thinking, loose coupling, loss aversion, Marc Andreessen, market bubble, Network effects, Parkinson's law, Paul Buchheit, Paul Graham, place-making, premature optimization, Ralph Waldo Emerson, rent control, scientific management, side project, statistical model, stealth mode startup, Steve Jobs, Steve Wozniak, subscription business, systems thinking, telemarketer, the scientific method, time value of money, Toyota Production System, tulip mania, Upton Sinclair, Vilfredo Pareto, Walter Mischel, Y Combinator, Yogi Berra

The critical path contains only the tasks that must be completed in order for the project to be finished on schedule. If something on the critical path changes, that Change cascades to everything else on the path. Any delay in a task on the critical path will delay the entire project. “Loosely coupled” systems have low degrees of Interdependence. Loosely coupled systems are more relaxed: they’re typically not time dependent. You may able to use “parallel processing,” completing multiple steps at a time. There’s plenty of slack, and you may be able to accomplish your goal using many different strategies. Think of an orchestra, which consists of a conductor and many instrumentalists.

…

There is scant evidence that the MBA credential, particularly from non-elite schools, or the grades earned in business courses—a measure of the mastery of the material—are related to either salary or the attainment of higher level positions in organizations. These data, at a minimum, suggest that the training or education component of business education is only loosely coupled to the world of managing organizations. That’s tough to hear if you’ve forked over a few hundred thousand dollars to buy a degree whose sole purpose is to make you a more successful businessperson. It gets worse: getting an MBA doesn’t even have an impact on your total lifetime earnings.

Redis Cookbook by Tiago Macedo, Fred Oliveira

Debian, full text search, loose coupling, Ruby on Rails, Silicon Valley, WebSocket

The publish/subscribe pattern defines a way in which receivers subscribe to messages that match a specific pattern (for instance, messages that are sent to a specific “channel”), and a way for an emitter to send messages to a message cloud. When a message hits that cloud, clients that subscribe to messages of that kind will get the message. The pattern allows then for emitters and clients to be loosely coupled—they don’t need to know each other. They just need to be able to send messages in a given pattern, and receive messages that match that pattern. For a better understanding of how Publish/Subscribe works, see the Wikipedia page. Redis has direct support for the pub/sub pattern, meaning that it lets clients subscribe to specific channels matching a given pattern, and to publish messages to a given channel.

Practical Ext JS Projects With Gears by Frank Zammetti

a long time ago in a galaxy far, far away, Albert Einstein, corporate raider, create, read, update, delete, database schema, en.wikipedia.org, fake news, Firefox, full text search, Gordon Gekko, Kickstarter, Larry Wall, leftpad, loose coupling, Ronald Reagan, web application

Then, add() is called, and we see 13 in a second alert() message. This is nice because you’re tying two functions together in a loose way. The alternative would be to have add() call the inline function (which would be defined like any other function is in that case) before doing its own work, which makes them tightly coupled. The sort of loose coupling that createInterceptor() allows for is much cleaner, though. ■Note The createSequence() and createInterceptor() at first glance look quite similar, but there is one key distinction: with createInterceptor(), if the function passed to createInterceptor() returns false, then the function that createInterceptor() is called on will not be called.

…

services, which will be used in this application, to be web services, even though they don’t use the full web services stack (that is, SOAP, WS-Security, and all the other specifications that can go along with it). Whatever line of demarcation you choose to use, the bottom line is that you’re developing using a SOA, which means you have loosely coupled components that expose a remote service interface that, usually, is platform- and language-agnostic and can therefore be married together in nearly limitless ways. The benefits of this approach are numerous. The simple fact that you aren’t generally tied to any particular technology or language is a big one.

…

Then, the background process, which has some information it wants to share with anyone who has subscribed to a given message, calls the publish() method, passing in the ID of the message being published along with any other information that interested subscribers might want. Then, the message bus goes through its list of subscribers to the published message and calls the specified function, passing the information that was published along to it. This model is a fairly simple way to allow communications between entities in a loosely coupled way, meaning they don’t need to know anything about each other to communicate. All they need is access to the common messaging bus, and knowledge of the messages that can be published or subscribed to. This is all done asynchronously, so there is no need for any sort of polling or background code running to send and receive messages (in other words, the message bus only does something when publish() or subscribe() is called).

git internal by Scott Chacon

Debian, en.wikipedia.org, loose coupling, pull request, Ruby on Rails

R1 1 R2 R3 C0 C6 R1 2 C0 C1 R2 C2 C7 R3 C3 C4 C5 You should remember to only do this on local branches before you push or on repositories that nobody has fetch access to – if anyone pulls down the objects that will become abandoned during a rebase, it gets a bit frustrating. 38 Use Cases So why is this helpful, exactly? It means that you can keep your development cycles loosely coupled. Here is an example of a common workflow with cheap branches. You have a master branch that is always stable – you never merge anything into it that you wouldn’t put into production. Then you have a development branch that you merge any experimental code into before you imagine pulling it into the master branch.

Brave New Work: Are You Ready to Reinvent Your Organization? by Aaron Dignan

"Friedman doctrine" OR "shareholder theory", Abraham Maslow, activist fund / activist shareholder / activist investor, adjacent possible, Airbnb, Albert Einstein, autonomous vehicles, basic income, benefit corporation, Bertrand Russell: In Praise of Idleness, bitcoin, Black Lives Matter, Black Swan, blockchain, Buckminster Fuller, Burning Man, butterfly effect, cashless society, Clayton Christensen, clean water, cognitive bias, cognitive dissonance, content marketing, corporate governance, corporate social responsibility, correlation does not imply causation, creative destruction, crony capitalism, crowdsourcing, cryptocurrency, David Heinemeier Hansson, deliberate practice, DevOps, disruptive innovation, don't be evil, Elon Musk, endowment effect, Ethereum, ethereum blockchain, financial engineering, Frederick Winslow Taylor, fulfillment center, future of work, gender pay gap, Geoffrey West, Santa Fe Institute, gig economy, Goodhart's law, Google X / Alphabet X, hiring and firing, hive mind, holacracy, impact investing, income inequality, information asymmetry, Internet of things, Jeff Bezos, job satisfaction, Kanban, Kevin Kelly, Kickstarter, Lean Startup, loose coupling, loss aversion, Lyft, Marc Andreessen, Mark Zuckerberg, minimum viable product, mirror neurons, new economy, Paul Graham, Quicken Loans, race to the bottom, reality distortion field, remote working, Richard Thaler, Rochdale Principles, Salesforce, scientific management, shareholder value, side hustle, Silicon Valley, single source of truth, six sigma, smart contracts, Social Responsibility of Business Is to Increase Its Profits, software is eating the world, source of truth, Stanford marshmallow experiment, Steve Jobs, subprime mortgage crisis, systems thinking, TaskRabbit, TED Talk, The future is already here, the High Line, too big to fail, Toyota Production System, Tragedy of the Commons, uber lyft, universal basic income, WeWork, Y Combinator, zero-sum game

Spotify, the Swedish music-subscription service, is often lauded for its structural innovation—the squads, tribes, chapters, and guilds that have been copied (often badly) by other firms around the world. It’s true that a network of multidisciplinary teams working on self-contained projects is part of the company’s special sauce. But what’s really impressive about Spotify’s workflow is how it ensures that teams are “loosely coupled but tightly aligned.” This concept, previously introduced in the Netflix Culture Deck (an employee handbook on steroids), suggests that we maximize strategic alignment but minimize dependencies and red tape among teams. When you’re building a single piece of software used by seventy million paying subscribers, that’s easier said than done.

…

Accept that workflow is something to be coordinated and refined, not something that can be solved. Ensure that every team has the capacity to do the work and improve how they do the work at the same time. In order to maximize the adaptive potential of the organization, create the infrastructure to support loosely coupled, tightly aligned teams. MEETINGS How we convene and coordinate; the many ways members and teams come together. To meet or not to meet? That is the question on everyone’s mind as we reconcile our visceral distaste for dysfunctional meetings with the fact that maybe, just maybe, we need them.

Exponential Organizations: Why New Organizations Are Ten Times Better, Faster, and Cheaper Than Yours (And What to Do About It) by Salim Ismail, Yuri van Geest

23andMe, 3D printing, Airbnb, Amazon Mechanical Turk, Amazon Web Services, anti-fragile, augmented reality, autonomous vehicles, Baxter: Rethink Robotics, behavioural economics, Ben Horowitz, bike sharing, bioinformatics, bitcoin, Black Swan, blockchain, Blue Ocean Strategy, book value, Burning Man, business intelligence, business process, call centre, chief data officer, Chris Wanstrath, circular economy, Clayton Christensen, clean water, cloud computing, cognitive bias, collaborative consumption, collaborative economy, commoditize, corporate social responsibility, cross-subsidies, crowdsourcing, cryptocurrency, dark matter, data science, Dean Kamen, deep learning, DeepMind, dematerialisation, discounted cash flows, disruptive innovation, distributed ledger, driverless car, Edward Snowden, Elon Musk, en.wikipedia.org, Ethereum, ethereum blockchain, fail fast, game design, gamification, Google Glasses, Google Hangouts, Google X / Alphabet X, gravity well, hiring and firing, holacracy, Hyperloop, industrial robot, Innovator's Dilemma, intangible asset, Internet of things, Iridium satellite, Isaac Newton, Jeff Bezos, Joi Ito, Kevin Kelly, Kickstarter, knowledge worker, Kodak vs Instagram, Law of Accelerating Returns, Lean Startup, life extension, lifelogging, loose coupling, loss aversion, low earth orbit, Lyft, Marc Andreessen, Mark Zuckerberg, market design, Max Levchin, means of production, Michael Milken, minimum viable product, natural language processing, Netflix Prize, NetJets, Network effects, new economy, Oculus Rift, offshore financial centre, PageRank, pattern recognition, Paul Graham, paypal mafia, peer-to-peer, peer-to-peer model, Peter H. Diamandis: Planetary Resources, Peter Thiel, Planet Labs, prediction markets, profit motive, publish or perish, radical decentralization, Ray Kurzweil, recommendation engine, RFID, ride hailing / ride sharing, risk tolerance, Ronald Coase, Rutger Bregman, Salesforce, Second Machine Age, self-driving car, sharing economy, Silicon Valley, skunkworks, Skype, smart contracts, Snapchat, social software, software is eating the world, SpaceShipOne, speech recognition, stealth mode startup, Stephen Hawking, Steve Jobs, Steve Jurvetson, subscription business, supply-chain management, synthetic biology, TaskRabbit, TED Talk, telepresence, telepresence robot, the long tail, Tony Hsieh, transaction costs, Travis Kalanick, Tyler Cowen, Tyler Cowen: Great Stagnation, uber lyft, urban planning, Virgin Galactic, WikiLeaks, winner-take-all economy, X Prize, Y Combinator, zero-sum game

This strategy quickly built one of the most valuable industries on the planet. But as the decades passed, inefficiencies and antitrust issues crept in, and by the 1960s, the studio system was all but dismantled. What replaced it was a system that was almost the exact opposite of what came before. Today, Hollywood operates in exactly the same loosely coupled, networked environment of an ExO ecosystem. Each participant, from the writer and actor, to the director and camera grip, manages his or her own career. Meanwhile, agents at every level help find and connect scripts with talent, production companies and equipment. These days, when a film is created, a swarm of independent entities come together for the duration of the production, operating on 24/7 schedules and in close collaboration.

…

Once the film is finished, sets are broken down for re-use, equipment is reassigned and all the actors, grips and production assistants disband and scatter to pursue their next projects, which often start the very next day. Hollywood didn’t plan this metamorphosis; rather, it evolved into an ExO-like ecosystem because it is the nature of film to be a series of discrete projects. The filmmaking process itself has always been characterized by a singular combination of high density, close proximity and loosely coupled constituents. These factors made Hollywood a pioneer in the virtualization of enterprises and now, combined with new social and communications technologies, puts it in the vanguard of the rise of the Exponential Organization. The high-tech startup ecosystem of Silicon Valley is another example of this model: entrepreneurs, employees, scientists, marketers, patent lawyers, angel investors, venture capitalists and even customers—all operate within a small geographic region of the San Francisco Bay Area.

Programming Android by Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

anti-pattern, business process, conceptual framework, create, read, update, delete, database schema, Debian, domain-specific language, en.wikipedia.org, fault tolerance, general purpose technology, Google Earth, interchangeable parts, iterative process, loose coupling, MVC pattern, revision control, RFID, SQL injection, systems thinking, web application

On the other hand, what happens when you want to convert your tightly bound gas vehicle to biodiesel? In this implementation, cars and engines are the same object. They cannot be separated. If the real-world situation that you are modeling requires you to consider the objects separately, your architecture will have to be more loosely coupled: interface Engine { void start(); } class GasEngine implements Engine { void start() { // spark plugs ignite gas } } class ElectricEngine implements Engine { void start() { // run power to battery } } class DelegatingVehicle { // has an engine field private Engine mEngine; public DelegatingVehicle(Engine engine) { mEngine = engine; } public void start() { // delegating vehicle can use a gas or electric engine mEngine.start(); } } void anInstantiatingMethod() { // new vehicle types are easily created by just // plugging in different kinds of engines.

…

DelegatingVehicle electricVehicle = new DelegatingVehicle(new ElectricEngine()); DelegatingVehicle gasVehicle = new DelegatingVehicle(new GasEngine()); //DelegatingVehicle hybridVehicle = new DelegatingVehicle(new HybridEngine()); //DelegatingVehicle steamVehicle = new DelegatingVehicle(new SteamEngine()); } In this architecture, the vehicle class delegates all engine-related behaviors to an engine object that it owns. This is sometimes called has-a, as opposed to the previous, subclassed example, called is-a. It can be even more flexible because it separates the knowledge of how an engine actually works from the car that contains it. Each vehicle delegates to a loosely coupled engine type and has no idea how that engine implements its behavior. The earlier example makes use of a reusable DelegatingVehicle class that does not change at all when it is given a new kind of engine. A vehicle can use any implementation of the Engine interface. In addition, it’s possible to create different types of vehicle—SUV, compact, or luxury, for instance—that each make use of any of the different types of Engine.

…

How, then does one activity invoke another, and pass information about what the user wants to do? The unit of communication is the Intent class. An Intent represents an abstract description of a function that one activity requires another activity to perform, such as taking a picture. Intents form the basis of a system of loose coupling that allows activities to launch one another. When an application dispatches an intent, it’s possible that several different activities might be registered to provide the desired operation. You have already "written" the code for an activity in the test application you created to verify that your Android SDK is correctly installed.

Sorting Things Out: Classification and Its Consequences (Inside Technology) by Geoffrey C. Bowker

affirmative action, business process, classic study, corporate governance, Drosophila, government statistician, information retrieval, loose coupling, Menlo Park, Mitch Kapor, natural language processing, Occam's razor, QWERTY keyboard, Scientific racism, scientific worldview, sexual politics, statistical model, Stephen Hawking, Stewart Brand, tacit knowledge, the built environment, the medium is the message, the strength of weak ties, transaction costs, William of Occam

Threads carry a variety of textural qualities that are often applied to human interactions: tension, knottiness or smoothness, bundling, proximity, and thickness. We select a small number here to focus on. Loosely Coupled-Tightly Coupled A category (or system of categories) may be loosely or tightly coupled with a person. Gender and age are very tightly coupled with a person as categories. One of the interesting aspects of the investigation of virtual identities in Multi User Dungeons (MUDs) and elsewhere on line is the loosening of these traditionally tightly coupled threads under highly constrained circumstances (e.g. , Turkle 1 995). Loosely coupled categories may be those that are transient, such as the color one is wearing on a given day or one's position in a waiting line.

…

The sharing of information resources and tools is a dimension of any coherent community, be it the world of homeless people in Los Angeles sharing survival knowledge via street gossip, or the world of high-energy physicists sharing electronic preprints via the Los Alamos archive. On the other hand, any given social world itself generates many interlinked information artifacts. The social world creates through bricolage, a (loosely coupled but relatively coherent) set of information resources and tools. Thus people without houses also log onto the Internet, and physicists indulge in street gossip at conferences as well as engage in a whole set of other information practices. Put briefly, information artifacts undergird social worlds , and social worlds undergird these same information resources.

Functional Programming in Scala by Paul Chiusano, Rúnar Bjarnason

domain-specific language, functional programming, higher-order functions, iterative process, loose coupling, off-by-one error, type inference, web application

There's no need to pessimistically make copies to avoid modification or corruption.9 Footnote 9mThis pessimistic copying can become a problem in large programs, when data may be passed through a chain of loosely components, each of which may be forced to make copies of this data. Using immutable data structures means never having to copy that data just to share it between two components of a system, which promotes keeping these components loosely coupled. We find that in the large, FP can often achieve greater efficiency than approaches that rely on side effects, due to much greater sharing of data and computation. In the same way, to "remove" an element from the front of a list val mylist = Cons(x,xs), we simply return xs. There is no real removing going on.

…

Let's look at some domains where it is applicable: File I/O: We've already demonstrated how to use stream processing for file I/O. Although we have focused on line-by-line reading and writing for the examples here, we can also use the library for processing binary files. Message processing, state machines, and actors: Large systems are often organized as a system of loosely-coupled components that communicate via message passing. These systems are often expressed in terms of actors, which communicate via explicit message sends and receives. We can express components in these architectures as stream processors, which lets us describe extremely complex state machines and behaviors while retaining a high-level, compositional API.

API Design Patterns by Jj Geewax

Amazon Web Services, anti-pattern, bitcoin, blockchain, business logic, cognitive load, continuous integration, COVID-19, database schema, en.wikipedia.org, exponential backoff, imposter syndrome, Internet of things, Kubernetes, lateral thinking, loose coupling, machine readable, microservices, natural language processing, Paradox of Choice, ride hailing / ride sharing, social graph, sorting algorithm

If basic comparisons are insufficient for users’ intentions, filters should provide a set of documented functions that can be interpreted and executed while filtering. 23 Importing and exporting This chapter covers Specific definitions for import and export Interacting directly with remote storage systems Converting serialized bytes into API resources Handling consistency for exporting volatile data sets How unique identifiers should be processed when importing and exporting What to do about related resources being imported or exported Handling failures during import or export operations How import and export differ from backup and restore Filtering data on input and output data In this pattern, we’ll explore how to safely and flexibly move resources in and out of an API via custom import and export methods. More importantly, this pattern relies on the API communicating directly with the external storage system rather than through an intermediary client. We’ll make all of this work by defining several loosely coupled configuration structures to cover the various aspects of these resources on their journey between the API and the underlying storage system, maximizing both flexibility and reusability. 23.1 Motivation In any API that manages user-supplied data (which is almost every API), we’ve already defined several ways to get resources in and out of the system.

…

Listing 23.4 Example using S3 as a data destination interface DataDestination { type: string; } interface S3DataDestination extends DataDestination { type: 's3'; bucket: string; prefix: string; ❶ } ❶ In this case, rather than a glob expression, we’d have a prefix to determine how written objects would be named. In other words, while these two concepts are very similar, they are not identical and don’t represent the same thing. There may be many overlapping fields, but this is by design to allow the two interfaces to change independently. And this type of loose coupling is the type of design that remains flexible even in the face of immense volatility. Now that we have a way to configure the way an API should retrieve bytes from (or send bytes to) an external storage system, we can get to the next piece: figuring out how to convert between API resources and those bytes. 23.3.3 Converting between resources and bytes It’s interesting to note that by the very nature of building a web API, we already have a mechanism to turn the underlying API resources into a serialized chunk of bytes.

…

: string; } ❶ These two are quite similar but not identical, as they have different responsibilities. Hopefully, this should all look quite boring and innocuous. The real value isn’t in the specific configuration parameters for importing and exporting data, but instead in the separation of concerns for retrieving raw data versus processing that data. This loose coupling ensures that we can reuse data sources and destinations for importing and exporting a variety of resource types across the API. Now that we’ve covered the structural aspects, let’s switch gears and start digging into the behavioral nuances of this pattern, starting with how we should address underlying resource consistency in the API. 23.3.4 Consistency When it comes to exporting data, we’re obviously required to read the entire collection of resources that are intended for export.

Working Backwards: Insights, Stories, and Secrets From Inside Amazon by Colin Bryar, Bill Carr

Amazon Web Services, barriers to entry, Big Tech, Black Lives Matter, business logic, business process, cloud computing, coronavirus, COVID-19, data science, delayed gratification, en.wikipedia.org, fulfillment center, iterative process, Jeff Bezos, late fees, loose coupling, microservices, Minecraft, performance metric, search inside the book, shareholder value, Silicon Valley, six sigma, Steve Jobs, subscription business, Toyota Production System, two-pizza team, web application, why are manhole covers round?

He suggested that each software team should build and clearly document a set of application program interfaces (APIs) for all their systems/services. An API is a set of routines, protocols, and tools for building software applications and defining how software components should interact. In other words, Jeff’s vision was that we needed to focus on loosely coupled interaction via machines through well-defined APIs rather than via humans through emails and meetings. This would free each team to act autonomously and move faster. NPI—An Early Response to Organizational Dependencies Meanwhile, we faced no shortage of good business ideas. Indeed, we had many more ideas than we could support or execute—we could only take on a few big projects each quarter.

…

If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.”5 Good examples like the Picking team demonstrated how long-term thinking, in the form of their up-front investments, generated compound returns over time. Later teams followed their lead. Sometimes it’s best to start slow in order to move fast. While it would be nice to trust that a swarm of loosely coupled, autonomous teams will always make the best tactical choices to deliver the company’s larger strategic objectives, that’s sometimes wishful thinking—even with the best of teams. The OP1 process we described in chapter one still framed the autonomy of these teams by aligning them with company strategy, giving them their initial bearing toward upcoming yearly targets.

The Railways: Nation, Network and People by Simon Bradley

Alfred Russel Wallace, back-to-the-land, Beeching cuts, book value, British Empire, classic study, clean water, Corn Laws, cross-subsidies, Crossrail, David Brooks, Etonian, high-speed rail, intermodal, joint-stock company, loose coupling, low cost airline, oil shale / tar sands, period drama, pneumatic tube, railway mania, Ralph Waldo Emerson, work culture

One trick of the job was to use the pole to set the chain swinging to and fro first, so that the final heft was not quite so demanding on the muscles. This method of joining vehicles by means of simple chain links was known as loose coupling. Men of the Lancashire & Yorkshire Railway demonstrate the hand signals for ‘caution’, ‘all right’ and ‘danger’, c. 1910 It was possible to join or detach loose-coupled wagons quite rapidly. On 4 November 1879, a train was received from Manchester at Ponty-pool Road Yard, an important centre for traffic in South Wales. It consisted of three wagons each for Swansea, Cardiff and Whitland, two each for Pontypool, Llanelli, Neath and Neath Abbey and one each for Aberdare, Aberbeeg, Bridgend, Briton Ferry, Carmarthen, Cefn, Ebbw Vale, Haverfordwest, Newport and Pontypool (Town).

…

On their part, the workers would not have signed up in the first place had the railways not offered an attractive combination of secure and decently paid employment, usually with some prospect of promotion. Changes to these attitudes depended on wider shifts in working culture and class consciousness: the railwayman of 1850 and his descendant of 1910 might have the same job to do, but they conceptualised it in different ways. The long loose-coupled trains assembled by the shunters required considerable skill to operate safely. Responsibilities were split between the locomotive driver and the goods guard, who travelled in a brake van at the back. It was the goods guard’s job to help the driver to slow or halt the wagons by braking his own vehicle, which was heavily weighted by means of cast-iron ballast within the underframe, and to release the brakes when required.

…

The final scenes follow some of these goods beyond the railway: budgies receive seed in a Blackpool pet shop, Glaswegians get drunk on Somerset cider, a Highland granny trudges through snow in her Glastonbury-made sheepskin boots. This method of working had some crucial weaknesses. On the technical side, there was a conflict between the aspiration to phase out loose-coupled trains and the continuing dependence on individually marshalled consignments. From the shunter’s point of view, vacuum-braked wagons were much more burdensome to attach and detach, each operation requiring attention to brake pipes as well as couplings. So that the pipes were not jerked apart in transit, these wagons also had to be coupled more closely, like passenger coaches.

That Will Never Work: The Birth of Netflix and the Amazing Life of an Idea by Marc Randolph

Airbnb, Apollo 13, crowdsourcing, digital rights, high net worth, inventory management, Isaac Newton, Jeff Bezos, late fees, loose coupling, Mason jar, pets.com, recommendation engine, rolodex, Sand Hill Road, Silicon Valley, Silicon Valley startup, Snapchat, Steve Jobs, subscription business, tech worker, The last Blockbuster video rental store is in Bend, Oregon, Travis Kalanick

Give them clear coordinates and let them figure it out. It’s the same at a startup. Real innovation comes not from top-down pronouncements and narrowly defined tasks. It comes from hiring innovators focused on the big picture who can orient themselves within a problem and solve it without having their hand held the whole time. We call it being loosely coupled but tightly aligned. From the beginning, I resolved to treat everyone who worked at Netflix as an adult. At Borland, I’d seen what happened when companies decided not to do that. When I worked at Borland, the company was at its decadent eighties height. Set on a dozen beautifully landscaped acres, the campus boasted a koi pond in the lobby, a redwood grove, walking paths, a theater, a full restaurant, a health club with racquetball courts, weight rooms, fitness studios, and an Olympic-size pool.

…

Years later, Patty would end up revolutionizing the field of HR at Netflix, and much of her philosophy can be traced back to the realization we both had that day at Borland: People don’t want hot tubs—not really. They don’t want free snacks or Ping-Pong tables or kombucha on tap. What they really want is freedom and responsibility. They want to be loosely coupled but tightly aligned. Following one problem through its various guises and iterations should give you a good idea about how we functioned pre-launch. This particular problem brought us into contact with another young company, one with its own unique culture—a culture that couldn’t have been more different from ours.

Reactive Messaging Patterns With the Actor Model: Applications and Integration in Scala and Akka by Vaughn Vernon

A Pattern Language, business intelligence, business logic, business process, cloud computing, cognitive dissonance, domain-specific language, en.wikipedia.org, fault tolerance, finite state, functional programming, Internet of things, Kickstarter, loose coupling, remote working, type inference, web application

That’s because we cannot predict when the processor will schedule the tasks. It’s also why multithreaded code is considered nondeterministic. This is all pointing to the fact that multithreading inherently causes temporal coupling and dependencies among the threads. We’ve been trained to work hard to loosely couple our software objects, and yet the very nature of common multithreading programming models and practices forces us to couple in a manner that our brains can’t comprehend very well. What we need is an easier way to be multithreaded. If temporal coupling is a problem, then we should attempt to decouple temporally.

…

Oftentimes it is suggested to use a queue to manage work items for threads to perform. One thread enqueues new work items while worker threads dequeue work items, as shown in Figure 3.4. As each worker thread goes to the work queue to get its next task, this can ease the tension between threads. Each thread is now more loosely coupled from the others. Figure 3.4 One thread enqueues new work items while worker threads dequeue work items. One potential problem with this approach is that it creates a natural competition between consuming threads. If one thread tends to get the tasks that can be completed more quickly, it will constantly be locking the shared queue ahead of the other worker threads, causing the starvation of the others.

The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece by Ron Jeffries

Amazon Web Services, anti-pattern, bitcoin, business cycle, business intelligence, business logic, business process, c2.com, call centre, cloud computing, continuous integration, Conway's law, creative destruction, dark matter, data science, database schema, deep learning, DevOps, disinformation, duck typing, en.wikipedia.org, fail fast, fault tolerance, Firefox, Hacker News, industrial robot, information security, Infrastructure as a Service, Internet of things, Jeff Bezos, Kanban, Kubernetes, load shedding, loose coupling, machine readable, Mars Rover, microservices, Minecraft, minimum viable product, MITM: man-in-the-middle, Morris worm, move fast and break things, OSI model, peer-to-peer lending, platform as a service, power law, ransomware, revision control, Ruby on Rails, Schrödinger's Cat, Silicon Valley, six sigma, software is eating the world, source of truth, SQL injection, systems thinking, text mining, time value of money, transaction costs, Turing machine, two-pizza team, web application, zero day

They’re also persistent, so they can be examined to understand the system’s status—though that often requires some “digestion” to trace state transitions into current states. If you want to avoid tight coupling to a particular monitoring tool or framework, then log files are the way to go. Nothing is more loosely coupled than log files; every framework or tool that exists can scrape log files. This loose coupling means log files are also valuable in development, where you are less likely to find ops tools. Even in the face of this value, log files are badly abused. Here are some keys to successful logging. Log Locations Despite what all those application templates create for us, a logs directory under the application’s install directory is the wrong way to go.

Glasshouse by Charles Stross

air gap, cognitive dissonance, experimental subject, gravity well, lateral thinking, loose coupling, military-industrial complex, operational security, peer-to-peer, phenotype, prisoner's dilemma, sensible shoes, theory of mind, white picket fence

I try my netlink, but it's dull and frozen, showing nothing but a crashed listing of point scores allocated to my cohort. Curious Yellow, I think dully. That's why I can't hear Sam when he says * * *: the score-tracking system is based on Curious Yellow. A couple hundred meters from the berm I see signs of life. Something about the size of a taxi, consisting of loosely coupled rods and spheres, is hunching up over the crest of the deposit. It extends tubular sensors in my direction, then vaults over the crest of the hill, sensors blurring into iridescent disks, balland-rod assemblies spinning on its back. The balls are growing and thinning, unfolding like cauliflower heads that glow with a diffractive sheen.

…

As a consequence of the postwar fragmentation, we end up moving around a lot, shuffling our appearances and sometimes our memories, forking spares and merging deltas. At first we live off the capital freed up by the Cats' liquidation; later we supplement it by setting up a variety of business fronts. (If you've ever heard of the Deadly Viper Assassination Squad, or Cordwainer Heavy Industries, that's us.) Operationally, we work in loosely coupled cells. I'm one of the heavy hitters, my background in combat ops meshing neatly with my intelligence experience. About fifty megs after the official end of hostilities, I receive a summons to the Polity of the Jade Sunrise. It's a strictly tech-limiting polity, and I'm in ortho drag, my cover being a walkabout swordfighting instructor.

Why Things Bite Back: Technology and the Revenge of Unintended Consequences by Edward Tenner

air freight, Alfred Russel Wallace, animal electricity, blue-collar work, Charles Babbage, clean water, collective bargaining, computer age, dematerialisation, Donald Knuth, Edward Jenner, Exxon Valdez, gentrification, germ theory of disease, Herman Kahn, informal economy, job automation, John Harrison: Longitude, John von Neumann, Lewis Mumford, Loma Prieta earthquake, loose coupling, Louis Pasteur, machine translation, mass immigration, Menlo Park, nuclear winter, oil shock, placebo effect, planned obsolescence, Productivity paradox, Ralph Waldo Emerson, rising living standards, Robert X Cringely, safety bicycle, scientific management, Shoshana Zuboff, Silicon Valley, sugar pill, systems thinking, technoutopianism, The Soul of a New Machine, The Wealth of Nations by Adam Smith, Thomas Malthus, Thorstein Veblen, Triangle Shirtwaist Factory

System Effects The best framework for understanding the emerging systems of the late nineteenth century comes from the diagnosis of the sociologist Charles Perrow. Perrow has argued that certain technologies are so inherently unsafe that what is called "operator error" is actually made inevitable by the way in which parts of a system are related. Perrow has classified systems as tightly and loosely coupled. In human terms, even thousands of people on a crowded beach form a loosely coupled system. If a bodybuilding bully kicks sand in some weakling's face, or even if two bullies start to bully each other, the limited personal space around the bathers will usually suffice to confine the problem. There is open access at a number of points, and of course a smooth transition between sea and sand.

Seeking SRE: Conversations About Running Production Systems at Scale by David N. Blank-Edelman

Affordable Care Act / Obamacare, algorithmic trading, AlphaGo, Amazon Web Services, backpropagation, Black Lives Matter, Bletchley Park, bounce rate, business continuity plan, business logic, business process, cloud computing, cognitive bias, cognitive dissonance, cognitive load, commoditize, continuous integration, Conway's law, crowdsourcing, dark matter, data science, database schema, Debian, deep learning, DeepMind, defense in depth, DevOps, digital rights, domain-specific language, emotional labour, en.wikipedia.org, exponential backoff, fail fast, fallacies of distributed computing, fault tolerance, fear of failure, friendly fire, game design, Grace Hopper, imposter syndrome, information retrieval, Infrastructure as a Service, Internet of things, invisible hand, iterative process, Kaizen: continuous improvement, Kanban, Kubernetes, loose coupling, Lyft, machine readable, Marc Andreessen, Maslow's hierarchy, microaggression, microservices, minimum viable product, MVC pattern, performance metric, platform as a service, pull request, RAND corporation, remote working, Richard Feynman, risk tolerance, Ruby on Rails, Salesforce, scientific management, search engine result page, self-driving car, sentiment analysis, Silicon Valley, single page application, Snapchat, software as a service, software is eating the world, source of truth, systems thinking, the long tail, the scientific method, Toyota Production System, traumatic brain injury, value engineering, vertical integration, web application, WebSocket, zero day

Launch guidance and requirements will likely include the following: Defect counts and severity Does the application actually perform as designed? Type/frequency of pager alerts Is the application generating an unsupportable number of alerts in production? Monitoring coverage Is the coverage of monitoring sufficient to restore service when things go wrong? System architecture Is the service loosely coupled enough to support a high rate of changes and deployments in production? Deployment process Is there a predictable, deterministic, and sufficiently automated process to deploy code into production? Production hygiene Is there evidence of enough good production habits that would allow production support to be managed by anyone else?

…

If one bad node begins writing corrupt data to another node, that data can propagate through the system and corrupt an increasingly large share of your storage. These failures happen because distributed systems often have strong logical dependencies between components. The key to logical isolation is to build loosely coupled systems. Logical isolation is difficult to achieve. Database replicas will happily store corrupt data issued to them by the primary database. A quorum consensus protocol like Zookeeper will also suffer the same fate. These systems are not only tightly coupled from a durability perspective, they’re tightly coupled from an availability perspective: if a load spike leads to a failure of one component, there is usually an even greater load applied to the other components, which subsequently also fail.

…

So why would a company spend more than it needs to for storage? The abstraction boundary between storage regions makes it extremely hard for cascading issues to propagate across regions. The loose logical coupling and simple API makes it difficult for a bug or inconsistency in one region to impact the other. The loose coupling also makes it possible to take an entire region down in an emergency without impacting our end users; in fact, we take a region down every week as a test exercise. This architecture results in a system that is extremely reliable from an availability and durability perspective, without imposing a significant operational burden on the engineers who run the system.

Making Work Visible: Exposing Time Theft to Optimize Workflow by Dominica Degrandis, Tonianne Demaria

cloud computing, cognitive bias, cognitive load, DevOps, Elon Musk, en.wikipedia.org, informal economy, Jeff Bezos, Kanban, loose coupling, microservices, Parkinson's law, Sheryl Sandberg, sunk-cost fallacy, systems thinking, TED Talk, transaction costs, two-pizza team

., test teams within a project team are measured by the number of software bugs), whereas product teams are measured by the business value derived. Senior Director of Technology at Pivotal Cornelia Davis noted in conversation at the 2017 DOES Forum, “Architecture is so tied to how we do our work. The preferred architecture is loosely coupled components, individual microservices, built by individual teams—autonomous product teams, not project teams.”1 EXERCISE The “Oh, By the Way” Dependency Matrix PURPOSE: To bring visibility to dependencies across teams, to help people anticipate what’s headed their way, and to prevent delays from unknown or invisible dependencies.

Learn You a Haskell for Great Good!: A Beginner's Guide by Miran Lipovaca

fault tolerance, functional programming, higher-order functions, loose coupling, type inference

This means that it makes them available for the outside world to see and use. Having code split up into several modules has many advantages. If a module is generic enough, the functions it exports can be used in a multitude of different programs. If your own code is separated into self-contained modules that don’t rely on each other too much (we also say they are loosely coupled), you can reuse them later. Your code is more manageable when you split it into several parts. The Haskell standard library is split into modules, and each of them contains functions and types that are somehow related and serve some common purpose. There are modules for manipulating lists, concurrent programming, dealing with complex numbers, and so on.

…

See also functions, Modules, Modules, Modules, Modules, Importing Modules, Importing Modules, Importing Modules, Importing Modules, Enter Data.Map, Enter Data.Map, Hierarchical Modules, Improving Shape with the Point Data Type accessing from GHCi, Modules advantages of, Modules exporting functions, Enter Data.Map exporting shapes in, Improving Shape with the Point Data Type geometry, Enter Data.Map hierarchical, Hierarchical Modules importing, Importing Modules loosely coupled, Modules qualified imports of, Importing Modules reading source code for, Importing Modules referencing functions from, Importing Modules Monad instance, Reader? Ugh, Not This Joke Again monad laws, A Knight's Quest, Making Monads Monad type class, The Monad Type Class, The Monad Type Class, The Monad Type Class, The Monad Type Class, The Monad Type Class, The Monad Type Class, I'll Fly Away, Banana on a Wire, Banana on a Wire, Pierre Returns >> function, The Monad Type Class, Banana on a Wire >>= (bind) function, The Monad Type Class fail function, The Monad Type Class, I'll Fly Away, Pierre Returns Maybe instance, The Monad Type Class return function, The Monad Type Class monadic functions, Error Error on the Wall, liftM and Friends, The join Function, filterM, Composing Monadic Functions, Composing Monadic Functions composing, Composing Monadic Functions FilterM, The join Function FoldM, filterM join, liftM and Friends liftM, Error Error on the Wall MonadPlus type class, do Notation and List Comprehensions monads, Upgrading Our Applicative Functors, Upgrading Our Applicative Functors, Code, Code, Code, Banana on a Wire, Banana on a Wire, The List Monad, MonadPlus and the guard Function, MonadPlus and the guard Function, Monad Laws, Right Identity, Right Identity, For a Few Monads More, Reader?

Alternatives to Capitalism by Robin Hahnel, Erik Olin Wright

affirmative action, basic income, crowdsourcing, inventory management, iterative process, Kickstarter, loose coupling, means of production, Pareto efficiency, profit maximization, race to the bottom, tacit knowledge, transaction costs

The upshot of these arguments is that in the intellectual ecosystem of emancipatory thinking it is certainly desirable to have some people pushing ideas anchored in models of a unitary system-building totality. But we also need institutional pluralists who attempt to give precision to the idea of a heterogeneous loosely coupled system embodying emancipatory values. 5. The Ultimate Need for System-Rupture As in many of the themes in our dialogue, Robin and I have similar views about many aspects of the process of transformation. In particular, we share a strong commitment to struggles for progressive reforms, both because these can make life better for people and because they can help pave the road for more radical transformation in the future.

Collaborative Futures by Mike Linksvayer, Michael Mandiberg, Mushon Zer-Aviv

4chan, AGPL, Benjamin Mako Hill, British Empire, citizen journalism, cloud computing, collaborative economy, corporate governance, crowdsourcing, Debian, Eben Moglen, en.wikipedia.org, fake news, Firefox, informal economy, jimmy wales, Kickstarter, late capitalism, lolcat, loose coupling, Marshall McLuhan, means of production, Naomi Klein, Network effects, optical character recognition, packet switching, planned obsolescence, postnationalism / post nation state, prediction markets, Richard Stallman, semantic web, Silicon Valley, slashdot, Slavoj Žižek, stealth mode startup, technoutopianism, The future is already here, the medium is the message, The Wisdom of Crowds, web application, WikiLeaks, Yochai Benkler

Science 2.0 Let the future tell the truth and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I really worked, is mine. —Nikola Tesla Science is a prototypical example of collaboration, from closely coupled collaboration within a lab to the very loosely coupled collaboration of the grant scientific enterprise over centuries. However, Science has been slow to adopt modern tools and methods for collaboration. And the efforts to adopt or translate those new tools and methods have been broadly (and loosely) characterized as “Science 2.0” and “Open Science”, very roughly corresponding to “Web 2.0” and “Open Source”.

Army of None: Autonomous Weapons and the Future of War by Paul Scharre

"World Economic Forum" Davos, active measures, Air France Flight 447, air gap, algorithmic trading, AlphaGo, Apollo 13, artificial general intelligence, augmented reality, automated trading system, autonomous vehicles, basic income, Black Monday: stock market crash in 1987, brain emulation, Brian Krebs, cognitive bias, computer vision, cuban missile crisis, dark matter, DARPA: Urban Challenge, data science, deep learning, DeepMind, DevOps, Dr. Strangelove, drone strike, Elon Musk, en.wikipedia.org, Erik Brynjolfsson, facts on the ground, fail fast, fault tolerance, Flash crash, Freestyle chess, friendly fire, Herman Kahn, IFF: identification friend or foe, ImageNet competition, information security, Internet of things, Jeff Hawkins, Johann Wolfgang von Goethe, John Markoff, Kevin Kelly, Korean Air Lines Flight 007, Loebner Prize, loose coupling, Mark Zuckerberg, military-industrial complex, moral hazard, move 37, mutually assured destruction, Nate Silver, Nick Bostrom, PalmPilot, paperclip maximiser, pattern recognition, Rodney Brooks, Rubik’s Cube, self-driving car, sensor fusion, South China Sea, speech recognition, Stanislav Petrov, Stephen Hawking, Steve Ballmer, Steve Wozniak, Strategic Defense Initiative, Stuxnet, superintelligent machines, Tesla Model S, The Signal and the Noise by Nate Silver, theory of mind, Turing test, Tyler Cowen, universal basic income, Valery Gerasimov, Wall-E, warehouse robotics, William Langewiesche, Y2K, zero day

There is very little “slack” in the system—little time or flexibility for humans to intervene and exercise judgment, bend or break rules, or alter the system’s behavior. In the case of Three Mile Island, the sequence of failures that caused the initial accident happened within a mere thirteen seconds. It is the combination of complexity and tight coupling that makes accidents an expected, if infrequent, occurrence in such systems. In loosely coupled complex systems, such as bureaucracies or other human organizations, there is sufficient slack for humans to adjust to unexpected situations and manage failures. In tightly coupled systems, however, failures can rapidly cascade from one subsystem to the next and minor problems can quickly lead to system breakdown.

…

., 317 Kennedy, William, 155–56, 178 Khalitov, Vyacheslav, 116 Khmer Rouge, 288 Khrushchev, Nikita, 307, 317–18 kill box, 106–8 kill switches, 202, 230 Knight Capital Group, 201–2 Korea, see North Korea; South Korea Kosovo, U.S. air campaign over, 322–23 Kubrick, Stanley, 312 Kumar, Vijay, 70 Kuwait, 169 land mines and arms control, 267, 331–32, 342 CCW regulations, 268 humanitarian consequences, 50–51 and public conscience, 265–66 unbounded autonomy of, 270 Jody Williams’s campaign to ban, 271 Lawrence, Peter, 205 laws of war, 251–70 accountability gap and, 258–63 autonomous weapons and, 282–83 core principles, 251–52 debates over restriction/banning of autonomous weapons, 266–69 and dictates of public conscience, 263–66 hors de combat, 258–61 legal status of humans vs. machines, 269–70 need for human judgment’s place in, 357–59 precautions in attack, 258 principle of distinction, 252–55 principle of proportionality, 255–57 and unnecessary suffering, 257–58 learning systems, see deep learning neural networks Ledé, Jean-Charles, 72 Lee, Daniel, 70 LeMay, Curtis, 279, 296 lethal autonomy; see also autonomous weapons debate over, 6–8 DoD policy, 25, 95 liability, autonomous weapons and, 258–59 LIDAR (light detection and ranging), 121, 122 Lieber Code, 259 life-and-death choices, 2–8 limited weapons bans, 342 Limits of Safety (Sagan), 174–75 Lin, Patrick, 223 LOCAAS (Low Cost Autonomous Attack System), 49 Lockheed Martin, 63 Loew ben Bezalel, Rabbi Judah, 234 loitering munitions, 46–47, 97–98, 354 London Blitz, 342 Long-Range Anti-Ship Missile (LRASM), 62–68, 66f–67f, 353 loosely coupled systems, 152 low probability of intercept/low probability of detection (LPI/LPD), 72–73 M2 .50 caliber heavy machine gun (ma deuce), 38 M249 SAW light machine gun, 191 machine guns, 37–38, 190–91, 276–77, 299 machine intelligence, 231; see also intelligent machines MAD (mutual assured destruction), 314, 315 “mad robot theory,” 315–16 Main, Kevin, 138, 139 Making of a Fly (Lawrence), 205 mal en se, 285 malware, 211–13, 225, 246–47 management by exception/management by consent, 404n Marine warfare Continuous Trail Unmanned Vessel ACTUV (anti-sub), 78–79 Marrison, Clive, 109 MARS (A800 Mobile Autonomous Robotic System), 114 MARS (Mobile Autonomous Robotic System), 114 Marshall, Andy, 94 Marshall, S.

Digital Transformation at Scale: Why the Strategy Is Delivery by Andrew Greenway,Ben Terrett,Mike Bracken,Tom Loosemore

Airbnb, behavioural economics, bitcoin, blockchain, butterfly effect, call centre, chief data officer, choice architecture, cognitive dissonance, cryptocurrency, data science, Diane Coyle, en.wikipedia.org, fail fast, G4S, hype cycle, Internet of things, Kevin Kelly, Kickstarter, loose coupling, M-Pesa, machine readable, megaproject, minimum viable product, nudge unit, performance metric, ransomware, robotic process automation, Silicon Valley, social web, The future is already here, the long tail, the market place, The Wisdom of Crowds, work culture

Rather than adding more management, the best way to scale digital teams is to scale the unit of delivery to cope with discrete tasks as they arise. This means replicating the product teams. As a digital service gets more complex, you should add more multidisciplinary product teams with a mix of skills and perspectives to add complementary problems. The teams should be loosely coupled, but tightly aligned to meeting the needs of the same users. Crucially, these teams will include people with deep knowledge of frontline operations who can provide insights based on reality. This is not a quality traditionally associated with the layers of management that tend to accompany the process of scaling up a service.

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

Amazon Web Services, anti-pattern, bioinformatics, business logic, commoditize, corporate governance, create, read, update, delete, data acquisition, en.wikipedia.org, fault tolerance, linked data, loose coupling, Network effects, recommendation engine, semantic web, sentiment analysis, social graph, software as a service, SPARQL, the strength of weak ties, web application

Moreover, their high affinity with the underlying graph makes them tightly coupled to its structure: when the graph structure changes, they can often break. Cypher can be more tolerant of structural changes—things such as variable length paths help mitigate variation and change. The Traversal Framework is both more loosely coupled than the Core API (since it allows the developer to declare informational goals), and less verbose, and as a result a query written using the Traversal Framework typically requires less developer effort than the equivalent written using the Core API. Because it is a general-purpose frame‐ work, however, the Traversal Framework tends to perform marginally less well than a well-written Core API query.

Agile Project Management with Kanban (Developer Best Practices) by Eric Brechner

Amazon Web Services, cloud computing, continuous integration, crowdsourcing, data science, DevOps, don't repeat yourself, en.wikipedia.org, index card, Kaizen: continuous improvement, Kanban, loose coupling, minimum viable product, pull request, software as a service

Making tests pass provides positive reinforcement for unit testing. (In contrast, writing code and then writing unit tests that fail negatively reinforces unit testing.) In addition, code written using TDD is testable by design and implements only what’s tested, so it tends to have high coherence and loose coupling and does the minimum necessary to meet requirements—all attributes of well-designed code. You can leave the use of TDD up to team members if you want to (relying on healthy peer pressure). If you prefer to ingrain TDD into your Kanban workflow, you could call the Implement step “TDD” or make the Implement done rule something like, “Code is developed using TDD and reviewed, the static analysis is clean, the code is checked in, and the customer-facing documentation is complete.”

97 Things Every Programmer Should Know by Kevlin Henney

A Pattern Language, active measures, Apollo 11, business intelligence, business logic, commoditize, continuous integration, crowdsourcing, database schema, deliberate practice, domain-specific language, don't repeat yourself, Donald Knuth, fixed income, functional programming, general-purpose programming language, Grace Hopper, index card, inventory management, job satisfaction, level 1 cache, loose coupling, machine readable, Silicon Valley, sorting algorithm, The Wisdom of Crowds

Singletons don't. Singletons cause implicit dependencies between conceptually independent units of code. This is problematic both because they are hidden and because they introduce unnecessary coupling between units. This code smell becomes pungent when you try to write unit tests, which depend on loose coupling and the ability to selectively substitute a mock implementation for a real one. Singletons prevent such straightforward mocking. Singletons also carry implicit persistent state, which again hinders unit testing. Unit testing depends on tests being independent of one another, so the tests can be run in any order and the program can be set to a known state before the execution of every unit test.

Clean Agile: Back to Basics by Robert C. Martin

Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, Boeing 737 MAX, c2.com, cognitive load, continuous integration, DevOps, disinformation, double entry bookkeeping, en.wikipedia.org, failed state, Frederick Winslow Taylor, index card, iterative process, Kanban, Kubernetes, loose coupling, microservices, remote working, revision control, scientific management, Turing machine

., the two developers changed the same lines of code) it forced the programmer to resolve the conflict before allowing the checkin. This drastically shortened the cycle time to the time required to edit, compile, and test a series of small changes. Coupling was still an issue. A tightly coupled system maintained long cycle times because many modules had to be changed in unison. But a loosely coupled system could be cycled much more quickly. Checkout time was no longer the limiting factor. Git and Tests Nowadays we use Git. Checkout time using Git has shrunk to zero. The concept doesn’t exist. Rather, any alteration to a module can be committed at any time. Conflicts among these commits are resolved as and when the programmers desire.

Think Twice: Harnessing the Power of Counterintuition by Michael J. Mauboussin

affirmative action, Alan Greenspan, asset allocation, Atul Gawande, availability heuristic, Benoit Mandelbrot, Bernie Madoff, Black Swan, butter production in bangladesh, Cass Sunstein, choice architecture, Clayton Christensen, cognitive dissonance, collateralized debt obligation, Daniel Kahneman / Amos Tversky, deliberate practice, disruptive innovation, Edward Thorp, experimental economics, financial engineering, financial innovation, framing effect, fundamental attribution error, Geoffrey West, Santa Fe Institute, George Akerlof, hindsight bias, hiring and firing, information asymmetry, libertarian paternalism, Long Term Capital Management, loose coupling, loss aversion, mandelbrot fractal, Menlo Park, meta-analysis, money market fund, Murray Gell-Mann, Netflix Prize, pattern recognition, Performance of Mutual Funds in the Period, Philip Mirowski, placebo effect, Ponzi scheme, power law, prediction markets, presumed consent, Richard Thaler, Robert Shiller, statistical model, Steven Pinker, systems thinking, the long tail, The Wisdom of Crowds, ultimatum game, vertical integration

A system is tightly coupled when there is no slack between items, allowing a process to go from one stage to the next without any opportunity to intervene. Aircraft, space missions, and nuclear power plants are classic examples of complex, tightly coupled systems. Engineers try to build in buffers or redundancies to avoid failure, but frequently don’t anticipate all possible contingencies.22 Most complex adaptive systems are loosely coupled, where removing or incapacitating one or a few agents has little impact on the system’s performance. For example, if you randomly remove some investors, the stock market will continue to function fine. But when the agents lose diversity and behave in a coordinated fashion, a complex adaptive system can behave in a tightly coupled fashion.

Natural Language Processing with Python and spaCy by Yuli Vasiliev

Bayesian statistics, computer vision, data science, database schema, Easter island, en.wikipedia.org, loose coupling, natural language processing, Skype, statistical model

Notice that even if a sentence fails to fully satisfy the dep_pattern and pos_pattern functions, it might still match the pron_pattern function. For example, the sentence “I know it.” doesn’t match either the dep_pattern or pos_pattern functions, because it doesn’t have a modal auxiliary verb. But it satisfies pron_pattern because it contains a personal pronoun that is the direct object of the sentence. This loose coupling between the patterns lets you use them with other patterns or independently. For example, you might use dep_pattern, which checks a sentence against the “subject + auxiliary + verb + . . . + direct object . . .” pattern in conjunction with, say, a “noun + modal auxiliary verb + base form verb + . . . + noun . . .” pattern, if you wanted to be sure that the subject and the direct object in the sentence are nouns.

Programming Scala: tackle multicore complexity on the JVM by Venkat Subramaniam

augmented reality, business logic, continuous integration, domain-specific language, don't repeat yourself, functional programming, higher-order functions, loose coupling, semantic web, type inference, web application

As you learn the language, you can experiment with the language and its API by writing test cases. • It improves your design. It is very hard to unit test code that is large and complex. In order to test it, you’d end up making the code smaller. This will lead to a better design by making the code more cohesive, loosely coupled, easier to understand, and easier to maintain. Unit testing is a low-hanging fruit in Scala. You have three options— you can use JUnit, TestNG, or ScalaTest. We will start with JUnit in this chapter and then see how to use ScalaTest, which is a tool written in Scala. 12.1 Using JUnit Using JUnit to run tests written in Scala is really simple.

Learning Android by Marko Gargenta

business logic, create, read, update, delete, database schema, Firefox, loose coupling, slashdot, SQL injection, web application

This goal will introduce us to one type of broadcast receiver. Timeline Receiver This type of receiver will exist only at certain times. Also, it won’t receive messages from the Android system, but from other parts of our own Yamba application. This will demonstrate how we can use receivers to put together loosely coupled components in an elegant and flexible way. Permissions At this point in the development process you know how to ask for system permissions, such as access to the Internet or filesystem. In this section we’ll learn how to define our own permissions and how to enforce them. After all, Yamba components might not want to respond to any other application for some Yamba-specific actions.

Ansible for DevOps: Server and Configuration Management for Humans by Jeff Geerling

Abraham Maslow, AGPL, Amazon Web Services, cloud computing, continuous integration, database schema, Debian, defense in depth, DevOps, fault tolerance, Firefox, full text search, Google Chrome, inventory management, loose coupling, microservices, Minecraft, MITM: man-in-the-middle, punch-card reader, Ruby on Rails, web application

I generally split tasks into separate files once I reach 15-20 tasks in a given file. Use Roles to bundle logical groupings of configuration Along the same lines as using included files to better organize your playbooks and separate bits of configuration logically, Ansible roles can supercharge your ability to manage infrastructure well. Using loosely-coupled roles to configure individual components of your servers (like databases, application deployments, the networking stack, monitoring packages, etc.) allows you to write configuration once, and use it on all your servers, regardless of their role. Consider that you will probably configure something like NTP (Network Time Protocol) on every single server you manage, or at a minimum, set a timezone for the server.

Developing Backbone.js Applications by Addy Osmani

Airbnb, anti-pattern, business logic, create, read, update, delete, don't repeat yourself, Firefox, full text search, Google Chrome, Khan Academy, Kickstarter, loose coupling, MVC pattern, node package manager, pull request, Ruby on Rails, side project, single page application, web application

As Sharon Cichelli says: “semantics will continue to be important, until we learn how to communicate in something other than language”. Modular Development Introduction When we say an application is modular, we generally mean it’s composed of a set of highly decoupled, distinct pieces of functionality stored in modules. As you probably know, loose coupling facilitates easier maintainability of apps by removing dependencies where possible. When this is implemented efficiently, it’s quite easy to see how changes to one part of a system may affect another. Unlike some more traditional programming languages, the current iteration of JavaScript (ECMA-262) doesn’t provide developers with the means to import such modules of code in a clean, organized manner.

Vue.js 2 Cookbook by Andrea Passaglia

bitcoin, business logic, cognitive load, functional programming, Kickstarter, Large Hadron Collider, loose coupling, MVC pattern, node package manager, Silicon Valley, single page application, web application, WebSocket

Having components all the way down makes your program, no matter how big, workable in isolated chunks. You can always add a new one without affecting others, and you can always throw away what you don't need, being sure that nothing will break. Actually, this will be the ideal situation. The truth is that writing well isolated (loosely coupled) components is not always straightforward. There might be the case that two components are meant to work together or they have a specific way to communicate with each other. If you follow the recipes in this chapter with attention and dedication, you will take mostly the good sides of components, and you will learn how to avoid some common pitfalls.

Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson

airport security, anti-pattern, business intelligence, call centre, collapse of Lehman Brothers, continuous integration, corporate governance, database schema, domain-specific language, index card, Kaizen: continuous improvement, Kanban, knowledge worker, lateral thinking, loose coupling, performance metric, six sigma, systems thinking, tacit knowledge, Toyota Production System, transaction costs

The best strategy for reduction of variability due to defects is to relentlessly pursue high quality with very low defect counts. Making changes to the software development lifecycle process can greatly affect defect rates. Use of peer reviews, pair programming, unit tests, automated testing frameworks, continuous (or very frequent) integration, small batch sizes, cleanly defined architectures, and well-factored, loosely coupled, highly cohesive code design will greatly reduce defects. Changes that directly affect defect rates and indirectly improve the predictability of the system are directly under the control of the local management and the team. External Sources of Variability External sources of variability come from places that are not directly controlled by the software development process or project management method.

Data Mining: Concepts, Models, Methods, and Algorithms by Mehmed Kantardzić

Albert Einstein, algorithmic bias, backpropagation, bioinformatics, business cycle, business intelligence, business process, butter production in bangladesh, combinatorial explosion, computer vision, conceptual framework, correlation coefficient, correlation does not imply causation, data acquisition, discrete time, El Camino Real, fault tolerance, finite state, Gini coefficient, information retrieval, Internet Archive, inventory management, iterative process, knowledge worker, linked data, loose coupling, Menlo Park, natural language processing, Netflix Prize, NP-complete, PageRank, pattern recognition, peer-to-peer, phenotype, random walk, RFID, semantic web, speech recognition, statistical model, Telecommunications Act of 1996, telemarketer, text mining, traveling salesman, web application

Providing support for all these features in DDM systems requires novel solutions. The Web architecture, with layered protocols and services, provides a sound framework for supporting DDM. The new framework embraces the growing trend of merging computation with communication. DDM accepts the fact that data may be inherently distributed among different loosely coupled sites, often with heterogeneous data, and connected by a network. It offers techniques to discover new knowledge through distributed data analysis and modeling using minimal communication of data. Also, interactions in a distributed system need to be implemented in a reliable, stable, and scalable way.

…

In either case, it is likely that a large number of plots are generated, and therefore it is a challenge to organize the plots in such a way that meaningful comparisons are possible. Visualization has been used routinely in data mining as a presentation tool to generate initial views, navigate data with complicated structures, and convey the results of an analysis. Generally, the analytical methods themselves do not involve visualization. The loosely coupled relationships between visualization and analytical data-mining techniques represent the majority of today’s state-of-the-art in visual data mining. The process-sandwich strategy, which interlaces analytical processes with graphical visualization, penalizes both procedures with the other’s deficiencies and limitations.

Lab Rats: How Silicon Valley Made Work Miserable for the Rest of Us by Dan Lyons

"Friedman doctrine" OR "shareholder theory", "Susan Fowler" uber, "World Economic Forum" Davos, Airbnb, Amazon Robotics, Amazon Web Services, antiwork, Apple II, augmented reality, autonomous vehicles, basic income, Big Tech, bitcoin, blockchain, Blue Ocean Strategy, business process, call centre, Cambridge Analytica, Clayton Christensen, clean water, collective bargaining, corporate governance, corporate social responsibility, creative destruction, cryptocurrency, data science, David Heinemeier Hansson, digital rights, Donald Trump, Elon Musk, Ethereum, ethereum blockchain, fake news, full employment, future of work, gig economy, Gordon Gekko, greed is good, Hacker News, hiring and firing, holacracy, housing crisis, impact investing, income inequality, informal economy, initial coin offering, Jeff Bezos, job automation, job satisfaction, job-hopping, John Gruber, John Perry Barlow, Joseph Schumpeter, junk bonds, Kanban, Kevin Kelly, knowledge worker, Larry Ellison, Lean Startup, loose coupling, Lyft, Marc Andreessen, Mark Zuckerberg, McMansion, Menlo Park, Milgram experiment, minimum viable product, Mitch Kapor, move fast and break things, new economy, Panopticon Jeremy Bentham, Parker Conrad, Paul Graham, paypal mafia, Peter Thiel, plutocrats, precariat, prosperity theology / prosperity gospel / gospel of success, public intellectual, RAND corporation, remote working, RFID, ride hailing / ride sharing, Ronald Reagan, Rubik’s Cube, Ruby on Rails, Sam Altman, San Francisco homelessness, Sand Hill Road, scientific management, self-driving car, shareholder value, Sheryl Sandberg, Silicon Valley, Silicon Valley startup, six sigma, Skinner box, Skype, Social Responsibility of Business Is to Increase Its Profits, SoftBank, software is eating the world, Stanford prison experiment, stem cell, Steve Jobs, Steve Wozniak, Stewart Brand, stock buybacks, super pumped, TaskRabbit, tech bro, tech worker, TechCrunch disrupt, TED Talk, telemarketer, Tesla Model S, Thomas Davenport, Tony Hsieh, Toyota Production System, traveling salesman, Travis Kalanick, tulip mania, Uber and Lyft, Uber for X, uber lyft, universal basic income, web application, WeWork, Whole Earth Catalog, work culture , workplace surveillance , Y Combinator, young professional, Zenefits

Spotify’s version of “team, not a family” is a claim that to protect the company’s culture, “firing is also crucial.” Patreon’s culture deck echoes McCord’s language about “high performance” and says only “world-class talent” gets retained. Financial start-up eShares claims the company is “managed like a professional sports team,” with groups that are “loosely coupled, highly aligned,” a phrase from McCord. Culture codes have become a thing, and it’s an icky, stupid, pointless thing. As Tom Peters once told me, “As soon as you put it down in writing and put it up on a wall, you’re screwed. That’s not culture.” Harvard psychologist and author of Presence Amy Cuddy talks about “insta-culture”—the notion that a company can make up a code, go buy a Ping-Pong table, and voilà—they’ve got a culture.

Beginning Backbone.js by James Sugrue

Airbnb, business logic, continuous integration, don't repeat yourself, Firefox, Google Chrome, loose coupling, MVC pattern, node package manager, single page application, web application, Y Combinator

Leveraging th e Mediator Pattern Another popular pattern in JavaScript applications is the Mediator pattern, which helps enforce better levels of decoupling between modules. The Mediator pattern is known as a behavioral pattern because it deals with the relationships and responsibilities between objects. The definition in the Gang of Four book states that the pattern does the following: “allows loose coupling by encapsulating the way disparate sets of objects interact and communicate with each other. Allows for the actions of each object set to vary independently of one another.” The best analogy for this pattern is an airport control tower: the tower (mediator) looks after who can take off and land, and all communication to and from planes goes through the control tower, rather than having each plane communicate with one another.

The Mind Is Flat: The Illusion of Mental Depth and the Improvised Mind by Nick Chater

Albert Einstein, battle of ideas, behavioural economics, classic study, computer vision, Daniel Kahneman / Amos Tversky, deep learning, double helix, Geoffrey Hinton, Henri Poincaré, Jacquard loom, lateral thinking, loose coupling, machine translation, speech recognition, tacit knowledge

So our ability to carry out several mental activities ‘in parallel’ will be severely limited. There are, though, tasks for which our neural ‘machinery’ is, conveniently, largely separate. One clear-cut example is the operation of the ‘autonomic’ nervous system, which runs our heart, breathing, digestion, and so on. These neural circuits are only loosely coupled with the cortex – so that, thankfully, our heart can keep beating, our lungs breathing, and our stomachs digesting, even while we focus our attention on a tricky problem or a good book. But what about more complex tasks? Perhaps if the tasks are sufficiently different, they might not use overlapping networks in the brain – and if so, perhaps they could operate independently and hence simultaneously.

Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century by Jeff Lawson

Airbnb, AltaVista, Amazon Web Services, barriers to entry, big data - Walmart - Pop Tarts, Big Tech, big-box store, bitcoin, business process, call centre, Chuck Templeton: OpenTable:, cloud computing, coronavirus, COVID-19, create, read, update, delete, cryptocurrency, data science, David Heinemeier Hansson, deep learning, DevOps, Elon Musk, financial independence, global pandemic, global supply chain, Hacker News, Internet of things, Jeff Bezos, Kanban, Lean Startup, loose coupling, Lyft, Marc Andreessen, Marc Benioff, Mark Zuckerberg, microservices, minimum viable product, Mitch Kapor, move fast and break things, Paul Graham, peer-to-peer, ride hailing / ride sharing, risk tolerance, Ruby on Rails, Salesforce, side project, Silicon Valley, Silicon Valley startup, Skype, social distancing, software as a service, software is eating the world, sorting algorithm, Startup school, Steve Ballmer, Steve Jobs, Telecommunications Act of 1996, Toyota Production System, transaction costs, transfer pricing, two-pizza team, Uber and Lyft, uber lyft, ubercab, web application, Y Combinator

Composable over Monolithic Our software is based on a microservices architecture composed of hundreds of microservices. Each microservice performs a single function or capability. The advantage of microservices is that we can route around or absorb a failure. If one service fails, it won’t bring down the entire Twilio voice system, for example. The services are all loosely coupled. They’re all built by different teams, who can work independently. One microservice might be version one or two, and another might be on version five. But as long as they all “speak” to the API that connects them, that’s fine. Platforms: The Software That Makes the Software In Ford v Ferrari, the film about Ford’s quest to win the 24 Hours of Le Mans race, there’s a great scene where Ford has finally managed to defeat Ferrari at Le Mans with an astonishing race car called the GT40.

Rapid GUI Programming With Python and Qt by Mark Summerfield

Debian, duck typing, Guido van Rossum, loose coupling, MVC pattern, software patent, sorting algorithm, web application

This approach saves memory, at the price of some speed overhead. For tiny dialogs like this, the overhead is too small for the user to notice, but later on we will show an alternative approach that avoids creating and destroying dialogs every time. Using a dumb dialog means that the dialog is quite loosely coupled to the application. We could completely decouple it by making the labels accessible as instance variables. Then we could use the PenPropertiesDlg to edit any kind of data that required a spinbox, a checkbox, and a combobox, simply by changing the labels. For example, we could use it to record a weather reading with a “Temperature” spinbox, an “Is raining” checkbox, and a “Cloud cover” combobox.

…

Summary We categorized dialogs into three “intelligences”, dumb, standard, and smart, and showned that they can be used modally or modelessly. Dumb dialogs are easy to create, and are perfectly adequate for doing widget-level validation. Dumb dialogs are normally used modally, and if we are careful they can be generalized since they can be very loosely coupled to the application’s logic. Nonetheless, using dumb dialogs usually ends up leading to programmer frustration and the need to rewrite in the form of a standard or smart dialog, so it is often best to avoid them except for those very simple cases where just one or two values are required and the built-in QInputDialog static dialogs are not suitable.

Hadoop: The Definitive Guide by Tom White

Amazon Web Services, bioinformatics, business intelligence, business logic, combinatorial explosion, data science, database schema, Debian, domain-specific language, en.wikipedia.org, exponential backoff, fallacies of distributed computing, fault tolerance, full text search, functional programming, Grace Hopper, information retrieval, Internet Archive, Kickstarter, Large Hadron Collider, linked data, loose coupling, openstreetmap, recommendation engine, RFID, SETI@home, social graph, sparse data, web application

ZooKeeper is highly available ZooKeeper runs on a collection of machines and is designed to be highly available, so applications can depend on it. ZooKeeper can help you avoid introducing single points of failure into your system, so you can build a reliable application. ZooKeeper facilitates loosely coupled interactions ZooKeeper interactions support participants that do not need to know about one another. For example, ZooKeeper can be used as a rendezvous mechanism so that processes that otherwise don’t know of each other’s existence (or network details) can discover and interact with each other.

…

Zab is described in “A simple totally ordered broadcast protocol” by Benjamin Reed and Flavio Junqueira (LADIS ’08: Proceedings of the 2nd Workshop on Large-Scale Distributed Systems and Middleware, pages 1–6, New York, NY, USA, 2008. ACM). Google’s Chubby Lock Service (Mike Burrows, “The Chubby Lock Service for Loosely-Coupled Distributed Systems,” November 2006, http://labs.google.com/papers/chubby.html), which shares similar goals with ZooKeeper, is based on Paxos. If the leader fails, the remaining machines hold another leader election and continue as before with the new leader. If the old leader later recovers, it then starts as a follower.

Richard Dawkins: How a Scientist Changed the Way We Think by Alan Grafen; Mark Ridley

Alfred Russel Wallace, Arthur Eddington, bioinformatics, Charles Babbage, cognitive bias, computer age, Computing Machinery and Intelligence, conceptual framework, Dava Sobel, double helix, Douglas Hofstadter, Easter island, epigenetics, Fellow of the Royal Society, Haight Ashbury, interchangeable parts, Isaac Newton, Johann Wolfgang von Goethe, John von Neumann, loose coupling, Murray Gell-Mann, Necker cube, phenotype, profit maximization, public intellectual, Ronald Reagan, Stephen Hawking, Steven Pinker, the scientific method, theory of mind, Thomas Kuhn: the structure of scientific revolutions, Yogi Berra, zero-sum game

The coefficient of relationship, r, translates easily into ‘blood’, and the human mind, already sophisticated in the intuitive calculus of blood ties and proportionate altruism races to apply the concept of inclusive fitness to a re-evaluation of its own social impulses. But the Hamilton viewpoint is also unstructured. The conventional parameters of population genetics, allele frequencies, mutation rates, epistasis, migration, group size, and so forth, are mostly omitted from the equations. As a result, Hamilton’s mode of reasoning can be only loosely coupled with the remainder of genetic theory, and the number of predictions it can make is unnecessarily limited. From Wilson, Sociobiology: The New Synthesis (1975), 119-120. 20 According to Wilson: Williams’ Canon was a healthy reaction to the excesses of explanation invoking group selection and higher social structure in populations ...

The Pragmatic Programmer by Andrew Hunt, Dave Thomas

A Pattern Language, Broken windows theory, business logic, business process, buy low sell high, c2.com, combinatorial explosion, continuous integration, database schema, domain-specific language, don't repeat yourself, Donald Knuth, Ford Model T, Free Software Foundation, general-purpose programming language, George Santayana, Grace Hopper, higher-order functions, if you see hoof prints, think horses—not zebras, index card, Kaizen: continuous improvement, lateral thinking, loose coupling, Menlo Park, MVC pattern, off-by-one error, premature optimization, Ralph Waldo Emerson, revision control, Schrödinger's Cat, slashdot, sorting algorithm, speech recognition, systems thinking, the Cathedral and the Bazaar, traveling salesman, urban decay, Y2K

Simple components can be designed, coded, unit tested, and then forgotten—there is no need to keep changing existing code as you add new code. An orthogonal approach also promotes reuse. If components have specific, well-defined responsibilities, they can be combined with new components in ways that were not envisioned by their original implementors. The more loosely coupled your systems, the easier they are to reconfigure and reengineer. There is a fairly subtle gain in productivity when you combine orthogonal components. Assume that one component does M distinct things and another does N things. If they are orthogonal and you combine them, the result does M x N things.

Bad Data Handbook by Q. Ethan McCallum

Amazon Mechanical Turk, asset allocation, barriers to entry, Benoit Mandelbrot, business intelligence, cellular automata, chief data officer, Chuck Templeton: OpenTable:, cloud computing, cognitive dissonance, combinatorial explosion, commoditize, conceptual framework, data science, database schema, DevOps, en.wikipedia.org, Firefox, Flash crash, functional programming, Gini coefficient, hype cycle, illegal immigration, iterative process, labor-force participation, loose coupling, machine readable, natural language processing, Netflix Prize, One Laptop per Child (OLPC), power law, quantitative trading / quantitative finance, recommendation engine, selection bias, sentiment analysis, SQL injection, statistical model, supply-chain management, survivorship bias, text mining, too big to fail, web application

For this reason, it is important to be able to cheaply (in human and compute time) be able to experiment with rerunning our clustering with altered inputs. The inputs we alter may remove data from a particular source, or add a new topic modeling stage between crawling and clustering. In order to achieve this, our infrastructure must be loosely coupled such that we can just as easily provide inputs to our clustering system for testing as we do in production. Popularity Calculating story popularity shares many of the same issues as clustering stories. As we experiment, or debug an issue, we want to quickly test our changes and see the result.

The Internet Trap: How the Digital Economy Builds Monopolies and Undermines Democracy by Matthew Hindman

A Declaration of the Independence of Cyberspace, accounting loophole / creative accounting, activist fund / activist shareholder / activist investor, AltaVista, Amazon Web Services, barriers to entry, Benjamin Mako Hill, bounce rate, business logic, Cambridge Analytica, cloud computing, computer vision, creative destruction, crowdsourcing, David Ricardo: comparative advantage, death of newspapers, deep learning, DeepMind, digital divide, discovery of DNA, disinformation, Donald Trump, fake news, fault tolerance, Filter Bubble, Firefox, future of journalism, Ida Tarbell, incognito mode, informal economy, information retrieval, invention of the telescope, Jeff Bezos, John Perry Barlow, John von Neumann, Joseph Schumpeter, lake wobegon effect, large denomination, longitudinal study, loose coupling, machine translation, Marc Andreessen, Mark Zuckerberg, Metcalfe’s law, natural language processing, Netflix Prize, Network effects, New Economic Geography, New Journalism, pattern recognition, peer-to-peer, Pepsi Challenge, performance metric, power law, price discrimination, recommendation engine, Robert Metcalfe, search costs, selection bias, Silicon Valley, Skype, sparse data, speech recognition, Stewart Brand, surveillance capitalism, technoutopianism, Ted Nelson, The Chicago School, the long tail, The Soul of a New Machine, Thomas Malthus, web application, Whole Earth Catalog, Yochai Benkler

Retrieved from http://www.newyorker.com/online/blogs/elements/2013/05/the -evolution-of-google-design.html. 208 • Bibliography Bucy, E. (2004). Second generation net news: interactivity and information accessibility in the online environment. International Journal on Media Management, 6 (1–2), 102–13. Burrows, M. (2006). The Chubby lock service for loosely-coupled distributed systems. In Proceedings of the 7th Symposium on Operating Systems Design and Implementation, Seattle, WA (pp. 335–50). USENIX Association. Cadwalladr, C., and Graham-Harrison, E. (2018, March). Revealed: 50 million Facebook profiles harvested for Cambridge Analytica in major data breach.

2034: A Novel of the Next World War by Elliot Ackerman, James Admiral Stavridis

coronavirus, COVID-19, creative destruction, cuban missile crisis, digital map, loose coupling, mutually assured destruction, South China Sea, sovereign wealth fund, undersea cable

As improbably as he had arrived, Minister Chiang was gone. 5 On Death Ground 02:38 July 01, 2034 (GMT+8) South China Sea From the nose cone rearward, his eyes ran the line of the fuselage. He ducked under the flared wings and walked in a crouch to each of their tips, brushing their leading edge with the pads of his four fingers as he checked for a dent, a loose coupling, any compromise in their aerodynamics. He made his way back to the dark, gaping exhaust of the twin engines. He stuck his head inside each afterburner, inhaled deeply, and shut his eyes. God, how he loved that smell: jet fuel. Next, in a single leap, like a house cat assuming its perch on a favorite windowsill, he hoisted himself onto the back of the Hornet.

Deep Survival: Who Lives, Who Dies, and Why by Laurence Gonzales

business climate, butterfly effect, complexity theory, Edward Lorenz: Chaos theory, impulse control, Lao Tzu, loose coupling, Louis Pasteur, Neil Armstrong, power law, systems thinking

As they moved up, they stored more and more as potential energy in the system, which was tightly coupled because of the rope. It was like blowing up a balloon. The tiniest pinprick, an almost imperceptible force, can release the air all at once. The climbers would have been better off if they had tried to descend the slope with no safety system at all. When a system is tightly coupled, the effects spread. In a loosely coupled system, effects do not spread to other parts of the system. Falling dominoes are a familiar illustration of how tight coupling works. Move the dominoes farther apart and knock one over: only one will fall. If the climbers had not been roped together, Ward wouldn’t have taken everyone else with him.

Adapt: Why Success Always Starts With Failure by Tim Harford

An Inconvenient Truth, Andrew Wiles, banking crisis, Basel III, behavioural economics, Berlin Wall, Bernie Madoff, Black Swan, Boeing 747, business logic, car-free, carbon footprint, carbon tax, Cass Sunstein, charter city, Clayton Christensen, clean water, cloud computing, cognitive dissonance, complexity theory, corporate governance, correlation does not imply causation, creative destruction, credit crunch, Credit Default Swap, crowdsourcing, cuban missile crisis, Daniel Kahneman / Amos Tversky, Dava Sobel, Deep Water Horizon, Deng Xiaoping, disruptive innovation, double entry bookkeeping, Edmond Halley, en.wikipedia.org, Erik Brynjolfsson, experimental subject, Fall of the Berlin Wall, Fermat's Last Theorem, financial engineering, Firefox, food miles, Gerolamo Cardano, global supply chain, Great Leap Forward, Herman Kahn, Intergovernmental Panel on Climate Change (IPCC), Isaac Newton, Jane Jacobs, Jarndyce and Jarndyce, Jarndyce and Jarndyce, John Harrison: Longitude, knowledge worker, loose coupling, Martin Wolf, mass immigration, Menlo Park, Mikhail Gorbachev, mutually assured destruction, Netflix Prize, New Urbanism, Nick Leeson, PageRank, Piper Alpha, profit motive, Richard Florida, Richard Thaler, rolodex, Shenzhen was a fishing village, Silicon Valley, Silicon Valley startup, South China Sea, SpaceShipOne, special economic zone, spectrum auction, Steve Jobs, supply-chain management, tacit knowledge, the market place, The Wisdom of Crowds, too big to fail, trade route, Tyler Cowen, Tyler Cowen: Great Stagnation, Virgin Galactic, web application, X Prize, zero-sum game

A change in US student visa policy; or a new government scheme to fund research; or the appearance of a fashionable book in economics, or physics, or anthropology; or an internecine academic row – all could have unpredictable consequences for Harvard and trigger a range of unexpected responses, but none will spiral out of control quickly enough to destroy the university altogether. So far, this book has looked at complex but loosely coupled systems, like Harvard. The sheer complexity of such systems means that failures are part of life, and the art of success is to fail productively. But what if a system is both complex and tightly coupled? Complexity means there are many different ways for things to go wrong. Tight coupling means the unintended consequences proliferate so quickly that it is impossible to adapt to the failure or to try something different.

Beautiful security by Andy Oram, John Viega

Albert Einstein, Amazon Web Services, An Inconvenient Truth, Bletchley Park, business intelligence, business process, call centre, cloud computing, corporate governance, credit crunch, crowdsourcing, defense in depth, do well by doing good, Donald Davies, en.wikipedia.org, fault tolerance, Firefox, information security, loose coupling, Marc Andreessen, market design, MITM: man-in-the-middle, Monroe Doctrine, new economy, Nicholas Carr, Nick Leeson, Norbert Wiener, operational security, optical character recognition, packet switching, peer-to-peer, performance metric, pirate software, Robert Bork, Search for Extraterrestrial Intelligence, security theater, SETI@home, Silicon Valley, Skype, software as a service, SQL injection, statistical model, Steven Levy, the long tail, The Wisdom of Crowds, Upton Sinclair, web application, web of trust, zero day, Zimmermann PGP

Some technologies (such as popular file-sharing protocols such as Common Internet File System [CIFS] and LAN-based synchronization protocols such as Address Resolution Protocol [ARP]) take this local environment for granted. But those foundations become irrelevant as tasks, messages, and data travel a mesh of loosely coupled nodes. The effect is similar to the effects of global commerce, which takes away the advantage of renting storefront property on your town’s busy Main Street or opening a bank office near a busy seaport or railway station. Tasks are routed by sophisticated business rules engines that determine whether a call center message should be routed to India or China, or whether the cheapest supplier for a particular good has the inventory in stock.

The Everything Store: Jeff Bezos and the Age of Amazon by Brad Stone

airport security, Amazon Mechanical Turk, Amazon Web Services, AOL-Time Warner, Apollo 11, bank run, Bear Stearns, Bernie Madoff, big-box store, Black Swan, book scanning, Brewster Kahle, buy and hold, call centre, centre right, Chuck Templeton: OpenTable:, Clayton Christensen, cloud computing, collapse of Lehman Brothers, crowdsourcing, cuban missile crisis, Danny Hillis, deal flow, Douglas Hofstadter, drop ship, Elon Musk, facts on the ground, fulfillment center, game design, housing crisis, invention of movable type, inventory management, James Dyson, Jeff Bezos, John Markoff, junk bonds, Kevin Kelly, Kiva Systems, Kodak vs Instagram, Larry Ellison, late fees, loose coupling, low skilled workers, Maui Hawaii, Menlo Park, Neal Stephenson, Network effects, new economy, off-the-grid, optical character recognition, PalmPilot, pets.com, Ponzi scheme, proprietary trading, quantitative hedge fund, reality distortion field, recommendation engine, Renaissance Technologies, RFID, Rodney Brooks, search inside the book, shareholder value, Silicon Valley, Silicon Valley startup, six sigma, skunkworks, Skype, SoftBank, statistical arbitrage, Steve Ballmer, Steve Jobs, Steven Levy, Stewart Brand, the long tail, Thomas L Friedman, Tony Hsieh, two-pizza team, Virgin Galactic, Whole Earth Catalog, why are manhole covers round?, zero-sum game

These teams would be independently set loose on Amazon’s biggest problems. They would likely compete with one another for resources and sometimes duplicate their efforts, replicating the Darwinian realities of surviving in nature. Freed from the constraints of intracompany communication, Bezos hoped, these loosely coupled teams could move faster and get features to customers quicker. There were some head-scratching aspects to Bezos’s two-pizza-team concept. Each group was required to propose its own “fitness function”—a linear equation that it could use to measure its own impact without ambiguity. For example, a two-pizza team in charge of sending advertising e-mails to customers might choose for its fitness function the rate at which these messages were opened multiplied by the average order size those e-mails generated.

The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise by Nathan L. Ensmenger

barriers to entry, business process, Charles Babbage, Claude Shannon: information theory, computer age, deskilling, Donald Knuth, Firefox, Frederick Winslow Taylor, functional programming, future of work, Grace Hopper, informal economy, information retrieval, interchangeable parts, Isaac Newton, Jacquard loom, job satisfaction, John von Neumann, knowledge worker, Larry Ellison, loose coupling, machine readable, new economy, no silver bullet, Norbert Wiener, pattern recognition, performance metric, Philip Mirowski, post-industrial society, Productivity paradox, RAND corporation, Robert Gordon, scientific management, Shoshana Zuboff, sorting algorithm, Steve Jobs, Steven Levy, systems thinking, tacit knowledge, technological determinism, the market place, The Theory of the Leisure Class by Thorstein Veblen, Thomas Kuhn: the structure of scientific revolutions, Thorstein Veblen, Turing machine, Von Neumann architecture, world market for maybe five computers, Y2K

His model can be summarized briefly as follows: 1) professions grow when occupational niches become available to them, and they change when their particular territory becomes threatened; 2) the critical events in professional development are struggles over jurisdictions, and key environmental changes involve the creation or abolition of jurisdictions; and 3) professional struggle occurs at three levels: the workplace, culture and public opinion, and legal and administrative rules. These levels are loosely coupled. Most shifts in jurisdiction start in the workplace, move to public opinion, and may end up in the legal sphere. Hence, the most consequential struggles are over competence and theory—the core jurisdiction. Increasing abstraction allows for professional expansion, but overabstraction can dilute the core jurisdiction.37 My argument is that just one of these jurisdictional struggles occurred on commercial computing in the late 1960s.

Binge Times: Inside Hollywood's Furious Billion-Dollar Battle to Take Down Netflix by Dade Hayes, Dawn Chmielewski

activist fund / activist shareholder / activist investor, Airbnb, Albert Einstein, Amazon Web Services, AOL-Time Warner, Apollo 13, augmented reality, barriers to entry, Big Tech, borderless world, cloud computing, cognitive dissonance, content marketing, coronavirus, corporate raider, COVID-19, data science, digital rights, Donald Trump, Downton Abbey, Elon Musk, George Floyd, global pandemic, Golden age of television, haute cuisine, hockey-stick growth, invention of the telephone, Jeff Bezos, John Markoff, Jony Ive, late fees, lockdown, loose coupling, Marc Andreessen, Mark Zuckerberg, Mitch Kapor, Netflix Prize, Osborne effect, performance metric, period drama, Phoebe Waller-Bridge, QR code, reality distortion field, recommendation engine, remote working, Ronald Reagan, Salesforce, Saturday Night Live, Silicon Valley, skunkworks, Skype, Snapchat, social distancing, Steve Jobs, subscription business, tech bro, the long tail, the medium is the message, TikTok, Tim Cook: Apple, vertical integration, WeWork

“We’ve always said it’s a team, not a family,” says Hastings. Netflix alums often are snapped up by new employers, given the halo around the company. But many employees express concern that “radical transparency” is just another phrase for “office politics.” Terms sprinkled throughout the Culture Deck like “highly aligned, loosely coupled” and “north star” feel like a language members of a secret society might use to reinforce an “us versus them” narrative. “You’re using those words in how you do business,” said one former executive. “In your emails. In the way you talk to your colleagues. It’s using that language and those words in order for you to understand one another.”

Docker: Up & Running: Shipping Reliable Containers in Production by Sean P. Kane, Karl Matthias

Airbnb, Amazon Web Services, business logic, business process, cloud computing, Colossal Cave Adventure, continuous integration, Debian, DevOps, don't repeat yourself, false flag, interchangeable parts, Kubernetes, loose coupling, Lyft, microservices, revision control, software as a service, source of truth, web application

With Docker, you achieve this by dynamically deploying and decommissioning con‐ tainers as requirements and load fluctuate so that your application is always able to handle server requests quickly, without deploying a lot of underutilized resources. Message-Driven Reactive systems rely on asynchronous message passing to establish a boundary between components that ensures loose coupling, isolation, and location transparency. Although not directly addressed by Docker, the idea here is that there are times when an application can become busy or unavailable. If you utilize asynchronous message passing between your services, you can help ensure that your services will not lose requests and that they will be processed as soon as possible.

What to Think About Machines That Think: Today's Leading Thinkers on the Age of Machine Intelligence by John Brockman

Adam Curtis, agricultural Revolution, AI winter, Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, algorithmic trading, Anthropocene, artificial general intelligence, augmented reality, autism spectrum disorder, autonomous vehicles, backpropagation, basic income, behavioural economics, bitcoin, blockchain, bread and circuses, Charles Babbage, clean water, cognitive dissonance, Colonization of Mars, complexity theory, computer age, computer vision, constrained optimization, corporate personhood, cosmological principle, cryptocurrency, cuban missile crisis, Danny Hillis, dark matter, data science, deep learning, DeepMind, Demis Hassabis, digital capitalism, digital divide, digital rights, discrete time, Douglas Engelbart, driverless car, Elon Musk, Emanuel Derman, endowment effect, epigenetics, Ernest Rutherford, experimental economics, financial engineering, Flash crash, friendly AI, functional fixedness, global pandemic, Google Glasses, Great Leap Forward, Hans Moravec, hive mind, Ian Bogost, income inequality, information trail, Internet of things, invention of writing, iterative process, James Webb Space Telescope, Jaron Lanier, job automation, Johannes Kepler, John Markoff, John von Neumann, Kevin Kelly, knowledge worker, Large Hadron Collider, lolcat, loose coupling, machine translation, microbiome, mirror neurons, Moneyball by Michael Lewis explains big data, Mustafa Suleyman, natural language processing, Network effects, Nick Bostrom, Norbert Wiener, paperclip maximiser, pattern recognition, Peter Singer: altruism, phenotype, planetary scale, Ray Kurzweil, Recombinant DNA, recommendation engine, Republic of Letters, RFID, Richard Thaler, Rory Sutherland, Satyajit Das, Search for Extraterrestrial Intelligence, self-driving car, sharing economy, Silicon Valley, Skype, smart contracts, social intelligence, speech recognition, statistical model, stem cell, Stephen Hawking, Steve Jobs, Steven Pinker, Stewart Brand, strong AI, Stuxnet, superintelligent machines, supervolcano, synthetic biology, systems thinking, tacit knowledge, TED Talk, the scientific method, The Wisdom of Crowds, theory of mind, Thorstein Veblen, too big to fail, Turing machine, Turing test, Von Neumann architecture, Watson beat the top human players on Jeopardy!, We are as Gods, Y2K

Designed intelligence will increasingly rely on synthetic biology and organic fabrication, in which neural circuitry will be grown from genetically modified cells and spontaneously self-assemble into networks of functional modules. Initially the designers will be humans, but soon they’ll be replaced by altogether smarter DI systems themselves, triggering a runaway process of complexification. Unlike in the case of human brains, which are only loosely coupled via communication channels, DI systems will be directly and comprehensively coupled, abolishing any concept of individual “selves” and raising the level of cognitive activity (“thinking”) to unprecedented heights. It’s possible (just) that some of this designed biocircuitry will incorporate quantum effects, moving toward Frank Wilczek’s notion of “quintelligence.”

Machines of Loving Grace: The Quest for Common Ground Between Humans and Robots by John Markoff

A Declaration of the Independence of Cyberspace, AI winter, airport security, Andy Rubin, Apollo 11, Apple II, artificial general intelligence, Asilomar, augmented reality, autonomous vehicles, backpropagation, basic income, Baxter: Rethink Robotics, Bill Atkinson, Bill Duvall, bioinformatics, Boston Dynamics, Brewster Kahle, Burning Man, call centre, cellular automata, Charles Babbage, Chris Urmson, Claude Shannon: information theory, Clayton Christensen, clean water, cloud computing, cognitive load, collective bargaining, computer age, Computer Lib, computer vision, crowdsourcing, Danny Hillis, DARPA: Urban Challenge, data acquisition, Dean Kamen, deep learning, DeepMind, deskilling, Do you want to sell sugared water for the rest of your life?, don't be evil, Douglas Engelbart, Douglas Engelbart, Douglas Hofstadter, Dr. Strangelove, driverless car, dual-use technology, Dynabook, Edward Snowden, Elon Musk, Erik Brynjolfsson, Evgeny Morozov, factory automation, Fairchild Semiconductor, Fillmore Auditorium, San Francisco, From Mathematics to the Technologies of Life and Death, future of work, Galaxy Zoo, General Magic , Geoffrey Hinton, Google Glasses, Google X / Alphabet X, Grace Hopper, Gunnar Myrdal, Gödel, Escher, Bach, Hacker Ethic, Hans Moravec, haute couture, Herbert Marcuse, hive mind, hype cycle, hypertext link, indoor plumbing, industrial robot, information retrieval, Internet Archive, Internet of things, invention of the wheel, Ivan Sutherland, Jacques de Vaucanson, Jaron Lanier, Jeff Bezos, Jeff Hawkins, job automation, John Conway, John Markoff, John Maynard Keynes: Economic Possibilities for our Grandchildren, John Maynard Keynes: technological unemployment, John Perry Barlow, John von Neumann, Kaizen: continuous improvement, Kevin Kelly, Kiva Systems, knowledge worker, Kodak vs Instagram, labor-force participation, loose coupling, Marc Andreessen, Mark Zuckerberg, Marshall McLuhan, medical residency, Menlo Park, military-industrial complex, Mitch Kapor, Mother of all demos, natural language processing, Neil Armstrong, new economy, Norbert Wiener, PageRank, PalmPilot, pattern recognition, Philippa Foot, pre–internet, RAND corporation, Ray Kurzweil, reality distortion field, Recombinant DNA, Richard Stallman, Robert Gordon, Robert Solow, Rodney Brooks, Sand Hill Road, Second Machine Age, self-driving car, semantic web, Seymour Hersh, shareholder value, side project, Silicon Valley, Silicon Valley startup, Singularitarianism, skunkworks, Skype, social software, speech recognition, stealth mode startup, Stephen Hawking, Steve Ballmer, Steve Jobs, Steve Wozniak, Steven Levy, Stewart Brand, Strategic Defense Initiative, strong AI, superintelligent machines, tech worker, technological singularity, Ted Nelson, TED Talk, telemarketer, telepresence, telepresence robot, Tenerife airport disaster, The Coming Technological Singularity, the medium is the message, Thorstein Veblen, Tony Fadell, trolley problem, Turing test, Vannevar Bush, Vernor Vinge, warehouse automation, warehouse robotics, Watson beat the top human players on Jeopardy!, We are as Gods, Whole Earth Catalog, William Shockley: the traitorous eight, zero-sum game

By the end of the 1990s Cheyer was ready for a new challenge. The dot-com era was in full swing and he decided to commercialize his ideas. The business-to-business Internet was exploding and everywhere there were services that needed to be interconnected. His research was a perfect fit for the newly popular idea of loosely coupled control. In a world of networked computers, software that allowed them to cooperate was just beginning to be designed. He was following a similar path to Marty Tenenbaum’s, the AI researcher who had created CommerceNet, the company for which Tom Gruber built ontologies. One of a small group of Silicon Valley researchers who realized early on that the Internet would become the glue that connected all commerce, Cheyer went to a competitor called VerticalNet, where he created a research lab and was soon made VP of engineering.

Click Here to Kill Everybody: Security and Survival in a Hyper-Connected World by Bruce Schneier

23andMe, 3D printing, air gap, algorithmic bias, autonomous vehicles, barriers to entry, Big Tech, bitcoin, blockchain, Brian Krebs, business process, Citizen Lab, cloud computing, cognitive bias, computer vision, connected car, corporate governance, crowdsourcing, cryptocurrency, cuban missile crisis, Daniel Kahneman / Amos Tversky, David Heinemeier Hansson, disinformation, Donald Trump, driverless car, drone strike, Edward Snowden, Elon Musk, end-to-end encryption, fault tolerance, Firefox, Flash crash, George Akerlof, incognito mode, industrial robot, information asymmetry, information security, Internet of things, invention of radio, job automation, job satisfaction, John Gilmore, John Markoff, Kevin Kelly, license plate recognition, loose coupling, market design, medical malpractice, Minecraft, MITM: man-in-the-middle, move fast and break things, national security letter, Network effects, Nick Bostrom, NSO Group, pattern recognition, precautionary principle, printed gun, profit maximization, Ralph Nader, RAND corporation, ransomware, real-name policy, Rodney Brooks, Ross Ulbricht, security theater, self-driving car, Seymour Hersh, Shoshana Zuboff, Silicon Valley, smart cities, smart transportation, Snapchat, sparse data, Stanislav Petrov, Stephen Hawking, Stuxnet, supply-chain attack, surveillance capitalism, The Market for Lemons, Timothy McVeigh, too big to fail, Uber for X, Unsafe at Any Speed, uranium enrichment, Valery Gerasimov, Wayback Machine, web application, WikiLeaks, Yochai Benkler, zero day

A RESILIENT INTERNET According to sociologist Charles Perrow’s theory of complexity, complex systems are less secure than simpler ones and, as a result, attacks and accidents involving complex systems are both more prevalent and more damaging. But Perrow demonstrates that not all complexity is created equal. In particular, complex systems that are both nonlinear and tightly coupled are more fragile. For example, the air traffic control system is a loosely coupled system. Both individual air traffic control towers and airplanes have failures all the time, but because the different parts of the system only mildly affect the others, the results are rarely catastrophic. Yes, you can read headlines about this or that airport being in chaos as a result of computer problems, but you rarely read about planes crashing into buildings, mountains, or each other.

Test-Driven Development With Python by Harry J. W. Percival

business logic, continuous integration, database schema, Debian, DevOps, don't repeat yourself, duck typing, Firefox, loose coupling, MVC pattern, off-by-one error, platform as a service, pull request, web application, WebSocket

Imagine something like this: Book.objects.filter(in_print=True, pub_date__lte=datetime.today()) Versus a helper method, like: Book.all_available_books() 350 | Chapter 19: Test Isolation, and “Listening to Your Tests” www.it-ebooks.info When we build helper functions, we can give them names that express what we are doing in terms of the business domain, which can actually make our code more legible, as well as giving us the benefit of keeping all ORM calls at the model layer, and thus making our whole application more loosely coupled. Finally, Moving Down to the Models Layer At the models layer, we no longer need to write isolated tests—the whole point of the models layer is to integrate with the database, so it’s appropriate to write integrated tests: lists/tests/test_models.py (ch19l026). class ListModelTest(TestCase): def test_get_absolute_url(self): list_ = List.objects.create() self.assertEqual(list_.get_absolute_url(), '/lists/%d/' % (list_.id,)) def test_create_new_creates_list_and_first_item(self): List.create_new(first_item_text='new item text') new_item = Item.objects.first() self.assertEqual(new_item.text, 'new item text') new_list = List.objects.first() self.assertEqual(new_item.list, new_list) Which gives: TypeError: create_new() got an unexpected keyword argument 'first_item_text' And that will take us to a first cut implementation that looks like this: lists/models.py (ch19l027).

How to Build a Billion Dollar App: Discover the Secrets of the Most Successful Entrepreneurs of Our Time by George Berkowski

Airbnb, Amazon Web Services, Andy Rubin, barriers to entry, Black Swan, business intelligence, call centre, crowdsourcing, deal flow, Dennis Tito, disruptive innovation, Dunbar number, en.wikipedia.org, game design, Google Glasses, Google Hangouts, Google X / Alphabet X, growth hacking, iterative process, Jeff Bezos, Jony Ive, Kickstarter, knowledge worker, Lean Startup, loose coupling, Marc Andreessen, Mark Zuckerberg, Mary Meeker, minimum viable product, MITM: man-in-the-middle, move fast and break things, Network effects, Oculus Rift, Paul Graham, QR code, Ruby on Rails, Salesforce, self-driving car, Sheryl Sandberg, Silicon Valley, Silicon Valley startup, Skype, Snapchat, social graph, SoftBank, software as a service, software is eating the world, Steve Jobs, Steven Levy, subscription business, TechCrunch disrupt, Travis Kalanick, two-pizza team, ubercab, Y Combinator

Team members, particularly super-talented ones, who cause friction and pain in the organisation need to be let go, no matter what the cost. It’s always tough to fire team members who perform exceptionally well but generate issues with other team members. The health of the organisation is always more important than a single individual. We had to make the call to remove key team members a couple of times at Hailo. • Loose coupling of components is critical. You can’t have one component fail and take down the entire system. Build resilience into your organisation, processes and systems. By hiring the best people – and ones with a variety of strong talents – you’re going to build in redundancy, and the ability to weather big team challenges, as Square was able to

Software Design for Flexibility by Chris Hanson, Gerald Sussman

Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, connected car, domain-specific language, Donald Knuth, en.wikipedia.org, functional programming, Guido van Rossum, higher-order functions, interchangeable parts, loose coupling, Magellanic Cloud, phenotype, premature optimization, Richard Stallman, stem cell, the scientific method, Turing machine, type inference

This is an important principle: rather than rewriting a program to adapt it to a new purpose, it's preferable to start with a simple and general base program and wrap it to specialize it for a particular purpose. The program doesn't know anything about the wrappers, and the wrappers make few assumptions about the underlying program. And the unit-specializer procedure knows very little about either. Because these parts are so loosely coupled, they can each be generalized for many purposes, including those we aren't thinking about here. This is a kind of layering strategy, which we will expand upon in chapter 6. Exercise 2.11: Implementing unit conversions Here we ask you to fill in the details that make this system work. a.

Programming Scala by Unknown

billion-dollar mistake, business logic, domain-specific language, duck typing, en.wikipedia.org, fault tolerance, functional programming, general-purpose programming language, higher-order functions, information security, loose coupling, type inference, web application

Scala Tools, Libraries, and IDE Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 Command-Line Tools scalac Command-Line Tool The scala Command-Line Tool The scalap, javap, and jad Command-Line Tools The scaladoc Command-Line Tool The sbaz Command-Line Tool The fsc Command-Line Tool Build Tools Integration with IDEs Eclipse IntelliJ NetBeans Text Editors Test-Driven Development in Scala ScalaTest Specs ScalaCheck Other Notable Scala Libraries and Tools Lift Scalaz Scalax MetaScala JavaRebel Miscellaneous Smaller Libraries Java Interoperability Java and Scala Generics Using Scala Functions in Java JavaBean Properties AnyVal Types and Java Primitives Scala Names in Java Code Java Library Interoperability AspectJ The Spring Framework 343 343 345 350 352 352 353 353 353 354 356 359 360 361 361 363 365 367 367 367 368 368 368 368 369 369 371 374 375 375 377 377 381 Table of Contents | xiii Download at WoweBook.Com Terracotta Hadoop Recap and What’s Next 384 384 385 Appendix: References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 xiv | Table of Contents Download at WoweBook.Com Foreword If there has been a common theme throughout my career as a programmer, it has been the quest for better abstractions and better tools to support the craft of writing software. Over the years, I have come to value one trait more than any other: composability. If one can write code with good composability, it usually means that other traits we software developers value—such as orthogonality, loose coupling, and high cohesion— are already present. It is all connected. When I discovered Scala some years ago, the thing that made the biggest impression on me was its composability. Through some very elegant design choices and simple yet powerful abstractions that were taken from the object-oriented and functional programming worlds, Martin Odersky has managed to create a language with high cohesion and orthogonal, deep abstractions that invites composability in all dimensions of software design.

Twitter and Tear Gas: The Power and Fragility of Networked Protest by Zeynep Tufekci

"Hurricane Katrina" Superdome, 4chan, active measures, Affordable Care Act / Obamacare, algorithmic bias, AltaVista, Alvin Toffler, Andy Carvin, anti-communist, Bernie Sanders, Black Lives Matter, bread and circuses, British Empire, citizen journalism, collective bargaining, conceptual framework, context collapse, crowdsourcing, digital divide, disinformation, Donald Trump, Edward Snowden, end-to-end encryption, Evgeny Morozov, fake news, feminist movement, Ferguson, Missouri, Filter Bubble, Future Shock, gentrification, Howard Rheingold, income inequality, index card, interchangeable parts, invention of movable type, invention of writing, John Gilmore, John Perry Barlow, loose coupling, Mahatma Gandhi, Mark Zuckerberg, Menlo Park, Mikhail Gorbachev, moral hazard, moral panic, Naomi Klein, Network effects, new economy, obamacare, Occupy movement, offshore financial centre, pre–internet, race to the bottom, RAND corporation, real-name policy, ride hailing / ride sharing, Rosa Parks, sharing economy, Silicon Valley, Skype, Snapchat, Streisand effect, the strength of weak ties, The Structural Transformation of the Public Sphere, The Theory of the Leisure Class by Thorstein Veblen, Thorstein Veblen, Twitter Arab Spring, We are the 99%, WikiLeaks, Yochai Benkler

Furthermore, through their algorithms, design choices, and terms-of-service rules, increasingly centralized platforms determine the architecture and the ground rules about how people can represent their identities online, as well as their methods of building reputation. Critical parameters include whether online and offline identities are tightly or loosely coupled, and whether social interactions online create persistent histories and a reputation that are visible to those with whom users interact. Social platforms differ in whether a pseudonym can serve to build a reputation and maintain continuity in the online identity even if it is not directly linked to offline identity.

The Book of Why: The New Science of Cause and Effect by Judea Pearl, Dana Mackenzie

affirmative action, Albert Einstein, AlphaGo, Asilomar, Bayesian statistics, computer age, computer vision, Computing Machinery and Intelligence, confounding variable, correlation coefficient, correlation does not imply causation, Daniel Kahneman / Amos Tversky, data science, deep learning, DeepMind, driverless car, Edmond Halley, Elon Musk, en.wikipedia.org, experimental subject, Great Leap Forward, Gregor Mendel, Isaac Newton, iterative process, John Snow's cholera map, Loebner Prize, loose coupling, Louis Pasteur, Menlo Park, Monty Hall problem, pattern recognition, Paul Erdős, personalized medicine, Pierre-Simon Laplace, placebo effect, Plato's cave, prisoner's dilemma, probability theory / Blaise Pascal / Pierre de Fermat, randomized controlled trial, Recombinant DNA, selection bias, self-driving car, seminal paper, Silicon Valley, speech recognition, statistical model, Stephen Hawking, Steve Jobs, strong AI, The Design of Experiments, the scientific method, Thomas Bayes, Turing test

I entered the arena rather late, in 1982, with an obvious yet radical proposal: instead of reinventing a new uncertainty theory from scratch, let’s keep probability as a guardian of common sense and merely repair its computational deficiencies. More specifically, instead of representing probability in huge tables, as was previously done, let’s represent it with a network of loosely coupled variables. If we only allow each variable to interact with a few neighboring variables, then we might overcome the computational hurdles that had caused other probabilists to stumble. The idea did not come to me in a dream; it came from an article by David Rumelhart, a cognitive scientist at University of California, San Diego, and a pioneer of neural networks.

Iron Sunrise by Stross, Charles

blood diamond, disinformation, dumpster diving, Future Shock, gravity well, hiring and firing, industrial robot, life extension, loose coupling, mass immigration, military-industrial complex, mutually assured destruction, phenotype, planetary scale, postindustrial economy, quantum entanglement, RFID, side project, speech recognition, technological singularity, trade route, urban sprawl, zero-sum game

Not that anyone had actually asked her if she wanted to be subjected to the bizarre cultural ritual known as “schooling,” locked up for half her waking hours in an institution populated by imbeciles, sadistic sociopaths, bullies, and howling maniacs, with another three years to go before the Authorities would let her out. Especially because at fifteen in Moscow system she’d been within two years of adulthood — but in Septagon, you didn’t even get out of high school until you were twenty-two. Centris Magna was part of the Septagon system, a loosely coupled cluster of brown dwarf stars with no habitable planets, settled centuries ago. It was probably the Eschaton’s heavy-handed idea of a joke: a group called the space settlers’ society had found themselves the sole proprietors of a frigid, barely terraformed asteroid, with a year’s supply of oxygen and some heavy engineering equipment for company.

Water: A Biography by Giulio Boccaletti

active transport: walking or cycling, Anthropocene, Asian financial crisis, Bretton Woods, British Empire, business cycle, clean water, conceptual framework, Corn Laws, deindustrialization, demographic transition, Deng Xiaoping, energy transition, financial engineering, Great Leap Forward, invisible hand, John Snow's cholera map, joint-stock company, land reform, land tenure, linear programming, loose coupling, market fundamentalism, mass immigration, means of production, Medieval Warm Period, megaproject, Mohammed Bouazizi, new economy, Nixon triggered the end of the Bretton Woods system, oil shock, opioid epidemic / opioid crisis, Peace of Westphalia, phenotype, scientific management, South China Sea, Suez crisis 1956, text mining, the long tail, The Rise and Fall of American Growth, The Wealth of Nations by Adam Smith, trade route, Washington Consensus, Works Progress Administration, Yom Kippur War, zero-sum game

It echoed the island of Utopia in More’s story, artificially separated from land by a fifteen-mile-wide canal that had been an imagined feat of engineering. The nineteenth century had been the pinnacle of private enterprise, a time of concession contracts and of companies, the natural evolution of medieval principles and their classical inheritance. But now, a new, powerful state was going to be the principal developer of the landscape. The loose coupling between human society and the water environment, one based on variability of the latter and adaptation of the former, one that had lasted for the better part of eight thousand years, had come to an end. From now on, human society was expecting predictability, stability, and control as a fundamental trait of the res publica.

Principles of Protocol Design by Robin Sharp

accounting loophole / creative accounting, business process, discrete time, exponential backoff, fault tolerance, finite state, functional programming, Gödel, Escher, Bach, information retrieval, loose coupling, MITM: man-in-the-middle, OSI model, packet switching, quantum cryptography, RFC: Request For Comment, stochastic process

In this book we have not said much about how actually to calculate or estimate quantitative parameters of a network with a view to optimising routing. An excellent source with much useful material on routing and congestion, including quantitative aspects, is Bertsekas and Gallagher’s book “Data Networks” [11]. The types of routing which we have concentrated on here are the ones most used in loosely-coupled distributed systems, where the physical separation of the component systems is ‘large’ and the topology of the network (for cost reasons) correspondingly sparse. In tightly-coupled multiprocessor systems, where the separation is ‘small’, more fully-connected networks are often used, and special routing algorithms have been developed to take advantage of this.

Mastering Blockchain, Second Edition by Imran Bashir

3D printing, altcoin, augmented reality, autonomous vehicles, bitcoin, blockchain, business logic, business process, carbon footprint, centralized clearinghouse, cloud computing, connected car, cryptocurrency, data acquisition, Debian, disintermediation, disruptive innovation, distributed ledger, Dogecoin, domain-specific language, en.wikipedia.org, Ethereum, ethereum blockchain, fault tolerance, fiat currency, Firefox, full stack developer, general-purpose programming language, gravity well, information security, initial coin offering, interest rate swap, Internet of things, litecoin, loose coupling, machine readable, MITM: man-in-the-middle, MVC pattern, Network effects, new economy, node package manager, Oculus Rift, peer-to-peer, platform as a service, prediction markets, QR code, RAND corporation, Real Time Gross Settlement, reversible computing, RFC: Request For Comment, RFID, ride hailing / ride sharing, Satoshi Nakamoto, seminal paper, single page application, smart cities, smart contracts, smart grid, smart meter, supply-chain management, transaction costs, Turing complete, Turing machine, Vitalik Buterin, web application, x509 certificate

The key idea behind sharding is to split up the tasks into multiple chunks that are then processed by multiple nodes. This results in improved throughput and reduced storage requirements. In blockchains, a similar scheme is employed whereby the state of the network is partitioned into multiple shards. The state usually includes balances, code, nonce, and storage. Shards are loosely coupled partitions of a blockchain that run on the same network. There are a few challenges related to inter-shard communication and consensus on the history of each shard. This is an open area for research. State channels This is another approach proposed for speeding up the transaction on a blockchain network.

The Future of the Internet: And How to Stop It by Jonathan Zittrain

A Declaration of the Independence of Cyberspace, algorithmic bias, Amazon Mechanical Turk, Andy Kessler, barriers to entry, behavioural economics, book scanning, Brewster Kahle, Burning Man, c2.com, call centre, Cass Sunstein, citizen journalism, Citizen Lab, Clayton Christensen, clean water, commoditize, commons-based peer production, corporate governance, Daniel Kahneman / Amos Tversky, digital divide, disruptive innovation, distributed generation, en.wikipedia.org, end-to-end encryption, Firefox, folksonomy, Free Software Foundation, game design, Hacker Ethic, Howard Rheingold, Hush-A-Phone, illegal immigration, index card, informal economy, information security, Internet Archive, jimmy wales, John Markoff, John Perry Barlow, license plate recognition, loose coupling, mail merge, Morris worm, national security letter, old-boy network, One Laptop per Child (OLPC), OSI model, packet switching, peer-to-peer, post-materialism, pre–internet, price discrimination, profit maximization, radical decentralization, Ralph Nader, RFC: Request For Comment, RFID, Richard Stallman, Richard Thaler, risk tolerance, Robert Bork, Robert X Cringely, SETI@home, Silicon Valley, Skype, slashdot, software patent, Steve Ballmer, Steve Jobs, Ted Nelson, Telecommunications Act of 1996, the Cathedral and the Bazaar, the long tail, The Nature of the Firm, The Wisdom of Crowds, Tragedy of the Commons, web application, wikimedia commons, Yochai Benkler, zero-sum game

Such a blessing would cure the material in question of its unlawful character, because the infringement would then be authorized. Yet at the same time, a copyright holder may be loath to issue DMCA notices to try to get material removed each time it appears, because clips can serve a valuable promotional function. The DMCA regime maintains a loose coupling between the law’s violation and its remedy, asking publishers to step forward and affirmatively declare that they want specific material wiped out as it arises and giving publishers the luxury to accede to some uses without forcing intermediaries to assume that the copyright holder would have wanted the material to be taken down.

Cities Under Siege: The New Military Urbanism by Stephen Graham

"hyperreality Baudrillard"~20 OR "Baudrillard hyperreality", addicted to oil, airport security, Alan Greenspan, Anthropocene, anti-communist, autonomous vehicles, Berlin Wall, call centre, carbon footprint, clean tech, clean water, congestion charging, creative destruction, credit crunch, DARPA: Urban Challenge, defense in depth, deindustrialization, digital map, disinformation, Dr. Strangelove, driverless car, edge city, energy security, European colonialism, export processing zone, failed state, Food sovereignty, gentrification, Gini coefficient, global supply chain, Global Witness, Google Earth, illegal immigration, income inequality, knowledge economy, late capitalism, Lewis Mumford, loose coupling, machine readable, market fundamentalism, mass incarceration, McMansion, megacity, military-industrial complex, moral panic, mutually assured destruction, Naomi Klein, New Urbanism, offshore financial centre, one-state solution, pattern recognition, peak oil, planetary scale, post-Fordism, private military company, Project for a New American Century, RAND corporation, RFID, Richard Florida, Scramble for Africa, Seymour Hersh, Silicon Valley, SimCity, smart transportation, surplus humans, The Bell Curve by Richard Herrnstein and Charles Murray, urban decay, urban planning, urban renewal, urban sprawl, Washington Consensus, white flight, white picket fence

‘As the state machine acts stealthily to prevent things happening’, Richard Sennett writes, ‘as its technologies become built into the fabric of everyday business practice, there can be no defining moment when an ordinary citizen could declare, “now I am more secure”’.137 This impossibility is compounded by the fact that it is basically futile to try to turn the infrastructures of everyday life–which, by definition, attain usefulness only through their openness–into truly secure systems which cannot be attacked or appropriated by terrorists. It would be much more effective in the long run, as sociologist Langdon Winner argues, to work towards designing and developing infrastructures ‘that are loosely coupled and forgiving, structured in ways that make disruptions easily borne, quickly repaired’.138 Urban planner Matt Hidek points out, however, that centralized command-and-control military paradigms have been creeping into the management of US civil infrastructures, owing to the efforts of the Department of Homeland Security and the new US Northern Command, or NORTHCOM.139 The danger here, of course, is the chipping away of democratic rights and liberties, and the progressive expansion towards globe-spanning surveillance, which, as discussed in Chapter 4, in their attempt to parallel global circulations, become as boundless as the purported threat.

Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin

bioinformatics, business cycle, business intelligence, business logic, business process, continuous integration, corporate governance, fail fast, hiring and firing, index card, inventory management, iterative process, Kanban, Lean Startup, loose coupling, minimum viable product, performance metric, shareholder value, six sigma, tacit knowledge, Y2K, you are the product

The INVEST criteria are Independent, Negotiable, Valuable, Estimatable, Small (sized appropriately), and Testable. When we combine the information derived from applying each criterion, we get a clear picture of what, if any, additional changes we might want to make to a story. Let’s examine each criterion. Independent As much as is practical, user stories should be independent or at least only loosely coupled with one another. Stories that exhibit a high degree of interdependence complicate estimating, prioritizing, and planning. For example, on the left side of Figure 5.8, story #10 depends on many other stories. Figure 5.8. Highly dependent stories Before we can work on story #10, we must first develop all of the dependent stories.

The TypeScript Workshop: A Practical Guide to Confident, Effective TypeScript Programming by Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matthew Thomas Morgan, Wekoslav Stefanovski

Ada Lovelace, Albert Einstein, business logic, Charles Babbage, create, read, update, delete, don't repeat yourself, Donald Knuth, fault tolerance, Firefox, full stack developer, functional programming, Google Chrome, Hacker News, higher-order functions, inventory management, Kickstarter, loose coupling, node package manager, performance metric, QR code, Ruby on Rails, SQL injection, type inference, web application, WebSocket

Note Coupling is about how tightly integrated/dependent two components (usually classes) are, in the sense that if we change one of them, how likely is the other to break without applicable changes to it too? The more tightly integrated/connected two components are to one another, the more coupled they are, and vice versa. Ideally, changing one class should not require changes in others. In such cases, the classes are considered decoupled (or loosely coupled). To make InversifyJS work, we first need to add a polyfill for reflect-metadata, which allows libraries to perform runtime reflection on objects to get their types in a more powerful manner than the (currently) built-in typeof and instanceof operators. In addition, since InverisfyJS works through decorators, you need to enable them by setting experimentalDecorators and emitDecoratorMetadata to true in your project's tsconfig.json file (note the bold lines): { "compilerOptions": { "target": "es5", "lib": ["es6", "dom"], "types": ["reflect-metadata"], "module": "commonjs", "moduleResolution": "node", "experimentalDecorators": true, "emitDecoratorMetadata": true } } Note There are additional requirements in order for InversifyJS to work, but all modern browsers and Node.js versions should be able to use it without further polyfills.

The Musical Human: A History of Life on Earth by Michael Spitzer

Ada Lovelace, agricultural Revolution, AlphaGo, An Inconvenient Truth, Asperger Syndrome, Berlin Wall, Boris Johnson, bread and circuses, Brownian motion, cellular automata, Charles Babbage, classic study, coronavirus, COVID-19, creative destruction, crowdsourcing, David Attenborough, Douglas Hofstadter, East Village, Ford Model T, gamification, Gödel, Escher, Bach, hive mind, horn antenna, HyperCard, Internet of things, invention of agriculture, invention of writing, Johannes Kepler, Kickstarter, language acquisition, loose coupling, mandelbrot fractal, means of production, Menlo Park, mirror neurons, music of the spheres, out of africa, planetary scale, power law, randomized controlled trial, Snapchat, social intelligence, Steven Pinker, talking drums, technological singularity, TED Talk, theory of mind, TikTok, trade route, Turing test, Yom Kippur War

Still, nature is full of clocks, from the atoms inside us, which oscillate 1016 times per second, to the American cicada’s seventeen-year breeding cycle. Pushing the evolutionary timeline to the limit, one could even argue that circadian clocks started 3 billion years ago with cyanobacteria,11 and that a definition of any organism is ‘a (loosely coupled) “population of oscillators” ’.12 And it is marvellous to consider this anecdote by the Dutch ethnomusicologist Frank Kouwenhoven about the musicality of midges: One day, I was humming a tune when I noticed that clouds of midges in the air above my head started to ‘dance’ to my music. The insects moved in unison (in up- or downward direction) in response to the rhythmical sound signals they ‘heard’.

Never Let a Serious Crisis Go to Waste: How Neoliberalism Survived the Financial Meltdown by Philip Mirowski

"there is no alternative" (TINA), Adam Curtis, Alan Greenspan, Alvin Roth, An Inconvenient Truth, Andrei Shleifer, asset-backed security, bank run, barriers to entry, Basel III, Bear Stearns, behavioural economics, Berlin Wall, Bernie Madoff, Bernie Sanders, Black Swan, blue-collar work, bond market vigilante , bread and circuses, Bretton Woods, Brownian motion, business cycle, capital controls, carbon credits, Carmen Reinhart, Cass Sunstein, central bank independence, cognitive dissonance, collapse of Lehman Brothers, collateralized debt obligation, complexity theory, constrained optimization, creative destruction, credit crunch, Credit Default Swap, credit default swaps / collateralized debt obligations, crony capitalism, dark matter, David Brooks, David Graeber, debt deflation, deindustrialization, democratizing finance, disinformation, do-ocracy, Edward Glaeser, Eugene Fama: efficient market hypothesis, experimental economics, facts on the ground, Fall of the Berlin Wall, financial deregulation, financial engineering, financial innovation, Flash crash, full employment, George Akerlof, Glass-Steagall Act, Goldman Sachs: Vampire Squid, Greenspan put, Hernando de Soto, housing crisis, Hyman Minsky, illegal immigration, income inequality, incomplete markets, information asymmetry, invisible hand, Jean Tirole, joint-stock company, junk bonds, Kenneth Arrow, Kenneth Rogoff, Kickstarter, knowledge economy, l'esprit de l'escalier, labor-force participation, liberal capitalism, liquidity trap, loose coupling, manufacturing employment, market clearing, market design, market fundamentalism, Martin Wolf, money market fund, Mont Pelerin Society, moral hazard, mortgage debt, Naomi Klein, Nash equilibrium, night-watchman state, Northern Rock, Occupy movement, offshore financial centre, oil shock, Pareto efficiency, Paul Samuelson, payday loans, Philip Mirowski, Phillips curve, Ponzi scheme, Post-Keynesian economics, precariat, prediction markets, price mechanism, profit motive, public intellectual, quantitative easing, race to the bottom, random walk, rent-seeking, Richard Thaler, road to serfdom, Robert Shiller, Robert Solow, Ronald Coase, Ronald Reagan, Savings and loan crisis, savings glut, school choice, sealed-bid auction, search costs, Silicon Valley, South Sea Bubble, Steven Levy, subprime mortgage crisis, tail risk, technoutopianism, The Chicago School, The Great Moderation, the map is not the territory, The Myth of the Rational Market, the scientific method, The Theory of the Leisure Class by Thorstein Veblen, The Wisdom of Crowds, theory of mind, Thomas Kuhn: the structure of scientific revolutions, Thorstein Veblen, Tobin tax, tontine, too big to fail, transaction costs, Tyler Cowen, vertical integration, Vilfredo Pareto, War on Poverty, Washington Consensus, We are the 99%, working poor

Outsiders would rarely perceive the extent to which individual protagonists embedded in a particular shell served multiple roles, or the strength and pervasiveness of network ties, since they could never see beyond the immediate shell of the Russian doll right before their noses. This also tended to foster the impression of those “spontaneous orders” so beloved by the neoliberals, although they were frequently nothing of the sort. Moreover, the loose coupling defeated most attempts to paint the thought collective as a strict conspiracy. It was much beyond that, in the sense it was a thought collective in pursuit of a mass political movement; and in any event, it was built up through trial and error over time. It grew so successful, it soon became too large to qualify

For the Win by Cory Doctorow

anti-globalists, barriers to entry, book value, Burning Man, company town, creative destruction, double helix, Internet Archive, inventory management, lateral thinking, loose coupling, Maui Hawaii, microcredit, New Journalism, off-the-grid, planned obsolescence, Ponzi scheme, post-materialism, printed gun, random walk, reality distortion field, RFID, San Francisco homelessness, Silicon Valley, skunkworks, slashdot, speech recognition, stem cell, Steve Jobs, Steve Wozniak, supply-chain management, technoutopianism, time dilation, union organizing, wage slave, work culture

“When it’s done, it will make toast.” “Make toast?” “Yeah, separate a single slice off a loaf, load it into a top-loading slice-toaster, depress the lever, time the toast-cycle, retrieve the toast and butter it. I got the idea from old-time backup-tape loaders. This plus a toaster will function as a loosely coupled single system.” “OK, that’s really cool, but I have to ask the boring question, Perry. Why? Why build a toast-robot?” Perry stopped working and dusted his hands off. He was really built, and his shaggy hair made him look younger than his crows-feet suggested. He turned a seashell with a half-built motor in it over and spun it like a top on the hand-painted WEATHER IS HERE/WISH YOU WERE BEAUTIFUL legend.

Atomic Accidents: A History of Nuclear Meltdowns and Disasters: From the Ozark Mountains to Fukushima by James Mahaffey

clean water, Dr. Strangelove, Ernest Rutherford, experimental economics, Ford Model T, Google Earth, Henry Ford's grandson gave labor union leader Walter Reuther a tour of the company’s new, automated factory…, it's over 9,000, loose coupling, Menlo Park, military-industrial complex, mutually assured destruction, off-the-grid, Richard Feynman, ROLM, Ronald Reagan, Saturday Night Live, Suez canal 1869, uranium enrichment, wage slave, wikimedia commons

Imagine sitting in the dentist chair and being blown through the wall of the building when the technician pushes the button on his x-ray machine. There are other forces at work in an H-bomb, such as the gamma front, the neutron front, the beta front, the alpha front, and, of course, the shock wave caused by the explosion, but the x-rays are the first out of the box. The x-rays are caused by accelerating electrons originating in the loosely coupled outer orbitals of the atoms. Before the atomic nuclei have time to fully react, the electrons have been bounced and are sending off x-rays at the speed of light in an extremely dense mob. 62 Alvin C. Graves, Ph.D. physics, became head of the Test Division at the Los Alamos National Laboratory.

The Future of Money: How the Digital Revolution Is Transforming Currencies and Finance by Eswar S. Prasad

access to a mobile phone, Adam Neumann (WeWork), Airbnb, algorithmic trading, altcoin, bank run, barriers to entry, Bear Stearns, Ben Bernanke: helicopter money, Bernie Madoff, Big Tech, bitcoin, Bitcoin Ponzi scheme, Bletchley Park, blockchain, Bretton Woods, business intelligence, buy and hold, capital controls, carbon footprint, cashless society, central bank independence, cloud computing, coronavirus, COVID-19, Credit Default Swap, cross-border payments, cryptocurrency, deglobalization, democratizing finance, disintermediation, distributed ledger, diversified portfolio, Dogecoin, Donald Trump, Elon Musk, Ethereum, ethereum blockchain, eurozone crisis, fault tolerance, fiat currency, financial engineering, financial independence, financial innovation, financial intermediation, Flash crash, floating exchange rates, full employment, gamification, gig economy, Glass-Steagall Act, global reserve currency, index fund, inflation targeting, informal economy, information asymmetry, initial coin offering, Internet Archive, Jeff Bezos, Kenneth Rogoff, Kickstarter, light touch regulation, liquidity trap, litecoin, lockdown, loose coupling, low interest rates, Lyft, M-Pesa, machine readable, Mark Zuckerberg, Masayoshi Son, mobile money, Money creation, money market fund, money: store of value / unit of account / medium of exchange, Network effects, new economy, offshore financial centre, open economy, opioid epidemic / opioid crisis, PalmPilot, passive investing, payday loans, peer-to-peer, peer-to-peer lending, Peter Thiel, Ponzi scheme, price anchoring, profit motive, QR code, quantitative easing, quantum cryptography, RAND corporation, random walk, Real Time Gross Settlement, regulatory arbitrage, rent-seeking, reserve currency, ride hailing / ride sharing, risk tolerance, risk/return, Robinhood: mobile stock trading app, robo advisor, Ross Ulbricht, Salesforce, Satoshi Nakamoto, seigniorage, Sheryl Sandberg, Silicon Valley, Silicon Valley startup, smart contracts, SoftBank, special drawing rights, the payments system, too big to fail, transaction costs, uber lyft, unbanked and underbanked, underbanked, Vision Fund, Vitalik Buterin, Wayback Machine, WeWork, wikimedia commons, Y Combinator, zero-sum game

Thus, the e-CNY does not compete with commercial bank deposits, reducing the risk of disintermediation of the banking system. In more technical terms, the e-CNY constitutes “a full reserve system with no derivative deposits or money multiplier effects.” To promote the broad use of the e-CNY and to further allay concerns about privacy, it is based on a “loosely coupled” design that allows fund transfers without the need for a bank account. Low-grade digital wallets, with limits on balances and transaction amounts, can be registered with just phone numbers, compared with higher-grade wallets that must comply with stringent know-your-customer rules that require financial institutions to verify the actual identities of wallet owners.

Structure and Interpretation of Computer Programs, Second Edition by Harold Abelson, Gerald Jay Sussman, Julie Sussman

Andrew Wiles, conceptual framework, Donald Knuth, Douglas Hofstadter, Eratosthenes, functional programming, Gödel, Escher, Bach, higher-order functions, industrial robot, information retrieval, iterative process, Ivan Sutherland, Johannes Kepler, loose coupling, machine translation, Multics, probability theory / Blaise Pascal / Pierre de Fermat, Richard Stallman, Turing machine, wikimedia commons

Each may influence the states of others through interactions, which serve to couple the state variables of one object to those of other objects. Indeed, the view that a system is composed of separate objects is most useful when the state variables of the system can be grouped into closely coupled subsystems that are only loosely coupled to other subsystems. This view of a system can be a powerful framework for organizing computational models of the system. For such a model to be modular, it should be decomposed into computational objects that model the actual objects in the system. Each computational object must have its own local state variables describing the actual object’s state.

Structure and interpretation of computer programs by Harold Abelson, Gerald Jay Sussman, Julie Sussman

Andrew Wiles, conceptual framework, Donald Knuth, Douglas Hofstadter, Eratosthenes, Fermat's Last Theorem, functional programming, Gödel, Escher, Bach, higher-order functions, industrial robot, information retrieval, iterative process, Ivan Sutherland, Johannes Kepler, loose coupling, machine translation, Multics, probability theory / Blaise Pascal / Pierre de Fermat, Richard Stallman, Turing machine

Each may influence the states of others through interactions, which serve to couple the state variables of one object to those of other objects. Indeed, the view that a system is composed of separate objects is most useful when the state variables of the system can be grouped into closely coupled subsystems that are only loosely coupled to other subsystems. This view of a system can be a powerful framework for organizing computational models of the system. For such a model to be modular, it should be decomposed into computational objects that model the actual objects in the system. Each computational object must have its own local state variables describing the actual object's state.

Architecting Modern Data Platforms: A Guide to Enterprise Hadoop at Scale by Jan Kunigk, Ian Buss, Paul Wilkinson, Lars George

Amazon Web Services, barriers to entry, bitcoin, business intelligence, business logic, business process, cloud computing, commoditize, computer vision, continuous integration, create, read, update, delete, data science, database schema, Debian, deep learning, DevOps, domain-specific language, fault tolerance, Firefox, FOSDEM, functional programming, Google Chrome, Induced demand, information security, Infrastructure as a Service, Internet of things, job automation, Kickstarter, Kubernetes, level 1 cache, loose coupling, microservices, natural language processing, Network effects, platform as a service, single source of truth, source of truth, statistical model, vertical integration, web application

This is facilitated by the Kafka consumer architecture, storing independent offsets into the buffered messages. This approach works particularly well for streaming use cases, in which data arrives in small units, usually referred to as messages, events, or records. This can be extended to include other auxiliary systems, such as Flume, to route the events from loosely coupled systems to Kafka for datacenter-local staging (harmonizing). Non-Event-Related Use Cases Other use cases—for example, those including raw HDFS data, such as log files being delivered to an ingest layer—could still use Kafka to queue metadata about the ingested files and to initiate a subsequent asynchronous copy process.

Masterminds of Programming: Conversations With the Creators of Major Programming Languages by Federico Biancuzzi, Shane Warden

Benevolent Dictator For Life (BDFL), business intelligence, business logic, business process, cellular automata, cloud computing, cognitive load, commoditize, complexity theory, conceptual framework, continuous integration, data acquisition, Dennis Ritchie, domain-specific language, Douglas Hofstadter, Fellow of the Royal Society, finite state, Firefox, follow your passion, Frank Gehry, functional programming, general-purpose programming language, Guido van Rossum, higher-order functions, history of Unix, HyperCard, industrial research laboratory, information retrieval, information security, iterative process, Ivan Sutherland, John von Neumann, Ken Thompson, Larry Ellison, Larry Wall, linear programming, loose coupling, machine readable, machine translation, Mars Rover, millennium bug, Multics, NP-complete, Paul Graham, performance metric, Perl 6, QWERTY keyboard, RAND corporation, randomized controlled trial, Renaissance Technologies, Ruby on Rails, Sapir-Whorf hypothesis, seminal paper, Silicon Valley, slashdot, software as a service, software patent, sorting algorithm, SQL injection, Steve Jobs, traveling salesman, Turing complete, type inference, Valgrind, Von Neumann architecture, web application

Grady: It’s been an issue for a long time. Simulated concurrency (multitasking) on single processors is an old concept, and the moment more then one computer existed in the world, people began to think about how to make those things work together. Today we have islands of computing, but more often than not, one has loosely coupled distributed concurrency (e.g., the Web) or intimate concurrency (multicore chips to massively parallel computers). In short, this has always been a “big topic” and, frankly, it’ s a really hard problem. The average developer does not know how to build distributed, concurrent, and secure systems, because these properties require systemic solutions.

Coders at Work by Peter Seibel

Ada Lovelace, Bill Atkinson, bioinformatics, Bletchley Park, Charles Babbage, cloud computing, Compatible Time-Sharing System, Conway's Game of Life, Dennis Ritchie, domain-specific language, don't repeat yourself, Donald Knuth, fallacies of distributed computing, fault tolerance, Fermat's Last Theorem, Firefox, Free Software Foundation, functional programming, George Gilder, glass ceiling, Guido van Rossum, history of Unix, HyperCard, industrial research laboratory, information retrieval, Ken Thompson, L Peter Deutsch, Larry Wall, loose coupling, Marc Andreessen, Menlo Park, Metcalfe's law, Multics, no silver bullet, Perl 6, premature optimization, publish or perish, random walk, revision control, Richard Stallman, rolodex, Ruby on Rails, Saturday Night Live, side project, slashdot, speech recognition, systems thinking, the scientific method, Therac-25, Turing complete, Turing machine, Turing test, type inference, Valgrind, web application

So I claim that it's simply the best way to program, whether you consider yourself an API designer or not. That said, the world of programming is very large. If programming for you is writing HTML, it's probably not the best way to program. But I think that for many kinds of programming, it is. Seibel: So you want a system that's made up of modules that are cohesive and loosely coupled. These days there's at least two views on how you can get to that point. One is to sit down and design these intermodule APIs in advance, the process that you're talking about. And the other is this “simplest thing that could possibly work, refactor mercilessly” approach. Bloch: I don't think the two are mutually exclusive.

Ajax: The Definitive Guide by Anthony T. Holdener

AltaVista, Amazon Web Services, business logic, business process, centre right, Citizen Lab, Colossal Cave Adventure, create, read, update, delete, database schema, David Heinemeier Hansson, en.wikipedia.org, Firefox, full text search, game design, general-purpose programming language, Guido van Rossum, information retrieval, loose coupling, machine readable, MVC pattern, Necker cube, p-value, Ruby on Rails, SimCity, slashdot, social bookmarking, sorting algorithm, SQL injection, Wayback Machine, web application

You can find a lot more on using XML-RPC based web services (and a broader discussion of RPC) in Programming Web Services with XML-RPC by Edd Dumbill et al. (O’Reilly). Service-Oriented Architecture An alternative to RPC is to implement a web service with Service-Oriented Architecture (SOA) concepts, where applications are built with loosely coupled services. These services communicate using a formal definition (typically WSDL, discussed shortly) that is independent of the application’s program language and the operating system in which it resides. The individual services are accessed without any knowledge of their underlying resource dependencies.

Programming Python by Mark Lutz

Benevolent Dictator For Life (BDFL), Build a better mousetrap, business logic, business process, cloud computing, Firefox, general-purpose programming language, Google Chrome, Guido van Rossum, iterative process, linear programming, loose coupling, machine readable, MVC pattern, natural language processing, off grid, slashdot, sorting algorithm, web application

The long-running task threads are also sometimes called workers, because they handle the work of producing results behind the scenes, for the GUI to present to a user. In some sense, the GUI is also a client to worker thread servers, though that terminology is usually reserved for more specific process-based roles; servers provide data sources which are longer-lived and more loosely coupled (though a GUI can also display data from independent servers). Whatever we call it, this model both avoids blocking the GUI while tasks run and avoids potentially parallel updates to the GUI itself. As a more concrete example, suppose your GUI needs to display telemetry data sent in real time from a satellite over sockets (an IPC tool introduced in Chapter 5).

…

For an example, see earlier in this chapter for the way the non-GUI packer and unpacker scripts were run from a GUI so that their results appear in a GUI; technically, these scripts are run in a GUI callback handler so that their output can be routed to a widget. Adding a GUI As a Separate Program: Sockets (A Second Look) As mentioned earlier, it’s also possible to spawn the GUI part of your application as a completely separate program. This is a more advanced technique, but it can make integration simple for some applications because of the loose coupling it implies. It can, for instance, help with the guiStreams issues of the prior section, as long as inputs and outputs are communicated to the GUI over Inter-Process Communication (IPC) mechanisms, and the widget after method (or similar) is used by the GUI program to detect incoming output to be displayed.

Strategy: A History by Lawrence Freedman

Albert Einstein, anti-communist, Anton Chekhov, Ayatollah Khomeini, barriers to entry, battle of ideas, behavioural economics, Black Swan, Blue Ocean Strategy, British Empire, business process, butterfly effect, centre right, Charles Lindbergh, circulation of elites, cognitive dissonance, coherent worldview, collective bargaining, complexity theory, conceptual framework, Cornelius Vanderbilt, corporate raider, correlation does not imply causation, creative destruction, cuban missile crisis, Daniel Kahneman / Amos Tversky, defense in depth, desegregation, disinformation, Dr. Strangelove, Edward Lorenz: Chaos theory, en.wikipedia.org, endogenous growth, endowment effect, escalation ladder, Ford Model T, Ford paid five dollars a day, framing effect, Frederick Winslow Taylor, Gordon Gekko, greed is good, Herbert Marcuse, Herman Kahn, Ida Tarbell, information retrieval, interchangeable parts, invisible hand, John Nash: game theory, John von Neumann, Kenneth Arrow, lateral thinking, linear programming, loose coupling, loss aversion, Mahatma Gandhi, means of production, mental accounting, Murray Gell-Mann, mutually assured destruction, Nash equilibrium, Nelson Mandela, Norbert Wiener, Norman Mailer, oil shock, Pareto efficiency, performance metric, Philip Mirowski, prisoner's dilemma, profit maximization, race to the bottom, Ralph Nader, RAND corporation, Richard Thaler, road to serfdom, Ronald Reagan, Rosa Parks, scientific management, seminal paper, shareholder value, social contagion, social intelligence, Steven Pinker, strikebreaker, The Chicago School, The Myth of the Rational Market, the scientific method, theory of mind, Thomas Davenport, Thomas Kuhn: the structure of scientific revolutions, Torches of Freedom, Toyota Production System, transaction costs, Twitter Arab Spring, ultimatum game, unemployed young men, Upton Sinclair, urban sprawl, Vilfredo Pareto, W. E. B. Du Bois, War on Poverty, women in the workforce, Yogi Berra, zero-sum game

Herbert Simon’s ideas of bounded rationality encouraged a realistic assessment of how managers actually went about their business.4 Another organizational psychologist, Karl Weick, challenged standard models in his book The Social Psychology of Organizing by demonstrating how uncoordinated and apparently chaotic systems could nonetheless prove adaptable when faced with the unexpected—more so than systems geared to assumptions of linearity. Weick drew on a range of disciplines, and introduced into the lexicon concepts such as “loose-coupling” (a distance and lack of responsiveness between individual parts of an organization created a form of adaptability), “enactment” (how structures and events are brought into existence by individual actions), and “sensemaking” (the processes by which people give meaning to experiences). Sensemaking was necessary because individuals must operate in inherently uncertain and unpredictable environments (“equivocality”).