January 24, 2025 • 49 mins
Welcome to another insightful episode of Elixir Mix, part of the Top End Devs podcast. In today’s conversation, our host Charles Max Wood and panelist Sasha Wolf welcome Ivan Rublev, a backend Elixir engineer with a particular focus on business domains like real estate and B2B.
Ivan dives deep into the Domo library—a project he started to address certain gaps he felt existed within Elixir’s type system. He explains how Domo provides meaningful errors by validating structures against type definitions both at compile-time and runtime. The discussion also covers the inspiration behind Domo, its practical applications, and performance considerations.
Moreover, Sasha and Ivan discuss potential use cases where Domo shines and some scenarios where it might not be the ideal tool. They also touch on domain-driven design principles and Ivan’s interest in seeing Domo deployed in large-scale systems with multiple microservices.
Don't miss it as they uncover the possibilities and limitations of Domo, its impact on compile times, and real-world testing scenarios. Plus, stay tuned till the end for some book recommendations and more details on how you can level up your development skills with Top End Devs.
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Ivan dives deep into the Domo library—a project he started to address certain gaps he felt existed within Elixir’s type system. He explains how Domo provides meaningful errors by validating structures against type definitions both at compile-time and runtime. The discussion also covers the inspiration behind Domo, its practical applications, and performance considerations.
Moreover, Sasha and Ivan discuss potential use cases where Domo shines and some scenarios where it might not be the ideal tool. They also touch on domain-driven design principles and Ivan’s interest in seeing Domo deployed in large-scale systems with multiple microservices.
Don't miss it as they uncover the possibilities and limitations of Domo, its impact on compile times, and real-world testing scenarios. Plus, stay tuned till the end for some book recommendations and more details on how you can level up your development skills with Top End Devs.
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hey everybody, and welcome to another episode of Alixer Mix.
Speaker 2 (00:10):
This week on our panel we have Sasha Wolf.
Speaker 3 (00:13):
Hello everybody, I'm.
Speaker 1 (00:14):
Charles Maxwood from devchat dot TV. And this week we
have a special guest, and that's Ivan Rubelog. Did I
get anywhere close to saying your name right?
Speaker 4 (00:23):
Yes, that's right. Hello, every bunny.
Speaker 1 (00:25):
Do you want to introduce yourself real quick? Let people
know who you are and why you're famous?
Speaker 4 (00:29):
Yeah? Sure, thanks to work for kind words. So, Hi,
I'm Ivan. I'm originally I'm from Russia, but for three
years we with my family live in Humburg, Germany. So
I'm software back at Elixir, engineer, working in business domains
real estate and currently in B two B business. Yeah,
(00:52):
so that's cool.
Speaker 1 (00:53):
And yeah, I was looking at this Domo library that
you wrote. I have to admit I'm I'm still green
when it comes to some of this stuff. So and
follow all of it. But do you want to give
us kind of the ten thousand view on what domo
is and what it does?
Speaker 3 (01:08):
Yeah?
Speaker 4 (01:08):
Sure, that started like about a year ago, and I
usually had the impressions that I miss something within Elixir
and when I look at the structure and especially type
definitions of the structure. Of course, there is a dialyzer
tool that helps us to check validity of the source
(01:31):
code program same time, it doesn't work at run time,
and vilizer is quite heavy too, to be honest. So
and I was missing these things. That's okay. Elixir is
dynamically type language, and on the other hand, the type definition,
maybe I can do something about that. And then pandemic
(01:53):
started and I've got some free time, and I just
kick it off. Made these libraries that basically validates the
structure against the type definition and return meaningful errors about
the fields. Okay, here you define that this field should
(02:14):
be a string, and you have some number in this
field in the structure. So these aims to keep the
state valid because many software errors comes from invalid state
in the memory, and structures looks like a good place
for keeping the state. So that was my thought, Okay,
(02:36):
let's make a tool that validates a state within the structure.
Speaker 3 (02:41):
Was prompted by like a concrete, like if use case
you had, like for example, at work, you had some
issues or what was just like an just an academic
idea at the beginning, and you were curious to try
somethings out.
Speaker 4 (02:53):
Well, yeah, it was mostly inspired by book The Main
Dream Design by Eric Evans and more. It was more
like in academic inspiration, let's say. And yeah, so I've
got this feelings that there are lots of trials and
terrors around. So we know that there are other libraries
(03:16):
like norm that aiming the validation and other attempts to
make to introduce types in Elixir to get these benefits
of checking and some time nothing what I meant before
suit mean well, and because of that I decided, okay,
(03:36):
maybe I should give it a try and do some
not full fledged type system or something, because Elixir is
not such kind of thing but a very little, tiny
specific library that does on the validation of the structures
and basically keeping invariants.
Speaker 3 (03:54):
Yeah.
Speaker 4 (03:55):
So, answering your question directly, no, it wasn't inspired by
any and create task at the office. So it was
more like general ideas that I would like to have
such a thing.
Speaker 3 (04:08):
And are you not using it in like any production scenarios?
I mean you said it comes from an academic background, sure,
but do you know that like anybody is using it
in production? Yeah?
Speaker 4 (04:17):
Well sure, so I checked it's with current real projects
that we have and it works well. So and it's
kind of at early stage, so of course it's in
development for about a year, but only a couple of
days ago I can say okay that final things were
(04:40):
fixed and now it can be widely adopted.
Speaker 3 (04:43):
Okay, Well, would you see like DOMO being used most
likely any specific use cases where you say, hey, that's
like a pretty good fit for DOMO where I saw
personal success and using it, Like when more people reach
for DOMO compared to something like for example, norm as
you mentioned earlier, because just to give them context for
listeners like NORMS, this data validation library where you specify
(05:06):
schemas like in code, like it doesn't use the type specs,
but like you can basically use functions and stuff from
norm to say okay, the data should conform to this
schema and mean demo that uses the typespecs. So when
would you say, is like it's a scenario where somebody
would like to use DOMO any specific.
Speaker 4 (05:27):
Yeah, sure, that's an amazing question. Thanks a lot. So
there is another component in DOMO. It's that I haven't
mentioned before. So it it's not only validating the data
against the type definition TYPESPEC, but it also has these
pre condition functions attached to the type, so meaning that
(05:50):
for example, if you have the type definition for a
field of your structure, you can also add a pre
condition function to this type that the normal library would
call and if this function returns okay, then it would
consider that the value is not only of that type,
but it's also of a for example, right format that
(06:11):
you expect. So and saying that I can point out
to the concrete scenario. So for example, if you know
that you have an identifier in your system for your order.
For example, let's say you build e commerce system right
some websites the e commerce website, and you know that
(06:33):
in your system this identifiers have specific format for example
AA letter in the beginning and some numbers afterwards. You
can just define the type okay my ideas of string
type and add a precondition function to this, so saying
that the value should begins with A and then using
(06:54):
this type across any structures in your application. You would
have these automatically validated whenever the structure is created with
a construction function added by dormal library, and the DOMO
will guarantee you that you will have valid values for
this id type across your application and that in this
(07:19):
regards the state would be valid. So yeah, this is
one of scenarios, and it can go even more. Like
we can go further. We can define with normal library,
it's possible to define the precondition for the struct type.
You know, when you write this type T for your structure,
(07:40):
and you can say, okay, for this type T, the
miprecondition function will be this one you name it. And
let's say you would like to have some relations check
between fields of this structure, saying that if this is
the order structure for e commerce website, that you have
some allowed amount or of the order in terms of money,
(08:03):
and you would like to have the sum of all
line items in this order to be not higher than
this given amount. So this precondition function attached to the
type of the structure can validate that and give some
meaningful error bag that okay, you should have the summary
(08:26):
amount less than a lot. And that's as a scenario.
When DOMO gives you a consistency of your structure or
more higher level let's say so so it allows to
follow business rules of the system implementing. So this is
(08:46):
the second scenario.
Speaker 3 (08:48):
So that's I guess that could make sense to use Thermo.
For example, at the edges of my system. When I
say I have a Phoenix API, for example, getting some
jacon in and I want to verify that the user
actually like the information the user gave me, conforms to
a certain data schema to like to the to the
(09:10):
requests objects I expect, and that I then can use
that to forward it to the rest of my application,
being sure that, Yeah, as you said, preconditions are met.
Is that right? Is that like a scenario where you
would say DOMO is applicable.
Speaker 4 (09:25):
Yes, is one of scenarios where DOMO can can play
and it's like equivalent to what can be implemented with norm. Right,
So you can define the schema and validate the adjacent
on the let's say boundary of your application, and then
be sure that the data that you operate on is valid.
(09:47):
And yeah, there's definitely one of the possible scenarios. On
the other hand, there are other scenarios. It's when you
work with a pure core having only pure functions and
structures in it, and you would like to follow to
make it follow some business rules that should be executed
(10:08):
in your system. So, for example, it's from the domain
domain driven design framework. Right, So when you have a
set of business rules, you can define them with normal
precondition functions page to the type and have this business
rule fulfilled everywhere you use these values of these type
(10:29):
in structures. So, for example, as I mentioned this before
with order, right, so you can have the order structure
in your core and have these values dependency between items
of this order and allowed amount the same invariants, same
(10:52):
kind of invariants may be for other structures that participate
in the business logic of your application.
Speaker 2 (11:02):
Right.
Speaker 4 (11:03):
And instead of the okay, this can be compared that
you can say, hey, I can write this in any module,
write this verification that my structure have a valid number
of items and that there's some is not exceeding the
allowed amount for this order. And the interesting part here
(11:26):
is that if you do this with DOMO, by using
this precondition function attached to the type, you can have
this validation not only in this structure but in any
other kind of structures using this type. So it goes
like automatically in these places and you don't need to
(11:47):
think twice about if I forgot any validations or you know,
any parts of checking my structures in regards to business
logic of the application, and it even can go further
across the application boundaries. For example, if you have several
micro services that is very common nowadays, you may have
(12:10):
hundreds of them, and if, for example, you share these
type definition and pre condition functions in some model files
across these several applications, due to the normal library, you
can be sure that this would be checked and full filled.
These either these validations for boundary situation or for business
(12:38):
logic in the core.
Speaker 3 (12:40):
When you say sharing the model fied, I assume like
in the sense of like a private tax package or
what exactly are you thinking of?
Speaker 4 (12:48):
Oh, yeah, sure, it can be a hex package. On
the other hand, it's usually starts like a little you
just have several modules like share models that you can
check out in various repels. So the techniques are various
(13:08):
for that. So for example, you can have shared Git
repository with this model and you can edit as submodules
to other Git repositors or you know, just check it.
Speaker 3 (13:22):
But basically you lose like some kind of mechanism to
like get the code into your micro services, be through
x package or like through okay, yeah, that's right, okay,
And I was just thinking because there are also solutions
such as protobaf or others I can think of right now,
which like also follow this idea of having like a
(13:42):
model definition which then can be used to generate some code.
But that's like more agnostic, not really specific to to
to elix here.
Speaker 4 (13:50):
Yeah, it's very interesting. Yes, the true protobuffs are very
good to have the intercommunication be validated time. It is
impossible to put function protobize definition.
Speaker 3 (14:06):
Which with some might argue is a good thing.
Speaker 4 (14:09):
At some scenario.
Speaker 3 (14:10):
Yes.
Speaker 4 (14:11):
On the other hand, with dormo, you can do that
and do more precise validation like Okay, if that if
these conditions that mad, then these values should be as expected.
On the other hand, if I have another value in
my structure set to this value, then this should be
(14:33):
should be another duly expected. So you can imagine that
it can be quite complex interdependencies between fields of even
one structure, not saying about some nested structures that usually
now can be seen in modern applications.
Speaker 3 (14:50):
Okay, to get back to something you said earlier, So
you said that you can reuse like type definitions and
preconditions that attached with that type. So if for example,
I like to get back into an example, you said, like, yeah,
I've a certain identifier, like an order identifier. I could
just specify this type in some module, attach some preconditions
(15:12):
to it, and then use it across my application and
wherever I use DOMO. Basically, I assume then that would
basically reuse these preconditions attached to my order identifier type.
Is that right? Did I get that right? Yeah? That's right?
To Okay, it looks like that. Okay, that's nice. I
guess DOMO boils a bit down to like saying to
(15:34):
avoid a bit of a petition, right, because for example,
if you look at EMO, you acto schemas like like
for at least from my experience, you tend to have
this scenario where you say, okay, this is like my
schema and these my fields. But then it's also helpful
to to have type definition on tops so that you
(15:55):
then just for documentation purposes, right ba, I say okay,
this is like the type of this, and these are
like the sphere as an integer and this field as
a string. And then you also have on the bottom,
like maybe some some ECTO change set validations where they say, okay,
I use the idea needs to start with an AID
or my other ID needs to start with an ASOL.
So I guess DOMO goes a bit in that direction
(16:17):
where they say, okay, I don't want to maintain like
multiple definitions of the same information basically.
Speaker 4 (16:23):
Right true true, that's it. And moreover, Domo has support
of ACTO. So if you have these schema defined, and
you have these type defined into the schema, you can
call the change set in the Dormo library and the
function that's named validate type, and DOMO will automatically validate
(16:47):
changes in the Acto change set for you according to
the type you defined. So this is already supported and
quite convenient.
Speaker 3 (16:57):
That's nice. I assume that, like to actually reuse a
type for example, such as the order ID, I have
to like use Domo in that place, right, I can't
just use any remote type. I mean that, like, how
does that work? When you say okay, it's like a
string T, then like we probably have some code written
(17:17):
which says, okay, if it's a string, then doing this
and that check. But if I just say I have
like this module over there, which like doesn't use domo
at all, but it specifies my type, I don't know which,
just say like it's a map with like certain certain keys,
and the keys need to be of a certain value.
Is that like something DOMO can can handle them? Or
(17:39):
how exactly can I can I imagine this to work?
Speaker 4 (17:42):
Yeah?
Speaker 3 (17:42):
Like where are the boundaries? Basically like why does it break?
Speaker 4 (17:45):
Okay, so three key questions, so where it's break? Well,
I can say that that's a very good example. And
it was a quite long year. But then here so
I had the time to resolve this and it was
successfully completed. So how DOMA works. If you have remote
type is within some structure or other module that's not
(18:10):
using DOMA at all, library automatically take this type into
validation because more has is shipped with compiler. So when
you add library to the project, it has two pass compilation.
(18:30):
First pass is by alixer and second past of the
compilation is by DOMA compiler that just do the job
by getting all the type definitions from remote modules and
putting them in place where the validation should be performed.
So and moreover, if you change remote type, for example,
you compile your project and you change one of the
(18:53):
keys in this map you mentioned in the remote module,
I mean type definition of the key and you can
again the DOMO will notice that and recompile the module
where you use is remote map definition.
Speaker 3 (19:08):
So automatically as signs that compiled time dependency to the remote.
Speaker 4 (19:14):
Model, it tracks dependence in between types in your application
and recompiles appropriately.
Speaker 3 (19:20):
I assume that this can have a hit on compilation
times because I mean, if you look at what the
Alexi core team and the Phoenix core team has been
doing in the past few months, they very much try
to reduce this kind of like compile time compilation compilation
links between modules which can SUI times. So I assume
(19:41):
that at least like a trade off of using domo
in that fashion is probably that it might impact your
compiled times.
Speaker 4 (19:47):
Right, yeah, sure when you comes at price, so definitely
it would increase compilation times. In synthetic tests it was
about maybe twenty percent of increase compilation time. And of
course during the run time it's additional sipute cycles that
are spent on the validation of the data you've got.
Speaker 3 (20:11):
I mean, that's your idea, right.
Speaker 4 (20:15):
That's true. Yeah. At the same time, I can say
that there is a heavy optimization implemented yet for the
dependency checks it just works. I can say that during
the compilation time, Dormo relies to the pattern matching a lot,
and at least for the part when you have this
(20:38):
validation at run time of your values. It's working on
already optimized code optimized by Elixir and a lung compilers.
Because of pattern matches that automatically generated by Domo, you
can have quite a good performance. Yeah. If you you know,
when we talk about code generation, that definitely happens here
(21:03):
with the dormal library. It's always a question mark, Okay,
what this library generates and how it works in my application,
So you can ask this question at some point in time.
And interesting enough that Domo rights the source code of
this validation into the build folder. So if you add
(21:27):
the type definition to your structure and say use dormo there,
then in underscore build folder you would have a Domo
generated called subfolder where you can see the old source
code that is used to do these run time validations.
So it's yeah, then used as a compilation source or
(21:48):
is it just like for the user's benefit, Well, it's
used as compilation source. The same time, if you change it,
it wouldn't affect anything because it would be overwritten during
the next company, so you can read it, but you
can't affect it much. This add this additional confidence about
(22:09):
what's going on when you call this function validate type
on your structure or constructor function or if you do
a reidate type in ECTO schema.
Speaker 3 (22:21):
Okay, I guess the question which for some people might
have like how readable is this code because that code
generation tends to sometimes produce code which is like a
bit not so nice on the ice to say to
phrase it like that.
Speaker 4 (22:36):
Yeah, true, there is a four matter run during the
generation of this code, and it's quite readable and quite simple.
So worse, the more fields in your structure you have,
the longer would be the output and the source code file.
Speaker 3 (22:57):
Same time.
Speaker 4 (22:58):
It's quite straightforward there too, same in functions there that
you just can read and say, okay, here is the validation,
here is the pattern matching. So it's quite simple.
Speaker 3 (23:10):
So that means that like domo generates like an additional
module or what which is then used FORUL for type checking.
Speaker 4 (23:17):
Yeah, okay, okay, what happens when you use domo at
minimum level? You can just add use domo into your
struct module, right, and then dormo generates a submodule that
is called type ensure. So let's say your module named
(23:37):
car and after DOMA works, you have also in addition
car dot type insure and inside of this type ensure
all validation happened and how it works in regards to
your original car structure. DOMO adds functions to the car
(23:57):
structure as well. It's a new function that is constructor
function for the structure and validate type function that is
for validation of existing instance. So there are also a
couple of other functions like typed fields and required fields
(24:19):
that returns the list of the fields of your structure
that has not new types. Let's say, so that's useful
in actual change that. So the first two new and
validate type functions they just facate for type insure module.
So when you call car dot new and keywould leads
(24:43):
to these fields and values for these fields, the new
function bypasses that after some checks to type insure module
type insure module, do pattern matches validate the all types
of the values is as expected, then run pre condition
functions associated with these types, checking okay the format of
(25:06):
these values is good, all invariants have full field, and
then returns back to the call site so and it
returns the constructor the structure basically, So that's how you
can be sure that at the time of the call,
when you get this structure back, it's valid structure according
(25:26):
to the type and pre conditions defined. Then if you
modify the structure, for example, alter field of the car,
then you can call again the validate type function with
this modified instance, and the validate type function would do
the same trip to the type insurance back, giving you
(25:48):
the answer is it still okay structure matching the type
and preconditions or no, you have this field incorrect because
of this and that. So that's how it works basically.
Speaker 3 (26:00):
Okay, And what happened if I, like, have my car
struck and I have said use domo and then instead
of that, I just define a module which it's called
type insure. What would happened then, like, because then I
have a name class.
Speaker 4 (26:15):
Right, yeah, sure, the behavior would be the same if
if you define type insure twice. So you can do
this by hand and there are no any you know,
hidden things behind that. It's just simply a generation of
the Elixir source code and compiling it with the LEIKXIR
(26:36):
two times.
Speaker 3 (26:37):
So okay, I guess, like on one thing DOMO could
do there is like generating like it in a different
name space, right, like could for example generated in domo
dot type insure dot name of a module, because then,
I mean people could then still define a module which
is called that way. But if they basically messed with
like another uplic another libraries name space, it's like they
(26:59):
all fault.
Speaker 4 (27:00):
Right, Yeah, well this nice idea. Let's see what can
be done in this regard. And there is another scenario
how to start using domo. You may not even use
all the functions that DOMA adds to your structure. For example,
let's say we have the car, and if you even
(27:21):
write use domo inside the car, you already get some benefits.
What I mean, during the compilation time, it would check
the default values of your car structure, these values that
you usually define with death struck, and during the compilation time,
DOMO already would validate if the default value specified conforms
(27:42):
to the type and pre conditions, and if it's not,
it would say compile error. So you have these values
not matching, and yeah, that's that's interesting. Even more, if
for example, you have some connected structure like one structure
nested in another and you let's say car, and what
(28:07):
can be inside of the car. Let's say some some seat,
yeah seat, and you know these seats with leather or
other materials some, So we can imagine that for the
seat it can be a separate structure defining all the
parameters of the sea.
Speaker 3 (28:26):
I want to cut a blue seed and orange seed
and two yellow seeds. Yeah.
Speaker 4 (28:31):
For example, So if you give the default value of
seats to the car saying okay, I would like orange
seat and blue and put it into the depths truct
of the car. And if you use a dorma function
like seat dot new right, so it would check during
(28:53):
the compilation time the validity of this default value. And if,
for example, you put into the sea dot new some
invalid value by mistake instead of orange stream orange atom,
and it wouldn't manage the seed type. DOMO will also
(29:13):
give you back the compilation error saying okay. So you're
constructing the thing that is not mentioned the type as
a default value. And this works even in function calls.
So if you pass this default value with domo dot
new to the function heater definition, it will also be
checked during the compile time. So how DOMO does that.
(29:37):
It basically tracks the calls to dot new that is
generated by the DOMA obviously, and then during the compilation
pass it just make validation of these fields.
Speaker 3 (29:55):
Okay, that some timeful. I mean I've not a had
a scenario. Well default values were as complex where I said, okay,
I want to verify about it. Don't make the mistake here.
But if you get for free, that's what's nice, I guess.
Speaker 4 (30:07):
Yeah, And you know the software is constantly evolving, so
and it may happen then for example, at some point
in time you change the type of your structure and
all humans, so you can forget to change the default value, right,
and that potentially could lead to mistakes, and DORMO play
(30:31):
safe here, so it gives you appropriate feedback very early
at compile time.
Speaker 3 (30:37):
Charles, do you have any questions I've been talking.
Speaker 1 (30:38):
About it's about to chime in. I'm more curious about
like testing and performance. Yeah, how does this affect any
of that?
Speaker 4 (30:47):
Well, did some synthetic tests, so you can find the
detailed results in the read me to the library. What
I've observed it's one point twenty six times slower than
without library at run time. So it looks like around
(31:08):
thirty PAF and slower work. Same time you get valid
state of your application price.
Speaker 3 (31:19):
I guess it makes sense when you're like, I wouldn't
probably use it in a scenario where I will already
know that certain data is valid, because then I mean,
way check in the first place. Right, But if you
are in a scenario they say, okay, I I'm not
uncertain that the data which I'm getting here is conforming
to what I expected to be, then sure why not?
I mean you can even write now validation at all,
(31:41):
but which works if the users friendly enough to give
you a right data. If they don't, then it's going
to go boom. Right, yeah, yes, and.
Speaker 4 (31:52):
It's not only user sometimes the business logic can be
quite sophisticated. And if of course we have you test
and cover all not happy but unhappy path as well.
And same time, it can be that you can forget
are one or another combination of all parameters and adding
(32:15):
these validated against the type can add additional let's say,
it can give you additional insurance that you will have
valid state of your application.
Speaker 3 (32:29):
One thing. As Charles asked about testing, for example, I say, like,
I let's go back to that example from earlier with
the idea it's a swing, it's supposed to start with
a letter A, Like I mean, how would I then
go roup fighting a test for that? Like? Because I mean,
as you mentioned earlier, this is like a reusable type, right,
like a type I can use the multiple places I
(32:50):
can see, like how I would use reuse like the
destruct how we test the struct definitions of dormal because
then I can just call dot new right if it
raises an error, it turns an error toroogle, then then
it can failed successful. Is that like an option to say, Okay,
I have this type over here, and now I would
(33:11):
write to write some tests because I also have some
preconditions attached to that, and I want to make sure
that I didn't make a mistake while writing these preconditions, right, yeah,
so like some option to do that? Yeah?
Speaker 4 (33:22):
So I remember one talk in regards to that from
camp back about what is right size of unit that
is under the test. And I can say that, for example,
in the test, you can define as trugged for test
purposes that uses the type definition and be sure that
(33:47):
these preconditions associated with this type working properly by calling
these you know, test struck Nott new Okay, so this
would be what what does it? It means that you
would ast the interface and not internal implementation. Right, So
the publicly available interface provided by domo is this new
(34:11):
function and validate type function.
Speaker 3 (34:14):
Okay, but there's no API where I can say, hey, Domo,
I'd like to use this type over there, and please
check it, like check piece values I give you, and
now tell me if that conforms, like basically probably similar
to what norm does. Right, there's like no altitude that
I guess they always have to go through, like the
(34:36):
motions of like specifying a struct and then I mean
either using a struct I already find or specifying one
if I want to, for example, test the remote type.
Speaker 4 (34:45):
Yeah, well technically you can, so you can call type
ensure modules that Domo generates for these kind of things.
So there is a public function that is called. And
on the other hand, it's a question where your interface is.
Speaker 3 (35:02):
So if yeah, I guess we're now entering some a
certain level of philosophical conversation like what is a unit test?
What is the purpose of life? Yeah?
Speaker 4 (35:18):
Well, it's possible to do the unit testing with either
new function or with calling typing. Sure, model directly.
Speaker 3 (35:26):
Yeah, I can see why I call it. Type into
a model directly is something which probably should not be encouraged.
From what you told me, it feels like it's more
of a private API think, so yeah, yeah, better not
go there, I guess.
Speaker 4 (35:42):
So it's a quite simple thing. On the other hand,
if you would like to express business rooms, it's another
possible way to do that. So for me, it's also
always a question to keep every scene in place, especially
when some parts of the business rules are shared across
(36:05):
various parts of the application or even across several micro services.
Speaker 3 (36:11):
So abe bit of a hard question now when it's
like a scenario where you would not use DOMO, So
it fe like, say, okay, this is just not the
right tool for job when people may be reach for
something else or write custom code.
Speaker 4 (36:26):
Yeah, so I think every tool should be used for
appropriate problem. And if it's high performances application like maybe cryptocurrency,
where you have heavy calculations and every microsecond is on count,
(36:47):
then maybe it's not right a problem to use DOMO for.
On the other hand, if you have a business application
like e commerce, website or lots of business logic that
should work correctly and you can spend some time to
get the answer to provide the user, then dom could
(37:08):
be a good choice.
Speaker 3 (37:10):
Okay, So what is any anything you see on the
horizon for for like DOMO, any next steps you'd like
to take, anything which is missing and you'd like to
tackle what comes next.
Speaker 4 (37:22):
Yeah, So I'm looking forward for some large system to
give this library a try, because all applications I work
with of the average size, so it's kind of web
shops or such kind of websites, and I'm really interested
(37:46):
to see how it would work on one hundred micro
services setups, so where you have lots of components that
should be play that should play nice together too, and
very welcome for any such kind of collaborations to run
(38:07):
a test on such larger than average systems. Other plans
are to add additional type checks to dormo, Like it
checks all the standard types, but that are defined in
the Elixir documentation. At the same time, it doesn't check
(38:28):
types that referencing itself yet, so I mean crimary trees,
recursive types, right, So I'd like to add support for that.
It's not such usual scenario in business applications, but I
intend to support this.
Speaker 3 (38:48):
I've done this when I wanted to have a representation
of like adjacent of like an arbitrary adjacent because then
you can say, okay, like adjacent value can be like
a list, that can be an integer, that can be
a stream, but it can also gain be an object
with in turn users values which then by definition, so yeah,
and I can see why why that we useful? Yeah,
(39:10):
and for many for many such kinds of definitions. DOMO
is working. Now if you say, okay, this is part
of Jason, and inside of this part of Jason, it
would be the same part of Jason, so you know,
recursively and DOMO wouldn't work.
Speaker 4 (39:25):
So yeah, what happens when you do that? It doesn't
raise an error? Yeah, yeah, it rises an error that
is not supported yet. Okay, so no binary trees for now, sorry,
so with leaves and branches, but it's it's a question
of some further work on that.
Speaker 3 (39:45):
It's also mean it might just then explode the runtime complexity, right,
because if you have a very large binarit tree, yes,
but sure, that's that's always an issue.
Speaker 4 (39:57):
Sure, And for example, if you have very long list
that can be in your structure, it's also can be
an issue. So This is natural limitation for DOMO because
it validates each list tallemands for conformance to the type,
so it should be considered as well.
Speaker 3 (40:18):
It's like some some smart instead of DOMO, for example,
when you say I've got a list of any, because
then there has no reason to check each element of
a list if you say it can be anything. Is
something like that DOMO or yeah.
Speaker 4 (40:33):
Well in regards to Liz, no, Well, it's so there
are such kind of optimizations. If you say that some
field is any, for example, it wouldn't be checked, so
it would be a shortcut like okay, SVLID and lists
should be supported as well with any type inside. Yeah,
(40:56):
so I intend to look up for other such kind
of optimitysations too.
Speaker 3 (41:01):
But I guess that goes into what you said earlier,
like to see it use the larger scale, and then
these kinds of issues and optimization things are going to
crop up naturally because you push the library to its limits. Yeah,
that's true. Okay, child to you if anything left because
I'm trying out.
Speaker 1 (41:19):
I think you pretty much covered it. Yeah, a couple
of the questions I was going to ask and when
you cover them.
Speaker 4 (41:24):
So so it may seems a bit weird from the
first point of view, right, So attaching pre conditions to
types and sharing here in there, but all the other
And it's another view on the same problem of having
valid state and fulfiling invariants in your models.
Speaker 2 (41:48):
So all right, well, I'm gonna push your Swart picks.
Speaker 1 (41:51):
You have a conversation about stuff that we like before
we do that, though, yvon if people want to follow
you on social media connect how do they do that?
Speaker 4 (42:01):
You can follow me on githab My username is Ivan
rublev and you can follow me on Twitter. User name
is Levy Brown. Maybe I should write it somewhere folks,
and you can add it to the description of the podcast.
Speaker 3 (42:17):
Yeah, yeah, we'll do that.
Speaker 1 (42:18):
Yeah, absolutely, yeah, I just put it in the chat.
Well all right, well let's go ahead and do the picks, Sasha,
Do you have some picks for us?
Speaker 3 (42:26):
Yes, And it's actually related to what we talked about,
because I mean even mentioned that he A lot of
these ideas are based on the main driven design by
Evan True. I forgot his last name, Evan Evans, Eric Evans, Yeah, Eric,
that was And there's also another book not from Eric Evans,
but from from Scott Blushing and that's called the main
(42:48):
Modeling Made Functional. Yeah, that's an amazing book. Yeah, it's
very nice. Arguably it's probably the best book I've read
it on the winderin design. It's also relatively short, especially
compared to Eric Evans book, which is not short.
Speaker 2 (43:03):
And we should see if we get Eric on we
had him on Ruby Road for a long time ago.
Speaker 3 (43:09):
Nice. Wow, yeah, that would be pretty cool, to be honest,
maybe you could also get Scott Blushing. Of all, he's
not an elixir of death. But yeah, just to get
back to the pic. So the book is called domin
Modeling Made Functional, and it's it's actually a nice introduction
into both like in the domainder design and also functional programming.
He's using f sharp there, and he's like talking a
lot about how to use the type system to basically
(43:30):
help you restricting and like restricting things to what they
should be to like basically avoid in that state already
on the type system level, which plays a bit in
what we talked about today, because I mean demo helps
with like using the type definitions and forcing those. And yeah,
it's like a really really nice book. It's well written,
(43:52):
it's it didn't really bore me to death text books
which I just stopped reading at a certain point. And
if anybody is interested in my demander of design is
into some function programming and types, then I can really
wold hotly recommend.
Speaker 2 (44:05):
This book awesome. I'm going to throw out a couple
of picks.
Speaker 1 (44:08):
The book I'm reading right now is I'm still in
the middle of a Rhythm of War by Brandon Sanderson.
Really enjoying that picture book fantasy book. I have another pick,
but I'm kind of saving it for last. There was
something else we're going to pick, and I can't remember.
I guess I'll just go to this last one because
I'm excited about it. So I've been doing a whole
bunch of work lately around the idea of top end devs.
(44:30):
You all, if you listen to dev chat dot tv
and are you subscribe to the mailing list and stuff
like that, you're going to start seeing a whole lot
more stuff branded with top end devs instead of dev
chat dot tv, because we're kind of moving everything over
to that, mainly because I want to communicate to people that, hey, look,
if you put in some effort. We talked a lot
about this last week with Audi. Audi and I talked
(44:52):
about this, but you can take your career wherever you
want it, and I am committed to that idea, and
so I want to because devchat dot tv doesn't dev
chat doesn't, it doesn't really mean anything.
Speaker 3 (45:04):
You know.
Speaker 1 (45:05):
The idea was is, Hey, we talked about dev right,
but this is kind of more of a higher idea
and aspirational idea.
Speaker 2 (45:11):
One of the things that I'm doing.
Speaker 1 (45:12):
And I can't remember if I brought this up last time,
and so I'm going to just throw it out here
so you all can show up if you need it.
But one of the things that I've really picked up
lately is is the coaching.
Speaker 2 (45:23):
Right.
Speaker 1 (45:23):
I've just loved helping people figure out, Hey, what do
I do next, What do we need to learn, what
do I need to work on to grow into what
I want what I want to be. And as I've
been doing that, it just it just fires me up.
I mean, I had a conversation with somebody on Friday,
and you know, he's trying to figure out where to
(45:44):
go next, right, and we talked about all kinds of stuff,
and at the end of the call, you know it's like, hey,
you know, go do this stuff. Let's talk in a
couple of weeks, right, and holy cow is just seeing
the potential of what he can do and the power
behind what he can accomplish.
Speaker 2 (46:00):
It just gets me going, right.
Speaker 1 (46:02):
And there are some things that everybody can do, and
then there are some things that, as we get into
the particulars of your situation, you can do, right. And
that's kind of the difference I guess between like the
course and coaching, or training and coaching. And so what
I'm doing is I'm kind of splitting the difference between both.
And so I'm using Zoom's webinar system. But it's not
a webinar, right. Webinar is I give you half the
(46:23):
information that's useful, leave you hanging, and then give you
a sales pitch. I'm not doing any of that crap. Okay,
that's I'm not doing a webinar. But I am going
to do training. So I'm gonna do like ten or
fifteen minutes of training and then for then the rest
of the hour hour and a half that I have,
I'm planning on doing this Wednesdays around noon mountain time.
I'm just gonna take questions, okay, and not take questions
(46:46):
in the sense of you know, what what what? How
do how do strings work in elixir?
Speaker 3 (46:51):
You?
Speaker 1 (46:51):
No, it's not that kind of stuff, right if I
if you have that question and I can answer it,
you can ask it, right, and I'll try and answer it.
Speaker 2 (46:58):
But what I'm really looking to dive into is, hey,
I've got this far.
Speaker 1 (47:03):
In my career, or hey, I'm trying to figure this
stuff out, or hey, i've got this situation at work,
or I'm trying to find a job and I'm not
getting interviews, or things are going really well, but I
feel like I could do more.
Speaker 2 (47:14):
What should I be doing next? And then we'll actually
talk through your situation, right, talk through where you're at,
and figure out where things should go.
Speaker 3 (47:22):
Right.
Speaker 2 (47:22):
So it's going to be almost more coaching than Q
and A. But we'll just do it until we run
out of time, run out of questions, whatever, right, And
I really just want to help people out, So it's
totally free, right, no commitment, no whatever. I'm not going
to do a sales pitch right and try and sell
you on coaching, nothing like that.
Speaker 3 (47:43):
Right.
Speaker 1 (47:43):
I am offering paid coaching, but I'm not gonna try
and sell anybody on that on these calls. Right, it's
completely free, completely you know whatever. So all you have
to do is just go to dev chat dot TV
slash level up. I think you have to put your
email address in so that the Zoom system can send
you the link to the webinar software and then from
there you're in, right, And yeah, just show up, jump
(48:07):
on the call, and we'll answer as many questions as
you want. And if we don't get to you, then
show up the next week, right, because we're going to
do it every week. And yeah, I'm really looking forward
to helping some folks out. Like I said, this is
the stuff that really just makes me feel like I'm
making a difference myself, right, and then yeah, you know,
(48:28):
if it turns into a kind of a deeper relationship
and we wind up doing coaching, than great. And if
I kind of get you there in twenty minutes, then great.
Then you got there in twenty minutes, and you can
come back when you get stuck again or you need
more guidance. All right, So that's kind of what I'm
looking at, and I'm really hoping that I can help
some fokes out.
Speaker 2 (48:46):
So dev chat, not TV slash level up, that's my
evon what are your picks?
Speaker 4 (48:50):
Okay, my peak for today and his book called micro
Services in Auction by Morgan Bruce and Paul Opereira. It's
very nice and laconic book about building micro services the
right way to Yeah, you can recommend it.
Speaker 2 (49:08):
Awesome. All right, Well we're gonna go ahead and wrap up.
Thanks for coming. This was fun.
Speaker 4 (49:12):
Thanks a lot, folks. It was very nice discussion about
types and the library. Thanks for having me today.
Speaker 3 (49:20):
If you fear interested in types like, check out our
episode with the Gleam of Lewis. Oh yeah, that's fun too, Yes, yes,
Gleam is very nice. Usually very nice too. We had
two weeks ago on the show. That was pretty cool.
Speaker 2 (49:33):
Yeah, louis cool.
Speaker 3 (49:35):
Good stuff.
Speaker 2 (49:35):
All right, Well till next time, folks. Next up,
Hey everybody, and welcome to another episode of Alixer Mix.
Speaker 2 (00:10):
This week on our panel we have Sasha Wolf.
Speaker 3 (00:13):
Hello everybody, I'm.
Speaker 1 (00:14):
Charles Maxwood from devchat dot TV. And this week we
have a special guest, and that's Ivan Rubelog. Did I
get anywhere close to saying your name right?
Speaker 4 (00:23):
Yes, that's right. Hello, every bunny.
Speaker 1 (00:25):
Do you want to introduce yourself real quick? Let people
know who you are and why you're famous?
Speaker 4 (00:29):
Yeah? Sure, thanks to work for kind words. So, Hi,
I'm Ivan. I'm originally I'm from Russia, but for three
years we with my family live in Humburg, Germany. So
I'm software back at Elixir, engineer, working in business domains
real estate and currently in B two B business. Yeah,
(00:52):
so that's cool.
Speaker 1 (00:53):
And yeah, I was looking at this Domo library that
you wrote. I have to admit I'm I'm still green
when it comes to some of this stuff. So and
follow all of it. But do you want to give
us kind of the ten thousand view on what domo
is and what it does?
Speaker 3 (01:08):
Yeah?
Speaker 4 (01:08):
Sure, that started like about a year ago, and I
usually had the impressions that I miss something within Elixir
and when I look at the structure and especially type
definitions of the structure. Of course, there is a dialyzer
tool that helps us to check validity of the source
(01:31):
code program same time, it doesn't work at run time,
and vilizer is quite heavy too, to be honest. So
and I was missing these things. That's okay. Elixir is
dynamically type language, and on the other hand, the type definition,
maybe I can do something about that. And then pandemic
(01:53):
started and I've got some free time, and I just
kick it off. Made these libraries that basically validates the
structure against the type definition and return meaningful errors about
the fields. Okay, here you define that this field should
(02:14):
be a string, and you have some number in this
field in the structure. So these aims to keep the
state valid because many software errors comes from invalid state
in the memory, and structures looks like a good place
for keeping the state. So that was my thought, Okay,
(02:36):
let's make a tool that validates a state within the structure.
Speaker 3 (02:41):
Was prompted by like a concrete, like if use case
you had, like for example, at work, you had some
issues or what was just like an just an academic
idea at the beginning, and you were curious to try
somethings out.
Speaker 4 (02:53):
Well, yeah, it was mostly inspired by book The Main
Dream Design by Eric Evans and more. It was more
like in academic inspiration, let's say. And yeah, so I've
got this feelings that there are lots of trials and
terrors around. So we know that there are other libraries
(03:16):
like norm that aiming the validation and other attempts to
make to introduce types in Elixir to get these benefits
of checking and some time nothing what I meant before
suit mean well, and because of that I decided, okay,
(03:36):
maybe I should give it a try and do some
not full fledged type system or something, because Elixir is
not such kind of thing but a very little, tiny
specific library that does on the validation of the structures
and basically keeping invariants.
Speaker 3 (03:54):
Yeah.
Speaker 4 (03:55):
So, answering your question directly, no, it wasn't inspired by
any and create task at the office. So it was
more like general ideas that I would like to have
such a thing.
Speaker 3 (04:08):
And are you not using it in like any production scenarios?
I mean you said it comes from an academic background, sure,
but do you know that like anybody is using it
in production? Yeah?
Speaker 4 (04:17):
Well sure, so I checked it's with current real projects
that we have and it works well. So and it's
kind of at early stage, so of course it's in
development for about a year, but only a couple of
days ago I can say okay that final things were
(04:40):
fixed and now it can be widely adopted.
Speaker 3 (04:43):
Okay, Well, would you see like DOMO being used most
likely any specific use cases where you say, hey, that's
like a pretty good fit for DOMO where I saw
personal success and using it, Like when more people reach
for DOMO compared to something like for example, norm as
you mentioned earlier, because just to give them context for
listeners like NORMS, this data validation library where you specify
(05:06):
schemas like in code, like it doesn't use the type specs,
but like you can basically use functions and stuff from
norm to say okay, the data should conform to this
schema and mean demo that uses the typespecs. So when
would you say, is like it's a scenario where somebody
would like to use DOMO any specific.
Speaker 4 (05:27):
Yeah, sure, that's an amazing question. Thanks a lot. So
there is another component in DOMO. It's that I haven't
mentioned before. So it it's not only validating the data
against the type definition TYPESPEC, but it also has these
pre condition functions attached to the type, so meaning that
(05:50):
for example, if you have the type definition for a
field of your structure, you can also add a pre
condition function to this type that the normal library would
call and if this function returns okay, then it would
consider that the value is not only of that type,
but it's also of a for example, right format that
(06:11):
you expect. So and saying that I can point out
to the concrete scenario. So for example, if you know
that you have an identifier in your system for your order.
For example, let's say you build e commerce system right
some websites the e commerce website, and you know that
(06:33):
in your system this identifiers have specific format for example
AA letter in the beginning and some numbers afterwards. You
can just define the type okay my ideas of string
type and add a precondition function to this, so saying
that the value should begins with A and then using
(06:54):
this type across any structures in your application. You would
have these automatically validated whenever the structure is created with
a construction function added by dormal library, and the DOMO
will guarantee you that you will have valid values for
this id type across your application and that in this
(07:19):
regards the state would be valid. So yeah, this is
one of scenarios, and it can go even more. Like
we can go further. We can define with normal library,
it's possible to define the precondition for the struct type.
You know, when you write this type T for your structure,
(07:40):
and you can say, okay, for this type T, the
miprecondition function will be this one you name it. And
let's say you would like to have some relations check
between fields of this structure, saying that if this is
the order structure for e commerce website, that you have
some allowed amount or of the order in terms of money,
(08:03):
and you would like to have the sum of all
line items in this order to be not higher than
this given amount. So this precondition function attached to the
type of the structure can validate that and give some
meaningful error bag that okay, you should have the summary
(08:26):
amount less than a lot. And that's as a scenario.
When DOMO gives you a consistency of your structure or
more higher level let's say so so it allows to
follow business rules of the system implementing. So this is
(08:46):
the second scenario.
Speaker 3 (08:48):
So that's I guess that could make sense to use Thermo.
For example, at the edges of my system. When I
say I have a Phoenix API, for example, getting some
jacon in and I want to verify that the user
actually like the information the user gave me, conforms to
a certain data schema to like to the to the
(09:10):
requests objects I expect, and that I then can use
that to forward it to the rest of my application,
being sure that, Yeah, as you said, preconditions are met.
Is that right? Is that like a scenario where you
would say DOMO is applicable.
Speaker 4 (09:25):
Yes, is one of scenarios where DOMO can can play
and it's like equivalent to what can be implemented with norm. Right,
So you can define the schema and validate the adjacent
on the let's say boundary of your application, and then
be sure that the data that you operate on is valid.
(09:47):
And yeah, there's definitely one of the possible scenarios. On
the other hand, there are other scenarios. It's when you
work with a pure core having only pure functions and
structures in it, and you would like to follow to
make it follow some business rules that should be executed
(10:08):
in your system. So, for example, it's from the domain
domain driven design framework. Right, So when you have a
set of business rules, you can define them with normal
precondition functions page to the type and have this business
rule fulfilled everywhere you use these values of these type
(10:29):
in structures. So, for example, as I mentioned this before
with order, right, so you can have the order structure
in your core and have these values dependency between items
of this order and allowed amount the same invariants, same
(10:52):
kind of invariants may be for other structures that participate
in the business logic of your application.
Speaker 2 (11:02):
Right.
Speaker 4 (11:03):
And instead of the okay, this can be compared that
you can say, hey, I can write this in any module,
write this verification that my structure have a valid number
of items and that there's some is not exceeding the
allowed amount for this order. And the interesting part here
(11:26):
is that if you do this with DOMO, by using
this precondition function attached to the type, you can have
this validation not only in this structure but in any
other kind of structures using this type. So it goes
like automatically in these places and you don't need to
(11:47):
think twice about if I forgot any validations or you know,
any parts of checking my structures in regards to business
logic of the application, and it even can go further
across the application boundaries. For example, if you have several
micro services that is very common nowadays, you may have
(12:10):
hundreds of them, and if, for example, you share these
type definition and pre condition functions in some model files
across these several applications, due to the normal library, you
can be sure that this would be checked and full filled.
These either these validations for boundary situation or for business
(12:38):
logic in the core.
Speaker 3 (12:40):
When you say sharing the model fied, I assume like
in the sense of like a private tax package or
what exactly are you thinking of?
Speaker 4 (12:48):
Oh, yeah, sure, it can be a hex package. On
the other hand, it's usually starts like a little you
just have several modules like share models that you can
check out in various repels. So the techniques are various
(13:08):
for that. So for example, you can have shared Git
repository with this model and you can edit as submodules
to other Git repositors or you know, just check it.
Speaker 3 (13:22):
But basically you lose like some kind of mechanism to
like get the code into your micro services, be through
x package or like through okay, yeah, that's right, okay,
And I was just thinking because there are also solutions
such as protobaf or others I can think of right now,
which like also follow this idea of having like a
(13:42):
model definition which then can be used to generate some code.
But that's like more agnostic, not really specific to to
to elix here.
Speaker 4 (13:50):
Yeah, it's very interesting. Yes, the true protobuffs are very
good to have the intercommunication be validated time. It is
impossible to put function protobize definition.
Speaker 3 (14:06):
Which with some might argue is a good thing.
Speaker 4 (14:09):
At some scenario.
Speaker 3 (14:10):
Yes.
Speaker 4 (14:11):
On the other hand, with dormo, you can do that
and do more precise validation like Okay, if that if
these conditions that mad, then these values should be as expected.
On the other hand, if I have another value in
my structure set to this value, then this should be
(14:33):
should be another duly expected. So you can imagine that
it can be quite complex interdependencies between fields of even
one structure, not saying about some nested structures that usually
now can be seen in modern applications.
Speaker 3 (14:50):
Okay, to get back to something you said earlier, So
you said that you can reuse like type definitions and
preconditions that attached with that type. So if for example,
I like to get back into an example, you said, like, yeah,
I've a certain identifier, like an order identifier. I could
just specify this type in some module, attach some preconditions
(15:12):
to it, and then use it across my application and
wherever I use DOMO. Basically, I assume then that would
basically reuse these preconditions attached to my order identifier type.
Is that right? Did I get that right? Yeah? That's right?
To Okay, it looks like that. Okay, that's nice. I
guess DOMO boils a bit down to like saying to
(15:34):
avoid a bit of a petition, right, because for example,
if you look at EMO, you acto schemas like like
for at least from my experience, you tend to have
this scenario where you say, okay, this is like my
schema and these my fields. But then it's also helpful
to to have type definition on tops so that you
(15:55):
then just for documentation purposes, right ba, I say okay,
this is like the type of this, and these are
like the sphere as an integer and this field as
a string. And then you also have on the bottom,
like maybe some some ECTO change set validations where they say, okay,
I use the idea needs to start with an AID
or my other ID needs to start with an ASOL.
So I guess DOMO goes a bit in that direction
(16:17):
where they say, okay, I don't want to maintain like
multiple definitions of the same information basically.
Speaker 4 (16:23):
Right true true, that's it. And moreover, Domo has support
of ACTO. So if you have these schema defined, and
you have these type defined into the schema, you can
call the change set in the Dormo library and the
function that's named validate type, and DOMO will automatically validate
(16:47):
changes in the Acto change set for you according to
the type you defined. So this is already supported and
quite convenient.
Speaker 3 (16:57):
That's nice. I assume that, like to actually reuse a
type for example, such as the order ID, I have
to like use Domo in that place, right, I can't
just use any remote type. I mean that, like, how
does that work? When you say okay, it's like a
string T, then like we probably have some code written
(17:17):
which says, okay, if it's a string, then doing this
and that check. But if I just say I have
like this module over there, which like doesn't use domo
at all, but it specifies my type, I don't know which,
just say like it's a map with like certain certain keys,
and the keys need to be of a certain value.
Is that like something DOMO can can handle them? Or
(17:39):
how exactly can I can I imagine this to work?
Speaker 4 (17:42):
Yeah?
Speaker 3 (17:42):
Like where are the boundaries? Basically like why does it break?
Speaker 4 (17:45):
Okay, so three key questions, so where it's break? Well,
I can say that that's a very good example. And
it was a quite long year. But then here so
I had the time to resolve this and it was
successfully completed. So how DOMA works. If you have remote
type is within some structure or other module that's not
(18:10):
using DOMA at all, library automatically take this type into
validation because more has is shipped with compiler. So when
you add library to the project, it has two pass compilation.
(18:30):
First pass is by alixer and second past of the
compilation is by DOMA compiler that just do the job
by getting all the type definitions from remote modules and
putting them in place where the validation should be performed.
So and moreover, if you change remote type, for example,
you compile your project and you change one of the
(18:53):
keys in this map you mentioned in the remote module,
I mean type definition of the key and you can
again the DOMO will notice that and recompile the module
where you use is remote map definition.
Speaker 3 (19:08):
So automatically as signs that compiled time dependency to the remote.
Speaker 4 (19:14):
Model, it tracks dependence in between types in your application
and recompiles appropriately.
Speaker 3 (19:20):
I assume that this can have a hit on compilation
times because I mean, if you look at what the
Alexi core team and the Phoenix core team has been
doing in the past few months, they very much try
to reduce this kind of like compile time compilation compilation
links between modules which can SUI times. So I assume
(19:41):
that at least like a trade off of using domo
in that fashion is probably that it might impact your
compiled times.
Speaker 4 (19:47):
Right, yeah, sure when you comes at price, so definitely
it would increase compilation times. In synthetic tests it was
about maybe twenty percent of increase compilation time. And of
course during the run time it's additional sipute cycles that
are spent on the validation of the data you've got.
Speaker 3 (20:11):
I mean, that's your idea, right.
Speaker 4 (20:15):
That's true. Yeah. At the same time, I can say
that there is a heavy optimization implemented yet for the
dependency checks it just works. I can say that during
the compilation time, Dormo relies to the pattern matching a lot,
and at least for the part when you have this
(20:38):
validation at run time of your values. It's working on
already optimized code optimized by Elixir and a lung compilers.
Because of pattern matches that automatically generated by Domo, you
can have quite a good performance. Yeah. If you you know,
when we talk about code generation, that definitely happens here
(21:03):
with the dormal library. It's always a question mark, Okay,
what this library generates and how it works in my application,
So you can ask this question at some point in time.
And interesting enough that Domo rights the source code of
this validation into the build folder. So if you add
(21:27):
the type definition to your structure and say use dormo there,
then in underscore build folder you would have a Domo
generated called subfolder where you can see the old source
code that is used to do these run time validations.
So it's yeah, then used as a compilation source or
(21:48):
is it just like for the user's benefit, Well, it's
used as compilation source. The same time, if you change it,
it wouldn't affect anything because it would be overwritten during
the next company, so you can read it, but you
can't affect it much. This add this additional confidence about
(22:09):
what's going on when you call this function validate type
on your structure or constructor function or if you do
a reidate type in ECTO schema.
Speaker 3 (22:21):
Okay, I guess the question which for some people might
have like how readable is this code because that code
generation tends to sometimes produce code which is like a
bit not so nice on the ice to say to
phrase it like that.
Speaker 4 (22:36):
Yeah, true, there is a four matter run during the
generation of this code, and it's quite readable and quite simple.
So worse, the more fields in your structure you have,
the longer would be the output and the source code file.
Speaker 3 (22:57):
Same time.
Speaker 4 (22:58):
It's quite straightforward there too, same in functions there that
you just can read and say, okay, here is the validation,
here is the pattern matching. So it's quite simple.
Speaker 3 (23:10):
So that means that like domo generates like an additional
module or what which is then used FORUL for type checking.
Speaker 4 (23:17):
Yeah, okay, okay, what happens when you use domo at
minimum level? You can just add use domo into your
struct module, right, and then dormo generates a submodule that
is called type ensure. So let's say your module named
(23:37):
car and after DOMA works, you have also in addition
car dot type insure and inside of this type ensure
all validation happened and how it works in regards to
your original car structure. DOMO adds functions to the car
(23:57):
structure as well. It's a new function that is constructor
function for the structure and validate type function that is
for validation of existing instance. So there are also a
couple of other functions like typed fields and required fields
(24:19):
that returns the list of the fields of your structure
that has not new types. Let's say, so that's useful
in actual change that. So the first two new and
validate type functions they just facate for type insure module.
So when you call car dot new and keywould leads
(24:43):
to these fields and values for these fields, the new
function bypasses that after some checks to type insure module
type insure module, do pattern matches validate the all types
of the values is as expected, then run pre condition
functions associated with these types, checking okay the format of
(25:06):
these values is good, all invariants have full field, and
then returns back to the call site so and it
returns the constructor the structure basically, So that's how you
can be sure that at the time of the call,
when you get this structure back, it's valid structure according
(25:26):
to the type and pre conditions defined. Then if you
modify the structure, for example, alter field of the car,
then you can call again the validate type function with
this modified instance, and the validate type function would do
the same trip to the type insurance back, giving you
(25:48):
the answer is it still okay structure matching the type
and preconditions or no, you have this field incorrect because
of this and that. So that's how it works basically.
Speaker 3 (26:00):
Okay, And what happened if I, like, have my car
struck and I have said use domo and then instead
of that, I just define a module which it's called
type insure. What would happened then, like, because then I
have a name class.
Speaker 4 (26:15):
Right, yeah, sure, the behavior would be the same if
if you define type insure twice. So you can do
this by hand and there are no any you know,
hidden things behind that. It's just simply a generation of
the Elixir source code and compiling it with the LEIKXIR
(26:36):
two times.
Speaker 3 (26:37):
So okay, I guess, like on one thing DOMO could
do there is like generating like it in a different
name space, right, like could for example generated in domo
dot type insure dot name of a module, because then,
I mean people could then still define a module which
is called that way. But if they basically messed with
like another uplic another libraries name space, it's like they
(26:59):
all fault.
Speaker 4 (27:00):
Right, Yeah, well this nice idea. Let's see what can
be done in this regard. And there is another scenario
how to start using domo. You may not even use
all the functions that DOMA adds to your structure. For example,
let's say we have the car, and if you even
(27:21):
write use domo inside the car, you already get some benefits.
What I mean, during the compilation time, it would check
the default values of your car structure, these values that
you usually define with death struck, and during the compilation time,
DOMO already would validate if the default value specified conforms
(27:42):
to the type and pre conditions, and if it's not,
it would say compile error. So you have these values
not matching, and yeah, that's that's interesting. Even more, if
for example, you have some connected structure like one structure
nested in another and you let's say car, and what
(28:07):
can be inside of the car. Let's say some some seat,
yeah seat, and you know these seats with leather or
other materials some, So we can imagine that for the
seat it can be a separate structure defining all the
parameters of the sea.
Speaker 3 (28:26):
I want to cut a blue seed and orange seed
and two yellow seeds. Yeah.
Speaker 4 (28:31):
For example, So if you give the default value of
seats to the car saying okay, I would like orange
seat and blue and put it into the depths truct
of the car. And if you use a dorma function
like seat dot new right, so it would check during
(28:53):
the compilation time the validity of this default value. And if,
for example, you put into the sea dot new some
invalid value by mistake instead of orange stream orange atom,
and it wouldn't manage the seed type. DOMO will also
(29:13):
give you back the compilation error saying okay. So you're
constructing the thing that is not mentioned the type as
a default value. And this works even in function calls.
So if you pass this default value with domo dot
new to the function heater definition, it will also be
checked during the compile time. So how DOMO does that.
(29:37):
It basically tracks the calls to dot new that is
generated by the DOMA obviously, and then during the compilation
pass it just make validation of these fields.
Speaker 3 (29:55):
Okay, that some timeful. I mean I've not a had
a scenario. Well default values were as complex where I said, okay,
I want to verify about it. Don't make the mistake here.
But if you get for free, that's what's nice, I guess.
Speaker 4 (30:07):
Yeah, And you know the software is constantly evolving, so
and it may happen then for example, at some point
in time you change the type of your structure and
all humans, so you can forget to change the default value, right,
and that potentially could lead to mistakes, and DORMO play
(30:31):
safe here, so it gives you appropriate feedback very early
at compile time.
Speaker 3 (30:37):
Charles, do you have any questions I've been talking.
Speaker 1 (30:38):
About it's about to chime in. I'm more curious about
like testing and performance. Yeah, how does this affect any
of that?
Speaker 4 (30:47):
Well, did some synthetic tests, so you can find the
detailed results in the read me to the library. What
I've observed it's one point twenty six times slower than
without library at run time. So it looks like around
(31:08):
thirty PAF and slower work. Same time you get valid
state of your application price.
Speaker 3 (31:19):
I guess it makes sense when you're like, I wouldn't
probably use it in a scenario where I will already
know that certain data is valid, because then I mean,
way check in the first place. Right, But if you
are in a scenario they say, okay, I I'm not
uncertain that the data which I'm getting here is conforming
to what I expected to be, then sure why not?
I mean you can even write now validation at all,
(31:41):
but which works if the users friendly enough to give
you a right data. If they don't, then it's going
to go boom. Right, yeah, yes, and.
Speaker 4 (31:52):
It's not only user sometimes the business logic can be
quite sophisticated. And if of course we have you test
and cover all not happy but unhappy path as well.
And same time, it can be that you can forget
are one or another combination of all parameters and adding
(32:15):
these validated against the type can add additional let's say,
it can give you additional insurance that you will have
valid state of your application.
Speaker 3 (32:29):
One thing. As Charles asked about testing, for example, I say, like,
I let's go back to that example from earlier with
the idea it's a swing, it's supposed to start with
a letter A, Like I mean, how would I then
go roup fighting a test for that? Like? Because I mean,
as you mentioned earlier, this is like a reusable type, right,
like a type I can use the multiple places I
(32:50):
can see, like how I would use reuse like the
destruct how we test the struct definitions of dormal because
then I can just call dot new right if it
raises an error, it turns an error toroogle, then then
it can failed successful. Is that like an option to say, Okay,
I have this type over here, and now I would
(33:11):
write to write some tests because I also have some
preconditions attached to that, and I want to make sure
that I didn't make a mistake while writing these preconditions, right, yeah,
so like some option to do that? Yeah?
Speaker 4 (33:22):
So I remember one talk in regards to that from
camp back about what is right size of unit that
is under the test. And I can say that, for example,
in the test, you can define as trugged for test
purposes that uses the type definition and be sure that
(33:47):
these preconditions associated with this type working properly by calling
these you know, test struck Nott new Okay, so this
would be what what does it? It means that you
would ast the interface and not internal implementation. Right, So
the publicly available interface provided by domo is this new
(34:11):
function and validate type function.
Speaker 3 (34:14):
Okay, but there's no API where I can say, hey, Domo,
I'd like to use this type over there, and please
check it, like check piece values I give you, and
now tell me if that conforms, like basically probably similar
to what norm does. Right, there's like no altitude that
I guess they always have to go through, like the
(34:36):
motions of like specifying a struct and then I mean
either using a struct I already find or specifying one
if I want to, for example, test the remote type.
Speaker 4 (34:45):
Yeah, well technically you can, so you can call type
ensure modules that Domo generates for these kind of things.
So there is a public function that is called. And
on the other hand, it's a question where your interface is.
Speaker 3 (35:02):
So if yeah, I guess we're now entering some a
certain level of philosophical conversation like what is a unit test?
What is the purpose of life? Yeah?
Speaker 4 (35:18):
Well, it's possible to do the unit testing with either
new function or with calling typing. Sure, model directly.
Speaker 3 (35:26):
Yeah, I can see why I call it. Type into
a model directly is something which probably should not be encouraged.
From what you told me, it feels like it's more
of a private API think, so yeah, yeah, better not
go there, I guess.
Speaker 4 (35:42):
So it's a quite simple thing. On the other hand,
if you would like to express business rooms, it's another
possible way to do that. So for me, it's also
always a question to keep every scene in place, especially
when some parts of the business rules are shared across
(36:05):
various parts of the application or even across several micro services.
Speaker 3 (36:11):
So abe bit of a hard question now when it's
like a scenario where you would not use DOMO, So
it fe like, say, okay, this is just not the
right tool for job when people may be reach for
something else or write custom code.
Speaker 4 (36:26):
Yeah, so I think every tool should be used for
appropriate problem. And if it's high performances application like maybe cryptocurrency,
where you have heavy calculations and every microsecond is on count,
(36:47):
then maybe it's not right a problem to use DOMO for.
On the other hand, if you have a business application
like e commerce, website or lots of business logic that
should work correctly and you can spend some time to
get the answer to provide the user, then dom could
(37:08):
be a good choice.
Speaker 3 (37:10):
Okay, So what is any anything you see on the
horizon for for like DOMO, any next steps you'd like
to take, anything which is missing and you'd like to
tackle what comes next.
Speaker 4 (37:22):
Yeah, So I'm looking forward for some large system to
give this library a try, because all applications I work
with of the average size, so it's kind of web
shops or such kind of websites, and I'm really interested
(37:46):
to see how it would work on one hundred micro
services setups, so where you have lots of components that
should be play that should play nice together too, and
very welcome for any such kind of collaborations to run
(38:07):
a test on such larger than average systems. Other plans
are to add additional type checks to dormo, Like it
checks all the standard types, but that are defined in
the Elixir documentation. At the same time, it doesn't check
(38:28):
types that referencing itself yet, so I mean crimary trees,
recursive types, right, So I'd like to add support for that.
It's not such usual scenario in business applications, but I
intend to support this.
Speaker 3 (38:48):
I've done this when I wanted to have a representation
of like adjacent of like an arbitrary adjacent because then
you can say, okay, like adjacent value can be like
a list, that can be an integer, that can be
a stream, but it can also gain be an object
with in turn users values which then by definition, so yeah,
and I can see why why that we useful? Yeah,
(39:10):
and for many for many such kinds of definitions. DOMO
is working. Now if you say, okay, this is part
of Jason, and inside of this part of Jason, it
would be the same part of Jason, so you know,
recursively and DOMO wouldn't work.
Speaker 4 (39:25):
So yeah, what happens when you do that? It doesn't
raise an error? Yeah, yeah, it rises an error that
is not supported yet. Okay, so no binary trees for now, sorry,
so with leaves and branches, but it's it's a question
of some further work on that.
Speaker 3 (39:45):
It's also mean it might just then explode the runtime complexity, right,
because if you have a very large binarit tree, yes,
but sure, that's that's always an issue.
Speaker 4 (39:57):
Sure, And for example, if you have very long list
that can be in your structure, it's also can be
an issue. So This is natural limitation for DOMO because
it validates each list tallemands for conformance to the type,
so it should be considered as well.
Speaker 3 (40:18):
It's like some some smart instead of DOMO, for example,
when you say I've got a list of any, because
then there has no reason to check each element of
a list if you say it can be anything. Is
something like that DOMO or yeah.
Speaker 4 (40:33):
Well in regards to Liz, no, Well, it's so there
are such kind of optimizations. If you say that some
field is any, for example, it wouldn't be checked, so
it would be a shortcut like okay, SVLID and lists
should be supported as well with any type inside. Yeah,
(40:56):
so I intend to look up for other such kind
of optimitysations too.
Speaker 3 (41:01):
But I guess that goes into what you said earlier,
like to see it use the larger scale, and then
these kinds of issues and optimization things are going to
crop up naturally because you push the library to its limits. Yeah,
that's true. Okay, child to you if anything left because
I'm trying out.
Speaker 1 (41:19):
I think you pretty much covered it. Yeah, a couple
of the questions I was going to ask and when
you cover them.
Speaker 4 (41:24):
So so it may seems a bit weird from the
first point of view, right, So attaching pre conditions to
types and sharing here in there, but all the other
And it's another view on the same problem of having
valid state and fulfiling invariants in your models.
Speaker 2 (41:48):
So all right, well, I'm gonna push your Swart picks.
Speaker 1 (41:51):
You have a conversation about stuff that we like before
we do that, though, yvon if people want to follow
you on social media connect how do they do that?
Speaker 4 (42:01):
You can follow me on githab My username is Ivan
rublev and you can follow me on Twitter. User name
is Levy Brown. Maybe I should write it somewhere folks,
and you can add it to the description of the podcast.
Speaker 3 (42:17):
Yeah, yeah, we'll do that.
Speaker 1 (42:18):
Yeah, absolutely, yeah, I just put it in the chat.
Well all right, well let's go ahead and do the picks, Sasha,
Do you have some picks for us?
Speaker 3 (42:26):
Yes, And it's actually related to what we talked about,
because I mean even mentioned that he A lot of
these ideas are based on the main driven design by
Evan True. I forgot his last name, Evan Evans, Eric Evans, Yeah, Eric,
that was And there's also another book not from Eric Evans,
but from from Scott Blushing and that's called the main
(42:48):
Modeling Made Functional. Yeah, that's an amazing book. Yeah, it's
very nice. Arguably it's probably the best book I've read
it on the winderin design. It's also relatively short, especially
compared to Eric Evans book, which is not short.
Speaker 2 (43:03):
And we should see if we get Eric on we
had him on Ruby Road for a long time ago.
Speaker 3 (43:09):
Nice. Wow, yeah, that would be pretty cool, to be honest,
maybe you could also get Scott Blushing. Of all, he's
not an elixir of death. But yeah, just to get
back to the pic. So the book is called domin
Modeling Made Functional, and it's it's actually a nice introduction
into both like in the domainder design and also functional programming.
He's using f sharp there, and he's like talking a
lot about how to use the type system to basically
(43:30):
help you restricting and like restricting things to what they
should be to like basically avoid in that state already
on the type system level, which plays a bit in
what we talked about today, because I mean demo helps
with like using the type definitions and forcing those. And yeah,
it's like a really really nice book. It's well written,
(43:52):
it's it didn't really bore me to death text books
which I just stopped reading at a certain point. And
if anybody is interested in my demander of design is
into some function programming and types, then I can really
wold hotly recommend.
Speaker 2 (44:05):
This book awesome. I'm going to throw out a couple
of picks.
Speaker 1 (44:08):
The book I'm reading right now is I'm still in
the middle of a Rhythm of War by Brandon Sanderson.
Really enjoying that picture book fantasy book. I have another pick,
but I'm kind of saving it for last. There was
something else we're going to pick, and I can't remember.
I guess I'll just go to this last one because
I'm excited about it. So I've been doing a whole
bunch of work lately around the idea of top end devs.
(44:30):
You all, if you listen to dev chat dot tv
and are you subscribe to the mailing list and stuff
like that, you're going to start seeing a whole lot
more stuff branded with top end devs instead of dev
chat dot tv, because we're kind of moving everything over
to that, mainly because I want to communicate to people that, hey, look,
if you put in some effort. We talked a lot
about this last week with Audi. Audi and I talked
(44:52):
about this, but you can take your career wherever you
want it, and I am committed to that idea, and
so I want to because devchat dot tv doesn't dev
chat doesn't, it doesn't really mean anything.
Speaker 3 (45:04):
You know.
Speaker 1 (45:05):
The idea was is, Hey, we talked about dev right,
but this is kind of more of a higher idea
and aspirational idea.
Speaker 2 (45:11):
One of the things that I'm doing.
Speaker 1 (45:12):
And I can't remember if I brought this up last time,
and so I'm going to just throw it out here
so you all can show up if you need it.
But one of the things that I've really picked up
lately is is the coaching.
Speaker 2 (45:23):
Right.
Speaker 1 (45:23):
I've just loved helping people figure out, Hey, what do
I do next, What do we need to learn, what
do I need to work on to grow into what
I want what I want to be. And as I've
been doing that, it just it just fires me up.
I mean, I had a conversation with somebody on Friday,
and you know, he's trying to figure out where to
(45:44):
go next, right, and we talked about all kinds of stuff,
and at the end of the call, you know it's like, hey,
you know, go do this stuff. Let's talk in a
couple of weeks, right, and holy cow is just seeing
the potential of what he can do and the power
behind what he can accomplish.
Speaker 2 (46:00):
It just gets me going, right.
Speaker 1 (46:02):
And there are some things that everybody can do, and
then there are some things that, as we get into
the particulars of your situation, you can do, right. And
that's kind of the difference I guess between like the
course and coaching, or training and coaching. And so what
I'm doing is I'm kind of splitting the difference between both.
And so I'm using Zoom's webinar system. But it's not
a webinar, right. Webinar is I give you half the
(46:23):
information that's useful, leave you hanging, and then give you
a sales pitch. I'm not doing any of that crap. Okay,
that's I'm not doing a webinar. But I am going
to do training. So I'm gonna do like ten or
fifteen minutes of training and then for then the rest
of the hour hour and a half that I have,
I'm planning on doing this Wednesdays around noon mountain time.
I'm just gonna take questions, okay, and not take questions
(46:46):
in the sense of you know, what what what? How
do how do strings work in elixir?
Speaker 3 (46:51):
You?
Speaker 1 (46:51):
No, it's not that kind of stuff, right if I
if you have that question and I can answer it,
you can ask it, right, and I'll try and answer it.
Speaker 2 (46:58):
But what I'm really looking to dive into is, hey,
I've got this far.
Speaker 1 (47:03):
In my career, or hey, I'm trying to figure this
stuff out, or hey, i've got this situation at work,
or I'm trying to find a job and I'm not
getting interviews, or things are going really well, but I
feel like I could do more.
Speaker 2 (47:14):
What should I be doing next? And then we'll actually
talk through your situation, right, talk through where you're at,
and figure out where things should go.
Speaker 3 (47:22):
Right.
Speaker 2 (47:22):
So it's going to be almost more coaching than Q
and A. But we'll just do it until we run
out of time, run out of questions, whatever, right, And
I really just want to help people out, So it's
totally free, right, no commitment, no whatever. I'm not going
to do a sales pitch right and try and sell
you on coaching, nothing like that.
Speaker 3 (47:43):
Right.
Speaker 1 (47:43):
I am offering paid coaching, but I'm not gonna try
and sell anybody on that on these calls. Right, it's
completely free, completely you know whatever. So all you have
to do is just go to dev chat dot TV
slash level up. I think you have to put your
email address in so that the Zoom system can send
you the link to the webinar software and then from
there you're in, right, And yeah, just show up, jump
(48:07):
on the call, and we'll answer as many questions as
you want. And if we don't get to you, then
show up the next week, right, because we're going to
do it every week. And yeah, I'm really looking forward
to helping some folks out. Like I said, this is
the stuff that really just makes me feel like I'm
making a difference myself, right, and then yeah, you know,
(48:28):
if it turns into a kind of a deeper relationship
and we wind up doing coaching, than great. And if
I kind of get you there in twenty minutes, then great.
Then you got there in twenty minutes, and you can
come back when you get stuck again or you need
more guidance. All right, So that's kind of what I'm
looking at, and I'm really hoping that I can help
some fokes out.
Speaker 2 (48:46):
So dev chat, not TV slash level up, that's my
evon what are your picks?
Speaker 4 (48:50):
Okay, my peak for today and his book called micro
Services in Auction by Morgan Bruce and Paul Opereira. It's
very nice and laconic book about building micro services the
right way to Yeah, you can recommend it.
Speaker 2 (49:08):
Awesome. All right, Well we're gonna go ahead and wrap up.
Thanks for coming. This was fun.
Speaker 4 (49:12):
Thanks a lot, folks. It was very nice discussion about
types and the library. Thanks for having me today.
Speaker 3 (49:20):
If you fear interested in types like, check out our
episode with the Gleam of Lewis. Oh yeah, that's fun too, Yes, yes,
Gleam is very nice. Usually very nice too. We had
two weeks ago on the show. That was pretty cool.
Speaker 2 (49:33):
Yeah, louis cool.
Speaker 3 (49:35):
Good stuff.
Speaker 2 (49:35):
All right, Well till next time, folks. Next up,
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.