anti-pattern

20 results back to index


pages: 504 words: 67,845

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

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

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! News, Activation Dialog Inlay, Dialog Inlay, Dialog Inlay, In context, In context, In context BBC home page, Dialog Inlay best practices, In context My 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! Buzz, Visual noise Yahoo! Mail, Discoverability Zooomr, Anti-pattern: Mystery Meat Hybrid Selection, Direct Selection, Hybrid Selection, Hybrid Selection, Considerations, Blending two models, Blending two models best practices, Blending two models confusing two models, Considerations Yahoo!


pages: 224 words: 48,804

The Productive Programmer by Neal Ford

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

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, Ruby on Rails, side project, type inference, web application, William of Occam

Some hard-fought knowledge about software development is not intuitive. 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.

We know all sorts of ways to deal with code: diff to compare versions, refactoring, robust testing libraries. 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.

They got their code in the standard place, and we got to use the tool best suited for our work. 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.


pages: 349 words: 114,038

Culture & Empire: Digital Revolution by Pieter Hintjens

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

4chan, airport security, anti-communist, anti-pattern, barriers to entry, Bill Duvall, bitcoin, blockchain, business climate, business intelligence, business process, Chelsea Manning, clean water, commoditize, congestion charging, Corn Laws, correlation does not imply causation, cryptocurrency, Debian, Edward Snowden, failed state, financial independence, Firefox, full text search, German hyperinflation, global village, GnuPG, Google Chrome, greed is good, Hernando de Soto, hiring and firing, informal economy, intangible asset, invisible hand, James Watt: steam engine, Jeff Rulifson, Julian Assange, Kickstarter, M-Pesa, mass immigration, mass incarceration, mega-rich, mutually assured destruction, Naomi Klein, national security letter, new economy, New Urbanism, Occupy movement, offshore financial centre, packet switching, patent troll, peak oil, pre–internet, private military company, race to the bottom, rent-seeking, reserve currency, RFC: Request For Comment, Richard Feynman, Richard Feynman, Richard Stallman, 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, 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. Like planting a forest tree by tree, it's a slow and almost invisible process and one that is, for me, absolutely key to understanding digital society.

Self-Organization Some people like to be told what to do. 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. TIP: Write rules to raise the quality of work and to explicitly allow anyone to work on anything they find interesting.

Power structures are like liquid cement; they harden and stop people from moving around as they need to. Any structure defends itself. 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. This is a difficult lesson that applies to broad society as well: there are no dangerous opinions, only dangerous responses.


pages: 372 words: 67,140

Jenkins Continuous Integration Cookbook by Alan Berg

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

anti-pattern, continuous integration, Debian, don't repeat yourself, en.wikipedia.org, Firefox, job automation, performance metric, revision control, web application, x509 certificate

The includes override specific file types under the src directory. 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. You should also consider splitting into two Jobs, and then pointing the RATs Job at the source codes 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. Luckily, at the bottom of every Jenkins page, there is a link that volunteers can use to upload translations.

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. See also Finding bugs with FindBugs Finding security defects with FindBugs Activating more PMD rulesets Finding security defects with FindBugs In this recipe, you will use FindBugs to discover a security flaw in a Java Server Page and some more security defects in a defective Java class.


pages: 201 words: 63,192

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

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

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

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.

START email = node:email(id = '11') MATCH (email)<-[f:FORWARD_OF*]-() RETURN count(f) The above query starts at the given email and then matches against all incoming FOR WARD_OF relationships to any depth. 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. It’s also important to realize that graphs are a naturally additive structure. It’s quite natural to add facts in terms of domain entities and how they interrelate using new nodes and new relationships, even if it feels like you’re flooding the database with a great deal of painstaking data.

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

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

anti-pattern, domain-specific language, en.wikipedia.org, Firefox, 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. For a general introduction to Unicode, read “Unicode and JavaScript¹” (a chapter in “Speaking JavaScript”). 26.1 Unicode is better supported in ES6 There are three areas in which ECMAScript 6 has improved support for Unicode: • Unicode escapes for code points beyond 16 bits: \u{···} Can be used in identifiers, string literals, template literals and regular expression literals.

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.


pages: 540 words: 103,101

