Hey, everyone, welcome to the Unhandled Exception podcast. I'm Dan Clark, and this is episode
number 17. And today I'm joined by Ian Cooper, who's a polyglotte coding architect in London,
speaker and founder of the London.net user group. And today we're going to be chatting
all about TDD, Test Driven Development. So a massive welcome to the show, Ian. Thank you for joining us.
Hi, Dan. Good to see you.
Yeah, you too. It's good catching up again. I've realised actually then I didn't mention
Brighter as well, because on your Twitter profile it says Gov of Brighter.
Ah, we can probably drop that in the conversation at some point.
Maybe. Well, if I don't put you off too much in this episode, it'd be quite a good one to have
another episode on, I guess.
Yeah, that's true, actually. We should do that. Yeah, that'd be good. We're about to get v9 out of it,
and we'll start doing docs and stuff on the summer.
Maybe it'd be good for us to have a bit of a bit of a tramping the podcast circuit when we get v9 out to tell people
about what's in there and what's changed and stuff.
Yeah, that'd be good, because I think episode two, we had Derek Comart and talking about
Mediator and CQRS, and Brighter definitely came into that conversation, so we could
have an episode dedicated to it.
Yeah, OK. Cool.
So today we're going to chat about TDD, and Ian and I were discussing beforehand, and
recently, a few years ago, I was working with a company, which was actually the first company I've
worked for where everyone did TDD for everything.
And we thought it would be good if I went through my experiences here and then we both then
dissected it as part of this conversation, the different bits and pieces.
And I did see your talk at IO.net, a virtual meetup about where TDD went wrong.
And there was certainly a lot of stuff that resonated with me based on my experiences at this company.
I feel like a TDD doctor.
I'm here to treat the patient.
But yeah, let's do it.
Well, that's it.
I think because I've seen quite a few of your different talks now over quite a few years now.
And out of everyone that can think of to get on the show talking about TDD, your name was just the first one
that you've ever heard.
So I'm so glad that you were good enough to find the time to join us.
No, I'm always kind of pleased to try and get the message out, because I think there's a whole lot of people
in who are struggling with TDD and ways that don't need to.
And I'd really like to help them stop struggling.
So it's really, really great to have the opportunity to do that.
Nice. Nice.
So look at my example.
So I've personally been developing for quite a long time and I've tried to write testable code for
quite a long time, too.
So like using like solid principles, dependency injection, blah, blah, blah.
So this meant that when I started with this company, which was the first time I've actually done
proper TDD, I didn't really have a big technical learning curve as such, because I already knew how to write
tests and testable code.
I just hadn't done TDD full time.
And there were quite a few different observations I had along this journey.
And the first one was like, whoa, we're spending 90% of our time writing tests.
I could have written this feature in an hour, but it was spending days on it.
But then I started to see the benefits.
Like we had hardly any books, which was a lot different than a lot of other large code bases.
I've worked on where we've had a massive buildup of books to fix at the end and big crunch periods.
I also found that we could refactor more safely and the test would catch a lot of the things we broke.
So it made quite a big difference there.
But at what cost?
It just took ages to write these tests.
We could safely refactor, but the refactoring took ages too, because we had to refactor all the unit tests as well.
But as well as doing unit tests, we were also writing integration tests.
So this was asp.net, called WebAPI Heavy.
And we were using Docker to spin up the databases for the integration tests to run against.
And one thing I observed was that a lot of the time the integration tests would render a lot of the unit tests completely redundant.
And I'd also find that the integration tests would be much more naturally requirement based rather than testing implementation detail.
They were faster to write and covered a lot more code.
And also there were a lot less mocking required as well, which is something I'm sure we can go into later.
The pros and cons of mocking.
A bit later that year, I saw your where did TDD go wrong talk.
And a lot of this resonated a lot with the experiences that I've just kind of observed.
I felt I learned quite a lot in that period about how I find I can do TDD without spending 95% of my time just writing.
Tests, and to go live date, almost being three years time because of that.
So yeah, I mean, it obviously mirrors a lot of my experience.
So now I started talking about TDD because I had some experiences to you.
And I went back to try and investigate the experience of TDD and where it came from for me.
That's very much, I think it's a very common store.
And what I did really to further my way through this, I went back and read Kent Beck's books.
Kent Beck, who's the kind of father of XB, the father of TDD,
Tent always says he rediscovered them, right?
He doesn't say I reject you these ideas.
I was someone that brought the public attention.
But his book TDD by example, I went and reread it.
Now, it's an interesting book TDD by example, because I've seen some reviews saying
I didn't really understand TDD as a result reading this book.
Don't get this book.
And what's interesting is, Kent had been doing TDD for a number of years at the time he wrote the book.
And I think it is a book that is perhaps more powerful for people that have done a little bit of TDD already
to kind of explain how TDD ought to be working.
It was like a more a masterclass in getting TDD right.
So to go back to your kind of problem space, right?
That's for happened to me a lot, right?
Big test weeks, first ship version seems to be fantastic.
High quality, low defect, hard to maintain because every change requires
making a lot of change, these test code.
Often three times as much test code as real code, slow product owners saying couldn't we skip the test
this time round, that kind of really common experience.
So you know how they refer to sometimes null as being the kind of billion dollar bug or what?
Effective, I think TDD has a kind of billion dollar bug equivalent.
And that's the word unit test.
So what's interesting is if you go and read Kent Beck's book, he never talks about unit tests.
He just talks about tests.
He has one kind of moment in the book where he uses the word unit test.
And it's basically to say tests as I describe them here are not unit tests.
And he says, though, although I sometimes refer to them as unit tests, what he means is verbally
in conversation, he occasion, he will talk about unit tests.
But what the practice of TDD is not around unit tests.
So what I want to do is take a step back and understand what unit tests are.
So in classical testing methodology, what you do when you're testing a system, usually in the test
after what it's waterfall, someone's built most of the system, QAs now going to look at it is the QA team
would come along and the system would divide into modules, whatever module is going to be
right in our system, may depend on our platform and language.
And they treat the modules as a black box.
And they tell them to test this module works.
And I want to put things into the module, get things out of the module and check for the
inputs I put in, I get the right outputs.
Now, in order to make sure that any problems with this module are this module, then I declare
the module to be unit and I say it from any other modules.

So that notion of saying, I'm going to use some kind of mark or stub to replace all the
dependence of this module.
So I know that if there's a defect, it's caused inside this black box.
That's unit testing.
And of course, it's only one module in my system.
So that I want to do is essentially say, well, what happens when these two modules talk to each
other?
Right?
I know this one works on its own, this one works on its own.
What happens when they talk to each other?
That's an integration test.
And the purpose of integration test is just what isn't a problem in module A or module B.
I've got tests to work for those.
So if a test now fails, it's the integration between the two modules that's incorrect.
Then you get to a system test, which says, when I have all these integrated modules working
together, then essentially I can prove the whole system works.
And that's a really valid approach to doing testing, but it has nothing to do with test
development.
And the problem was we took these ideas and said, well, what's the unit from TDD?
Oh, well, it's got to be a class.
It'll be the class, right?
Great.
So I need to isolate my class so that I can localise all defects that I get in testing
to be in that class, which means I have to mock out any other class that I deal with.
And as a result of mocking at every class that I deal with, that means I have to inject
all the other classes that I deal with.
And I, you know, I'm a good OO programmer.
I want lots of classes that have just one kind of responsibility.
So that means if this thing needs to talk to other things, I'm going to have to get to a whole
load of things.
Wow, I've got this massive graph of things I need to inject.
I better build a tool that does that.
I'll call it an inversion of control container.

And this whole edifice is really built around this notion that I'm doing unit testing.
Right.
And we've built a huge amount of cost into all the systems we design because of this
idea of unit testing.
All right.
So what I want to tell people is that is not how TDD works.
So test driven development focuses on something that the TDD community back in the
nautis coined the term developer or programmer test for.
And developer or programmer test says this, I'll let you have some kind of requirement.
Usually, let's say an agile world, that's some kind of user story or a lightweight
use case, but it can be anything you want.
Someone wants you to build something.

