Hey, everyone, welcome to the Unhandled Exception podcast. I'm Dan Clark and this is episode
number 54. So, first of all, I want to start off with a quick apology for the gap since
the last episode. I'm currently juggling a whole bunch of things at the moment, but
don't worry, this podcast certainly is not going away. Episodes are just a bit less
frequent at the moment. And in this episode, I am joined by Matt Hunt and we're going
to talk about big balls of f***** mud. So, welcome to the show, Matt, and thank you
for joining us.
Thanks, Dan. Thanks for having me.
You're welcome. I've actually been meaning to ask you on the show for a while. And recently
I went to a DGD, Southwest conference event and watched your talk, which was really, really
good. Lots of good stuff in there. And I knew at that point, I really have to get you
on. But I pulled into conversations and I never tend to saw you, you were in conversations
chatting, so we never actually caught up at the event.
Yeah, that is a shame. It was quite a nice event, actually. And to go on first, I was
quite pleased with that to get it out the way. But then, unfortunately, so poor gentleman,
I passed out halfway through my talk. So, that was a little bit off put in, to say the
least, but I hear he's okay. And it was, yeah, it was a good event and a good talk. So,
yeah, I'm glad we finally caught up, definitely.
Yeah, definitely. Yeah, I had forgotten about that, actually. And he was seated right at
the top in the middle above the centre set of stairs, wasn't he? So, that could have
been very nasty.
It could have been very nasty, yeah, so, yeah. I'm glad he's okay.
So yeah, so could you introduce yourself to the listeners and just tell us a bit about
what you do?
Yeah, sure. So, I'm Matt Hunt, I've been a software developer now for nearly 20 years.
And one day, I'm going to actually be able to say 20 years. And I'll be happy then, a nice
round number. But yeah, so I've been working mainly the last sort of 10 years as a contractor
and with the last five years, mainly sort of in the finance area. And for no specific
reason, I've always fallen into sort of the back end API development side of things. But
then the first part of my career was really based around digital agencies and all the fun
that comes with that, the fun and the time pressures.
Been there, done that.
Yeah, yeah, I think it's a rite of passage these days. Yeah, so that's a bit about me.
I'm currently working for a start-up bank called Zero. We're actually sort of looking
towards sustainability side of things. So, we're a bank with a conscience and a purpose,
hopefully helping people get to net zero.
Hence the name.
Hence the name Zero. Yeah, so it's, yeah.
Yeah, so very early days. So yeah, so we'll see how that goes.
Awesome stuff.
So before we dive into big massive balls and mud, I just wanted to mention to everyone
that I've actually recently started a newsletter. So I kind of enjoy writing and thought it'd
be a nice way to consolidate all the bits I do. So the podcast, YouTube channel, dotnet
Oxford. And also I'm going to include links to news items and pics that I found interesting
this past month. So it'll be a monthly newsletter and the first one will go out on Thursday,
so, first of June. So obviously in the future from us chatting now, but in the past from
when this episode goes out, when I edit this episode.
But you'll be able to, I think on the subscribe page it shows past episodes anyway. But yeah,
I'll include a link to subscribe to that on the, in the show notes.
And also just a quick reminder to everyone that the podcast is on Discord now, so you
can join via the link on the website, which is the unhandledexceptionpodcast.com. And lastly,
quick reminder to this podcast is sponsored by Everstack, which is my own company providing
software development and consultation services for more information, visit Everstack.com.
Right, now that's over and done with. Let's talk about big balls of mud. What is a big
ball of mud?
So a big ball of mud is generally sort of the deterioration of sort of code quality
over time.
There's lots of different ways to, you can just describe this. It's kind of better to
be described as spaghetti code, I think, where things are pointing all across the code base.
There's dependencies linked left, right and centre. There's been hacks put in that sort
of people think, well, we go back and do that and then never get time to go back.
There's also a big ball of mud is potentially hard to test. And as with the big ball of mud
that you see a sort of a dung beetle pushing over time, the mud gets bigger and bigger
and bigger and never gets cleaned, essentially.
One of the things that happens is that people come in and see a bit of bad code or they
don't realize it's bad code or they don't realize it's a hack.
And then they sort of emulate that.
I know as a contractor when I was went into companies, I was expected to deliver straight
away. So part of doing that was being able to identify a pattern that was already in
the code base.
Now, if there's not not any sort of good patterns or practices laid out in that code base, I
used to just have to do my best, essentially, and sometimes emulate what's already there.
So big ball of mud, if this bad code in there, someone might come along like the next developer
in the line, come along and replicate the badness that's already there and it gets bigger and
bigger and worse and worse.
So over time, sort of, it's just the quality goes down to the point where it's hard to
change, hard to debug.
I've worked, like, I'm a contractor and I've worked with quite a few different companies
and just seeing most companies have those big balls of mud because you've had multiple
members of staff going in.
They used to different patterns, different ways of doing things and they'll do it their
own way.
And over many years where different people have got the hands in that big ball of mud
doing things in different ways, it just gets, you've got to have patterns around it to
actually protect against that because if you don't, the technical debt's going to grow,
especially where you've got the business asking for features and stuff faster than you can
fix technical debt.
Yeah, this is this is very much a problem that I've seen over the years, especially with
digital agencies and people that are under a time crunch.
If you're paid to do a specific job from start to end, then the code's got to be written
and it gets written badly just to try and get it done.
And then I've seen companies as well that I would describe them as feature factories.
They think that their code will be better if the more features they put in, so features
are priority and paying back the tech debt sort of never gets paid back.
And then tech debt is not a bad thing.
As long as it doesn't turn to bad debt and you have to pay that debt back.
Unfortunately, otherwise it'll come and bite you.
And I've worked on plenty of systems where the tech debt wasn't given time, like the
business wanted to just feature, feature, feature.
And then it gets to a point where they can't get their features because the code is set
in such a bad state that the time to create those new features gets longer and longer
and longer to the point where one day one of the developers will come along and say,
right, I've got a good idea.
Let's rewrite this.
And yeah, so and the cycle, the cycle just continues, unfortunately, until someone
breaks out of that cycle or realizes what what they're doing wrong.
Yeah.
So like the point of all of this, when I started doing my talk around this subject
was just because I've worked in so many of those places and I thought this got to be
a better way.
And I remember quite a few years in my career, just thinking, how can I make this
better?
There must be some way.
You know, I'm doing something wrong.
And you sort of you read blog post after blog post, you know, a lot of developers
these days, they learn from the internet.
And the blog post will tell you like a little snippet of this bit and a little snippet
of that bit, but never really the full picture.
So people sort of go down the wrong path.
I do remember once I worked for a rather large company, I was helping a junior out
who had read all of the blog posts in the world and then put all that knowledge
from all these blog posts into this one small piece of functionality that you had to
create.
And and like it was wonderful.
It was like it was it was actually laid out quite well.
It had all the all the patterns in at the only unfortunate thing was that it didn't
actually do what it was meant to do.
So there was thousands of classes, thousands of line of code.
And so eventually we went back to sort of first principles, tour it all up and said,
right, what do we need to do?
And it turned out, we need to take a sequel table and put it into a CSV file.
So one class in the end did that.
But yeah, so the point with the I was trying to make was that sort of people,
people go down the wrong route sometimes.
And I was I've just always tried to find a better way of it, which is sort of
trying to get myself out of this mud and not get into it in the first place.
I feel I feel many times that not getting into it.
I think everyone has, hasn't they?
Yeah, I think we're just with the whole like lots, lots of developers
getting hands and even if you've got a good pattern, then it's so hard to enforce
that because you've got to constantly be checking to make sure everyone's
following those patterns, new developers, people that are being pressured by the
business and just need to get something quick and want to cut corners.
Because people do, people always will try and cut corners.
But how do you get people to follow patterns like CQS or whatever pattern
you decide is the right way to go.
One of my favorite patterns is kiss, keep it super simple.
That's the nice way of doing the acronym.
But it's that recently I've been involved with doing quite a few interviews.
And quite often I've found that the candidate hasn't actually managed to
solve the task at the end.
It's a technical interview at the end of the test because they've gone in
and created abstractions, layers, different projects for different things.
Before they've even got, it's quite a simple.
I'm not going to say what the actual requirement is just in case I do it again.
But it's quite a simple requirement.
It's not complicated, but quite a few people just don't do it in time
because they don't keep it simple and they try and create lots of services
and extra projects, like different layers and everything.
Rather than just do it, then refactor it.
Yeah, I'm very much, I'm very much a keep it simple kind of guy.
I like my sort of, I like my code to be easy to read,
easy to maintain it and sort of, yeah, as little code as possible.
I think that's something that we get from TDD these days as well.
And only recently I read Robert Martin's book on clean code.
I was I was on holiday and I had some time.
So I sat by the pool sipping my cocktail reading that.
And I came across the three laws of TDD and I made a note of them.
The third law says you may not write more production code
than is sufficient to pass the currently failing test.
And I think that's something that sort of people could learn from
in lots of in lots of ways, because you will end up with
otherwise with this spaghetti code if you write too much for sure.
Yeah, I kind of, on the flip side of that with TDD,
I've worked for companies where they do take TDD to the extreme
and basically every single class is TDD
and everything else is marked.
And where you were saying before about not being able to make changes
because you've got so much technical debt,
I found the same with tests,
not being able to do refactoring improvements
because all the test break and nowadays I'm a much,
I'm a strong advocate of TDD.
It's use the term integration test
because it's that might not be the right word,
but as in using mocks as little as possible,
as probably the best way of saying it.
So rather than mocking stuff out,
just actually like HP.NET Core has the web application factory,
which does an integration test against the API.
So that's simulating what the end user,
so it's an API calls to the end user might be a machine,
but it's simulating the requirement of that API.
So with one test, you're getting,
it's testing everything in,
I was going to say startup.cs, but now program.cs.
So it's testing all that stuff,
it's testing your dependency injection is set up,
it's testing your like much more,
you're getting so much more bang for buck
and you're free to completely refactor
as long as you're not breaking the requirement.
And that's just, you're not locking in
by writing these tests that mock everything else.
And even like taking it a step further,
I use Docker quite a lot to spin up databases
and have the test also testing against real databases.
And that just saves so much time,
you get so much more bang for buck from your tests,
but you've not got the look in of what mocking does.
Hi, this is editing Dan.
So I just wanted to pause and just say that
what I just said then about integration tests,
you can totally do that in a TDD fashion.
I realized it sounded a bit like I was saying,
oh, I don't like TDD
because you get into that situation
and integration tests are better.
That's not what I meant.
I quite often do TDD
using these integration tests.
All I meant was that quite often
when I see code bases that do like full on TDD,
it's typically lots and lots of unit tests
with everything else being mocked.
It doesn't have to be the case though, when doing TDD.
Anyway, I just wanted to clarify that.
So back to the show.
Yeah, so that's definitely something
that I've seen a lot more in the last sort of four or five years.
Especially in some of the finance
or FinTech companies that I've worked in,
is that we're moving completely away from unit tests
and just testing sort of the API as a whole.
One thing that I do a lot of
is sort of trying to mock as realistically as possible
sort of the cloud infrastructure.
So I use Azure a lot.
So I'm trying to mock the parts of my code
that are Azure based or the SDK,
I should say mocking the SDK that connects to Azure
so that I'm not mocking any of my own code.
And as you say, just exercising the API
from the client call,
all the way through to the sort of the layers of your system
or however you've built your code.
Yeah, and as soon as you write a unit test,
you've locked in that design,
which once you get into your big ball of mud,
there's no realistic way out.
You're sort of locked into this architecture
that you've chosen rightly or wrongly
and it may not even be a recognized pattern,
it might just be a load of code thrown together
and it's very hard to change.
And at least if you can change it,
you end up rewriting your tests
and then you've sort of lost the original intent,
so to speak, you could end up writing your tests wrong
and then with these wrong tests,
you've sort of everything's passing,
but the system still doesn't work
once you've done this big refactor.
So I think yeah, there's, yeah,
moving away from unit tests in the situation
where the unit or system under test is a class.
I think that's where I've seen a lot of people go
and it's a great idea.
I do see a lot of pushback though.
People sort of look at this and say,
what, you've got a unit test every single class.
And I'm like, that's never been a thing,
that a system under test is what you're testing, not a class.
So once people see the power of that in real life,
I think they sort of get where it's going
and what's good about that.
Yeah, definitely.
A class is an implementation detail.
It's not part of the requirement.
The requirement doesn't know what a class is.
Yeah, very much so.
Yeah.
So with CQS,
how does that help solve the problem?
Or in fact, so we probably just take a step back
and define what CQS is actually.
Yes.
And maybe how it differs to CQRS,
which is another term we hear going around.
Yeah, the CQRS seems to be everywhere,
but not a lot of people understand it.
Or they don't know it's in's and out's
and where it should be used.
But moving away from that,
CQS is the command query separation pattern.
And this is something I discovered actually
in a series of blog posts by Stephen van der Sen
of Simple Injective Fame,
if it is famous.
I used to use Simple Injective a lot.
That's how I got on to his blog posts.
He was very much like solid.
And so that was sort of,
I was on a journey of learning solid at the time.
I came across a blog post.
One is called Meemaw on the query side of my architecture.
And then there's a converse one,
Meemaw on the command side of my architecture.
And he explains the command query separation principle very well.
And I initially, when this was,
I wanted a better pattern than just your sort of end here,
you know, business, data, UI.
And so I was looking at CQRS,
but CQRS is sort of this, this two sides of CQRS.
It's basically you're separating out the whole of your sort of
infrastructure into two sides, a complete read side
and a complete right side.
And then they joined by some sort of message queue normally
or some sort of events,
which brings eventual consistency.
So that was sort of too big a pattern
for a lot of systems I was using.
And I have seen people shoehorn that in
because it was a buzzword for a long time.
So when I found command query separation,
I kind of did a little jump for joy
because it was sort of, it was nice and neat.
It's all in, it's all in process.
There's no need to separate your infrastructure.
And so CQRS, it's the,
it states that everything should either be a command
that performs an action or a query
that returns data to the caller, but never both.
So never cross the streams.
There's sort of the commands are there to mutate data
and should never return any state from the system.
And then queries are there to return the current state
of the system or the data.
I always try and think of these as two little stories.
So for the query, I always think, right,
so if I was in Curry's or Dickson's,
then what would I go up to a salesperson
and I say, how much is this television?
All I want to know is that's my query.
All I want to know is the price.
I don't expect them to tell me the price,
charge my card and put the tally in the back of my car.
So that's a query.
So I just want information and commands.
Commands, I always think of as
when I want my daughter to tidy her room.
So I want her to go and do the action that I'm asking her.
So I'm asking her to tidy my room.
And so I don't want any back chat from her.
Just wanted to go away and tidy the room,
could perform the action.
Does that command ever throw un handle's exception?
Sometimes they have the door shut in my face.
Yeah, so yeah,
so this a couple of times,
we'll be nice if my daughter did talk back to me.
One of them would be if she didn't quite understand
what I was asking her to do,
that normally would come back as a what?
Then there's, if she's done it,
then brilliant.
I'd like to know that it's finished
and that she's performed the action that I've asked
and not just sat on her phone talking to her friends.
And then there's the last one,
if the house cat or if a bedroom catches fire
when she's tied in it,
I'd like to know that so we can put the fires out
and carry on.
And sort of those three things
mapped to sort of really,
really like success true, false.
So you could return that from command.
Any validation errors,
so she doesn't understand.
And then any exceptions that are thrown.
So for me, those are the only three things
that I really would like to get back from my command.
I haven't done sort of a talk about this a few times.
A lot of people always ask,
what about database generated IDs?
And I both love and hate that question in equal measure.
Well, you just pinched my next question.
I know the answer, but it's kind of,
I had to ask it because that's like the canonical,
is that the right word, canonical question
for this kind of stuff, isn't it?
I think so, yeah.
So yeah, it's, for me,
I don't generally let my database do anything now.
Good words all the way.
Good words all the way.
And I try and take any sort of,
I don't use store procedures.
I try and take any business logic out of my database.
Because to me, I always think it's just a data store.
It's a place I put data and information.
I don't want it to do anything else.
So for IDs,
I normally generate the ID as a good
while I'm generating the command.
So I know already what the ID is going to be.
So I don't need to return it.
There are cases,
if you've got a clustered index on an ID field,
you will lose performance
if you're putting in sort of un sequenced GUIDs.
There are packages, I think.
I've seen some packages,
a colleague sent me a package the other day
that was produced sequenced GUIDs,
which would help with sort of the clustered index problem.
But then for me,
I generally don't use SQL server
or haven't done for many years.
C'est toujours un database d'un document
comme CarseMos
ou quelque chose d'autre.
Ou même mon dernier projet,
j'ai utilisé beaucoup de tables.
Donc beaucoup de problèmes vont au bout.
Si vous voulez faire une exception,
dire que,
si un commande va retourner,
juste une ID,
rien que l'indice,
est-ce que c'est acceptable
ou juste que ça va contre tout ce qu'on a?
Je pense que si il y a une exception
qui est acceptable,
comme longs tu l'as documentée,
une des points que j'ai toujours créé,
c'est de ne pas vous dire
que vous êtes en train de faire un grand coup de marde.
C'est juste de dire,
que vous avez un bon readme dans votre repository.
Je pense que juste quelques lines
sur ce que l'intention était initialement,
c'est toujours bon.
Donc si vous avez cette exception,
mets-le dans un readme.
Le readme doit être un document de vie.
J'ai travaillé avec des gars
qui étaient très bons en faisant ça.
Et chaque fois que c'est un change d'architecture,
ou un pattern qui a été introduit,
ou évoqué,
c'est toujours documenté dans le readme.
Et ça doit être un peu de lines longs.
Mais juste mettre ça dans le readme,
je pense que ça donne l'intention de la prochaine développeur.
Ce qui était l'intention initiale,
c'est qu'ils peuvent se faire avancer
pour ne pas réinventer le rouleau
ou ne faire quelque chose d'inconstitue.
Ou ils peuvent juste prendre le code
et se faire un peu plus vite.
Oui, donc juste des choses comme ça
peuvent vraiment aider
avec toutes les exceptions
que tu mets dans les idées de l'intention.
Je pense que
il n'y a pas de rèdits rapides
avec toutes ces patterns.
Je pense que si tu peux communiquer
ce que tu as fait clairement,
pour que la prochaine personne
arrive et peut le prendre,
je pense que tu es bien.
Avec le readme aussi,
je pense qu'il y a un balancier,
si tu dois faire un readme qui est
comme un novel,
personne ne va le lire.
Il y a pas trop d'informations.
Donc il y a le bon balancier
entre ce qui est trop d'informations
et ce qui n'est pas suffisant.
Oui, c'est bien sûr.
Juste un peu de headings
sur le design
avec un couple de points de bouleaux.
Tout le monde a des points de bouleaux.
Je...
Je pense que les points de bouleaux
sont tous les temps...
Oui, et je pense que la prochaine personne
va apprécier la breveté de ça.
Donc c'est un bon tangent.
J'ai utilisé un note
qui s'appelle Workflow.
Je ne sais pas si vous avez entendu.
Mais c'est tout de même
la premises
autour des points de bouleaux.
Mais c'est...
Tu peux cliquer
sur un point de bouleau
et se dérouler.
Évidemment, tu as des points de bouleaux
mais tu peux dérouler.
Ça devient un grand fruit.
Oh mon Dieu.
Je dois ça dans ma vie.
La raison que j'ai stoppé
c'est parce que
ce n'est pas ce que je peux faire maintenant
mais
je n'ai pas supporté les images
et plus de richesse.
C'était juste texte.
Mais il y a beaucoup de shortcuts
pour le keyboard
et tu peux
se dérouler
à chaque niveau de bouleaux.
Le point de bouleaux.
Et...
L'ensemble du projet
dans ton note
était un point de bouleaux
à un point
dans ce point de bouleaux
de point de bouleaux.
Mais ça n'a pas l'air
parce que tu peux mettre un marché.
Il y a beaucoup de...
Il y a beaucoup de
choses à manger.
C'est juste
une grande hierarchy de notes.
Très puissant.
Oui, un autre tangent
que tu as mentionné.
Donc moi et Dan
ont eu quelques issues techniques
en essayant de faire
le recours de ce projet.
Oh, je savais que ça allait venir.
Oui.
Et ce que je n'ai pas
généralement pas dit
mais je l'ai juste remarqué
une des choses de la soundproof
se fait à la back
de la porte derrière toi.
Je pensais
que Dan s'affiche
vraiment bien.
Tout le monde.
Quick buy me coffee, quick.
C'est comme
aujourd'hui, c'est
c'est un des jours
un peu plus contexte.
On a commencé à faire un recours
et on a utilisé le Riverside
FM2,