Building Microservices by Sam Newman

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

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

A good rule of thumb is that you probably want an order of magnitude more tests as you descend the pyramid, but the important thing is knowing that you do have different types of automated tests and understanding if your current balance gives you a problem! 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. When they break, everyone assumes it is someone else’s problem, so they don’t care whether the tests are passing.


pages: 153 words: 27,424

REST API Design Rulebook by Mark Masse

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

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

Rule: CRUD function names should not be used in URIs URIs should not be used to indicate that a CRUD[22] function is performed. 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. URI Query Design This section provides rules relating to the design of URI queries.


pages: 719 words: 181,090

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

Air France Flight 447, anti-pattern, barriers to entry, business intelligence, business process, Checklist Manifesto, cloud computing, combinatorial explosion, continuous integration, correlation does not imply causation, crowdsourcing, database schema, defense in depth, DevOps, en.wikipedia.org, fault tolerance, Flash crash, George Santayana, Google Chrome, Google Earth, job automation, job satisfaction, linear programming, load shedding, loose coupling, meta analysis, meta-analysis, minimum viable product, MVC pattern, performance metric, platform as a service, revision control, risk tolerance, side project, six sigma, the scientific method, Toyota Production System, trickle-down economics, web application, zero day

Recognizing that you will hire people who have a mix of these preferences, it would be shortsighted to only cater to one style at the expense of the others. 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.

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

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

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

The implementation might have bugs, but at least addTextChangedListener will never be passed, say, an object intended to respond to network events. That is what polymorphism is all about. 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. As usual, there are no hard and fast rules about interface pollution. There is, as already noted, lots of working code that looks just like this.


pages: 655 words: 141,257

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

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

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

The implementation might have bugs, but at least addTextChangedListener will never be passed, say, an object intended to respond to network events. That is what polymorphism is all about. 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. As usual, there are no hard and fast rules about interface pollution. There is, as already noted, lots of working code that looks just like this.


pages: 209 words: 54,638

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

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

anti-pattern, barriers to entry, cognitive dissonance, Dean Kamen, en.wikipedia.org, fear of failure, Guido van Rossum, Paul Graham, publish or perish, Richard Stallman, Silicon Valley, Steve Jobs, 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. I wish I’d had this book years ago.” — Brian Behlendorf “Software Development is a team sport.

Sass and Compass for Designers by Ben Frain

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

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.


pages: 420 words: 79,867

Developing Backbone.js Applications by Addy Osmani

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

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