And in order to build that thing, I, it has some acceptance criteria.
When you've built this thing, all these, you know, it passes all these acceptance
criteria.
In general, what I'm doing with something like TDD is I'm saying, okay, I want to
pick one of these acceptance criteria such that I can make, right.
The smallest amount of code I can.
Towards the point, solve implementing this requirement.
So I picked the smallest bit I can, because I want to work incrementally.
It's want to keep, to make a little change test, make a little change test.
So I picked the thing that gives me the smallest possible version of that
requirement, right.
And quite often what people do, they start with something that says like, you
know, I just need to get something that basically just spins up a test, right.
So I quite often, when I teach this a bit, I use the example of game of life, right.
In game of life, you may go about the rules, but you have a board, you apply
some rules, you get a new board plus, effectively sells live or die.
And I always say, with the first test, I want to start with is dead board
produces dead board, right.
Really simple requirement, what it gets me is writing a very tiny amount of code.
And that code is based off requirements.
It's not based off, here's a class, I want to do a method.
The problem is, if I say, I want to test this class, implicitly, I've done
some design around my implementation.
I must have thought about what classes am I going to use to implement this requirement.
I've done that thinking up front.
And what it turns out is it's very hard for me to unwind that thinking.
I get very wedded to that thought process.
And I see the problem in the context of that thought process.
And what that leads quite often to me doing is writing a lot of speculative code,
because it turns out, I didn't need this for this requirement.
But hey, my, in my head plan of how this will work, I've got all those classes mapped out.

So generally, in a kind of unit testing approach, you'd start with saying, oh, here's
one of the classes I need.
It's going to need these kind of methods or write some tests against it.
In a TDD approach, you say, what's the first requirement I can think of?
So I'm doing Game of Life.
The first requirement is I want to have a board.
If the board has no living cells on it, then when I run a tick, as it's called
in the game, I should get another dead board.
And then I just keep going with requirements.
And what this leads to is what TDD is actually trying to achieve.
And the first thing is design.
So I always say TDD is a contract first design approach.
In the same way, we go out there and we say things like, hey,
a really good way of designing your API, your HTTP API.
We drop an open API, a swagger document, effectively, share it with the customer,
get feedback, play with it as a mock, decide what the shape looks like,
then go and implement it.
Because hey, that way I get all this feedback before I need to actually go and write all the code.
In the same way with test-driven development, we want to be contract first like that.
So we say, well, what's the API that's going to implement these requirements?
Hey, I can sketch that out in my test.
I haven't got an implementation yet, so it's easy to change.
When I'm happy with what that looks like, then I can begin saying I could get that to pass,
that first example.
So once we're out of time in XP, there was this notion saying,
oh, you're not going to need documentation anymore.
The test will be documentation.
I thought this was one of the great lies.
I looked at my test six months later and I had no idea what this test was doing.
Turns out, if you do TDD like this, if you treat it as I'm creating examples
to express the acceptance criteria, then one of the things you focus on is,
hey, I want to create a really readable example.
I want to go to look at this test and read it as a stranger to my system and go,
that's how you use this particular system.
Right?
So I write that test and then that test.
And it isn't necessarily one particular class and getting under control.
Now, when you see examples, so Ron Jeffries is a really good person
to see him doing this online.
When you see Ron doing examples, he's always tends to be dealing with a class,
but that class is the one that expresses the API.
Right? So he's dealing with the API and just happens to be expressed by a class.
When we say API, by the way, we don't necessarily mean the thing
at the boundary of your system, HTTP or some event system.
We mean, effectively, probably what I would think of
in a layered sense as the service layer, the thing that sits over my domain
and provides a more coarse-grained operation.
One of the talks I saw you did quite a few years back,
you were talking a lot about outside in testing.
So where the outside is this boundary you're talking about.
Yeah, sure.
And that's very true.
I mean, out of testing, there's a bit of a term for BDD.
You come back to BDD later.
So I've moved away from it a bit.
I tend to think more now in terms of clean architecture and testing at port.
So it's a bit of a easier term or a service layer,
if you think about that kind of classic application layer, service layer
and domain, basically.
So you can't test that level
because that's basically where your requirement is expressed most naturally
in the code.

It's a right test now.
And then what you just do is keep adding tests
to basically increase the amount of coverage of examples.
Now.
The thing is that you might say, well, hang on a minute.
How is the localisation of my defect?
If something goes wrong, if I write some code
and then I get red tests, how do I know what broke?
Because it's just quite coarse-grained at this kind of level.
And the answer with TDD is the last change you made is what broke something.
So TDD's principle is that developer tests and unit tests,
it's basically a red test indicates that basically there is a defect in this module.
In TDD, a red test indicates there is a defect in the last change that you make.
And actually, a lot of TDD practitioners are quite aggressive
and they say, revert the last change and try again.
I'm a little bit more like, you know, what maybe debugging is actually
the quickest route to fight, you know, maybe it's a trivial error.
Deep, have a look for trivial errors that debugging will show up, first of all.
And then, if you really think I didn't understand that,
my debugging is showing me that I've done it, then revert it and try again.
But it's also why TDD wants to make small changes
so you don't feel worried about throwing it away.
If you switch to this model of developer testing,
you'll find a couple of things happen.
One is you'll get TDD code where it forms an example
and you can use that effectively to understand what it is that you're writing.
Two, if you think about basically this kind of led architecture
where effectively you've got the application as your controller,
some kind of service layer and then domain underneath it,
you'll have a clear kind of service boundary that says,
I express high level operations on the domain,
easily to the application.
The other thing you'll find is that you don't need mocks very much.
We talk about where mocks come in, but you don't tend to need mocks.
Why?
Well, actually what you do when you implement that API
is the first thing you do in the red green effect cycle.
Remember, red is right or failing test.
So I write my test, which is an example of how the system ought to be used.
I write that example.
Then what I'm supposed to do to go green is as quickly as possible.
So cut and paste some stack overflow, whatever you need.
I effectively get that test to go green.
So I'm figuring out the algorithm that basically passes that test.
I don't do good design at that point.
I figure it out.
Et puis ce qui se passe est que,
dès que je commence à avoir mon software émettant sur les requimités,
je peux à un moment dire que je peux refactoriser.
Maintenant, j'ai une idée claire de ce que l'on doit faire.
Je peux voir que je peux improving le design.
En général, je me laisse un peu de temps maintenant
parce que je suis en train de voir que j'ai eu les requimités
avant de refactoriser.
Et si je le fais plus tard, ça m'a aidé.
C'est un grand livre qui parle du processus de refactoriser.
L'un des choses que ça fait de nous en faire est la complexité primaire.
Je fais l'exercice quelques années plus tard dans le livre.
Tu commences à faire...
Tu sais, tu fais de la même chose, tu fais de la même chose.
Je l'ai fait et je l'ai réalisé par comparaison à leur solution.
Mais si j'avais ce que nous pensions de la code bien enginére
avec des factures, des lignes, etc.,
c'était hugely compliqué.
Quand on regarde leur code, même si, essentiellement,
tu penses que c'est plus proche de l'exercice que le script.
C'est plus proche de l'exercice que le script.
C'est plus proche quand tu as regardé le code.
Ce que ça fait, c'est plus proche.
J'ai eu tous les niveaux d'abstraction.
Pour simplifier le truc, je n'ai pas besoin de tout ça.
La deuxième chose, en effet, dans le temps de refactorisation,
est que tu peux introduire des classes
qui sont effectivement internes,
dans les termes de C-sharp,
parce que l'API est efficace
pour les classes intervues en public
sur ces classes internes et qu'elles n'ont pas besoin de tests.
Le truc est que, quand tu refactes,
c'est un mouvement de sécurité qui ne fait pas de la même chose.
Je vais faire ce genre de refacteur
qui ne vous introduira pas de nouveaux paths.
Je vais introduire un truc qui est un métier
qui est un métier de sa propre classe,
parce que c'est une responsabilité différente.
C'est découvert par les tests.
Je ne l'ai pas écrit en code
qui n'est pas créé en réponse à les tests.
C'est donc découvert par les tests.
Ce design de la classe,
j'ai choisi de le faire dans deux classes.
Un autre peut dire que je vais m'améliorer les deux ensemble,
qu'ils ne sont pas en train de faire de leur weight,
ou en fait, il y a 4, etc.
Ce sont les choses qui sont les parts flexibles de refacteur.
Si nous avons des tests pointés à ceux,
c'est pour ça qu'on doit changer nos tests.
Nous ne voulons pas faire ça.
Donc, pour nos tests,
nous ne voulons pas couper les détails d'implementation
parce que si nous faisons ça,
nos tests devraient être un obstacle à refacturer,
ce n'est pas un truc qui nous aide à faire ça.
Donc, à l'extérieur,
nous voulons juste tester contre ce type de niveau top,
la interface de course de graines.
Et puis, on dit, ok,
je peux ensuite changer l'implementation
comme j'ai besoin,
comme je veux apprendre plus sur
comment cela fonctionne,
comment est-ce qu'il faut maintenir, etc.
C'est probablement acceptable,
souvent, de vraiment se passer,
de faire de la weight,
j'ai eu des codes à la minute,
et je n'ai pas de note pour les autres,
qui disent,
je vais devoir refacturer,
mais je ne suis pas au bout de la figure de l'algorithme,
je parle de les gens,
en essayant de les faire,
si ça fait le bon travail,
les gens en parlant,
ce code est supposed à travailler pour.
Quand je suis heureux,
nous savons ce que cela fait,
alors nous nous le refacturons.
On dit, ok,
on va faire ce plus facile
pour le lire et maintenir,
les autres doivent regarder ce qu'il y a d'autre que nous.
On va être plus clair
sur l'intention, la réjouissance,
la grande,
la réjouissance, l'intention expérimente,
ce sont les deux très grandes,
ce que vous pouvez faire.
On a des patterns de design,
c'est là où il vient,
il dit,
j'ai clairement le contexte
pour une pattern de design ici.
Je ne suis pas juste créant
une pattern de design pour le sake de ça,
parce que j'aime les patterns de design,
et c'est cool,
je peux clairement voir
que j'aurais pu pouvoir
imprimer ce plus clair pattern de design.
C'est un truc que j'ai bien aimé
de pouvoir utiliser un docker
pour pouvoir tester le détail de l'implementation,
pour évoluer un database,
en n'ayant pas utilisé
quelque chose comme un code
en database de membre,
parce que les choses comme
l'intention de l'intention de l'implementation
ou le docker,
ou le pattern de la reposité,
ou tout ce que vous avez
de classes de data access
que vous avez,
qui sont tous en détail d'implementation,
vous pouvez prendre
tout ça,
après l'équation,
et ce que je fais
maintenant,
c'est dans mon test de intégration,
je peux souvent utiliser
le code de la web,
je l'utilise sur le web
de l'application de l'application.
Et les requises sont que,
par exemple,
un système d'ordre de la management
où nous créons un ordre,
le test est,
si je fais un post-request
à un point de vue,
le test
se détaille le database
pour faire sure que l'intervier
a été ajouté.
Et puis,
cela a été fait
de l'équation,
ce que l'OMC
utilise,
ce que les
layers de data
ont utilisé,
donc je peux compléter
ce qu'on a fait,
les tests
qui testent
les requises,
elles ne sont pas récourus,
et je n'ai pas de
rewrite tous ces tests.
Et c'est le problème
que j'ai trouvé
où
nous faisons
beaucoup de tests de unités
contre chaque layer.
Ce sont ces choses
qui ont été détruits
pendant l'intérimation
de la test de intégration,
qui ont été déclarées.
Et je suis en train de le faire.
Oui, donc je tend
de sortir de l'intergration
de l'intergration,
parce que ça va
avec les tests de unités
en main et en main.
Donc je parle de tests
de développeurs,
puis je parle
de testings.
Et parfois
je parle de tests
de développement
et de tests après testings
pour faire un peu
plus clair pour les gens.
Alors, une des choses
que je tend à dire
est que
le TDD
fonctionne très bien
pour le suivi
de la situation,
qui est généralement
que vous êtes testé
votre domaine,
et que vous êtes testé
potentiellement
par un plus grand cours
de l'interface
de ce domaine.
Et la raison que je like,
c'est que, effectivement,
ça dit,
tous les portes
qui sont en train de
sortir,
effectivement,
sont en train de faire un

