-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathglossary.html
More file actions
324 lines (313 loc) · 24.5 KB
/
glossary.html
File metadata and controls
324 lines (313 loc) · 24.5 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
<!DOCTYPE html>
<html lang="en" class="no-js">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="description" content="microsite">
<meta name="generator" content="Paradox, paradox-material-theme=0.7.0, mkdocs-material=3.0.3">
<meta name="lang:clipboard.copy" content="Copy to clipboard">
<meta name="lang:clipboard.copied" content="Copied to clipboard">
<meta name="lang:search.language" content="">
<meta name="lang:search.pipeline.stopwords" content="true">
<meta name="lang:search.pipeline.trimmer" content="true">
<meta name="lang:search.result.none" content="No matching documents">
<meta name="lang:search.result.one" content="1 matching document">
<meta name="lang:search.result.other" content="# matching documents">
<meta name="lang:search.tokenizer" content="[\s\-]+">
<meta name="description" content="microsite">
<link rel="shortcut icon" href="assets/images/favicon.png">
<title>Izumi Glossary · Izumi Project</title>
<link rel="stylesheet" href="assets/stylesheets/application.451f80e5.css">
<link rel="stylesheet" href="lib/material__tabs/dist/mdc.tabs.min.css">
<link rel="stylesheet" href="lib/prettify/prettify.css">
<script src="assets/javascripts/modernizr.1aa3b519.js"></script>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:300,400,400i,700|Roboto+Mono">
<style>
body,input{font-family:"Roboto","Helvetica Neue",Helvetica,Arial,sans-serif}
code,kbd,pre{font-family:"Roboto Mono","Courier New",Courier,monospace}
</style>
<link rel="stylesheet" href="assets/fonts/font-awesome.css">
<link rel="stylesheet" href="assets/fonts/material-icons.css">
<link rel="stylesheet" href="assets/stylesheets/paradox-material-theme.css">
</head>
<body
>
<input class="md-toggle" data-md-toggle="drawer" type="checkbox" id="__drawer" autocomplete="off">
<input class="md-toggle" data-md-toggle="search" type="checkbox" id="__search" autocomplete="off">
<label class="md-overlay" data-md-component="overlay" for="__drawer"></label>
<header class="md-header" data-md-component="header">
<nav class="md-header-nav md-grid">
<div class="md-flex">
<div class="md-flex__cell md-flex__cell--shrink">
<a href="index.html" title="Izumi Project" class="md-header-nav__button md-logo">
<i class="md-icon">local_library</i>
</a>
</div>
<div class="md-flex__cell md-flex__cell--shrink">
<label class="md-icon md-icon--menu md-header-nav__button" for="__drawer"></label>
</div>
<div class="md-flex__cell md-flex__cell--stretch">
<div class="md-flex__ellipsis md-header-nav__title" data-md-component="title">
<span class="md-header-nav__topic">
Izumi Project
</span>
<span class="md-header-nav__topic">
Izumi Glossary
</span>
</div>
</div>
<div class="md-flex__cell md-flex__cell--shrink">
<label class="md-icon md-icon--search md-header-nav__button" for="__search"></label>
<div class="md-search" data-md-component="search" role="dialog">
<label class="md-search__overlay" for="__search"></label>
<div class="md-search__inner" role="search">
<form class="md-search__form" name="search">
<input type="text" class="md-search__input" name="query" placeholder="Search" autocapitalize="off" autocorrect="off" autocomplete="off" spellcheck="false" data-md-component="query" data-md-state="active">
<label class="md-icon md-search__icon" for="__search"></label>
<button type="reset" class="md-icon md-search__icon" data-md-component="reset" tabindex="-1"></button>
</form>
<div class="md-search__output">
<div class="md-search__scrollwrap" data-md-scrollfix>
<div class="md-search-result" data-md-component="result">
<div class="md-search-result__meta">
Type to start searching
</div>
<ol class="md-search-result__list"></ol>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="md-flex__cell md-flex__cell--shrink">
<div class="md-header-nav__source">
<a href="https://github.com/7mind/izumi"
title="Go to repository"
class="md-source"
data-md-source="github">
<div class="md-source__icon">
<i class="fa fa-github"></i>
</div>
<div class="md-source__repository">
7mind/izumi
</div>
</a>
</div>
</div>
</div>
</nav>
</header>
<div class="md-container">
<main class="md-main">
<div class="md-main__inner md-grid" data-md-component="container">
<div class="md-sidebar md-sidebar--primary" data-md-component="navigation">
<div class="md-sidebar__scrollwrap">
<div class="md-sidebar__inner">
<nav class="md-nav md-nav--primary" data-md-level="0" style="visibility: hidden">
<label class="md-nav__title md-nav__title--site" for="drawer">
<a href="index.html" title="Izumi Project" class="md-nav__button md-logo">
<span class="md-nav__button md-logo">
<i class="md-icon">local_library</i>
</a>
<a href="index.html" title="Izumi Project">
Izumi Project
</a>
</label>
<div class="md-nav__source">
<a href="https://github.com/7mind/izumi"
title="Go to repository"
class="md-source"
data-md-source="github">
<div class="md-source__icon">
<i class="fa fa-github"></i>
</div>
<div class="md-source__repository">
7mind/izumi
</div>
</a>
</div>
<ul>
<li><a href="glossary.html" class="active page">Izumi Glossary</a></li>
<li><a href="guidelines.html" class="page">Izumi Framework Best Practices</a></li>
<li><a href="bio/index.html" class="page">BIO Hierarchy</a></li>
<li><a href="logstage/index.html" class="page">LogStage</a></li>
<li><a href="distage/index.html" class="page">DIStage</a>
<ul>
<li><a href="distage/basics.html" class="page">Overview</a></li>
<li><a href="distage/debugging.html" class="page">Debugging</a></li>
<li><a href="distage/advanced-features.html" class="page">Advanced Features</a></li>
<li><a href="distage/distage-framework.html" class="page">distage-framework</a></li>
<li><a href="distage/distage-framework-docker.html" class="page">distage-framework-docker</a></li>
<li><a href="distage/distage-testkit.html" class="page">distage-testkit</a></li>
<li><a href="distage/reference.html" class="page">Syntax Reference</a></li>
</ul></li>
<li><a href="idealingua/index.html" class="page">IdeaLingua</a>
<ul>
<li><a href="idealingua/language-reference.html" class="page">Idealingua Language Reference</a></li>
<li><a href="idealingua/json.html" class="page">JSON Wire Format</a></li>
<li><a href="idealingua/cogen.html" class="page">Code generator reference</a></li>
<li><a href="idealingua/cogen-circe.html" class="page">Circe serialization reference</a></li>
</ul></li>
<li><a href="sbt/index.html" class="page">SBT Notes</a></li>
<li><a href="manifesto/index.html" class="page">Productivity and challenges</a></li>
<li><a href="pper/index.html" class="page">PPER Pattern</a></li>
</ul>
<nav class="md-nav md-nav--secondary">
<label class="md-nav__title" for="__toc">Table of contents</label>
<ul>
<li><a href="glossary.html#izumi-glossary" class="header">Izumi Glossary</a>
<ul>
<li><a href="glossary.html#izumi-specific-terms" class="header">Izumi-specific terms</a></li>
<li><a href="glossary.html#izumi-overloaded-terms" class="header">Izumi-overloaded terms</a></li>
<li><a href="glossary.html#terms-elaborated-by-izumi" class="header">Terms elaborated by Izumi</a></li>
</ul></li>
</ul>
</nav>
</nav>
<ul style="display: none">
<li class="md-nav__item md-version" id="project.version">
<label class="md-nav__link" for="__version">
<i class="md-icon" title="Version">label_outline</i> 1.2.25
</label>
</li>
</ul>
</div>
</div>
</div>
<div class="md-sidebar md-sidebar--secondary" data-md-component="toc">
<div class="md-sidebar__scrollwrap">
<div class="md-sidebar__inner">
<nav class="md-nav md-nav--secondary">
<label class="md-nav__title" for="__toc">Table of contents</label>
<ul>
<li><a href="glossary.html#izumi-glossary" class="header">Izumi Glossary</a>
<ul>
<li><a href="glossary.html#izumi-specific-terms" class="header">Izumi-specific terms</a></li>
<li><a href="glossary.html#izumi-overloaded-terms" class="header">Izumi-overloaded terms</a></li>
<li><a href="glossary.html#terms-elaborated-by-izumi" class="header">Terms elaborated by Izumi</a></li>
</ul></li>
</ul>
</nav>
</div>
</div>
</div>
<div class="md-content">
<article class="md-content__inner md-typeset">
<div class="md-content__searchable">
<h1><a href="#izumi-glossary" name="izumi-glossary" class="anchor"><span class="anchor-link"></span></a>Izumi Glossary</h1>
<h2><a href="#izumi-specific-terms" name="izumi-specific-terms" class="anchor"><span class="anchor-link"></span></a>Izumi-specific terms</h2>
<p>Izumi introduces many concepts which are not common in other frameworks and libraries. We had to come up with some good and descriptive names for them:</p>
<ul>
<li><strong>multi-modal application</strong> – an application which support multiple <em>modes</em>. A multi-modal application can be soundly reconfigured by a command-line flag or a configuration flag. An example: an application with multiple persistence layer implementations, like a PostgreSQL persistence and a MongoDB one. DIStage provides you first-class support for multi-modality on both component and application level.</li>
<li><strong>multi-tenant application</strong>, <em>also</em> <strong>role-based application</strong> – an application which has multiple entrypoints (or <em>Roles</em>). When user launches a multi-tenant application, they may define which <em>Roles</em> they would like to launch and provide the respective command-line arguments, configuration sections, etc. An example: an OSGi container running several WAR applications.</li>
<li><strong>flexible monolith</strong> – a multi-modal multi-tenant application where each <em>Role</em> substitutes a microservice. <em>Flexible monoliths</em> can be deployed in both <em>microservice-oriented</em> manner and <em>monolith-oriented</em> manner. It’s typical for <em>flexible monoliths</em> to have <em>dummy implementations</em> of their <em>integration points</em> and their <em>transport layers</em>. <em>Flexible monoliths</em> (and <em>multi-tenant applications</em> in general) provide us a lot of additional deployment flexibility, increase computational density, and allow to run <em>product simulations</em>.</li>
<li><strong>dummy</strong>, <em>also</em> <strong>manual mock</strong>, <strong>fake</strong> – a handcrafted test implementation of an application <em>integration point</em>. Dummies are alike to <em>automatic mocks</em>, but they are not auto-generated. Dummies implement component interfaces, should follow all the good programming practices, never break encapsulation (like <em>automatic mocks</em> do) and provide a reasonably good simulation of the aspects important for particular domain. For example, a dummy implementation of a UDP transport layer might be able to simulate packet loss and packet reordering.</li>
<li><strong>integration point</strong> – an application component which runs outside of an application process. An application interacts with its integration points over network (or, in some cases, using various forms of host-local I/O). A microservice A interacting with another microservice B <em>has an integration point with microservice B</em>. A microservice, interacting with a third-party service through its API <em>has an integration point with that third-party service</em>.</li>
<li><strong>external integration point</strong> – an integration point a team has no ownership over. All the <em>integration points</em> with components, provided by third-party companies or projects, and teams, which cannot be involved into a productive discussion, are <em>external integration points</em>. Integrations between microservices are <em>internal integration points</em>, integrations with components developed by another team are <em>internal integration points</em> only if a discussion between the teams is possible. If we integrate with a PostgreSQL database, running on our infrastructure, — it should be considered an external integration point because we can’t alter its APIs and have to work around any issues instead of going the lengthy way of interacting with its developers or implementing custom patches. If we integrate with Stripe API – that’s an external integration point too. If we integrate with an internally developed microservice, but we cannot involve the team which holds ownership over it into a discussion, – that’s an external integration point too.</li>
<li><strong>evil integration point</strong> – an <em>external integration point</em> with a proprietary third-party service, which cannot be influenced by the application developers at all. An <em>evil integration point</em> cannot be launched in an isolated environment and requires connection to Internet to be interacted with. An <em>integration point</em> with a PostgreSQL database isn’t <em>evil</em> because we can launch and access it locally without having access to Internet. Frequently, <em>evil integration points</em> have no test APIs, are billed per-request, and, in worst cases, they can’t be safely accessed for testing purposes at all.</li>
<li><strong>integration check</strong> – a predicate which verifies that an <em>integration point</em> is available and functional. An application should fail fast if an <em>integration check</em> fails. A test should be ignored if an <em>integration check</em> fails.</li>
<li><strong>product simulation</strong> – a <em>multi-tenant application</em> launched with all its <em>integration points</em> substituted by <em>dummies</em>. This allows all the client teams and individual developers in these teams to quickly launch isolated local transient test environments when necessary, avoid long provisioning wait times and avoid any interference between developers working with the same test instances. Also, <em>simulation-oriented</em> workflow promotes good testing practices, like having self-contained fixtures for reproducible tests which would never rely on pre-provisioned state of a test environment.</li>
<li><strong>dual test tactic</strong>, <em>also</em> <strong>dual tests</strong> – an approach when developers run the same test suites twice – against <em>dummy</em> integration point implementations and <em>production</em> ones. Usually we do this for business logic which should be abstracted from all the integration-point specific details and for the interfaces of the integration points themselves. When <em>production integration points</em> are not available their tests should be skipped and never fail the test run. <em>Dual tests</em> simplify onboarding and promote clean design and good abstractions. All the important aspects of the integration points may be simulated in their respective dummies.</li>
<li><strong>scene</strong>, <em>also</em> <strong>environment</strong> – a full set of application integration points which are required to be available for an application or a test suite to run.</li>
<li><strong>managed scene</strong> – a <strong>scene</strong> which an application or a test suite may provision and clean up automatically. Usually <em>managed scenes</em> would be created by setting up transient docker containers.</li>
<li><strong>provided scene</strong> – a <strong>scene</strong> which an application or a test suite expects to be pre-provisioned an readily available when it starts.</li>
<li><strong>constructive test taxonomy</strong> – an improved test taxonomy, proposed by 7mind. Constructive Test Taxonomy replaces outdated “unit-functional-integration” classification with multi-dimensional weighted space and forms a reasonable mental framework helping to approach testing in more structured and rational manner. More details might be found <a href="https://blog.7mind.io/constructive-test-taxonomy.html">here</a>.</li>
</ul>
<h2><a href="#izumi-overloaded-terms" name="izumi-overloaded-terms" class="anchor"><span class="anchor-link"></span></a>Izumi-overloaded terms</h2>
<p>We have overloaded the following terms for the domain of dependency injection:</p>
<ul>
<li><strong>wiring definitions</strong> – the definitions of the components of an application and dependencies between them. Frequently <em>wiring definitions</em> are done with <em>direct wiring code</em> (direct constructor calls, variable initialization and parameter passing), or with one of three major <em>creational patterns</em>: <em>Singletons</em>, <em>Service Locators</em> and <em>Dependency Injection</em>. <em>Singletons</em> and <em>Service Locators</em> do not completely eliminate <em>direct wiring code</em>.</li>
<li><strong>wiring process</strong> – the process of execution of the <em>wiring definitions</em>.</li>
<li><strong>wiring problem</strong> – an engineering problem of finding a way of efficient and maintainable way to write <em>wiring definitions</em> and performing the <em>wiring process</em>. A source of multiple holy wars. For an external observer, a typical discussion on wiring problem strongly reminds a bunch of monkeys throwing whatever they have at each other.</li>
<li><strong>garbage-collection</strong>, <em>also</em> <strong>garbage-collecting DI</strong> – a process of hard exclusion of dependency declarations which are not required for current application configuration to run. A <em>garbage-collecting DI</em> requires a set of <em>garbage collection roots</em> (application entrypoints) in order to be able to <em>trace</em> required dependencies. It’s important to note that, while <em>lazy</em> dependency instantiation does provide similar capabilities, it’s less observable and cannot guarantee soundness of the wiring process. Thus <em>lazy</em> instantiation frequently leads to problems in run-time.</li>
</ul>
<p>Terms used by Izumi ——————-d</p>
<p>Also we use the following terms which have stable semantic but aren’t widely used in the domain of software design and engineering:</p>
<ul>
<li><strong>generative programming</strong>, <em>also</em> <strong>planning</strong>, <strong>staged programs</strong>, <strong>staged execution</strong> – a powerful generic approach to software design when program execution is separated into two phases. During <em>planning</em> phase, a program generates a “script” in some DSL, which addresses a goal to be achieved. During <em>interpretation</em> phase the program <em>interprets</em> the plan. When we apply <em>generative programming</em>, we want our DSL “scripts” to always be executable in finite time, be Turing-incomplete, have no support for conditional execution and have no support for unbounded loops. A <em>generative program</em> might oscillate between <em>planning</em> and <em>interpretation</em> phases and might reuse <em>interpretation</em> results in the next planning cycles.</li>
<li><strong>directed acyclic graph</strong>, <em>also</em> <strong>DAG</strong> – there is a good <a href="https://en.wikipedia.org/wiki/Directed_acyclic_graph">definition</a> on Wikipedia. It’s important to note, that <em>DAGs</em> are the best <em>natural</em> way to express <em>parallel</em> programs, thus they work perfectly as a native representation for any non-trivial <em>plans</em>. The downside of <em>DAGs</em> is the computational complexity of many important algorithms over them and lack of good tools and convenient metaphors to work with them. Most of the programs we write are <em>unnecessarily sequential</em> which won’t be a case if we use <em>DAGs</em> to describe them.</li>
<li><strong>compile-time reflection</strong> – type information which is preserved during compile time and does not require any support from the language runtime. In some sense almost any reflection is a compile-time reflection (e.g. Java type information is preserved during compile time). Though a true compile-time reflection would try to precompute what’s possible during compile-time and won’t require whole parts of the compiler to be available at run time. Without a preprocessor, only a language with strong macro capabilities can support compile-time reflection.</li>
<li><strong>test dependency memoization</strong> – sound sharing of test dependencies between tests in a test suite or a family of test suites. Good memoization should avoid any use of singletons, apply just-in-time cleanups, provide users with good control capabilities of what can and what cannot be shared and share dependencies transitively.</li>
<li><strong>shift left</strong> – a particular set of practices and mindset which assume that engineers should try to address the problems as early in the software development pipeline as possible. <em>Shift left</em> approach is based on a strong semi-empiric hypothesis saying that the total amount of resources spent on a particular issue would lower if it’s addressed earlier. Generally <em>shift left</em> approach always pays back.</li>
<li><strong>shift right</strong> – a particular set of mispractices and mindset allowing developers to postpone problem detection as much as they can. <em>Shift right</em> approach creates technical debt, forces the operations teams to do more job which can be easily avoided, and, frequently, turns users into alpha-testers.</li>
</ul>
<h2><a href="#terms-elaborated-by-izumi" name="terms-elaborated-by-izumi" class="anchor"><span class="anchor-link"></span></a>Terms elaborated by Izumi</h2>
<p>Also we use the following terms which are used widely but often improperly and having unstable semantic:</p>
<ul>
<li><strong>product</strong> – all the logical components of some software, solving particular business problem. Typically a <em>product</em> includes multiple <em>back-end</em> services (or microservices), various <em>client</em> applications (mobile, web, desktop), third-party supplied components managed by the company and external third-party service APIs.</li>
<li><strong>continuous integration</strong> – automatic testing of all integrations between <em>product</em> components, after each commit. That’s lot more than just running builds and tests of individual microservices after each commit. We want to make sure that the whole <em>product</em> works properly after each change. <em>Integration</em> should start as early as possible. IDL/RPC languages are <em>integration</em> tools. Static typers are <em>integration</em> tools. Formal proof assistants are <em>integration</em> tools. Deployment and orchestration systems are <em>integration</em> tools. Usually <em>monitoring</em> tools might be considered <em>integration tools</em> too. A <em>monitoring</em> tool which is not a part in the feedback loops with application developers shouldn’t be considered an <em>integration</em> tool.</li>
</ul>
</div>
<div>
<a href="https://github.com/7mind/izumi/tree/v1.2.25/doc/microsite/target/mdoc/glossary.md" title="Edit this page" class="md-source-file md-edit">
Edit this page
</a>
</div>
<div class="print-only">
<span class="md-source-file md-version">
1.2.25
</span>
</div>
</article>
</div>
</div>
</main>
<footer class="md-footer">
<div class="md-footer-nav">
<nav class="md-footer-nav__inner md-grid">
<a href="index.html" title="Izumi Project" class="md-flex md-footer-nav__link md-footer-nav__link--prev" rel="prev">
<div class="md-flex__cell md-flex__cell--shrink">
<i class="md-icon md-icon--arrow-back md-footer-nav__button"></i>
</div>
<div class="md-flex__cell md-flex__cell--stretch md-footer-nav__title">
<span class="md-flex__ellipsis">
<span class="md-footer-nav__direction">
Previous
</span>
Izumi Project
</span>
</div>
</a>
<a href="guidelines.html" title="Izumi Framework Best Practices" class="md-flex md-footer-nav__link md-footer-nav__link--next" rel="next">
<div class="md-flex__cell md-flex__cell--stretch md-footer-nav__title">
<span class="md-flex__ellipsis">
<span class="md-footer-nav__direction">
Next
</span>
Izumi Framework Best Practices
</span>
</div>
<div class="md-flex__cell md-flex__cell--shrink">
<i class="md-icon md-icon--arrow-forward md-footer-nav__button"></i>
</div>
</a>
</nav>
</div>
<div class="md-footer-meta md-typeset">
<div class="md-footer-meta__inner md-grid">
<div class="md-footer-copyright">
<div class="md-footer-copyright__highlight">
7mind.io
</div>
Powered by
<a href="https://github.com/lightbend/paradox">Paradox</a>
and
<a href="https://sbt.github.io/sbt-paradox-material-theme/">Paradox Material Theme</a>
</div>
</div>
</div>
</footer>
</div>
<script src="assets/javascripts/application.583bbe55.js"></script>
<script src="assets/javascripts/paradox-material-theme.js"></script>
<script>app.initialize({version:"0.17",url:{base:"."}})</script>
<script type="text/javascript" src="lib/prettify/prettify.js"></script>
<script type="text/javascript" src="lib/prettify/lang-scala.js"></script>
<script type="text/javascript">
document.addEventListener("DOMContentLoaded", function(event) {
window.prettyPrint && prettyPrint();
});
</script>
</body>
</html>