├── CITATION.cff ├── CODE_OF_CONDUCT.md ├── README.md └── doc ├── algorithms.md ├── data_structures.md ├── interfaces_protocols_traits_mixins_abstract_classes.md ├── raw_and_cooked.md ├── software_concepts.md ├── software_design_patterns.md ├── software_testing.md ├── technical_debt_causes.md └── variable_shadowing.md /CITATION.cff: -------------------------------------------------------------------------------- 1 | cff-version: 1.2.0 2 | title: Awesome developing 3 | message: >- 4 | If you use this work and you want to cite it, 5 | then you can use the metadata from this file. 6 | type: software 7 | authors: 8 | - given-names: Joel Parker 9 | family-names: Henderson 10 | email: joel@joelparkerhenderson.com 11 | affiliation: joelparkerhenderson.com 12 | orcid: 'https://orcid.org/0009-0000-4681-282X' 13 | identifiers: 14 | - type: url 15 | value: 'https://github.com/joelparkerhenderson/awesome-developing/' 16 | description: Awesome developing 17 | repository-code: 'https://github.com/joelparkerhenderson/awesome-developing/' 18 | abstract: >- 19 | Awesome developing 20 | license: See license file 21 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | 2 | # Contributor Covenant Code of Conduct 3 | 4 | ## Our Pledge 5 | 6 | We as members, contributors, and leaders pledge to make participation in our 7 | community a harassment-free experience for everyone, regardless of age, body 8 | size, visible or invisible disability, ethnicity, sex characteristics, gender 9 | identity and expression, level of experience, education, socio-economic status, 10 | nationality, personal appearance, race, caste, color, religion, or sexual 11 | identity and orientation. 12 | 13 | We pledge to act and interact in ways that contribute to an open, welcoming, 14 | diverse, inclusive, and healthy community. 15 | 16 | ## Our Standards 17 | 18 | Examples of behavior that contributes to a positive environment for our 19 | community include: 20 | 21 | * Demonstrating empathy and kindness toward other people 22 | * Being respectful of differing opinions, viewpoints, and experiences 23 | * Giving and gracefully accepting constructive feedback 24 | * Accepting responsibility and apologizing to those affected by our mistakes, 25 | and learning from the experience 26 | * Focusing on what is best not just for us as individuals, but for the overall 27 | community 28 | 29 | Examples of unacceptable behavior include: 30 | 31 | * The use of sexualized language or imagery, and sexual attention or advances of 32 | any kind 33 | * Trolling, insulting or derogatory comments, and personal or political attacks 34 | * Public or private harassment 35 | * Publishing others' private information, such as a physical or email address, 36 | without their explicit permission 37 | * Other conduct which could reasonably be considered inappropriate in a 38 | professional setting 39 | 40 | ## Enforcement Responsibilities 41 | 42 | Community leaders are responsible for clarifying and enforcing our standards of 43 | acceptable behavior and will take appropriate and fair corrective action in 44 | response to any behavior that they deem inappropriate, threatening, offensive, 45 | or harmful. 46 | 47 | Community leaders have the right and responsibility to remove, edit, or reject 48 | comments, commits, code, wiki edits, issues, and other contributions that are 49 | not aligned to this Code of Conduct, and will communicate reasons for moderation 50 | decisions when appropriate. 51 | 52 | ## Scope 53 | 54 | This Code of Conduct applies within all community spaces, and also applies when 55 | an individual is officially representing the community in public spaces. 56 | Examples of representing our community include using an official e-mail address, 57 | posting via an official social media account, or acting as an appointed 58 | representative at an online or offline event. 59 | 60 | ## Enforcement 61 | 62 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 63 | reported to the community leaders responsible for enforcement at 64 | [INSERT CONTACT METHOD]. 65 | All complaints will be reviewed and investigated promptly and fairly. 66 | 67 | All community leaders are obligated to respect the privacy and security of the 68 | reporter of any incident. 69 | 70 | ## Enforcement Guidelines 71 | 72 | Community leaders will follow these Community Impact Guidelines in determining 73 | the consequences for any action they deem in violation of this Code of Conduct: 74 | 75 | ### 1. Correction 76 | 77 | **Community Impact**: Use of inappropriate language or other behavior deemed 78 | unprofessional or unwelcome in the community. 79 | 80 | **Consequence**: A private, written warning from community leaders, providing 81 | clarity around the nature of the violation and an explanation of why the 82 | behavior was inappropriate. A public apology may be requested. 83 | 84 | ### 2. Warning 85 | 86 | **Community Impact**: A violation through a single incident or series of 87 | actions. 88 | 89 | **Consequence**: A warning with consequences for continued behavior. No 90 | interaction with the people involved, including unsolicited interaction with 91 | those enforcing the Code of Conduct, for a specified period of time. This 92 | includes avoiding interactions in community spaces as well as external channels 93 | like social media. Violating these terms may lead to a temporary or permanent 94 | ban. 95 | 96 | ### 3. Temporary Ban 97 | 98 | **Community Impact**: A serious violation of community standards, including 99 | sustained inappropriate behavior. 100 | 101 | **Consequence**: A temporary ban from any sort of interaction or public 102 | communication with the community for a specified period of time. No public or 103 | private interaction with the people involved, including unsolicited interaction 104 | with those enforcing the Code of Conduct, is allowed during this period. 105 | Violating these terms may lead to a permanent ban. 106 | 107 | ### 4. Permanent Ban 108 | 109 | **Community Impact**: Demonstrating a pattern of violation of community 110 | standards, including sustained inappropriate behavior, harassment of an 111 | individual, or aggression toward or disparagement of classes of individuals. 112 | 113 | **Consequence**: A permanent ban from any sort of public interaction within the 114 | community. 115 | 116 | ## Attribution 117 | 118 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 119 | version 2.1, available at 120 | [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. 121 | 122 | Community Impact Guidelines were inspired by 123 | [Mozilla's code of conduct enforcement ladder][Mozilla CoC]. 124 | 125 | For answers to common questions about this code of conduct, see the FAQ at 126 | [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at 127 | [https://www.contributor-covenant.org/translations][translations]. 128 | 129 | [homepage]: https://www.contributor-covenant.org 130 | [v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html 131 | [Mozilla CoC]: https://github.com/mozilla/diversity 132 | [FAQ]: https://www.contributor-covenant.org/faq 133 | [translations]: https://www.contributor-covenant.org/translations 134 | 135 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Awesome developing 2 | 3 | Ideas for developing software and systems. Work in progress. 4 | 5 | 6 | ## Introduction 7 | 8 | Developing software and systems can be complex. There are many ideas and resources that can help practitioners, and one of the best ideas we use is to share information. 9 | 10 | This document is our notes and work in progress about ideas and resources that are helping us build better software, and better teams, and better results. 11 | 12 | 13 | ## Preferences 14 | 15 | Preferences for working: 16 | 17 | * action > indecision 18 | * written > verbal 19 | * experiment > intuition 20 | * testing > guessing 21 | * empowering > commanding 22 | * commitment > consensus 23 | 24 | Preferences for implementation: 25 | 26 | * code > documentation 27 | * asynchronous > blocking 28 | * functional > stateful 29 | * composition > inheritance 30 | * distributed > centralized 31 | * messaging > procedural 32 | 33 | 34 | ## Developing the right things the right ways 35 | 36 | How can we know if we're developing the right things? We ask questions and we communiate with everyone involved. 37 | 38 | Developing with purpose: 39 | 40 | * [Strategic Balanced Scorecard (SBS)](https://github.com/joelparkerhenderson/strategic_balanced_scorecard) 41 | * [Objectives and key results (OKR)](https://github.com/joelparkerhenderson/objectives_and_key_results) 42 | * [Key performance indicator (KPI)](https://github.com/joelparkerhenderson/key_performance_indicator) 43 | * [Value Stream Mapping (VSM)](https://github.com/joelparkerhenderson/value_stream_mapping) 44 | 45 | Developing with teams: 46 | 47 | * [Ground rules](https://github.com/joelparkerhenderson/ground_rules) 48 | * [Crucial conversations](https://github.com/joelparkerhenderson/crucial_conversations) 49 | * [TEAM FOCUS](https://github.com/joelparkerhenderson/team_focus) 50 | * [Milestones ideas & examples](https://github.com/joelparkerhenderson/milestones) 51 | * [Feedback request template](https://github.com/joelparkerhenderson/feedback_request_template) 52 | * [Social Value Orientation (SVO)](https://github.com/joelparkerhenderson/social_value_orientation) 53 | * [Wordbooks & glossaries](https://github.com/joelparkerhenderson/wordbooks) 54 | 55 | Developing with planners: 56 | 57 | * [Stakeholder analysis](https://github.com/joelparkerhenderson/stakeholder_analysis) 58 | * [Responsibility assignment matrix (RAM)](https://github.com/joelparkerhenderson/responsibility_assignment_matrix) 59 | * [SMART criteria for goals](https://github.com/joelparkerhenderson/smart_criteria) 60 | * [ADKAR change manangement model](https://github.com/joelparkerhenderson/adkar_change_management_model) 61 | 62 | Developing with project managers: 63 | 64 | * [Project management checklist](https://github.com/sixarm/sixarm_project_management_checklist) 65 | * [Project management priority score](https://github.com/sixarm/sixarm_project_management_priority_score) 66 | * [Project management ROPE estimate](https://github.com/sixarm/sixarm_project_management_rope_estimate) 67 | 68 | Developing with specifications: 69 | 70 | * [Statement of Work (SOW)](https://github.com/joelparkerhenderson/statement_of_work) 71 | * [Functional specs template](https://github.com/joelparkerhenderson/functional_specifications_template) 72 | * [Functional specs tutorial](https://github.com/joelparkerhenderson/functional_specifications_tutorial) 73 | 74 | Developing with assessments: 75 | 76 | * [Agile assessment](https://github.com/joelparkerhenderson/agile_assessment) 77 | * [Discovery assessment](https://github.com/joelparkerhenderson/discovery_assessment) 78 | * [Maturity Models (MM)](https://github.com/joelparkerhenderson/maturity_models) 79 | 80 | Developing with startups: 81 | 82 | * [Pitch deck](https://github.com/joelparkerhenderson/pitch_deck) 83 | * [Company culture](https://github.com/joelparkerhenderson/company_culture) 84 | * [Vision statements](https://github.com/joelparkerhenderson/vision_statements) 85 | * [Oblique strategies](https://github.com/joelparkerhenderson/oblique_strategies) 86 | 87 | Developing with legal agreements: 88 | 89 | * [Consulting agreement](https://github.com/sixarm/sixarm_company_consulting_agreement) 90 | * [Confidentiality agreement](https://github.com/sixarm/sixarm_company_confidentiality_agreement) 91 | 92 | Developing with engineers: 93 | 94 | * [Architecture Decision Record (ADR)](https://github.com/joelparkerhenderson/architecture_decision_record) 95 | * [System quality attributes (SQA)](https://github.com/joelparkerhenderson/system_quality_attributes) 96 | * [Coordinated disclosure](https://github.com/joelparkerhenderson/coordinated_disclosure) 97 | * [Versioning](https://github.com/joelparkerhenderson/versioning) 98 | 99 | Devloping with git: 100 | 101 | * [Git commit message](https://github.com/joelparkerhenderson/git_commit_message) 102 | * [Git commit template](https://github.com/joelparkerhenderson/git_commit_template) 103 | * [Git flow help](https://github.com/joelparkerhenderson/git_flow_help) 104 | * [GitHub special files and paths](https://github.com/joelparkerhenderson/github_special_files_and_paths) 105 | 106 | 107 | ## Computer science concepts 108 | 109 | * [algorithms](doc/algorithms.md) 110 | * [data structures](doc/data_structures.md) 111 | * [software concepts](doc/software_concepts.md) 112 | * [software design patterns](doc/software_design_patterns.md) 113 | * [software testing](software_testing.md) 114 | * [technical debt causes](technical_debt_causes.md) 115 | 116 | 117 | ## Awesome lists 118 | 119 | * [Awesome lists, curated](https://github.com/sindresorhus/awesome) 120 | * [Awesome programming](https://github.com/hardikvasa/awesome-programming) 121 | 122 | 123 | ## To do - Ways of Working 124 | 125 | * [Amazon Leadership Principles](https://www.amazon.jobs/principles) e.g. always day 1, bias for action, customer first, disagree and commit. 126 | * [Agile manifesto](http://agilemanifesto.org/) 127 | * Google idea: "All hands welcome on all code" 128 | * 5 Whys 129 | * no broken windows. 130 | * Lean 131 | * BDD + TDD 132 | * CI + CD 133 | * DevOps 134 | * IaC 135 | 136 | Thought leaders: 137 | 138 | * [ThoughtWorks.com](https://thoughtworks.com/) 139 | * [SVGP](https://svpg.com/) 140 | 141 | 142 | ## Books by Pragmatic Programming 143 | 144 | These books are for general developing. For specific languages, tools, etc. see https://pragprog.com/ 145 | 146 | * [101 Design Ingredients to Solve Big Tech Problems](https://pragprog.com/book/ec101di/101-design-ingredients-to-solve-big-tech-problems) 147 | * [A Common-Sense Guide to Data Structures and Algorithms](https://pragprog.com/book/jwdsal/a-common-sense-guide-to-data-structures-and-algorithms) 148 | * [Agile and Lean Program Management](https://pragprog.com/book/d-jrlean/agile-and-lean-program-management) 149 | * [Agile Retrospectives: Making Good Teams Great](https://pragprog.com/book/dlret/agile-retrospectives) 150 | * [Design It! From Programmer to Software Architect](https://pragprog.com/book/mkdsa/design-it) 151 | * [Debug It! Find, Repair, and Prevent Bugs in Your Code](https://pragprog.com/book/pbdp/debug-it) 152 | * [Domain Modeling Made Functional](https://pragprog.com/book/swdddf/domain-modeling-made-functional) 153 | * [Behind Closed Doors: Secrets of Great Management](https://pragprog.com/book/rdbcd/behind-closed-doors) 154 | * [Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver](https://pragprog.com/book/jragm/create-your-successful-agile-project) 155 | * [Creating Great Teams: How Self-Selection Lets People Excel](https://pragprog.com/book/mmteams/creating-great-teams) 156 | * [Designed for Use: Create Usable Interfaces for Applications and the Web](https://pragprog.com/book/lmuse2/designed-for-use-second-edition) 157 | * [DevOps in Practice](https://pragprog.com/book/d-devops/devops-in-practice) 158 | * [Driving Technical Change: Why People on Your Team Don't Act on Good Ideas, and How to Convince Them They Should](https://pragprog.com/book/trevan/driving-technical-change) 159 | * [Explore It! Reduce Risk and Increase Confidence with Exploratory Testing](https://pragprog.com/book/ehxta/explore-it) 160 | * [Liftoff: Start and Sustain Successful Agile Teams](https://pragprog.com/book/liftoff/liftoff-second-edition) 161 | * [Manage It! Your Guide to Modern Pragmatic Project Management](https://pragprog.com/book/jrpm/manage-it) 162 | * [New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup](https://pragprog.com/book/jcdeg/new-programmer-s-survival-manual) 163 | * [Outsource It! A No-Holds-Barred Look at the Good, the Bad, and the Ugly of Offshoring Tech Projects](https://pragprog.com/book/nkout/outsource-it) 164 | * [Practices of an Agile Developer](https://pragprog.com/book/pad/practices-of-an-agile-developer) 165 | * [Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost](https://pragprog.com/book/d-jrpredict/predicting-the-unpredictable) 166 | * [Real-World Kanban: Do Less, Accomplish More with Lean Thinking](https://pragprog.com/book/mskanban/real-world-kanban) 167 | * [Release It! Design and Deploy Production-Ready Software](https://pragprog.com/book/mnee2/release-it-second-edition) 168 | * [Remote Pairing: Collaborative Tools for Distributed Development](https://pragprog.com/book/jkrp/remote-pairing) 169 | * [Ship It! Practical Guide to Successful Software Projects](https://pragprog.com/book/prj/ship-it) 170 | * [Small, Sharp, Software Tools: Harness the Combinatoric Power of Command-Line Tools and Utilities](https://pragprog.com/book/bhcldev/small-sharp-software-tools) 171 | * [Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis](https://pragprog.com/book/atevol/software-design-x-rays) 172 | * [The Agile Samurai: How Agile Masters Deliver Great Software](https://pragprog.com/book/jtrap/the-agile-samurai) 173 | * [The Developer's Code: What Real Programmers Do](https://pragprog.com/book/kcdc/the-developer-s-code) 174 | * [The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece](https://pragprog.com/book/rjnsd/the-nature-of-software-development) 175 | * [Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design](https://pragprog.com/book/atcrime/your-code-as-a-crime-scene) 176 | -------------------------------------------------------------------------------- /doc/algorithms.md: -------------------------------------------------------------------------------- 1 | # Algorithms wordbook 2 | 3 | * [List of algorithms](https://en.wikipedia.org/wiki/List_of_algorithms) 4 | * [Bcrypt: secure password key derivation function](https://wikipedia.org/wiki/Bcrypt) (cf. Scrypt) 5 | * [MD5: Message Digest Algorithm](https://wikipedia.org/wiki/Md5) (cf. SHA) 6 | * [SHA: Secure Hash Algorithm](https://wikipedia.org/wiki/Secure_Hash_Algorithm) (cf. MD5) (related: SHA1, SHA2, SHA512, etc.) 7 | * [Scrypt: secure password key derivation function](https://wikipedia.org/wiki/Scrypt) (cf. Bcrypt) 8 | * [Vector clock: for ordering events in a distributed systems](https://en.wikipedia.org/wiki/Vector_clock) 9 | -------------------------------------------------------------------------------- /doc/data_structures.md: -------------------------------------------------------------------------------- 1 | # Data structures wordbook 2 | 3 | * [Array](https://wikipedia.org/wiki/array) 4 | * [B-tree](https://wikipedia.org/wiki/b-tree) 5 | * [Bag](https://wikipedia.org/wiki/bag) 6 | * [Hash](https://wikipedia.org/wiki/hash) 7 | * [Hash tree a.k.a. Merkle tree](https://wikipedia.org/wiki/merkle_tree) 8 | * [Heap](https://wikipedia.org/wiki/heap) 9 | * [List](https://wikipedia.org/wiki/list) 10 | * [Map](https://wikipedia.org/wiki/bag) 11 | * [Matrix](https://wikipedia.org/wiki/matrix) 12 | * [Set](https://wikipedia.org/wiki/set) 13 | * [Sorted Set](https://wikipedia.org/wiki/sorted_set) 14 | * [Stack](https://wikipedia.org/wiki/stack) 15 | * [Queue](https://wikipedia.org/wiki/queue) 16 | * [Vector](https://wikipedia.org/wiki/vector) 17 | 18 | 19 | -------------------------------------------------------------------------------- /doc/interfaces_protocols_traits_mixins_abstract_classes.md: -------------------------------------------------------------------------------- 1 | # Interfaces, protocols, traits, mixins, abstract classes 2 | 3 | There are many ways to combine software code. This page explains a bit about 4 | common patterns for combining code: interfaces, protocols, traits, mixins, abstract classes. 5 | 6 | These languages all use similar techniques that have different names: 7 | 8 | * Java interface 9 | * Swift protocol 10 | * Rust trait 11 | * Ruby mixin 12 | * C++ abstract class 13 | 14 | These concepts are ways to do more-abstract composition instead of more-concrete inheritance. 15 | 16 | These concepts may also be known as abilities, behaviors, capabilities, qualities, etc. 17 | 18 | These concepts encourage code reuse, and tend to improve testability, maintainability, and even security. 19 | 20 | These concepts are examples of the dependency inversion principle: 21 | 22 | * High-level modules should not depend on low-level modules. 23 | 24 | * Both should depend on abstractions. 25 | 26 | * Abstractions should not depend on details. 27 | 28 | How other classes gain access to the techniques depends on the particular language. 29 | 30 | 31 | ## Interface 32 | 33 | An interface is a description of a code's capabilties and/or how to interact with the code. 34 | 35 | * An interface provides definitions of functionality, such as functions, methods, messages, exceptions, etc. 36 | 37 | * The interface is an agreement of what the object understands and how to interact with it. 38 | 39 | * An interface is useful because it enables unrelated objects to communicate and/or co-operate. 40 | 41 | * A class that has code and data for all the methods corresponding to an interface, and declaring so, is said to "implement" the interface. 42 | 43 | * A class can implement multiple interfaces, and hence can be of different types at the same time. 44 | 45 | * An interface a kind of type definition; anywhere an object can be exchanged (for example, in a function call or method call), the type of the object to be exchanged can be defined in terms of one of its implemented interfaces, rather than specifying a specific class. This approach means that any class that implements that interface can be used. 46 | 47 | * An interface can contain any number of methods. For example, the Java language defines the interface "Readable" that has the single read() method; various implementations are used for different purposes, including FileReader, PipedReader, and StringReader. 48 | 49 | * An interface can contain no methods. For example, the Java language define the interface "Serializable" that contains no methods and serves to provide run-time information to generic processing using reflection. 50 | 51 | * An interface can be valuable for testing. For example, a dummy implementation may be used to allow development to progress before the final implementation is available. In another case, a fake or mock implementation may be substituted during testing. Such stub implementations are replaced by real code later in the development process. 52 | 53 | * An interface can be valuable for trying multiple implementation strategies. For example, an interface can be implemented by writing typical code, and then implented again by writing very fast optimized code. 54 | 55 | 56 | ## Protocol 57 | 58 | An object-oriented protocol is like an interface. 59 | 60 | The first difference is that typically a protocol may have some method implementations, such as default code. 61 | 62 | The second difference is that Apple favors the name "protocol" instead of "interface", which means that many iOS developers use the name "protocol". 63 | 64 | An object-oriented protocol is totally different in meaning than a transmission protocol (such as SSH, FTP, HTTP). 65 | 66 | 67 | ## Trait 68 | 69 | A trait is like a interface and a protocol. 70 | 71 | The most important difference is that a trait provides all the method implementations a.k.a. the method bodies. 72 | 73 | Traits also have useful properties in some languages: 74 | 75 | * symmetric sum: an operation that merges two disjoint traits to create a new trait 76 | 77 | * override (or asymmetric sum): an operation that forms a new trait by adding methods to an existing trait, possibly overriding some of its methods. 78 | 79 | * alias: an operation that creates a new trait by adding a new name for an existing method. 80 | 81 | * exclusion: an operation that forms a new trait by removing a method from an existing trait. (Combining this with the alias operation yields a shallow rename operation). 82 | 83 | Traits can be composed in the following ways in some languages: 84 | 85 | * Trait composition is commutative; the ordering of adding traits does not matter. For example, given trait S = A + B, then trait T = B + A is the same as S. 86 | 87 | * Conflicting methods are excluded from the composition. 88 | 89 | * Nested traits are equivalent to flattened traits; the composition hierarchy does not affect the traits behaviour. For example, given trait S = A + X, where X = B + C, then trait T = A + B + C is the same as S.[1] 90 | 91 | Some languages and compilers (e.g. Rust) require traits to be explicated, which ensures the safety of generics in the language, and also helps to avoid major problems of templates (e.g. in C++). 92 | 93 | 94 | ## Mixin 95 | 96 | A mixin is like an interface, protocol, and trait. 97 | 98 | A mixin defines behaviors via full method definitions, same as a traits, and may also carry state through member variables, whereas traits usually don't. 99 | 100 | A mixin can also be understood as an interface plus its implemented methods, and plus any member variables. 101 | 102 | Mixins are useful when a programmer wants to share functionality between different classes. Instead of repeating the same code over and over again, the common functionality can simply be grouped into a mixin, then included into each class that requires it. 103 | 104 | 105 | ## Abstract class 106 | 107 | An abstract class is, conceptually, a class that cannot be instantiated, and is usually implemented as a class that has one or more abstract functions a.k.a. pure virtual functions. 108 | 109 | An abstract function, a.k.a. pure virtual function, is one which must be overridden by any concrete (i.e., non-abstract) derived class. In C++, this is indicated in the declaration with the syntax " = 0" in the member function's declaration. 110 | 111 | 112 | ## Summary 113 | 114 | Comparison: 115 | 116 | * An interface defines behaviors via method signatures (a.k.a. method headers) and never includes method implementations (a.k.a. the method bodies). 117 | 118 | * An protocol defines behaviors via method signatures (a.k.a. method headers), same as an interface, and may also provide one or more method implementations (a.k.a. the method bodies). 119 | 120 | * A trait defines behaviors via full method definitions, i.e. the trait provides all the method implementations a.k.a. the method bodies. A trait can express that it requires specific properties or methods for functioning. Traits can create new objects from scratch by composing many together, instead of extending existing objects or classes. 121 | 122 | * A mixin defines behaviors via full method definitions, same as a traits, and may also carry state through member variables, whereas traits usually don't. A mixin does not express that it requires specific properties or methods for functioning. Mixins usually extend existing objects or classes, and do not usually create new objects from scratch. 123 | 124 | * An abstract class defines behaviors via method signatures (e.g. pure virtual functions) and can also include method implementations, member variables, helper methods, and more. An abstract class is usable solely by its subclasses, which is unlike interaces, protocols, traits, and mixins. 125 | 126 | Similarities: 127 | 128 | * Interfaces, protocols, traits, and mixins are sometimes described as being "included" or "composed", rather than "inherited" or "subclassed". 129 | 130 | * These avoid the inheritance ambiguity that multiple inheritance can cause, which is known as the "diamond problem". 131 | 132 | * These all help with code sharing. 133 | 134 | 135 | ## See also 136 | 137 | https://en.wikipedia.org/wiki/Protocol_(object-oriented_programming) 138 | 139 | https://en.wikipedia.org/wiki/Traits_(computer_science) 140 | 141 | https://en.wikipedia.org/wiki/Mixin 142 | 143 | https://javascript.info/mixins 144 | -------------------------------------------------------------------------------- /doc/raw_and_cooked.md: -------------------------------------------------------------------------------- 1 | # Raw and cooked 2 | 3 | Raw data is original data, such as directly from a source. 4 | 5 | Cooked data is raw data after it has been processed - that is, extracted, organized, and perhaps analyzed and presented - for further use. 6 | 7 | ## Raw literals and cooked literals 8 | 9 | A raw literal receives input from the application source and doesn’t interpret it in any way. 10 | 11 | A cooked literal interprets input and performs any required conversions to make the data usable to the recipient. 12 | -------------------------------------------------------------------------------- /doc/software_concepts.md: -------------------------------------------------------------------------------- 1 | # Software wordbook 2 | 3 | Contents: 4 | 5 | * [Overviews](#overviews) 6 | * [Challenges](#challenges) 7 | * [Formats](#formats) 8 | * [Lists](#lists) 9 | * [Programming languages](#programming-languages) 10 | * [Protocols](#protocols) 11 | * [RFCs](#rfcs) 12 | * [Software development philosophies](#software-development-philosophies) 13 | * [Standards](#standards) 14 | * [Terminology](#technology-terminology) 15 | * [Web frameworks](#web-frameworks) 16 | 17 | 18 | ## Overviews 19 | 20 | * [Outline of software development](https://en.wikipedia.org/wiki/Outline_of_software_development) 21 | 22 | * [Outline of software engineering](https://en.wikipedia.org/wiki/Outline_of_software_engineering) 23 | 24 | 25 | ## Challenges 26 | 27 | * [longest path problem](https://en.wikipedia.org/wiki/Longest_path_problem) 28 | 29 | 30 | ## Formats 31 | 32 | * [CSV: comma separated values](https://wikipedia.org/wiki/Comma-separated_values) (cf. TDF, TSV) 33 | * [PDF: portable document format](TODO) 34 | * [HTML: hyper text markup language](https://wikipedia.org/wiki/HTML) 35 | * [JPEG](TODO): image format. 36 | * [JSON: JavaScript object notation](https://wikipedia.org/wiki/JSON) (cf. XML) 37 | * [PNG](TODO): image format. 38 | * [RDF: resource description framework](https://wikipedia.org/wiki/Resource_Description_Framework) 39 | * [TDF: tab delimited files](https://wikipedia.org/wiki/Delimiter-separated_values) (cf. CSV, TSV) 40 | * [TIFF](TODO): image format. 41 | * [TSV: tab separated values](https://wikipedia.org/wiki/Tab-separated_values) (cf. CSV, TDF) 42 | * [UML: Unified Modeling Lanuage](TODO) 43 | * [XML: extensible markup language](https://wikipedia.org/wiki/Xml) (cf. JSON: JavaScript Object Notation) 44 | 45 | 46 | ## Programming languages 47 | 48 | * [Bash](https://wikipedia.org/wiki/Bash_(Unix_shell)) 49 | * [C](https://wikipedia.org/wiki/C_(programming_language)), [C++](https://wikipedia.org/wiki/C%252B%252B), [C#](https://wikipedia.org/wiki/C_Sharp_(programming_language)), [Objective-C](https://en.wikipedia.org/wiki/Objective-C) 50 | * [Go](https://wikipedia.org/wiki/Go_(programming_language)) 51 | * [Elixir](https://wikipedia.org/wiki/Elixir_(programming_language)) 52 | * [Erlang](https://wikipedia.org/wiki/Erlang_(programming_language)) 53 | * [Haskell](https://wikipedia.org/wiki/Haskell_(programming_language)) 54 | * [Java](https://wikipedia.org/wiki/Java_(programming_language)) 55 | * [Perl](https://wikipedia.org/wiki/Perl_(programming_language)) 56 | * [Python](https://wikipedia.org/wiki/Python_(programming_language)) 57 | * [PHP](https://wikipedia.org/wiki/Php) 58 | * [Rust](https://wikipedia.org/wiki/Rust_(programming_language)) 59 | * [Scala](https://wikipedia.org/wiki/Scala_(programming_language)) 60 | 61 | 62 | ## Protocols 63 | 64 | * [FTP: File Transfer Protocol](https://wikipedia.org/wiki/File_Transfer_Protocol) 65 | * [HTTP: Hyper-Text Tranfer Protocol](https://wikipedia.org/wiki/Hypertext_Transfer_Protocol) 66 | * [LDAP: Lightweight Directory Access Protocol](https://wikipedia.org/wiki/Ldap) 67 | * [SMTP: Simple Mail Transfer Protocol](https://wikipedia.org/wiki/Smtp) 68 | * [SOAP: Simple Object Access Protocol](https://wikipedia.org/wiki/SOAP) (cf. REST) 69 | * [STOMP: Streaming Text Oriented Messaging Protocol](https://wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol) 70 | 71 | 72 | ## Standards 73 | 74 | * [ISAE 3402: Assurance Reports on Controls at a Service Organization](https://en.wikipedia.org/wiki/ISAE_3402) 75 | * [ISO/IEC_42010- Systems and software engineering — Architecture description](https://wikipedia.org/wiki/ISO/IEC_42010) 76 | * [SAS 70: Statement on Auditing Standards No. 70: Service Organizations](https://en.wikipedia.org/wiki/Statement_on_Auditing_Standards_No._70:_Service_Organizations) 77 | * [SSAE 16: Statement on Standards for Attestation Engagements 16](https://en.wikipedia.org/wiki/SSAE_16) 78 | 79 | 80 | ## Software development philosophies 81 | 82 | * [List of software development philosophies](https://wikipedia.org/wiki/List_of_software_development_philosophies) 83 | * [agile modeling](https://wikipedia.org/wiki/List_of_software_development_philosophies) 84 | * [agile software development](https://en.wikipedia.org/wiki/Agile_software_development) 85 | * [agile unified process (AUP)](https://wikipedia.org/wiki/Agile_Unified_Process) 86 | * [aspect-oriented programming (AOP)](https://en.wikipedia.org/wiki/Aspect-oriented_programming) 87 | * [BDUF: big design pp Front](https://wikipedia.org/wiki/Big_Design_Up_Front) (cf. waterfall) 88 | * [CD: continuous delivery](TODO) (cf. Kaizen) 89 | * [CI: continuous improvement](TODO) (cf. Kaizen) 90 | * [CI: continuous integration](https://wikipedia.org/wiki/Continuous_integration) (cf. CD) 91 | * [Continuous Obsolescence](https://wikipedia.org/wiki/Continuous_obsolescence) 92 | * [domain-specific language](https://en.wikipedia.org/wiki/Domain-specific_language) 93 | * [domain-specific modeling](https://en.wikipedia.org/wiki/Domain-specific_modeling) 94 | * [EBO: enterprise business object](TODO) 95 | * [emergent design](https://en.wikipedia.org/wiki/Emergent_Design) 96 | * [extreme programming (XP)](https://wikipedia.org/wiki/Extreme_Programming) 97 | * [extreme programming practices (XPP)](https://wikipedia.org/wiki/Extreme_programming_practices) 98 | * [functional programming](https://en.wikipedia.org/wiki/Functional_programming) 99 | * [graphical system design](https://wikipedia.org/wiki/Graphical_system_design) 100 | * [hypothesis driven development](TODO) 101 | * [kaizen (Japanese for "good change")](https://wikipedia.org/wiki/Kaizen) 102 | * [kanban lean manufacturing process](https://wikipedia.org/wiki/Kanban) 103 | * [kanban (software development) process management and improvement method](https://wikipedia.org/wiki/Kanban_(development)) 104 | * [lean software development (LSD)](https://wikipedia.org/wiki/Lean_software_development) 105 | * [method stub](https://en.wikipedia.org/wiki/Method_stub) 106 | * [mock object](https://en.wikipedia.org/wiki/Mock_object) 107 | * [model-driven architecture](https://en.wikipedia.org/wiki/Model-driven_architecture) 108 | * [model-driven engineering](https://en.wikipedia.org/wiki/Model-driven_engineering) 109 | * [object-oriented programming (OOP)](https://en.wikipedia.org/wiki/Object-oriented_programming) 110 | * [object-oriended analysis and design](https://en.wikipedia.org/wiki/Object-oriented_analysis_and_design) 111 | * [OOP: object-oriented programming](https://en.wikipedia.org/wiki/Object-oriented_programming) 112 | * [pair programming](https://wikipedia.org/wiki/Pair_programming) 113 | * [procedural programming](https://en.wikipedia.org/wiki/Procedural_programming) 114 | * [programming paradigm](https://en.wikipedia.org/wiki/Programming_paradigm) 115 | * [scrum (software development](https://wikipedia.org/wiki/Lean_software_development) 116 | * [SemVer: semantic versioning specification](http://semver.org/) 117 | * [software engineering](https://wikipedia.org/wiki/Software_engineering) 118 | * [software versioning](https://en.wikipedia.org/wiki/Software_versioning) 119 | * [src: source] 120 | * [story-driven modeling](https://wikipedia.org/wiki/Story-driven_modeling) 121 | * [thin slice](TODO) (see Agile) 122 | * [waterfall model](https://wikipedia.org/wiki/Waterfall_model) 123 | * [velocity (software development)](https://wikipedia.org/wiki/Velocity_tracking) 124 | 125 | 126 | ## RFCs 127 | 128 | * [List of RFCs](https://en.wikipedia.org/wiki/List_of_RFCs) 129 | * [RFC 3696: Application Techniques for Checking and Transformation of Names](https://tools.ietf.org/html/rfc3696) 130 | * [RCF 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)](https://tools.ietf.org/html/rfc7540) 131 | * [RFC 6749: The OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749) 132 | 133 | 134 | ## Terminology 135 | 136 | * [ABAC: Attribute-Based Access Control](https://wikipedia.org/wiki/Abac) 137 | * [ADC: application delivery controller](https://en.wikipedia.org/wiki/Application_delivery_controller) 138 | * [ADN: application delivery network](https://en.wikipedia.org/wiki/Application_delivery_network) 139 | * [AJAX: Asynchronous JavaScript and XML](https://wikipedia.org/wiki/Ajax_(programming)) 140 | * [AKM: Architectural Knowledge Management](TODO) 141 | * [Algorithm](https://en.wikipedia.org/wiki/Algorithm) 142 | * [AMI: asynchronous method invocation](https://wikipedia.org/wiki/Asynchronous_method_invocation) 143 | * [AMQP: Advanced Message Queuing Protocol](https://wikipedia.org/wiki/Advanced_Message_Queuing_Protocol) 144 | * [AMQP: Advanced Message Queuing Protocol](https://wikipedia.org/wiki/Advanced_Message_Queuing_Protocol): an application layer protocol for message-oriented middleware. 145 | * [anti-pattern](https://wikipedia.org/wiki/Anti-pattern) 146 | * [API: application programming interface](https://wikipedia.org/wiki/Application_programming_interfaces) 147 | * [APM: application performance management](https://en.wikipedia.org/wiki/Application_performance_management) 148 | * [application delivery controller (ADC)](https://en.wikipedia.org/wiki/Application_delivery_controller) 149 | * [application delivery network (ADN)](https://en.wikipedia.org/wiki/Application_delivery_network) 150 | * [application firewall](https://en.wikipedia.org/wiki/Application_firewall) 151 | * [application performance management (APM)](https://en.wikipedia.org/wiki/Application_performance_management) 152 | * [Architectural Knowledge Management (AKM)](TODO) 153 | * [assertion](https://en.wikipedia.org/wiki/Assertion_(software_development)) 154 | * [AST: abstract syntax tree](TODO) 155 | * [authentication](https://wikipedia.org/wiki/Authentication) 156 | * [authorziation](https://wikipedia.org/wiki/Authorization) 157 | * [availability (A)](https://en.wikipedia.org/wiki/Availability): every system request receives a meaningful response 158 | * [B2B: Business to Business](TODO) 159 | * [B2C: Business to Consumer](TODO) 160 | * [bandwidth](https://en.wikipedia.org/wiki/Bandwidth_(computing)) 161 | * [bandwidth throttling](https://en.wikipedia.org/wiki/Bandwidth_throttling) 162 | * [benchmarking](https://wikipedia.org/wiki/Benchmarking) 163 | * [Blockchain database](https://wikipedia.org/wiki/Blockchain_(database)) 164 | * [Boolean algebra](https://wikipedia.org/wiki/Boolean_algebra) 165 | * [bounded context](https://en.wikipedia.org/wiki/Domain-driven_design#Bounded_context] 166 | * [BPEL: Business Process Execution Language](https://wikipedia.org/wiki/Business_Process_Execution_Language) 167 | * [BPS: bits per second](https://en.wikipedia.org/wiki/Data_rate_units): also abbreviated as bitrate and bits/s. 168 | * [browser a.k.a. web browser](https://en.wikipedia.org/wiki/Web_browser) 169 | * [business logic](https://wikipedia.org/wiki/Business_logic) 170 | * [business to business (B2B)](TODO) 171 | * [business to consumer (B2C)](TODO) 172 | * [cache](https://en.wikipedia.org/wiki/Cache_(computing)) 173 | * [cache pollution](https://en.wikipedia.org/wiki/Cache_pollution): where an executing computer program loads data into CPU cache unnecessarily, thus causing other useful data to be evicted from the cache. 174 | * [CAM: Content Assembly Mechanism](https://wikipedia.org/wiki/Content_Assembly_Mechanism): a generalized assembly mechanism for using templates of XML business transaction content and the associated rules. CAM templates augment schema syntax and provide implementers with the means to specify interoperable interchange patterns. 175 | * [CAMP: Cloud Application Management for Platforms](https://wikipedia.org/wiki/Cloud_Application_Management_for_Platforms): an API for managing public and private cloud applications. 176 | * [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem): a distributed system cannot simultaneously provide consistency, availability, and partition tolerance. (cf. PACELC) 177 | * [CAP: Common Alerting Protocol](https://wikipedia.org/wiki/Common_Alerting_Protocol): an XML-based data format for exchanging public warnings and emergencies between alerting technologies. 178 | * [CASE: computer-aided software engineering](https://wikipedia.org/wiki/Computer-aided_software_engineering) 179 | * [CIQ: Customer Information Quality](https://wikipedia.org/wiki/EDXL#Customer_Information_Quality): an XML Specifications for defining, representing, interoperating and managing party information (e.g. name, address). 180 | * [CLI: call level interface](https://en.wikipedia.org/wiki/Call_Level_Interface) 181 | * [CLI: command-line interface](https://en.wikipedia.org/wiki/Command-line_interface) 182 | * [CM: content management](TODO) 183 | * [CMIS: Content Management Interoperability Services](https://wikipedia.org/wiki/Content_Management_Interoperability_Services): a domain model and Web services standard for working with Enterprise content management repositories and systems. 184 | * [CMS: content management system](https://en.wikipedia.org/wiki/Content_management_system) 185 | * [CNAME: canonical name record](https://wikipedia.org/wiki/CNAME_record) (see DNS, IP address) 186 | * [conceptual architecture](TODO) (cf. logical architecture) 187 | * [connection pool](https://wikipedia.org/wiki/Connection_pool) 188 | * [consistency (C)](https://en.wikipedia.org/wiki/Consistency_(database_systems)): all system nodes see the same data at the same time 189 | * [content management (CM)](TODO) 190 | * [content management system (CMS)](https://en.wikipedia.org/wiki/Content_management_system) 191 | * [core concern](https://en.wikipedia.org/wiki/Core_concern) 192 | * [CQRS: command query responsibility segregation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation#Command_Query_Responsibility_Segregation) 193 | * [CQS: command-query separation](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation) 194 | * [cross-cutting concern](https://en.wikipedia.org/wiki/Cross-cutting_concern) 195 | * [cross-fader release](TODO) 196 | * [cyclomatic complexity](https://en.wikipedia.org/wiki/Cyclomatic_complexity) 197 | * [DAMP: descriptive and meaningful phrases](TODO): a software development principal that improves code readability; cf. DRY. 198 | * [dark launch](TODO) 199 | * [data analysis](https://en.wikipedia.org/wiki/Data_analysis) 200 | * [data compression](https://en.wikipedia.org/wiki/Data_compression) 201 | * [data grid](https://en.wikipedia.org/wiki/Data_grid): architecture and services to enable geographically distributed data and caching. 202 | * [data item descriptions](https://wikipedia.org/wiki/Data_item_descriptions) 203 | * [DB: database](https://en.wikipedia.org/wiki/Database) 204 | * [DbC: design by contract](https://en.wikipedia.org/wiki/Design_by_contract) a.k.a. contract programming, programming by contract, design-by-contract programming. 205 | * [DBMS: database management system](https://en.wikipedia.org/w/index.php?title=Database_management_system) 206 | * [debugging](https://en.wikipedia.org/wiki/Debugging) 207 | * [design thinking](TODO): the discipline that uses the designer’s sensibility and methods to match people’s needs with what is feasible and valuable. 208 | * [devops: development + operations](https://en.wikipedia.org/wiki/DevOps) 209 | * [digital content](https://en.wikipedia.org/wiki/Digital_content): any type of content that exists in the form of digital data. 210 | * [digital data](https://en.wikipedia.org/wiki/Digital_data) 211 | * [digital distribution](https://en.wikipedia.org/wiki/Digital_distribution) 212 | * [digital economy](https://en.wikipedia.org/wiki/Digital_economy) 213 | * [digital marketing](https://en.wikipedia.org/wiki/Digital_marketing): marketing of products/services using digital technologies. 214 | * [digital media](https://en.wikipedia.org/wiki/Digital_media) 215 | * [digital signature](https://wikipedia.org//wiki/Digital_signature) 216 | * [DITA: Darwin Information Typing Architecture](https://wikipedia.org/wiki/Darwin_Information_Typing_Architecture): a modular and extensible XML-based language for topic-based information, such as for online help, documentation, and training. 217 | * [DKIM: DomainKeys identified mail](https://wikipedia.org/wiki/DomainKeys_Identified_Mail) (cf. DMARC, SPF) 218 | * [DMARC: domain-based message authentication, Reporting and Conformance](https://wikipedia.org/wiki/DMARC) (cf. DKIM, SPF) 219 | * [DNS: domain name system](https://wikipedia.org/wiki/Domain_Name_System) (see CNAME, IP address) 220 | * [DNSBL: DNS-based blackhole list](https://wikipedia.org/wiki/DNSBL) (a.k.a. RBL) 221 | * [DocBook](https://wikipedia.org/wiki/DocBook): markup language for technical documentation. 222 | * [domain-specific language (DSL)](https://en.wikipedia.org/wiki/Domain-specific_language) 223 | * [DRY: don't repeat yourself](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself): a principle of software development, aimed at reducing repetition of information of all kinds; cf. DAMP. 224 | * [DSL: domain-specific language](https://en.wikipedia.org/wiki/Domain-specific_language) 225 | * [DSML: Directory Services Markup Language](https://wikipedia.org/wiki/Directory_Services_Markup_Language) 226 | * [DSS: Digital Signature Services](https://wikipedia.org/wiki/Digital_Signature_Services) 227 | * [dst: destination](TODO) 228 | * [ebXML](https://wikipedia.org/wiki/EbXML) 229 | * [EAI: enterprise application integration](TODO) 230 | * [ECM: enterprise content management](https://en.wikipedia.org/wiki/Enterprise_content_management) 231 | * [ESB: enterprise service bus](TODO) 232 | * [EDXL: Emergency Data Exchange Language](https://wikipedia.org/wiki/EDXL): suite of XML-based messaging standards that facilitate emergency information sharing between government entities and the full range of emergency-related organizations. 233 | * [EML: Election Markup Language](https://wikipedia.org/wiki/Election_Markup_Language): end to end information standards and processes for conducting democratic elections using XML-based information recording. 234 | * [encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)) 235 | * [enterprise application integration (EAI)](TODO) 236 | * [enterprise service bus (ESB)](https://en.wikipedia.org/wiki/Enterprise_service_bus) 237 | * [ESB: enterprise service bus](https://en.wikipedia.org/wiki/Enterprise_service_bus) 238 | * [ESD: electronic software distribution](TODO) 239 | * [fat client](https://en.wikipedia.org/wiki/Fat_client) (cf. thin client) 240 | * [FIFO: first in, first out](TODO) (a.k.a. queue, cf. FILO, LIFO, LILO) 241 | * [FILO: first in, last out](TODO) (a.k.a. stack, cf. FIFO, LIFO, LILO) 242 | * [firewall](https://en.wikipedia.org/wiki/Firewall_(computing)) 243 | * [font](TODO) 244 | * [fuzzy logic](https://wikipedia.org/wiki/Fuzzy_logic) 245 | * [GeoXACML: Geospatial eXtensible Access Control Markup Language](https://wikipedia.org/wiki/GeoXACML): a geo-specific extension to XACML, mainly the geometric data-type and several geographic functions such as topological, bag, set, geometric and conversion functions. 246 | * [Git: distributed version control for source code](https://wikipedia.org/wiki/Git_(software)) 247 | * [globalization management system](https://en.wikipedia.org/wiki/Globalization_management_system) 248 | * [GPG: GNU Privacy Guard](https://wikipedia.org/wiki/GNU_Privacy_Guard) (cf. PGP) 249 | * [graphical user interface builder](https://wikipedia.org/wiki/Graphical_user_interface_builder) 250 | * [HCI: human-computer interaction](https://en.wikipedia.org/wiki/Human%E2%80%93computer_interaction) 251 | * [Heisenbug](https://en.wikipedia.org/wiki/Heisenbug) 252 | * [Hypervisor](https://en.wikipedia.org/wiki/Hypervisor): software, firmware, or hardware that creates and runs virtual machines. 253 | * [i18n: internationalization](https://en.wikipedia.org/wiki/Internationalization_and_localization) 254 | * [IAM: identity and access management](https://wikipedia.org/wiki/Identity_and_Access_Management) 255 | * [IDM: identity management](TODO) 256 | * [information hiding](https://en.wikipedia.org/wiki/Information_hiding) 257 | * [internationalization (i18n)](https://en.wikipedia.org/wiki/Internationalization_and_localization) 258 | * [internet of things (Iot)](TODO) 259 | * [invalidation](TODO) 260 | * [invariant](https://en.wikipedia.org/wiki/Invariant_(computer_science)) 261 | * [IoT: Internet of Things](TODO) 262 | * [IP address](https://wikipedia.org/wiki/IP_address) (see CNAME, DNS) 263 | * [IP traceback](https://en.wikipedia.org/wiki/IP_traceback) 264 | * [ISO 9000](https://wikipedia.org/wiki/Iso_9000)A family of standards for quality management systems and requirements. 265 | * [ITBM: IT Business Management](TODO) 266 | * [ITOA: IT Operations Analytics](https://en.wikipedia.org/wiki/IT_Operations_Analytics) 267 | * [ITOM: IT Operations Management](TODO) 268 | * [ITSM: IT Service Management](TODO) 269 | * [KMIP: Key Management Interoperability Protocol](https://wikipedia.org/wiki/Key_Management_Interoperability_Protocol): tries to establish a single, comprehensive protocol for the communication between enterprise key management systems and encryption systems. 270 | * [l10n: localization](https://en.wikipedia.org/wiki/Internationalization_and_localization) 271 | * [latency](https://en.wikipedia.org/wiki/Latency_(engineering)) 272 | * [Legal XML](https://wikipedia.org/wiki/Legal_XML): an XML specification for law, electronic court filing, and eNotarization standards. 273 | * [lib: library](TODO) 274 | * [LIFO: last in, first out](TODO) (a.k.a. stack, cf. FIFO, FILO, LILO) 275 | * [LILO: last inn, last out](TODO) (a.k.a. queue, cf. FIFO, FILO, LIFO) 276 | * [load balancing](https://en.wikipedia.org/wiki/Load_balancing_(computing)) 277 | * [locality of reference](https://en.wikipedia.org/wiki/Locality_of_reference) memory access patterns, with types such as temporal, spatial, memory, branch, equidistant. 278 | * [localization (l10n)](https://en.wikipedia.org/wiki/Internationalization_and_localization) 279 | * [logical architecture](TODO) (cf. conceptual architecture) 280 | * [loose coupling](https://wikipedia.org/wiki/Loose_coupling) 281 | * [MDM: master data management](https://en.wikipedia.org/wiki/Master_data_management): comprises the processes, governance, policies, standards and tools that consistently define and manage the critical data of an organization to provide a single point of reference. 282 | * [MDM: mobile device management](https://en.wikipedia.org/wiki/Mobile_device_management): an industry term for the administration of mobile devices, such as smartphones and tablet computers. 283 | * [microservices](https://en.wikipedia.org/wiki/Microservices) 284 | * [ML: machine learning](https://wikipedia.org/wiki/Machine_learning) 285 | * [ML: markup langauge](https://wikipedia.org/wiki/Markup_language) 286 | * [MLS: multiple levels of security (MLS)](https://en.wikipedia.org/wiki/Multilevel_security) 287 | * [MML: Modeling Maturity Levels](https://en.wikipedia.org/wiki/Modeling_Maturity_Levels) 288 | * [Modeling Maturity Levels (MML)](https://en.wikipedia.org/wiki/Modeling_Maturity_Levels) 289 | * [model-view-controller (MVC)](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller): a software architectural pattern for implementing logic and user interfaces. 290 | * [model-view-presenter (MVP)](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter): a derivation of the model–view–controller (MVC) architectural pattern. 291 | * [MQ: message queue](TODO) 292 | * [multilevel security a.k.a. multiple levels of security (MLS)](https://en.wikipedia.org/wiki/Multilevel_security) 293 | * [multiplexing](https://en.wikipedia.org/wiki/Multiplexing) 294 | * [multitier architecture](https://en.wikipedia.org/wiki/Multitier_architecture) (a.k.a. n-tier architecture) 295 | * [mutual exclusion](https://wikipedia.org/wiki/Mutual_exclusion) 296 | * [MVC: model-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller): a software architectural pattern for implementing logic and user interfaces. 297 | * [MVP: model-view-presenter](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter): a derivation of the model–view–controller (MVC) architectural pattern. 298 | * [naked objects](https://en.wikipedia.org/wiki/Naked_objects) 299 | * [network partition](https://en.wikipedia.org/wiki/Network_partition): a failure of a network device that causes a network to be split. 300 | * [oBIX: open Building Information Exchange](https://wikipedia.org/wiki/OBIX): an extensible XML specification for enterprise interaction with building-based (or other) control systems, including HVAC, Access Control, Intrusion Detection, and many others. 301 | * [object pool](https://wikipedia.org/wiki/Object_pool) pattern. 302 | * [object-relational mapping (ORM)](https://en.wikipedia.org/wiki/Object-relational_mapping) 303 | * [ODBC: Open Database Connectivity](https://en.wikipedia.org/wiki/Open_Database_Connectivity) 304 | * [OpenDocument: OASIS Open Document Format for Office Applications](https://wikipedia.org/wiki/OpenDocument): an open document file format for saving office documents such as spreadsheets, memos, charts, and presentations. 305 | * [ORDBMS: object-relational database management system](https://en.wikipedia.org/wiki/Object-relational_database_management_system) 306 | * [ORM: object-relational mapping](https://en.wikipedia.org/wiki/Object-relational_mapping) 307 | * [orthogonality](https://en.wikipedia.org/wiki/Orthogonality#Computer_science) 308 | * [OSLC: Open Services for Lifecycle Collaboration](https://wikipedia.org/wiki/OSLC): develops standards for software lifecycle tools to share data with one another. 309 | * [PACELC](?) If data has a Partition, do Availability-Consistency trade-off; Else, i.e. in normal operation, do Latency-Consistency trade-off. 310 | * [Partition-tolerance (P)](https://en.wikipedia.org/wiki/Network_partition): the system continues to operate despite arbitrary partitioning due to network failures 311 | * [performance metric](https://en.wikipedia.org/wiki/Performance_metric) 312 | * [PGP: Pretty Good Privacy](https://wikipedia.org/wiki/Pretty_Good_Privacy) (cf. GPG) 313 | * [PO: plain old](https://en.wikipedia.org/wiki/Plain_Old_Java_Object) 314 | * [POJO: plain old Java object](https://en.wikipedia.org/wiki/Plain_Old_Java_Object) 315 | * [postcondition](https://en.wikipedia.org/wiki/Postcondition) compare precondition. 316 | * [precondition](https://en.wikipedia.org/wiki/Precondition) compare postcondition. 317 | * [rapid application development](https://wikipedia.org/wiki/Rapid_application_development) 318 | * [RBAC: role-based access control](https://wikipedia.org/wiki/Rbac) 319 | * [RBL: Real-time Blackhole List](https://wikipedia.org/wiki/DNSBL) (a.k.a. DNSBL) 320 | * [RDBMS: relational database management system](https://en.wikipedia.org/wiki/Relational_database_management_system) 321 | * [resource management software](https://en.wikipedia.org/wiki/List_of_resource_management_software) 322 | * [RED: random early detection](https://en.wikipedia.org/wiki/Random_early_detection) 323 | * [referential opacity](https://en.wikipedia.org/wiki/Referential_transparency) 324 | * [referential transparency](https://en.wikipedia.org/wiki/Referential_transparency) 325 | * [reflection](https://en.wikipedia.org/wiki/Reflection_(computer_programming)): the ability of a computer program to examine, introspect, and modify its own structure and behavior at runtime. 326 | * [REST: representational state transfer](https://wikipedia.org/wiki/Representational_state_transfer) (cf. SAP, ROA) 327 | * [ROA: resource oriented architecture](https://wikipedia.org/wiki/Resource-oriented_architecture) (cf. REST)* [scheduling](https://wikipedia.org/wiki/Scheduling_(computing)) 328 | * [SAML: Security Assertion Markup Language](https://wikipedia.org/wiki/Security_Assertion_Markup_Language): a standard XML-based framework for the secure exchange of ## authentication 329 | * [SCM: source code management](https://wikipedia.org/wiki/Source_code_management) 330 | * [SDD: Solution Deployment Descriptor](https://wikipedia.org/wiki/Solution_Deployment_Descriptor) 331 | * [SEO: search engine optimiation](https://en.wikipedia.org/wiki/Search_engine_optimization) 332 | * [Shibboleth single sign on system](https://wikipedia.org/wiki/Shibboleth_(Internet2)) 333 | * [side effect](https://en.wikipedia.org/wiki/Side_effect_(computer_science)) 334 | * [SMO: social media optimiation](https://en.wikipedia.org/wiki/Social_media_optimization) 335 | * [SOA: resource oriented architecture](https://wikipedia.org/wiki/Service-oriented_architecture) (cf. REST) 336 | * [SOAP-over-UDP](https://wikipedia.org/wiki/SOAP-over-UDP) 337 | * [SoE: System of Engagement](TODO) 338 | * [software development process](https://wikipedia.org/wiki/Software_development_process) 339 | * [SPF: Sender Policy Framework](https://wikipedia.org/wiki/Sender_Policy_Framework) (cf. DKIM, DMARC) 340 | * [SPML: Service Provisioning Markup Language](https://wikipedia.org/wiki/Service_Provisioning_Markup_Language) 341 | * [SPML: Service Provisioning Markup Language](TODO): a standard ## XML 342 | * [SSH: secure shell](https://wikipedia.org/wiki/Secure_Shell) 343 | * [SSL: secure sockets layer](https://wikipedia.org/wiki/Secure_Sockets_Layer) 344 | * [SSL acceleration](https://en.wikipedia.org/wiki/SSL_acceleration) 345 | * [SSO: single sign-on](https://wikipedia.org/wiki/Single_sign-on) 346 | * [subclass](https://wikipedia.org/wiki/Subclass_(computer_science)) 347 | * [synthetic monitoring](https://en.wikipedia.org/wiki/Synthetic_monitoring): (also known as active monitoring or proactive monitoring) is website monitoring that is done using a web browser emulation or scripted recordings of web transactions. 348 | * [technical debt](https://en.wikipedia.org/wiki/Technical_debt) (also known as design debt or code debt) 349 | * [thin client](https://en.wikipedia.org/wiki/Thin_client) (cf. fat client) 350 | * [thrashing](https://en.wikipedia.org/wiki/Thrashing_(computer_science)) performance problems when a computer system is in a constant state of paging, to the exclusion of most application-level processing. 351 | * [thread pool](https://wikipedia.org/wiki/Thread_pool) 352 | * [throughput](https://en.wikipedia.org/wiki/Throughput) 353 | * [TLS: transport layer security](https://wikipedia.org/wiki/Transport_Layer_Security) 354 | * [TOSCA: Topology and Orchestration Specification for Cloud Applications](https://wikipedia.org/wiki/OASIS_TOSCA): a standard to describe cloud services, the relationships between parts of the service, and the operational behavior of the services. 355 | * [TOSCA](https://wikipedia.org/wiki/OASIS_TOSCA) 356 | * [traffic shaping](https://en.wikipedia.org/wiki/Traffic_shaping) a.k.a. packet shaping. 357 | * [UBL: Universal Business Language](https://wikipedia.org/wiki/Universal_Business_Language) 358 | * [UBL](https://wikipedia.org/wiki/Universal_Business_Language) — Universal Business Language, National effort to define a royalty-free library of standard electronic XML business documents. All invoices to the Danish government have to be in UBL electronic format since February 2005. 359 | * [UDDI: Universal Description Discovery and Integration](https://wikipedia.org/wiki/Universal_Description_Discovery_and_Integration) 360 | * [UDDI: Universal Description Discovery and Integration](TODO): a ## platform-independent 361 | * [UI: user interface](https://en.wikipedia.org/wiki/User_interface) (cf. user interaction, HCI) 362 | * [URI: uniform resource identifier](https://wikipedia.org/wiki/Uniform_resource_identifier) (cf. URL) 363 | * [URL: uniform resource locator](https://wikipedia.org/wiki/Url) (cf. URI) 364 | * [UX: user experience](https://en.wikipedia.org/wiki/User_experience) 365 | * [validation](TODO) 366 | * [vCPU: virtual central processing unit](TODO): one or more vCPUs are assigned to every Virtual Machine (VM) within a cloud environment. 367 | * [VCS: version control system](TODO) 368 | * [virtual environment](TODO) 369 | * [virtual LAN (VLAN)](https://en.wikipedia.org/wiki/Virtual_LAN): any broadcast domain that is partitioned and isolated in a computer network at the data link layer. 370 | * [VLAN: virtual LAN](https://en.wikipedia.org/wiki/Virtual_LAN): any broadcast domain that is partitioned and isolated in a computer network at the data link layer. 371 | * [web framework](https://wikipedia.org/wiki/Web_framework) 372 | * [WebCGM: Web Computer Graphics Metafile](https://wikipedia.org/wiki/Computer_Graphics_Metafile) 373 | * [WRR: weighted round robin](https://en.wikipedia.org/wiki/Weighted_round_robin) 374 | * [WS-BPEL](https://wikipedia.org/wiki/Business_Process_Execution_Language) 375 | * [WS-BPEL](https://wikipedia.org/wiki/WS-BPEL) — Web Services Business Process Execution Language 376 | * [WSDM: Web Services Distributed Management](https://wikipedia.org/wiki/Web_Services_Distributed_Management) 377 | * [WSDM](https://wikipedia.org/wiki/Web_Services_Distributed_Management) — Web Services Distributed Management 378 | * [WSRF](https://wikipedia.org/wiki/Web_Services_Resource_Framework) 379 | * [WSS](https://wikipedia.org/wiki/WS-Security) 380 | * [XACML: eXtensible Access Control Markup Language](https://wikipedia.org/wiki/XACML) 381 | * [XACML](https://wikipedia.org/wiki/XACML) 382 | * [XDI: XRI Data Interchange](TODO): a standard for sharing, linking, and synchronizing data ("## dataweb 383 | * [XDI](https://wikipedia.org/wiki/XDI) 384 | * [XLIFF: XML Localization Interchange File Format](TODO) a ## XML 385 | * [XRI: Extensible Resource Identifier](https://wikipedia.org/wiki/Extensible_Resource_Identifier) 386 | * [XRI: eXtensible Resource Identifier](https://wikipedia.org/wiki/XRI) 387 | -------------------------------------------------------------------------------- /doc/software_design_patterns.md: -------------------------------------------------------------------------------- 1 | # Software design patterns 2 | 3 | * [Abstract factory](https://wikipedia.org/wiki/Abstract_factory_pattern): Provide an interface for creating families of related or dependent objects. 4 | * [Abstraction principle](https://wikipedia.org/wiki/Abstraction_principle_(programming)) 5 | * [Active object](https://wikipedia.org/wiki/Active_object): Decouple method execution from method invocation that reside in their own thread of control. 6 | * [Active record](https://wikipedia.org/wiki/Active_record_pattern) 7 | * [Adapter](https://wikipedia.org/wiki/Adapter_pattern): Convert the interface of a class into another interface clients expect. 8 | * [Aggregate](https://wikipedia.org/wiki/Aggregate_pattern) object sequentially without exposing its underlying representation. 9 | * [Algorithmic skeleton](https://wikipedia.org/wiki/Algorithmic_skeleton) 10 | * [Anti-pattern](https://wikipedia.org/wiki/Anti-pattern) 11 | * [Architectural pattern](https://wikipedia.org/wiki/Architectural_pattern_(computer_science)) 12 | * [Artificial intelligence](https://wikipedia.org/wiki/Artificial_intelligence) 13 | * [Balking](https://wikipedia.org/wiki/Balking_pattern): Only execute an action on an object when the object is in a particular state. 14 | * [Binding properties](https://wikipedia.org/wiki/Binding_properties_pattern): Combine multiple observers to force properties in different objects to be coordinated. 15 | * [Blackboard](https://wikipedia.org/wiki/Blackboard_design_pattern): Artificial intelligence pattern for combining disparate sources of data. 16 | * [Blockchain](https://wikipedia.org/wiki/Blockchain_(database)): Decentralize storage of data and agree on ways of processing it. 17 | * [Bridge](https://wikipedia.org/wiki/Bridge_pattern): Decouple an abstraction from its implementation allowing the two to vary independently. 18 | * [Builder](https://wikipedia.org/wiki/Builder_pattern): Separate the construction of a complex object from its representation. 19 | * [Business delegate](https://wikipedia.org/wiki/Business_delegate_pattern) 20 | * [Cache access patterns](TODO) 21 | * [Chain of responsibility](https://wikipedia.org/wiki/Chain_of_responsibility_pattern): Chain event-receiving objects in order to pass a request along the chain until an object handles it. 22 | * [Circuit-breaker](TODO) 23 | * [Command](https://wikipedia.org/wiki/Command_pattern): Encapsulate a request as an object. 24 | * [Composite entity](https://wikipedia.org/wiki/Composite_entity_pattern): Compose objects into tree structures to represent part-whole hierarchies. 25 | * [Composite](https://wikipedia.org/wiki/Composite_pattern) 26 | * [Concurrency pattern](https://wikipedia.org/wiki/Concurrency_pattern) 27 | * [Creational pattern](https://wikipedia.org/wiki/Creational_pattern) 28 | * [Data access object](https://wikipedia.org/wiki/Data_access_object) 29 | * [Data transfer object](https://wikipedia.org/wiki/Data_transfer_object) 30 | * [Debugging patterns](https://wikipedia.org/wiki/Debugging_patterns) 31 | * [Decorator](https://wikipedia.org/wiki/Decorator_pattern): Attach additional responsibilities to an object dynamically keeping the same interface. 32 | * [Dependency injection](https://wikipedia.org/wiki/Dependency_injection) 33 | * [Design pattern](https://wikipedia.org/wiki/Design_pattern) 34 | * [Distributed design patterns](https://wikipedia.org/wiki/Distributed_design_patterns) 35 | * [Double-chance function](https://wikipedia.org/wiki/Double-chance_function) 36 | * [Double-checked locking](https://wikipedia.org/wiki/Double-checked_locking): Reduce the overhead of acquiring a lock by first testing the locking criterion. 37 | * [EDA: Event-driven architecture a.ka. message-driven architecture (MDA)](https://en.wikipedia.org/wiki/Event-driven_architecture) 38 | * [Enterprise Architecture framework](https://wikipedia.org/wiki/Enterprise_Architecture_framework) 39 | * [Event-based asynchronous](https://wikipedia.org/wiki/Asynchronous_method_invocation): Address problems with asynchronous patterns that occur in multithreaded programs. 40 | * [Extension object](TODO): Add functionality to a hierarchy without changing the hierarchy. 41 | * [Facade](https://wikipedia.org/wiki/Facade_pattern): Provide a unified interface to a set of interfaces in a subsystem. 42 | * [Factory method](https://wikipedia.org/wiki/Factory_method_pattern): Define an interface to create an object, but let subclasses decide which class to instantiate. 43 | * [Fault tolerance access patterns](TODO) 44 | * [Flyweight](https://wikipedia.org/wiki/Flyweight_pattern): Use sharing to support large numbers of similar objects efficiently. 45 | * [Front controller](https://wikipedia.org/wiki/Front_controller): Provide a centralized entry point for handling requests. 46 | * [General Responsibility Assignment Software Patterns (GRASP)](https://wikipedia.org/wiki/GRASP_(object-oriented_design)) 47 | * [GRASP (object-oriented design)](https://wikipedia.org/wiki/GRASP_(object-oriented_design)) 48 | * [Guarded suspension](https://wikipedia.org/wiki/Guarded_suspension): Manage operations that first require both a lock and a precondition. 49 | * [Helper class](https://wikipedia.org/wiki/Helper_class) 50 | * [Identity map](https://wikipedia.org/wiki/Identity_map_pattern) 51 | * [Interaction design pattern](https://wikipedia.org/wiki/Interaction_design_pattern) 52 | * [Intercepting filter](https://wikipedia.org/wiki/Intercepting_filter_pattern) 53 | * [Interceptor](https://wikipedia.org/wiki/Interceptor_pattern) 54 | * [Interpreter](https://wikipedia.org/wiki/Interpreter_pattern): Represent a language's grammar and how to interpret sentences. 55 | * [Inversion of control](https://wikipedia.org/wiki/Inversion_of_control) 56 | * [Iterator](https://wikipedia.org/wiki/Iterator_pattern): Provide a way to access the elements of an aggregate object sequentially. 57 | * [Join](https://wikipedia.org/wiki/Join-pattern): Provide a way to write concurrent, parallel and distributed programs by message passing. 58 | * [Lazy initialization](https://wikipedia.org/wiki/Lazy_initialization): Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed. 59 | * [Lazy loading](https://wikipedia.org/wiki/Lazy_loading) 60 | * [Lock](https://wikipedia.org/wiki/Lock_pattern): Put a "lock" on a resource, preventing other objects from accessing or modifying it. 61 | * [Marker](https://wikipedia.org/wiki/Marker_interface_pattern): Empty interface to associate metadata with a class. 62 | * [Mediator](https://wikipedia.org/wiki/Mediator_pattern): Promote loose coupling by keeping objects from referring to each other explicitly. 63 | * [Memento](https://wikipedia.org/wiki/Memento_pattern): Capture and externalize an object's internal state, enabling the object to be restored to this state later. 64 | * [Messaging design pattern (MDP)](https://wikipedia.org/wiki/Messaging_pattern): Enable interchange of information (i.e. messages) between components. 65 | * [Mock object](https://wikipedia.org/wiki/Mock_object) 66 | * [Module](https://wikipedia.org/wiki/Module_pattern): Group related elements, such as classes and methods, into a single conceptual entity. 67 | * [Monitor](https://wikipedia.org/wiki/Monitor_(synchronization)): An object whose methods are subject to mutual exclusion, thus preventing multiple objects from erroneously trying to use it at the same time. 68 | * [Multi-tier architecture a.k.a. n-tier architecture](https://wikipedia.org/wiki/Multitier_architecture) 69 | * [Multiton](https://wikipedia.org/wiki/Multiton_pattern): Ensure a class has only named instances, and provide a global point of access to them. 70 | * [MVC: Model-View-Controller](https://wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) 71 | * [Naked objects](https://wikipedia.org/wiki/Naked_objects) 72 | * [Null object](https://wikipedia.org/wiki/Null_object_pattern): Provide a default object, so as to avoid null references. 73 | * [Object pool](https://wikipedia.org/wiki/Object_pool_pattern): Avoid expensive acquisition and release of resources by recycling objects that are no longer in use. 74 | * [Observer](https://wikipedia.org/wiki/Observer_pattern): Define how a state change in one object results in dependents being notified and updated. 75 | * [Pattern language](https://wikipedia.org/wiki/Pattern_language) 76 | * [Pattern theory](https://wikipedia.org/wiki/Pattern_theory) 77 | * [Pedagogical patterns](https://wikipedia.org/wiki/Pedagogical_patterns) 78 | * [Portland Pattern Repository](https://wikipedia.org/wiki/Portland_Pattern_Repository) 79 | * [Proactor](https://wikipedia.org/wiki/Proactor_pattern) 80 | * [Prototype](https://wikipedia.org/wiki/Prototype_pattern): Create new objects from the skeleton of an existing object. 81 | * [Proxy](https://wikipedia.org/wiki/Proxy_pattern): Provide a surrogate or placeholder for another object to control access to it. 82 | * [Publish–subscribe a.k.a. pubsub](https://wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern): Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically. 83 | * [Reactor](https://wikipedia.org/wiki/Reactor_pattern): Provide an asynchronous interface to resources that must be handled synchronously. 84 | * [Read-write lock](https://wikipedia.org/wiki/Read/write_lock_pattern): Allows concurrent read access to an object, but requires exclusive access for write operations. 85 | * [Refactoring](https://wikipedia.org/wiki/Refactoring) 86 | * [Resource acquisition is initialization](https://wikipedia.org/wiki/Resource_Acquisition_Is_Initialization): Ensure resources are released by tying them to the lifespan of objects. 87 | * [Scheduler](https://wikipedia.org/wiki/Scheduler_pattern): Explicitly control when threads may execute single-threaded code. 88 | * [Servant](https://wikipedia.org/wiki/Servant_(design_pattern)): Define common functionality for a group of classes. 89 | * [Service locator](https://wikipedia.org/wiki/Service_locator_pattern) 90 | * [Service to service access patterns](TODO) 91 | * [Singleton](https://wikipedia.org/wiki/Singleton_pattern): Ensure a class has only one instance, and provide a global point of access to it. 92 | * [SOA: Service-oriented architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture) 93 | * [Software design pattern](https://wikipedia.org/wiki/Software_design_pattern) 94 | * [Software development methodology](https://wikipedia.org/wiki/Software_development_methodology) 95 | * [Specification](https://wikipedia.org/wiki/Specification_pattern): Recombinable business logic in a Boolean fashion. 96 | * [State](https://wikipedia.org/wiki/State_pattern): Allow an object to alter its behavior when its internal state changes. 97 | * [Strategy](https://wikipedia.org/wiki/Strategy_pattern): Define a family of algorithms, encapsulate each one, and make them interchangeable. 98 | * [Structural pattern](https://wikipedia.org/wiki/Structural_pattern) 99 | * [Template method](https://wikipedia.org/wiki/Template_method_pattern): Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. 100 | * [Thread pool](https://wikipedia.org/wiki/Thread_pool_pattern): A number of threads are created to perform a number of tasks. 101 | * [Thread-local storage](https://wikipedia.org/wiki/Thread-local_storage) 102 | * [Thread-specific storage](https://wikipedia.org/wiki/Thread-Specific_Storage): Static or "global" memory local to a thread. 103 | * [Twin](https://wikipedia.org/wiki/Twin_pattern): Model multiple inheritance in programming languages that do not support this feature. 104 | * [Type tunnel](https://wikipedia.org/wiki/Type_Tunnel_pattern) 105 | * [Visitor](https://wikipedia.org/wiki/Visitor_pattern): Represent an operation to be performed on the elements of an object structure. 106 | -------------------------------------------------------------------------------- /doc/software_testing.md: -------------------------------------------------------------------------------- 1 | # Software testing wordbook 2 | 3 | * [acceptance testing](https://wikipedia.org/wiki/Acceptance_testing) 4 | * [ad hoc testing](https://en.wikipedia.org/wiki/Ad_hoc_testing) 5 | * [BDD: behavior-driven development](https://wikipedia.org/wiki/Behavior-driven_development) (cf. EDD, FDD, TDD) 6 | * [black-box testing](https://en.wikipedia.org/wiki/Black-box_testing) 7 | * [boundary testing](https://en.wikipedia.org/wiki/Boundary_testing) 8 | * [code coverage](https://en.wikipedia.org/wiki/Code_coverage): the degree to which the source code of a program is executed when a particular test suite runs. 9 | * [compatibility testing](https://en.wikipedia.org/wiki/Compatibility_testing) 10 | * [contract testing](TODO) 11 | * [dynamic testing](https://en.wikipedia.org/wiki/Dynamic_testing) (compare static testing) 12 | * [EDD: experiment-driven development](https://wikipedia.org/wiki/Test-driven_development) (cf. BDD, FDD, HDD, TDD) 13 | * [FAT: factory acceptance testing](TODO) 14 | * [FDD: feature-driven development](https://wikipedia.org/wiki/Feature-driven_development) (cf. BDD, EDD, TDD) 15 | * [functional testing](https://wikipedia.org/wiki/Functional_testing) 16 | * [fuzz testing](https://en.wikipedia.org/wiki/Fuzz_testing) 17 | * [HDD: hypothesis-driven development](https://wikipedia.org/wiki/Test-driven_development) (cf. BDD, EDD, FDD, TDD) 18 | * [graphical user interface testing](https://en.wikipedia.org/wiki/Graphical_user_interface_testing) 19 | * [gray-box testing](https://en.wikipedia.org/wiki/Gray_box_testing) 20 | * [installation testing](https://en.wikipedia.org/wiki/Installation_testing) 21 | * [integration testing](https://wikipedia.org/wiki/Integration_testing) 22 | * [load testing](https://en.wikipedia.org/wiki/Load_testing) 23 | * [maintenance testing](https://en.wikipedia.org/wiki/Maintenance_testing) 24 | * [OAT: operational acceptance testing](https://en.wikipedia.org/wiki/Operational_acceptance_testing) 25 | * [performance testing](https://en.wikipedia.org/wiki/Software_performance_testing) 26 | * [recovery testing](https://en.wikipedia.org/wiki/Recovery_testing) 27 | * [regression testing](https://en.wikipedia.org/wiki/Regression_testing) 28 | * [regulation acceptance testing](TODO) 29 | * [sanity testing](https://en.wikipedia.org/wiki/Sanity_testing) 30 | * [security testing](https://en.wikipedia.org/wiki/Security_testing) 31 | * [scalability testing](https://en.wikipedia.org/wiki/Scalability_testing) 32 | * [shift-left testing](https://en.wikipedia.org/wiki/Shift_left_testing) 33 | * [shift-right testing](https://en.wikipedia.org/wiki/Shift_right_testing) 34 | * [smoke testing](https://en.wikipedia.org/wiki/Smoke_testing_(software)) 35 | * [software testing](https://en.wikipedia.org/wiki/Software_testing) 36 | * [static testing](https://en.wikipedia.org/wiki/Static_program_analysis) (compare dynamic testing) 37 | * [stress testing](https://en.wikipedia.org/wiki/Stress_testing) 38 | * [system testing](https://en.wikipedia.org/wiki/System_testing) 39 | * [TDD: test-driven development](https://wikipedia.org/wiki/Test-driven_development) (cf. BDD, EDD, FDD, HDD) 40 | * [test automation](https://en.wikipedia.org/wiki/Test_automation) 41 | * [test harness](https://en.wikipedia.org/wiki/Test_harness) 42 | * [test pyramid a.k.a. test triangle](http://martinfowler.com/bliki/TestPyramid.html) 43 | * [UAT: user acceptance test](TOD) 44 | * [unit testing](https://wikipedia.org/wiki/Unit_testing) 45 | * [usability testing](https://en.wikipedia.org/wiki/Usability_testing) 46 | * [white-box testing](https://en.wikipedia.org/wiki/White-box_testing) (also known as clear box testing, glass box testing, transparent box testing, and structural testing) 47 | -------------------------------------------------------------------------------- /doc/technical_debt_causes.md: -------------------------------------------------------------------------------- 1 | # Software technical debt causes 2 | 3 | * Business pressures: where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes. 4 | * Lack of process or understanding: where businesses are blind to the concept of technical debt, and make decisions without considering the implications. 5 | * Lack of building loosely coupled components: where functions are not modular, the software is not flexible enough to adapt to changes in business needs. 6 | * Lack of a test suite: which encourages quick and risky band-aids to fix bugs. 7 | * Lack of documentation: where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid. 8 | * Lack of collaboration: where knowledge isn't shared around the organization and business efficiency suffers, or junior developers are not properly mentored. 9 | * Parallel development: at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up. 10 | * Delayed refactoring: as the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done. 11 | * Lack of alignment to standards: where industry standard features, frameworks, technologies are ignored. Eventually, integration with standards will come, doing sooner will cost less (similar to 'delayed refactoring'). 12 | * Lack of knowledge: when the developer simply doesn't know how to write elegant code. 13 | * Lack of ownership: when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code. 14 | * Poor technological leadership: where poorly thought out commands handed down the chain of command increases the technical debt rather than reduce it 15 | * Last minute specification changes: these have potential to percolate throughout a project but no time or budget to see them through with documentation and checks 16 | * Scope Doping: unmanaged scope reduction or shedding of scope by project managers, or indeed technical staff. Subtly different to Business pressures in that, while business pressures may be a cause, Scope Doping will also cause business pressure due to unmanaged work scope that has been shed. 17 | -------------------------------------------------------------------------------- /doc/variable_shadowing.md: -------------------------------------------------------------------------------- 1 | # Variable shadowing 2 | 3 | https://en.wikipedia.org/wiki/Variable_shadowing 4 | 5 | Examples of variable shadowing with synergy with affine types (move semantics): 6 | 7 | x = x.unwrap // e.g. change from an object to its primitive type 8 | 9 | x = x.validate // e.g. if valid, then return self, else throw 10 | 11 | x = x.sanitize // e.g. untaint, trim, chop, etc. 12 | 13 | Examples of variable shadowing for functional changes: 14 | 15 | x = typecast(x) // e.g. change from one type to another type 16 | 17 | x = decorate(x) // e.g. add info to the object 18 | 19 | x = combine(x, y, z) // e.g. merge, intersect, union, min, max 20 | 21 | Example of variable shadowing for changing mutability/immutability: 22 | 23 | let mut vec = Vec::new(); // vec is mutable 24 | vec.push(a); 25 | let vec = vec; // vec immutable 26 | 27 | Some languages allow variable shadowing. 28 | 29 | Some languages allow variable shadowing with type changes. 30 | 31 | Some languages can show warnings when a variable shadowing happens, or when a variable is unused. 32 | 33 | Some languages (e.g. Rust) have variable shadowing automatically from supporting shadowing-in-general (idents in enclosing scopes) and the ability to declare new variables mid-block. Each new declaration opens a new implicit scope from its point-of-declaration to the end of its lexical block. 34 | 35 | Posts: 36 | 37 | * [rust-dev: Variables with the same name in the same scope])https://mail.mozilla.org/pipermail/rust-dev/2013-May/004298.html) 38 | * [Why does Rust need local variable shadowing?](https://www.reddit.com/r/rust/comments/2cho4g/why_does_rust_need_local_variable_shadowing/) 39 | 40 | --------------------------------------------------------------------------------