Et mon test
juste dérive
ce domaine.
Et je n'ai pas vraiment
qu'à savoir
les autres détails,
parce que, effectivement,
mon test
peut s'appliquer.
Maintenant, parfois,
vous pouvez avoir
l'utilisation de
un camp d'interface
de la base de la base,
d'un plan de poste,
et vous dites,
dans mon camp de cours,
en fait, l'une des choses
qui fait c'est de obtenir de l'argent.
À la fois, je vais
donner un défilé
qui fait ça pour moi.
Et ça nous donne
l' seres essentiels
des uns dont,
non,

des créateurs
açis
si nous disons
que la part de la base
tllt
qui dirige
n'eställement pas
impliqué.
À l'aide de
Earthquie EV
qu'en tout cas tu sais
il y a du
son)...
sobre
de cenan.
So Kehn
a dit,
il y a 3 choses
qui nous ont
prри de
seule
Hes OK
qui
on ne format
que tu travailles sur.
L'un est des choses qu'il s'appelle shared fixture.
Shared fixture est essentiellement un état qui est shared entre deux tests,
pour que je ne puisse pas les tests en parallèle, qui les s'arrêtent.
L'OAO est classiquement une des deux, ou des statiques, en fait.
L'autre chose, c'est des tests slow, qui peut être causés par l'OAO,
souvent par un réseau.
Le troisième est le test fragile.
Les tests ne comportent pas tous les jours.
Il peut avoir des problèmes sur la threading, ou il peut aussi être l'OAO.
Ce sont les places où Ken would tend to, if he needed to, use a mock.
En fait, c'est pas mal de replacer ces choses.
En général, c'est l'OAO, que tu veux replacer.
Mais si tu fais tes tests,
souvent tu peux juste exclure l'OAO de l'équation.
Tu peux dire que l'OAO s'occupe d'autre place.
Si il ne t'a pas fait de l'exemple, je vais juste donner le data
et je vais avoir des résultats.
Et mon test peut se dérouler et se replacer.
À la fois, c'est utile d'avoir une layer d'access,
qui est en fait ma course de lait.
Je vais parler de l'access,
et puis faire un tour de la surface.
Ça dépend de ta préférence.
Je suis bien sur ça, si tu veux.
Mais tu vas tendre à exclure ce problème.
Et puis, ce que je dis aux gens, c'est que,
si tu veux faire un test,
par exemple,
si je vais utiliser l'entity framework correctement,
et si je vais persister à mon stuff d'entity framework,
tu peux faire un test pour ça, pour sûr.
Mais si tu reconnais ce que tu fais,
tu es effectivement en train de faire un test de régression,
pour dire que tu as eu des codes que tu n'as pas fait,
donc je vais automater un test de régression
pour ce qu'il y a de ma code,
qui effectivement vérifie
si je suis correctement correctement correctement.
C'est un test de réaction,
et c'est un test de réaction,
et il n'y a rien à faire avec la practice TDD.
C'est juste que tu fais le test.
Et c'est ce que je vais parler de test de la surface,
comme sur ce point.
Les tests de réaction unit sont géniaux pour nous
pour tester la application de la application de la business.
Mais il y a d'autres lait,
qui nous permettent de donner un feedback plus lent,
et parfois moins de feedback binariant,
mais aussi valable,
pour que nous puissions avoir un peu d'acquisition.
Donc, un des trucs qui touchent à I.O.
Vous pouvez faire un test separate,
pour vérifier si ça va travailler.
Et comme vous le dites,
le plus important que vous pouvez faire,
c'est de faire quelque chose
dans le postman,
ou même de faire des tests de réaction
en code,
ou des facilities de l'HGTP,
et quelque chose dans le rider,
qui fait le même chose que le postman,
qui fait des tests de systèmes,
qui font des tests,
qui disent que c'est un break,
et qui ne font pas de tests de contrôle,
parce que c'est un break,
qui donne des tests, qui donne des feedbacks,
qui me rend le résultat.
Je peux utiliser des tools de X,
si je veux,
pour automater mon test
autour de mon EF Core,
mon DAPALER,
mais juste des tests différents.
Je ne fais pas les TDD,
car les TDD sont une activité d'exploration.
Je ne sais pas ce que la interface a fait,
je ne sais pas ce que je veux faire,
mais je vais dire.
Si je fais quelque chose qui me dit,
je sais ce que la code a fait,
je le documenterai, et je me refacte
des numéros. Il n'y a pas d'exploration,
il n'y a pas de refactoring,
je le réacte.
Je fais les tests de travail,
et les interfaces user,
je fais des tests de TDD,
mais je mets des boutons,
comme je l'explique,
et je vais utiliser des tests de TDD,
pour tester les end-of-détailes,
et faire un test de style.
Et donc,
utiliser des TDD où c'est
supposed à être utilisé,
c'est de la façon dont je veux
exprimer,