le recours,
qui est comme
ce plateforme de podcast.
On a jumpé
dans les mêmes mikes
sélectées,
donc on a changé la mike
et la toute chose a crassé
et je n'aurais pas accepté
mon mike tout de suite.
Donc j'ai dû refaire
et je n'ai pas accepté mon mike.
Donc en le meantime,
on a eu des conversations
en refusant sur Discord,
avec moi en étant
très apologétique.
Et
mais ça ne devrait pas
fonctionner.
Alors maintenant, on est en train
de recourser sur Zoom.
Non,
on parle sur Zoom,
mais on recrute
individuellement,
localement,
et en
je pense que je vais utiliser
audition,
ou d'audacity.
Oui,
j'ai toujours voulu
comment ces podcasts
sont recoursés.
Et je ne sais pas.
Je l'ai voulu.
C'est normalement beaucoup plus
smooth que ça.
C'est juste trop embarrassant,
mais de toute façon,
de toute façon,
mais puis,
et oui,
et puis ces taux
sont en train de bloutir
et le constat est tombé.
C'est tellement délicieux.
Oui,
il va devoir
avoir des superglues
ou quelque chose.
Cool.
Sur cette note.
Sur cette note, oui.
Oh,
donc sur cette note,
changer de sujet
pour mes
beaucoup, beaucoup de failures.
On va voir
QS.
Est-ce que
vous vous récliez
pour la code
pour se dégager
cette séparation?
Ou vous utilisez
comme un library
comme
Mediator ou quelque chose?
Oui,
donc il y a
il y a quelques libraries
là-bas,
comme Mediator.
Il y a un autre qui
que
tous vos listes
ne savent pas.
C'est ce qui est
Brighter et Barker.
Ceux sont les deux
grands lesquels je sais
de la N.O.A.
Il y a Mediator,
dans mon expérience,
qui a un très mauvais
réputation
pendant
sa implementation.
Et je trouve que
c'est
le moyen que les gens
utilisent
moi-même, je pense,
c'est le mauvais.
Je pense
que les gens disent
que c'est beaucoup
de libraries de Jimmy Bogard.
Autumap a été
l'autre.
J'ai
vu des impérimétations
terriblees de ça.
Je sais,
Nick Japsas a eu
beaucoup de fun
de prendre le micro
de Jimmy, je pense.
Oui.
Donc oui,
donc les libraries
sont les moyens de la
façon de aller.
Je
j'ai
mon set de classes
que j'utilise
pour implementer
et ça ne
n'a pas vraiment
fait que ça.
Si vous utilisez
un peu de magie
d'I
juste pour
passer
un command
ou un
commandeur
ou un
commandeur.
Oui,
donc vous pouvez
faire ça.
Et en parlant
des commandes,
chaque commande
et chaque commandeur
ont
sa propre commandeur
où tout le
logic business
s'y passe.
C'est un chose
que j'ai
spécifiquement
aimé
sur ce pattern.
Vous avez
un commandeur
ou un commandeur
qui est juste
un
plan de
plan de
objecteur
ou un
record
ces jours
plutôt que
une classe.
Et puis
ça a juste
l'information
et
le commandeur
ou le
query
de
poursuivre
les réquises.
Et puis
votre
logic business
donc
en parlant
on
juste
vivait
dans le
commandeur.
Une chose
que j'aime
sur ce
genre
vous avez
le commandeur
vous avez le commandeur
vous pouvez
vous pouvez

