loose coupling

60 results back to index


pages: 372 words: 89,876

The Connected Company by Dave Gray, Thomas Vander Wal

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

A Pattern Language, Albert Einstein, Amazon Mechanical Turk, Amazon Web Services, Atul Gawande, Berlin Wall, business process, call centre, Clayton Christensen, commoditize, complexity theory, creative destruction, David Heinemeier Hansson, en.wikipedia.org, factory automation, Googley, index card, industrial cluster, interchangeable parts, inventory management, Jeff Bezos, John Markoff, Kevin Kelly, loose coupling, market design, minimum viable product, more computing power than Apollo, profit maximization, Richard Florida, Ruby on Rails, 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, The Wealth of Nations by Adam Smith, Tony Hsieh, Toyota Production System, Vanguard fund, web application, WikiLeaks, Zipcar

At the same time, the bar and kitchen services are separate in the sense that they are not dependent on one other—they 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, 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. For example, many mobile phone companies have a unique interface for attaching the charger to the phone.

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?


pages: 540 words: 103,101

Building Microservices by Sam Newman

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

airport security, Amazon Web Services, anti-pattern, business process, call centre, continuous integration, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, fault tolerance, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, load shedding, loose coupling, platform as a service, premature optimization, pull request, recommendation engine, social graph, software as a service, source of truth, the built environment, web application, WebSocket, x509 certificate

What makes a good service? 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. Windows Vista Microsoft carried out an empirical study where it looked at how its own organizational structure impacted the software quality of a specific product, Windows Vista.

As we discussed earlier, we really want to ensure that 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 logic? If consumers are directly manipulating the DB, then they have to own the associated logic. The logic to perform the same sorts of manipulation to a customer may now be spread among multiple consumers. If the warehouse, registration UI, and call center UI all need to edit customer information, I need to fix a bug or change the behavior 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.


pages: 346 words: 102,625

Early Retirement Extreme by Jacob Lund Fisker

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

8-hour work day, active transport: walking or cycling, barriers to entry, clean water, Community Supported Agriculture, delayed gratification, discounted cash flows, diversification, don't be evil, dumpster diving, financial independence, game design, index fund, invention of the steam engine, inventory management, loose coupling, market bubble, McMansion, passive income, peak oil, place-making, Ponzi scheme, psychological pricing, the scientific method, time value of money, 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. It naturally follows that slack or loose couplings have a cost, in that they're less efficient under normal operations.

However, with sporadic income, credit will be more expensive for the working man compared to the salary man, who earns a steadier income. 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. The salary man has easy access to credit, and if he chooses to accept this burden, he must maintain a job to shoulder it.

Later on I offer a philosophy modeled on the Renaissance ideal of the 17th century and the craftsmen of the 18th century who wrote the Constitution of the United States at the peak of the Age of Enlightenment. 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.


pages: 757 words: 193,541

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, Google Glasses, information asymmetry, Infrastructure as a Service, intermodal, Internet of things, job automation, job satisfaction, load shedding, loose coupling, Malcom McLean invented shipping containers, Marc Andreessen, place-making, platform as a service, premature optimization, recommendation engine, revision control, risk tolerance, side project, Silicon Valley, software as a service, sorting algorithm, statistical model, Steven Levy, supply-chain management, Toyota Production System, 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. As a result a subsystem can be replaced by one that provides the same abstract interface even if its implementation is completely different.

The problem with this technique is that it reduces the potential rate of change. 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. Google’s infrastructure is more like a biological system than a mechanical clock.

The main group simply had to make sure the publisher was working. 4.7 Service-Oriented Architecture Service-oriented architecture (SOA) enables large services to be managed more easily. 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. It accepts requests to perform various actions, schedules them, coordinates them, and reports back progress as it executes.

Django Book by Matt Behrens

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Benevolent Dictator For Life (BDFL), create, read, update, delete, database schema, distributed revision control, don't repeat yourself, en.wikipedia.org, Firefox, full text search, loose coupling, MVC pattern, revision control, Ruby on Rails, school choice, slashdot, web application

If you live elsewhere, you’ll want to change it in settings.py. 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.

Taken together, these pieces loosely follow a pattern called Model-View-Controller (MVC). 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. A database administrator can rename a database table and specify the change in a single place, rather than having to search and replace through a dozen files.

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. For example, an online bookstore might give each book its own URL, like /books/243/ and /books/81196/.


pages: 834 words: 180,700

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

8-hour work day, anti-pattern, bioinformatics, c2.com, cloud computing, collaborative editing, combinatorial explosion, computer vision, continuous integration, create, read, update, delete, David Heinemeier Hansson, Debian, domain-specific language, Donald Knuth, en.wikipedia.org, fault tolerance, finite state, Firefox, friendly fire, Guido van Rossum, linked data, load shedding, locality of reference, loose coupling, Mars Rover, MVC pattern, 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

An alternative solution would be to allow for the use of digitally signed recipes, so that trusted individuals could write and distribute signed recipes, and CI clients could check to see if they should trust the recipes. 6.2.7. Choosing a Model In our experience, a loosely coupled RPC or webhook callback-based model for continuous integration is extremely easy to implement, as long as one ignores any requirements for tight coordination that would involve complex coupling. 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.

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. It is easy to reach the conclusion that the loosely coupled model is "better" all around, but obviously this is only true if build coordination is not needed. This decision should be made based on the needs of projects using the CI system. 6.3. The Future While thinking about Pony-Build, we came up with a few features that we would like to see in future continuous integration systems.

The consumer code was therefore less reusable because people couldn't override which implementation the consumer receives. 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. Contexts are hierarchical. If a context has a request that cannot be satisfied, it will delegate the request to the parent context.


pages: 1,758 words: 342,766