et pour les autres,
j'ai besoin de la logique,
pour que la TDD s'aide,
et je vais dire,
pour les autres,
pour mes études,
où je veux être assuré
que, si je le fais,
je ne vais pas le faire,
faire des tests qui me protègent
pour les agressions,
mais ce n'est pas TDD,
même si je vais utiliser les mêmes tools.
Je pense que ça me aide,
parce que parfois, c'est la chose,
le goal de TDD
est le même goal que l'Ajah,
qui est,
speed up le loop de la tue,
et donner des décisions sur le design.
Donc, en TDD, la décision du design
que je fais,
c'est de la interface qui ressemble
à ceci, pour imprimer mon requim,
et donner des décisions sur le design.
C'est-à-dire, si le UX
est comme ça,
le plus rapide de la décision du design,
peut-être une tue,
peut-être que, pour faire le travail,
le couler, le couler devant quelqu'un,
c'est la décision du design,
et la tue n'est pas une binary,
c'est une nuance,
et ce que je vais faire
c'est de la recette, c'est ça que je teste.
Si c'est de la décision,
c'est de la décision de DAPA,
c'est d'aider
le code et de la faire,
c'est d'aider
un plus rapide de la décision,
d'accepter un tout test,
et c'est toujours de
voir le plus rapide de la décision
d'avoir des réponses,
de voir le plus rapide
de la décision d'avoir des réponses,
et de faire le plus rapide,
si TDD n'est pas le plus rapide
de faire ça,
ne fais pas quelque chose d'autre,
ne fais pas quelque chose de cargo,
faire quelque chose qui dit
que c'est un moyen vraiment valable
d'avoir des réponses en design.
Il vous donne aussi des contrôles,
c'est vraiment important
parce que
pour les problèmes que j'ai
vu avec les tests unis,
c'est que parce que les gens créent des tests unis,
ils doivent alors dire
comment tout se met ensemble,
tous ces tests,
comment je sais que ça met le requin de fonction,
alors ils vont en mettre un TDD
ou ATDD,
en utilisant des tools comme specflow
ou en passant,
pour faire des tests,
à un niveau de la haute,
il y a deux problèmes avec eux.
Le premier, ils tendent à utiliser
des tests anglais
ou des tests table,
et l'assumement est
que les producteurs vont réveiller
ces tests, et qu'ils regardent
et qu'ils regardent,
les requins sont établis, ils sont automatisés et éprouvés,
et c'est comme,
je n'ai jamais vu personne faire ça,
je n'ai jamais vu les producteurs
réveiller ces tests specflow
et dire, en fait, ce n'est pas
le requin que je m'ai expéré,
et ça coûte beaucoup, parce que je dois
transler entre le DSL et le code.
Mais ce que je dois vraiment faire
c'est prendre les exemples que je suis
donné et utiliser des noeuds
pour dépasser mon practice TDD.
Il n'y a pas de différence anymore,
c'est un point
où c'est vraiment comment vous expérimiez
la TDD, et j'ai un slide
que j'ai utilisé, je vais vous donner un lien,
vous pouvez le mettre dans le podcast à la fin.
Et
une chose à parler de là, c'est le fait
que
un des gens qui m'a dit que j'étais un avocat
de la XP,
il a parlé de la facture qu'il a donné un point
et il a dit, créez des exemples
qui vont effectivement dépasser
votre practice TDD,
c'est tout le même, c'est juste
les tests de développement,
les tests de développement fonctionnel,
les requinements d'expression,
vous n'avez pas besoin de TDD, BDD,
c'est tout part de cette séparation
entre unit, intégration, acceptance.
C'est pas tout le monde avec TDD.
TDD dit clairement que c'est un requin
dans le test de l'application de l'application
que je dois prouver.
Hey, let's write
des autres tests, ou élevé des codes,
et des feedbacks télémetriques,
pour prouver les autres parts du système,
où la TDD n'est pas la bonne réponse.
Je n'aime pas
ce que vous avez dit, c'est pas de l'exploité,
parce que j'ai considéré que vous avez utilisé ça dans le passé
avec différentes entreprises,
et mes pensées m'ont vraiment écoïncée
ce que vous avez dit,
c'est bien en principe, mais en réalité,
il n'y a pas de manière, le salle de stake
qui a sorti
par les tests de spec, c'est la preuve
des développeurs, et les développeurs savent
comment écrire le test de l'exploité
de l'exploité de l'application.
Exactement, le format de l'exploité
je l'ai utilisé souvent pour l'exploité
d'un certain point de vue,
et en fait, l'exploité de l'application
qui vous donne un test,
et qui a fait le même chose.
Et un autre conseil,
c'est un des problèmes que j'ai eu
avec des frameworks de l'exploité
de l'exploité
de l'application
de l'application
si vous utilisez
un ex-unit
qui vous donne
une DSL,
le problème est
que votre test est focussé sur la DSL
pas sur ce que l'application a
à l'exploité.
Et donc, vous ne vous donne pas la chose
quand vous évoquez votre test, vous dites
que ce que l'application a à l'exploité
est un exemple de comment
j'utilise l'application.
Ce que j'ai fait, c'est que
c'est assez obscur, je ne peux pas voir
l'application, c'est dans un autre sens.
Je n'ai pas l'air de distinguer
maintenant, car pour moi, ils sont obscur
l'application et le test.
Et le point de la TDD
c'est que c'est un approche contracte
un approche design contracte
qui dit que ce que l'application a à l'exploité
est une des requimements.
Est-ce que je peux impliquer
ce que je peux faire pour l'exploitation?
Est-ce que je peux contrôler
que je ne peux pas faire le code
nécessaire pour passer ce requimment?
Parce que le autre chose que nous faisons
c'est que nous compliquons de choses, nous
ajoutons des codes nécessaires,
nous nous disons
que le futur de nous serait vraiment gréif
parce que le futur de nous
quand le producteur
n'est pas obligé de venir et d'imprimer
ce requimement, le futur de nous
sera bien, je l'ai déjà fait
et je me suis dit que ce que le futur de nous
trouve toujours est que je n'ai pas
un demi-réquimité, mais ce n'est pas
ce que je pensais. Et le futur de nous
dans ce bind,
parce que le futur de nous a dit que
je n'ai déjà eu
une solution à la travail, donc je vais
juste le hacker et ça va travailler.
Et mon beau code devient un ugly code
parce que c'est un hack que j'ai fait
pour faire, ici c'est celui que j'ai fait avant
et je vais travailler pour la situation réelle
et la réalité est que si je l'ai juste
attendu jusqu'à ce que je n'ai vraiment pas besoin
ça serait mieux parce que je vais maintenant
faire une meilleure code et aussi
ça ne peut jamais venir. Et le smell,
c'est le smell classique où tu viens across un peu de code
et tu enables un nouveau requimement
et puis les choses vont redire
et il est comme, wow, il y a des lignes de code
ici qui ne peuvent jamais
pouvoir être réunis
parce qu'ils n'ont jamais travaillé.
Oui, je le fais souvent
parce que j'utilise un rideur
qui est très
plus dans votre tête
sur les warnings et les choses
que le code n'a pas été appelé.
Et je fais beaucoup de fonds de fois
quand je regarde les bases de code, il y a
des clés de code qui n'ont jamais été appelés
à tout le monde et c'est juste que
en temps, le refacteur a été placé
et les choses ont été
ennuyées.
Et par exemple,
avant d'exprimer les choses en envers
l'acronyme Yagny,
il ne va pas en avoir besoin. Il y a
beaucoup de code
qui est presque comme les développeurs qui l'ont
réveillé en essayant de être clairs
par la façon dont je peux le solider
dans un très clairs moyen, mais il
est en train de être compliquant,
inondable et très difficile à réveiller.
Je pense qu'il y a un peu de problèmes
avec les médecins.
Et un de mes reconnaissances
quand je suis jeune
est qu'il y a des
jeunes qui pensaient qu'il y avait
deux audiences pour son code.
L'un était qu'il y a des gens
qui sont heureux,
d'autre, les développeurs et les
team. Vous voulez imprimer
vos clés, et
je sais comment utiliser les features
de C-Sharp9 et il y a un couple
d'experiments très puissants
et je vais vous montrer comment vous faites.
Et l'autre, je suis très fain
et j'ai l'impression
que le code est un
plus simple possible de solider
le problème, car les gens comme moi
vont avoir de la maintenance.
C'est la chose où vous reposiez
6 mois plus tard et vous vous dites
« Wow, j'ai écrit ça ».
Et je pense que
j'étais plus smart que je dois
perdre ces celtos.
Mais je trouve que
le code est un peu
plus clé, c'est un problème.
Mais je pense que plus de
ce que nous faisons
c'est que nous avons nos
nos propres weaknesses.
Et une des raisons, je vais
revenir à la C-Sharp9 et les
bottles de l'Oube, je trouve qu'ils sont
très puissants.
Vous vous dites que vous vous
vous dites que vous vous dites
que vous vous reconnaissez que
j'ai une tendance à introduire
les obstacles plus tard que
ils ont besoin.
Si vous savez ça
je peux vous dire
que quand je me sens le courage
de refactor, je peux dire
« Lorsque vous
vous abstrapez trop vite,
vous savez que c'est votre bad habit.
Vous avez des tests,
vous pouvez refactor à quel point
vous avez des bons tests à couvrir
et cela signifie que
à quel point vous pouvez briser
vos méthodes à écrire le temps
et vos classes
si vous avez besoin de simplifier
les choses. Mais vous ne vous
n'avez pas besoin de faire ça
jusqu'à
ce point où vous êtes sûrs
que vous avez vraiment été difficile
de suivre maintenant.
Et donc, quels sont les plus simples
refacturations que je peux faire
pour que je puisse y arriver
à la prochaine phase.
Et vous vous demandez toujours
que vous devez vous demander
ce que c'est le plus simple refacturation que je peux faire.
Qu'est-ce que c'est le plus petit de la clé
et c'est pourquoi je peux
faire attention à la duplication.
Et par contre, le plus important
de la duplication est que ce n'est pas
la duplication, c'est la knowledge.
Donc, deux bits de code savent
comment faire la même chose.
Vous pouvez avoir beaucoup de lines
qui disent
« String.format » ou tout ça.
C'est pas la duplication, vous devez plus
prendre la même chose.
C'est deux bits de code
qui disent que, vous devez
prendre la même chose.
Vous devez prendre ça.
Ou, l'expression de méthode
d'intention,
qui est que je suis élevé
de commentaires, parce que c'est pas clair.
En fait, je peux, peut-être,
renomber
et créer un nom de méthode.
Ce sont les commentaires.
Ces deux se sont très puissants.
Avant de me dire
« Strategy.pan »
ou « Command.pan »
ou tout ça, que j'aime,
je dois prendre un tour de la main
et dire « C'est pourquoi Ian a besoin de faire ça.
Parce que vous avez une tendance
pour atteindre ça, parce que vous avez besoin
de faire ça. »
Et « Good.TDD » m'a aidé.
Parce que « Good.TDD » dit
« Je suis sur le haut de la lait.
Je n'ai pas besoin de créer
cette structure belle.
Et aussi,
cette structure belle est un
moutable.
C'est un truc qui peut changer,
le détail d'implementation.
Surtout en C-Shop,
une des choses que je
fais pour me réveiller
dans la communauté C-Shop,
qui est une chose de ronde.
Une des choses, c'est ne pas
utiliser des assemblages multiples.
La situation est,
si vous êtes un programme Python,
personne ne peut dire que vous ne vous utilisez pas des modules.
Si vous êtes un programme Python, vous ne vous utilisez pas des modules,
les assemblages sont votre structure module.
Si vous vous mettez public
sur votre assemblage,
vous dites « Hey, je suis le truc
que vous avez parlé de sur la interface course.
Ce qui est interne est hidden
par les collaborateurs.
Les assemblages publics, c'est ce que vous avez
parlé de, les stuff interne
ne vous parle pas.
En pensant à un peu de codes, des tests,
vous avez signifiquement réduit un nombre
de tests, si tout est testé par les interface publics.
Je vous dis que les détails de l'implementation
sont bien solides.
Je vous dis que je vous dis que les détails
sont bien solides.
Donc, utilisez les assemblages.
Ne vous parlez pas de module en mode.
Si vous parlez de la
part des modules,
vous vous mettez des choses qui changent
ensemble.
Et faites des modules qui ont
une cohesion et une coupe basée.
Utilisez les assemblages et modules.
Absolument,
n'étiez pas de l'envers de la
compétition de la science.
Évidemment, vous avez besoin d'une
complétité suffisante pour faire ça, mais je dirais
que les plus non tribunaux sont rapidement
au point où un module m'a aidé.
Les gens ne utilisent pas les laires.
Les gens ne comprennent pas les laires.
Les laires ont deux choses.
L'un est,
on ne peut pas avoir
des références circulaires,
on ne peut pas avoir des modules.
On a un autre chose.
On va faire une raison
sur les modules.
Les modules de la laire
font des choses différentes que les modules.
On a beaucoup de gens qui sont très
intéressés par les laires et modules, mais
elles sont des bouts fondamentaux de la science
qui sont très utiles.
Je me suis évoqué
beaucoup de la récité dans la communauté
de C-Shop.
Ne utilisez pas les assemblages,
n'étiez pas de laires et n'étiez pas
de laires.
Les folders ne vous donnent pas
public et internaux.
On peut utiliser
X-Tool
pour renforcer les
boundaries de la laire.
Pourquoi?
Pourquoi vous allez
en utilisant
les assemblages modules
et les façons d'effectuer.
Vous ne peut pas
pas avoir besoin d'un
de plus de la laire.
Vous pouvez les réutiliser.
Vous pouvez réutiliser
les constructeurs
car vous n'en avez plus besoin
pour les moquer.
En beaucoup de cas, vous ne vous en avez pas besoin
d'une pour les réutiliser.
Je l'ai toujours utilisé.
Je l'ai réutilisé.
Et je l'ai réutilisé dans les laires.
Les choses que la laire de la laire
a besoin de moi, je l'ai réutilisé.
Il n'y a que un petit nombre
de choses,
les routes de composition,
qui en ont besoin
d'une création.
Vous n'en avez pas besoin de
des frameworks de la laire.
Et si vous vous en avez
une ou deux,
vous pouvez vous faire
un truc de la laire.
Vous n'en avez pas besoin
de la laire.
Vous n'en avez pas besoin
d'un IOC.
Vous voulez faire
quelque chose de nouveau,
peut-être une fois,
et puis, effectivement,
il y a des routes de composition
et des choses de chaine.
IOC contient
beaucoup de problèmes que nous avons.
Ils arrivent parce
d'une test de unité
de la laire.
On développe un test.
Simplifier, simplifier,
nouer un truc.
Tout est parfaitement bien.
Ne vous en injectez pas.
Si c'est essentiellement créé
d'une laire à l'arrière et
donc vous ne pouvez pas créer un instant
parce que vous voulez éviter
des problèmes de la route de la laire,
cela peut changer.
Vous avez une approche
pour la stratégie,
où je peux proposer
plusieurs implementations.
Si vous n'avez pas besoin
de la laire, vous avez juste le nouveau.
C'est un instant.
Vous trouvez que ne pas se souviendra
d'un test de unité
et ne pas se concentrer
pour que c'est plus facile
d'avoir une test
contre des bases de la laire?
C'est une bonne question.
Les bases de la laire, c'est plus facile
de faire quelque chose
parce que vous avez juste le droit
de faire un test qui arrive en contrôle.
La difficulté de bases de la laire
est souvent
de trouver le point pour faire le test.
Ça peut dépendre.
Si vous avez un code de la laire
qui a un niveau de laire,
c'est facile.
Si vous avez un test de la laire
ou un contrôle,
vous pouvez faire des tests
si vous avez besoin de le contrôler.
Si vous avez un code de la laire,
vous n'avez pas les bases de la laire.
C'est un des choses
de la structure de la laire
qui a l'air de la laire
ou des choses qui font
de l'aie au niveau de la laire
et pas de la laire.
Je travaille avec un code de la laire
qui, à un moment,
fait un procédé de base
de base de base de base.
Ce qui s'est passé
est qu'il est très difficile
de maintenir,
parce que c'est très difficile
de savoir, quand ils ont dit ce code,
qu'est-ce qu'il va faire?
Est-ce que c'est facile?
Est-ce qu'ils vont m'en parler
de la base de base de base?
Si je commence un transaction,
qu'est-ce que je vais faire?
C'est un problème.
C'est la transition de base de base.
Qu'est-ce que je vais faire?
Qu'est-ce que je vais faire?
C'est impossible de faire un transaction.
Je préfère
de garder le domaine
de ce qu'on appelle les objets c'est-à-dire
de la laire,
de la gastronomique de la batterie,