l'anglais
dans le nom de
des choses.

ordre
producte
ou
des invités
ou quelque chose
sur ces les
les
donc ça vous

une langue
dans votre classe.
Cette classe
juste
fait
ce qu'on veut.
Et
si vous avez besoin
de
penser
sur les
principaux

qui ne
je ne
pas
souvent
pour être
honnête
parce que
vous avez
ce commandeur
et vous avez
le commandeur
si vous avez besoin
de l'utiliser
dans une
version différente
de ça
vous n'avez pas besoin
de changer
ces classes.
Vous pouvez
laisser
tous vos tests
simple
et
et
vous pouvez juste
créer
une nouvelle
nouvelle version
de ça
l'a été
l'a été
comme si c'était
l'ordre
de la classe
l'a été
l'a été
l'a été
et puis
je pense que
les gens
sont
plus écrits
de faire
choses comme ça
et qu'ils
auraient plutôt
changé
les codes
qu'ils ont
mais parfois
juste
laisser
laisser
la code de travail
où
il est
et créer
une nouvelle
c'est
c'est
brillant
ce qui est
pourquoi
une des causes
où
j'aime
ce secret
vous avez
ce genre
version 2
peut-être
sur un
fonctionnel
ou quelque chose
pour qu'on
soit
le swap
pour la nouvelle version
ou un baccord
de très vite
et puis
peut-être
de la V1
une fois
vous savez
que tout est
en train
oui
c'est


