Hey, everyone, welcome to the Unhandled Exception podcast. I'm Dan Clark and this is episode
number 51. And today I'm joined by Ian Cooper to chat about his open source library brighter.
Now Ian joined me back in episode 17 to talk about test driven development, which was quite a
popular episode. And thankfully, it looks like I didn't put him off too much. So welcome back
Ian. Thank you for joining me again. Hey Dan, nice to see you again. You too, you too. So for those
that missed the first episode or don't already know who you are from various talks and community
stuff that you do, could you introduce yourselves to the listeners and talk a bit about what you
do? Yeah, sure. So my name is Ian Cooper. And I have been a software engineer for quite a few years
now. I think it could be close to 30, I suspect. Yeah, I just get like all agréable. My beard
now. And I used to have more hair on my head when I started this. So you can, if you go out
there on to the videos that they're gonna be doing various talks, I talk quite a bit of
conferences. I was very lucky to get into conference speaking because I was a C++ developer.
I worked in fintech in the 90s. I started my career in healthcare and I went to fintech in the 90s.
And both Java and .NET came out. Because I was more in the window space, I got into .NET very early
when I was still in beta. I was on various mailing lists and we were all very excited by this idea
of not having to do things like memory management ourselves and dealing with positive point
orathématiques. So we were all very excited. And there was a post to one of the forums about .NET
saying, hey, the Dallas user groups meeting up tonight, who's gonna be there? And I was like,
oh, that's cool. I must go to the London user group. So I put a post in saying, hey,
when does the London user group meet? And somebody said, well, there isn't one. But if you
started, I'll come to your meeting. So I contacted a few folks in the US who ran them,
a development tour, I don't exist anymore. I'm not sure. Help me out. So we can use the offices.
But when we started, of course, there were no experts. There was no one even at Microsoft,
really. There are a few people we eventually got in touch with. So we had to do our own talks.
So it's like a question of, well, who's gonna do something next week? 10 minutes on something
they discovered in the framework. So I got used to with a quite collegiate sort of atmosphere
standing up and giving a short presentation, what we think of nowadays as a kind of lightning talk.
And then we began to give slightly longer talks. We invite people who knew what they were doing
to speak. So you'd learn by watching them. And that then got me into the first of the developer
developer developers, DDD days in the UK. And that and got me from being seen doing that into
speaking at NDC. So I've been traveling and speaking at conferences ever since. And it's great
because you do get to refine your thoughts on something in order to be able to teach it to
somebody else or present a fact, make an argument to somebody else. So I guess, you know,
a lot of people know me from that test of development talk. But yeah, I've sort of done quite
a few over the time. And I always say, you can look back at my videos, and you can see a progression
of Ian basically all cling cut with, you know, hair on top of his head to Ian with basically,
you know, long gray beard and piercings, etc. And a few people out there will occasionally post
before and after in the software career memes about me. So yeah.
I feel if we take your webcam view and just turn upside down.
I would have luxury luxury hair. Yeah.
I think the first time we met, I remember it was one of the DDD conferences. And it was near
the end. And there was like, you know, when everyone's starting to leave and remember in the
corner near the where the slide deck was, you were sat down, there's like a swarm of people
round and you were talking and there's something like, it looks like he knows what he's doing
cause everyone's like listening and everyone's intending. You just sat there completely chill
chatting away. So I think that was the first time I saw you in person. And then obviously,
you've been to dotnet Oxford and spoken there a couple of times now, I think.
I think it's a few. Yeah. Yeah. I mean, Oxford's quite close for really. I mean,
in terms of travel, it's pretty easy to get to. So you want to be easy, easy groups to come visit.
Yeah, well, we just started going back in person again, cause obviously it's a lockdown
and everything we were on to. And we're just, we're not doing every single month in person now.
We're kind of like old snating.
Yeah. So we just, we just started London up again. And it's a bit tricky to navigate
because of course, particularly in London, because the commute is so painful, usually,
the number of people who are going into the office every day is quite small.
So whereas before people went to the office all the time, we'd say, hey, we're going to be there
on this Thursday. It was almost like, well, I fancy the beer anyway on the way home.
I'll pop it on to London.net, chat with the other dotnet folks here, talk and go for a drink with them.
But now it's more, I've got to ask you to come in on that day.
Maybe one of the days you do come into office so that you come to our talk in the evening.
So there's a bigger barrier to entry, I think, to in person use the groups than there used to be.
But at the same time, also, I think there is a core group of people who have missed face to face interaction,
who are very excited it's come back.
Yeah, definitely. I think as a speaker, actually being on stage, doing your talk in front of real people,
you can see the interactions, you're not speaking to a webcam or anything.
That makes a massive difference.
But I can certainly see from, even as an organizer, it's in the past where I've been working in Oxford
and then I finished working just going to Oxford and we do the event.
Right now I'm working from home, which is, I'm not that far away from Oxford, but it's a bit further.
And just used to working from home and not having a commute.
Then if me as an organizer, it feels like a bit of a chore to actually get all the way to Oxford to do.
Don't know, Oxford.
And then once I get there, it's worth it because it's like the same old faces and we can catch up and everything.
So I think there's an interesting thing.
Right. I think one of the things is, of course, the user group in person meeting in a post pandemic.
It's on a postage of YouTube, to some extent, where you can get a lot of content just by going to YouTube
and your own home and watching it is the interaction.
And that's an interesting thing for us to think about as we go forward as user groups
that have an in-person component, is how do we emphasize that part of it?
And I think one of the things that we may want to play into there is this,
when we first started London, a big constituent of our user group were quite often people like
contractors or folks actually working in very small, they were the only developer,
because they just wanted someone to come and talk to about development, etc.,
almost down the pub afterwards.
Right. And, you know, have a moment with somebody that understood their pain.
Right. And I feel a little bit like that's one of the things we should probably emphasize
about in-person user groups is, hey, look, we are going for a chat afterwards.
I think the only thing in the UK we need to think about in 2023 is,
does that always need to involve alcohol?
Because that is a question we, I think,
not really challenged ourselves enough.
Can we have that social interaction in the UK post-events where we don't always demand
that that is based on the pub, which is, it's a lot of people.
So it's an interesting question.
Yeah, I guess if you kind of went the other way and it wasn't down the pub,
it was something else, then that would also put a lot of people,
people off the waxy enjoys,
especially if it's in a town centre and people enjoy going to the pub
and having a pint whilst just geeking out.
Yes, a double-edged sword, really,
can picture that putting a lot of people off as well,
not having it down to the pub,
because that is an attracting factor to it, I guess.
We need to bounce, I think, basically,
just have a reality so that there are some events
that everybody feels comfortable with.
Yeah, definitely.
The sponsors for our event,
they actually provide the venue and food and drinks and everything,
and they always make sure that they provide soft drinks as well
and even non-alcoholic beers so that they've got their own range,
because a lot of people,
even if the only reason for not drinking
is the fact that they're driven in,
they still want to feel like they're having a drink
or something and taking part.
Non-alcoholic beers are actually quite nice, though.
You're drinking a different non-alcoholic beer than I am.
So we should really talk about Brighter, then,
and I guess the counterpart Darker.
Well, it's probably not the counterpart, is it, really?
But we can get into that as well.
Yeah, yeah, we can get into what the difference is, yeah, sure.
So as an elevator pitch, what is Brighter?
OK.
So Brighter is a...
And Darker, a sister, is it?
Brighter is a framework for essentially commands and events.
And you can either use them in an internal bus,
and by that we would mean just in memory in your application.
So one-point application,
rather than WebABI controller, for example,
rather than exercising your domain model directly,
raises a command,
and that command basically is what actually exercises your domain.
Or, some part of your domain has finished exercising a command
and wants to trigger other parts of your domain,
and so it raises an event.
And our sweet spot is we can do that as an internal bus in memory.
So that's the equivalent of something like Mediate,
which I think a lot of people know, which is all in memory.
Or we can do that basically out of process,
which is the equivalent of things like Mass Transit and EnServe this bus.
We make that fairly straightforward
to kind of switch to one and the other.
So we use Send to be, hey, it's a command with one target,
Publish to be, it is event with multiple targets.
But we use Post to say,
either my command or event is actually
going to be handled out of process.
And what lives in between you and the thing handling out of process
is some message oriented middleware.
We support a range of them.
So we have a range, what we call Transports.
And we support, for example, AWS, Azure, Rabbit, Kafka.
Those are ones that are most frequently used and well tested.
We've also got some ones that are less commonly used around,
things like Redis.
And we're always happy to add new ones.
There are a couple of flights.
MQTT is currently in flight.
It does sound very,
so the two technologies libraries you mentioned,
at Mass Transit and Mediator.
I've used them both before.
And I must confess,
up until today I've not actually used writer,
but it's been on my list for a long time to play with.
So actually doing this podcast has been a nice excuse
to have a little play with it,
which I've been doing today.
And I really like it.
So because I've been used to those two libraries,
it felt, the concept felt very familiar.
And I really like the whole thing of having a handler class
where there's just one method with the application logic
and it's the framework that calls it.
And the handler doesn't need to know or care what triggered it,
whether it's a message on a queue or it's an API call.
The handler just doesn't care.
It's single responsibility principle.
It's very clean.
And you can use DI in that class.
And it's just that same pattern,
which, when I've used Mediator,
it's obviously the same kind of thing with Mass Transit
and the consumers in Mass Transit.
It looks very, very similar.
And also, yeah, playing with writer today,
it's the same kind of concept
where you've got this handler with a method
and you can put your stuff in there
and the system calls it.
I just think that's a really nice pattern, very clean.
Yeah, I mean, we all have slight differences.
I mean, we predate Mediator,
but we, and I think we are about the same time as Mass Transit.
There were earlier dotnet projects
that we learned from, like FUBU was one of the ones,
which Jeremy's got a kind of new version of
called Wolverine out right now.
But I think many of us were operating in that same space.
We were, as a dotnet community,
putting our toes into the water of CQRS
and that kind of thing.
So these things were definitely coming up.
But with the, one of our kind of design goals was this.
We like the way, if you are a dotnet developer,
when you want to write a web API,
you just write a controller, right?
You don't have to really get into the depths of the HTTP
that is underlying it.
I just write a controller, I set it up,
configure it, and effectively,
those HTTP messages get received,
essentially turn into basically a call to my code.
We thought, well, that's really how messaging should work, right?
Particularly for a consumer,
you shouldn't really have to know nothing
about message pumps,
you shouldn't really have to know
anything about the details
of a particular transport and how it works.
All you really want to do is write the code
that runs when you receive a message
and then have us handle,
well, how do I do that in a way
that is essentially reliable
and performant and consistent?
So hopefully, when you look at the way we work,
you'll see that some of the design ideas
come particularly from the kind of SP dotnet model.
So we use attributes on that handler method
to let you control things like whole pipeline
of orthogonal steps middleware,
right, that runs for your handler.
So hopefully, you're familiar with the concept of middleware
and we let you configure it with attributes.
So one of the attributes we let you configure
is to use a policy.
What we do there is we say wrap your handler
in a poly policy.
Now, poly policy is everyone,
I think, in the dotnet community,
really got familiar with when ASP.net adopted them,
but we were a really early champion of poly
and I used to hang out with and speak to Dylan about it a bit
and we loved it because for us,
when we looked over in the Java space
and what Netflix were doing with things like Hysterics,
we really wanted something that gave us
that kind of support for retries and circuit breakers
and we saw this thing and thought, that's great,
we can wrap any given handler call in those facilities.
We want to make it simple.
You don't have to wrap all your code
effectively in the poly code,
you just put an attribute on your handler
saying, I want to use this policy
and we'll do all the work of wrapping for you.
And there are some features today in poly
that we actually built in Brighter
and Dylan looked at and then extracted
those to be general poly features.
So that's one of our early sweet spots
was this idea of saying,
we want to make it really simple
for you to configure a middleware pipeline
as a series of attributes.
So it feels very familiar
if you're an ASP.NET developer,
but it lets you introduce these ideas
like logging or retry or falling back
to a method where if you basically execution fails,
take some action at the end,
in a very simple way.
Yeah, that's very cool.
I'm assuming, so I've said I used Master Transit
before, one of the reasons I kind of like
using that kind of abstraction
and I'm assuming it's going to work the same with Brighter
is, for example, one project I'm working on,
locally in-dev,
we're using RabbitMQ for QAM production,
we're using Azure Service Bus.
But the code,
pretty much all the code doesn't change
except for a little bit of Bootstrap
in Program.cs,
where it sets them up.
I'm assuming it's the same kind of concept with Brighter.
Yeah, so it's adding the same.
So the, I mean, the hardest part,
we were having a little bit of chat before it began.
The hardest part usually of what you're doing
is in the kind of startup or program,
CS file,
where essentially you have to configure everything,
right?
And we have a notion of a publication
and a subscription.
So publication,
if you're producing messages
and a subscription,
if you're consuming messages,
when we have to configure,
well, what am I listening to, right?
I'm listening to a rather endpoint
or I'm listening to an AWS,
basically SNS endpoint.
You have to configure that
and that tells us what you're,
what you're actually listening to
or producing to.
Once you've done that,
it's fairly straightforward then.
Basically,
just writing code
to handle the messages
that get produced.
I mean,
we all have slight variations.
So Mass Transit from memory
has a slightly more fluent syntax
in that sort of more classic
teens era
when DSL,
fluent kind of style configuration
was very popular.
We stuck slightly more to
what we felt was more familiar
to SP.net devs
and we stuck slightly more
with an attribute-based model.
But at the same time,
things evolve.
I mean, we are keen,
I think,
to look at what minimal APIs give
and say,
well, if our design goal
is to try and be familiar
to the SP.net devs,
to have a similar approach,
we need to,
in Prodv 10,
think about addressing
how do we work
in a kind of minimal API
as well,
as our classic way.
And we might,
our current thinking
is we would probably use CodeGen
so that actually you build something
that looks very much like it would have done,
but without having to necessarily write
the class that basically contains your handler,
you'd just write the handler
and we would then basically
co-generate the class
that wraps it, for example.
So, the do-bugging experience
would be very similar to what it is today.
Yeah, yeah.
I've still not,
speaking of minimal API,
I've still not,
I still default to using controllers
and everything.
I can't,
I don't know,
it's the whole one.
They're a bit marmite.
They're definitely bit marmite.
Yeah.
I think that for
a level of complexity,
it's easier
and at another level
of complexity gets harder.
And I think that's always been true
of those kind of fluent style approaches.
If you have low complexity,
it's quite,
it's really quite straightforward.
Once the complexity grows,
switching to the other model
makes a lot of sense.
And I suspect that some of what,
I mean,
we could ask them about this.
Once some of what the SP.NET team
we're aiming at
were in a kind of
microservices
world
where I've got some small service
that has essentially hosted
in a Kubernetes pod
that I don't necessarily want
to write a full on web API style service.
I'm just doing some
chatty internal HTTP communication
between two services
and hey,
something simple will do me.
Right.
And that level of complexity,
I don't necessarily want
all the things I might with the public
by phasing HTTP API.
And given we are using that context a lot,
write someone out brighter
is using the context
to service,
service communication
for doing that kind of middleware stuff.
It's definitely something
we might want to try and learn from.
But what we're talking about
is down the buses,
obviously we can be used
in an internal bus scenario
and we, much like mediator.
The big difference to mediator
is that we distinguish,
we're slightly more CQRC.
So we, brighter in that model
is essentially says
you want to potentially
mutate state
and darker our sister project
says, hey, I want to query state.
And they're very similar
and the way they work,
but it's just that the,
if you like the interface is different.
So with our commands,
we don't expect effectively
a return value.