d'aujourd'hui.
Quand je parlais de DOKA, c'était toujours en mode automatique, mais en utilisant les tests
de integration sur les Asp.NET Core.
Oui.
Et puis automatiquement, en utilisant DOKA Compose, on a été temporairement sur le database
de l'intégration de l'intégration, alors que je vais éviter les tests de l'intégration
et puis de la spinning sur le database.
Oui, donc le projet de Microsoft, le projet de Brighter, ça fait ça, oui.
Donc, le problème de Brighter est que nous avons extracté des transports, donc des
différents messages de la machine de la machine et des databases, parce que en ce cas,
nous avons des outboxes et des inboxes, nous avons plusieurs de ces.
Donc le projet de Core a un test de TDD, parce que c'est le même que le transport que
vous utilisez ou le database que vous utilisez.
Et ces choses, il y a un interface que nous implementons pour ce que nous avons donné
une partie de la machine de la machine de la machine, ou pour ce que c'est le database.
Et donc, nous avons des tests automatique, des tests de l'interface, mais ils sont
généralement très souvent élus dans une façon très testée et prouvente,
que oui, effectivement, vous pouvez impliquer ce interface correctement pour nous.
Nous faisons exactement le même avec ça.
Nous avons, en fait, un file de compo, nous avons un grand nombre de machines de
la machine, ou des petits individus, sinon.
Et puis, en fait, nous nous avons spiné ça et vous pouvez...
Le projet de GitHub est reposé, donc vous pouvez faire des tests,
on teste tous nos transports si vous voulez, et on prouve que ça fonctionne.
Et en fait, nous utilisons des actions de GitHub maintenant,
et on raccl intensity de ça le même.
Pour ce qu'onард APPLAUSE est gravement bog憂.
Aujourd'hui, nousostaient nos testsimmerciés
concurrencement qui appartiennent é adelèdes dans un approaching
Usama, et ce dont nous avons la visarah,
ce que vous vous souvenez
controlés, ou caractérisation,
scaled.
Dans ennemi, c'est une personne.
et ça fait très bien.
Et ça fait très bien que ça soit installé sur votre machine,
ça fait très facile de vous faire participer à la construction de votre projet,
parce que, essentiellement, ils pourront juste poursuivre tout,
ils peuvent faire les tests localement,
et ils peuvent, si ils veulent faire les tests plus suifs,
juste utiliser Docker Compose,
ou tout ça, pour pouvoir évoluer les infos nécessaires.
Je trouve que c'est tellement de différents outils pour Docker.
Le plus j'utilise c'est...
même les outils dans Docker,
donc, il n'y a pas de la dernière,
.NET SDK ou un Node sur les agents de la construction.
Et comme vous l'avez dit,
juste pouvoir temporairement,
faire des tests,
faire les tests et faire le test,
et c'est tellement de pouvoir.
Et cette whole CICD,
la manière moderne de faire des choses,
c'est tout comme,
qui sont allées par des gic-commits,
et puis, vous pouvez juste aller et faire un café,
et ça va faire sa propre chose.
Je l'ai aimé, je peux me rappeler des places où je l'ai travaillé,
avant,
où, en général,
vous avez des radis dans votre devin,
et il vous a pris deux jours pour créer votre machine,
pour que vous puissiez faire de l'autre côté.
Parce que vous devez installer tout ce genre de choses,
et si vous êtes heureux,
à un moment où je travaillais,
Ian Battersby, je pense, l'a écrit originalement,
et puis, il a été rendu en train de le maintenir,
il y avait un script de chocolat,
que vous pouvez utiliser,
qui vous aimait de la machine et de l'installer.
Mais, c'est vrai, c'était seulement le plus bon,
que la dernière personne qui a fait le tout,
et puis, les gens auraient pu ajouter des requimages,
et qu'ils aient à l'éliminer le script.
Ça aurait été deux ans plus tard, je pense.
Oui, oui, on a eu un script qui était parfait
pour la prochaine personne,
et puis, on a essayé de faire des choses
où on pourrait avoir des vagues,
et essayer de placer une box vague,
et de faire un script, etc.
On ne va pas faire avec le docker,
mais ici, c'est le docker compose file,
qui installe la plupart des choses,
où vous pouvez prendre un repos,
et pour que vous puissiez le docker compose file,
et que vous puissiez mettre des choses,
alors que c'est bien que vous prenez.
Je ne viens même pas de s' femme, mais j'ai aussi eu
un截otede l'épicier...
de l'un des dec clearly
Je pense que çaоты maintenant,
un desemorisants de una danse-voix
qui s'était faite quand j'ai du micro-force,
parce que vous avez beaucoup de microservices,
si vous virtuellement
en vous sou dressant,
pour y tester un micro-service Watson,
tu dirais que noodle est le micro-service type qui
s'est construits en the lecker contנה.
Vous pouvez gustaître deaint range tout,
et puis tu as toujours joué localement en parlant à tous les containers de Docker
qui ont fait tous les services micros, c'est-à-dire que tu as besoin de parler.
Il était joué en octopus deploy et tu pouvais effectivement déployer live comme c'était
ou tu pouvais dire que je voulais déployer live plus la version en staging
pour ce service micros, etc.
C'était vraiment drôle, j'ai hâte de me rappeler ce que c'est appelé.
Je vais vous le démarquer, je vais mettre un lien, je vais vous le démarquer,
c'est assez powerful.
Je pense que les gens, les choses comme, c'est-à-dire,
tu as des Tire, tu as des DotNet,
oh les nouveaux DotNet, Project Tire.
Project Tire, c'est un travail sur les Kubernetes,
c'est un truc de tout un sens,
j'espère que tu déployes ton app local
pour que tu puisses tester le bit que tu as.
C'est vraiment plus puissant pour les développeurs
parce que les choses que tu n'as pas pu faire,
c'est que tu as des jours de installation sur ta machine
et à un moment tu as dû reposer ta machine
pour que ça soit répliqué dans le taux avec ce modèle, c'est assez powerful.
Je vais définitivement travailler avec les entreprises
avant que tu décrives que ça prend des jours pour s'envoyer,
et en particulier, il y a quelques années,
j'ai commencé et les premiers jours,
je voulais aller sur les scripts et ça m'a fait un fail,
puis les leaders de la équipe, un couple d'entre eux,
sont allés et nous essayons de travailler sur ce qui s'est passé.
Ils étaient les leaders de la équipe et ils ne pouvaient pas travailler
avec les scripts, et comme vous le disiez,
ça aurait été un mois ou un an plus tard,
depuis que c'était le dernier jour.
Donc, ça a été un truc de maman pour me faire construire
un code sur le computer.
J'espère que nous commençons à utiliser
Docker et Tire, et d'étroper,
pour que ça se débrouille un peu.
Et aussi, ça fait que tu as pu déployer ta machine,
parce que à un moment, la seule façon de la déployer,
c'est de repayer tout le monde.
Et il y a des gens qui ont toujours été en développement
sur VM, pour qu'ils puissent créer un VM,
ils avaient une image de gold,
ils ont créé le VM, ils ont fait le développement,
et effectivement, quand tu as réouvenu,
tu as brûlé un verre et créé un VM,
et Docker a vraiment été...
Les gens ont été vagrants pour faire ça,
et Docker a vraiment été l'équivalent de faire ça,
qui est juste de se couper tout ce que je besoin
pour les containers, et puis je peux se couper de l'eau,
effectivement, quand je suis en train de faire ça,
ou juste de me couper tous mes containers,
et de commencer à nouveau si je veux.
Je pense que l'un des problèmes, c'est que le monde,
nous vivons dans un monde où nous sommes tous des organisateurs,
nous aimerions payer attention à ce qui se passe,
et nous sommes en fait un petit pourcentage
des développeurs qui font ça.
Et donc, nous pensons que Docker a été
en train de faire ça, comme containers,
c'est juste le moyen de faire des choses,
les ICD, c'est le moyen de faire des choses.
Un peu de places ICD, c'est que
ils ne sont pas là,
et ils sont toujours en train de faire la même chose.
On en décrivit maintenant.
Un peu de compagnies sont encore dans ce monde.
Oui, et bien sûr,
je pense que nous sommes aussi en train de
estimer comment beaucoup de gens travaillent
sur les petites et les medium-sized businesses,
où le temps constant,
la pression des jours,
signifie que vos mains sont en train
de se mettre en train de se mettre en train
et de apprendre à Docker,
parce que vous pensez que vous avez entendu
d'un autre, d'un autre,
que ça pourrait simplifier votre espace de problèmes.
C'est souvent,
c'est assez difficile de demander
pour le temps, de pouvoir aller en train de apprendre
ce genre de choses.
Et même si vous avez fait ça,
si vous n'avez pas pu être
déjà dans toutes les expériences que vous avez,
ça peut prendre beaucoup de temps
entre apprendre et déliver
beaucoup d'extra-value.
Et je pense que nous nous underestimate
comment ça peut prendre pour
les idées de devenir mainstream,
pour les tools de devenir utiles,
pour que, pour la plupart,
ça devient un peu de ma main,
mais je peux juste faire ça maintenant.
Ou les gens viennent de plus en plus de la
large, de plus en plus de la petite,
où ils effectivement
prennent des pratiques avec eux,
parce qu'ils ont déjà fait beaucoup de ce
apprendre et ils peuvent apprendre à les gens.
Mais vous êtes bien, oui, nous underestimate
comment beaucoup de gens travaillent
dans lesquels c'est juste eux,
ou eux et deux ou trois autres gens,
et ils sont dans le sable
d'avoir des requimages de produits,
alors que, à l'aise,
ils ont l'automation d'une infrastructure.
Donc, nous sommes en fait
quasiment en train de faire des temps,
donc, nous allons faire des tips de détail.
Oui, on va faire des choses.
Donc, ce que je vais recommencer
c'est un blog pour vos browser
qui s'appelle Guitarco.
Je vous donne le lien, vous pouvez le partager
avec tout le monde à la fin.
Je vais vous interpréter
par un collègue de Georges Armstrong
et Jesse Tenton, c'est là où je travaille.
Et ce que ça fait pour vous,
c'est que, quand vous êtes dans un repo
de GitHub, dans le web browser,
dans la main gauche
de l'enquête de la display browser,
ça vous donne une structure de la traînage
pour naviguer le code.
C'est super cool, parce que
parfois, ce que vous voulez faire
c'est parler à un collègue de code,
et plutôt que de
basically, vous vous envoyez votre idée,
vous vous vous partez, particulièrement dans ce temps,
ce que vous voulez faire, c'est
juste aller au repo, et vous vous naviguez
au repo, vous vous rappelons de code,
et ça fonctionne bien pour ça.
Et si vous voulez explorer le repo et trouver
quelque chose, plutôt que de dégager
votre code, vous envoyer votre idée,
pour que vous puissiez une structure de traînage,
ça vous fait partie de la box pour vous.
Et ça n'a pas tué
pas mes browsers,
dans le fait que
vous avez toujours un bon travail.
Oui, on a toujours un mémoire, parce que
vous avez beaucoup de tabs, mais ça semble bien.
Donc, c'est vraiment un peu pire,
et j'ai trouvé
il est invaluable pour discuter
le code avec des collègues,
ou juste pour qu'on
ait besoin de trouver quelque chose dans le repo
que j'ai voulu faire attention à, etc.
C'est très bien, et je ne l'ai pas
essayé, mais je sais qu'il y a un
ton de choses dans GitHub,
qui sont très nouvelles de
pouvoir créer une idée dans le browser.
Je ne sais pas ce qu'il s'appelle, mais je ne sais
pasósto dans le code