Code Complete (Developer Best Practices) by Steve McConnell

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Ada Lovelace, Albert Einstein, Buckminster Fuller, call centre, choice architecture, continuous integration, data acquisition, database schema, don't repeat yourself, Donald Knuth, fault tolerance, Grace Hopper, haute cuisine, if you see hoof prints, think horses—not zebras, index card, inventory management, iterative process, Larry Wall, late fees, loose coupling, Menlo Park, Perl 6, place-making, premature optimization, revision control, Sapir-Whorf hypothesis, slashdot, sorting algorithm, statistical model, Tacoma Narrows Bridge, the scientific method, Thomas Kuhn: the structure of scientific revolutions, Turing machine, web application

If your design doesn't let you safely ignore most other parts of the program when you're immersed in one specific part, the design isn't doing its job. 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. Extensibility Extensibility means that you can enhance a system without causing violence to the underlying structure.

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. Model railroad cars are coupled by opposing hooks that latch when pushed together.

A routine like sin() is loosely coupled because everything it needs to know is passed in to it with one value representing an angle in degrees. A routine such as InitVars( var 1, var2, var3, …, varN ) is more tightly coupled because, with all the variables it must pass, the calling module practically knows what is happening inside InitVars(). Two classes that depend on each other's use of the same global data are even more tightly coupled. Coupling Criteria Here are several criteria to use in evaluating coupling between modules: Size 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.


Martin Kleppmann-Designing Data-Intensive Applications. The Big Ideas Behind Reliable, Scalable and Maintainable Systems-O’Reilly (2017) by Unknown

active measures, Amazon Web Services, bitcoin, blockchain, business intelligence, business process, c2.com, cloud computing, collaborative editing, commoditize, conceptual framework, cryptocurrency, database schema, DevOps, distributed ledger, Donald Knuth, Edward Snowden, ethereum blockchain, fault tolerance, finite state, Flash crash, full text search, general-purpose programming language, informal economy, information retrieval, Internet of things, iterative process, John von Neumann, loose coupling, Marc Andreessen, natural language processing, Network effects, packet switching, peer-to-peer, performance metric, place-making, premature optimization, recommendation engine, Richard Feynman, 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, statistical model, 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.

If you want the output of one job to become the input to a second job, you need to configure the second job’s input directory to be the same as the first job’s output directory, and an external workflow scheduler must start the second job only once the first job has completed. 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.


pages: 496 words: 70,263

Erlang Programming by Francesco Cesarini

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

cloud computing, fault tolerance, finite state, loose coupling, revision control, RFC: Request For Comment, sorting algorithm, Turing test, type inference, web application

This will from now on allow you to get an Erlang shell in the right directory just by double-clicking any .beam file in the same location where you have placed your source code. 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.

Distributed Systems in Erlang The essence of distributed systems is to provide in a transparent way a service of some kind through a number of computers, processors, or cores linked together by a network. 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. These nodes, residing on the same or separate machines, help each other by sharing the message and event loads.

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. Examples of OTP applications include the Mnesia database, which we cover in Chapter 13; an SNMP agent; or the mobile subscriber database introduced in Chapter 10, which we will convert to an application using behaviors later in this chapter.


pages: 319 words: 89,477

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

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. In our personal lives, many of us have become accustomed to creating our own highly personalized music experiences by leveraging pull platforms such as Apple’s iTunes store.

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.

The team leader expects that a very different approach to product development is essential for success in the future. 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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

create, read, update, delete, database schema, Debian, don't repeat yourself, en.wikipedia.org, Firefox, full text search, Guido van Rossum, loose coupling, MVC pattern, revision control, Ruby on Rails, Silicon Valley, slashdot, 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.

In a system such as Django’s ORM, you can easily honor DRY by creating a Person class with a sum_accounts method defined only once and then used in all the previous locations. 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.


pages: 289 words: 113,211

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

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. Flights can be delayed or canceled; in the worst case, aircraft en route can be rerouted. It may seem preposterous that a system has been developed in which a storm near Chicago can ground a flight going from a cloudless Dallas to a balmy San Diego, but at least it occurs without further incident. These examples hint at how, just as loose coupling can diminish the effects of complexity, the effects of tight coupling can be diminished by simple, linear systems.

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. The by-the-book mode of operation that is required with tightly coupled systems is precisely the way to get into trouble with interactively complex systems.

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. Things go wrong: Class schedules conflict, lectures are canceled, teachers come and go, and students fail to make it to class or attend the exams. 157 ccc_demon_143-164_ch08.qxd 2/13/07 A DEMON 1:46 PM OF Page 158 OUR OWN DESIGN In spite of all this, students regularly make it through; few, if any, find a missed class unleashing a chain of events that derails their college careers.


pages: 478 words: 126,416

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Affordable Care Act / Obamacare, asset-backed security, bank run, banking crisis, Basel III, Bernie Madoff, Big bang: deregulation of the City of London, bitcoin, Black Swan, Bonfire of the Vanities, bonus culture, Bretton Woods, call centre, capital asset pricing model, Capital in the Twenty-First Century by Thomas Piketty, cognitive dissonance, corporate governance, Credit Default Swap, cross-subsidies, dematerialisation, diversification, diversified portfolio, Edward Lloyd's coffeehouse, Elon Musk, Eugene Fama: efficient market hypothesis, eurozone crisis, financial innovation, financial intermediation, financial thriller, fixed income, Flash crash, forward guidance, Fractional reserve banking, full employment, George Akerlof, German hyperinflation, Goldman Sachs: Vampire Squid, Growth in a Time of Debt, 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, John Meriwether, light touch regulation, London Whale, Long Term Capital Management, loose coupling, low cost carrier, M-Pesa, market design, millennium bug, mittelstand, money market fund, moral hazard, mortgage debt, Myron Scholes, new economy, Nick Leeson, Northern Rock, obamacare, Occupy movement, offshore financial centre, oil shock, passive investing, Paul Samuelson, peer-to-peer lending, performance metric, Peter Thiel, Piper Alpha, Ponzi scheme, price mechanism, purchasing power parity, quantitative easing, quantitative trading / quantitative finance, railway mania, Ralph Waldo Emerson, random walk, regulatory arbitrage, Renaissance Technologies, rent control, Richard Feynman, risk tolerance, road to serfdom, Robert Shiller, Robert Shiller, Ronald Reagan, Schrödinger's Cat, 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, 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. It is collected on Tuesday afternoon and shipped across the Channel to Paris during the night.