With darker, with the query,
you have to define
what the return value is
that you're going to receive
at the same time.
And our usual expectation,
if you see a lot of our sample projects
is that you use both
and typically you'll mutate something
and then query something
to give result back to somebody.
That does to create
a little bit of funkiness
in one condition, which is
if you're using something like
SQL identity columns
to generate ID,
so you're not using a GUID
or whatever to be the ID
of the thing you're creating.
If you then want to query it,
how do you get the ID back
for what you've created with the command?
And we do have some
easy workarounds for that one
of those just actually in the command.
Effectively have an out parameter
because you see the command afterwards
and fill in that ID number
and then read off the command
and then do the query.
But that's only not
bit of funkiness,
but we have otherwise
quite distinct
what you think of as command
query separation
in the two.
So if you're like abstracting
over like rabbit MQ
or some message broker
and you're doing a query,
does that then have to
send a request back?
Yes.
So one of the reasons
for separation
is that we don't do
darker over a message
in middleware because
that query model
becomes less sensible.
Now you could do it, right?
And something like rabbit,
right?
What you would do is
we would have to basically
send the message
as a reply to header.
We would basically create
a private temporary queue.
We'd receive the response back
and we'd have to block
waiting for that response
and give you the query back.
We don't really want to go down
that route because
we do support
on the command process
or call method
which we'll do that for
if you are desperate
to do that kind of RPC
syntax.
But the normal messaging model
is send a command
and listen for an event
where the event
is the response back
to that query.
So another reason
for the kind of separation
of brighter and darker
is because brighter
is sending a message
and you have to listen
to an event in response.
Essentially,
the kind of query interface
wouldn't make so much sense
and so that model
is then in darker
where we do,
hey, I just want to
query my data store.
Yeah, that makes sense.
I know with MustTrans
that they've got this whole
request response model
over a message broker
and I must admit,
I'm not,
I don't really like that
so I can avoid
that side of things.
Yeah, I mean,
it's theoretically possible
but under the hood
you're just blocking
on a response
over a given queue.
So we tend to say
it's probably best not done.
We do have a method
called call and brighter
which we'll do it
but we don't tend
to recommend you use it.
It's kind of a get out of jail
clause for someone
that desperately needs it.
Yeah, I tend to like,
if I need a response
I'll do it like a GRPC
request or something instead.
Yeah, I mean,
so messaging,
you know,
messaging has a classic pattern
which is
I send you a command
and I wait for a response
and I use a correlation ID
to tie the two together, right?
There's less people
understood that
in a pre-acing world
in a post-acing world
than everyone gets
basically post-acing
away.
This idea of saying,
well, over here
I'm sending a request
and at some point later
I'll get a call back over here
and then I'll execute
the code that is in response.
And so messaging
does do that pretty well
although we tend to have
some other techniques
a lot in messaging
so we explicitly do few
but there's a technique
called event carrier-stake transfer.
So the only event carrier-stake transfer
is typically
if I'm building
an event driven architecture.
One of the things
I want to avoid doing
is an HTTP get
between my services.
Why is the question?
Well, the reason I want
to avoid an HTTP get
is that that creates
what we call temporal coupling.
So that means
any call like that
any synchronous conversation.
So if you get asynchronous
it's about conversations.
So a synchronous conversation
both parties have to be present
and an asynchronous conversation
which is messaging
both parties don't have to be present.
So the parallel is
a synchronous conversation
is a phone call.
A synchronous conversation
is WhatsApp
or Telegram
or Signal or whatever
your preference is.
And the advantage of asynchronous
is because the other party
doesn't have to be there.
I'm very resilient
to their failure.
Right?
They're not there.
That's fine.
My message basically
goes into a queue
waiting for them to basically
look at it
when they can.
So as soon as she's an HTTP get
I say this service
is dependent on the uptime
of the other service.
If what I do is say
well I don't really want that
I want to be independent
of the other services uptime.
I create a bulkhead
to failure
so I can think about it.
So what the other thing I can do
is say well rather than
making a get request to it
I will ask it to publish
events
about the things
that we all might want to know.
I will listen to those events
and build what's called
a forward cache
or sometimes a projection.
And I can just locally to me
and I can look in my local store
to get that information.
That's important.
We understand we're not doing
any kind of database replication.
So really what I'm caching
is what you would have given me
had I done a HTTP get to you
to give me this result.
I'm just saying to you
could you give me those beforehand
and I'll cache them
and then I can just look them up
locally when I need them.
So it doesn't work for something
where there's a runtime calculation
based on now
or there's some kind of
Cartesian.
So I currently work for
just to take away
and you know understanding
whether a restaurant delivers to you
it would be difficult for me to build
a big table somewhere
that said every place in the country
I'm going to figure out
whether I can get to it.
They can deliver to me.
So I have to look up at real time.
But otherwise
you can try and push this stuff
down ahead.
So that's one way
of avoiding that problem
of you needing to do a
query call.