de mécanismes
pour
faire
la feature
de l'in
si
vous
vous
vous


l'API
puis
dans votre
contrôler
juste
avoir
un
toggle
dans
là-bas
c'est
ce
version 1
ou
version 2
et
vous
vous
vous
vous
vous
vous
et puis
marquez
ce qui est
obsélite
c'est ce que
j'ai
tendu
à
faire
et marquez
votre code
c'est
obsélite
quand
vous
vous

et juste
laisser
un moment
vous ne
ne
regardez

teşekküré
,-
Terminé

vous
eli
mais beaucoup de Anti-Exenaus et donc il n'est pas juste pas le cas
j'ai дома moi, il n'y a pas de这个
Putoh !
Je l'enschaft que ça ne me plaît pas avec ça
une destination dramatique


elle connaît bien cette élève
et cette là-basie qu'on a


que c'est ça
j'ai parlé d'un millier de fois, c'est de faire tous les side effects dans votre ligne de code.
Ce sont les choses que l'on logique, c'est le grand.
Je vais expliquer les side effects.
Les side effects ne sont vraiment pas les principaux événements.
Donc, le bi-product, on va dire que c'est un bi-product, command, command, handler,
vous voulez juste que ce handler soit juste le code pour acheter le product.
Si vous avez besoin de vous envoyer un message à un équipe de profondeur,
comme un SMS ou un email, c'est un side effect.
C'est quelque chose qui se passe comme un effect de la main qui se passe.
Je ne pense pas que vous devez mettre ce genre de choses dans votre handler.
C'est comme ça que vous allez avoir à ce point
qu'on a un class de service, c'est-à-dire que c'est mon nemesse,
avec des milliers et des milliers de codes,
parce que c'est comme, oui, ceci est un moyen de faire ce qu'on a.
Mais aussi, nous allons faire ces autres 20 choses après le facteur.
Ils sont tous side effects.
Donc, je pense que, en handler, en gardant le petit et le concice,
juste faites ce que vous avez besoin de faire.
Encore une fois, retournez au TDD.
Si votre test a passé, commencez à faire un code.
Je pense que c'est sympa d'avoir un petit amount de code dans ça.
Un peu de choses que j'ai réveillées ces jours,
j'ai 10 lines de code dans l'étude d'un mode de Handle, et c'est ça que nous avons fait.
Mais le source secret, c'est le côté d'événement.
Les événements sont un topic massive.
Il y a beaucoup de différents types d'événements.
Mais dans l'événement de CQS,
ou vous pouvez le dire, un événement domainé,
c'est juste une note pour les autres parties du système
pour dire que quelque chose a été passé.
Donc, si vous avez fait ce biproduct,
c'est un exemple terrible, ça semble comme un biproduct.
Le commande de l'ordre d'ordre, on le referme.
Vous avez fait un ordre dans le biproduct,
et vous voulez avoir un événement qui se dit « thing ordered ».
C'est comme en utilisant l'inglice.
C'est un pass-tent.
C'est ce qui a été passé dans le passé.
Et vous avez changé les mots en le nom de votre commande.
Vous vous dites que vous avez ordré notre bipédé.
Vous vous firez un événement qui se dit « thing ordered ».
Et vous pouvez avoir beaucoup de Handlers qui l'entendent.
Vous avez besoin d'un plus que un bipédé,
après que votre main est portée,
vous n'avez pas besoin de mettre tout ça en classe,
ou en méthode.
Vous pouvez avoir un événement,
un événement pour beaucoup,
vous avez un événement pour les Handlers
pour faire toutes les choses différentes que vous avez besoin de faire.
Vous pouvez envoyer un SMS,
un email, un custom, etc.
C'est là que vous pouvez vous protéger,
vous avez besoin d'un code,
vous avez des classes petites,
que vous faites juste ce qu'on dit.
C'est ce que vous avez dit,
ne faites pas bien.
Je ne pense pas que ça doit être bien.
Je pense que ça doit être bien,
pour passer votre test.
Et puis arrêter.
Ou alors vous ne pourrez pas faire trop.
Je pense que ce qu'on dit,
ce qu'on dit, c'est un événement pour les Handlers,
parce que, comme vous le dites,
quelque chose a été fait,
un ordre a été créé,
ou ce qu'il y soit,
c'est que ça a été évoqué.
Et puis, on a l'a évoqué,


