Forum, avec le segúnement de la

av義, drunk,
iner l��, ou
voulu comma goose commands
avec une ou ses appui kal Sunnyq petrol
on peut demander de l'accessoire pour les codes.
Mon modèle mental, qui peut être complètement faux,
est que c'est un code visio-studio qui est plugué dans la GitHub.
Mais je ne sais pas si c'est vrai ou non.
Peut-être que le code et les spaces sont confusés.
Une chose est, quand vous vous appelez pour le dire,
vous demandez de quelle langue vous êtes intéressée.
Et la GitHub, je trouve, si vous êtes un developer de C-Shop,
même si vous êtes maintenant en train de faire la vidéo par Microsoft,
il tend à ignorer un peu,
parce qu'ils sont internaits dans les trucs rouges.
Et il y a des autres trucs qui ont été faits.
Je me souviens que, à part le fait que,
même si Ruby était une langue minoritaire,
par rapport à C-Shop,
Ruby avait plein de support pour tout ce genre de trucs.
Et C-Shop n'a rien.
Donc, ce que nous devons faire c'est de aller en ce genre.
Parce que c'est ce que l'anglais est intéressant.
Nous demandons que le code C-Shop soit en place.
Juste de faire surement que tout soit en place.
Il va se faire en place.
Tout le Ruby ne peut pas avoir un code.
Et nous ne devons pas avoir un code pour C-Shop.
Et le C-Shop, tout le C-Shop team,
va en demandant de soutien C-Shop.
Vous devez mettre C-Shop sous un autre.
Donc, vous pouvez juste compliquer
pour que le GitHub soit classé comme un autre.
Parce que je sais comment vous vous ressentez.
C'est très étrange, parce que c'est que Microsoft
a apporté un GitHub,
que la .NET ne serait pas de haut niveau.
Je pense que c'est parce que c'est un company qui est en armes.
Je pense que tout le monde veut que Microsoft
puissent faire de la base pour que le GitHub soit plus basé.
C'est un company qui est de la même manière.
Mais oui, c'est un peu d'influence sur le GitHub
en termes de faire le code C-Shop plus de la base.
Il n'est pas assez là.
Je n'ai pas fait un peu de rubis,
parce que je n'ai pas oublié de vous demander à Ian
de faire un tip de dev.
Je pensais que je vais le faire.
Je n'ai pas pensé à un.
Et Ian était juste un extra boy scout
et a été sur le podcast de la web de FACQ,
qui a mentionné le dev tip et pensé à un.
En fait, je vais être chier et piquer comme le code space.
Parce que j'ai un dev tip.
Je vais inclure les liens à tous.
Qu'est-ce que l'expérience que vous avez mentionné?
Gitaco.
Gitaco et code spaces dans les notes de la show.
Donc, où est le meilleur endroit que les gens à la maison
peuvent garder en contact avec vous?
Je suis I Cooper sur Twitter.
C'est l'une des plus les plus easiest de la base.
Je suis touché.
Mes DMs sont à l'open.
Je vais essayer de répondre
des questions simples et inquiétantes
sur les messages ou les TDD.
Si il se trouve vraiment compliqué,
je ne vais pas avoir le temps
de répondre à ces questions.
Je vais essayer de me remettre les meilleurs.
C'est la meilleure façon.
Je vais vous donner un lien de l'épisode
dans le cas de GitHub Repo.
Toutes les présentations que je fais
dans la folder,
ne cléz pas la folder,
parce que c'est beaucoup de choses
dans la overtime,
incluant des vidéos, etc.
Donc, ça va consommer votre hard disk.
Mais vous pouvez avoir ce qu'il faut.
Tout mon contenu est public.
Je dois faire un YouTube.
Je ne sais pas. Je pense que c'est une subscription.
Vous pouvez le faire.
Je peux vous donner ça aussi.
Il y a beaucoup de ma talk
quand il y a des conférences.
Je vais le mettre dans cette liste.
Vous pouvez le faire.
Cool.
Je peux vous inclure dans les notes de la show.
Quoi qu'on a parlé
sur les vidéos ou les liens
que nous avons mentionnées
throughout l'épisode.
Donc, un grand merci.
Merci beaucoup.
C'est probablement un des DDD
que je dirais.
Je dirais ça.
C'est intéressant
avec Jesse's DDD.
Qu'est-ce que c'est?
Nothingham.
Oui, l'East Midlands est cool,
n'est-ce pas?
Oui, ce sont des gens en personne.
Est-ce Octobre, je pense?
Oui, c'est ça.
Je suis très fier
que ça puisse arriver.
Provider les vaccins
pour les prendre.
C'est ça.
Je pense que si on a un variant,
les bruits, les vaccins
sont
50% plus efficaces
que ce qu'on a.
Ce serait probablement
un avance en personne.
Mais d'ailleurs, je pense
que c'est probablement OK.
Je pense que
un autre facteur
peut être que
les gens sont nerveux
d'attendre ce type d'avance.
Mais ça semble
que quand ils ont révé la ticket,
ils ont déjà vu
ce qu'on a fait.
Donc, ça semble
pas un problème.
Je n'ai pas eu un ticket
parce que je n'ai pas spoté
les tweets.
Oh non.
Je dois attendre
d'une autre façon
où je dois
d'une autre façon
pour qu'on puisse
révéler mon tour.
Oui, je ne dois pas
prendre une ticket
parce que je dois être honnête
que je suis probablement
plus nerveux.
Je n'ai pas eu mon premier avance.
Je n'ai pas été le deuxième.
Je me sens presque
comme si on était
dans un choc
à ce moment
où les vaccins
ont commencé
comme ça,
plus l'avance
et plus le vône
qui est probablement
comme ça.
Mais c'est les gens
jeunes qui ont probablement
déclaré le virus.
Ils n'ont pas été
vaccinés à ce moment.
Donc, il y a une petite fenêtre
qui est en train de se dévier
et les gens qui ont déclaré
le virus,
les jeunes qui n'ont pas été
vaccinés
où il y a cette fenêtre
et ensuite on a une nouvelle variante.
Donc, ça a l'air
comme si ça était
un point important.
Et, mais,
j'espère que
le total
va savoir ce qui s'est passé.
Pour moi,
je pense que
je pense que
je pense que
c'est un peu plus tard.
Pour moi,
ce qui me semble rare
comme ça,
ce qu'ils doivent faire
c'est
certainement
que tout le monde,
tout le monde adulte
a été offert
à 2 heures
avant de l'opiner.
Parce que c'est comme
à ce point,
vous êtes assez proche
de la immunité
à 70%
où
même si vous avez un out-break,
ça ne va pas aller très loin.
Donc, pour les gens
qui ne sont essentiellement
pas vaccins,
ou pour ceux
qui n'ont pas été vaccins,
les odds de vous
être un personne
qui n'a pas
eu un succès
pour la vaccination,
puis de rencontrer
le virus
dans le monde,
réduire,
parce que
un personne
a fait
un autre personne
mais puis il s'arrête
parce que tout le monde
a été succès
pour vacciner
et que ça ne peut pas
s'en aller.
Ça, pour moi,
me semble un point
important.
Parce que,
vous avez un risque,
vous avez un risque
que,
en fait,
vous êtes venu,
vous n'avez pas de
antibody,
même si vous avez été
vacciné,
et vous vous rendez
à l'event,
et vous rencontrez
quelqu'un qui est
chargé
et Covid,
mais,
j'espère que
c'est un petit
set d'odges
et un plus
moins
de risque
que d'autres choses
que nous faisons
dans nos yeux
sur un basis de data.
Ce sont des choses
qui commencent à se faire
en vie.
Mais oui,
je pense
que
seulement la plupart
avec deux jabs,
je pense que ça me semble
trop tard
pour faire
indoor,
en personne,
plus,
vous savez,
de l'argent.
Pour moi,
même restaurants
et barres,
je suis un peu
comme,
comment ça va,
que je veux faire en personne?
Qu'est-ce que votre pensée
avec,
c'est évidemment
London.net,
avec
en personne?
Je pense que ça va probablement.
La chose qui est intéressante
est
que l'on a deux problèmes
d'intervention.
La première est
quand l'on a perdu
l'éventuil de Matta,
l'éventuil de Matta
existe encore,
mais je ne sais pas ce qui
va arriver
et que l'enquête n'existe,
mais je ne suis pas sûr
que la pandémie poste
soit un état de joueur,
effectivement,
et si on peut utiliser ça.
On pourrait utiliser
l'acteur Microsoft,
mais c'est un processus
plus compliqué
que le processus.
C'est la première.
La deuxième est
qu'il y a un,

