anti-pattern

33 results back to index

Designing Web Interfaces: Principles and Patterns for Rich Interactions by Bill Scott, Theresa Neil

A Pattern Language, anti-pattern, en.wikipedia.org, Firefox, recommendation engine, Ruby on Rails, Silicon Valley, web application

* * * Symbols 37 Signals' Backpackit, Multi-Field Inline Edit, Considerations, Drag and Drop List, Hover-Reveal Tools, Blank Slate Invitation, Interactive versus static, Perceived affordance, Considerations, Spotlight, Explain What Just Happened Affordance Invitation, Perceived affordance Blank Slate Invitation, Blank Slate Invitation Hover Invitation, Interactive versus static Hover-Reveal Tools, Hover-Reveal Tools multi-field form, Considerations Self-Healing Fade, Considerations Spotlight, Spotlight, Explain What Just Happened 37 Signals' Basecamp, Discoverability versus readability, Considerations, Explain What Just Happened Help system, Explain What Just Happened Toggle-Reveal Tools, Considerations A Accordion, Considerations, Accordion: More than one pane visible at a time, Accordion, Accordion, Accordion more than one pane visible at a time, Accordion: More than one pane visible at a time Nasa.gov, Accordion one-at-a-time expand, Considerations Rico's Accordion widget, Accordion actors (drag and drop), The Actors advertising drag and drop, Advertising drag and drop Affordance Invitation, Considerations, Bridging the new with the familiar, Bridging the new with the familiar, Multiple idioms, Perceived affordance, Perceived affordance, Perceived affordance 37 Signals' Backpackit, Perceived affordance best practices, Perceived affordance bridging new interaction styles with familiar idioms, Bridging the new with the familiar Flickr, Bridging the new with the familiar multiple idioms, Multiple idioms perceived affordance, Perceived affordance Ajax, What Happened alerts, JavaScript, Using JavaScript alerts Alexander, Christopher, What This Book Is About AllTheWeb.com, Live Search, Combining Live Suggest and Live Search Always-Visible Tools, Contextual Tools, Always-Visible Tools, Clear call to action, Discoverability, Discoverability, Discoverability best practices, Discoverability Digg, Always-Visible Tools discoverability, Discoverability Google Reader, Discoverability Netflix, Clear call to action Amazon, The Magic Principle, Responsiveness, Considerations, Carousel Carousel, Carousel Inline Assistant Process, Considerations interface for selecting a shirt, Responsiveness multi-page "Add to Shopping Cart" process, The Magic Principle Amazon's Endless.com, Inline Paging AMCtheatres.com, Animation direction American Express, Input Overlay animation, Animation direction, Considerations direction, Animation direction hinting with, Considerations Animation Gone Wild, Expand/Collapse as Overlay Animation pattern, Animation, Zoom back, Drop animation, Drop animation, Cut it in half rule cut it in half rule, Drop animation dropping modules, Drop animation iGoogle, Cut it in half rule zoom-back, Zoom back anti-patterns, Anti-pattern: Hover and Cover, Anti-pattern: Mystery Meat, Anti-pattern: Tiny Targets, Anti-pattern: Idiot Boxes, Anti-pattern: Mouse Traps, Anti-pattern: Non-Symmetrical Activation/Deactivation, Anti-pattern: Needless Fanfare, Anti-pattern: Hover and Cover, Anti-pattern: Hover and Cover, Expand/Collapse as Overlay Animation Gone Wild, Expand/Collapse as Overlay Hover and Cover, Anti-pattern: Hover and Cover, Anti-pattern: Hover and Cover, Anti-pattern: Hover and Cover Idiot Boxes, Anti-pattern: Idiot Boxes Mouse Traps, Anti-pattern: Mouse Traps Mystery Meat, Anti-pattern: Mystery Meat Needless Fanfare, Anti-pattern: Needless Fanfare Non-Symmetrical Activation/Deactivation, Anti-pattern: Non-Symmetrical Activation/Deactivation Tiny Targets, Anti-pattern: Tiny Targets AOL Finance, Anti-pattern: Hover and Cover Apple Human Interface Guidelines, Drag feedback: Drag start Apple's one-page configurator, Out of view status Artificial Visual Construct, Anti-pattern: Artificial Visual Construct Auto Complete, Lookup Patterns, Auto Complete, Typing, Matching, Selecting, Selecting, Kayak Auto Complete, Kayak Auto Complete best practices, Kayak Auto Complete Kayak, Kayak Auto Complete matching, Matching selecting, Selecting typing, Typing Yahoo!

…

Photos, Collected Selection and actions combining inlays and overlays, Considerations complex editing, Guidelines for Choosing Specific Editing Patterns Concept Share, Drag and Drop Invitations, Invitation to drag Configurator Process, Configurator Process, Immediate feedback, Immediate feedback, Out of view status, Out of view status, Out of view status Apple's one-page configurator, Out of view status immediate feedback, Immediate feedback out of view status, Out of view status Porsche site, Immediate feedback Spotlight technique, Out of view status content tabs, Content tabs contextual toolbar, Contextual toolbar Contextual Tools, Interaction in Context, Discoverability, Contextual Tools in an overlay, Anti-pattern: Mystery Meat, Activation, Soft mode, Anti-pattern: Tiny Targets, Discoverability, Acting on multiple objects best practices, Discoverability, Activation, Soft mode, Anti-pattern: Tiny Targets, Discoverability Always-Visible Tools, Discoverability Hover-Reveal Tools, Activation Multi-Level Tools, Anti-pattern: Tiny Targets Secondary Menus, Discoverability Toggle-Reveal Tools, Soft mode general practices, Acting on multiple objects in overlay, Contextual Tools in an overlay overlays warning, Anti-pattern: Mystery Meat Cooper, Alan, Design Patterns, Theresa's Acknowledgments, The Magic Principle Creating Passionate Users blog, The Advantage of Invitations Csikszentmihalyi, Mihaly, Flow cursor, The Actors cut it in half rule, Drop animation D deferred loading, Showing upload status deJesus, Ericson, Design Patterns design patterns, What This Book Is About desktop-style applications, Considerations desktop-style selection, Considerations Detail Inlay, Detail Inlay, Considerations, Considerations, Combining inlays and overlays best practices, Combining inlays and overlays combining inlays and overlays, Considerations Roost, Considerations Detail Overlay, Detail Overlay, Detail Overlay, Activation, Activation, Activation, Anti-pattern: Non-Symmetrical Activation/Deactivation, Anti-pattern: Needless Fanfare, Anti-pattern: Needless Fanfare, Anti-pattern: Hover and Cover, Anti-pattern: Hover and Cover, Anti-pattern: Hover and Cover activation, Activation anti-pattern: Hover and Cover, Anti-pattern: Needless Fanfare anti-pattern: Mouse Traps, Activation anti-pattern: Needless Fanfare, Anti-pattern: Needless Fanfare anti-pattern: Non-Symmetrical Activation/Deactivation, Anti-pattern: Non-Symmetrical Activation/Deactivation AOL Finance, Anti-pattern: Hover and Cover Barnes & Noble, Anti-pattern: Hover and Cover best practices, Anti-pattern: Hover and Cover Netflix, Detail Overlay Yahoo!

…

Movies, Enhancing Hover Invitation Hover-Reveal Tools, Contextual Tools, Hover-Reveal Tools, Hover-Reveal Tools, Visual noise, Visual noise, Discoverability, Discoverability, Discoverability, Contextual Tools in an overlay, Contextual Tools in an overlay, Anti-pattern: Mystery Meat, Anti-pattern: Mystery Meat, Anti-pattern: Mystery Meat, Activation, Activation 37 Signals' Backpackit, Hover-Reveal Tools anti-pattern: Hover and Cover, Contextual Tools in an overlay anti-pattern: Mystery Meat, Anti-pattern: Mystery Meat best practices, Activation Contextual Tools in overlay, Contextual Tools in an overlay discoverability, Discoverability Flickr, Discoverability overlays warning, Anti-pattern: Mystery Meat tool overlays, immediate activation, Activation visual noise, Visual noise Yahoo!

Designing Social Interfaces by Christian Crumlish, Erin Malone

A Pattern Language, Amazon Mechanical Turk, anti-pattern, barriers to entry, c2.com, carbon footprint, cloud computing, collaborative editing, commons-based peer production, creative destruction, crowdsourcing, en.wikipedia.org, Firefox, folksonomy, Free Software Foundation, game design, ghettoisation, Howard Rheingold, hypertext link, if you build it, they will come, information security, lolcat, Merlin Mann, Nate Silver, Network effects, Potemkin village, power law, recommendation engine, RFC: Request For Comment, semantic web, SETI@home, Skype, slashdot, social bookmarking, social graph, social software, social web, source of truth, stealth mode startup, Stewart Brand, systems thinking, tacit knowledge, telepresence, the long tail, the strength of weak ties, The Wisdom of Crowds, web application, Yochai Benkler

And as social becomes integrated into every facet of interactive experiences, it is important to put a stake in the ground about just what those pieces should be and how they should and shouldn’t behave. The Importance of Anti-Patterns The term anti-patterns was coined in 1995 by Andrew Koenig in the C++ Report, and was inspired by the Gang of Four’s book Design Patterns. Koenig defined the term with two variants: • Those that describe a bad solution to a problem that resulted in a bad situation. • Those that describe how to get out of a bad situation and how to proceed from there to a good solution. Anti-patterns became a popular method for understanding bad design solutions in programming with the publication of the book Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis by William Brown et al.

…

Anti-patterns became a popular method for understanding bad design solutions in programming with the publication of the book Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis by William Brown et al. For our purposes, anti-patterns are common mistakes or a bad solution to a common problem. It is sometimes easier to understand how to design successfully by dissecting what not to do. In the world of social experiences, often the anti-patterns have some sort of jarring or malicious side effects. The anti-patterns we illustrate will point out why the solution seems good and why it turns out to be bad, and then we will discuss refactored alternatives that are more successful or gentler to the user experience. So, That’s All the Little Parts: Now What?

…