Because if rather than saying
I'm going to ask you
and you're going to send me the information
which works in messaging.
Right?
You're just queuing up your request.
Someone answers it
and get a response back.
Sometimes if you just subscribe
and I've got the thing
locally before
they'll need anyway.
But messaging will be a request response.
Just don't block.
Just don't block
in a kind of call syntax
when you do it.
That's the thing I'll be wearing
about.
If the sender
or the publisher
was expecting a response
and it's just hung
if it didn't get one
then I think it's just having
as you architect a system
having awareness of
what happens if it doesn't go down
the happy path
and just thinking that through
as architecting.
But yeah, that's quite nice pattern
with the caching.
And I guess it's kind of even
if service B
is caching the thing
and it's still calling out
to service C
and it only uses
the cache if it fails.
It can still
there's various different
patterns around.
Yeah, so that's definitely
a pattern I've seen
sometimes is to say,
okay.
If I mean you can do that
generically
you can say
hang on a call a
a history teacher
for Netflix.
I call tell the service
if it's not available
what was the last good result
I have
which had the same parameters.
If I stored that
I could serve that result
instead and hope that
style result was good enough.
I guess the downside there
is that
if the very first request fails
then it's got no cache data
so it's kind of where
I think your version works
getting the data and caching it
and that's kind of the
temporary source of truth.
Yeah.
So yeah, I think one of the
consensus people have
with that kind of model
is eventual consistency.
Right.
When I deal with messaging a law
and one of the problems
you get in terms of
perception as people go
or I don't want to use messaging
it's going to be really slow.
All right.
I just make an HTTP
call that be faster
and you're like
why do you think it's going to be slow?
So there are a lot of answers
to that particular problem
but let's kind of work through them.
So the first thing is
obviously I am putting
the request from service A
to service B
will go on a queue.
But really
you don't want a lot
in that queue
in terms of
to back up a long way.
The queues purpose
is to hold the message
if service B
is not there.
It's not to make service B wait.

And you can apply back pressure
if service B
looks into a say
constrained resource.
So let's say
it's got a DB connection pool
it can only process
some things so fast.
You can use it for back pressure
but unless you want
use a bit of back pressure
generally what you want to do
have enough
processing of the queue
so that whatever your rate
of arrival on the queue is
and given your rate of execution
you have enough consumers
with
I think with competing consumers pattern
to read the queue
fast enough
that you can control the latency.
Now there's a thing called
a queuing theory calculator.
So queuing theory
just takes that calculation
and adds a bit of a Poisson distribution.
You can find them out on the internet.
And it will tell you
in order to get a given latency
how many readers of the queue
do you need.

And if you then add together
the queue latency for outgoing,
processing and then response
it's not necessarily going to be
that different to an HTTP call
going back and forth.
But you have some reliability
in the event the other service
is not there
that essentially
your question is eventually answered.
Now it may be that eventually answered
is no use to you.
Right.
Which is the whole.
When I query you
if you're not there
it doesn't matter to me
that you will answer me in
you know
three seconds.
The fact that you haven't answered me now
doesn't help my customer
at the other end.
And that's where effectively
the ESST model helps
where it says well
because I've listened to you in advance
I've got this local cached version
and that is how I can respond.
And people say well
that might be stale
and you're like well yeah
but everything is stale.
Right.
If I make a get request to you
and I get a response back
and we're in HTTP body
that's stale
because immediately after my get
someone could have written
made a poster service B
updated the data
the data I've received
is no longer the same
as the data the service B holds.
Right.
It's the nature of distributed systems
as soon as you are distributed
you must deal with eventual consistency
to some degree.
So you have to really
cope with the idea
that your response
could be dealing with stale data.
And so things like versioning
are very become very important
because you have to say
well which version of data
did you use
to create this request
which version have I got
am I able to respond right now
to that problem.
But yeah
I think one of the problem
as the venture of an architecture has
overall is that
these kind of concepts
that you just have to dig into
is a whole barrier to entry
of an acquisition of some knowledge
whereas you know most devs
because they have come from an environment
where they've had to serve
web request to customers
get HTTP
they understand how it works
they've had this bread and butter for them
and so I'm now asking you to learn
a whole new set of patterns
and approaches
in order to succeed at this
and it feels like
it's just going to be easy to do HTTP
that's the thing I know
and that's the big problem
I guess we have in the messaging space
is that kind of barrier to entry of
but how do I succeed at this.
But I always say
start light right
it's the same way we all learn stuff
when I
I thought I started messaging
back in the 90s
and I worked for a fintech
and we built risk management software
mid-tier investment banks
and my boss came to me one day
and he said
there's this new product
like BMMQ series
I can't but it's called now
it's something else
I've ever rebranded it to
it's like a message queue
we don't know what it is
but we know the banks are telling us
we need to start using this
so we can help integrate with them
I got given this manual
it's a IBM manual
and told figure out how to use it
and I had no idea right
I could make it work
but I had no idea how you would use this
unfortunately there was a guy
called Marcus Rainbow
great name
and Marcus
talked me all about brokers
and pipelines
and that was kind of the start of my journey
but there was an enormous body of knowledge
to have to acquire
to be able to suddenly use this stuff
beyond
here's a manual
I can put something on a message queue
I can take something off
to understand
but what does that mean
and I think that is the
slight problem for messaging
so yeah
I mean we certainly see that
we see a number of people
essentially just use
Brighter as a media alternative
Right
and what they
what do they want Brighter
as opposed to media
Sort of a menu
because we have a middleware pipeline
it's what we call
Russian Dole model
and that is that
each pipeline component
encompasses the next
pipeline component
so if you think about a try catch block
essentially inside the try catch block
I call the next component
which could have a try catch box
which inside the next component
and that let's us do things
comme utiliser Poly, parce qu'on peut dire, on peut rappeler tous les plus bas.
Donc, certains de ces gens sont comme nous, parce que nous avons ce type de pipeline distincte de la Russie et de l'Ordre.
Donc, est-ce que ça est comme dans le site ASP.NET, dans la place du MW?
C'est l'un des deux qui s'appelle Next, dans le méthode.
Oui, exactement. Donc, si vous utilisez un ordinateur de request,
un des choses, si vous vous réévolez un ordinateur de request,
c'est que, après votre ordinateur de request, c'est que vous appelez le type bas,
quand vous retournez pour passer le ordinateur de request.
Maintenant, beaucoup de gens ne font pas de règle après, parce que, en fait, c'est un model russien,
mais il existe si vous avez besoin de ça.
Il y a un débat intéressant, il y a quelqu'un qui n'est pas sur le team qui parle à Jimmy
de mediator et dit, vous pouvez le faire?
Jimmy dit, il ne le fera jamais, et on dit, c'est OK, ça va bien.
C'est un peu trop fort.
Mais oui, c'est un peu comme ça, on voit beaucoup de gens qui utilisent ça,
parce qu'ils veulent la pipeline de la mW et ils veulent la distingue
entre la C et la CQS style.
Et puis, il y a un groupe qui dit, hey, je veux le faire,
je vais le faire en mW, et ça se trouve,
vous me donnez beaucoup de choses que je dois faire.
Donc, ce que Brightwell va vous donner, c'est le plus facile,
c'est que vous pensez que Brightwell va vous donner des postes,
et ça met un message en mW.
On tend à recommandation de utiliser le mode split,
et ça fait des postes de deposit,
des out-boxes de clear, pourquoi ça se fait?
Il y a un problème en message,
c'est que si je change de state dans mon database,
comme je dis, je vais donner un ordre pour la pente,
et je vais donc envoyer un message,
je vais envoyer un message à mon service accept,
disant que je vais prendre la pente.
Mon code dans ce service est maintenant assuré,
il y a un message en dessous,
et quand je suis en train de reposer la réponse,
et quand je prends le message en dessous,
le message est accepté,
notre marché est terminé,
et je vais aller au suivi,
ou le message est rejeté,
et je vais faire le suivi,
mais ça peut être qu'il ne soit pas là pour toujours,
sans avoir été envoyé,
parce que, potentiellement,
mon code de la pente a été faible,
donc je pourrais avoir toutes les transactions que je veux dans le database,
mais si mon code de la pente a été faible,
le service n'est jamais pas avancé.
Comment je vais avoir un moyen de dire
que si je change le database de ce database,
et que le database est en train de s'apprendre,
je vais envoyer un message.
Et le problème est que, maintenant,
nous n'avons pas des shops de clous,
où, une des données de Microsoft
qui nous permet d'avoir toutes les outils que nous utilisons,
n'a pas de manière à avoir une transaction
qui fonctionne entre mon message et le database.
C'est ce que je pense que le patent de la pente a été faible.
Et le patent de la pente a été faible,
alors que, avant de le dire,
le message est rejeté,
je vais envoyer un table de la pente,
et je peux mettre le même transaction que votre entité.
Maintenant, je dois réétenir les deux choses.
Ce que je peux faire, c'est que je peux avoir
quelque chose qui est réétenu de la table de la pente,
et puis, envoyer des messages
qui n'ont pas été dispatchés pour moi.
Ce que nous recommandons de vous faire,
c'est deux pas de la pente.
Vous vous rendez des outils à l'outil,
et vous vous rendez des outils à l'outil,
et vous vous recommandez,
que vous faites de l'outil,
et vous vous remerciez de l'outil,
pour que ça soit réduit à la latitude.
Et dans un autre processus,
vous vous rendez un sweeper,
qui dit que je regarde les choses qui n'ont pas été sentées,
et je les envoie.
Donc, si vous avez des outils au bout,
vous avez fait un fail,
vous vous rendez un outil à l'outil,
et vous vous envoiez des messages
qui n'ont pas été sentés pour vous.

vous devez être préparés pour des duplicates,
parce que je vais envoyer
les messages et vous vous envoyer
les messages à l'outil,
donc, en théorie, vous pouvez
les duplicates à l'outil.
Et c'est pourquoi nous avons pris
la garantie de la première livraison,
par exemple,
nous avons promis sur un texte,




on a des exemples de la façon dont vous faites ça.
On travaille avec Dapper, EF Core et des autres des main-bords que vous voulez.
Et ça vous donne la correcte quand vous êtes en train de vendre.
Et puis il y a le consommateur, où on fait beaucoup de travail.
On appelle ça un service activateur, c'est juste un nommage technique.
Et ça signifie que quand vous avez un nommage,

votre code se tourne quand un signal external,
que votre code est juste là, en dessous,
quelque chose se passe quand on tourne.
On fait tout le travail en faisant un message pump.
Un message pump est un truc standard, il y a des messages offre-cut.
Il traduit les messages, c'est à dire que le message sur le « y »
est probablement un JSON, ou bien un format binary.
Et vous voulez que vous puissiez convertir ça en un type.net.
C'est le même truc que si vous utilisez un web API controller,
vous ne regardez pas le « raw HTTP »
le « HTTP » est converti en un type, le postbody,
et ça vous présente pour vous, pour le faire.
On le tourne en type, c'est un « command » ou « event » dans notre part, dans le système.
Et puis on dispatche ça.
Alors, on invoque le « command » processor,
que vous utilisez sur le bus interne,
donc le bus interne effectivement est ce que nous fâchons,
mais on a entendu quelque chose au-delà de la bus interne,
et vous vous appelez le « handler »
Donc, si vous êtes sur le bus interne ou l'extérieur, c'est le même modèle.
On a un « command dispatcher » qui dit
« Hey, ce command ou « event » doit aller au handler,
trouver le « registered handler »,
et vous envoyez le code,
mais vous pouvez également invoquer le code
par « Hey, on est interne,
et je fais un « command » processor post-door,
plutôt que de la post-door,
ou vous pouvez être extérieur,
en ce cas, on réunit le « message pump »
qui fait que vous portez quelque chose de l'envers de la queue,
crée le « command » et puis invoque le « command » processor
pour le mettre au « handler »
C'est le même processus,
on va juste déclencher plus de ça pour vous.
Et puis ce que nous essayons de faire,
c'est des�bl recover la feeling...
C'est exactement pourquoi nous essayons d'ex소리-médie