Its arrival there early on Thursday morning triggers a phone call at around 8 a.m. from a friendly UPS representative who arrives at lunchtime on Thursday. 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. The basic principle should be that intermediaries in capital allocation should normally be familiar with the needs of either borrowers or lenders – or both.


pages: 360 words: 110,929

Saturn's Children by Stross, Charles

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

augmented reality, British Empire, business process, gravity well, indoor plumbing, invisible hand, Isaac Newton, Kuiper Belt, loose coupling, phenotype, Pluto: dwarf planet, Plutocrats, 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.)

“Horrible!” “But you know it’s not me,” I insist angrily. “Why did you do it?” “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. Who knew? It can’t be easy being a ruthless industrialist by day and yearning for the kiss of a Creator’s lash by night.

By the time we’re an hour from Deimos, we’re decelerating hard enough that I have to hang on to Jeeves as I straddle him. 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.


pages: 791 words: 85,159

Social Life of Information by John Seely Brown, Paul Duguid

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

AltaVista, business process, Claude Shannon: information theory, computer age, cross-subsidies, disintermediation, double entry bookkeeping, Frank Gehry, frictionless, frictionless market, future of work, George Gilder, George Santayana, global village, Howard Rheingold, informal economy, information retrieval, invisible hand, Isaac Newton, John Markoff, Just-in-time delivery, Kenneth Arrow, Kevin Kelly, knowledge economy, knowledge worker, loose coupling, Marshall McLuhan, medical malpractice, moral hazard, Network effects, new economy, Productivity paradox, Robert Metcalfe, rolodex, Ronald Coase, shareholder value, Shoshana Zuboff, Silicon Valley, Steve Jobs, Superbowl ad, Ted Nelson, telepresence, the medium is the message, The Nature of the Firm, The Wealth of Nations by Adam Smith, Thomas Malthus, transaction costs, Turing test, Vannevar Bush, Y2K

The process view is important, giving shape and direction to an organization. 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.

Networks of this sort are notable for their reacha reach now extended and fortified by information technology. 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. These subsections stand in contrast to the network as a whole in several ways.

., and Todd Bayma. 1995. "The Virtual College: Computer-Mediated Communication and Scientific Work." 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. New York: Harper and Brothers. . 1986.


pages: 49 words: 12,968

Industrial Internet by Jon Bruner

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

autonomous vehicles, barriers to entry, commoditize, computer vision, data acquisition, demand response, 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, web application

Software operating across several types of machine data can also draw out useful systemic insights. 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. The industrial internet means that machines will no longer be constrained by the quality of their on-board intelligence.


pages: 82 words: 17,229

Redis Cookbook by Tiago Macedo, Fred Oliveira

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

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.


pages: 120 words: 19,624

git internal by Scott Chacon

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

You’ll notice that now it looks like she cloned you and committed and then you changed that code, rather than you both working at the same time and merging. 36 jen/master R1 R2 C2 C0 C3 C1 master At this point, instead of merging two more times like we did originally, we rebase the next two commits she makes. jen/master R1 R2 C0 R1:C2 C1 C2 C3 C2:C3 C4 C5 master 37 jen/master R1 R2 R3 C0 C4:C5 R2:C4 C1 C2 C3 C4 C6 C7 C5 master And finally, we are left with a commit history that looks like Figure 1, rather than Figure 2, which is what we would have if we had merged instead. 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. It’s a common error to think of the master branch as being equivalent to Subversion’s trunk.

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

You can extend individual types of vehicles without affecting any other type. In many circumstances, this is an ideal implementation. 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.

Activities provide the reusable, interchangeable parts of the flow of UI components across Android applications. 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. Let’s take a look at that code again: public class TestActivity extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); } } When the system starts this activity it calls the constructor for TestActivity, a subclass of Activity, and then calls its onCreate method.


pages: 655 words: 141,257

Programming Android: Java Programming for the New Generation of Mobile Devices by Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

You can extend individual types of vehicles without affecting any other type. In many circumstances, this is an ideal implementation. 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.

Activities provide the reusable, interchangeable parts of the flow of UI components across Android applications. 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. At one layer of abstraction, Android applications look a lot like a web applications. Activities are very much analogous to the servlets in web applications. A well designed activity is responsible for a managing a single UI page and each has its own, unique, "name": the URL that invokes it.


pages: 624 words: 127,987

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Albert Einstein, Atul Gawande, Black Swan, 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, 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, Kevin Kelly, Lao Tzu, 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, side project, statistical model, stealth mode startup, Steve Jobs, Steve Wozniak, subscription business, telemarketer, the scientific method, time value of money, Toyota Production System, tulip mania, Upton Sinclair, Vilfredo Pareto, Walter Mischel, Y Combinator, Yogi Berra

If you’ve ever heard the project management term “critical path,” you know the importance of Interdependencies. 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. If the first violin hits the wrong note, the quality of the performance will be affected, but the mistake won’t necessarily cascade to the rest of the orchestra.