parce que ça sort de,
ça me donne une question,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,

c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,
c'est ce qu'on dit,


c'est ce qu'on dit,
c'est un événement pour l'ельзя.

j'ai il argued dans la spécif Guanadio,
pour le repos.



c'est la texture de werat,
c'est le «C rouxDown Schlossoffery],
on mediait, mais je ne sais pas si ils ont été explicitement mediés,
ils ont juste été en conversation,
une fois, un épisode avec Nick Chapsas,
et on a brûlé tout le monde dans plusieurs topics différents,
un de eux était medié, il y avait un bunch d'autres.
Donc, plutôt que d'avoir un sujet avec différents sub-topiques,
mais oui, on a bien sûr été medié.
C'est un de ces libraries qui se sont faits en conversation,
donc oui, c'est bien bien découvert.
Oui, j'étais assez gâté quand je l'ai trouvé,
parce que j'étais en train de faire ce que je fais,
et je pensais que je vais juste vérifier si il y a quelque chose dans le monde qui le fait,
et oui, je suis gâté, j'étais gâté en même temps.
Je dois dire que le moyen de l'utiliser medié,
je n'ai pas besoin d'utiliser medié,
je l'utilise parce que tu te laisses en dessous de la boîte,
et ça force un potentiel,
mais je pouvais également faire le même potentiel
par avoir une classe qui s'appelle « Something Handler »
et avoir une méthode qui s'appelle « Execute »
je n'aurais pas besoin d'aller à un library comme « Mediator »
mais je pense que quand tu as beaucoup de différents développeurs,
et peut-être qu'ils ont utilisé « Mediator » dans le passé,
c'est juste un path en commun qui est facilement understandable,
la documentation autour de ça, tu es force.
Si tu utilises un « Mediator » « Handler »
cela arrive d'une interface
et tu es force d'avoir cette exacte « Execute » méthode.
Mais avec « Handler »
si c'est « Mediator » ou tout ça,
je suis un grand fan de ce path en qui c'est un « Handler »
« Application Logic » « Single Responsibility »
« Support de pensée d'injection »
le nom de ce path est très bien ce que c'est fait.
Je peux regarder dans ma solution explorer dans l'ID
et très rapidement trouver ce que je veux trouver
parce que c'est juste tout consistant.
Et d'autres choses comme
« Mass Transit » a un concept de « Handler »
qui s'appelle « Consumer »
et c'est exactement le même path
et ça me sent très familier.
On a dit « Mediator »
« The Brighter » aussi.
Exactement le même path.
Donc, en regards à la technologie,
et tu as dit que tu implementes ça à toi-même
mais tu as encore un « Handler »
ce whole « Pattern of Handlers »
je l'aime vraiment.
Oui, et c'est quelque chose qui est
un des choses que je dois dire
qui appelait à moi quand je first
j'ai trouvé ce path
parce que les gens
tous ont des défauts pour avoir cette classe de service.
Et ça devient un « Dumping Ground » pour tout.
Et c'est toujours comme
« Order Service »
« Product Service »
et c'est un « Entity Name Service »
Je vais vous évoquer
votre « Nemesis of Service Class »
et vous voir avec
« Manager Class »
Mais c'est toujours
comme si vous avez dit
« Manager »
et c'est comme 5 billon de l'alimentation.
Oui, je suis heureux
que je fasse « Escape Manager Class »
je pense à cet extent.
Mais oui,
« Service »
je pense que c'est les deux
et les mêmes, vraiment.
C'est un « Rose »
par n'importe quel nom
mais je pense que c'est un « Thorn »
par n'importe quel nom.
Oui,
je pense que
en retard,
quand les DDD
ont commencé à devenir un « Thing »
les gens disent
« OK, ils ont lu le « Blue Book »
et ils pensent
« Il y a un « Service Class »
C'est ça.
C'est où tous mes logics vont aller.
Et sur l'occasion,
je vais aller sur les « DDD Books »
Je l'ai fait par Vone Vurnin
qui est implémentaire du design
dans le domaine.
Et je pense que l'un des choses
que je vais aller sur
et encore en ce livre
est la définition de un « Service »
et ils ont...
Je pense que c'est un « Application Service »
et il y a un autre genre.
C'est soit le domaine
ou le service business
ou quelque chose dans ces lignes.
Et non de ces définitions
ne marient pas
à ce que je vois en code réel.
C'est juste un « Dumping Ground »
pour tout.
Et il y a
beaucoup de moyens pour faire un « Thing »
et...
oui,
il y a un point
où c'est un « Mess »
Un autre « Thing »
que je vois en ça
est que
les gens souvent ont des « Anemic Domain Models »
ce qui est un autre « Thing »
que je l'ai écrit
un de mes
ma préférée « Projects »
il y a des années auparavant
que nous avons écrit
nous avons eu des « Service » classes
avec un « Anemic Domain Models »
donc un « Domain » model
qui est juste
classes avec des « Getters »
et des « Setters »
n'ont pas d'objet
dans les actuales « Domain Models »
eux-mêmes.
Et nous pensions que c'était bruyant.
Et puis
je l'ai fait
parce que je suis un contracteur
et je suis allé au contracteur
de cette même company
et après beaucoup de années
de gens
qui suivent ces « Patterns »
et qui font les mêmes choses
et c'était juste un « Mess »
et
donc je suis maintenant un grand avocat
qui a un « Domain » model
un « Strong Domain » model
avec la logique
entre les « Entities »
et les « Aggregates »
parce que puis vous savez
vous ne pouvez pas changer
ce modèle
sans aller au bout des règles de business
vous devez trouver un « Method »
sur ce modèle
ou ce « Entité »
ou « Aggregate »
donc je pense que ça sort
de l'invente
dans les « Handlers »
où vous avez
votre « Handler »

loader une « Entité »
ou « Aggregate »
ou quoi que vous avez
et puis il vous cause
le « Method »
donc vous avez
des places où
votre logique
sort de réalisément existe
sort de
comme
la mutation de l'entité
est faite
par l'entité
et puis le « Handler »
cause ce « Method »
pour faire cette mutation
et c'est
de faire des places
où les choses
sont faites
pour vous arrêter
encore ces « Domain »
de la code
et
de l'horribilité
de la « Handler »