nous ne faisons pas encourage without having the funniest
de la suite.
On n'est pas sûrs qu'on ne peut pas vous dire comment la production est bien
nécessaire, mais les autres sont, on peut dire, qu'ils se sont
mis à l'aise chaque jour et qu'ils ont délévé des résultats pour les
clients.
Je pense que ce que j'ai dit, c'est que tu as dit que beaucoup de
choses que les développeurs ne ont plus besoin de se décerner
avec eux.
Tu as mentionné avant que les gens qui étaient used à les
utiliser comme le reste et ce genre de choses.
Et maintenant ils sont en train de se faire un avantage d'architecture
et les complexes de la système distribuée, ils ont suddenly
beaucoup à apprendre.
Et ce genre de choses, même si ils ont toujours besoin de comprendre
les concepts, parce qu'ils ont besoin de comprendre quand j'ai mentionné
avant de faire un passage de bonheur et ce qui se passe si
quelque chose se passe.
Il y a beaucoup d'autres choses qu'ils n'ont pas de
comprendre parce que les choses comme le bruit ou la transmasse
sont en train de faire.
Et comme j'ai dit avant, j'ai joué avec eux, j'ai
littéralement appris deux classes, une qui était un
handler qui était classique, j'ai mis un code qui a fait
l'initial console.writeLine Hello World et puis effectivement
un DTO.
Mais c'est juste deux classes très simples et tout
autre juste marche pour moi.
Oui, c'est pour le coman d'expérience sur ce que tu
fais en fait, c'est que je veux séparer les paramètres
du corps métier.
Et tu dis que, plutôt que de la mienne avec des paramètres
de la zone et du corps métier, ce que je fais c'est
prendre ces paramètres et mettre un objet qui est
essentiellement ton base classique qui est
le requiert et on dérive des commandes d'un
coman et le coman est un exécuteur possible et un
coman est beaucoup possible.
Le coman va descendre et le coman va publier.
On va juste utiliser le type pour contrôler
ce comportement.
C'est juste les paramètres, c'est les paramètres
des calls que tu veux faire.
Donc, en général, dans l'insight, tu sais
que les paramètres sont lesquels tu veux passer.
Et dans le coman, tu as le code qui te fait
exécuter dans le respect de ce call pour les paramètres.
Et cette séparation de les deux,
vous le separating de, par exemple,
le contrôleur où tu es en train de
dédié avec la STTP en disant que tu peux exécuter
mon domaine, tu peux effectivement juste
évoluer les paramètres et aller au-delà
d'autre, dans le coman, c'est où tu
exécutes ton logic de domaine.
Et il y a une bonne séparation de clé,
ça aide à tester aussi,
parce que je peux évoluer
beaucoup de mes tests d'exécution
sur ce niveau, et puis je peux
vraiment dévier le contrôleur qui
doit essentiellement produire
ce message. Je ne dois pas
savoir où ça va, je dois juste savoir
que tu as évolué ça. Et ça simplifie
un peu ton logic de tester un
contrôleur, de savoir que tu as évolué
un coman avec les paramètres corrects,
ce qui peut être vraiment aidant.
Si tu es développé en utilisant
un Briter,
tu as un concept de test
qui est un concept de test
où tu peux simuler et vérifier
que un message a été
évolué ou que quelque chose a été évolué.
Nous faisons nos tests,
pour que tu puisses les prendre,
il y a un processus de commande
qui est assez spécifique, je ne me souviens pas
de ne pas se surpasser directement
à l'extérieur de Briter,
c'est un aide testant, et c'est pas
une bonne séparation, nous avons
des tests sur nos libraries, donc nous
pouvons en théorie surpasser, donc
que tu puisses utiliser un processus de commande
pour dire que
tu as été évolué.
Mais le processus de commande
n'a pas de complexe interface,
donc même en écrit un simple fête
qui dit que recorder les choses qui sont passées
pour envoyer le command dans la longue liste
et ensuite vérifier, c'est très straight forward.
C'est ce que nous faisons, tu peux me faire
passer nos codes de test, nous avons un lot de tests,
donc tu peux aller voir
et ça va vous aider à faire ça.
Mais tu as aussi réussi
à créer un souci
pour nous dans vos aventures,
c'est assez intéressant pour nous
pour les listeners qui ne sont pas au point
de commencer le podcast, Dan a dit
je pense que j'ai trouvé un bug, et j'étais un peu
comme, oh non, donc on a un
très bon bug, nous avons un nouveau
release, et il y a un pre-release,
et nous avons juste vécu un pre-release,
et c'est toujours le moyen que quelqu'un
trouve un peu de bug pour venir le pré-release,
et Dan a mis un peu
de ça parce que ça ne s'est pas passé
quand, qu'est-ce que Dan, tu as...
Je l'ai trouvé
un projet de dotnet
donc un projet de dotnet, un worker
et j'ai ajouté
les trucs plus brillants,
et quand j'ai pris le jeu, je me suis dit
quelque chose de stockage, je n'ai pas
réussi à réagir des trucs d'I,
donc je suis
un sample de la sample de la sample de la
github et la poste, et
je l'ai downloadé, je l'ai pris,
on l'a troisi dans le Blizzard
pas mal si skillant.
Alors, c'est comme ça対 Face


Dont je veux 놓ire
Auch tu vois un aid

qu'il signifie que c'est pas des
brésilies comme ça, et c'est pas
vraiment ce qui arrête ?

la crafting enfance a maintenant

par default.
Donc, par déleter cela, cela signifie que l'environnement n'a pas été réglé.
Donc c'était cela qui a été déclenché.
Donc il y avait quelque chose à propos de cela.
Donc il y avait toujours un problème, après ce que nous avons discuté.
Oui, donc nous pensons, juste pour les listes, que c'est parce que nous avons construit
un nouveau transformateur, un de ces clés de clé, donc un message, si je ne veux pas
avoir, mettre un grand payload sur le message, un des choses que je peux faire est mettre
ce payload en des storeurs de plus en plus, S3 ou sort de bloc de blocs.
Et pour le moment, il a juste mis la idée de où ça est dans le message de l'équipe
d'un autre, il a envoyé un message sur le noir et sur l'autre côté, il a pris le
fond de S3.
Donc nous avons fait ce que nous faisons à la suite de vous, vous vous postez un attribute
qui dit que si mon payload est sur une certaine dimension, on l'offre.
C'est un de ces clé de clé.
Et un de ces clé de clé, il a besoin d'un provider de store, où vais-je faire
un clic et lire les choses.
Donc nous avons fait la question, je pense que ce qui se passe et que vous l'appuyez
est que nous sommes enregistrés, comme part de notre autorégistration, en basé de
un hostbuilder, nous sommes enregistrés un whole load de types de bâtiments.
Et si vous n'avez pas un provider de store, ce que la collection de services fait
en développement, c'est de faire un check pour dire, hey, peut-je résolver toutes les
dépendances qui existent à l'intérieur de moi et c'est simplement de dire que je ne
peux pas, parce que pour ce point, vous n'avez pas un provider de store.
Maintenant, bien sûr, vous ne pouvez pas en utiliser un provider de store, c'est
ce que vous faites, c'est ce que vous avez pas donné.
Donc oui, c'est un issue intéressant, vous devez revenir et figurez ce que nous
faisons, où vous n'avez pas vraiment donné un provider de store, on ne doit pas
penser qu'on ne soit pas enregistrés à ces classes, mais c'est un point

Donc c'est un bon issue pour nous de se faire.
Je vais inclure un lien avec ça dans les notes de la show, pour les issues de github
que je vous ai réellis.
Oui, ils peuvent nous faire fixer, c'est un débat qui va se passer.
J'ai eu une documentation de me dire, c'est un issue, c'est bien, n'est-ce pas?
Oui, vous avez fait.
Il devrait être un person de QA.
Il devrait être, oui, oui, donc notre documentation est en
github et c'est présent et à date.
Il y a un ancien SEO optimisé, l'optimisation de l'application,
le goparin, c'est juste un peu à la date.
Et la raison pour laquelle nous n'avons pas fixé c'est qu'on va dans le
sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,





c'est un sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,


on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,

on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,

on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,



on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,