According to Pfeffer and Fong’s study, it doesn’t matter if you graduate at the top of your class with a perfect 4.0 or at the bottom with a barely passing grade—getting an MBA has zero correlation with long-term career success. None. 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. It takes decades of work simply to dig yourself out of the debt you took on to get the degree. Christian Schraga, the Wharton MBA, estimated that the ten-year “net present value” (a financial analysis technique used to estimate whether or not an investment is worthwhile) of a top MBA program is approximately negative $53,000 (that’s bad).


pages: 602 words: 207,965

Practical Ext JS Projects With Gears by Frank Zammetti

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

For example: var addMult = add.createInterceptor(function(num1, num2) { alert(num1 * num2); }); addMult(6, 7); Now, when addMult() is called, first the function defined inline in the call to createInterceptor() is executed, multiplying the two arguments and showing the result via alert(), 42 in this case. 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. In this case, if the inline function returns false, then add() will not be called.

However, the meaning of that term has been evolving as well. People now often consider things such as the Yahoo! 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. The ease with which updates can be done, assuming the interface doesn’t change, is another big one (this is the same reason people love web apps in general).

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).


pages: 719 words: 181,090

Site Reliability Engineering by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

Air France Flight 447, anti-pattern, barriers to entry, business intelligence, business process, Checklist Manifesto, cloud computing, combinatorial explosion, continuous integration, correlation does not imply causation, crowdsourcing, database schema, defense in depth, DevOps, en.wikipedia.org, fault tolerance, Flash crash, George Santayana, Google Chrome, Google Earth, job automation, job satisfaction, linear programming, load shedding, loose coupling, meta analysis, meta-analysis, minimum viable product, MVC pattern, performance metric, platform as a service, revision control, risk tolerance, side project, six sigma, the scientific method, Toyota Production System, trickle-down economics, 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. While this monitoring philosophy is a bit aspirational, it’s a good starting point for writing or reviewing a new alert, and it can help your organization ask the right questions, regardless of the size of your organization or the complexity of your service or system.

In software, less is more! A small, simple API is usually also a hallmark of a well-understood problem. 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. While the modularity that APIs offer may seem straightforward, it is not so apparent that the notion of modularity also extends to how changes to APIs are introduced.


pages: 292 words: 85,151

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

23andMe, 3D printing, Airbnb, Amazon Mechanical Turk, Amazon Web Services, augmented reality, autonomous vehicles, Baxter: Rethink Robotics, bioinformatics, bitcoin, Black Swan, blockchain, Burning Man, business intelligence, business process, call centre, chief data officer, Chris Wanstrath, Clayton Christensen, clean water, cloud computing, cognitive bias, collaborative consumption, collaborative economy, commoditize, corporate social responsibility, cross-subsidies, crowdsourcing, cryptocurrency, dark matter, Dean Kamen, dematerialisation, discounted cash flows, distributed ledger, Edward Snowden, Elon Musk, en.wikipedia.org, ethereum blockchain, Galaxy Zoo, game design, Google Glasses, Google Hangouts, Google X / Alphabet X, gravity well, hiring and firing, Hyperloop, industrial robot, Innovator's Dilemma, intangible asset, Internet of things, Iridium satellite, Isaac Newton, Jeff Bezos, Kevin Kelly, Kickstarter, knowledge worker, Kodak vs Instagram, Law of Accelerating Returns, Lean Startup, life extension, lifelogging, loose coupling, loss aversion, Lyft, Marc Andreessen, Mark Zuckerberg, market design, means of production, minimum viable product, natural language processing, Netflix Prize, Network effects, new economy, Oculus Rift, offshore financial centre, p-value, PageRank, pattern recognition, Paul Graham, peer-to-peer, peer-to-peer model, Peter H. Diamandis: Planetary Resources, Peter Thiel, prediction markets, profit motive, publish or perish, Ray Kurzweil, recommendation engine, RFID, ride hailing / ride sharing, risk tolerance, Ronald Coase, Second Machine Age, self-driving car, sharing economy, Silicon Valley, skunkworks, Skype, smart contracts, Snapchat, social software, software is eating the world, speech recognition, stealth mode startup, Stephen Hawking, Steve Jobs, subscription business, supply-chain management, TaskRabbit, telepresence, telepresence robot, Tony Hsieh, transaction costs, Tyler Cowen: Great Stagnation, urban planning, WikiLeaks, winner-take-all economy, X Prize, Y Combinator, zero-sum game

Even actors were contracted to single studios, and distribution was exclusive to the theaters owned by that studio. 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.

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

domain-specific language, iterative process, loose coupling, sorting algorithm, 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. The original list, mylist is still available, unharmed. We say that functional data structures are persistent, meaning that existing references are never changed by operations on the data structure.

A surprising number of programs can be cast in terms of stream processing—once you are aware of the abstraction, you begin seeing it everywhere. 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. Servers, web applications: A web application can be thought of as converting a stream of HTTP requests to a stream HTTP responses.


pages: 559 words: 130,949

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

digital map, fault tolerance, loose coupling, type inference

A module can have many functions and types defined inside it, and it exports some of them. 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. All the functions, types, and type classes that we’ve dealt with so far are part of the Prelude module, which is imported by default.

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?


pages: 443 words: 123,526

Glasshouse by Stross, Charles

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

cognitive dissonance, experimental subject, gravity well, loose coupling, peer-to-peer, phenotype, prisoner's dilemma, sensible shoes, theory of mind, white picket fence

Maybe there'll be some emotional machinery near there that I'll be able to communicate with, something from outside YFH-Polity's frontier that'll be able to put me in touch with reality. 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. I stop and wait for it to arrive. I guess it's some kind of specialized biome construction supervisor, an intelligent gardener.

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. I've got access to enough gray-market military wetware that I can walk the walk as well as slice the floating hair, and my second-level cover is as a demilitarized fugitive from summary justice somewhere that isn't tech-limited—which sets me up for the Odessa Introduction if I see a target of opportunity and need to run a Spanish Prisoner scam on them.