un,
un,
tous les
rants et
sont
qui
e
.
ties established
t
.
.
et la compagnie de recrutement a commencé un groupe d'utilisateurs qui ont utilisé le mailing list.
On a appelé le salon.net, on a eu une grande confusion.
Et bien sûr, ils ont effectivement du mien, donc ils ont déjà un vénu.
On a un peu de la paix dans les yeux,
donc l'une des choses dans la pandémie que nous avons faite,
c'est de changer à ce que je n'appelle pas le salon,
ce qui est beaucoup plus d'un style de space.
Parce que A, ça nous apprécie de nous différencier,
et B, c'est un peu plus sympa de rencontrer vos collègues,
les amis et les chers, et tout ça.
Donc la question pour nous après la pandémie,
est-il possible de nous retourner à l'affaire et de combattre avec eux,
parce qu'on peut avoir un vénu et d'essentier un deuxième meetup au London.net,
ce que nous pouvons faire,
on a parlé d'un des deux dollars qui se passe par eux,
et c'est que si vous venez et vous parlez de nous,
vous pouvez dire que vous savez que London est une grande ville,
on a traditionnellement été dans l'île,
pourquoi n'est-ce pas le West ?
Alors que les gens vivent en fonction des différents secteurs,
donc que l'on peut aller dans différents places.
Mais ils n'ont pas de la chanson de parler à nous.
Donc en termes de base,
on peut dire qu'on peut commencer à faire des events de l'entrée,
donc on peut juste changer de style de space,
créer l'agenda, avoir une rencontre,
et d'être plus peer-to-peer.
Je ne sais pas si c'est ce qu'on veut faire,
mais on peut en faire plus de deux,
mais je pense que probablement on va en personner,
à l'aide de l'autre.
Mais mon plan de retard est plus en septembre ou octobre.
Et part de ça, c'est aussi l'opinion des vénus pour faire cela possible.
Un problème,
ou bien, un problème,
une chose qu'on doit penser,
c'est que quand on commence à ouvrir,
on a maintenant eu beaucoup plus de membres
qui ne pouvaient pas faire un event en personne.
Il y a un gars qui nous a toujours jointé
et qui nous a jointé dans la session de virtual public,
et qui, de suite,
s'exclut avec un virtual et se fait en personne,
exclut beaucoup de nouveaux membres.
Donc si nous nous sommes en personne,
on pourrait toujours avoir une forme de virtualité
pour cela,
si c'est comme un webcam à l'event
et puis un écran avec la matrix zoom,
je ne suis pas sûr.
Donc une des raisons que je pense
de faire un tour au espace,
c'est que je pense que ça,
c'est que je suis suspectif
que beaucoup de groupes de vue,
des choses comme ça,
on décide d'être en ligne assez utiles.
Parce que, en même temps,
je travaille beaucoup de chez moi,
je ne vais pas en London beaucoup,
je ne pense pas que mon futur
se commette en London à chaque fois,
en fait, on pense que le bain
a l'air un peu plus loin
que London,
parce que je peux en commuter plus.
Et ça veut dire
que l'un des groupes en personne
peut vraiment souffrir
sur la basis de
pourquoi je vais dans la ville
pour aller dans un groupe de vue.
D'ailleurs,
les groupes de vue virtuel ne souffrent pas
de ce problème.
Mais si tu ouvres plus des spaces,
ça tend à être
que tu fais quelque chose
qui, effectivement,
est plus, hey,
j'ai pas le droit de faire un tour au espace,
ça peut être.