on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage,
on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le s
ondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va
dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage, on va dans le sondage
c'est votre classe, quelque chose de ce que nous avons créé, comme nous l'avons dit, vous nous donnez un command, nous allons créer l'instance de la réquestation de la dédicence, mais c'est votre classe.
Donc nous ne savons pas vraiment comment créer ça, nous ne savons pas vraiment ce que nos appendances sont.
Donc ce que nous devons faire c'est que vous le créez.
Ce que nous avons fait par Maxime, c'est que ce que nous avons besoin est une facture que vous implementez.
Nous ne voulons pas abstracter un container AOC, nous devons faire les choses toutes.
Nous voulons une facture que vous vous instantierez.
Donc nous avons, par exemple, une facture de la dédicence, qui est une méthode, deux méthodes qui ont créé une rélease, nous allons juste dire, donnez-nous une de ces, right?
Maintenant, avec le host builder, nous vous donnons une shelf wrapper, un collecteur de services pour une facture de la dédicence, mais vous pouvez supporter Ninja, structure map,
tous ceux autres, par juste créant votre propre facture de la dédicence.
Donc, il n'y a rien que vous avez besoin, vous pouvez le construire.
Et donc, dans notre documentation, je vais vous expliquer comment configurer le Brighter à un niveau très bas,
où, effectivement, vous vous throwz un host builder, et vous dites, OK, ici sont toutes ces choses que je dois basicement vous donner
afin d'avoir une instance en travaillant, et surtout, c'est autour de l'AOC et de la compétence de la rédicence.
Mais c'est vraiment utile.
Donc, internally, l'autre jour, nous avons eu un code ou l'old, que c'était, en fait, un project de la dédicence de la dédicence.
C'est une bonne pièce de kit, c'est encore le travail qu'il faut faire, il n'y a pas besoin de rewrite, à ce point de temps.
Mais c'est écrit dans la structure map, c'est la dédicence de la dédicence, nous voulons utiliser le Brighter support Kafka dans ça,
et ça est parfaitement viable pour nous, right?
Je dois vous montrer comment faire ça, mais nous pouvons dire, bien, nous pouvons mettre un facture de la dédicence de la structure map,
nous pouvons ensuite placer la structure map, nous pouvons faire un tour complètement de l'intérieur de la dédicence de la dédicence.
Je ne sais pas comment les autres transports de la dédicence de la dédicence ont été réalisés aujourd'hui,
on continue de avoir ce niveau de compétence de la dédicence de la dédicence,
mais nous n'avons pas besoin d'abandonner nos amis en utilisant la dédicence de la dédicence,
jusqu'à ce point, nous sommes absolument presque forcements par Microsoft,
ou même si il n'y a aucun personne qui veut qu'il y ait une dédicence de la dédicence de la dédicence de la dédicence de la dédicence.
Oui, ça me semble. Je pense que c'est plus important de cléir les listeners,
nous sommes en train de parler de la compétence de la dédicence de la dédicence de la dédicence,
par exemple, si vous faites un nouveau projet, vous avez la dédicence de la dédicence de la dédicence,
et ça fonctionne.
Le bâtiment de la dédicence a été construit, donc vous devez aller sous la couverture,
dans ce que nous faisons pour vous avec le bâtiment de la dédicence de la dédicence,
mais généralement, il y a beaucoup de gens qui ont besoin d'understand que les gens ont vraiment contribué à ce que ce soit le plus grand.
Donc, si vous voulez contribuer à ce que ce soit le plus grand, vous devez être vraiment bienvenus.
Donc, s'il vous plaît, vous pouvez vous recommencer des problèmes.
Le autre chose que nous souvent recommandons, parce que certains gens veulent bienvenu le bâtiment,
mais ils ne sont pas vraiment bienvenus, et nous disons,
« Réglisez-vous des projets de tests, vous pourrez probablement créer quelques problèmes, comme le fait d'Ambit.
»
Surtout que si vous vous trouvez des docks, vous pouvez trouver quelques issues avec des docks,
parce que nous réglons les docks pour savoir comment le bâtiment fonctionne,
donc c'est vraiment difficile pour nous de faire des docks pour quelqu'un qui est nouveau.
Donc, si vous êtes nouveau, vous avez beaucoup d'insights valibles pour nous,
mais nous ne pouvons plus les avoir.
Je sais bien comment ça fonctionne, donc je me refais les gâts.
Si vous êtes nouveau et que vous vous trouvez des docks,
et vous vous dites, « Ça ne fait pas de sens à moi, c'est la meilleure réponse que nous pouvons avoir,
parce que c'est dit qu'on a un nouveau personne et nous pouvons ensuite correcter et ajuster avec votre aide,
pour faire cela mieux. »
Donc, je me dis toujours aux gens,
si vous voulez contribuer à l'open source, ne vous underestimatez pas les docks,
et nous vous en avons de la connaissance, parce que vous avez aidé à fixer les docks,
et vous vous demandez beaucoup de questions.
Et typiquement, vous pouvez dire, « Est-ce que je peux prendre quelque chose ? »
On peut souvent, en fait, avoir des choses comme,
« Vous pouvez faire des transports. »
Donc, « Transport » est une abstraction pour un bâtiment de la moyenne,
parce que ce sont des deux, on n'a pas été découvert.
On peut dire, « Hey, on n'a pas été découvert, on a pas été découvert, on a pas été découvert. »
On va faire des transports, et c'est assez fort pour nous,
parce que c'est seulement un couple d'interfaces,
vous devez construire tout autrement,
vous pouvez, assez bien, avoir une première version de la couture,
et nous pouvons travailler avec vous,
pour un plus standardisé pattern,
de comment nous ferons cela,
pour que vous puissiez faire cela plus robustement,
avec vous, incrementale.
Et cela tend à être assez fort,
ou même un bâtiment de la moyenne pour nous,
et cela vous permet de faire plus loin,
pour potentiellement contribuer,
à prendre des docks,
dans la plateforme cor, et ce genre de choses.
Donc, c'est bien, et nous avons eu des gens,
Paul Ridden, qui est maintenant un des maintenance,
il a appris dans nos vies,
il était très enthousiastique,
et maintenant, il a contribué,
à des plus grands features,
pour la plateforme.
Donc, les rostres de l'exchange de source d'objet,
de l'exchange de temps,
c'est toujours très bien pour nous,
de nous donner des gens,
et ils sont enthousiasmants et infectés,
parce que,
quand vous avez un nouveau personne,
et qu'il y a un de ces features,
il excite tout le monde,
et il dit,
« Oh, c'est génial,
on va vraiment en faire,
parce que les gens sont intéressés,
ils utilisent, ils veulent en faire des features. »
La autre chose que je dirais,
c'est que parfois,
on voit que les gens construisent des transports,
etc.,
internement, dans leur entreprise,
pour les choses qu'ils veulent utiliser,
pour lesquelles nous ne sommes pas en supportant.
Et notre grand plaisir,
c'est que vous contribuez à ça,
c'est vrai.
Pour la fois,
nous n'avons pas un servicebus,
qui a été utilisé pour quelque temps,
et c'est parce que,
les maintenance que nous avons,
nous avons travaillé sur le servicebus,
nous avons vraiment besoin d'un de nous,
d'un de nos bons uns,
qui est utilisé pour l'exchange de servicebus,
pour que les gens signent,
чтобы bitch jouer,
encore un samedi après la nuit,



