DOCSLIB.ORG

Chris Richardson

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Chris Richardson MANNING www.EBooksWorld.ir List of Patterns Application architecture patterns External API patterns Monolithic architecture (40) API gateway (259) Microservice architecture (40) Backends for frontends (265) Decomposition patterns Testing patterns Decompose by business capability (51) Consumer-driven contract test (302) Decompose by subdomain (54) Consumer-side contract test (303) Service component test (335) Messaging style patterns Messaging (85) Security patterns Remote procedure invocation (72) Access token (354) Reliable communications patterns Cross-cutting concerns patterns Circuit breaker (78) Externalized configuration (361) Microservice chassis (379) Service discovery patterns 3rd party registration (85) Observability patterns Client-side discovery (83) Application metrics (373) Self-registration (82) Audit logging (377) Server-side discovery (85) Distributed tracing (370) Exception tracking (376) Transactional messaging patterns Health check API (366) Polling publisher (98) Log aggregation (368) Transaction log tailing (99) Transactional outbox (98) Deployment patterns Deploy a service as a container (393) Data consistency patterns Deploy a service as a VM (390) Saga (114) Language-specific packaging format (387) Service mesh (380) Business logic design patterns Serverless deployment (416) Aggregate (150) Sidecar (410) Domain event (160) Domain model (150) Refactoring to microservices patterns Event sourcing (184) Anti-corruption layer (447) Transaction script (149) Strangler application (432) Querying patterns API composition (223) Command query responsibility segregation (228) www.EBooksWorld.ir Microservices Patterns www.EBooksWorld.ir www.EBooksWorld.ir Microservices Patterns WITH EXAMPLES IN JAVA CHRIS RICHARDSON MANNING SHELTER ISLAND www.EBooksWorld.ir For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: [email protected] ©2019 by Chris Richardson. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. Manning Publications Co. Development editor: Marina Michaels 20 Baldwin Road Technical development editor: Christian Mennerich PO Box 761 Review editor: Aleksandar Dragosavljevic´ Shelter Island, NY 11964 Project editor: Lori Weidert Copy editor: Corbin Collins Proofreader: Alyson Brener Technical proofreader: Andy Miles Typesetter: Dennis Dalinnik Cover designer: Marija Tudor ISBN: 9781617294549 Printed in the United States of America 12345678910–DP–232221201918 www.EBooksWorld.ir Where you see wrong or inequality or injustice, speak out, because this is your country. This is your democracy. Make it. Protect it. Pass it on. — Thurgood Marshall, Justice of the Supreme Court www.EBooksWorld.ir www.EBooksWorld.ir brief contents 1 ■ Escaping monolithic hell 1 2 ■ Decomposition strategies 33 3 ■ Interprocess communication in a microservice architecture 65 4 ■ Managing transactions with sagas 110 5 ■ Designing business logic in a microservice architecture 146 6 ■ Developing business logic with event sourcing 183 7 ■ Implementing queries in a microservice architecture 220 8 ■ External API patterns 253 9 ■ Testing microservices: Part 1 292 10 ■ Testing microservices: Part 2 318 11 ■ Developing production-ready services 348 12 ■ Deploying microservices 383 13 ■ Refactoring to microservices 428 vii www.EBooksWorld.ir www.EBooksWorld.ir contents preface xvii acknowledgments xx about this book xxii about the cover illustration xxvi Escaping monolithic hell 1 1 1.1 The slow march toward monolithic hell 2 The architecture of the FTGO application 3 ■ The benefits of the monolithic architecture 4 ■ Living in monolithic hell 4 1.2 Why this book is relevant to you 7 1.3 What you’ll learn in this book 7 1.4 Microservice architecture to the rescue 8 Scale cube and microservices 8 ■ Microservices as a form of modularity 11 ■ Each service has its own database 12 The FTGO microservice architecture 12 ■ Comparing the microservice architecture and SOA 13 1.5 Benefits and drawbacks of the microservice architecture 14 Benefits of the microservice architecture 14 ■ Drawbacks of the microservice architecture 17 ix www.EBooksWorld.ir x CONTENTS 1.6 The Microservice architecture pattern language 19 Microservice architecture is not a silver bullet 19 ■ Patterns and pattern languages 20 ■ Overview of the Microservice architecture pattern language 23 1.7 Beyond microservices: Process and organization 29 Software development and delivery organization 29 ■ Software development and delivery process 30 ■ The human side of adopting microservices 31 Decomposition strategies 33 2 2.1 What is the microservice architecture exactly? 34 What is software architecture and why does it matter? 34 Overview of architectural styles 37 ■ The microservice architecture is an architectural style 40 2.2 Defining an application’s microservice architecture 44 Identifying the system operations 45 ■ Defining services by applying the Decompose by business capability pattern 51 Defining services by applying the Decompose by sub-domain pattern 54 ■ Decomposition guidelines 56 ■ Obstacles to decomposing an application into services 57 ■ Defining service APIs 61 Interprocess communication in a microservice architecture 65 3 3.1 Overview of interprocess communication in a microservice architecture 66 Interaction styles 67 ■ Defining APIs in a microservice architecture 68 ■ Evolving APIs 69 ■ Message formats 71 3.2 Communicating using the synchronous Remote procedure invocation pattern 72 Using REST 73 ■ Using gRPC 76 ■ Handling partial failure using the Circuit breaker pattern 77 ■ Using service discovery 80 3.3 Communicating using the Asynchronous messaging pattern 85 Overview of messaging 86 ■ Implementing the interaction styles using messaging 87 ■ Creating an API specification for a messaging-based service API 89 ■ Using a message broker 90 Competing receivers and message ordering 94 ■ Handling duplicate messages 95 ■ Transactional messaging 97 Libraries and frameworks for messaging 100 www.EBooksWorld.ir CONTENTS xi 3.4 Using asynchronous messaging to improve availability 103 Synchronous communication reduces availability 103 Eliminating synchronous interaction 104 Managing transactions with sagas 110 4 4.1 Transaction management in a microservice architecture 111 The need for distributed transactions in a microservice architecture 112 ■ The trouble with distributed transactions 112 ■ Using the Saga pattern to maintain data consistency 114 4.2 Coordinating sagas 117 Choreography-based sagas 118 ■ Orchestration-based sagas 121 4.3 Handling the lack of isolation 126 Overview of anomalies 127 ■ Countermeasures for handling the lack of isolation 128 4.4 The design of the Order Service and the Create Order Saga 132 The OrderService class 133 ■ The implementation of the Create Order Saga 135 ■ The OrderCommandHandlers class 142 The OrderServiceConfiguration class 143 Designing business logic in a microservice architecture 146 5 5.1 Business logic organization patterns 147 Designing business logic using the Transaction script pattern 149 Designing business logic using the Domain model pattern 150 About Domain-driven design 151 5.2 Designing a domain model using the DDD aggregate pattern 152 The problem with fuzzy boundaries 153 ■ Aggregates have explicit boundaries 154 ■ Aggregate rules 155 ■ Aggregate granularity 158 ■ Designing business logic with aggregates 159 5.3 Publishing domain events 160 Why publish change events? 160 ■ What is a domain event? 161 ■ Event enrichment 161 ■ Identifying domain events 162 ■ Generating and publishing domain events 164 Consuming domain events 167 www.EBooksWorld.ir xii CONTENTS 5.4 Kitchen Service business logic 168 The Ticket aggregate 169 5.5 Order Service business logic 173 The Order Aggregate 175 ■ The OrderService class 180 Developing business logic with event sourcing 183 6 6.1 Developing business logic using event sourcing 184 The trouble with traditional persistence 185 ■ Overview of event sourcing 186 ■ Handling concurrent updates using optimistic locking 193 ■ Event sourcing and publishing events 194 Using snapshots to improve performance 195 ■ Idempotent message processing 197 ■ Evolving domain events 198 Benefits of event sourcing 199 ■ Drawbacks of event sourcing 200 6.2 Implementing an event store 202 How the Eventuate Local event store works 203 ■ The Eventuate client framework for Java 205 6.3 Using sagas and event sourcing together 209 Implementing choreography-based sagas using event sourcing 210 Creating
Recommended publications
  • Automatically Detecting ORM Performance Anti-Patterns on C# Applications Tuba Kaya Master's Thesis 23–09-2015

    Automatically Detecting ORM Performance Anti-Patterns on C# Applications Tuba Kaya Master's Thesis 23–09-2015

    Automatically Detecting ORM Performance Anti-Patterns on C# Applications Tuba Kaya Master's Thesis 23–09-2015 Master Software Engineering University of Amsterdam Supervisors: Dr. Raphael Poss (UvA), Dr. Giuseppe Procaccianti (VU), Prof. Dr. Patricia Lago (VU), Dr. Vadim Zaytsev (UvA) i Abstract In today’s world, Object Orientation is adopted for application development, while Relational Database Management Systems (RDBMS) are used as default on the database layer. Unlike the applications, RDBMSs are not object oriented. Object Relational Mapping (ORM) tools have been used extensively in the field to address object-relational impedance mismatch problem between these object oriented applications and relational databases. There is a strong belief in the industry and a few empirical studies which suggest that ORM tools can cause decreases in application performance. In this thesis project ORM performance anti-patterns for C# applications are listed. This list has not been provided by any other study before. Next to that, a design for an ORM tool agnostic framework to automatically detect these anti-patterns on C# applications is presented. An application is developed according to the designed framework. With its implementation of analysis on syntactic and semantic information of C# applications, this application provides a foundation for researchers wishing to work further in this area. ii Acknowledgement I would like to express my gratitude to my supervisor Dr. Raphael Poss for his excellent support through the learning process of this master thesis. Also, I like to thank Dr. Giuseppe Procaccianti and Prof. Patricia Lago for their excellent supervision and for providing me access to the Green Lab at Vrije Universiteit Amsterdam.
  • 1. Domain Modeling

    1. Domain Modeling

    Software design pattern seminar sse, ustc Topic 8 Observer, Mediator, Facade Group K 1. The observer pattern (Behavioral pattern, chapter 16 and 17) 1) the observer is an interface or abstract class defining the operations to be used to update itself 2) a solution to these problems A. Decouple change and related responses so that such dependencies can be added or removed freely and dynamically 3) solution A. Observable defines the operations for attaching, de-attaching and notifying observers B. Observer defines the operations to update itself 4) liabilities A. Unwanted concurrent update to a concrete observable may occur Figure 1 Sample Observer Pattern 2. The mediator pattern (Behavioral pattern, chapter 16 and 17) 1) the mediator encapsulates how a set of objects interact and keeps objects from referring to each other explicitly 2) a solution to these problems A. a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand B. reusing an object is difficult because it refers to and communicates with many other objects C. a behavior that's distributed between several classes should be customizable without a lot of subclassing 3) solution A. Mediator defines an interface for communicating with Colleague objects, knows the colleague classes and keep a reference to the colleague objects, and implements the communication and transfer the messages between the colleague classes 1 Software design pattern seminar sse, ustc B. Colleague classes keep a reference to its Mediator object, and communicates with the Mediator whenever it would have otherwise communicated with another Colleague 4) liabilities A.
  • FAKULT¨AT F¨UR INFORMATIK Architectural Design And

    FAKULT¨AT F¨UR INFORMATIK Architectural Design And

    FAKULTAT¨ FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Masterarbeit in Informatik Architectural Design and Implementation of a Web Application for Adaptive Data Models Stefan Bleibinhaus FAKULTAT¨ FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Masterarbeit in Informatik Architectural Design and Implementation of a Web Application for Adaptive Data Models Architektur Design und Implementierung einer Web Anwendung fur¨ adaptive Datenmodelle Author: Stefan Bleibinhaus Supervisor: Prof. Florian Matthes Advisor: Matheus Hauder Date: April 15, 2013 Ich versichere, dass ich diese Masterarbeit selbstandig¨ verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. I assure the single handed composition of this master thesis only supported by declared resources. Munchen,¨ den 15. April 2013 Stefan Bleibinhaus Acknowledgments I would like to express my very great appreciation to Prof. Florian Matthes for offering me to write my thesis on such a delightful topic and showing so much interest in my work. I am particularly grateful for the assistance given by Matheus Hauder and his will to support me in my research. vii Abstract This thesis discusses the architectural design and implementation of an Enterprise 2.0 collaboration web application. The designed web application uses the concept of hybrid wikis for enabling business users to capture easily content in structured form. A Hybrid wiki is a wiki, which empowers business users to incrementally structure and classify content objects without the struggle of being enforced to use strict information structures. The emergent information structure in a hybrid wiki evolves in daily use by the interaction with its users. Whenever a user wants to extend the content, the system guides them to automatically structure it by using user interface friendly methods like auto-completion and unobtrusive suggestions based on previous similar content.
  • Software Architecture: Past, Present, Future

    Software Architecture: Past, Present, Future

    Software Architecture: Past, Present, Future Wilhelm Hasselbring 1 Introduction For large, complex software systems, the design of the overall system structure (the software architecture) is an essential challenge. The architecture of a software system defines that system in terms of components and connections among those components [55, 58]. It is not the design of that system which is more detailed. The architecture shows the correspondence between the requirements and the constructed system, thereby providing some rationale for the design decisions. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, and frameworks for systems that serve the needs of specific application domains. An architecture embodies decisions about quality properties. It represents the earliest opportunity for evaluating those decisions. Furthermore, reusability of components and services depends on how strongly coupled they are with other components in the system architecture. Performance, for instance, depends largely upon the complexity of the required coordination, in particular when the components are distributed via some network. The architecture is usually the first artifact to be examined when a programmer (particularly a maintenance programmer) unfamiliar with the system begins to work on it. Software architecture is often the first design artifact that represents decisions on how requirements of all types are to be achieved. As the manifestation of early design decisions, it represents design decisions that are hardest to change and hence most deserving of careful consideration. W. Hasselbring () Kiel University, Kiel, Germany e-mail: [email protected] © The Author(s) 2018 169 V.
  • Dynamic Data Access Object Design Pattern (CECIIS 2008)

    Dynamic Data Access Object Design Pattern (CECIIS 2008)

    Dynamic Data Access Object Design Pattern (CECIIS 2008) Zdravko Roško, Mario Konecki Faculty of Organization and Informatics University of Zagreb Pavlinska 2, 42000 Varaždin, Croatia [email protected], [email protected] Abstract . Business logic application layer accessing 1 Introduction data from any data source (databases, web services, legacy systems, flat files, ERPs, EJBs, CORBA This paper presents a pattern that help to desing the services, and so forth) uses the Dynamic Data Access data access layer for any data source (not just Object which implements the Strategy[1] design relational) such as CICS, JMS/MQ, iSeries, SAP, pattern and hides most of the complexity away from Web Services, and so forth. Dynamic Data Access an application programmer by encapsulating its Object (DDAO) is an implementation of the Strategy dynamic behavior in the base data access class. By design pattern [1] which defines a family of using the data source meta data, it automates most of algorithms, encapsulate each one, and make them the functionality it handles within the application. interchangeable through an interface. Application programmer needs only to implement Having many options available (EJB, Object specific „finder“ functions, while other functions such Relational Mapping, POJO, J2EE DAO, etc.) to use as „create, store, remove, find, removeAll, storeAll, while accessing a data source, including persistent createAll, findAll“ are implemented by the Dynamic storage, legacy data and any other data source, the Data Access Object base class for a specific data main question for development is: what to use to source type.. bridge the business logic layer and the data from a Currently there are many Object Relational data source ? Assuming that the data access code is Mapping products such as Hibernate, iBatis, EJB not coded directly into the business logic layer (Entity CMP containers, TopLink, which are used to bridge Bean, Session Bean, Servlet, JSP Helper class, POJO) objects and relational database.
  • Ioc Containers in Spring

    Ioc Containers in Spring

    301AA - Advanced Programming Lecturer: Andrea Corradini [email protected] http://pages.di.unipi.it/corradini/ AP-2018-11: Frameworks and Inversion of Control Frameworks and Inversion of Control • Recap: JavaBeans as Components • Frameworks, Component Frameworks and their features • Frameworks vs IDEs • Inversion of Control and Containers • Frameworks vs Libraries • Decoupling Components • Dependency Injection • IoC Containers in Spring 2 Components: a recap A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party. Clemens Szyperski, ECOOP 1996 • Examples: Java Beans, CLR Assemblies • Contractually specified interfaces: events, methods and properties • Explicit context dependencies: serializable, constructor with no argument • Subject to composition: connection to other beans – Using connection oriented programming (event source and listeners/delegates) 3 Towards Component Frameworks • Software Framework: A collection of common code providing generic functionality that can be selectively overridden or specialized by user code providing specific functionality • Application Framework: A software framework used to implement the standard structure of an application for a specific development environment. • Examples: – GUI Frameworks – Web Frameworks – Concurrency Frameworks 4 Examples of Frameworks Web Application Frameworks GUI Toolkits 5 Examples: General Software Frameworks – .NET – Windows platform. Provides language interoperability – Android SDK – Supports development of apps in Java (but does not use a JVM!) – Cocoa – Apple’s native OO API for macOS. Includes C standard library and the Objective-C runtime. – Eclipse – Cross-platform, easily extensible IDE with plugins 6 Examples: GUI Frameworks • Frameworks for Application with GUI – MFC - Microsoft Foundation Class Library.
  • An Experimental Study on Microservices Based Edge Computing Platforms Qian Qu, Ronghua Xu, Seyed Yahya Nikouei, Yu Chen Dept

    An Experimental Study on Microservices Based Edge Computing Platforms Qian Qu, Ronghua Xu, Seyed Yahya Nikouei, Yu Chen Dept

    1 An Experimental Study on Microservices based Edge Computing Platforms Qian Qu, Ronghua Xu, Seyed Yahya Nikouei, Yu Chen Dept. of Electrical & Computer Engineering, Binghamton University, SUNY, Binghamton, NY 13902, USA fqqu2, rxu22, snikoue1, [email protected] Abstract—The rapid technological advances in the Internet of development and easy deployment among multiple service Things (IoT) allows the blueprint of Smart Cities to become providers. feasible by integrating heterogeneous cloud/fog/edge computing Because of many attractive features, such as good scalabil- paradigms to collaboratively provide variant smart services in our cities and communities. Thanks to attractive features like fine ity, fine granularity, loose coupling, continuous development, granularity and loose coupling, the microservices architecture and low maintenance cost, the microservices architecture has has been proposed to provide scalable and extensible services in emerged and gained a lot of interests both in industry and large scale distributed IoT systems. Recent studies have evaluated academic community [17], [21]. Compared to traditional SOAs and analyzed the performance interference between microser- in which the system is a monolithic unit, the microservices vices based on scenarios on the cloud computing environment. However, they are not holistic for IoT applications given the architecture divides an monolithic application into multiple restriction of the edge device like computation consumption and atomic microservices that run independently on distributed network capacity. This paper investigates multiple microservice computing platforms. Each microservice performs one specific deployment policies on edge computing platform. The microser- sub-task or service, which requires less computation resource vices are developed as docker containers, and comprehensive ex- and reduces the communication overhead.
  • Inversion of Control in Spring – Using Annotation

    Inversion of Control in Spring – Using Annotation

    Inversion of Control in Spring – Using Annotation In this chapter, we will configure Spring beans and the Dependency Injection using annotations. Spring provides support for annotation-based container configuration. We will go through bean management using stereotypical annotations and bean scope using annotations. We will then take a look at an annotation called @Required, which allows us to specify which dependencies are actually required. We will also see annotation-based dependency injections and life cycle annotations. We will use the autowired annotation to wire up dependencies in the same way as we did using XML in the previous chapter. You will then learn how to add dependencies by type and by name. We will also use qualifier to narrow down Dependency Injections. We will also understand how to perform Java-based configuration in Spring. We will then try to listen to and publish events in Spring. We will also see how to reference beans using Spring Expression Language (SpEL), invoke methods using SpEL, and use operators with SpEL. We will then discuss regular expressions using SpEL. Spring provides text message and internationalization, which we will learn to implement in our application. Here's a list of the topics covered in this chapter: • Container configuration using annotations • Java-based configuration in Spring • Event handling in Spring • Text message and internationalization [ 1 ] Inversion of Control in Spring – Using Annotation Container configuration using annotation Container configuration using Spring XML sometimes raises the possibility of delays in application development and maintenance due to size and complexity. To solve this issue, the Spring Framework supports container configuration using annotations without the need of a separate XML definition.
  • Comparing Service- Based Architectures

    Comparing Service- Based Architectures

    Comparing Service- based Architectures @neal4d nealford.com 1 agenda Micro Service-oriented Service-based 2 Service-oriented Architecture 3 origins: hubs System B System A System C 4 origins: hubs System B System A System C System D (ftp only) 5 origins: hubs System E (http only) System B System A System C System D (ftp only) 6 origins: hubs System E (http only) System B System A System C System D (ftp only) 7 origins: hubs System E (http only) System B Integration System A Hub System C System D (ftp only) 8 origins: hubs System E (http only) System B Integration System A Hub System C System D (ftp only) 9 origins: hubs System E (http only) System B Integration System A Hub System C System D (ftp only) 10 origins: hubs looks great, but what about single point of failure and performance bottleneck considerations? 11 orchestration hub intelligent hub service oriented architecture / enterprise service bus pattern 12 service-oriented architecture abstraction service taxonomy shared resources middleware interoperability 13 service-oriented architecture business services BS BS BS BS BS BS message bus process choreographer service orchestrator enterprise services ES ES ES ES ES ES application services AS infrastructure services IS 14 service-oriented architecture business services BS BS BS BS BS BS messageabstract bus enterprise-level coarse-grained process choreographer owned and defined by business users data represented as WSDL, BPEL, XML, etc. service orchestrator no implementation - only name, input, and output enterpriseAre we services
  • Data Loader Guide

    Data Loader Guide

    Data Loader Guide Version 53.0, Winter ’22 @salesforcedocs Last updated: August 24, 2021 © Copyright 2000–2021 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of salesforce.com, inc., as are other names and marks. Other marks appearing herein may be trademarks of their respective owners. CONTENTS Chapter 1: Data Loader . 1 Chapter 2: When to Use Data Loader . 2 Chapter 3: Installing Data Loader . 3 Install Data Loader on macOS . 4 Install Data Loader on Windows . 5 Considerations for Installing Data Loader . 6 Chapter 4: Configure Data Loader . 8 Data Loader Behavior with Bulk API Enabled . 12 Configure the Data Loader to Use the Bulk API . 12 Chapter 5: Using Data Loader . 13 Data Types Supported by Data Loader . 14 Export Data . 15 Define Data Loader Field Mappings . 17 Insert, Update, or Delete Data Using Data Loader . 17 Perform Mass Updates . 18 Perform Mass Deletes . 19 Upload Attachments . 19 Upload Content with the Data Loader . 20 Review Data Loader Output Files . 21 Data Import Dates . 21 View the Data Loader Log File . 22 Configure the Data Loader Log File . 22 Chapter 6: Running in Batch Mode (Windows Only) . 23 Installed Directories and Files . 24 Encrypt from the Command Line . 24 Upgrade Your Batch Mode Interface . 25 Run Batch File With Windows Command-Line Interface . 25 Configure Batch Processes . 26 Data Loader Process Configuration Parameters . 27 Data Loader Command-Line Operations . 35 Configure Database Access . 36 Spring Framework . 37 Data Access Objects . 38 SQL Configuration . 38 Map Columns . 40 Contents Run Individual Batch Processes . 42 Chapter 7: Command-Line Quick Start (Windows Only) .
  • Experimental Algorithmics from Algorithm Desig

    Experimental Algorithmics from Algorithm Desig

    Lecture Notes in Computer Science 2547 Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 3 Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo Rudolf Fleischer Bernard Moret Erik Meineche Schmidt (Eds.) Experimental Algorithmics From Algorithm Design to Robust and Efficient Software 13 Volume Editors Rudolf Fleischer Hong Kong University of Science and Technology Department of Computer Science Clear Water Bay, Kowloon, Hong Kong E-mail: [email protected] Bernard Moret University of New Mexico, Department of Computer Science Farris Engineering Bldg, Albuquerque, NM 87131-1386, USA E-mail: [email protected] Erik Meineche Schmidt University of Aarhus, Department of Computer Science Bld. 540, Ny Munkegade, 8000 Aarhus C, Denmark E-mail: [email protected] Cataloging-in-Publication Data applied for A catalog record for this book is available from the Library of Congress. Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data is available in the Internet at <http://dnb.ddb.de> CR Subject Classification (1998): F.2.1-2, E.1, G.1-2 ISSN 0302-9743 ISBN 3-540-00346-0 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag.
  • From Zero to 1000 Tests in 6 Months

    From Zero to 1000 Tests in 6 Months

    From Zero to 1000 tests in 6 months Or how not to lose your mind with 2 week iterations Name is Max Vasilyev Senior Developer and QA Manager at Solutions Aberdeen http://tech.trailmax.info @trailmax Business Does Not Care • Business does not care about tests. • Business does not care about internal software quality. • Business does not care about architecture. • Some businesses don’t care so much, they even don’t care about money. Don’t Tell The Business Just do it! Just write your tests, ask no one. Honestly, tomorrow in the office just create new project, add NUnit package and write a test. That’ll take you 10 minutes. Simple? Writing a test is simple. Writing a good test is hard. Main questions are: – What do you test? – Why do you test? – How do you test? Our Journey: Stone Age Started with Selenium browser tests: • Recording tool is OK to get started • Boss loved it! • Things fly about on the screen - very dramatic But: • High maintenance effort • Problematic to check business logic Our Journey: Iron Age After initial Selenium fever, moved on to integration tests: • Hook database into tests and part-test database. But: • Very difficult to set up (data + infrastructure) • Problematic to test logic Our Journey: Our Days • Now no Selenium tests • A handful of integration tests • Most of the tests are unit-ish* tests • 150K lines of code in the project • Around 1200 tests with 30% coverage** • Tests are run in build server * Discuss Unit vs Non-Unit tests later ** Roughly 1 line of test code covers 2 lines of production code Testing Triangle GUI Tests GUI Tests Integration Tests Integration Tests Unit Tests Unit Tests Our Journey: 2 Week Iterations? The team realised tests are not optional after first 2-week iteration: • There simply was no time to manually test everything at the end of iteration.