je pense que
quand j'ai commencé
à utiliser « Mediator »
pour un petit moment
j'étais obligé de le faire
moi-même
avoir
l'application logique
dans un « Handler »
« Mediator »
qui cause
un
je dis
« Les listens ne peuvent pas
voir moi faire ça
»
« Repositorie »
ce qui fait
l'entité
de la « Framework Code »
et maintenant
je me mets
l'injecteur
dans le contexte
dans mon « Handler »
et je le fais
parce que
l'entité de la « Framework »
est une construction
et c'est
juste de sauver
beaucoup de temps
plutôt que de la « Framework »
avec les « Headaches »
et les « Repositories »

oui
c'est très bien
où j'ai été
dans ces jours
j'ai été
une des premières choses
que je fais
quand j'ai
mis mon « Stool »
dans la « Repositorie »

vous ne vous en avez pas besoin
comme vous le dites
le contexte de la « Data »
est déjà un abstraction
et j'ai vu les gens
râper ça
dans un « Unit of Work »
mais c'est un « Unit of Work »

je me dis
« Qu'est-ce que vous faites ? »
oui, je
en général
j'injecte mon contexte de « Data »
dans le constructeur
pour qu'il soit cool
ou ce n'est pas
qu'il faut
faire mon mutation
et remettre le « Back »
je pense que ça fait un grand différence
parce que ces « Handlers »
sont très
petits
comme vous l'avez mentionné
la responsabilité
il y a
probablement
10 lignes de code
il n'y a pas beaucoup
et avec
« Entité of Work »
le « Link » est assez succinct
c'est juste
beaucoup
je vais retourner
au « Kiss »
c'est juste de la « Simple »
c'est très facile de l'éliminer
et de voir ce qui se passe
c'est juste
le « Life » est beaucoup plus facile
et
le code est beaucoup plus maintenable
oui, très bien
parfois je vois un besoin
où
une représentation
ou quelque chose comme ça
était advisable
ou était nécessaire, je dirais
et l'une des choses que j'ai regardé
c'est
Steve Smith
ou Steve Darliss Smith
a eu
une belle
« Specification Pattern »
pour faire ça
donc, créer un « Abstraction »
entre
votre logique de business
et votre représentation
et je trouve que c'est
une belle « Clean »
sort de pattern
pour travailler
avec
je n'ai pas vu ça
quand je vais
avoir un « Look »
et
mettre dans les notes de la show
oui, oui, je l'ai utilisé
une fois que j'ai utilisé
si je l'ai été parfaitement honnête
mais j'aime les idées
derrière cela
si vous avez besoin
d'avoir cette sortation de séparation
et ne pas
injecter votre contexte de données
donc, une chose
en pensant
sur les commandes de les handlers
et en avoir un très petit code
ou un least code
possible dans lesquels
je vous remercie
d'avoir une autre chose
que j'ai appris
de Steven van derz
et
c'était
ce « aspect orienté »
programmé
et c'est juste
une forme de séparation
de concerns
l'exemple d'architecture
que j'ai toujours donné
c'est de l'enquête
je ne sais pas de vous
mais je suis dans
des situations où
la première chose
que vous faites
dans le projet
c'est
que vous vous dites
« loga.information »
et puis vous donnez
le nom de la méthode
et peut-être
une information
sur les paramètres
qui ont été passés
ou quelque chose
mais ça se trouve
très malade
il y a
beaucoup de répétition
et
pendant que je ne suis pas
un avocat
d'en train
je pense que
c'est mieux
ou c'est mieux
d'avoir un login
et des validations
sorties d'une place
donc
avec nos commandes
et nos handlers
nous pouvons
entre les commandes
d'avoir un commandeur
nous pouvons avoir
un handler logant
et un handler validé
qui apprécie
dans le système
ils apprécient
d'être
le même handler
et puis
cela utilise
ou peut-être
utiliser le pattern de décor
dans une façon pipeline
très bien
comme un sort de
pipeline de la mode ASP
où vous pouvez
poursuivre les choses
qui ont été élevé
dans l'ordre
donc maintenant
vous pouvez juste
avoir votre login
dans un endroit
donc le commandeur
va passer
à ce
login
handler
et le handler
n'est pas vraiment un handler
et puis
il va faire
le login
donc il va loger
tout ce qu'il faut
et puis il va
apprécier
le même handler
et je pense
que c'est un meilleur
moyen
j'ai toujours tenté de dire
que si vous voulez
changer votre système de log
bien
c'est comme
l'histoire de l'old
ce que vous voulez
changer de base
et tout
ça peut-être
ça peut-être
peut-être pas
mais ce n'est pas
tout ce qui est
c'est
ce qui est en train
de faire
son propre place
donc
tout votre login
est appelé
d'un endroit certain
et puis vous pouvez
changer de
validation
ou authentication
ou cash
tout dans cette pipeline
tout en étant
appelé
de cet endroit
donc
de la
code
simple
petit
et sorti
concis
ou focus
je dois dire
focus
sur le travail
que c'est en train
et
laisser les autres choses
se faire
avec ce qu'ils ont
voulu faire
oui
je pense
que
avant
j'ai dit
avec
mediator
le manière où j'ai utilisé
mediator
je pouvais juste
avoir une classe
et
s'en parler
quelque chose
je n'ai pas pensé
sur les
pipelines
où ils ont été
appelés
behaviors
ce qui est
ce que vous avez
déclaré
c'est
vous pouvez
créer un pipeline
de
je pense
si vous avez
pour
le
et
donc
molt
ma
SARAH
dans
without