mais pas de repos.
C'est malade à comprendre,
les entreprises ne comprennent pas
la contribution de la source,
mais la gratitude va le faire, je vous promets.
Je pense aussi que c'est pas juste
un nouveau transport,
c'est pas des fixations,
si vous travaillez dans un projet d'open source,
vous faites un fixation, vous partez
le fixage, vous l'appuyez, vous l'appuyez,
vous l'appuyez, vous l'appuyez,
et vous l'utilise,
oui, pour exemple,
on a des choses où
on a fait une petite décision,
on a une autre journée d'un autre,
ils veulent juste changer
le manière dont nous avons écrit
les hauteurs de notre message
dans Kafka.
C'est quelque chose qu'ils ont besoin,
et pas tout le monde,
ils pouvaient juste fixer ça pour eux-mêmes,
mais ils ont mis le PR,
ils ont mis le PR, ils ont mis le plus tard,
c'est une point d'extensibilité,
et on regarde ça, et on dit
que ça ne marche pas pour eux,
c'est pas vraiment
compliquant de faire des choses,
c'est un truc qui peut être
un peu override si vous voulez,
mais en général, mon expérience
a été une personne qui a fait ça,
ça peut être que des autres veulent faire ça,
et en fait, seconde ou troisième fois,
nous commençons à voir un
requirement générique
qui est en train de bubbler,
que nous voulons adresser
en un futur version, dans un moyen intéressant.
C'est un peu tangible, mais vous vous souvenez
avant que vous parlez de la standard.
Et
2 vs 2.1,
je pensais que c'était 2.1,
je pensais que c'était Spann,
et je pensais, oh, ça me rappelle,
quand j'ai créé mon commande,
j'ai créé le spann propére,
et je pensais, pourquoi j'ai pas
un Spann ici, et j'ai vu le type
et c'était l'activité, et c'est comme, oh,
un truc télé-métri,
et je pensais que c'est cool
que c'est en fait partie de toutes les messages
différentes. Donc, presumably,
ça veut dire que vous vous entrez
à l'intervention, que vous vous tracez
autour des services différents.
Oui, donc, l'Hôtel est
nouveau pour nous de V9, mais nous sommes très
très contents de l'hôtel, parce que
ça donne à tout le monde, l'hôtel a un bon standard,
et ça veut dire que vous pouvez
se connecter, comme vous,
de donner des providers dans leur espace,
vous donner vos compagnies, ou vous utilisez l'hôtel,
et vous vous en avez à faire des valeurs
ou des flashboards, et tout le reste.
Donc, oui, nous ne voulons pas être en black box,
si vous vous en avez à l'intervention,
c'est ça, vous savez, il va dans le Brige,
il ne va pas sortir, alors nous
l'intervention.
Nous verrons probablement plus de
l'intervention sur l'hôtel, c'est un support
assez basé, et nous voulons
penser à plus de plus, donc
si vous utilisez l'hôtel et vous voulez
donner des feedbacks, ou même faire des PRs
pour apporter la façon dont l'hôtel fonctionne,
pour le premier, vous êtes prêts à voir ça,
ça va être bien.
Je l'aime beaucoup.
Je ne pense pas que c'est assez là,
dans l'opinion téléphonique, mais je pense que c'est
vraiment beaucoup de choses qui sont embrassées.
C'est vraiment la bonne direction, c'est comme...
Oui, c'est vrai.
Un autre chose qui est relaté au-dessus de ce que vous parlez,
qui est le APR, qui, si vous n'avez pas parlé,
par rapport à quelques paroles de conférence,
est effectivement
l'application d'application, mais pour
les messages, pour les conversations.
Dans le V2, il y a des
niggles, parce que ça a essentially
commencé par quelqu'un qui a dit
que je veux prendre l'application APR
de format parrainé
et faire une version synchronisée
et il y a un couple de...
des états de faute de faire ça,
un version 3 qui va se fixer.
C'est un bon exemple de standard
qui, même dans le V2, est bien adopté,
parce que le tournage et tout le reste
continuent à être construit
pour soutenir ça, que,
en passant, ça sera vraiment positif.
Nous ne faisons pas de support pour ça,
maintenant, au APR,
on a tendance à
recommencer un modèle contract 1
et de la faute de faute.
Mais, en V10, il y a quelque chose
qu'on commence à penser, on veut
donner des états de faute
pour générer des projets
de la faute,
vous avez des états de faute,
pour générer des projets de faute
et vous pouvez aller y construire
ça.
Pouvez-vous faire des hoseurs
voilà, et tu as senti
s'il y avait jedem,
nothin à fluoriser,
c'est un moyen pourborgir et
hypocriser les objets de core.
Et après.
Moi tu n'as jamais eu deרך
et je n'ai pas de vainque part.
Il y a quelques pensées intéressantes.
Dans les cas de Brighter, on tend à imaginer que vous re-actez à un événement,
que vous recevez sur un stream de Kafka et que vous faites du travail avec ça.
On utilise l'entreprise de la cliente.net, et sur ce point, on fait des managements sur des offs.
On fait ça parce que Brighter a un standard de la façon dont ça fonctionne avec les Qs.
C'est ce que nous n'avons pas à faire avec la Q.
Nous n'avons pas à délire la Q, la message de la Q,
jusqu'à ce que vous acknowledgez, ce qui signifie que votre handler est complet,
alors nous agons.
Nous agons en fait si vous vous mettez une exception.
Nous ne regardons pas l'application d'erreurs,
parce que vous n'avez pas de raison pour ne pas mettre la message de la Q,
et que vous dites que vous voulez mettre un message de défaut,
une exception de défaut,
qui dit que, en fait, en ce cas,
plutôt que de l'acquier la message et de la logger,
je veux que vous ne vous n'aurez explicitement pas à cacher la message
pour que quelque chose ne peut pas être mis en place.
Mais d'ailleurs, ça tend à être notre politique.
Ce qui veut dire que si vous êtes en train de procéder en maîtres et que vous crachiez,
ça ne peut pas activer.
Donc votre service commence et vous commencez à travailler sur la message.
Avec un stream, vous ne vous en dealz pas avec la Q,
sur la message vous en dealz avec la loggerie,
avec les records, et vous vous en managez en offset.
Nous ne devons pas être incroyablement offsets,
jusqu'à ce que vous puissiez effectivement avoir un point de biais pour nous.
Et puis, on a des works qui permettent de vous mettre en place des offsets
pour vous et des batchs pour improvement de performance.
Vous pouvez mettre en place des batchs et nous dire
comment vous voulez mettre en place vos batchs.
Vous persistez des offsets?
Donc, le Kafka vous en a dit, le Kafka client tend à persister.
Maintenant, c'est un Kafka modern, c'est en Kafka,
il used à être en Zookeeper, mais je suis sûr que c'est maintenant.
Je ne peux pas voir le version de Kafka que ça change,
mais c'est en Kafka.
Je pense que, je ne sais pas si le plus l'on est en Kafka
ou si c'est en Kafka, mais c'est en Kafka.
Je pense que le Zookeeper est maintenant seulement utilisé pour les élections de leader
par le cluster, mais je ne vous en parle pas, je ne me souviens pas.
Donc, ça fonctionne en ce principle avec Kafka.
Il y a un couple de choses que Brighter n'a essentiellement pas...
Vous pouvez l'affaire avec Brighter, mais pas sans un restart.
L'une des choses est que, quand je commence à consommer mon stream,
on assume que je vais lire mon offset de la store,
si je n'ai pas eu un offset, je vais commencer à commencer.
Si vous voulez commencer à lire,
vous devez configurer une publication,
dire que vous devez lire ici et se couper.
Effectivement, vous devez configurer ça,
vous devez mettre un variable environnement,
lire le variable environnement, et faire la publication.
L'autre chose que je veux faire avec Kafka,
c'est la nature du single thread de Kafka.
Si ce que vous avez est un stream de Kafka
ou un partition dans le stream,
parce que si vous avez beaucoup de work, vous devez partitioner.
Si vous voulez lire un ordre, vous devez utiliser un single thread.
Si vous essayez de utiliser plusieurs threads,
vous devez faire l'ordre,
parce que je le read le premier,
l'autre thread le read le deuxième,
mais si le deuxième finit le premier,
parce que ça peut arriver en concurrence,
particulièrement, ça fonctionne en testant,
puis, il ne faille pas en production,
vous devez utiliser les choses au ordre.
Vous devez utiliser un single thread.
En fait, Kafka, quand ça fonctionne,
enforcee cette idée que,
dans un groupe de consumer,
seulement un thread
doit procéder un partitioner à un moment donné.
Maintenant,
Brighter,
a un model single thread de département
pour ceux qui sont assez vieux,
c'est le même moyen, effectivement,
Je pense que c'est un nightmare.
Oui, Windows Forms
fonctionne, c'est un thread STA,
et c'est le même moyen que Windows,
et ce que ça veut dire, c'est que
Brighter utilise un thread
pour un message,
donc quand vous read un message
en bas, c'est le même thread
qui effectivement
transgne
le message, dispatche le message,
et processe le message,
ensuite, il revient pour avoir quelque chose
d'autre, en bas,
et il y a des bufferingues
et tout, mais on ne va pas le faire,
parce que ça complique le modèle.
Et le raison que Brighter
offre à vous un message single thread,
c'est que si vous vous rendez
un message,
et Brighter vous donne des messages
pour les abonnés,
mais si vous vous rendez
un message, votre ordinateur est préserve.
Et c'est vraiment surprise, si vous êtes single thread,
et que vous êtes très vieux,
parce que vous n'avez pas de contexte.
Donc il y a un modèle naïve,
qui vous voit un peu de la mode
qui dit,
« Je vais avoir un poids,
et quand je read un message,
je vais donner un poids. »
Et ça marche bien pour eux,
en bas volume, si ils ne sont pas inquiets
d'en prenant, un poids très high,
ce que vous voyez, c'est que ces frameworks
sont sur le point, et ils sont sur le point
parce qu'ils sont contexte,
parce qu'ils ont lu beaucoup de messages
sur le poids,
et ils ne peuvent pas
ne pas se switcher entre eux.
Et ils ne peuvent pas appeler ce qu'il s'appelle la pression de la back,
donc la pression de la back
veut dire, « Je veux limiter le nombre
de choses que je read,
pour éviter ce problème. »
Donc on a dit,
« Vous avez explicit de contrôle
sur le nombre de threads
que vous utilisez
pour les messages de la queue. »
Donc, un autre problème,
c'est que vous avez essayé de mettre un poids,
où vos problèmes vont être,
par exemple, qu'ils justent de fixer,
mais ça va déterminer le nombre
de threads qu'ils vont utiliser
pour les reads de la queue, pour les caller
« LambdaWid ». Vous n'avez pas de contrôle
sans la suite de la recueillie, etc.
On l'a dit explicitement.
Donc on a dit que la choice de la single thread
est de la modélisation.
Nous avons de la support pour Async,
les pipelines sont effectifs,
nous avons notre contexte de synchronisation,
donc, c'est un peu comme les formes
qui sont à travail.
Mais quand vous avez un casque,
je vous recommande
d'utiliser un pipeline synchronisé
avec une single thread,
parce que c'est la seule façon
que vous allez préserver l'ordering.
Dès que vous vous dites que vous devez être Async,
c'est ce que je dois faire dans le monde moderne,
tout le monde est au bout.
Parce que maintenant, on ne sait pas
où vous allez procéder à ces choses.
Et si vous utilisez multiple threads, c'est le même problème.
Nous avons un client de Brighter,
qui a un test de volume très high,
et ils ont fait des threads
de Brighter et Async,
et c'était vraiment stressant.
Nous avons dit,
« Switch tout le monde et retournez-vous
à une single thread ».
Et ça a été très bien performé,
et c'est la toute de la route
par les messages de Q.
C'est un peu cautuel,
parce que je comprends
que nous avons été tous les deux,
nous avons été tous les deux,
nous avons été tous les deux,
nous avons été tous les deux,
le multithreading est bien,
juste d'être cautuel,
parce que ça a des effectifs,
et nous vous donnons de la force
pour faire la décision
que vous voulez faire,
mais nous allons faire le bon travail
pour vous,
si vous vous demandez
pour une single thread
et vous avez un pipeline
synchronisé,
nous allons faire le bon travail
et on va pouvoir
faire le bon travail,
juste au côté de ce sujet.
En général,
si vous n'avez pas de solidité,
si vous avez un défi

comme sur un défi
avec des pieds,
et que vous êtes en train de faire le bon travail,
normalement,
un droit synchronisé
est plus performé
que un droit synchronisé.
Je n'en ai pas.
Oui, il y a un.
Je pense que...
parce que, en fait,
c'est tellement rapide,
en tant que le set-up,
c'est tout de même
ce qui se passe
dans le hoodie,
c'est de dire
que vous êtes en train de
faire un model de completion,
etc.
En général,
le prix de faire ça
est plus grand que la nature,
le prix du droit
était le point de vue de la discurse
du sein du sein du premier endroit.
Donc,
le fait d'avoir un droit synchronisé
a été un grand point de vue
pour DotNet,
particulièrement
un poste de NoJS,
V8, Runtime,
encore,
NoJS,
single thread,
c'est un single thread
avec Async,
qui est un model
que nous avocons.
Mais,
juste un peu cautiaire,
parce que Async signifie quelque chose,
c'est effectivement
que vous ne seriez pas
en train d'aller.
Ça signifie
que vous allez avoir
des contextes,
bien,
des offloads
sur un port de completion,
des contextes,
c'est toujours le droit de la solution
pour les yeux, c'est ce que je dis.
Donc,
oui,
c'est la seule chose
qui est un peu d'héritage
quand vous utilisez Kafka
par le writer,
c'est juste de la pensée
des choses qui peuvent
travailler sur la box
pour des messages
complètement inaudibles,
des messages targed
basés sur les messages,
ça ne fait pas le sens anymore
si vous êtes en train
de lire une séquence
des messages
en orderant de la construction de Kafka.
Oui, ça me rend le sens.
Ça me rend le sens.
Donc, je suis assez
d'affiché de temps maintenant.
Donc,
est-ce qu'il y a des bêtes
que vous n'avez pas
couvertes
que vous voulez couvertes
avant que nous voulons
mettre des tips?
Je pense que c'est bien.
Je veux dire,
que vous avez un sens,
que vous ressentez
comme un éclairateur,
que vous avez une idée
ou que vous avez des idées
ou que vous avez des idées
de la guerre,
ou que vous voulez voir
par comparaison
avec d'autres,
que vous avez une idée
de ça?
Je pense que ça.
Je pense que
l'issue que vous avez mentionnée
avant,
parce que vous n'êtes pas
un débutant
à ces concepts,
c'est difficile de savoir
pour quelqu'un
qui est un débutant,
alors que,
même si je suis YouTube
writer,
je n'ai pas un débutant
à un débutant
d'architecture
et de distribuer les systèmes,
donc je sais tous ces concepts.
Donc, c'est difficile pour moi
de mettre mes
moi-même en position
d'un personne
qui n'a jamais fait
un débutant d'architecture
avant.
Mais je pense que c'est ça.
Et aussi,
pour être honnête,
l'audience de la série
pour cet podcast
n'est pas un nouveau développeur,
c'est plus d'experience
de développeurs.
Donc, je pense que c'est bien.
Cool.
Cool.
Donc,
si on se fait des défis?
Oui.
Donc, le seul défis
que je pense que
peut-être
serait intéressant
de donner la conversation
qu'on a eu.
Si vous utilisez
Kafka,
un des...
il y a un couple de tools
pour vous aider.
Donc,
qu'est-ce que vous avez
des choses que...
Il y a un général application
pour ce genre de messager.
Ce que vous avez des messages
c'est...
comment
mon système
doit-il
déployer
sur mon machine local
ou
sur un
environnement