In Thorax, this can particularly useful in conjunction with the collection helper which generates a view class (with a model property) for each model in the collection. 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. A Thorax implementation of TodoMVC is available, in addition to this far simpler example composed of this single Handlebars template: {{#collection todos tag="ul"}} <li{{#if done}} class="done"{{/if}}> <input type="checkbox" name="done"{{#if done}} checked="checked"{{/if}}> <span>{{item}}</span> </li> {{/collection}} <form> <input type="text"> <input type="submit" value="Add"> </form> and the corresponding JavaScript: var todosView = Thorax.View({ todos: new Thorax.Collection(), events: { 'change input[type="checkbox"]': function(event) { var target = $(event.target); target.model().set({done: !!


pages: 757 words: 193,541

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

active measures, Amazon Web Services, anti-pattern, barriers to entry, business process, cloud computing, commoditize, continuous integration, correlation coefficient, database schema, Debian, defense in depth, delayed gratification, DevOps, domain-specific language, en.wikipedia.org, fault tolerance, finite state, Firefox, Google Glasses, information asymmetry, Infrastructure as a Service, intermodal, Internet of things, job automation, job satisfaction, load shedding, loose coupling, Malcom McLean invented shipping containers, Marc Andreessen, place-making, platform as a service, premature optimization, recommendation engine, revision control, risk tolerance, side project, Silicon Valley, software as a service, sorting algorithm, statistical model, Steven Levy, supply-chain management, Toyota Production System, web application, Yogi Berra

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?

There is no good reason to not invest in the additional infrastructure for a proper test environment—it always pays for itself in increased service availability. 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. The waterfall methodology has many phases.


pages: 315 words: 85,791

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

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

Albert Einstein, anti-pattern, bitcoin, bounce rate, cloud computing, en.wikipedia.org, John Gruber, Lean Startup, Network effects, revision control, Ruby on Rails, search engine result page, slashdot, software as a service, web application

Reason to read it: To stay up-to-date and keep a pulse on the Ruby ecosystem. 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. Reason to read it: To improve your marketing skills with the aid of a leader in the marketing world via thought-provoking ideas and insight.


pages: 1,025 words: 150,187

ZeroMQ by Pieter Hintjens

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

anti-pattern, carbon footprint, cloud computing, Debian, distributed revision control, domain-specific language, factory automation, fault tolerance, fear of failure, finite state, Internet of things, iterative process, premature optimization, profit motive, pull request, revision control, RFC: Request For Comment, Richard Stallman, Skype, smart transportation, software patent, Steve Jobs, Valgrind, WebSocket

Some widely used models, despite being the basis for entire industries, are fundamentally broken, and shared state concurrency is one of them. 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. However, they will be easier to break into standalone processes afterwards.


pages: 834 words: 180,700

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

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

8-hour work day, anti-pattern, bioinformatics, c2.com, cloud computing, collaborative editing, combinatorial explosion, computer vision, continuous integration, create, read, update, delete, David Heinemeier Hansson, Debian, domain-specific language, Donald Knuth, en.wikipedia.org, fault tolerance, finite state, Firefox, friendly fire, Guido van Rossum, linked data, load shedding, locality of reference, loose coupling, Mars Rover, MVC pattern, peer-to-peer, Perl 6, premature optimization, recommendation engine, revision control, Ruby on Rails, side project, Skype, slashdot, social web, speech recognition, the scientific method, The Wisdom of Crowds, web application, WebSocket

The lobby module, for displaying and allowing setup of games on the multiplayer server. 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. This includes a multiplayer server that facilitates multiplayer network games, as well as a content server that allows users to upload their content to a common server and share it with others.


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 process, call centre, cloud computing, combinatorial explosion, commoditize, Computer Numeric Control, conceptual framework, database schema, discounted cash flows, en.wikipedia.org, fault tolerance, finite state, friendly fire, hiring and firing, Infrastructure as a Service, inventory management, new economy, packet switching, performance metric, platform as a service, Ponzi scheme, 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.


pages: 1,737 words: 491,616

Rationality: From AI to Zombies by Eliezer Yudkowsky

Albert Einstein, Alfred Russel Wallace, anthropic principle, anti-pattern, anti-work, Arthur Eddington, artificial general intelligence, availability heuristic, Bayesian statistics, Berlin Wall, Build a better mousetrap, Cass Sunstein, cellular automata, cognitive bias, cognitive dissonance, correlation does not imply causation, cosmological constant, creative destruction, Daniel Kahneman / Amos Tversky, dematerialisation, discovery of DNA, Douglas Hofstadter, Drosophila, effective altruism, experimental subject, Extropian, friendly AI, fundamental attribution error, Gödel, Escher, Bach, hindsight bias, index card, index fund, Isaac Newton, John Conway, John von Neumann, Long Term Capital Management, Louis Pasteur, mental accounting, meta analysis, meta-analysis, money market fund, Nash equilibrium, Necker cube, NP-complete, P = NP, pattern recognition, Paul Graham, Peter Thiel, Pierre-Simon Laplace, placebo effect, planetary scale, prediction markets, random walk, Ray Kurzweil, reversible computing, Richard Feynman, Richard Feynman, risk tolerance, Rubik’s Cube, Saturday Night Live, Schrödinger's Cat, scientific mainstream, sensible shoes, Silicon Valley, Silicon Valley startup, Singularitarianism, Solar eclipse in 1919, speech recognition, statistical model, Steven Pinker, strong AI, technological singularity, The Bell Curve by Richard Herrnstein and Charles Murray, the map is not the territory, the scientific method, Turing complete, Turing machine, ultimatum game, X Prize, Y Combinator, zero-sum game

Douglas Hofstadter paraphrased the argument some time later: ACHILLES: “If you have [(A and B) → Z], and you also have (A and B), then surely you have Z.” TORTOISE: “Oh! 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.