15
15
% \usepackage[mathletters]{ucs}
16
16
% \usepackage[utf8x]{inputenc}
17
17
\usepackage [utf8 ]{inputenc }
18
- \usepackage {pifont }
18
+ \usepackage {pifont }
19
19
\usepackage {newunicodechar }
20
20
\newunicodechar {✪}{\ding {74}}
21
21
47
47
48
48
\usepackage {tikz}
49
49
\usetikzlibrary {positioning}
50
- \graphicspath {{target/ media/}}
50
+ % \graphicspath {{media/}}
51
51
% ----------------------------------------------------------------------------------------
52
52
% TITLE PAGE
53
53
% ----------------------------------------------------------------------------------------
65
65
\begin {document }
66
66
67
67
\begin {VerbatimOut }{ex-scala-roles.tmp}
68
- @RoleId("testservice")
69
- class TestService[F[_] : Monad](http: HttpSrv[F])
68
+ @RoleId("testservice")
69
+ class TestService[F[_] : Monad](http: HttpSrv[F])
70
70
extends IzService {
71
71
override def start(): Unit = http.start()
72
72
override def stop(): Unit = http.stop()
@@ -145,9 +145,9 @@ \section{The problem: both Monolith and Microservice approaches are broken}
145
145
\begin {itemize }
146
146
\item \textit {Software components } are still in place -- in form of Services.
147
147
All the potential pitfails of component design apply to microservices,
148
- \item Many checks which may be done by your compiler in case of monolithic design have
149
- to be performed by integration test suites (in case you have them, it's hard to write),
150
- \item Many tasks are delegated to operations: in case of a monolith your dependency graph is being
148
+ \item Many checks which may be done by your compiler in case of monolithic design have
149
+ to be performed by integration test suites (in case you have them, it's hard to write),
150
+ \item Many tasks are delegated to operations: in case of a monolith your dependency graph is being
151
151
processed by your DI framework\footnotemark [1], in case of microservices it is\dots in worst case processed by people,
152
152
in best case requires an orchestration tool. But we don't have any single great tool yet,
153
153
\item An orchestration tool does \textit {exactly the same job } your DI framework may do. And lot more things.
@@ -166,7 +166,7 @@ \section{The solution: roles}
166
166
\item Let's choose which \textit {roles } we wish to assign to a before we start it,
167
167
\item Roles come from Classpath, may be discovered dynamically or statically,
168
168
\item It resembles Containers and OSGi,
169
- \item Containers have some disadvantages.
169
+ \item Containers have some disadvantages.
170
170
They provide you a lot so we get used to think that they are sluggish on startup.
171
171
Isolated classloaders are inconvenient. Dynamic DI is a nightmare,
172
172
\item Let's get rid of Dynamic DI. And let's keep isolation optional.
@@ -185,7 +185,7 @@ \section{The solution: roles}
185
185
Roles allow you to do \textbf {everything } you can do with microservices plus have additional benefits\footnotemark [1]:
186
186
\begin {itemize }
187
187
\item Higher Density makes Development Flows better: instant startup of any combination of roles,
188
- \item Higher Density makes Operations easier: any combination of roles for any container.
188
+ \item Higher Density makes Operations easier: any combination of roles for any container.
189
189
You don't need to start 5 containers to have 5 services with low load profile,
190
190
\item Smaller distribution size: Just one image, less traffic,
191
191
\item More static checks $ \Rightarrow $ higher reliability,
@@ -201,9 +201,9 @@ \section{The solution: roles}
201
201
\item Startup time. Do you remember Tomcat? Design matters\footnotemark [1],
202
202
\item Weaker isolation $ \Rightarrow $ more dangerous failures,
203
203
\item Dependency convergence. You may need isolated classloaders\footnotemark [2],
204
- \item Heterogenous systems: C\# , Scala and Go won't mix in a single process\footnotemark [3],
205
- \item Distributed communication between Roles: most likely you don't want it. Otherwise
206
- you need a mechanism similar to: distrubuted DI framework
204
+ \item Heterogenous systems: C\# , Scala and Go won't mix in a single process\footnotemark [3],
205
+ \item Distributed communication between Roles: most likely you don't want it. Otherwise
206
+ you need a mechanism similar to: distrubuted DI framework
207
207
built around \textit {Service Discovery } and \textit {Cluster State } concepts. See: \code {dOSGi},
208
208
\item You need to build a nice Continuous Delivery pipeline.
209
209
\end {itemize }
@@ -216,12 +216,12 @@ \section{The implementation: distage}
216
216
217
217
\begin {frame }
218
218
\begin {figure }
219
- \Huge
219
+ \Huge
220
220
\color {RubineRed} DISTAGE
221
221
\noindent
222
222
{\color {RubineRed} \rule {\linewidth }{1mm} }
223
223
\Large Next-gen Dependency Injection Framework for Scala
224
- \normalsize Generative, Modular, R✪les and Garbage Collection included
224
+ \normalsize Generative, Modular, R✪les and Garbage Collection included
225
225
\end {figure }
226
226
\end {frame }
227
227
@@ -230,7 +230,7 @@ \section{The implementation: distage}
230
230
\begin {itemize }
231
231
\item Next generation of DI.
232
232
\item Generative, built on PPER principle. Allows you to plan context provisioning, edit the plan, then execute it,
233
- \item Fully aware of Scala typesystem, allows you to fuse FP and OOP lot better than before,
233
+ \item Fully aware of Scala typesystem, allows you to fuse FP and OOP lot better than before,
234
234
\item Bundled Garbage Collector,
235
235
\item \textit {Bundled Roles mechanism } built as an extension. Cheap for developer because of Garbage Collection,
236
236
\item Bundled \code {typesafe-config} support built as an extension,
@@ -240,7 +240,7 @@ \section{The implementation: distage}
240
240
241
241
\begin {frame }
242
242
\frametitle {How may\footnotemark [1] it look like: Dynamic\footnotemark [2] loader example ?}
243
- \scalacode {target/ ex-scala-roles.tmp}
243
+ \scalacode {ex-scala-roles.tmp}
244
244
\footnotetext [1]{Roles API is not published yet. More details to follow.}
245
245
\footnotetext [2]{Static one is also available.}
246
246
\end {frame }
@@ -275,7 +275,7 @@ \section{The implementation: distage}
275
275
\item Idealingua: transport and codec agnostic gRPC alternative with rich modeling language,
276
276
\item LogStage: zero-cost logging framework,
277
277
\item \textit {Fusional Programming and Design } guidelines. We love both FP and OOP,
278
- \item \textit {Continous Delivery } guidelines for Role-based process,
278
+ \item \textit {Continous Delivery } guidelines for Role-based process,
279
279
\item \textit {Percept-Plan-Execute } Generative Programming approach, abstract machine and computational model.
280
280
Addresses Project Planning (see Operations Research). Examples: orchestration, build systems.
281
281
\end {itemize }
0 commit comments