pour tester?
Et la réponse est
qu'il y a un préférence
que vous faites
que vous teste
des messages

et des messages

Vous ne vous contrôlez
le tout.
Vous avez un plan de plan,
c'est un contract
et vous dites
Hey, je dois être ok
si vous avez donné
des messages
ou je vous ai reçu
des messages
et des messages.
Donc,
comment vous envisagez
des messages
à la commande?
Il se termine
les normaux de tools
de la chelon
qui vous permettent
de vous générer
des messages
à la commande
ou de recevoir
des messages
à la commande.
Donc,
le casque de Kafka
est un appel KCAT.
KCAT est très utile.
Il s'agit d'essayer
de vous envoyer
des messages
à la commande.
Il peut être utile
de vous déterminer
pourquoi mon application
n'est pas en train
de travailler
ou pas.
Vous pouvez,
quand vous avez KCAT
envoyer
quelque chose
et recevoir
quelque chose
avec KCAT
et dire
ok, ça a été
un sujet
que je peux recevoir.
Ok,
maintenant je vais
faire mon service
parce que je sais
que j'ai des sujets
avec KCAT.
Est-ce que ça peut recevoir?
Ok.
Et je pense que ça va
vraiment bien avec KCAT
Exactement.
C'est un JQ
pour ceux qui ne le savent pas.
C'est un petit outil
pour basément
parier Jason,
essentiellement
un petit outil commande
et à manipuler.
Et en ce moment,
je pense que je dois juste
faire une autre source
d'autres softwares
qu'à utiliser Curl
et JQ
ou KCAT
et JQ.
Je suis sûr que je peux
mettre des applications
de cette manière.
Mais ça peut être
vraiment utile.
Donc, si vous vous réveillez
un message
pour le Y,
particulièrement avec
Jason Payload,
quelque chose comme
JQ avec KCAT
c'est fantastique.
En général,
dans l'environnement,
vous pouvez trouver
des tools de CLI
avec AWS CLI.
Vous pouvez mettre
des messages sur SNS.
Vous pouvez les lire.
Et,
d'ailleurs,
vous pouvez utiliser JQ
avec ça.
Vous pouvez mettre
des petits scripts
qui sont les équivalents
de Curl.
Si vous êtes
un API de HTTP
ou un postman
ou
quelque chose de ta couleur
de choice
pour faire des tests
de HTTP
dans des simples scripts,
c'est vraiment valable.
Donc,
ça existe un message,
un message pour vous.
Et,
d'ailleurs,
si vous avez des gens
qui ont besoin de message,
ne portez pas des
équivalents de Curl
qui vous font
ça.
C'est mon défi.
C'est très cool.
Oui, avec
le JQ,
avez-vous vu
JQPlay.org, je pense?
Oh, non,
je n'ai pas vu ça.
JQ...
Oui,
.org.
Oh,
non,
c'est pas
de rien.
Il ressemble à
ce que c'est.
Oh, c'est un pain.
Oh,
j'ai un service non-unit,
un service non-unit.
C'est pas très bon.
J'ai un JQPlay.org
de Google,
HTTPS.
Il y a un peu de temps pour aujourd'hui.
Je me demande si je peux
donner un résultat cash
pour Google.
C'est un de ces
desquels vous pouvez
passer
un JSON.
Vous avez des WebTools

C'est comme
un JQ.
Vous pouvez tester
différents Queries
de JQ.
Et il y a un documentateur,
et
il y a un cheat-cheat
à la fin.
C'est pas mal.

mais c'est un chien
qui se démarre.
Oui, je peux voir
qu'il y a un site de Github
qui est là,
mais il y a un peu de temps.
Je pense que
peut-être que
quelqu'un
se démarre.
Ah, peut-être.
Si c'est pas
demain,
je vais vous le faire
pour les organisateurs.
Ah, c'est un chien.
Donc,
mon dev-tip
est
complètement
inédit
pour ce sujet.
Mais je pense que
je ne veux pas
faire de dev-tips
parce que je dois
penser à un pour chaque épisode.
Mais
je ne sais pas, je suis sûr
que tous les listeners
ont entendu de la GBT
et ont joué avec ça.
Et c'est un peu
très...
C'est peut-être
un peu de choses sur la GBT
et pensent
« Oh, c'est génial,
comment ça a été fait
et puis on a oublié. »
Et mon dev-tip
est juste
ne pas oublier
et utiliser ça
comme un tour.
Et souvent,
je trouve que
il y a des choses
qui sont mauvais,
mais si vous savez
assez
qu'est-ce que vous vous demandez,
que vous pouvez vraiment
utiliser comme un tour
pour vous commencer.
Et donc,
c'est vraiment
une génération de théâtre
juste d'avoir un conversation
avec elle.
Elle se fait
faire un peu de biais
et je ne sais pas,
je vais juste
utiliser ça
plus et plus
pour des choses différentes.
Et j'ai eu un périphère
où j'ai déjà essayé
et je me suis dit
« Wow ! »
et puis je l'ai oublié
comme je l'ai dit
et puis
j'ai pas essayé
et maintenant je me suis dit
« Pourquoi ne pas
juste utiliser le tour
comme on utilise
les autres tournards ? »

je l'aime,
je l'aime
tous ces
modèles de langue
comme
ChatGPT
et
CodePilot.
Et une de mes recommandations
en regardant le tour TDD
c'est
si vous faites
une
ou un classique
TDD, comme je vous le disais,
et si vous faites
une réglage de gris
un des idées est
que
quand vous allez
de la grise à la grise
vous ne faites pas
de la qualité de qualité

vous faites
de la solvérisation
de la problématique
qui se trouve en front
de vous.
Donc
vous êtes explicitement
rejoins
pour être sincère,
vous n'aurez pas de code
de stack overflow
et ce genre de choses
parce que vos tests
sont là
pour vous dire
quand vous avez
quelque chose qui passe
et le refacteur
est pour faire
ça en code clean.
Donc une des choses
que j'ai tendance
à recommandé c'est
que
utilisez des tournards
comme
CoPilot
ou ChatGPT
et que c'est le stage gris
vous avez un comportement
vous avez un test
qui vous dit si c'est correct
le comportement
si c'est bien expéré
c'est quelque chose
que vous vous mettez
dans le ChatGPT
pour dire que c'est bon
pour faire des codes
pour passer ça,
ça vous donnera quelque chose
et puis
parce que vous avez un test
autour de ça
vous pouvez ensuite refactor
si vous avez la solution de passage
et vous dites
que ça n'est pas le cas
et que ça a un peu
bizarre et funky
alors vous pouvez refactor
votre comportement
parce que ce que vous voulez
c'est le hint
sur
quel est le régime
qui passe ce problème
et puis
si vous pouvez
tout le temps
protéger par le test
le autre chose
c'est que les tests
vous disent que
le ChatGPT est le plus bon
ou est-ce que c'est
une solution
de la solution de la solution
de mon problème
donc je pense que c'est
idéal
dans le red-to-green
et vous pouvez me sentir
plus confortable
d'utiliser ça
parce que c'est à l'heure
que nous serons
de la base
de la code de stack
de overflow
c'est le grand secret
d'un grand secret
de tous les ingénieurs
des softwares
c'est que
nous avons Google
l'answer
donc le ChatGPT
est juste que
Google l'answer
était un peu plus
plus fort
pour se dévier
mais
TDD vous protège
basiquement
dans ce cas
je suis curieux
et je n'ai pas essayé
ceci
mais je suis beaucoup
de ChatGPT
et
j'ai honte
que je n'ai pas essayé
ceci
je suis juste
curieux
c'est bien
c'est bien
c'est bien
c'est bien
c'est bien
commande-handler
c'est bien
c'est bien
c'est bien
c'est bien
c'est bien

d segundo lemon
c'est bien
d segment
c'est bien
c'est bien
c'est bien









