loose coupling

back to index

127 results

Code Complete (Developer Best Practices)

by Steve McConnell  · 8 Jun 2004  · 1,758pp  · 342,766 words

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

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

breaks in subtle ways that seem unrelated to the change made in the used module, which turns debugging into a Sisyphean task. The point of loose coupling is that an effective module provides an additional level of abstraction—once you write it, you can take it for granted. It reduces overall program

conventions for common operations? Does the routine have strong, functional cohesion—doing one and only one thing and doing it well? Do the routines have loose coupling—are the routine's connections to other routines small, intimate, visible, and flexible? Is the length of the routine determined naturally by its function and

the Loop coupling, Desirable Characteristics of a Design, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Coupling Criteria, Coupling Criteria, Coupling Criteria, Kinds of Coupling, Good Encapsulation, Good Encapsulation base classes to derived classes, Good Encapsulation classes, too tightly, Good Encapsulation design

Design iteration practice, Iterate key points, Standards leanness goal, Desirable Characteristics of a Design level of detail needed, Experimental Prototyping levels of, Levels of Design loose coupling goal, Desirable Characteristics of a Design low-to-medium fan-out goal, Desirable Characteristics of a Design maintenance goals, Desirable Characteristics of a Design mental

initializations, General Guidelines for Minimizing Scope variables checklist, Correspondence Between Loops and Arrays verifying termination, Exiting the Loop while loops, Selecting the Kind of Loop loose coupling, Desirable Characteristics of a Design, Keep Coupling Loose design goal, as, Desirable Characteristics of a Design strategies for, Keep Coupling Loose low-to-medium fan

Building Microservices

by Sam Newman  · 25 Dec 2014  · 540pp  · 103,101 words

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

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

a bit about what makes a good service, and how to find seams in our problem space that give us the dual benefits of both loose coupling and high cohesion. Bounded contexts are a vital tool in helping us find these seams, and by aligning our microservices to these boundaries we ensure

implementation detail is hidden from consumers to allow our service a level of autonomy in terms of how it changes its internals over time. Goodbye, loose coupling. Finally, let’s think about behavior for a moment. There is going to be logic associated with how a customer is changed. Where is that

in three different places, and deploy those changes too. Goodbye, cohesion. Remember when we talked about the core principles behind good microservices? Strong cohesion and loose coupling — with database integration, we lose both things. Database integration makes it easy for services to share data, but does nothing about sharing behavior. Our internal

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

Remote Calls logsaggregated, Logs, Logs, and Yet More Logs…(see also monitoring) security issues, Logging standardization of, Standardization logstash, Logs, Logs, and Yet More Logs… loose coupling, Loose Coupling, Orchestration Versus Choreography, Loose and Tightly Coupled Organizations M man-in-the-middle attacks, Allow Everything Inside the Perimeter Marick's quadrant, Types of Tests

Server standardization of, Standardization standards establishment and, Monitoring synthetic, Synthetic Monitoring monolithic systemscodebases in, Small, and Focused on Doing One Thing Well lack of cohesion/loose coupling in, It’s All About Seams reporting databases in, The Reporting Database vs. service-oriented architecture, What About Service-Oriented Architecture? Moore's law, Conway

issues, Integration Spaghetti lack of control over, Lack of Control reporting databases, Data Retrieval via Service Calls Strangler Application Pattern, The Strangler Pattern tight coupling, Loose Coupling, Loose and Tightly Coupled Organizations time to live (TTL), DNS timeouts, Timeouts transaction managers, Distributed Transactions transactional boundaries, Transactional Boundaries-So What to Do? transactionscompensating

Debt Exception Handling Governance and Leading from the Center Building a Team Summary 3. How to Model Services Introducing MusicCorp What Makes a Good Service? Loose Coupling High Cohesion The Bounded Context Shared and Hidden Models Modules and Services Premature Decomposition Business Capabilities Turtles All the Way Down Communication in Terms of

Early Retirement Extreme

by Jacob Lund Fisker  · 30 Sep 2010  · 346pp  · 102,625 words

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. It naturally follows that slack or loose couplings have a cost, in that they're less efficient under normal operations. Conversely, they're less costly under disrupted operations, such as in catastrophes. Changing

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