pages: 292 words: 62,575

97 Things Every Programmer Should Know by Kevlin Henney

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

Broadcasting such speculative properties across an application's design is bound to cause pain at some point. Requirements will change. Good design embraces this. 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.


pages: 188 words: 9,226

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

While there are daunting challenges, meeting them means achieving “world domination” for freedom in the most important means of production—computer-mediated collaboration —something the free so ware movement failed to approach in the era of desktop office so ware. 114 31. 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”. Why Science 2.0? Didn't we claim in the chapter 'A Brief History of Collaboration' that “Web 2.0 is bullshit” as the “version number” of the Web as it conveys the incorrect sense that progress is not incremental and a marketing-driven message to “upgrade”?


pages: 201 words: 63,192

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Amazon Web Services, anti-pattern, bioinformatics, 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, web application

The downside is that such queries can be verbose, requiring con‐ siderable developer effort. 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.


pages: 167 words: 50,652

Alternatives to Capitalism by Robin Hahnel, Erik Olin Wright

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

It is on this strong confidence in the conclusions derived from formal models that we disagree. 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.


pages: 226 words: 17,533

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

augmented reality, continuous integration, domain-specific language, don't repeat yourself, loose coupling, semantic web, type inference, web application

Even though your production code is in Java, you can write the test code in Scala. • It is a good way to learn Scala itself. 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. Since Scala compiles to Java bytecode, you can write your tests in Scala, use scalac Download at Boykma.Com Prepared exclusively for sam kaplan U SING JU NIT to compile your code into bytecode, and then run your tests like you normally run JUnit test cases.


pages: 378 words: 67,804

Learning Android by Marko Gargenta

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

create, read, update, delete, database schema, Firefox, loose coupling, slashdot, web application

We also want to stop pulling the data from the cloud when the network is unavailable, and start it again only when we’re back online. 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.


pages: 420 words: 79,867

Developing Backbone.js Applications by Addy Osmani

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

Or am I talking about a technology and consumer products company? 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.


pages: 313 words: 75,583

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Amazon Web Services, Any sufficiently advanced technology is indistinguishable from magic, cloud computing, continuous integration, database schema, Debian, defense in depth, DevOps, fault tolerance, Firefox, full text search, Google Chrome, inventory management, loose coupling, Minecraft, Ruby on Rails, web application

- hosts: all vars_files: - vars/main.yml handlers: - include: handlers/handlers.yml tasks: - include: tasks/init.yml - include: tasks/database.yml - include: tasks/app.yml Using a more hierarchical model like this allows you to see what your playbook is doing at a higher level, and also lets you manage each portion of a configuration or deployment separately. 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.


pages: 933 words: 205,691

Hadoop: The Definitive Guide by Tom White

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Amazon Web Services, bioinformatics, business intelligence, combinatorial explosion, database schema, Debian, domain-specific language, en.wikipedia.org, fault tolerance, full text search, Grace Hopper, information retrieval, Internet Archive, linked data, loose coupling, openstreetmap, recommendation engine, RFID, SETI@home, social graph, web application

Examples include: distributed queues, distributed locks, and leader election among a group of peers. 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. Coordinating parties may not even be contemporaneous, since one process may leave a message in ZooKeeper that is read by another after the first has shut down.

Zab is similar, but it differs in several aspects of its operation, such as relying on TCP for its message ordering guarantees. 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. Leader election is very fast, around 200 ms according to one published result,[134] so performance does not noticeably degrade during an election.


pages: 643 words: 53,639

Rapid GUI Programming With Python and Qt by Mark Summerfield

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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

For this reason, we must always create a new dialog and populate its widgets whenever setPenProperties() is called. 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.

For this reason, many programmers prefer the “middle way” of using standard dialogs—dumb dialogs are too limited and can be inconvenient to use, and smart dialogs can be more work to maintain because of the tight coupling their knowledge of their callers’ data structures implies. 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. The most common choice is between a standard modal dialog and a smart modeless dialog, and in the latter case between the “apply” and “live” styles Summary 163 of updating.


pages: 286 words: 90,530

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Alfred Russel Wallace, Arthur Eddington, bioinformatics, cognitive bias, computer age, conceptual framework, Dava Sobel, double helix, Douglas Hofstadter, 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, 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 ... Nevertheless, Williams’ distaste for group-selection hypotheses wrongly led him to urge the loading of the dice in favor of individual selection.


pages: 509 words: 92,141

The Pragmatic Programmer by Andrew Hunt, Dave Thomas

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

A Pattern Language, Broken windows theory, business process, buy low sell high, c2.com, combinatorial explosion, continuous integration, database schema, domain-specific language, don't repeat yourself, Donald Knuth, general-purpose programming language, George Santayana, Grace Hopper, if you see hoof prints, think horses—not zebras, index card, loose coupling, Menlo Park, MVC pattern, premature optimization, Ralph Waldo Emerson, revision control, Schrödinger's Cat, slashdot, sorting algorithm, speech recognition, traveling salesman, urban decay, Y2K

It is easier to write relatively small, self-contained components than a single large block of code. 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. However, if the two components are not orthogonal, there will be overlap, and the result will do less.


pages: 398 words: 86,855

Bad Data Handbook by Q. Ethan McCallum

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

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, database schema, en.wikipedia.org, Firefox, Flash crash, Gini coefficient, illegal immigration, iterative process, labor-force participation, loose coupling, natural language processing, Netflix Prize, quantitative trading / quantitative finance, recommendation engine, selection bias, sentiment analysis, statistical model, supply-chain management, survivorship bias, text mining, too big to fail, web application