Ritten by Ian Cooper.
Oh, something went wrong trying to reload the conversation.
Ah, that's not...
If you say .NET, I mean, you can also use Paramore.
So it's named after the song by Param, P-A-R-A-M-O-R-E,
Paramore Brighter, that will give it a slight guess
then you get a package that might help it.
I'll refresh the page because it...
Oh, it says, it said, no, I meant the Brighter written by Ian Cooper
and it says, oh, my apologies for the confusion.
Here's an example of a Brighter command handler
that writes hello world to the console.
Oh, my... Right, that is... It's done it.
Wow, cool.
I'll put a screenshot in the show notes,
but it's written in C-sharp.
It's using the do-get package.
And it's explaining it.
So it's written the code sample and it's explaining it to me.
Awesome.
Oh, it's saying how...
Oh, now it's telling me how to actually
send a message using the command processor.
Wow.
Awesome.
Oh, that's insane, isn't it?
And honestly, I didn't try that before.
It was kind of...
I just...
But I've been trying for this kind of thing, but not for Brighter.
To be honest with you, we should probably use it
to help us write some of our documentation
because probably it's doing a better job
at writing the docs than we are.
I haven't really thought about that before,
but I do wonder if that's a sweet spot for open source projects.
Please write documentation for my project.
I don't have to try it later.
I've got a new chat.
Write some document.
So, it worked out in Cooper, so I'm going to use that term.
Write some documentation on in Cooper's writer library.
Right, it's doing it.
It's off and it's writing a whole bunch of stuff
talking about CQRS
and command dispatcher patterns and...
Oh, my goodness, me.
C'est ridicule.
Mais mon travail est terminé, je pense.
Il faut me faire un email, je peux
mettre des bits sur ça pour
m'améliorer nos doigts.
Oh mon Dieu.
Il y a un nouveau hot tip pour les D.B.
Je dois poster les bouts pour les gens
de savoir que quand vous avez terminé votre
feature, il ne faut pas vous aider à
faire une question de chat d'EPT.
C'est bien, je suis content que vous puissiez
poser des questions d'EPT à Brighter.
C'est bien, c'est bien de savoir que
nous avons fait une question d'EPT
à Brighter.
Je me demande, c'est
maintenant, et ça
me semble que ce type de
AI est tout de suite
détenu.
Qu'est-ce qui va bientôt ?
Je vous dis que
ma analyse est comme ça.
Une fois de temps, pour
utiliser un database,
D.B. a beaucoup de
structures de data,
algoritmes, etc.
À un moment, il y a un sequel
et des stores de data relation
qui sont assez reliant.
Ça a été le cas dans mon career de développement.
Et ça a été très facile de
utiliser des databases et de query
et la explosion de database a été
élevé.
Et ça n'a pas été pour nous,
mais pour nous, c'est juste un changement
de façon dont nous travaillons
sur une abstraction de haut niveau.
Je me demande
si, à la fin de la révolution
où il y a un niveau de
abstraction de haut niveau, on
commence à travailler.
Il y a un très intéressant point,
qui est presque l'idée de
des wars de langue.
Si quelqu'un dit que vous pouvez
écrire ce truc en type script
et vous dites
que vous savez que c'est un C sharp,
mais ils sont assez proches,
donc je vais juste écrire c sharp
pour que vous puissiez
écrire le programme, et ça va.
C'est vraiment un programme de langue
que vous utilisez,
je vais juste dire un A.I. tool.
Convertir à la forme, s'il vous plaît.
Je pense aussi que nous parlons de ce
point de vue de développement, mais
avec des autres, des chiffres de technologie,
des choses comme le smartphone,
et tout ça, tout a changé.
Toutes les choses, tout le monde a un smartphone
que, dans 5, 10 ans,
tout le monde, pas seulement les techniques,
mais les gens de la technologie,
ils vont juste communiquer avec l'A.I.
et ne pas même penser à ça.
Je pense que tout le monde
utilise ça comme un assistant.
Une autre analyse que vous pouvez penser
est le processus.
Quand j'étais à l'université,
il y avait beaucoup de années,
tu as écrit des essays par main,
je faisais mon programme de compétition
avec la université,
je suis le premier en anglais,
je suis le maître de la université.
Même après, tu as écrit des programmes de compétition
avec un biais et un pen,
un papier en examen.
Mais quand tu as une essaye,
tu as des problèmes, tu fais peut-être
un premier drap, tu le parles
et tu changes le drap.
Mais le drap, c'était un exercice
hélio, parce que tu n'avais pas le temps
de dire, je veux que je mette ce paragraph,
et ça m'a fait plus de sens
que je faisais ça et ça.
Quand la technologie de processus
s'est allée, tout de suite
nous avons la capacité
de faire des documents
plus vachement
parce que nous pouvions
faire des choses,
procéder, d'improuver
les choses,
ce n'était pas un truc
qui nous a tous remis
qu'on a tous répliqué
tous ces jobs.
Les tippings-poules ont
fait des choses,
on ne pense pas que ça,
on ne pense pas qu'on utilise
le processus en parole
pour nous aider à faire des choses.
Mon goutte est que
ce serait un des revolutions
dans les 5, 10 ans
on va tous travailler
un peu différemment, mais on va
regarder comme plus efficace
en même manière que nous regardons
les processus en parole,
c'est plus facile.
Et quand on va être en école,
on va se faire des choses,
on va voir que les gens
ont des yeux,
on va faire des choses,
je ne suis pas panique
je pense que
on va juste remettre
des drogeries,
on va faire des choses
plus rapides,
mon exemple classique
serait que
je veux basément apporter un file
pour un S3 Bucket en AWS.
Je ne fais pas assez de ça
pour que je ne regarde pas tout seul
le temps. Je vais lire les drogeries
et faire des choses.
Et ce processus,
ce n'est pas comme que je déploie
des expertises, je vais juste lire les drogeries
figurez comment apporter les drogeries
dans ma situation, si le GPD
peut faire ça pour moi, je n'ai pas vraiment
perdu tout ce qu'il y a là, c'est juste
lire les drogeries pour moi et dire
que c'est le code que vous avez besoin
pour faire ça et je suis comme, bon.
Et j'espère que si nous commençons
à serrer les doors et tout ça, et que
nous ne nous paniquons pas,
nous allons tous faire ce que nous voulons
faire, qui est
faire un peu plus attention
sur les problèmes de modèles domaines
que notre cliente a.
Pour aller au plus grand,
je veux vous dire que je veux vous
dire le commandement de la réquest,
je ne veux pas que vous devez
vous faire des messages,
ou en même manière que nous
n'avons pas de compétitions, je vais juste
faire des messages, des messages, des messages, des
questions, tout ça,
nous n'avons pas de compétitions,
nous ne faisons pas de compétitions, nous
fichons sur le code que nous avons
fait pour les problèmes de cliente, et je pense que
c'est là où nous allons les faire.
Oui, je pense que les développeurs
qui sont en train de changer
sont pas mal, mais
les développeurs qui sont
en train de apprendre de la nouvelle
et de changer de la manière dont ils
les déclencher et de prendre des avantages
pour les cinq ans, nos problèmes vont changer
dramatiquement, mais
nous allons les avoir.
Oui, je pense que je veux dire que
les types sont les plus importants de la
activité en programme, c'est
de construire
des modèles de choses, et
automater ces modèles,
et nous avons eu un long
période où nous avons
juste été unnotés par nous,
si vous comparez
l'idée que nous avons aujourd'hui
pour un pricent relativement bas
avec le fait que nous avons
pu faire le right stuff et de
débugger, etc.
Il y a des improvements de productivité
pour tous les uns, nous ne nous
regardons pas de la suite,
on a eu des débuggers,
nous avons juste bougé avec les temps
pour faire des choses dans un nouvel
et je pense que
comme je l'ai dit
les plus dévus sont incroyables,
ils se sentent que ils se sont
encore débugés, ils se sont
désormais motivés pour
automater les choses de la boite
et tout de suite, je suis sûr que ça va bien.
C'est intéressant, je
utilise copilot et
nous avons écrit un nouveau feature
pour le transfert de la encryption,
c'est pas encore, je le vois à un moment,
mais je l'ai écrit pour le test
et ils ont essayé de faire
les improvements, et copilot
m'a dit que je vais essayer de faire
les improvements, c'est
que c'est juste de la skeleton
de ce que ça pourrait être
et je n'ai pas
réveillé les codes et les choses
que j'ai évoquées,
et je me suis dit que c'est pas mal,
c'est pas mal, c'est pas exactement ce que je veux
écrire, mais selon ce que je voulais
faire contextuellement,
c'est une possibilité
de faire des incrptions
et tout,
c'est pas un bad staff
et si je suis vraiment
bouché pour commencer,
ça serait un point de start
de la construction,
je pense que ça ne va pas être le point de refroidissement,
juste de la faire comme un ami de programme de paire
c'est un autre outil que vous pouvez
prendre un bon travail pour être plus efficace
je l'aime, surtout avec le chat
le style de chac GBT
où vous pouvez avoir des conversations
et ça fait contexte, comme vous le dis,
vous avez des programmes de paire
et des conversations avec ça
je suis très sûr que c'est
le plus long de l'épisode,
donc, je vais en mélanger




on a un chac GBT
pouvez-vous faire de cette flipped?
ou surрист орals
차 distance
c'est bien
mais on devrait en mélanger
c'est le plus meiner
place for listeners to reach out to you.
Oh, that is a good question nowadays.
Because I would have just said you can grab me at likecooper on Twitter.
And I do keep on Twitter.
I'm also likecooper on hackyderm.lyo, which is a master on server.
I tend to be more active on master on.
I check Twitter and I, you know, if you're talking to me and I will occasionally scroll
through the feeds of people that's gone on Twitter, but I tend to post more on
hackyderm, the master on server nowadays.
It's funny, I just, the previous episode recorded this morning, and the guest was
saying exactly the same thing, just at the end, when we're talking about contact details,
he's not really using Twitter anymore, and he's now using master.
Don, and I kind of, I'm kind of using both, but I'm still more Twitter, probably,
but it feels like everyone's moving over, especially in our space.
I think that some communities, so tech, another one, I mean, in table
front role-playing games, there's definitely large numbers of people that
were moved.
I think some people that haven't moved, they're either, they don't, it doesn't
make any difference to them because they're not active, and therefore, they're
as passive consumers, they just want to feed.
Or some folks that have real investments in their profile on, say, Twitter,
big audience, and they won't get that same audience immediately over on, say,
master on, and they've got to figure out, did that.
And master on's different because you don't have a feed that essentially a
master don curates, so it won't promote things.
You don't get that thing where, hey, this tweet, everyone's looking at it and
talking about engaging it, or stick it in your feed because it's on the topics
you like and stuff, so you can't get that kind of organic stuff.
You either have to be a hashtag, or effectively, somebody has to boost
you to people other people know.
For some of us, that's one of the attractive things about master don, right?
You don't see some of those, you'll never guess what happened next, kind of
clickbait, threads, to try and push engagement.
It's much harder to do those and there's no algorithm to promote you, which
is like early Twitter before the algorithm crept in, which is why people talk
about master as being early Twitter.
What they mean is it's before the algorithm began to dominate everything.
But at the same time, that also means if what you want to do is reach new
audiences and that kind of thing, you maybe, Twitter has a huge advantage
because the algorithm helps you.
So part of my guess is that they don't, they're not necessarily mutually exclusive.
That master don is where you go for a conversation and Twitter becomes more
where you go for broadcast.
Yeah, maybe.
One thing I like about, and I said this in the last episode, to David,
David Wenji was on the last episode.
And one of the things I really like about master don is that you can follow
hashtags like it was a user.
Hmm.
Yeah.
And so I'm finding that when I'm posting on master don, I'm now using a lot,
like really thinking about the hashtags I'm using, cause I know people are
following those hashtags.
Yeah.
And I found really useful is, I said, I didn't really realize until a
month, but it's told me on the advanced web interface, you can effectively,
a bit like tweet day, create columns that basically follow given hashtags.
So I've got a column for dotnet, a like, calling that permanently follows
the dotnet hashtag.
And that's really great cause I should see a lot of dotnet people and dotnet
stuff that on Twitter, I might have been frightened to try and, you know,
follow that kind of like a number of people, but it's great.
Just a hashtag, I follow them.
You know, if you're posting on dotnet tend to see your stuff, right?
Yeah, it's a good tip that advanced things.
It's like, it's not obvious when you first go to it, but yeah, it's just a
checkbox and suddenly you get like a tweet that kind of much nicer interface.
Yeah.
I don't know why it's a hidden secret.
I guess they feel it's intimidating for average users, but it feels like
something they should surface more or that, you know, click this button and
you'll get a multi-column interface and you can follow hashtags really easily.
Yeah, definitely.
Right.
So I'm probably should wrap up.
We're given the time.
But yeah, thank you so, so much for joining us.
It's been amazing having you on.
Hey, but I'd love you to see you again, Dan.
Yeah, you too.
You too.
It's been a while.
Yeah.
See you soon.