. Competitively, it's easier (but also riskier) to gain an advantage by leveraging complexity than it is to specialize while keeping the slack of the loose coupling, because the latter requires a lot of effort. Businessmen essentially move the structure from skilled artisans to factories by setting up a structure as described

are the tightly coupled complexities.42 They will gladly borrow those, but they won't own them. To wit, they use a modularity strategy with loose couplings to avoid many problems. Slowness can be achieved through delayed gratification. In a world of scarcity, instant gratification is the optimal strategy. In a world

The Connected Company

by Dave Gray and Thomas Vander Wal  · 2 Dec 2014  · 372pp  · 89,876 words

the overall system, just like species coevolve in a biological community. Three principles at the core of service-oriented design are service contracts, composability, and loose coupling. Service Contracts A service contract is a simple description of the service, including what the service provider needs from customers, what it will do for

can exchange information, but each can also operate independently of the other. 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

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. For example, many mobile phone companies have a

, the more valuable it is. Service contracts make services simple, modular, understandable, and easy to access, like building blocks. Composability makes services combinable and connectable. Loose coupling is the standardized interfaces and connections that make it all work. Organizing for Agility Agile and service-oriented approaches are designed for complex, uncertain, fast

systems and work. And the same approaches that solved complex software problems can also work in business. Taken together, agile teams, service contracts, composability, and loose coupling allow the creation of complex service clusters and networks that operate in a peer-to-peer, city-like way. In fact, these kinds of “service

leaders of each store in a region make up a regional team, and the six regional presidents make up the team that manages the company. Loose coupling: Each Whole Foods team operates as an autonomous unit that has control over its own fate. Performance data is available to all the teams, so

is Connectedness–The Future is Connectedness, The Future is Connectedness, The Complexity Issue, Agile Development, Service Orientation–Netflix, a City of Services, Service Contracts, Composability, Loose Coupling, Organizing for Agility, Netflix, a City of Services, Whole Foods, an Agile Team of Agile Teams, Whole Foods, an Agile Team of Agile Teams, Chains

to a Few Fitness Peaks Red Queen race, The Red Queen Race service orientation and, Service Orientation–Netflix, a City of Services, Service Contracts, Composability, Loose Coupling, Netflix, a City of Services tipping point, We are Reaching a Complexity Tipping Point composability, Service Contracts–Netflix, a City of Services, Netflix, a City

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

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

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

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

Parts–Conflicting Constraints Lead to Rigidity, Conflicting Constraints Lead to Rigidity, Reducing Variety, Reducing Variety, Loose Coupling customers resisting, Reducing Variety interchangeable parts, Interchangeable Parts–Conflicting Constraints Lead to Rigidity, Conflicting Constraints Lead to Rigidity loose coupling and, Loose Coupling reducing variety by, Reducing Variety Starbucks (company), A Wake-up Call at Starbucks, A Wake-up

Iron Sunrise

by Stross, Charles  · 28 Oct 2004  · 462pp  · 142,240 words

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

No Rules Rules: Netflix and the Culture of Reinvention

by Reed Hastings and Erin Meyer  · 7 Sep 2020  · 317pp  · 89,825 words

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

. 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

your own company and your goal is innovation and flexibility, try to keep decision-making decentralized, with few interdependencies between functions, in order to nurture loose coupling from the outset. It will be a whole lot trickier to introduce once your organization has settled into a tightly coupled structure. All this said

CEO wants all departments throughout the company to focus on sustainability and ethical sourcing, then she can control that through her centralized decision-making. With loose coupling, on the other hand, the risk of misalignment is high. Who’s to say one department won’t put low cost ahead of protecting the

departmental vision a reality anytime soon. 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

, 197–203 stepping out of line during, 200–201 tips for, 199–200 written, names used in, 191–97 Thunell, Matt, 75–79 tight versus loose coupling, 215–17 transparency (opening the books), 101–27 decision-making and, 131 difficult decisions in, 115–16 empowerment and, 109 and feeling it’s better

The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2