Outlying or mislabeled data can completely change our clusters. 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. We also want to see the most popular story on our own page and trace all the way through our own processing steps, back to the origin site we crawled.


pages: 459 words: 103,153

Adapt: Why Success Always Starts With Failure by Tim Harford

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Andrew Wiles, banking crisis, Basel III, Berlin Wall, Bernie Madoff, Black Swan, car-free, carbon footprint, 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, double entry bookkeeping, Edmond Halley, en.wikipedia.org, Erik Brynjolfsson, experimental subject, Fall of the Berlin Wall, Fermat's Last Theorem, Firefox, food miles, Gerolamo Cardano, global supply chain, 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, special economic zone, spectrum auction, Steve Jobs, supply-chain management, the market place, The Wisdom of Crowds, too big to fail, trade route, Tyler Cowen: Great Stagnation, 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.


pages: 290 words: 119,172

Beginning Backbone.js by James Sugrue

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Airbnb, 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.


pages: 297 words: 98,506

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

business climate, butterfly effect, complexity theory, Edward Lorenz: Chaos theory, impulse control, Lao Tzu, loose coupling, Louis Pasteur, V2 rocket

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. (For that matter, if they had not misperceived which way was down, they might not have positioned themselves over Hillman and Biggs.)


pages: 302 words: 82,233

Beautiful security by Andy Oram, John Viega

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Albert Einstein, Amazon Web Services, business intelligence, business process, call centre, cloud computing, corporate governance, credit crunch, crowdsourcing, defense in depth, Donald Davies, en.wikipedia.org, fault tolerance, Firefox, loose coupling, Marc Andreessen, market design, Monroe Doctrine, new economy, Nicholas Carr, Nick Leeson, Norbert Wiener, 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, statistical model, Steven Levy, The Wisdom of Crowds, Upton Sinclair, web application, web of trust, x509 certificate, zero day, Zimmermann PGP

Many security principles are based on the notion of a physical office or a physical or logical network. 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.


pages: 629 words: 142,393

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

A Declaration of the Independence of Cyberspace, Amazon Mechanical Turk, Andy Kessler, barriers to entry, book scanning, Brewster Kahle, Burning Man, c2.com, call centre, Cass Sunstein, citizen journalism, Clayton Christensen, clean water, commoditize, corporate governance, Daniel Kahneman / Amos Tversky, distributed generation, en.wikipedia.org, Firefox, game design, Hacker Ethic, Howard Rheingold, Hush-A-Phone, illegal immigration, index card, informal economy, Internet Archive, jimmy wales, John Markoff, license plate recognition, loose coupling, mail merge, national security letter, old-boy network, packet switching, peer-to-peer, Post-materialism, post-materialism, pre–internet, price discrimination, profit maximization, 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 Nature of the Firm, The Wisdom of Crowds, web application, wikimedia commons, zero-sum game

A company with such diverse internal voices cannot come right out and give an even temporary blessing to apparent copyright infringement. 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. People might make videos that include copyrighted background music or television show clips and upload them to centralized video sharing services like YouTube.


pages: 429 words: 114,726

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

barriers to entry, business process, Claude Shannon: information theory, computer age, deskilling, Donald Knuth, Firefox, Frederick Winslow Taylor, future of work, Grace Hopper, informal economy, information retrieval, interchangeable parts, Isaac Newton, Jacquard loom, Jacquard loom, job satisfaction, John von Neumann, knowledge worker, loose coupling, new economy, Norbert Wiener, pattern recognition, performance metric, Philip Mirowski, post-industrial society, Productivity paradox, RAND corporation, Robert Gordon, Shoshana Zuboff, sorting algorithm, Steve Jobs, Steven Levy, the market place, Thomas Kuhn: the structure of scientific revolutions, Thorstein Veblen, Turing machine, Von Neumann architecture, 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.


pages: 717 words: 150,288

Cities Under Siege: The New Military Urbanism by Stephen Graham

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

airport security, anti-communist, autonomous vehicles, Berlin Wall, call centre, carbon footprint, clean water, congestion charging, creative destruction, credit crunch, DARPA: Urban Challenge, defense in depth, deindustrialization, digital map, edge city, energy security, European colonialism, failed state, Food sovereignty, Gini coefficient, global supply chain, Google Earth, illegal immigration, income inequality, knowledge economy, late capitalism, loose coupling, market fundamentalism, mass incarceration, McMansion, megacity, moral panic, mutually assured destruction, Naomi Klein, New Urbanism, offshore financial centre, one-state solution, pattern recognition, peak oil, planetary scale, private military company, Project for a New American Century, RAND corporation, RFID, Richard Florida, Scramble for Africa, Silicon Valley, 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.


pages: 448 words: 71,301

Programming Scala by Unknown

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

domain-specific language, en.wikipedia.org, fault tolerance, general-purpose programming language, 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.


pages: 380 words: 118,675

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

3D printing, airport security, AltaVista, Amazon Mechanical Turk, Amazon Web Services, bank run, Bernie Madoff, big-box store, Black Swan, book scanning, Brewster Kahle, call centre, centre right, Chuck Templeton: OpenTable, Clayton Christensen, cloud computing, collapse of Lehman Brothers, crowdsourcing, cuban missile crisis, Danny Hillis, Douglas Hofstadter, Elon Musk, facts on the ground, game design, housing crisis, invention of movable type, inventory management, James Dyson, Jeff Bezos, John Markoff, Kevin Kelly, Kodak vs Instagram, late fees, loose coupling, low skilled workers, Maui Hawaii, Menlo Park, Network effects, new economy, optical character recognition, pets.com, Ponzi scheme, quantitative hedge fund, recommendation engine, Renaissance Technologies, RFID, Rodney Brooks, search inside the book, shareholder value, Silicon Valley, Silicon Valley startup, six sigma, skunkworks, Skype, statistical arbitrage, Steve Ballmer, Steve Jobs, Steven Levy, Stewart Brand, Thomas L Friedman, Tony Hsieh, Whole Earth Catalog, why are manhole covers round?, zero-sum game