si tu maximises
l'utilisation de
personne à personne,
ça peut aider.
Mais j'y agree avec toi,
je pense que c'est sympa
pour qu'on puisse faire un évent
pour les gens de la vie,
David Evans,
quiники des fanatis,
qui le crue awareness encueillant,
par la frère Pour逃ir,
et quiwhy r stroke.
Je suis 터d pourtraire,
Python se dé technician pzcz
ou Jingle���re, les Tutaj, par exemple,
c'est ce qui est là j'utilise plus taller大家好!



je mange de temps Pretty faceacao,
pas mal de temps bred...






Oui, il y a des modèles hypermodels,
et une option pour beaucoup de gens peut être quelque chose comme ça.
On en a tous, et on dit, on va organiser des choses virtuelles,
et souvent on fait quelque chose comme un invité,
une espèce d'Ottawa qui veut rencontrer un certain partagé,
ou un pub-night, pour rencontrer un certain partagé.
C'est une option, il y a beaucoup d'objets potentiellement
pour un dotnet usagroup, c'est UK dotnet usagroup,
qui est virtuel, et puis organiser des chapters de ça,
qui disent, on va avoir un invité en personnel,
ou on va avoir un invité dans un place,
dans un autre endroit, ou quelque chose.
C'est un idéal intéressant,
parce que nous allons avoir beaucoup de masses
plus importants dans ces conférences.
En plus d'être dotnet Oxford,
vous en êtes, vous savez, UK dotnet,
ou quelque chose, vous en dites,
on va juste prendre des meetings virtuelles
pour tous les gens, UK,
ou en bas, on va en parler,
où les organisateurs sont,
mais on va organiser des places locales
où vous êtes, c'est-à-dire,
ça peut être ma travail.
Quand c'est virtuel,
le whole dotnet location,
donc dotnet Oxford, dotnet Southe-Waerst,
etc. les locations sont rélevantes.
Oui, c'est ça.
Je ne suis pas sûr que c'est part de ce podcast,
c'est probablement intéressant d'y inclure,
mais on devrait probablement râper
un grand merci à tous d'avoir regardé,
et une petite reminder
que ce podcast est sponsorisé par Everstack,
qui est mon propre company,
qui a offert des services de développement
et de consultation,
pour plus d'informations visite at Everstack.com.
Si vous êtes en train de rejoindre le podcast,
s'il vous plait,
me portez le nom sur social,
je utilise le hashtag
UnhandledException, et je peux être trouvé sur Twitter
ou sur le site d'Altracan,
et mes DMs sont en train d'ouvrir.
Et mon blog d'Angloire.com
a des liens à tous mes trucs sociaux.
Nous allons inclure les liens
à toutes les choses qu'on a mentionnées
dans les notes de la show,
qui peuvent être trouvées sur
UnhandledException podcast.com.
Sous-titres réalisés par la communauté d'Amara.org