mais peut-être aussi, et de stress.
Mes livres ne peuvent pas être aussi travaillés
comme Mediator ou Brighter.
Je ne peux pas dire Mediator, c'est le seul qui est là.
Je pense que Brighter est un peu plus...
Tu parles de processus.
Je pense que Mediator est un processus
où Brighter peut connecter à des proches massives
et tout ça.
Je pense que la comparaison est probablement plus Mediator.
Avec tes interfaces et les mots de la version DIY,
que les crossings ont des archimènes
ou pionnage et pasteur?
...
Celui-là, c'est ouvient en enfant.
Voilà, comment j'en vais.
C'est en ce moment que je pense qu'on va plus ill trapérent.
J'genderais aussi mes decision.
Voilà.
ou avoir leur propre...
Il y a des magiques trop magiques, je pense,
dans un projet qui n'est pas toujours bien.
Donc, comme un médateur,
quand il est bien et fait le travail,
il y a des magiques qui sont derrière,
que les gens ne peuvent pas comprendre
comment ça fonctionne,
ou...
ou...
ils peuvent vouloir savoir plus.
Bien sûr, les codes sont en ligne,
mais vous devez apprendre quelqu'un d'autre.
Donc, juste si vous avez besoin de ça pour être basé,
alors, en writing,
c'est assez facile.
Et, oui, c'est très bien.
Donc,
évidemment, si vous avez un gros mode de balle,
il y aura beaucoup de travail
pour en faire un gros mode de balle.
Et vous avez des managments,
qui ne sont pas très bien compétents,
ce qui signifie un mode de balle.
Qu'est-ce que vous pouvez faire pour que vous puissiez vendre
en attendant le temps de se faire sortir de ce problème,
de l'adversation ?
Donc, il y a quelques choses
qui vont définitivement arriver
à votre système,
ou à la compagnie et à sauvage.
Donc, le total de la faute de l'adversation
de l'adversation ou de l'adversation que vous faites,
c'est un peu de problème.
C'est évidemment avec le temps de votre argent
et en avoir à faire un gros mode de balle,
chaque fois que vous voulez faire un changement simple,
ça va prendre plus longtemps.
Donc, la production va aller en bas,
vous allez en prendre plus sur les développeurs.
Vous êtes en train de vous donner vos features,
les clients ont été promis sur ces features,
comme des salaires que les gens aient aimé promis,
et puis ils vont prendre beaucoup plus longtemps
pour sortir,
ce qui sera un bon client.
Ce sont des choses que vous pouvez facilement vendre
pour les entreprises.
Je pense que l'autre chose qui est peut-être
un peu plus difficile
ou moins évident
pour les gens qui ne sont pas dans la industrie de la tech,
c'est la dévélopérance des développeurs.
Je pense que le travail dans le système
et ne pouvoir changer,
et ne pas donner le temps à changer,
c'est assez détrimenté
pour développer la dévélopérance.
Je sais que je suis dévélopéré
avec le point de place de la date,
parce que je n'ai pas le temps de le faire,
ni de ne pas donner le temps
pour changer les nécessaires.
Et les développeurs vont se laisser,
et je suis allé voir des entreprises
où les développeurs ont été.
Je suis allé voir une entreprise
où les développeurs de 10 ont été
juste allés tous les mêmes jours.
Ils se disent qu'est-ce qu'on va faire,
et nous avons commencé à regarder.
Ils me disent qu'il y a beaucoup de problèmes,
et ils disent qu'on n'a pas le temps
de faire des problèmes,
on va faire des features.
Donc oui, je suis allé.
Mais oui,
je pense que l'ultime chose,
si vous n'avez pas le temps de le faire,
c'est que vous vous arrêtez de réévaluer.
C'est le point où la traction a été stoppée complètement,
et vous ne pouvez pas faire des changements
sans introduire plus de bugs.
Et les bugs que vous introduisiez,
vous trouverez que ça va prendre plus de temps
pour être trouvé.
Et puis ne pas être puable de se faire fixer,
parce que vous avez écrit
comme ça,
que les systèmes...
C'est un grand bug, je pense.
Et je pense aussi...
Je pense que...
Une des choses qui peuvent arriver,
c'est que la performance peut se faire descendre.
Je vois un pire remarquable de code,
où ils ont injecté
une source de dépense d'injection,
dans un autre scope,
et puis ils ont basically
scopé dans un scope,
dans un scope,
et ça a juste affecté la performance massivement,
parce que c'était essentiellement un petit objet,
de nouveau, de nouveau.
Donc oui, avec ces grands balles de messie,
la sécurité peut se faire descendre,
la performance peut se faire descendre,
et le développement de la joie
peut définitivement se faire descendre.
Ça peut être bien de la fin de vos termes,
et ça me rappelle de vos slides,
où,
en lieu de
des murs,
ils étaient...
Ils étaient en mode de pauvre.
Les grands balles...
Oui, je...
J'ai spent beaucoup de temps
en essayant de faire ce talk
sans mentionner ce mot,
surtout avec ces poires emojis.
Il y a...
Il y a souvent, je veux dire,
utiliser des explotives,
mais oui, ne l'en fais pas.
Oui.
Quand tu parles,
et que des images de toi
étaient à la génération de l'AI,
c'était assez fun.
Oui, c'était une situation bizarre.
Je l'ai écrit ce talk
un peu d'années,
et je n'ai pas fait ça
pour...
Je l'ai fait tout de suite,
et je ne l'ai pas fait pour longtemps.
Donc,
quand j'ai eu la chance
de faire ça,
je me suis réveillé sur les slides
et j'ai expéré le talk,
et ça m'a fait un peu plus
intéressant.
Et je pensais,
je vais essayer
cette AI.
Donc, je pense que c'était dali
que j'ai utilisé.
Je n'ai jamais fait
une sorte de...
Je n'ai jamais fait
que de chat GDP,
je n'ai jamais fait
que dali,
que d'image génération.
Donc, je pensais,
on va voir ce qui se passe ici.
Et puis, oui,
je suis arrivé dans ce très
bizarre cas
de me demander
plus et plus
bizarre des choses,
jusqu'à ce que je suis arrivé
avec un de mes slides
qui s'est dit
de râper le balle de mœur
dans les tests.
C'est un bon endroit
pour commencer
si tu vas faire
un petit balle de mœur
et je pense que c'était
l'image
que
c'était pas un balle de mœur
que c'était de râper.
Et, oui,
je pense que j'ai dû
arrêter,
je l'ai fermé
et je n'ai pas été
enversé,
en fait,
pas pour une génération de mœur.
Je ne pense pas que je me souviendrai.
Je vais dire ce que je vais dire.
J'ai été en train de
utiliser la tour de la course
récemment
et c'est insain.
En fait,
live sur le podcast,
je vais essayer
de générer un grand balle de mœur
en tour de la course.
Évidemment,
je vais éduquer
pour que ça soit un peu plus
consommable.
Qu'est-ce que nous avons promis ?
J'ai toujours trouvé
que
faire quelque chose sur la table
quand les gens ne peuvent
qu'il n'y a que un bon moyen
de faire un podcast.
Oh, c'est ça.
C'est ce que je peux éduquer
et juste faire
un petit tour de la course.
Qu'est-ce que nous avons promis ?
Je vais mettre l'image
que ça génère
dans les notes de la show.
Un grand balle de mœur.
Je dois...
Qu'est-ce que nous pouvons ajouter
pour faire un peu plus
intéressant ?
Je ne sais pas.
J'ai demandé
de faire un piece de
l'hiver
dans ce bizarre endroit.
Donc, je ne sais pas.
Je vais mettre un grand balle
pour voir ce qu'il vient de faire.
Mais oui,
le tour de la course
est insain.
C'est un peu...
Je ne sais pas
si vous avez vu
quelque chose de ce qui génère,
mais ça ressemble
à un peu de réalisme.
Nous parlons de
l'HGPT
en faisant programme
pour faire des works.
Ce sera
un artiste pour faire des works.
Je vois.
Je n'aime pas ce art de Asci.
Ce n'est pas très bon
avec les mots
et les personnages.
Il les a tous trompés.
Dali fait ça.
Je suspecte
que ce soit quelque chose
de ne pas être
puissant,
puissant,
parce que chaque fois
j'ai demandé
de faire des trucs,
il le trompe.
Je pense que le moyen
progressif
génère des images
de la brosse.
Ce n'est pas bien.
Ah oui, bien sûr.
Avec les textes.
Oui.
J'ai essayé
de mettre un espaguet
avec un truc
que j'ai essayé de chercher.
Je ne sais pas
pourquoi c'est appelé
un grand ballon de mâtre.
Il devrait être appelé
un grand ballon
de espaguet,
de horreur.
Parce que c'est
ce qu'il est.
Euh,
je vais vous montrer mon écran.
Vous pouvez voir ça?
Ah oui.
Vous pouvez choisir
quel est le préféré.
Donc, c'est quelqu'un
de la faite de la carte.
Donc, si on fait
ça...
Est-ce qu'ils ont tous généré?
Oui.
Pas de quoi.
Vous voulez ceci?
Donc, c'est un peu
de scale,
ceci maintenant.
Ça ne tient pas.
Mais,
je sais,
c'était un super tangent,
mais je vais
inclure
le grand ballon de mâtre
dans les notes de la show
pour les gens à voir.
Excellent.
Est-ce qu'il y a quelque chose
que vous voulez voir
avant de nous mettre
dans les tips de la carte?
Non, ne le pensez pas.
Vous avez un tip de la carte?
Je l'ai.
Je vais aller
avec la code clean
par Robert Martin.
Je l'ai spenté
des années,
comme,
pas à l'évoquer,
mais je n'ai pas
vraiment
trouvé le temps.
Et récemment,
je l'ai récentré
au lieu de la Holiday.
Et
j'ai rien à faire
au lieu de la Holiday.
C'est incroyable.
Donc, je l'ai récentré
la code clean.
Ce qui était intéressant
était que
les premières quelques chapters
étaient très bien
comme mon présentation
ou mon tour
que j'ai donné.
Et je l'ai trouvé
beaucoup de similarities
dans ça.
Donc, oui,
je pense
que la code clean
est une façon de aller,
même si c'est juste
les premières quelques chapters
qui parlent de la code
et la carte de la carte
et de ce qu'elle est.
Oui, donc c'est mon
petit tip.
Je pense que j'ai lu
ça un très, très long temps
d'anime.
Je vais définitivement
inclure un lien
dans les notes de la show.
C'est un bon pick.
Donc, mon pick
n'est pas vraiment
pas vraiment de développement,
mais je ne pense pas
d'autre chose.
Mais j'ai fait
beaucoup de
vidéos de contenu de la