Employees would be organized into autonomous groups of fewer than ten people—small enough that, when working late, the team members could be fed with two pizza pies. 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.


pages: 468 words: 124,573

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Airbnb, Amazon Web Services, barriers to entry, Black Swan, business intelligence, call centre, crowdsourcing, en.wikipedia.org, game design, Google Glasses, Google Hangouts, Google X / Alphabet X, iterative process, Jeff Bezos, Jony Ive, Kickstarter, knowledge worker, Lean Startup, loose coupling, Marc Andreessen, Mark Zuckerberg, minimum viable product, move fast and break things, move fast and break things, Network effects, Oculus Rift, Paul Graham, QR code, Ruby on Rails, self-driving car, Silicon Valley, Silicon Valley startup, Skype, Snapchat, social graph, software as a service, software is eating the world, Steve Jobs, Steven Levy, 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. • Blameless postmortems are the key to learning from a tech-ops crisis.


pages: 481 words: 125,946

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

3D printing, agricultural Revolution, AI winter, Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, algorithmic trading, artificial general intelligence, augmented reality, autonomous vehicles, basic income, bitcoin, blockchain, 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, discrete time, Douglas Engelbart, Elon Musk, Emanuel Derman, endowment effect, epigenetics, Ernest Rutherford, experimental economics, Flash crash, friendly AI, functional fixedness, Google Glasses, hive mind, income inequality, information trail, Internet of things, invention of writing, iterative process, Jaron Lanier, job automation, John Markoff, John von Neumann, Kevin Kelly, knowledge worker, loose coupling, microbiome, Moneyball by Michael Lewis explains big data, natural language processing, Network effects, Norbert Wiener, pattern recognition, Peter Singer: altruism, phenotype, planetary scale, Ray Kurzweil, 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, speech recognition, statistical model, stem cell, Stephen Hawking, Steve Jobs, Steven Pinker, Stewart Brand, strong AI, Stuxnet, superintelligent machines, supervolcano, 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!, 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.” Such entities will be so far removed from the realm of human individual thinking and its accompanying qualia that almost all the traditional questions asked about the opportunities and dangers of AI will be transcended.


pages: 413 words: 119,587

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

A Declaration of the Independence of Cyberspace, AI winter, airport security, Apple II, artificial general intelligence, Asilomar, augmented reality, autonomous vehicles, basic income, Baxter: Rethink Robotics, Bill Duvall, bioinformatics, Brewster Kahle, Burning Man, call centre, cellular automata, Chris Urmson, Claude Shannon: information theory, Clayton Christensen, clean water, cloud computing, collective bargaining, computer age, computer vision, crowdsourcing, Danny Hillis, DARPA: Urban Challenge, data acquisition, Dean Kamen, deskilling, don't be evil, Douglas Engelbart, Douglas Engelbart, Douglas Hofstadter, Dynabook, Edward Snowden, Elon Musk, Erik Brynjolfsson, factory automation, From Mathematics to the Technologies of Life and Death, future of work, Galaxy Zoo, Google Glasses, Google X / Alphabet X, Grace Hopper, Gunnar Myrdal, Gödel, Escher, Bach, Hacker Ethic, haute couture, hive mind, hypertext link, indoor plumbing, industrial robot, information retrieval, Internet Archive, Internet of things, invention of the wheel, Jacques de Vaucanson, Jaron Lanier, Jeff Bezos, job automation, John Conway, John Markoff, John Maynard Keynes: Economic Possibilities for our Grandchildren, John Maynard Keynes: technological unemployment, John von Neumann, Kevin Kelly, knowledge worker, Kodak vs Instagram, labor-force participation, loose coupling, Marc Andreessen, Mark Zuckerberg, Marshall McLuhan, medical residency, Menlo Park, Mother of all demos, natural language processing, new economy, Norbert Wiener, PageRank, pattern recognition, pre–internet, RAND corporation, Ray Kurzweil, Richard Stallman, Robert Gordon, Rodney Brooks, Sand Hill Road, Second Machine Age, self-driving car, semantic web, 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, strong AI, superintelligent machines, technological singularity, Ted Nelson, telemarketer, telepresence, telepresence robot, Tenerife airport disaster, The Coming Technological Singularity, the medium is the message, Thorstein Veblen, Turing test, Vannevar Bush, Vernor Vinge, Watson beat the top human players on Jeopardy!, Whole Earth Catalog, William Shockley: the traitorous eight, zero-sum game

Eventually he became so passionate about Engelbart’s ideas that he kept a photo of the legendary computer scientist on his desk to remind him of his principles. 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.


pages: 462 words: 142,240

Iron Sunrise by Stross, Charles

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

blood diamonds, dumpster diving, gravity well, hiring and firing, industrial robot, life extension, loose coupling, mass immigration, mutually assured destruction, phenotype, planetary scale, postindustrial economy, RFID, side project, speech recognition, technological singularity, trade route, uranium enrichment, 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. After about a century of bloodshed and the eventual suppression of the last libertarian fanatics, the Septagon orbitals had gravitated toward the free-est form of civilization that was possible in such a hostile environment: which meant intensive schooling, conscript service in the environmental maintenance crews, and zero tolerance for anyone who thought that hanging separately was better than hanging together.

Principles of Protocol Design by Robin Sharp

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