Related patterns “Adding Friends” on page 361 As seen on Facebook (http://www.facebook.com) LinkedIn (http://www.linkedin.com) MySpace (http://www.myspace.com) Twitter (http://www.twitter.com) The Ex-Boyfriend Anti-Pattern The boyfriend anti-pattern (also known as the ex-girlfriend bug) exists when the social system makes suggestions for connecting, based on friends-of-friends inference, to people who are not desired, such as an ex-boyfriend or ex-girlfriend. The anti-pattern also presents itself when systems without connections grouping or filtering rely on location awareness and alert a user’s network about where the user is or announces an event to her whole network, regardless of whether the user wanted that to happen (see “Mobile” on page 432; see also Figures 14-35 and 14-36).

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

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

But first, let’s look at a couple of common anti-patterns that result from ad hoc team design. Team Anti-Patterns As we’ve seen so far, the way in which people are organized into teams for building and operating software systems has a strong effect on the nature of the resulting systems, following Conway’s law. When organizations do not explicitly think about team structures and patterns of interaction, they encounter unexpected difficulties building and running software systems. In our work with clients, we’ve seen the occurrence of two particular anti-patterns for team formation across organizations of different sizes.

…

The first anti-pattern is ad hoc team design. This includes teams that have grown too large and been broken up as the communication overhead starts taking a toll, teams created to take care of all COTS software or all middleware, or a DBA team created after a software crash in production due to poor database handling. Of course, all of these situations should trigger some action, but without considering the broader context of the interrelationships between teams, what seems like a natural solution might slow down delivery and eat away at the autonomy of teams. The other common anti-pattern is shuffling team members.

…

This is the book.” —Nick Tune, API Platform Lead, Navico “At Condé Nast International, [the DevOps Topologies] was crucial in understanding our current DevOps state and in defining the vision for our aspirational DevOps operating model. We were able to navigate round the pitfalls and organizational anti-patterns as excellently described in the models. . . . I am extremely pleased that Matthew and Manuel are growing on the success of the DevOps Topologies and turning their further learnings into the far-reaching book Team Topologies for organization design.” —Crystal Hirschorn, VP of Engineering, Global Strategy and Operations at Condé Nast “The high-performing team is the core generator of value in the modern digital economy.

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

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

Figure 2.2 The positive impact of delivering APIs with a design process that optimizes for efficiency and repeatability. The minimum calendar time required is T1 + max(T2 + T3) API Design Process Anti-Patterns Failing to adopt an API design process or adopting a process that is less than effective can lead to the anti-patterns that result in negative impacts for the team and the entire organization. Review the common API design anti-patterns detailed here and see if any of them resonate. The “Code the Design” Anti-Pattern API designers without a formal API design process will start with code and work backwards into an API design. The API design will incorporate internal technology decisions, sometimes to the point of requiring familiarity with a particular database or cloud vendor.

…

Before getting started with the process, it is important to understand how some mistakes in defining API boundaries can lead to a poor developer experience. Avoiding API Boundary Anti-Patterns It is important to clarify the intent and scope of an API. Identifying the scope of an API helps developers find the right one for the job. Without a clear scope and set of associated responsibilities, APIs will suffer from common API boundary anti-patterns. The Mega All-in-One API Anti-Pattern Even the most experienced API designers are faced with challenges when trying to determine how many separate API products they need. Creating a single, large API product makes it difficult for developers to find what they need quickly.

…

An effective API design process supports this iterative learning approach. The “Next Release Design Fix” Anti-Pattern Teams without an API design process may find themselves already planning the next API release, perhaps before the current version has been pushed to production. This is a result of API design decisions that become unchangeable with the current release. Design improvements that would result in breaking changes get moved as technical debt to the backlog. This anti-pattern starts as an innocent design decision due to the complexity of the underlying code change. Perhaps the code change will take too long.

User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton, Peter Economy

anti-pattern, Ben Horowitz, business logic, business process, card file, index card, Kickstarter, Lean Startup, mail merge, minimum viable product, performance metric, software as a service, tacit knowledge

In every conversation, keep what’s valuable, what’s usable, and what’s feasible in the discussion. Include people who can speak to those things. Avoid design by committee by holding a product owner responsible for a successful, cohesive product. The Client-Vendor Anti-Pattern There’s a nasty anti-pattern that gets in the way of using stories well. In fact, it can get in the way of people working together to do anything well. It’s the dreaded client-vendor anti-pattern. In this anti-pattern, one person in a conversation takes the client role, while the other takes the vendor role. It’s the client’s job to know what he wants, and to explain the details to the vendor. That’s what we call “requirements.”

…

And the person who understands the technology is often the most qualified to solve the problem because she knows how the technology she’s working with can help. What’s more, most technologists honestly want to help. They want to know the things they’re building are put to good use. But, in the client-vendor anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins. One of the goals of stories is to break this anti-pattern. One kind of relationship many of us have that does break this anti-pattern when it goes well is the one we have with our doctor. Try showing up at your doctor’s office and giving her your “requirements.” Tell her the prescriptions you’d like written and the operations you’d like scheduled.

…

Now, this should go lots faster than early conversations where you worked together to make tough decisions, since hopefully you won’t need to remake them. Use what’s written to help tell the story. Talk and point to pictures. Let your listener ask questions and make changes to the pictures that help her remember. Help her turn the information associated with the story into her own vacation photos. There’s a nasty anti-pattern I often see here. Some think that since anyone in a team might pick up the story and do work on it, everyone on the team should be involved in every conversation. Perhaps you work at this company. You’ll know it because you’ll hear lots of people complaining that there are way too many meetings.

Hands-On Functional Programming in RUST by Andrew Johnson

anti-pattern, Debian, domain-specific language, don't repeat yourself, Donald Knuth, functional programming, higher-order functions, level 1 cache, premature optimization

To achieve this, you will need to use much of what you have learned so far, along with a gained understanding of the specific behaviors and constraints of ownership in Rust. Learning outcomes: Recognizing anti-patterns of complex ownership Learning specific rules of complex ownership Using immutable data to prevent anti-patterns of ownership Using pure functions to prevent anti-patterns of ownership Technical requirements A recent version of Rust is necessary to run the examples provided: https://www.rust-lang.org/en-US/install.html This chapter's code is also available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file.

…

PacktPub.com Contributors About the author About the reviewer Packt is searching for authors like you Preface Who this book is for What this book covers To get the most out of this book Download the example code files Conventions used Get in touch Reviews Functional Programming – a Comparison Technical requirements Reducing code weight and complexity Making generics more generic Functions as values Iterators Compact legible expressions Strict abstraction means safe abstraction Scoped data binding Algebraic datatypes Mixing object-oriented programming and functional programming Improving project architecture File hierarchy, modules, and namespace design Functional design patterns Metaprogramming Summary Questions Further reading Functional Control Flow Technical requirements Designing the program Gathering project requirements Architecting a code map from requirements Creating a Rust project Writing stubs for each program requirement Implementing program logic Filling in the blanks Parsing input and storing as building description and floor requests Updating location, velocity, and acceleration If the next floor request in the queue is satisfied, then remove it from the queue Adjusting motor control to process the next floor request Printing real-time statistics Printing summary Breaking down long segments into components Searching for abstractions Writing tests Unit testing Integration testing Summary Questions Functional Data Structures Technical requirements Adjusting to changing the scope of the project Gathering new project requirements Architecting a change map from requirements Translating expectations into requirements Translating requirements into a change map Mapping requirements directly to code Writing the physics simulator Writing the motor controller Writing the executable to run a simulation Writing the executable to analyze a simulation Running simulations and analyzing data Summary Questions Generics and Polymorphism Technical requirements Staying productive during downtime Learning about generics Investigating generics Investigating parametric polymorphism Investigating generalized algebraic datatypes Investigating parametric lifetimes Defining lifetimes on ground types Defining lifetimes on generic types Defining lifetimes on traits Defining lifetime subtyping Investigating parametric types Applying parameterization concepts Parameterizing data Parameterizing functions and trait objects Parametric traits and implementations Summary Questions Code Organization and Application Architecture Technical requirements Shipping a product without sacrificing quality Reorganizing the project Planning content of files by type Organizing the motor_controllers.rs module Organizing the buildings.rs module Planning content of files by purpose Organizing the motion_controllers.rs module Organizing the trip_planning.rs module Organizing the elevator_drivers.rs module Planning content of files by layer Organizing the physics.rs module Organizing the data_recorder.rs module Planning the content of files by convenience Organizing the simulate_trip.rs executable Organizing the analyze_trip.rs executable Organizing the operate_elevator.rs executable Mapping code changes and additions Developing code by type Writing the motor_controllers.rs module Writing the buildings.rs module Developing code by purpose Writing the motion_controllers.rs module Writing the trip_planning.rs module Writing the elevator_drivers.rs module Developing code by layer Writing the physics.rs module Writing the data_recorders.rs module Developing code by convenience Writing the simulate_trip.rs executable Writing the analyze_trip.rs executable Writing the operate_elevator.rs executable Reflecting on the project structure Summary Questions Mutability, Ownership, and Pure Functions Technical requirements Recognizing anti-patterns of ownership Inspecting the microcontroller drivers Inspecting the type and trait definitions Defining the OverrideCode enum Defining the ErrorCode enum Defining the AuthorizedSession struct and deconstructor Authorizing sessions Checking errors and resetting state Privileged commands Normal commands Querying library and session state Inspecting the foreign library tests Issuing override codes Accessing status information and sessions Deactivating active sessions Issuing normal commands Issuing privileged commands Denying unauthorized commands Inspecting the Rust tests Rust authorization with sessions Rust sharing session reference Privileged commands Unprivileged commands Denying access to privileged commands Learning the rules of ownership When the owner goes out of scope, the value will be dropped Using immutable data Fixing the hard-to-reproduce bug Preventing hard-to-reproduce bugs Using pure functions Summary Questions Design Patterns Technical requirements Using the functor pattern Using the monad pattern Using the combinator pattern Parser combinators Using the lazy evaluation pattern Summary Questions Implementing Concurrency Technical requirements Using subprocess concurrency Understanding nix fork concurrency Using thread concurrency Understanding Send and Sync traits Using functional design for concurrency Summary Questions Performance, Debugging, and Metaprogramming Technical requirements Writing faster code Compiling with release mode Doing less work Optimizing the code that needs it – profiling For a code rarely executed, performance is not affected Multiples of small numbers are also small numbers Measuring first, to optimize it Putting the fridge next to the computer Capping the Big O Constanting no growth Logarithmic growth Polynomial growth Exponential growth Referencing data is faster Preventing bugs with defensive coding Using Option and Result instead of panic!

…

This is shown in the following code, in intro_patterns.rs: trait Monad<A> { fn return_(t: A) -> Self; //:: A -> Monad<A> fn bind<MB,B>(m: Self, f: Fn(A) -> MB) -> MB where MB: Monad<B>; //:: Monad<A> -> (A -> Monad<B>) -> Monad<B> } If that doesn't help clarify things (and it probably doesn't), a monad has two methods. The first method is the constructor. The second method lets you bind an operation to create another monad. Many common traits have hidden semi-monads but, by making the concept explicit, the concept becomes a strong design pattern instead of a messy anti-pattern. Don't try to reinvent what you don't have to. Function currying: Function currying is a technique that may seem strange for anyone coming from a background in object-oriented or imperative languages. The reason for this confusion is that in many functional languages, functions are curried by default, whereas this is not the case for other languages.

API Design Patterns by Jj Geewax

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

Hopefully at this point you have a good idea of when to rely on references versus hierarchies (as well as when to in-line information rather than use a reference as a pointer). But after exploring these topics there are a couple of knee-jerk reactions we tend to fall into when designing our APIs. Let’s take a moment and look at some resource layout anti-patterns and how to avoid them. 4.3 Anti-patterns As with most topics, there are common blanket behaviors that are easy to follow under all circumstances, but these behaviors tend to lead us awry. After all, it’s much easier to blindly follow a rule than to think deeply about an API design and decide on the best way to arrange resources and how they relate to one another. 4.3.1 Resources for everything It can often be tempting to create resources for even the tiniest concept you might want to model in your API.

…

Expressive Simple Predictable 3.3 Language, grammar, and syntax Language Grammar Syntax 3.4 Context 3.5 Data types and units 3.6 Case study: What happens when you choose bad names? 3.7 Exercises 4 Resource scope and hierarchy 4.1 What is resource layout? Types of relationships Entity relationship diagrams 4.2 Choosing the right relationship Do you need a relationship at all? References or in-line data Hierarchy 4.3 Anti-patterns Resources for everything Deep hierarchies In-line everything 4.4 Exercises 5 Data types and defaults 5.1 Introduction to data types Missing vs. null 5.2 Booleans 5.3 Numbers Bounds Default values Serialization 5.4 Strings Bounds Default values Serialization 5.5 Enumerations 5.6 Lists Atomicity Bounds Default values 5.7 Maps Bounds Default values 5.8 Exercises Part 3 Fundamentals 6 Resource identification 6.1 What is an identifier?

…

Final API definition 16.4 Trade-offs 16.5 Exercises Part 5 Collective operations 17 Copy and move 17.1 Motivation 17.2 Overview 17.3 Implementation Identifiers Child resources Related resources External data Inherited metadata Atomicity Final API definition 17.4 Trade-offs 17.5 Exercises 18 Batch operations 18.1 Motivation 18.2 Overview 18.3 Implementation Atomicity Operation on the collection Ordering of results Common fields Operating across parents Batch Get Batch Delete Batch Create Batch Update Final API definition 18.4 Trade-offs 18.5 Exercises 19 Criteria-based deletion 19.1 Motivation 19.2 Overview 19.3 Implementation Filtering results Validation only by default Result count Result sample set Consistency Final API definition 19.4 Trade-offs 19.5 Exercises 20 Anonymous writes 20.1 Motivation 20.2 Overview 20.3 Implementation Consistency Final API definition 20.4 Trade-offs 20.5 Exercises 21 Pagination 21.1 Motivation 21.2 Overview 21.3 Implementation Page size Page tokens Total count Paging inside resources Final API definition 21.4 Trade-offs Bi-directional paging Arbitrary windows 21.5 Anti-pattern: Offsets and limits 21.6 Exercises 22 Filtering 22.1 Motivation 22.2 Overview 22.3 Implementation Structure Filter syntax and behavior Final API definition 22.4 Trade-offs 22.5 Exercises 23 Importing and exporting 23.1 Motivation 23.2 Overview 23.3 Implementation Import and export methods Interacting with storage systems Converting between resources and bytes Consistency Identifiers and collisions Handling related resources Failures and retries Filtering and field masks Final API definition 23.4 Trade-offs 23.5 Exercises Part 6 Safety and security 24 Versioning and compatibility 24.1 Motivation 24.2 Overview What is compatibility?

The Productive Programmer by Neal Ford

anti-pattern, business process, c2.com, continuous integration, database schema, domain-specific language, don't repeat yourself, Firefox, general-purpose programming language, knowledge worker, Larry Wall, Paradox of Choice, Ruby on Rails, side project, type inference, web application, William of Occam

The idea that you can design the entire software up front, and then just transcribe it seems logical, but it doesn’t work in the real world of constant change. Fortunately, a giant catalog of nonintuitive software lore exists in the Anti Patterns catalog (http://c2.com/cgi/wiki? AntiPatternsCatalog). This is the ancient lore of software. Rather than gnashing your teeth in frustration when your boss is forcing you to use a library of subquality code, point out to him that he’s falling into the “Standing on the Shoulder of Midgets” anti pattern, and he’ll see that you aren’t the only one who thinks it’s a bad idea. Understanding the existing software lore provides great resources when you are being asked to do something that you know in your gut is the wrong thing to do, and yet some managertype is forcing the issue.

…

Why would we give all the accumulated knowledge of what we know about code just for the siren song of some elaborate tool? NOTE Pay attention to the evolution of your tools. Un-Choosing the Wrong Tools As important (or perhaps even more so) than choosing the right tools is rejecting bad tools. In fact, an anti-pattern exists that describes this: boat anchor. A boat anchor is a tool that you are forced to use even though it is ridiculously ill-suited for the job at hand. Frequently, this boat anchor costs a vast amount of money, increasing the political pressure to use it for every situation. For a tortured but depressingly accurate metaphor, imagine that a carpenter was forced to use a sledge hammer (undoubtably powerful) for driving nails.

…

Fight internal feature creep and boat anchors While vendors are the pushers of accidental complexity, it grows within organizations as well. Boat anchors don’t have to be external tools; they are often existing, homegrown headaches. Lots of projects are saddled with inappropriate internal frameworks and tools (victims of the Standing on the Shoulders of Midgets anti-pattern). Business users request “nice to have” functionality without understanding the orders of magnitude of difficulty involved. Developers, architects, and tech leads must make users and management understand the cost of complexity incurred by using inappropriate tools, libraries, and frameworks. Being saddled with an inappropriate tool may seem like a minor thing (especially to nondevelopers), but it can have a huge impact on the overall productivity of developers.

Super Thinking: The Big Book of Mental Models by Gabriel Weinberg, Lauren McCann

Abraham Maslow, Abraham Wald, affirmative action, Affordable Care Act / Obamacare, Airbnb, Albert Einstein, anti-pattern, Anton Chekhov, Apollo 13, Apple Newton, autonomous vehicles, bank run, barriers to entry, Bayesian statistics, Bernie Madoff, Bernie Sanders, Black Swan, Broken windows theory, business process, butterfly effect, Cal Newport, Clayton Christensen, cognitive dissonance, commoditize, correlation does not imply causation, crowdsourcing, Daniel Kahneman / Amos Tversky, dark pattern, David Attenborough, delayed gratification, deliberate practice, discounted cash flows, disruptive innovation, Donald Trump, Douglas Hofstadter, Dunning–Kruger effect, Edward Lorenz: Chaos theory, Edward Snowden, effective altruism, Elon Musk, en.wikipedia.org, experimental subject, fake news, fear of failure, feminist movement, Filter Bubble, framing effect, friendly fire, fundamental attribution error, Goodhart's law, Gödel, Escher, Bach, heat death of the universe, hindsight bias, housing crisis, if you see hoof prints, think horses—not zebras, Ignaz Semmelweis: hand washing, illegal immigration, imposter syndrome, incognito mode, income inequality, information asymmetry, Isaac Newton, Jeff Bezos, John Nash: game theory, karōshi / gwarosa / guolaosi, lateral thinking, loss aversion, Louis Pasteur, LuLaRoe, Lyft, mail merge, Mark Zuckerberg, meta-analysis, Metcalfe’s law, Milgram experiment, minimum viable product, moral hazard, mutually assured destruction, Nash equilibrium, Network effects, nocebo, nuclear winter, offshore financial centre, p-value, Paradox of Choice, Parkinson's law, Paul Graham, peak oil, Peter Thiel, phenotype, Pierre-Simon Laplace, placebo effect, Potemkin village, power law, precautionary principle, prediction markets, premature optimization, price anchoring, principal–agent problem, publication bias, recommendation engine, remote working, replication crisis, Richard Feynman, Richard Feynman: Challenger O-ring, Richard Thaler, ride hailing / ride sharing, Robert Metcalfe, Ronald Coase, Ronald Reagan, Salesforce, school choice, Schrödinger's Cat, selection bias, Shai Danziger, side project, Silicon Valley, Silicon Valley startup, speech recognition, statistical model, Steve Jobs, Steve Wozniak, Steven Pinker, Streisand effect, sunk-cost fallacy, survivorship bias, systems thinking, The future is already here, The last Blockbuster video rental store is in Bend, Oregon, The Present Situation in Quantum Mechanics, the scientific method, The Wisdom of Crowds, Thomas Kuhn: the structure of scientific revolutions, Tragedy of the Commons, transaction costs, uber lyft, ultimatum game, uranium enrichment, urban planning, vertical integration, Vilfredo Pareto, warehouse robotics, WarGames: Global Thermonuclear War, When a measure becomes a target, wikimedia commons

.), and biostatistics (common drug trial designs, statistical methods, etc.). The opposite of the well-tested design pattern is the anti-pattern, a seemingly intuitive but actually ineffective “solution” to a common problem that often already has a known, better solution. Most of the mental models in this book are either design patterns or anti-patterns, and learning them can help you avoid common mistakes. Anti-patterns in this chapter include bike-shedding, present bias, and negative returns. You can avoid anti-patterns by explicitly looking for them and then seeking out established design patterns instead. While some amount of planning is always useful, sometimes the most efficient way to finish a task is to dive in quickly and start, rather than getting bogged down in analysis paralysis (see Chapter 2).

…

The prosecutors have chosen to frame the situation competitively because, for them, the Nash equilibrium with both criminals getting five years is actually the preferred outcome. However, if the criminals can instead frame the situation cooperatively—stick together at all costs—they can vastly improve their outcome. WHERE’S THE LINE? In Chapter 3, we advised seeking out design patterns that help you more quickly address issues, and watching out for anti-patterns, intuitively attractive yet suboptimal solutions. Influence models like those we’ve been discussing in the past two sections can also be dark patterns when they are used to manipulate you for someone else’s benefit (like at the casino). The name comes from websites that organize their sites to keep you in the dark through using disguised ads, burying information on hidden costs, or making it really difficult to cancel a subscription or reach support.

…

A&P, 70 absence of evidence is not the evidence of absence, 167 A/B testing, 136 Accidental Empires (Cringley), 253 accountability, 275 acne, 169–71 activation energy, 112–13 actor-observer bias (self-serving bias), 21, 272 Adams, John, 222 adaptability, 121, 129 ad hominem, 226 adverse selection, 46–47 advertising, 103–4, 120, 262 advisers, 44, 45, 296 Affordable Care Act (ACA), 46, 47 Afghanistan, 54, 243 agent, 44–45 aggregation, 205 aggression, obnoxious, 264 agreeableness, 250 AIDS, 233 Airbnb, 276, 288, 292 air pollution, 41 air travel, 53–54 Aldi, 70 Alexander, Christopher, 92 algorithms, 94, 97 Allen, David, 76 all-nighter, 83 alpha, 161, 182 al-Qaeda, 52, 54 alternative hypothesis, 163, 164, 166, 167 altruism, effective, 80 alumni, 119 Amazon, 61, 70, 95–96, 283, 290, 300 American Revolution, 221–22, 239, 240 American Statistical Association, 168 Amway, 217 analysis paralysis, 60–62, 93 anchoring, 14–15, 30, 199 anecdotal evidence, 133, 139, 146 antibiotics, 37, 47–49 Antifragile (Taleb), 2, 105 antifragility, 2–3, 31–33 anti-patterns, 93 AOL, 106 Apollo 13, 4 appeasement, 237 Apple, 103, 104, 231, 241, 258, 289–91, 305, 309 iPad, 290 iPod, 296–97 Newton, 290 approval ratings, 152–54, 158 arbitrage, 282–83 Archilochus, 254 Archimedes, 78 arguing from first principles, 4–7, 31, 207 Ariely, Dan, 14, 222–23 arithmetic, ix–x, 23–24, 30, 178 arms races, 209–12, 214 Ashley Madison, 229 Associated Press (AP), 306 asymmetric information, 45–47 atomic bomb, see nuclear weapons Atwood, Jeff, 253 authority, 219–20, 226 automation, 95, 310 availability bias, 15–18, 30, 33, 300 average, 146, 187 Avon, 217 Aztecs, 243–44 babies, 198, 279 sleep and, 131–32 babysitters, 222 backfire effect, 26 back-of-the-envelope calculation, 299 bacteria, 47–49, 295 bait and switch, 228, 229 bandwagon effect, 202 barriers to entry and barriers to exit, 305 baseball, 83, 145–46, 289 base rate, 157, 159, 160 base rate fallacy, 157, 158, 170 BATNA (best alternative to a negotiated agreement), 77 Battle of Heraclea, 239 Battle of Tsushima, 241 Bayes’ theorem and Bayesian statistics, 157–60 beachhead, 300–301 Beatles, 105 Beautiful Mind, A, 213 beliefs, 103, 107 bell curve (normal distribution), 150–52, 153, 163–66, 191 Bell Labs, 89 benefit of the doubt, 20 benefits: cost-benefit analysis, 177–86, 189, 194 eliminating, 224 net, 181–82, 184 Berlin, Isaiah, 254 Bernoulli distribution, 152 best practices, 92 beta, 162, 182 Better Angels of Our Nature, The (Pinker), 144 Bezos, Jeff, 61–62, 286–87 bias, 3, 139 availability, 15–18, 30, 33, 300 confirmation, 26–28, 33, 103, 159 disconfirmation, 27 groupthink, 201–3 hidden, 139–43 hindsight, 271–72 nonresponse, 140, 142, 143 observer-expectancy, 136, 139 optimistic probability, 33 present, 85, 87, 93, 113 publication, 170, 173 response, 142, 143 selection, 139–40, 143, 170 self-serving, 21, 272 survivorship, 140–43, 170, 272 Big Short, The (Lewis), 289 bike-shedding, 75, 93 Bird, Larry, 246 birth lottery, 21–22, 69 black-and-white thinking, 126–28, 168, 272 black boxes, 94–95 Black Flags rebellion, 276 blackouts, electric, 120 black swan events, 190–91, 193 Blank, Steve, 294 bleeding them dry, 239 blinded experiments, 136 Blockbuster, 106 blowback, 54 Boaty McBoatface, RSS, 35 body mass index (BMI), 137 body temperature, 146–50 boiling frog, 55, 56, 58, 60 bonds, 180, 184 Bonne, Rose, 58 Boot, Max, 239 boots on the ground, 279 Boston Common, 36–38, 42 Boyd, John, 294 Bradley, Bill, 248 brainstorming, 201–3 Brandeis, Louis, 307 breast cancer, 156–57, 160–61 Breathalyzer tests, 157–58, 160 Brexit, 206, 305 bright spots, 300 bring in reinforcements, 279 British Medical Journal (BMJ), 136–37 broken windows theory, 235–36 Broderick, Matthew, 230 Brody, William, 290–91 Brookings Institution, 306 brute force solution, 93, 97 Bryson, Bill, 50 budget, 38, 74–75, 81, 95, 113 national, 75–76 Buffett, Warren, viii, 69, 286, 302, 317, 318 burning bridges, 243 burnout, 82, 83 Burns, Robert, 49 burn the boats, 244 Bush, George H.

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

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

Companies start experimenting and applying that hot new approach to more and more things until the number of situations where that approach does not work or is not ideal grows into a force that reverses momentum. The industry rediscovers a different way of doing things and swings back. Engineers praised the publish/subscribe model of Kafka as superior to the hub-and-spoke model of Enterprise Service Buses (ESBs). ESBs were a single point of failure and an anti-pattern for service-oriented architecture. Then Kafka added its Connect framework (version 0.9) and its Streams API (0.10), which reintroduced many of the core concepts of ESBs. Google developed Accelerated Mobile Pages to advance asynchronous loading through JavaScript and then added server-side rendering to them—breaking its own spec to move back to a pattern already established by HTML.

…

When the Committee on Data Systems Languages (CODASYL) was developing COBOL, the attitude among those devoted to the study and development of computers was that you should learn the flavor of Assembly relevant for your particular machine. Making programming more accessible and code human-readable was considered an anti-pattern, dumbing down the beauty of programming for an unworthy audience. This audience, however, was made up of people who actually used computers for practical purposes, and many of them were largely unamused by the idea that they should rewrite their programs every single time they upgraded their machines.

…

Some common types of static analysis used for software renovation include the following: Dependency graphs In this style of software renovation, the dependency graph is mapped, and clustering algorithms are used to determine where there is overlap, redundancy, unused libraries, or circular dependencies.4 Grammars These are language-specific tools that produce analysis by parsing the abstract syntax tree. Typically they look for duplicate code or specific practices that are considered anti-patterns (like goto statements). Control flow/data flow graphs These graphs are tools that track how software executes. Control flow graphs map the order in which lines of code are executed, while data flow graphs map the variable assignments and references. You can use such analysis to discover lost business requirements or track down dead code.

Jenkins Continuous Integration Cookbook by Alan Berg

anti-pattern, continuous integration, Debian, don't repeat yourself, en.wikipedia.org, Firefox, information security, job automation, One Laptop per Child (OLPC), performance metric, revision control, web application

Depending on the type of frameworks used in your projects, the range of includes will change. For information on customizing RATs for specific license types, visit: http://incubator.apache.org/rat/apache-rat-plugin/examples/custom-license.html There's more... Here are a few more useful tips to review: Multiple approaches and anti-patterns There were multiple approaches to configuring the Jenkins Job. You could avoid copying the RATs report file by fixing its location in the Maven plugins configuration. This has the advantage of avoiding a copying action. You could also use the Multiple SCM plugin (https://wiki.jenkins-ci.org/display/JENKINS/Multiple+SCMs+Plugin) to first copy the source code into the workspace.

…

In the plugins directory, under the Jenkins workspace, you will find an HTML file for help with the configuration of Google plugins, named /plugins/gcal/help-projectConfig.html. Replace the contents with the following: <div> <p> Add your local comments here: </p> </div> After restarting the Jenkins server, visit the plugin configuration /configure. You will now see the new content. This example is an anti-pattern. If you need to change content for local needs, it is much better to work with the community, adding to the Jenkins SCM, so everyone can see and improve. You will be told immediately that your content is not internationalized. It needs to be translated into the languages that Jenkins supports natively.

…

To include external detectors, you added an extra line to FindBugs' Maven configuration: <pluginList> http://downloads.sourceforge.net/project/fb-contrib/Current/ fb-contrib-4.6.1.jar </pluginList> It is worth visiting SourceForge to check for the most up-to-date version of the detectors. Currently, it is not possible to use Maven's dependency management to pull in the detectors through from a repository, though this might change. In this recipe, you have added a Java class to trigger the new bug detection rules. The anti-pattern is the unnecessary line with the creation of the answer object before the return. It is more succinct to return the object anonymously, for example: Return "This is the answer"; The ant-pattern triggers the USBR_UNNECESSARY_STORE_BEFORE_RETURN pattern, which is described on the home page of the fb-contrib project.

Culture & Empire: Digital Revolution by Pieter Hintjens

4chan, Aaron Swartz, airport security, AltaVista, anti-communist, anti-pattern, barriers to entry, Bill Duvall, bitcoin, blockchain, Boeing 747, bread and circuses, business climate, business intelligence, business process, Chelsea Manning, clean water, commoditize, congestion charging, Corn Laws, correlation does not imply causation, cryptocurrency, Debian, decentralized internet, disinformation, Edward Snowden, failed state, financial independence, Firefox, full text search, gamification, German hyperinflation, global village, GnuPG, Google Chrome, greed is good, Hernando de Soto, hiring and firing, independent contractor, informal economy, intangible asset, invisible hand, it's over 9,000, James Watt: steam engine, Jeff Rulifson, Julian Assange, Kickstarter, Laura Poitras, M-Pesa, mass immigration, mass incarceration, mega-rich, military-industrial complex, MITM: man-in-the-middle, mutually assured destruction, Naomi Klein, national security letter, Nelson Mandela, new economy, New Urbanism, no silver bullet, Occupy movement, off-the-grid, offshore financial centre, packet switching, patent troll, peak oil, power law, pre–internet, private military company, race to the bottom, real-name policy, rent-seeking, reserve currency, RFC: Request For Comment, Richard Feynman, Richard Stallman, Ross Ulbricht, Russell Brand, Satoshi Nakamoto, security theater, selection bias, Skype, slashdot, software patent, spectrum auction, Steve Crocker, Steve Jobs, Steven Pinker, Stuxnet, The Wealth of Nations by Adam Smith, The Wisdom of Crowds, trade route, transaction costs, twin studies, union organizing, wealth creators, web application, WikiLeaks, Y2K, zero day, Zipf's Law

Aggressive groups, like cults, can break down a person's mind by forcing out all independence and replacing it with a synthetic groupthink. People who undergo such treatment become compliant and accept authority without question. There is a whole dark science of turning intelligent individuals into accepting morons, simply through the manipulation of their social context. For more on this, see "Social Anti-Patterns" in “Spheres of Light”. Happily, in my experience, this process also works in reverse. When we can construct our own lives, we generally become happier, more productive, and more discerning. The easy dogmas of the past are broken down and a form of wisdom based on uncovering objective truths takes their place.

…

The best contributors and teams choose their own tasks. A successful community recognizes problems and organizes itself to solve them. Further, it does that faster and more accurately than any top-down management structure. This means the community should accept contributions in any area, without limit. Top-down task assignment is an anti-pattern with many weaknesses. It makes it impossible for individuals to act when they recognize new problems. It creates fiefdoms where work and the necessary resources belong to specific people. It creates long communication chains that can't react rapidly. It requires layers of managers just to connect decision-makers with those doing the work.

…

Tolerance A diverse group has conflicting opinions, and a healthy group has to embrace and digest these conflicts. Critics, iconoclasts, vandals, spies, and trolls keep a group on its toes. They can be a catalyst for others to stay involved. Wikipedia thrives thanks to, not in spite of, those who click Edit to make a mess of articles. It's a classic anti-pattern to suppress minority ideas and views on the basis that they are "dangerous." This inevitably means suppressing new ideas as well. The logic is usually that group coherence is more important than diversity. What then happens is that mistakes aren't challenged, and get solidified into policy. In fact, the group can be more important than the results, if it is diverse and open to arguments.

Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield

air gap, anti-pattern, barriers to entry, bash_history, behavioural economics, business continuity plan, business logic, business process, Cass Sunstein, cloud computing, cognitive load, continuous integration, correlation does not imply causation, create, read, update, delete, cryptocurrency, cyber-physical system, database schema, Debian, defense in depth, DevOps, Edward Snowden, end-to-end encryption, exponential backoff, fault tolerance, fear of failure, general-purpose programming language, Google Chrome, if you see hoof prints, think horses—not zebras, information security, Internet of things, Kubernetes, load shedding, margin call, microservices, MITM: man-in-the-middle, NSO Group, nudge theory, operational security, performance metric, pull request, ransomware, reproducible builds, revision control, Richard Thaler, risk tolerance, self-driving car, single source of truth, Skype, slashdot, software as a service, source of truth, SQL injection, Stuxnet, the long tail, Turing test, undersea cable, uranium enrichment, Valgrind, web application, Y2K, zero day

This pattern arises in the form of multiple types of errors—for example, software errors like Y2K, the Unix epoch rollover, or accidental errors where developers choose certificate expiration times so far in the future that it’s “not their problem anymore.” Clear-text or unauthenticated NTP connections also introduce risk if an attacker is able to control the network. A fixed date or time offset in code exhibits a code smell indicating that you may be creating a time bomb. Note Tying events to wall-clock time is often an anti-pattern. Instead of wall-clock time, we recommend using one of the following: Rates Manually advanced notions of forward progress like epoch numbers or version numbers Validity lists As mentioned in Chapter 8, Google’s ALTS transport security system does not use expiration time in its digital certificates, and instead relies on a revocation system.

…

Business Justifications As mentioned in “Choosing an auditor”, you can enforce authorization by tying access to a structured business justification, such as a bug, incident, ticket, case ID, or assigned account. But building the validation logic may require additional work, and may also require process changes for the people staffing on-call or customer service. As an example, consider a customer service workflow. In an anti-pattern sometimes found in small or immature organizations, a basic and nascent system may give customer service representatives access to all customer records, either for efficiency reasons or because controls don’t exist. A better option would be to block access by default, and to only allow access to specific data when you can verify the business need.

…

However, you can avoid common security vulnerabilities and reliability issues by using hardened frameworks and libraries designed to be resilient against these problem classes. This chapter presents software development patterns that should be applied during the implementation of a project. We start by looking at an RPC backend example and exploring how frameworks help us automatically enforce desired security properties and mitigate typical reliability anti-patterns. We also focus on code simplicity, which is achieved by controlling the accumulation of technical debt and refactoring the codebase when needed. We conclude with tips on how to select the right tools and make the most of your chosen development languages. Security and reliability cannot easily be retrofitted into software, so it’s important to account for them in software design from the earliest phases.

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

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

Data Modeling with Graphs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Models and Goals The Property Graph Model Querying Graphs: An Introduction to Cypher Cypher Philosophy START MATCH RETURN Other Cypher clauses 25 26 27 27 29 29 30 30 iii A Comparison of Relational and Graph Modeling Relational Modeling in a Systems Management Domain Graph Modeling in a Systems Management Domain Testing the Model Cross-Domain Models Creating the Shakespeare Graph Beginning a Query Declaring Information Patterns to Find Constraining Matches Processing Results Query Chaining Common Modeling Pitfalls Email Provenance Problem Domain A Sensible First Iteration? Second Time’s the Charm Evolving the Domain Avoiding Anti-Patterns Summary 30 31 34 36 37 40 42 42 44 45 46 46 47 47 49 51 54 55 4. Building a Graph Database Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Data Modeling Describe the Model in Terms of Your Application’s Needs Nodes for Things, Relationships for Structure Fine-Grained Versus Generic Relationships Model Facts as Nodes Represent Complex Value Types as Nodes Time Iterative and Incremental Development Application Architecture Embedded Versus Server Clustering Load Balancing Testing Test-Driven Data Model Development Performance Testing Capacity Planning Optimization Criteria Performance Redundancy Load 57 57 59 59 60 64 64 67 68 68 73 74 76 76 82 86 87 87 90 90 5.

…

These relationships are bound to an identifier f. To calculate the length of the email chain, we count the number of FORWARD_OF relationships bound to f using Cypher’s count function. In this example, we see the original email has been forwarded twice: +----------+ | count(f) | +----------+ | 2 | +----------+ 1 row Avoiding Anti-Patterns In the general case, don’t encode entities into relationships. Use relationships to convey semantics about how entities are related, and the quality of those relationships. Domain entities aren’t always immediately visible in speech, so think carefully about the nouns you’re actually dealing with.

Exploring ES6 - Upgrade to the next version of JavaScript by Axel Rauschmayer

anti-pattern, domain-specific language, duck typing, en.wikipedia.org, Firefox, functional programming, Google Chrome, MVC pattern, web application, WebSocket

Thus, we can convert a jQuery deferred to an ES6 Promise via Promise.resolve(): Promise.resolve( jQuery.ajax({ url: 'somefile.html', type: 'GET' })) .then(function (data) { console.log(data); }) .catch(function (reason) { console.error(reason); }); ²⁷https://github.com/matthew-andrews/denodeify/ ²⁸http://api.jquery.com/category/deferred-object/ ²⁹https://github.com/kriskowal/q/wiki/Coming-from-jQuery Promises for asynchronous programming 476 25.17 Further reading [1] “Promises/A+³⁰”, edited by Brian Cavalier and Domenic Denicola (the de-facto standard for JavaScript Promises) [2] “JavaScript Promises: There and back again³¹” by Jake Archibald (good general intro to Promises) [3] “Promise Anti-Patterns³²” by Tao of Code (tips and techniques) [4] “Promise Patterns³³” by Forbes Lindesay [5] “The Revealing Constructor Pattern³⁴” by Domenic Denicola (this pattern is used by the Promise constructor) ³⁰http://promisesaplus.com/ ³¹http://www.html5rocks.com/en/tutorials/es6/promises/ ³²http://taoofcode.net/promise-anti-patterns/ ³³https://www.promisejs.org/patterns/ ³⁴http://domenic.me/2014/02/13/the-revealing-constructor-pattern/ VI Miscellaneous 26. Unicode in ES6 This chapter explains the improved support for Unicode that ECMAScript 6 brings.

…

Also similarly to functions, the identifier of a class expression is only visible within the expression: const MyClass = class Me { getClassName() { return Me.name; } }; let inst = new MyClass(); console.log(inst.getClassName()); // Me console.log(Me.name); // ReferenceError: Me is not defined 16.2.2 Inside the body of a class definition A class body can only contain methods, but not data properties. Prototypes having data properties is generally considered an anti-pattern, so this just enforces a best practice. 16.2.2.1 constructor, static methods, prototype methods Let’s examine three kinds of methods that you often find in class definitions. class Foo { constructor(prop) { this.prop = prop; } static staticMethod() { return 'classy'; } prototypeMethod() { return 'prototypical'; Classes 215 } } let foo = new Foo(123); The object diagram for this class declaration looks as follows.

Getting Things Done for Hackers by Lars Wirzenius

anti-pattern, Debian, Firefox, full text search, Inbox Zero, Kickstarter, Merlin Mann, security theater

You might have one inbox for work, and another for personal use. Further, you might have automatic filters that move some incoming e-mail into other folders: software developers are often on many discussion mailing lists, each of which goes into its own folder. Each such folder would be a separate inbox. A common anti-pattern for people is to keep e-mail in their inboxes. They read it, and leave it there. The next time they read e-mail, there might be some new mail, which they read, and leave there. Eventually, the mail piles up a lot, and it gets hard to find a specific mail you may need. Even more importantly, it gets hard to know which mails still require you to do something.

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

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

It failed to identify the management of variability that is inherent to TPS and that was learned and adapted from Deming’s System of Profound Knowledge. Lean also fell victim to misinterpretation and over-simplification. Many Lean consultants jumped on the concept of Waste Reduction (or elimination) and taught Lean as purely a waste-elimination exercise. In this anti-pattern of Lean, all work activities are classified as value-added or non-value-added. The non-value-added, wasteful activities, are further sub-classified into necessary and unnecessary waste. The unnecessary activities are eliminated and the necessary are reduced. Although this is a valid use of Lean tools for improvement, it tends to sub-optimize the outcome for cost reduction and leaves value on the table by not embracing the Lean ideas of Value, Value Stream, and Flow.

…

Lean without Deming’s ideas is Lean without an understanding of variation, and, by implication, is Lean without a focus on maintaining flow. Given that the early Lean literature did not include an understanding of variation nor any references to Deming’s System of Profound Knowledge, it is easy to understand the root cause of the anti-pattern of teaching Lean as a process of waste reduction only. While Deming’s ideas were embedded into TPS in Japan at the shop-floor level, where SPC and the System of Profound Knowledge were employed to identify local improvement opportunities, another body of knowledge developed in the U.S. based around Deming’s ideas.

REST API Design Rulebook by Mark Masse

anti-pattern, business logic, conceptual framework, create, read, update, delete, data acquisition, database schema, hypertext link, information retrieval, off-the-grid, web application

URIs should be used to uniquely identify resources, and they should be named as described in the rules above. As discussed in Request Methods, HTTP request methods should be used to indicate which CRUD function is performed. For example, this API interaction design is preferred: DELETE /users/1234 The following anti-patterns exemplify what not to do: GET /deleteUser?id=1234 GET /deleteUser/1234 DELETE /deleteUser/1234 POST /users/1234/delete * * * [20] Web Resource Modeling Language (WRML) was introduced in WRML [21] http://tools.ietf.org/html/draft-gregorio-uritemplate. [22] CRUD is an acronym that stands for create, read, update, delete—the four standard, storage-oriented functions.

Software Engineering at Google: Lessons Learned From Programming Over Time by Titus Winters, Tom Manshreck, Hyrum Wright

anti-pattern, computer vision, continuous integration, defense in depth, en.wikipedia.org, functional programming, Jevons paradox, job automation, loss aversion, microservices, reproducible builds, supply-chain attack, transaction costs, Turing complete

In many cases, a large-scale change is dictated by your repository topology: if your organization uses a collection of distributed or federated repositories1, making atomic changes across them might not even be technically possible.2 We’ll look at potential barriers to atomic changes in more detail later in this chapter. Large-scale changes at Google are almost always generated using automated tooling. Reasons for making a large-scale change vary, but the changes themselves generally fall into a few basic categories: Cleaning up common anti-patterns using codebase-wide analysis tooling Replacing uses of a deprecated library features Enabling low-level infrastructure improvements, such as compiler upgrades Moving users from an old system to a newer one3 The number of engineers working on these specific tasks in a given organization might be low, it is useful for their customers to have insight in to the LSC tools and process.

Building Microservices by Sam Newman

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

I worked on one monolithic system, for example, where we had 4,000 unit tests, 1,000 service tests, and 60 end-to-end tests. We decided that from a feedback point of view we had way too many service and end-to-end tests (the latter of which were the worst offenders in impacting feedback loops), so we worked hard to replace the test coverage with smaller-scoped tests. A common anti-pattern is what is often referred to as a test snow cone, or inverted pyramid. Here, there are little to no small-scoped tests, with all the coverage in large-scoped tests. These projects often have glacially slow test runs, and very long feedback cycles. If these tests are run as part of continuous integration, you won’t get many builds, and the nature of the build times means that the build can stay broken for a long period when something does break.

…

With the tests that run as part of the pipeline for a specific service, the sensible starting point is that the team that owns that service should write those tests (we’ll talk more about service ownership in Chapter 10). But if we consider that we might have multiple teams involved, and the end-to-end-tests step is now effectively shared between the teams, who writes and looks after these tests? I have seen a number of anti-patterns caused here. These tests become a free-for-all, with all teams granted access to add tests without any understanding of the health of the whole suite. This can often result in an explosion of test cases, sometimes resulting in the test snow cone we talked about earlier. I have seen situations where, because there was no real obvious ownership of these tests, their results get ignored.

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

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

Thus, there is no style of education that works best to train new SREs, and there is certainly no one magic formula that will work for all SRE teams. Table 28-1 lists recommended training practices (and their corresponding anti-patterns) that are well known to SRE at Google. These practices represent a wide range of options available for making your team well educated in SRE concepts, both now and on an ongoing basis. Table 28-1. SRE education practices Recommended patterns Anti-patterns Designing concrete, sequential learning experiences for students to follow Deluging students with menial work (e.g., alert/ticket triage) to train them; “trial by fire” Encouraging reverse engineering, statistical thinking, and working from fundamental principles Training strictly through operator procedures, checklists, and playbooks Celebrating the analysis of failure by suggesting postmortems for students to read Treating outages as secrets to be buried in order to avoid blame Creating contained but realistic breakages for students to fix using real monitoring and tooling Having the first chance to fix something only occur after a student is already on-call Role-playing theoretical disasters as a group, to intermingle a team’s problem-solving approaches Creating experts on the team whose techniques and knowledge are compartmentalized Enabling students to shadow their on-call rotation early, comparing notes with the on-caller Pushing students into being primary on-call before they achieve a holistic understanding of their service Pairing students with expert SREs to revise targeted sections of the on-call training plan Treating on-call training plans as static and untouchable except by subject matter experts Carving out nontrivial project work for students to undertake, allowing them to gain partial ownership in the stack Awarding all new project work to the most senior SREs, leaving junior SREs to pick up the scraps The rest of this chapter presents major themes that we have found to be effective in accelerating SREs to on-call and beyond.

…

To simplify our comparison of best practices in other industries, we distilled these concepts into four key themes: Preparedness and Disaster Testing Postmortem Culture Automation and Reduced Operational Overhead Structured and Rational Decision Making This chapter introduces the industries that we profiled and the industry veterans we interviewed. We define key SRE themes, discuss how these themes are implemented at Google, and give examples of how these principles reveal themselves in other industries for comparative purposes. We conclude with some insights and discussion on the patterns and anti-patterns we discovered. Meet Our Industry Veterans Peter Dahl is a Principal Engineer at Google. Previously, he worked as a defense contractor on several high-reliability systems including many airborne and wheeled vehicle GPS and inertial guidance systems. Consequences of a lapse in reliability in such systems include vehicle malfunction or loss, and the financial consequences associated with that failure.

The Art of Monitoring by James Turnbull

Amazon Web Services, anti-pattern, business logic, cloud computing, continuous integration, correlation does not imply causation, Debian, DevOps, domain-specific language, failed state, functional programming, Kickstarter, Kubernetes, microservices, performance metric, pull request, Ruby on Rails, single source of truth, software as a service, source of truth, web application, WebSocket

Firstly, though, we're going to go through some high-level design patterns and principles you should consider when thinking about application monitoring. An application monitoring primer Let's look at some basic tenets for application monitoring. Firstly, in any good application development methodology, it's a good idea to identify what you want to build before you build it. Monitoring is no different. Sadly there is a common anti-pattern in application development of considering monitoring and other operational functions like security as value-add components of your application rather than core features. Monitoring (and security!) are core functional features of your applications. So, if you're building a specification or user stories for your application, include monitoring for each component of your application.

…

Not building metrics or monitoring is a serious business and operational risk resulting in: An inability to identify or diagnose faults. An inability to measure the operational performance of your application. An inability to measure the business performance and success of an application or a component, like tracking sales figures or the value of transactions. A second common anti-pattern is not instrumenting enough. It's always recommended that you over-instrument your applications. One will often complain about having too little data but rarely worry about having too much. Thirdly, if you use multiple environments—for example development, testing, staging, and production—then ensure your monitoring configuration provides tags or identifiers so you know that the metric, log entry, or event is from a specific environment.

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

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

Of course, this helps only if you know that the thread will be acquiring both locks and you can control the order in which they are acquired. Let’s take an example in Java. This illustration could be from some kind of message-oriented middleware library: stability_anti_patterns/UserCallback.java ​ ​public​ ​interface​ UserCallback { ​ ​public​ ​void​ messageReceived(Message msg); ​ } stability_anti_patterns/Connection.java ​ ​public​ ​interface​ Connection { ​ ​public​ ​void​ registerCallback(UserCallback callback); ​ ​ ​public​ ​void​ send(Message msg); ​ } I’m sure this looks quite familiar. Is it safe? I have no idea. We can’t tell what the execution context will be just by looking at the code.

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

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

It is worth mentioning one particular antipattern in this context, because it is so common. Many developers find anonymous classes to be a verbose and clumsy way of essentially passing a pointer to a function. In order to avoid using them, they skip the messenger object altogether, like this: // !!! Anti-pattern warning public class MyModel implements TextWatcher { public MyModel(TextView textBox) { textBox.addTextChangedListener(this); } public void afterTextChanged(Editable s) { handleTextChange(s); } public void beforeTextChanged( CharSequence s, int start, int count, int after) { } public void onTextChanged( CharSequence s, int start, int count, int after) { } void handleTextChange(Editable s) { // do something with s, the changed text. } } Sometimes this approach makes sense.

…

On the other hand, if (as the name MyModel suggests) the class will be used broadly and in a wide variety of circumstances, eliminating the messenger classes breaks encapsulation and limits extension. Obviously, it’s going to be messy to extend this implementation to handle input from a second TextBox that requires different behavior. Nearly as bad, though, is something called interface pollution, which happens when this idea is taken to an extreme. It looks like this: // !!! Anti-pattern ALERT! public class MyModel implements TextWatcher, OnKeyListener, View.OnTouchListener, OnFocusChangeListener, Button.OnClickListener { // .... } Code like this is seductively elegant, in a certain way, and fairly common. Unfortunately, though, MyModel is now very tightly coupled to every one of the events it handles.

Learning Ansible 2 - Second Edition by Fabio Alessandro Locati

Amazon Web Services, anti-pattern, business logic, cloud computing, continuous integration, Debian, DevOps, don't repeat yourself, Infrastructure as a Service, inventory management, Kickstarter, revision control, source of truth, web application

I think the best quality of the ICT industry is not related to its ability to grow at a super high speed, but to its ability to revolutionize itself and the rest of the world at an astonishing speed. Every 10 to 15 years there are major shifts in how this industry works and every shift solves problems that were very hard to manage up to that point, creating new challenges. Also, at every major shift, many best practices of the previous iteration are classified as anti-patterns and new best practices are created. Although it might appear that those changes are impossible to predict, this is not always true. Obviously, it is not possible to know exactly what changes will occur and when they will take place, but looking at companies with a large number of servers and many lines of code usually reveals what the next steps will be.

Team Geek by Brian W. Fitzpatrick, Ben Collins-Sussman

anti-pattern, barriers to entry, cognitive dissonance, Dean Kamen, do what you love, en.wikipedia.org, fail fast, fear of failure, Free Software Foundation, Guido van Rossum, Ken Thompson, Paradox of Choice, Paul Graham, publish or perish, Richard Stallman, Silicon Valley, Steve Jobs, TED Talk, value engineering, web application

” — Vint Cerf “I’ve been working with engineers for over 30 years, and in that time I’ve learned that engineering is as much about people as it is science and technology, but most engineers put little or no effort into understanding how to work with others. If you want to be more effective and efficient at creating and innovating, then this book is for you.” — Dean Kamen “Ben and Fitz have assembled an amazing collection of patterns and anti-patterns for software development teams to consider. This book is for anyone struggling with understanding how to make such a team more productive—for the code wranglers themselves, for their managers, and for everyone in orbit around them. It puts down on paper many of the things innate to great open source developers.

Python Tricks: The Book by Dan Bader

anti-pattern, business logic, data science, domain-specific language, don't repeat yourself, functional programming, Hacker News, higher-order functions, linked data, off-by-one error, pattern recognition, performance metric

This gives a nice and clean exception hierarchy with little extra effort: class NameTooShortError(BaseValidationError): pass class NameTooLongError(BaseValidationError): pass class NameTooCuteError(BaseValidationError): pass For example, this allows users of your package to write try…except statements that can handle all of the errors from this package without having to catch them manually: try: validate(name) except BaseValidationError as err: handle_validation_error(err) People can still catch more specific exceptions that way, but if they don’t want to, at least they won’t have to resort to snapping up all exceptions with a catchall except statement. This is generally considered an anti-pattern—it can silently swallow and hide unrelated errors and make your programs much harder to debug. Of course you can take this idea further and logically group your exceptions into fine grained sub-hierarchies. But be careful—it’s easy to introduce unnecessary complexity by going overboard with this.

Sass and Compass for Designers by Ben Frain

anti-pattern, don't repeat yourself, Firefox, Steve Jobs

If your humble author has done even a half decent job, you should have gained an understanding of most of the major functionality and techniques available when using Sass and Compass to author style sheets. Just be mindful that although we have these skills and techniques at our disposal, this doesn't necessarily mean they are right to use all the time. Practically, we have already considered that things such as over-nesting rules can produce anti-patterns in our generated code. In the same vein, consider whether other practices that are now more easily achievable with Sass and Compass are actually the right choice. In-lining a 1 MB image as a data URI in your CSS wouldn't be a smart move, for example. I know you'll make the right choices. With that fatherly advice squared away, my primary wish is that you now feel empowered and not intimidated by all that Sass and Compass has to offer.

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

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

8.1.1 The Traditional Approach 8.1.2 The DevOps Approach 8.2 The Three Ways of DevOps 8.2.1 The First Way: Workflow 8.2.2 The Second Way: Improve Feedback 8.2.3 The Third Way: Continual Experimentation and Learning 8.2.4 Small Batches Are Better 8.2.5 Adopting the Strategies 8.3 History of DevOps 8.3.1 Evolution 8.3.2 Site Reliability Engineering 8.4 DevOps Values and Principles 8.4.1 Relationships 8.4.2 Integration 8.4.3 Automation 8.4.4 Continuous Improvement 8.4.5 Common Nontechnical DevOps Practices 8.4.6 Common Technical DevOps Practices 8.4.7 Release Engineering DevOps Practices 8.5 Converting to DevOps 8.5.1 Getting Started 8.5.2 DevOps at the Business Level 8.6 Agile and Continuous Delivery 8.6.1 What Is Agile? 8.6.2 What Is Continuous Delivery? 8.7 Summary Exercises 9 Service Delivery: The Build Phase 9.1 Service Delivery Strategies 9.1.1 Pattern: Modern DevOps Methodology 9.1.2 Anti-pattern: Waterfall Methodology 9.2 The Virtuous Cycle of Quality 9.3 Build-Phase Steps 9.3.1 Develop 9.3.2 Commit 9.3.3 Build 9.3.4 Package 9.3.5 Register 9.4 Build Console 9.5 Continuous Integration 9.6 Packages as Handoff Interface 9.7 Summary Exercises 10 Service Delivery: The Deployment Phase 10.1 Deployment-Phase Steps 10.1.1 Promotion 10.1.2 Installation 10.1.3 Configuration 10.2 Testing and Approval 10.2.1 Testing 10.2.2 Approval 10.3 Operations Console 10.4 Infrastructure Automation Strategies 10.4.1 Preparing Physical Machines 10.4.2 Preparing Virtual Machines 10.4.3 Installing OS and Services 10.5 Continuous Delivery 10.6 Infrastructure as Code 10.7 Other Platform Services 10.8 Summary Exercises 11 Upgrading Live Services 11.1 Taking the Service Down for Upgrading 11.2 Rolling Upgrades 11.3 Canary 11.4 Phased Roll-outs 11.5 Proportional Shedding 11.6 Blue-Green Deployment 11.7 Toggling Features 11.8 Live Schema Changes 11.9 Live Code Changes 11.10 Continuous Deployment 11.11 Dealing with Failed Code Pushes 11.12 Release Atomicity 11.13 Summary Exercises 12 Automation 12.1 Approaches to Automation 12.1.1 The Left-Over Principle 12.1.2 The Compensatory Principle 12.1.3 The Complementarity Principle 12.1.4 Automation for System Administration 12.1.5 Lessons Learned 12.2 Tool Building versus Automation 12.2.1 Example: Auto Manufacturing 12.2.2 Example: Machine Configuration 12.2.3 Example: Account Creation 12.2.4 Tools Are Good, But Automation Is Better 12.3 Goals of Automation 12.4 Creating Automation 12.4.1 Making Time to Automate 12.4.2 Reducing Toil 12.4.3 Determining What to Automate First 12.5 How to Automate 12.6 Language Tools 12.6.1 Shell Scripting Languages 12.6.2 Scripting Languages 12.6.3 Compiled Languages 12.6.4 Configuration Management Languages 12.7 Software Engineering Tools and Techniques 12.7.1 Issue Tracking Systems 12.7.2 Version Control Systems 12.7.3 Software Packaging 12.7.4 Style Guides 12.7.5 Test-Driven Development 12.7.6 Code Reviews 12.7.7 Writing Just Enough Code 12.8 Multitenant Systems 12.9 Summary Exercises 13 Design Documents 13.1 Design Documents Overview 13.1.1 Documenting Changes and Rationale 13.1.2 Documentation as a Repository of Past Decisions 13.2 Design Document Anatomy 13.3 Template 13.4 Document Archive 13.5 Review Workflows 13.5.1 Reviewers and Approvers 13.5.2 Achieving Sign-off 13.6 Adopting Design Documents 13.7 Summary Exercises 14 Oncall 14.1 Designing Oncall 14.1.1 Start with the SLA 14.1.2 Oncall Roster 14.1.3 Onduty 14.1.4 Oncall Schedule Design 14.1.5 The Oncall Calendar 14.1.6 Oncall Frequency 14.1.7 Types of Notifications 14.1.8 After-Hours Maintenance Coordination 14.2 Being Oncall 14.2.1 Pre-shift Responsibilities 14.2.2 Regular Oncall Responsibilities 14.2.3 Alert Responsibilities 14.2.4 Observe, Orient, Decide, Act (OODA) 14.2.5 Oncall Playbook 14.2.6 Third-Party Escalation 14.2.7 End-of-Shift Responsibilities 14.3 Between Oncall Shifts 14.3.1 Long-Term Fixes 14.3.2 Postmortems 14.4 Periodic Review of Alerts 14.5 Being Paged Too Much 14.6 Summary Exercises 15 Disaster Preparedness 15.1 Mindset 15.1.1 Antifragile Systems 15.1.2 Reducing Risk 15.2 Individual Training: Wheel of Misfortune 15.3 Team Training: Fire Drills 15.3.1 Service Testing 15.3.2 Random Testing 15.4 Training for Organizations: Game Day/DiRT 15.4.1 Getting Started 15.4.2 Increasing Scope 15.4.3 Implementation and Logistics 15.4.4 Experiencing a DiRT Test 15.5 Incident Command System 15.5.1 How It Works: Public Safety Arena 15.5.2 How It Works: IT Operations Arena 15.5.3 Incident Action Plan 15.5.4 Best Practices 15.5.5 ICS Example 15.6 Summary Exercises 16 Monitoring Fundamentals 16.1 Overview 16.1.1 Uses of Monitoring 16.1.2 Service Management 16.2 Consumers of Monitoring Information 16.3 What to Monitor 16.4 Retention 16.5 Meta-monitoring 16.6 Logs 16.6.1 Approach 16.6.2 Timestamps 16.7 Summary Exercises 17 Monitoring Architecture and Practice 17.1 Sensing and Measurement 17.1.1 Blackbox versus Whitebox Monitoring 17.1.2 Direct versus Synthesized Measurements 17.1.3 Rate versus Capability Monitoring 17.1.4 Gauges versus Counters 17.2 Collection 17.2.1 Push versus Pull 17.2.2 Protocol Selection 17.2.3 Server Component versus Agent versus Poller 17.2.4 Central versus Regional Collectors 17.3 Analysis and Computation 17.4 Alerting and Escalation Manager 17.4.1 Alerting, Escalation, and Acknowledgments 17.4.2 Silence versus Inhibit 17.5 Visualization 17.5.1 Percentiles 17.5.2 Stack Ranking 17.5.3 Histograms 17.6 Storage 17.7 Configuration 17.8 Summary Exercises 18 Capacity Planning 18.1 Standard Capacity Planning 18.1.1 Current Usage 18.1.2 Normal Growth 18.1.3 Planned Growth 18.1.4 Headroom 18.1.5 Resiliency 18.1.6 Timetable 18.2 Advanced Capacity Planning 18.2.1 Identifying Your Primary Resources 18.2.2 Knowing Your Capacity Limits 18.2.3 Identifying Your Core Drivers 18.2.4 Measuring Engagement 18.2.5 Analyzing the Data 18.2.6 Monitoring the Key Indicators 18.2.7 Delegating Capacity Planning 18.3 Resource Regression 18.4 Launching New Services 18.5 Reduce Provisioning Time 18.6 Summary Exercises 19 Creating KPIs 19.1 What Is a KPI?

…

While one may think of the build phase as the domain of developers and the deployment phase as the domain of operations, this is not true in a DevOps environment. Both groups share responsibility for the construction and use of the entire system. The handoff between steps marks the flow of work, not organizational boundaries. 9.1.2 Anti-pattern: Waterfall Methodology The waterfall methodology works differently from the modern DevOps methodology. It is predicated on multiple phases, each controlled by a different organization. Handoffs not only mark the flow of work, but also indicate the end of each organization’s responsibility. The waterfall methodology was previously discussed in Section 8.1.1.

Forge Your Future with Open Source by VM (Vicky) Brasseur

AGPL, anti-pattern, Benevolent Dictator For Life (BDFL), call centre, continuous integration, Contributor License Agreement, Debian, DevOps, don't repeat yourself, en.wikipedia.org, Firefox, FOSDEM, Free Software Foundation, Guido van Rossum, information security, Internet Archive, Larry Wall, microservices, Perl 6, premature optimization, pull request, Richard Stallman, risk tolerance, Turing machine

It’s far more effective to send a link to the appropriate documentation. scope creep When a feature or bug fix starts with a small set of requirements, but over time accumulates more and more requirements, greatly increasing the scope (and therefore also the risk as well as the time to complete) for the feature or bug fix. Scope creep is an anti-pattern in software development and should be avoided by any means possible. scrollback In real-time chat systems, the conversation that occurred while you were away from the chat session. Some systems store this for you automatically, while others (such as IRC) require a special setup to store and view scrollback.

Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs by Ken Kocienda

1960s counterculture, anti-pattern, Apple Newton, Apple's 1984 Super Bowl advert, bash_history, Bill Atkinson, Charles Lindbergh, conceptual framework, Donald Knuth, en.wikipedia.org, Free Software Foundation, HyperCard, Kickstarter, Lao Tzu, lock screen, premature optimization, profit motive, proprietary trading, QWERTY keyboard, reality distortion field, Richard Feynman, Richard Stallman, Robert X Cringely, Silicon Valley, Steve Ballmer, Steve Jobs, Steven Levy, The Soul of a New Machine, Tony Fadell, work culture , zero-sum game

It describes a top executive who is rarely around but flies in occasionally and unexpectedly from who knows where, lands on your beach, squawks noisily, flaps its wings all over the place, launches itself back into the air, circles overhead, drops a big poop on everyone, and then flies away, leaving the rest of the team to clean up the mess, figure out what it all meant, and wonder what to do about the inevitable follow-up visit.5 We didn’t establish large, cutting-edge software research departments sequestered from, and with a tenuous connection to, the designers and engineers responsible for creating and shipping the real products. Steve Jobs famously disbanded such an organization at Apple, the Advanced Technology Group, shortly after he reasserted control over the company in 1997. These kinds of anti-patterns can prevent creative selection from functioning correctly, since they block the steady accumulation of positive change while developing a product. They’re not the only ways the process can break down. You could build and release products without ever living on them to see if they’re any good, as we did with Nautilus and our online services at Eazel.

Developing Backbone.js Applications by Addy Osmani

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

An example template: {{#collection kittens tag="ul"}} <li>{{name}}</li> {{/collection}} And the corresponding view class: Thorax.View.extend({ events: { 'click li': function(event) { var kitten = $(event.target).model(); console.log('Clicked on ' + kitten.get('name')); } }, kittens: new Thorax.Collection(...), template: ... }); A common anti-pattern in Backbone applications is to assign a className to a single view class. Consider using the data-view-name attribute as a CSS selector instead, saving CSS classes for things that will be used multiple times: [data-view-name="child"] { } Thorax Resources No Backbone related tutorial would be complete without a todo application.

Technical Blogging: Turn Your Expertise Into a Remarkable Online Presence by Antonio Cangiano

23andMe, Albert Einstein, anti-pattern, bitcoin, bounce rate, cloud computing, content marketing, en.wikipedia.org, Hacker News, John Gruber, Kickstarter, Lean Startup, lolcat, Network effects, Paradox of Choice, revision control, Ruby on Rails, search engine result page, slashdot, software as a service, web application

http://daringfireball.net: News and opinions about Apple by an unrepentant advocate of Apple products. Reason to read it: It provides fresh insight, interesting controversy, and news about Apple and its competitors delivered by an established community pundit. http://thedailywtf.com: Daily examples of bad programming. Reason to read it: To learn more about anti-patterns in programming, and for the amusement. http://igvita.com: HOWTO articles on cutting-edge open source technologies. Reason to read it: To learn how to use some of the coolest technologies around and apply them to real-world problems. http://sethgodin.typepad.com: Marketing ideas and opinions.

Speaking JavaScript: An In-Depth Guide for Programmers by Axel Rauschmayer

Airbnb, anti-pattern, digital divide, en.wikipedia.org, fail fast, Firefox, functional programming, higher-order functions, machine readable, web application

I’ll later explain why that is not recommended. A constructor usually sets instance properties to initial values. If one such value is a default, then you don’t need to create an instance property. You only need a prototype property with the same key whose value is the default. For example: /** * Anti-pattern: don’t do this * * @param data an array with names */ function Names(data) { if (data) { // There is a parameter // => create instance property this.data = data; } } Names.prototype.data = []; The parameter data is optional. If it is missing, the instance does not get a property data, but inherits Names.prototype.data instead.

Lessons-Learned-in-Software-Testing-A-Context-Driven-Approach by Anson-QA

anti-pattern, Chuck Templeton: OpenTable:, finite state, framing effect, full employment, independent contractor, information retrieval, job automation, knowledge worker, lateral thinking, Ralph Nader, Richard Feynman, side project, Silicon Valley, statistical model, systems thinking, tacit knowledge, web application

Group after group has created test-planning templates based on Standard 829 and then created worthless documents that followed the template. Initially, we thought that the problem was in the people; they misapplied the standard. Later, we concluded that the problem must be deeper because it was widespread, and it snared people who we respected. The pattern (or anti-pattern) that we saw was that a test group would create or borrow a template and invest a substantial initial burst of paperwork- filling energy that yielded an initial not-very-informative mass of material. They then ran into the costs and constraints of this type of documentation effort and gradually abandoned it.

Succeeding With AI: How to Make AI Work for Your Business by Veljko Krunic

AI winter, Albert Einstein, algorithmic trading, AlphaGo, Amazon Web Services, anti-fragile, anti-pattern, artificial general intelligence, autonomous vehicles, Bayesian statistics, bioinformatics, Black Swan, Boeing 737 MAX, business process, cloud computing, commoditize, computer vision, correlation coefficient, data is the new oil, data science, deep learning, DeepMind, en.wikipedia.org, fail fast, Gini coefficient, high net worth, information retrieval, Internet of things, iterative process, job automation, Lean Startup, license plate recognition, minimum viable product, natural language processing, recommendation engine, self-driving car, sentiment analysis, Silicon Valley, six sigma, smart cities, speech recognition, statistical model, strong AI, tail risk, The Design of Experiments, the scientific method, web application, zero-sum game

Consequently, any argument that a PhD is needed to manage an AI project is actually an argument that a successful AI project is a rarity. 4.2.6 You need the right business metric As explained in chapter 3, it’s important to use the right business metrics to measure the progress of your AI project. Surprisingly, often the right business metrics aren’t developed early in the project. This section reminds you of the pitfalls of having the wrong business metrics. One common anti-pattern is to allow business metrics to emerge from the nomination of various team members with no additional analysis. Often, those metrics are transplants that someone has seen used on previous projects. It’s not uncommon for teams to think that because previous projects used a business metric successfully, they should use the same metric again.

ZeroMQ by Pieter Hintjens

AGPL, anti-pattern, behavioural economics, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, eat what you kill, Eben Moglen, exponential backoff, factory automation, fail fast, fault tolerance, fear of failure, finite state, Internet of things, iterative process, no silver bullet, power law, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket

Code that wants to scale without limit does it like the Internet does, by sending messages and sharing nothing except a common contempt for broken programming models. You should follow some rules to write happy multithreaded code with ØMQ: You must not access the same data from multiple threads. Using classic MT techniques like mutexes is an anti-pattern in ØMQ applications. The only exception to this is a ØMQ context object, which is threadsafe. You must create a ØMQ context for your process, and pass that to all threads that you want to connect via inproc sockets. You may treat threads as separate tasks with their own context, but these threads cannot communicate over inproc.

The Rust Programming Language by Steve Klabnik, Carol Nichols

anti-pattern, billion-dollar mistake, bioinformatics, business logic, business process, cryptocurrency, data science, DevOps, duck typing, Firefox, functional programming, Internet of things, iterative process, pull request, reproducible builds, Ruby on Rails, type inference

We’re not currently conveying this meaning in the structure of the data other than by grouping the two values into a tuple; we could put the two values into one struct and give each of the struct fields a meaningful name. Doing so will make it easier for future maintainers of this code to understand how the different values relate to each other and what their purpose is. NOTE Some people call this anti-pattern of using primitive values when a complex type would be more appropriate primitive obsession. Listing 12-6 shows the improvements to the parse_config function. src/main.rs fn main() { let args: Vec<String> = env::args().collect(); ➊ let config = parse_config(&args); println!("Searching for {}", config.query➋); println!

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

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

The "play game" module that controls the main gameplay. The "play game" module and the main display module are the largest within Wesnoth. Their purpose is the least well defined, as their function is ever-changing and thus difficult to have a clear specification for. Consequently, the modules has often been in danger of suffering from the Blob anti-pattern over the program's history—i.e., becoming huge dominant segments without well-defined behaviors. The code in the display and play game modules are regularly reviewed to see if any of it can be separated into a module of its own. There are also ancillary features that are part of the overall project, but are separate from the main program.

The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise by Martin L. Abbott, Michael T. Fisher

always be closing, anti-pattern, barriers to entry, Bernie Madoff, business climate, business continuity plan, business intelligence, business logic, business process, call centre, cloud computing, combinatorial explosion, commoditize, Computer Numeric Control, conceptual framework, database schema, discounted cash flows, Dunning–Kruger effect, en.wikipedia.org, fault tolerance, finite state, friendly fire, functional programming, hiring and firing, Infrastructure as a Service, inventory management, machine readable, new economy, OSI model, packet switching, performance metric, platform as a service, Ponzi scheme, power law, RFC: Request For Comment, risk tolerance, Rubik’s Cube, Search for Extraterrestrial Intelligence, SETI@home, shareholder value, Silicon Valley, six sigma, software as a service, the scientific method, transaction costs, Vilfredo Pareto, web application, Y2K

See also AKF Scale Cube for databases. cost, 366, 367 description, 365–367 pros and cons, 366 summary of, 367–370 559 This page intentionally left blank Design Patterns for Succeeding with Enterprise Mashups: One of Today’s Fastest-Growing Areas of Software Development Mashup Patterns: Designs and Examples for the Modern Enterprise Michael Ogrinz • ISBN-13: 978-0-321-57947-8 • Contains authoritative insights based on extensive real-world experience, from one of the world’s leading innovators in enterprise mashups and integration • Covers every part of the mashup development lifecycle, from planning core functionality through integration, testing, and much more • Includes multiple real-world case studies, dozens of patterns, and a full chapter of must-avoid “anti-patterns” In this book, leading enterprise mashup expert Michael Ogrinz provides more than fifty new patterns that cover virtually every facet of enterprise mashup development, from core functionality through integration, and beyond. These patterns address crucial issues including data extraction and visualization, reputation management, security, accessibility, usability, content migration, load and regression testing, governance, and more.

Rationality: From AI to Zombies by Eliezer Yudkowsky

Albert Einstein, Alfred Russel Wallace, anthropic principle, anti-pattern, anti-work, antiwork, Arthur Eddington, artificial general intelligence, availability heuristic, backpropagation, Bayesian statistics, behavioural economics, Berlin Wall, Boeing 747, Build a better mousetrap, Cass Sunstein, cellular automata, Charles Babbage, cognitive bias, cognitive dissonance, correlation does not imply causation, cosmological constant, creative destruction, Daniel Kahneman / Amos Tversky, dematerialisation, different worldview, discovery of DNA, disinformation, Douglas Hofstadter, Drosophila, Eddington experiment, effective altruism, experimental subject, Extropian, friendly AI, fundamental attribution error, Great Leap Forward, Gödel, Escher, Bach, Hacker News, hindsight bias, index card, index fund, Isaac Newton, John Conway, John von Neumann, Large Hadron Collider, Long Term Capital Management, Louis Pasteur, mental accounting, meta-analysis, mirror neurons, money market fund, Monty Hall problem, Nash equilibrium, Necker cube, Nick Bostrom, NP-complete, One Laptop per Child (OLPC), P = NP, paperclip maximiser, pattern recognition, Paul Graham, peak-end rule, Peter Thiel, Pierre-Simon Laplace, placebo effect, planetary scale, prediction markets, random walk, Ray Kurzweil, reversible computing, Richard Feynman, risk tolerance, Rubik’s Cube, Saturday Night Live, Schrödinger's Cat, scientific mainstream, scientific worldview, sensible shoes, Silicon Valley, Silicon Valley startup, Singularitarianism, SpaceShipOne, speech recognition, statistical model, Steve Jurvetson, Steven Pinker, strong AI, sunk-cost fallacy, technological singularity, The Bell Curve by Richard Herrnstein and Charles Murray, the map is not the territory, the scientific method, Turing complete, Turing machine, Tyler Cowen, ultimatum game, X Prize, Y Combinator, zero-sum game

You mean ((A and B) and [(A and B) → Z]) → Z, don’t you?” As Hofstadter says, “Whatever Achilles considers a rule of inference, the Tortoise immediately flattens into a mere string of the system. If you use only the letters A, B, and Z, you will get a recursive pattern of longer and longer strings.” This is the anti-pattern I call Passing the Recursive Buck; and though the counterspell is sometimes hard to find, when found, it generally takes the form The Buck Stops Immediately. The Tortoise’s mind needs the dynamic of adding Y to the belief pool when X and (X → Y) are previously in the belief pool. If this dynamic is not present—a rock, for example, lacks it—then you can go on adding in X and (X → Y) and ((X and (X → Y)) → Y) until the end of eternity, without ever getting to Y.