Et en en apprendre
sur la vidéo.
Et
il y a un 3d editor
qui est
juste comme bon
comme la première pro,
qui est assez expensif.
Et beaucoup de gens
sont en train de
faire de première pro
pour ce qui est
un résolve de la vente.
Et il y a une version de paix
mais une version de 3
qu'on n'a pas besoin de plus.
Je sais que,
comme développeurs,
on sometimes
a des requises
pour créer des vidéos.
Et,
si ceci est libre,
c'est juste
un bon piece de software.
Quoi que tu as
d'exprimer
de quelque chose
comme la première pro,
ce genre de
niveau de software.
Donc, je vais inclure
ceci dans les notes de la show.
C'est cool.
Je vais être
en train de le downloader
très rapidement.
Je suis un
utilisateur de première.
Et,
oui,
je ne pourrai pas
acheter de la vente
à ces jours.
C'est pour sûr,
pas pour le
truc que je fais.
Il y a beaucoup de vidéos
sur YouTube
qui ont l'air de l'utiliser
et beaucoup de gens
qui sont en train de
faire de première
pro.
Et c'est
incroyable
que c'est libre.
Il y a un studio de
Dvintia Resolve,
qui est
la version de paix.
Mais,
les features,
je pense que
la différence importante
est que
la version de paix
se débrouille sur le GPU.
C'est la version de 3D.
C'est une CPU.
Ah, OK.
Mais si tu as un bon CPU,
c'est bien.
Oui,
je suis sûr que les gens
ont eu le temps
de
rendre les choses
plutôt que
les murs
pour payer
pour un format.
Oui,
mais oui, c'est très bon.
Donc,
oui,
je vais le linker
dans les notes de la show.
Donc,
avant de rappeler,
où est le meilleur place
pour les listeners
pour vous acheter?
Si vous avez des questions
ou quelque chose.
Donc, je suis sur Twitter.
Mon
alias
est
c'est
parce que
je
je ne
n'ai pas vraiment pensé
sur ça
quand je
quand je
j'ai commencé
et linké
mat underscore
underscore
je ne
ne
pas vraiment
je ne suis pas beaucoup
mais je me réponds
à n'importe
n'importe les messages.
Donc,
je me suis pas mal.
Et tu es aussi
sur notre discord
maintenant
aussi
donc je dois vous
apporter
et vous donner
la
tag
de la tag
dans notre discord.
Oh,
c'est fantastique.
C'est-à-dire que
je n'ai jamais utilisé
le discord
jusqu'à l'autre jour.
C'est-à-dire que
oui,
donc je
je suis toujours en train de
c'est comme
chaque
nouveau
chose
il y a beaucoup
de choses
qui se placent à vous.
Donc,
oui,
je suis en train de
avoir
cette tag de guest.
Préléent.
Nous avons move
d'aujourd'hui
les podcasts
et Donald Ock
avec la groupe d'usages
de la

nous sommes tous
sur Slack
nous avons move
d'aujourd'hui
sur discord
et c'est juste
mieux.
La chose que j'aime
de l'autre
c'est que
votre compte
s'étend sur
tous les différents
discord
que vous en
ils se n'appliquent
des serveurs discord
c'est comme une organisation de Slack
ce n'est pas un serveur
des instances
ou
exactement.

oui.
Mais votre compte
est sur ceci.
Donc,
si vous vous envoyez
un discord d'AMON
il n'y a pas de
le podcast
discord
ou le
discord de Donald Ock
où nous
on a un DMS
à l'intérieur
à l'intérieur
de ce instance.

oui,
exactement.
Oui,
donc
je suis en train de
faire plus
discordant
si c'est ce que c'est.
Oui,
peut-être,
peut-être.
Je pense que vous avez
inventé le verbe.
Oui,
oui,
il y a un
gagnant.
C'est cool.
Donc,
je pense que
c'est probablement
juste un peu de temps,
mais
oui,
merci beaucoup
pour
m'amuser
sur le podcast
et,
encore,
je vous remercie
beaucoup
pour tous les
défis techniques.
Non,
pas de problème.
Merci
d'avoir
moi.
Je ne dirais pas
que c'est un rêve
pour vrai,
parce que tu m'as dit
que je suis trop fan
de toi avant,
mais
c'était
c'était
un plaisir
de venir
sur un autre chat.
Tu finis
de vous coucher.
Mais tu dis que c'était
un rêve
pour moi.
Je dis ça.
Il n'y a pas de prouve.
Il y a un
coup d'oeil.
Je vais juste y aller.
C'est trop drôle.
C'est génial.
Et
juste un grand merci
pour tout ceux
qui l'entendent
et un
petit réplique
sur ce podcast.
Je ne peux pas parler maintenant.
Il est sponsorisé
par Everstack,
qui est mon propre
company,
qui permet de
faire des services
de développement et de consultation.
Pour plus d'informations,
visite Everstack.com.
Et si vous avez aimé
l'épidémie,
n'hésitez pas
à m'exprimer le nom
sur les médias sociaux.
Je utilise normalement
le hashtag
UnhandledException
et je peux être
trouvé sur Twitter
à Drakkan.
Mes DMs sont
ouvertes.
Et mon blog
d'Ancloch.com
a des liens
sur tous mes
choses sociales, aussi.
Et nous allons
inclurent les liens
sur tout ce qu'on a
mentionné aujourd'hui
dans les notes de la show
qui peuvent être
trouvé sur
UnhandledException
podcast.com.