accounting loophole / creative accounting, business process, discrete time, fault tolerance, finite state, Gödel, Escher, Bach, information retrieval, loose coupling, packet switching, RFC: Request For Comment, stochastic process, x509 certificate

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. An area of particular theoretical and practical interest is networks with an n-dimensional binary hypercube or Boolean cube topology, in which each system is connected to its neighbours in n dimensions.


pages: 624 words: 180,416

For the Win by Cory Doctorow

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

barriers to entry, Burning Man, creative destruction, double helix, Internet Archive, inventory management, loose coupling, Maui Hawaii, microcredit, New Journalism, Ponzi scheme, Post-materialism, post-materialism, random walk, RFID, Silicon Valley, skunkworks, slashdot, speech recognition, stem cell, Steve Jobs, Steve Wozniak, supply-chain management, technoutopianism, union organizing, urban renewal, wage slave

They said GOD BLESS AMERICA and SOUVENIR OF FLORIDA and CONCH REPUBLIC and each had to be fitted out for a motor custom built to conform to its contours. “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.


pages: 496 words: 174,084

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Benevolent Dictator For Life (BDFL), business intelligence, business process, cellular automata, cloud computing, commoditize, complexity theory, conceptual framework, continuous integration, data acquisition, domain-specific language, Douglas Hofstadter, Fellow of the Royal Society, finite state, Firefox, follow your passion, Frank Gehry, general-purpose programming language, Guido van Rossum, HyperCard, information retrieval, iterative process, John von Neumann, Larry Wall, linear programming, loose coupling, Mars Rover, millennium bug, NP-complete, Paul Graham, performance metric, Perl 6, QWERTY keyboard, RAND corporation, randomized controlled trial, Renaissance Technologies, Ruby on Rails, Sapir-Whorf hypothesis, Silicon Valley, slashdot, software as a service, software patent, sorting algorithm, Steve Jobs, traveling salesman, Turing complete, type inference, Valgrind, Von Neumann architecture, web application

Yes, I think so, but I think that’s orthogonal with the means of expression—object-oriented or not—that we use to express such semantics. Concurrency in software is a big topic these days. 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. What about concurrency in development? Will we ever be able to reduce development time by adding more people?


pages: 893 words: 199,542

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Andrew Wiles, conceptual framework, Donald Knuth, Douglas Hofstadter, Eratosthenes, Fermat's Last Theorem, Gödel, Escher, Bach, industrial robot, information retrieval, iterative process, loose coupling, probability theory / Blaise Pascal / Pierre de Fermat, Richard Stallman, Turing machine

In a system composed of many objects, the objects are rarely completely independent. 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. Since the states of objects in the system being modeled change over time, the state variables of the corresponding computational objects must also change.


pages: 1,201 words: 233,519

Coders at Work by Peter Seibel

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Ada Lovelace, bioinformatics, cloud computing, Conway's Game of Life, domain-specific language, don't repeat yourself, Donald Knuth, fault tolerance, Fermat's Last Theorem, Firefox, George Gilder, glass ceiling, Guido van Rossum, HyperCard, information retrieval, Larry Wall, loose coupling, Marc Andreessen, Menlo Park, Metcalfe's law, 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, the scientific method, Therac-25, Turing complete, Turing machine, Turing test, type inference, Valgrind, web application

If you write a monolithic system and, when it gets too big, you tear it into pieces, there will likely be no clear boundaries, and you'll end up with unmaintainable sewage. 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. In a sense, what I'm talking about is test-first programming and refactoring applied to APIs.


pages: 1,387 words: 202,295

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Andrew Wiles, conceptual framework, Donald Knuth, Douglas Hofstadter, Eratosthenes, Gödel, Escher, Bach, industrial robot, information retrieval, iterative process, loose coupling, probability theory / Blaise Pascal / Pierre de Fermat, Richard Stallman, Turing machine, wikimedia commons

In a system composed of many objects, the objects are rarely completely independent. 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. Since the states of objects in the system being modeled change over time, the state variables of the corresponding computational objects must also change.


pages: 662 words: 180,546

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

Amazon: amazon.comamazon.co.ukamazon.deamazon.fr

Alvin Roth, Andrei Shleifer, asset-backed security, bank run, barriers to entry, Basel III, Berlin Wall, Bernie Madoff, Bernie Sanders, Black Swan, blue-collar work, Bretton Woods, Brownian motion, capital controls, 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, Edward Glaeser, Eugene Fama: efficient market hypothesis, experimental economics, facts on the ground, Fall of the Berlin Wall, financial deregulation, financial innovation, Flash crash, full employment, George Akerlof, Goldman Sachs: Vampire Squid, Hernando de Soto, housing crisis, Hyman Minsky, illegal immigration, income inequality, incomplete markets, information asymmetry, invisible hand, Jean Tirole, joint-stock company, Kenneth Arrow, Kenneth Rogoff, 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, Ponzi scheme, precariat, prediction markets, price mechanism, profit motive, quantitative easing, race to the bottom, random walk, rent-seeking, Richard Thaler, road to serfdom, Robert Shiller, Robert Shiller, Ronald Coase, Ronald Reagan, savings glut, school choice, sealed-bid auction, Silicon Valley, South Sea Bubble, Steven Levy, technoutopianism, The Chicago School, The Great Moderation, the map is not the territory, The Myth of the Rational Market, the scientific method, The Wisdom of Crowds, theory of mind, Thomas Kuhn: the structure of scientific revolutions, Thorstein Veblen, Tobin tax, too big to fail, transaction costs, 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. * * * Figure 2.2: MPS Founding Meeting, 1947 * * * * * * The MPS edifice of neoliberalism was anchored by a variety of mainly European and American keystones, progressively encompassed a variety of economic, political, and social schools of thought, and maintained a floating transnational agora for debating solutions to perceived problems, a flexible canopy tailored with an eye to accommodating established relations of power in academia, politics, and society at large.