by Thomas A. Limoncelli, Strata R. Chalup and Christina J. Hogan  · 27 Aug 2014  · 757pp  · 193,541 words

Tree 1.4 Distributed State 1.5 The CAP Principle 1.5.1 Consistency 1.5.2 Availability 1.5.3 Partition Tolerance 1.6 Loosely Coupled Systems 1.7 Speed 1.8 Summary Exercises 2 Designing for Operations 2.1 Operational Requirements 2.1.1 Configuration 2.1.2 Startup and

For the Win

by Cory Doctorow  · 11 May 2010  · 624pp  · 180,416 words

-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

Glasshouse

by Charles Stross  · 14 Jun 2006  · 443pp  · 123,526 words

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

Hands-On RESTful API Design Patterns and Best Practices

by Harihara Subramanian  · 31 Jan 2019  · 422pp  · 86,414 words

added, modified, or replaced. However, the loose coupling approach offers clients better flexibility and reusability of APIs while its elements are added, replaced, or

the meaning of its response, then the client needs to be aware of it and act on those new responses accordingly. Well-designed APIs exhibit loose coupling and well-composed functionalities across service boundaries to maximize scalability factors. Leverage web architecture Since its invention by Sir Tim Berners-Lee in 1989, the

streamline troubleshooting. Further on, these kinds of interactions happen through tight coupling, but tight coupling can lead to dependency issues. This is why lightly- and loosely-coupled services are preferred: so that the development and deployment can be done independently. Also, service interactions don't produce any issues. RESTful APIs are the

authority. By employing such an intermediary among different microservices, the issues that come from tight coupling go off once for all. That is, we get loosely-coupled microservices and they don't need to know each other. They also don't need to know whether other services are running. The communication can

architecture (SOA) and resource-oriented architecture (ROA), that inherently support request/response, and fire and forget. And also, there are ways to achieve light and loose coupling between participating components. But the future undoubtedly belongs to event-driven architecture (EDA), which is the way forward to realize sensitive and responsive (S and

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

by Martin Kleppmann  · 16 Mar 2017  · 1,237pp  · 227,370 words

Saturn's Children

by Charles Stross  · 30 Jun 2008  · 360pp  · 110,929 words

Design Patterns: Elements of Reusable Object-Oriented Software (Joanne Romanovich's Library)

by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides  · 18 Jul 1995

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

by James Mahaffey  · 15 Feb 2015

Howard Rheingold

by The Virtual Community Homesteading on the Electronic Frontier-Perseus Books (1993)  · 26 Apr 2012

Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton and Manuel Pais  · 16 Sep 2019

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

by Richard Bookstaber  · 5 Apr 2007  · 289pp  · 113,211 words

The Architecture of Open Source Applications

by Amy Brown and Greg Wilson  · 24 May 2011  · 834pp  · 180,700 words

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities

by Justin Schuh  · 20 Nov 2006  · 2,054pp  · 359,149 words

Django Book

by Matt Behrens  · 24 Jan 2015

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

by Martin Kleppmann  · 17 Apr 2017

Masterminds of Programming: Conversations With the Creators of Major Programming Languages

by Federico Biancuzzi and Shane Warden  · 21 Mar 2009  · 496pp  · 174,084 words

Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design

by Diomidis Spinellis and Georgios Gousios  · 30 Dec 2008  · 680pp  · 157,865 words

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

by James Higginbotham  · 20 Dec 2021  · 283pp  · 78,705 words

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

by Ron Jeffries  · 14 Aug 2015  · 444pp  · 118,393 words

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

by Sam Newman  · 14 Nov 2019  · 355pp  · 81,788 words

Practical Ext JS Projects With Gears

by Frank Zammetti  · 7 Jul 2009  · 602pp  · 207,965 words

Artificial Intelligence: A Modern Approach

by Stuart Russell and Peter Norvig  · 14 Jul 2019  · 2,466pp  · 668,761 words

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

by Robert Daigneau  · 14 Sep 2011

Strategy: A History

by Lawrence Freedman  · 31 Oct 2013  · 1,073pp  · 314,528 words

Seeking SRE: Conversations About Running Production Systems at Scale

by David N. Blank-Edelman  · 16 Sep 2018

Data and the City

by Rob Kitchin,Tracey P. Lauriault,Gavin McArdle  · 2 Aug 2017

Site Reliability Engineering: How Google Runs Production Systems

by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy  · 15 Apr 2016  · 719pp  · 181,090 words

Sorting Things Out: Classification and Its Consequences

by Geoffrey C. Bowker and Susan Leigh Star  · 25 Aug 2000  · 357pp  · 125,142 words

The Railways: Nation, Network and People

by Simon Bradley  · 23 Sep 2015  · 916pp  · 248,265 words

Army of None: Autonomous Weapons and the Future of War

by Paul Scharre  · 23 Apr 2018  · 590pp  · 152,595 words

The Everything Store: Jeff Bezos and the Age of Amazon

by Brad Stone  · 14 Oct 2013  · 380pp  · 118,675 words

Python Web Development With Django

by Jeff Forcier

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

by Edward Tenner  · 1 Sep 1997

Heat Wave: A Social Autopsy of Disaster in Chicago

by Eric Klinenberg  · 11 Jul 2002  · 440pp  · 128,813 words

The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion

by John Hagel Iii and John Seely Brown  · 12 Apr 2010  · 319pp  · 89,477 words

Erlang Programming

by Francesco Cesarini  · 496pp  · 70,263 words

Sorting Things Out: Classification and Its Consequences (Inside Technology)

by Geoffrey C. Bowker  · 24 Aug 2000

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

by John Kay  · 2 Sep 2015  · 478pp  · 126,416 words

Social Life of Information

by John Seely Brown and Paul Duguid  · 2 Feb 2000  · 791pp  · 85,159 words

The TypeScript Workshop: A Practical Guide to Confident, Effective TypeScript Programming

by Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matthew Thomas Morgan and Wekoslav Stefanovski  · 28 Jul 2021  · 739pp  · 174,990 words

An Elegant Puzzle: Systems of Engineering Management

by Will Larson  · 19 May 2019  · 227pp  · 63,186 words

Ajax: The Definitive Guide

by Anthony T. Holdener  · 25 Jan 2008  · 982pp  · 221,145 words

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

by John Markoff  · 24 Aug 2015  · 413pp  · 119,587 words

Programming Scala

by Unknown  · 2 Jan 2010  · 448pp  · 71,301 words

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

by Josh Kaufman  · 2 Feb 2011  · 624pp  · 127,987 words

Collaborative Futures

by Mike Linksvayer, Michael Mandiberg and Mushon Zer-Aviv  · 24 Aug 2010  · 188pp  · 9,226 words

Deep Survival: Who Lives, Who Dies, and Why

by Laurence Gonzales  · 1 Dec 1998  · 297pp  · 98,506 words

Programming Android

by Zigurd Mednieks, Laird Dornin, G. Blake Meike and Masumi Nakamura  · 15 Jul 2011

API Design Patterns

by Jj Geewax  · 19 Jul 2021  · 725pp  · 168,262 words

Adapt: Why Success Always Starts With Failure

by Tim Harford  · 1 Jun 2011  · 459pp  · 103,153 words

Water: A Biography

by Giulio Boccaletti  · 13 Sep 2021  · 485pp  · 133,655 words

Binge Times: Inside Hollywood's Furious Billion-Dollar Battle to Take Down Netflix

by Dade Hayes and Dawn Chmielewski  · 18 Apr 2022  · 414pp  · 117,581 words

The Future of the Internet: And How to Stop It

by Jonathan Zittrain  · 27 May 2009  · 629pp  · 142,393 words

Kill It With Fire: Manage Aging Computer Systems

by Marianne Bellotti  · 17 Mar 2021  · 232pp  · 71,237 words

Kanban: Successful Evolutionary Change for Your Technology Business

by David J. Anderson  · 6 Apr 2010  · 318pp  · 78,451 words

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

by George Berkowski  · 3 Sep 2014  · 468pp  · 124,573 words

Programming Python

by Mark Lutz  · 5 Jan 2011

Functional Programming in Scala

by Paul Chiusano and Rúnar Bjarnason  · 13 Sep 2014

Chaos Engineering: System Resiliency in Practice

by Casey Rosenthal and Nora Jones  · 27 Apr 2020  · 419pp  · 102,488 words

Coders at Work

by Peter Seibel  · 22 Jun 2009  · 1,201pp  · 233,519 words

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

by Marc Randolph  · 16 Sep 2019  · 334pp  · 102,899 words

The Pragmatic Programmer

by Andrew Hunt and Dave Thomas  · 19 Oct 1999  · 509pp  · 92,141 words

Rapid GUI Programming With Python and Qt

by Mark Summerfield  · 27 Oct 2007  · 643pp  · 53,639 words

The Musical Human: A History of Life on Earth

by Michael Spitzer  · 31 Mar 2021  · 632pp  · 163,143 words

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

by Philip Mirowski  · 24 Jun 2013  · 662pp  · 180,546 words

Beautiful security

by Andy Oram and John Viega  · 15 Dec 2009  · 302pp  · 82,233 words

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

by Nick Chater  · 28 Mar 2018  · 263pp  · 81,527 words

2034: A Novel of the Next World War

by Elliot Ackerman and James Admiral Stavridis  · 15 Mar 2021  · 297pp  · 89,292 words

Test-Driven Development With Python

by Harry J. W. Percival  · 10 Jun 2014  · 779pp  · 116,439 words

Hadoop: The Definitive Guide

by Tom White  · 29 May 2009  · 933pp  · 205,691 words

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

by Bruce Schneier  · 3 Sep 2018  · 448pp  · 117,325 words

Exponential Organizations: Why New Organizations Are Ten Times Better, Faster, and Cheaper Than Yours (And What to Do About It)

by Salim Ismail and Yuri van Geest  · 17 Oct 2014  · 292pp  · 85,151 words

Extreme Teams: Why Pixar, Netflix, AirBnB, and Other Cutting-Edge Companies Succeed Where Most Fail

by Robert Bruce Shaw, James Foster and Brilliance Audio  · 14 Oct 2017  · 280pp  · 82,355 words

Real-World Kanban

by Mattias Skarin  · 23 Jun 2015

Advanced Software Testing—Vol. 3, 2nd Edition

by Jamie L. Mitchell and Rex Black  · 15 Feb 2015

The Future of Money: How the Digital Revolution Is Transforming Currencies and Finance

by Eswar S. Prasad  · 27 Sep 2021  · 661pp  · 185,701 words

Cities Under Siege: The New Military Urbanism

by Stephen Graham  · 30 Oct 2009  · 717pp  · 150,288 words

Think Twice: Harnessing the Power of Counterintuition

by Michael J. Mauboussin  · 6 Nov 2012  · 256pp  · 60,620 words

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

by John Brockman  · 5 Oct 2015  · 481pp  · 125,946 words

Working Backwards: Insights, Stories, and Secrets From Inside Amazon

by Colin Bryar and Bill Carr  · 9 Feb 2021  · 302pp  · 100,493 words

Richard Dawkins: How a Scientist Changed the Way We Think

by Alan Grafen; Mark Ridley  · 1 Jan 2006  · 286pp  · 90,530 words

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

by Aaron Dignan  · 1 Feb 2019  · 309pp  · 81,975 words

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

by Dan Lyons  · 22 Oct 2018  · 252pp  · 78,780 words

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

by Matthew Hindman  · 24 Sep 2018

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

by Jeff Lawson  · 12 Jan 2021  · 282pp  · 85,658 words

On the Slow Train Again

by Michael Williams  · 7 Apr 2011  · 196pp  · 66,253 words

Data Mining: Concepts, Models, Methods, and Algorithms

by Mehmed Kantardzić  · 2 Jan 2003  · 721pp  · 197,134 words

Clean Agile: Back to Basics

by Robert C. Martin  · 13 Oct 2019  · 333pp  · 64,581 words

Agile Project Management With Kanban

by Eric Brechner  · 25 Feb 2015

Learning Android

by Marko Gargenta  · 11 Mar 2011  · 378pp  · 67,804 words

Graph Databases

by Ian Robinson, Jim Webber and Emil Eifrem  · 13 Jun 2013  · 201pp  · 63,192 words

Architecting Modern Data Platforms: A Guide to Enterprise Hadoop at Scale

by Jan Kunigk, Ian Buss, Paul Wilkinson and Lars George  · 8 Jan 2019  · 1,409pp  · 205,237 words

Making Work Visible: Exposing Time Theft to Optimize Workflow

by Dominica Degrandis and Tonianne Demaria  · 14 May 2017  · 153pp  · 45,721 words

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

by Vaughn Vernon  · 16 Aug 2015

Twitter and Tear Gas: The Power and Fragility of Networked Protest

by Zeynep Tufekci  · 14 May 2017  · 444pp  · 130,646 words

The Hacker's Diet

by John Walker

Digital Transformation at Scale: Why the Strategy Is Delivery

by Andrew Greenway,Ben Terrett,Mike Bracken,Tom Loosemore  · 18 Jun 2018

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

by Miran Lipovaca  · 17 Apr 2011  · 559pp  · 130,949 words

Beginning Backbone.js

by James Sugrue  · 15 Dec 2013  · 290pp  · 119,172 words

Does Capitalism Have a Future?

by Immanuel Wallerstein, Randall Collins, Michael Mann, Georgi Derluguian, Craig Calhoun, Stephen Hoye and Audible Studios  · 15 Nov 2013  · 238pp  · 73,121 words

Natural Language Processing with Python and spaCy

by Yuli Vasiliev  · 2 Apr 2020

Vue.js 2 Cookbook

by Andrea Passaglia  · 27 Apr 2017  · 550pp  · 84,515 words

Structure and interpretation of computer programs

by Harold Abelson, Gerald Jay Sussman and Julie Sussman  · 25 Jul 1996  · 893pp  · 199,542 words

Structure and Interpretation of Computer Programs, Second Edition

by Harold Abelson, Gerald Jay Sussman and Julie Sussman  · 1 Jan 1984  · 1,387pp  · 202,295 words

Essential Scrum: A Practical Guide to the Most Popular Agile Process

by Kenneth S. Rubin  · 19 Jul 2012  · 584pp  · 149,387 words

Bad Data Handbook

by Q. Ethan McCallum  · 14 Nov 2012  · 398pp  · 86,855 words

Alternatives to Capitalism

by Robin Hahnel and Erik Olin Wright  · 167pp  · 50,652 words

97 Things Every Programmer Should Know

by Kevlin Henney  · 5 Feb 2010  · 292pp  · 62,575 words

git internal

by Scott Chacon  · 1 Jan 2008  · 120pp  · 19,624 words

Mastering Blockchain, Second Edition

by Imran Bashir  · 28 Mar 2018

Programming Scala: tackle multicore complexity on the JVM

by Venkat Subramaniam  · 1 May 2009  · 226pp  · 17,533 words

Docker: Up & Running: Shipping Reliable Containers in Production

by Sean Kane and Karl Matthias  · 14 May 2023  · 433pp  · 130,334 words

Docker: Up & Running: Shipping Reliable Containers in Production

by Sean P. Kane and Karl Matthias  · 15 Mar 2018  · 350pp  · 114,454 words

The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise

by Nathan L. Ensmenger  · 31 Jul 2010  · 429pp  · 114,726 words

Ansible for DevOps: Server and Configuration Management for Humans

by Jeff Geerling  · 9 Oct 2015  · 313pp  · 75,583 words

Developing Backbone.js Applications

by Addy Osmani  · 21 Jul 2012  · 420pp  · 79,867 words

Software Design for Flexibility

by Chris Hanson and Gerald Sussman  · 17 Feb 2021

Redis Cookbook

by Tiago Macedo and Fred Oliveira  · 26 Jul 2011  · 82pp  · 17,229 words

Industrial Internet

by Jon Bruner  · 27 Mar 2013  · 49pp  · 12,968 words

Principles of Protocol Design

by Robin Sharp  · 13 Feb 2008

The Book of Why: The New Science of Cause and Effect

by Judea Pearl and Dana Mackenzie  · 1 Mar 2018