How'd you like to listen to dot net rocks with no ads? Easy?
Become a patron For just five dollars a month you get access to a private
RSS feed where all the shows have no ads. Twenty dollars a month will
get you that and a special dot net Rocks patron mug. Sign up now
at Patreon dot dot net rocks dot com. Hey Carlin Richard. Here.
As you may have heard, NDC is back offering their incredible in person conferences
around the world, and we'd like to tell you about them. NDC Oslow
will be made twenty first through the twenty fifth. Go to NDC Oslo dot
com to register. NDC Copenhagen is happening August twenty seventh through the thirty first.
The early bird discount for NDC Copenhagen ends June second. Go to NDC
Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the
twentieth. The early bird discount for dc Porto ends July twenty first. Go
to EDDC Porto dot calm to register and check out the full lineup of conferences
at NDC Conferences dot com. Hey, guess what it's Dot and Net Rocks.
I'm Carl Franklin and I'm Richard Campbell. And this is the beginning of
a long run over a few days of show recordings that we have to get
in the can because we're gonna be busy, we're gonna be traveling again,
and so it's good too. I sort of organize it. I think I
said to you in between recordings last week, because we're just doing like a
show or here, or they're just staying a week or so ahead. It's
like, I'm gonna load up a bit. We'll see what happens here.
I've got a few emails going out, and then in fairly short order I
kind of said, hey, sorry, this is a lot of shows.
But yeah, it's also fun. Yeah, sure is, you know,
to just sort of focus and have intense conversations about great technology. So I'm
really looking forward to this flurry. And then we'll be doing some on stage
and live shows and in person shows coming into spring conferences. That's right,
Techarama for one yep around, we'll be one of them. Yeah, And
when is dev Intersection again? The next dev Intersection is the first week of
December in Orlando, Ah that's gonna be fun. So we're going back to
Orlando. We're in the Swan and the registration's opening up shortly. Still working
on some curriculum and stuff, but you know, we got some time.
I got some crazy keynotes because you know, you think about how much has
happened since chat GPT in November. Oh, I know, yeah, crazy,
and here we are in April. Now, think about what it's going
to be like by the end of the year. It's gonna be insane.
I mean, it already is insane. I don't know, it could go
either way. This is quite the hype cycle. Yeah, well, let's
get things started with a little thing we call a better note a framework.
Awesome, all right, man, what do you got? Speaking of chat
GPT and all that great stuff and hype cycle and the hype cycle and the
hype never ends. Everybody's jumping on the hype bandwagon. Here Google announces AI
features in Gmail docs and more to rival Microsoft. This is an article in
The Verge March thirtieth. Google will soon offer ways to generate text and images
using machine learning and its workspace products, as part of a scramble to catch
up with rivals in the new AI race, right, Yeah, this is
the logical hit back, right of course, because Microsoft goes after search with
being AI, so Google goes after office with features in Google Docs, yeah,
sheets, etc. That's one of the few places that Google can really
scare Mike or soft right. Yeah. Yeah, one would argue everything to
happen in office. Three sixty five, now, m three sixty five was
about competing with Google's docs online Google Docs. Yeah, yeah, I use
it all the time. Yeah, just because it's easy. Well, I
think about the number of times you and I have been writing simultaneously in a
Google Doc for like an ad script or any sorts of things. And I
even use that feature in our admin app. Yeah. Yeah, that same
affect good old signal arm. Man. The thing that's the thing it interests
me is is this, like Bard, is this a forever beta a Gmail?
What's beta? Forever? Wasn't it? Yeah? For sixty years?
Seven years? Like six years? Yeah? You crazy? I get that,
they're responding. It's the question is when are you going to release it?
Because I'm in Canada. You can't use Bard in Canada. It's not
can't even take it out for his bit. I gotta tell you, I
was talking to one of my customers just a few days ago, and he
said, uh, boy, tell you what, man, chat CHPT is
just saving my butt, saving so much time, you know for little syntactical
things like how do I do this? How do I do that? Yeah,
it's pretty good. Just make sure you test it thoroughly. It's actually
correct. And the question is is that special chat GPT or if he'd bought
grammarily, would he have gotten the same thing. Oh, I don't think
grammarly can do link queries, but certainly chat gpt ken. Yeah, that's
true if he's writing code versus writing copy. Yeah, yeah, code.
It's really great for code. Yeah, you just got to make sure that
you know it's good. Is it big? Is it better than get hub
copie? Yeah? I don't know. That's a man, what a great
comparison to do. Yeah, we ought to do that. There's so many
believe me, and I don't want to make this the all large language model
show. No, no, no, no, this is just the intro.
Here. There's lots of there's lots of talk about Brown. He's coming
right up here. But before we bring him on, who's talking to us?
Richard grabbed a Comma Top of Show seventeen ninety. That's the one we
did with Chris Kluge when we were talking about his experiences doing experiments with different
infrastructure as code Solutions, Terraform and BICEP and Pullumi, and of course that
had that ended up in a conversation about the DevOps cycle as whole automating of
builds and so on, which is really you know, part and parcel with
trying to make your software better and Devil Goel had this great comment from last
year. He said, my hot take on DevOps is that too many practitioners
start off with rigid, preconceived notions of what they want to do. This
is normal. Our decision making is always going to be shaped by our scars.
We've used that line before. Oh yeah, old favorite. Yeah.
However, it helps to approach devots technology, like any technology, with an
open mind, start by looking at whether or not the out of box functionality
is sufficient and if not, why, Yeah. You know, we always
tend to want to mold the tools to our vision of what it's going to
be, rather than just use what's there. And here's a line that I
loved, are the scars running the show? Wow, there's always going to
be some amount of custom work that needs to be done, But our first
step is always start figuring out how to get the pipeline to run a custom
Bash or PowerShell script. You're probably doing something wrong. You aren't that special.
If the canned features can get you most I done all the way there,
you should start with those. They almost always are going to provide decent
air handling, logging, and parameter checking, especially if their first party offerings.
Keep in mind that there are going to be differences between green Field and
Lift and Shift that might require some extra work. I like to think this
way in any cloud project. If step one's great an Azure VM and install
a sequel server, you're probably doing it wrong. Devon's gotten gotten. I
checked back and saw we've exchanged a few emails before. He's received music code
By before. But Devin's such a great comment man, so thanks so much
for commenting. If you'd like a copy of Music go By, I write
a comment on the website at dot at Rocks dot com or on the facebooks.
We publish every show there, and if we comment there and I read
it on the show, we'll send you a copy Music go By. And
you know you can follow us on Twitter, but we'd really like you to
follow us on Mastodon. I'm at Carl Franklin at tech Hub dot social,
and I'm Rich Campbell at mastodon dont social and send us a two we'd like
to see there. My tutors are growing. Let me say that. Can
you say that you need to bleep that? No, I don't think so.
Tutors man, your tutors, my minions of tutors, well, you
know that they're just followers like two thing else. I started this just at
a couple of months ago maybe and got about twelve hundred followers now, so
that's really good. And I always follow whoever follows me. That's just the
way it goes. Well, anyway, let's bring on Rony Roni Dover is
a holistic developer and builder with a passion for development processes and practices. Afflicted
by an acute product manager slash developer split personality disorder that was never treated.
There a cream for that. I don't think there is. I don't think
so. You got to go into the office. Currently CTO and co founder
of Digma Digma dot ai, an ide plug in for code runtime AI analysis
to help accelerate development in complex codebases. A big believer in evidence based development
and proponent of continuous feedback in all aspects of software engineering. Welcome Ronie.
Hello, Hello, great to be here. When I hear continuous feedback,
you know, that's one of the features of being in a state of flow,
isn't it. Yeah. We heard about this great book Flow by Mehi
Chicks and me Hi from Mark Sieman many years ago, and you know they
talked about people fileting fish, you know, all day long at the market
a Pike's Market. You know, the guys who are just like fileting salmon
and they're just in the zone. But that state of flow gives you this
continuous feedback and that really allows you to go fast. Yeah, and maybe
before I dived right into it, I just want to touch on your previous
discussion about AI and AI systems. Oh sure, Yeah. I was just
having a casual conversation with a friend and we were trying to estimate just how
much code exists today in production systems. That was written by AI and maybe
nobody even took a look at it, like no no human intervention. And
you know, you could say the same about tack overflow. Or you know,
they said back then, coppy taste that type of development. But the
more abstract the AI. And I'm a big proponent of AI, and I'm
using it a lot myself, But the more you kind of abstract the request
from the AI and kind of remove yourself from the generated code, it becomes
less about snippets or regular expressions or linqueries and you can actually, you know,
request entire business logic being implemented. That's right, and and that's amazing
to me, and to me it's also very poignant and relevant to the to
the topic of feedback, because essentially, you have a bit of code here,
and it doesn't matter if somebody else wrote it, or I wrote it
a year ago, or maybe I'm just kind of trying to make my to
make kind of this opaque piece of code a little more transparent to me,
and it seemed like without that type of visibility, we kind of have a
problem on our hand. And it's the kind of problem that you don't notice
until you do. And we were kind of chatting before, and you guys
said that over twenty years year on the air, which is amazing. And
I've been a developer for more than twenty years and when I got started,
at least in the culture of the organizations that I worked around, there was
no continuous testing. And I remember it very well, and it was you
know, that's what that's what we knew. There was some testing that you
had, out of the kindness of your hearts to run every now and then,
but that was just about it. Hopefully you had testers or some sort
of QA in your organization, yeah, or QA department. Yeah, But
essentially, but that's not continuous, right, They're still taking a bite and
you're right, like it it comes down to how how do you describe continuous
Like I would argue that intellisenses continuous for sure, for sure. So so
essentially I was we were kind of running blind like today for me, like
pushing changes without running tests. As you know, you must be a very
brave and I don't know, desperate soul to actually do something like that,
but you know that it's it's crazy, or so it seems today. And
at the same time, once kind of you you start understanding that feedback is
really essential. Coding without feedback, I kind of feel the same type of
blindness that I felt when there was no kind of infrastructure of tests to support
me. So what do you mean when you say feedback, Like what are
you looking for there? So essentially, today we're pushing code, we're running
code, and that code, especially with recent kind of leaps and observability technology,
has a lot to say about how it's functioning and how it's running.
There is a lot of data. Bit the question is are we looking at
that data? And when are we looking at at data? So let's say
I just got um. I pushed an upgrade to the doll system, like
I A to the doll or that access. I added that some caching and
some other features around it. I was shocked how many developers, when given
such a feature to develop, would go ahead, developed a feature, maybe
run a few times, deploy, and let's move on to the next feature,
without, for example, examining they did it make life better for everyone?
Did it improved the state of the system? And there are many reasons
for that, And you know, I just give one example, but you
know I could look at numerous cases. And this is something I noticed while
working alongside was very commented developer. And they were given a feature, they
developed it, they wrote the test, they did everything. Today you know,
they even wrote the helm file or the terror form to deploy it.
They pushed that merge to master button and then they they moved on to the
next feature. And I asked them, you know, is your code even
getting executed in production? Can you tell me even that maybe you made uh
you know, maybe there's one bad IF statement preventing your code from ever being
run. I mean presumably they you know you even described it this way.
They ran it themselves. Right, You write some code, you run it,
like there's your feedback, the compiler compiled it, and it showed up
on the screen or showed up, you know in some way. But I
think about point of now you push it out, you know, put it
into the pipeline, it goes out of the production. When is the next
time it actually those lines of code get executed exactly exactly? And uh,
this is something that's uh that's been bugging me. Um. And you know
you're right that there is some information that you get out of let's say your
debt system, and maybe some feedback you get back from the test, which
is mostly kind of limited because it's not qualitative. It's more true false as
failed kind of thing. But when it comes to more non functional feedback and
more kind of feedback that has to do with the quality of the code and
the impact of your changes. There's very little of that, both from CRI
and production and even in Devon. I'll tell you another story. I caught
a developer in my team adding a console log statement to a background service.
And I noticed it because I'm looking at my code and I'm saying it was
just printing the amount of time that that kind of loop iteration took. And
you were you were, you were running your code. You have to call
his code and now you're seeing stuff show but your console exactly. Now,
First of all, I would like to command that developer because a lot of
developers would not do that right, they would not even check for that.
It shows that he had the kind of insight to say, this is important
to notice as I'm making changes, did this kind of U the discycle increased
dramatically in terms of performance? Why because maybe I made a mistake. It's
the wrong technology to do it. Yeah, like he probably a console log
would kind of you know, he probably not noticed it forever and it doesn't
become a part of it. Have methodology beyond just that one time that that
that he added, the console log is the er debug tool for JavaScript,
isn't it exactly? But at the same time, I completely sympathize with the
sentiment, and I want, without thinking about adding a console long, for
that information to be very as we said before, continuous and proactive, so
that I don't need to think about it immediately. Because my code is running
and because I made some changes, and because things are now worse or even
better, like I'm I like to get positive feedback as well, that feedback
will start streaming to me as a developer, and that becomes kind of my
eyes and ears about how my code is running and whether it's running, and
again, what is the impact of my change it Because so it's part of
what you're saying there reminded me of this is stuff we catching code review that
if you're pair programming, or if you do a code review like I don't
know if any other way that really assesses code quality other than other pairs of
eyes on it saying you know, there's a more reliable way to write this.
You know that that kind of mentality of just like making higher quality code
because the law of volvers are still very much in the place of hey,
you know what it runs like, that's good enough. There's no concern about
quality. The main quality is it functions exactly. So did this issue UM
ultimately leads you to Digma? And yes, yes, exactly. And and
did you look for other tools out there? You said, there isn't anything
out there that does it. But what does DIGMA do that's so different from
you know, other telemetry products, let's say so, Actually, the origin
story is is that I was looking at the DevOps loop, a diagram that
by now become you know, completely overused michiels look whatever, you've foreign it,
but it's still kind of a good model of the profit UM. And
I was noticing in that particular diagram I was looking at it, it had
like at different tools associated was each that was kind of like an equosystem long
break now, but you saw the build tools of diploy tool, of continous
integration tools, and there was a actually an arrow leading in the other direction.
There was an arrow leading from production back into death and it said continuous
feedback. That's what that's what their name said. Yes, and they went
out tools associated with that particular error, and that kind of blew me off
because I was looking at this Stagram, and there's so many CI tools,
so many build and deployed tool, so many monitoring tools. All of these
exists. How come when you looked at continuous feedback, what was supposed to
bring the information back to the developer. Now we could talk in terms of
was that feedback supposed to go back to the developers? That feedback supposed to
go back to the to the pms, as this health features were used,
here are the but the errors that we're seeing and then it gets fed into
the sprint pipeline as remediations and people aren't using as the way we thought.
You know that kind of thing like there is tools and the ear right,
but I think that we need to separate the types of feedback. And as
I was saying before, and you actually mentioned it in the most accurate intro
that was ever a clearly written about me that I have a split personality between
being a product manager and a coder. And at putting on my product manager
had for a second, there are graduals as a product manager to understand what
my users have gen So from a product perspective, I have, you know,
the analytics, the tools that gave me feedback about how the product is
doing. From a developer perspective, there is no Google Analytics for developers.
I don't know which parts of my code are being used and how, and
I don't understand that this specific area of the code is a major a nexus
bubbleneck area that is being used by multiple flows in the system that the routing
so much traffic, and I need to think about concurrency here. It kind
of becomes trivling knowledge. So, if anything, I think there is a
big gap between that kind of of elegance and richness of the ecosystem available to
product managers and the technical feedback that I want to receive, both as requirements
as and as kind of or feedback back on my work that's available from a
technical perspective to the perth. So ray gun doesn't do that. For example,
I'm just thinking off the top of my head, you can't tell raygun
to analyze bottlenecks and report back to me timings and things like that. Sure,
there are a lot of technologies, but what I found out when I
to developers is that montyas feedback is not something they past meaning when you talk
to most developers. Although there are many dashboards and many kind of nice ways
to visualize the data and you know, and to be frank, this caught
me so off guard as a developer that I spent half a year just research
this. And by researching, I de meant talking to as many people as
I could, and you know, trying to get to the rook of the
problem. And I found out two very simple things. First of all,
developers are busy, mostly over work, and they don't go looking for trouble.
This is why developers did right out of the kindness of their heart,
unless it became continuous and it became something that had to happen. And in
the same way, developers won't go looking for trouble in the dashboard if it
means another kind of headache that they need to fix. Right, you work
your burn down chart, and if you've got somebody in forcing code coverage,
then you do enough code coverage to keep you out of trouble. That that
is such a true statement there. Developers don't go looking for trouble. So
talk about security like, we don't like security. That's just telling me what
I can't do. We don't like somebody telling us, oh, this code
could be improved if you just did this and that you're like, yeah,
yeah, get around to that. Shut up, you know, get a
little fragile ego. Well, mostly because I benefit from shipping features. Yeah
right, right, But but you know we've said this before on the show
many times, Richard, if you want to be a good developer, lose
your ego, right, because it's all about having the best code and having
tools that point out you know, this could be better. It's actually making
you a better programmer and making your products better for sure. So yeah,
truer words were never spoken. Developers don't like to go looking for trouble being.
And by the way, I completely shared that sentiment, you know when
when when when I stopped talking on podcasts and I start coding. Uh,
it's it's the same thing, you know, I feel and what I like
moving forward to the next new feature. Uh, you know, I like,
um kind of a feeling progress. And and if I get sucked into
these issues and it just slowed me down, and I'm right consciously motivated to
kind of not necessarily invest in these areas. And this is a problem,
and it also requires cognitive effort. And this is the other thing that I
know this so you get to some of these realizations like, you know what,
as of my last commit, this and this change, this timeout error
rate is different than it was before, and this API that I'm using or
whatnot? Right, I need to have some cognitive effort and tools and expertise
that not all the developers have. And as a result, you know,
my statistics one on one is pretty kind of not as up to date,
and many developers kind of well try to ignore it because it's not in their
conflicts, I mean, not something that they know and practice every day.
And that makes a lot of sense to That's why we have tools. You
talk about cognitive effort, it's when you have that feed, that typical debop
feed backside. All that lands back on the pms and the feature designers,
the business analysts and so forth. The way it trickles back to the developer
is, yeah, the apps too slow, Like that's some cognitive effort like
to try and address that problem, say, okay, well where is it
too slow? How is it too slow? Like to just decompose these sorts
of broad statements into actionable code. That's a lot of effort. You can
spend a long time trying to break that down enough to go. This is
the piece of code we need to optimize. You're absolutely right, and time
is key here because it takes a long cyc of those context of what you
were doing your contact switching. You need to there is this issue, but
now it goes back need more information and then develops guys way in and then
the IT guy's way in and you go back to the customer and eventually kind
of it becomes a very inefficient process. So how does digma address this issue?
Yeah, so the premise of Digma was very simple. It was all
of the information is there. The problem is making it proactive and reducing the
cognitive effort and making it something that's continuous that fits into my DARE workflow.
And if we can use AI to generate code, there is no way we
can't use AI to evaluate the code at frontime. And essentially what Tigma is
is a way to is a platform that evaluate the code in WRON time and
kind of like a linterm maybe but not for static analysis or dynamic analysis.
And it can give you that indication straight away in depth than in test and
in production about specific issues that you should notice in your code, specific parameters
that you need to know in order to better design it and and and the
concept is that we didn't invent the profiler. We didn't you know, have
to add some weird reflection into the code to make it happen. We just
used the existing technologies. And actually dot net made it amazingly easy by incorporating
hotel into the standard library. As far as System Diagnostic, which you know,
to me as as a dotnet developer, was was great. It was
great news because it just made it I'm a lot easier to support it within
doctor. So what's built in the dot net that makes your life easier?
So as of dot Net, I think it's four point six to eight.
They back that they added it backwards or something like that. Un System Diagnostics
now supports open telemetry right open telemetry for those who are not familiar with it
is a great step forward with observability. And the reason is not that it's
doing anything groundbreaking, but that everybody agrees on it and it's open source.
So the combination of these two, you know, it's understated here, but
it really becomes a game changer in terms of observability because suddenly, a you
can rely on an open standard, then you don't need to kind of support
one APM or another APM and their proprietary kind of finicking abstraction. But you
have this open source, by the way, very staggeringly popular across different platforms
and languages javan js, dot net. You can be a polyglot developer and
kind of benefit from it across your distributed micro services and multiple languages. And
it's open and very easy to kind of create an ecosystem around it. And
because it's so widely agreed upon, support started kind of becoming standard for any
library platform. So aspeed, dot neet, NBC NAT supports it. You
don't need to do anything, you just need to turn it on. It's
an on switch. If you're using any inframwork, it supports it. If
you're using an adapter for posters, it probably supports it. If you're using
mass transit to work with a rabbit and queue or something like that, it
supports it. So that means that taking a project from having zero visibility about
what it does in terms of traces, metrics and logs to having almost too
much data is a matter of flipping a switch rather than kind of, oh,
let's kind of think about it, create a producag the philosophies for like
two months about what we want to capture, then implement the let the infrastructure
team work on some infrastructure for that. No, it's it's already kind of
out of the bat, and that's a big game changer that makes technologies like
what we're doing with stigmas very easy because now we have the data very easy
for the user to turn it on, and then it's just a matter of
how do we process it and make it relevant. And to make it relevant,
we understood that our front end needs to be not a nice dashboard,
but the developers tooling, which is the ide the get tops process, this
is where he'll need that information. And so it becomes this kind of a
living documentation and something that kind of becomes embedded within the code in so that
I kind of take even that cognitive effort of taking opening another tab in my
browser and and looking up a dashboard just because I thought I should check instead,
it becomes something that just like a lintern, becomes embedded in my it.
Well, now that you've completely piqued her and just we're going to pause
for this very important message or too, we'll be right back and we're back
for talking Roney about DIGMA. And now that we know what it is,
and apparently that you just have to turn it on and magic happens. Is
it really that easy? Yes, but I can take no credit for that.
The open telemetry and open telemetry and how easy it is to integrate with
dot was a very strategic decision by the dot back team and there you know
so many different examples online. It is that easy to get some data out
of your application, and there is also so much more depth to that data
because now it's not just about logs, it's about logs and metrics and traces
and inter correlating them. So it's it's very very easy to get very rich
data and start making evidence based decision about your code and knowing what to focus
on and what you need to improve. And it can see back to their
product managers who now know that they need to prioritize something because they know it's
impact. Give me a typical example of something that a developer might do that
UM DIGMA would pick up on and say, hey, you should do it
this way instead. Sure, UM, I'll give you a few. One
example that I noticed is especially working with enemy firm work and these kind of
absumptions, is you often fall into some coat smells inadvertedly just because of leaky
abstractions and such, where you might create let's say an end plus one query
or some kind of inefficient query that can be picked up if we analyzed what
was actually happening when you when you're runner. And this is something that's easily
picked up, like if you look at the choice, it will immediately jump
at you. But to look at it and to know how to do that
as a novel, right, and it could be something that has to do
with basically how, let's say, how the quode is being used. So
let's say I want to make a change in a particular area, and I'm
working in a complex environment. So finding static usages is one thing, but
understanding who's using this code in run time is another. And why is that
important? Because those are the areas I want to test that I didn't break
their flows, I didn't break their APIs and so on. That this is
from a usage perspective, Well, that's ultimately what matters. It is not
what you thought they were going to query from the data, it's what they
queried from the data exactly. You're taking in a parameter from a user and
they're searching on something horrible, but that's what they're searching on, so you
know, how are you going to deal with this? On top of that,
the you know, the any framework context could be could be described as
a wrapper around leakey abstraction and so many ways you can go wrong, especially
when you apply it to the Web. Definitely, definitely. And the idea
is once you start getting those types of feedbacks, you start coding a bit
more confidently because it's kind of like how then tests behind you. You know
that there is something that's actually checking what's happening. And if I change the
quarry and I forgot to add an index, I'll see those effects immediately.
I'll see them and get notified about them and be able to do something about
it. So rather than wait for that report up the stack of this the
app is too slow. I mean, what I find very cool about this,
and I'm just looking some of the screenshots and things, is you're you're
in studio, you're looking at your code, but highlighted beside it is how
this code ran in production from open telemetry data. So you can see that
the fifty percent case took this long. The ninety percent case the slowest cases
to take this long, so you see the variability in that, like you're
kind of being guided to your problem children exactly exactly. And actually comparing those
environments is also really critical. So knowing that let's say this area where I'm
having major issues in one environment, visit project production is not getting hit at
all in my testing environment, for example, would be some some other insight,
and that's an interesting insight. That's kind of barress environment, just because
we have the various different content, right, So all in all, I
think that the one way to see how valuable it is for me it was
just to turn it off because and you can see that in the screenshot like
on the website where you kind of see these code lands and highlights all around
your code telling you what's going on here. And then the first thing I
do is I turn it off, and and suddenly you know that it's still
there. You just can't see it because that data we didn't invent, We
just analyzed the existing one. Yeah, so immediately there Now there seems to
be a sort of excuse him here between servicing the open telemetry information and the
AI part of the equation. I hesitate to even say that because is it
actually a recommendation engine for how to treat it. So the AI is used
to do a lot of thang. Now we're getting a lot of data,
and the first things and the need to we need to do is make it
useful and data is there's a lot of instances. This took this, this
took that. But now you need to start to break it down to clustery
in order to understand the main flows that are going through the system. Then
to start understanding changes. What constitutes a change. You know, production environments
look like a very abstract kind of wall where you just scattered paint all over
it. It doesn't look like a nice graph where you can say, oh,
here is that area where the change happened. In order to kind of
start analyzing that, you need to make very advanced kind of data processing to
understand which variables are related. For example, so I can't just say this
is slow. This is not slow, because maybe it's low when a lot
of users are online right right, So that's where are the open tell emergy
data comes into play. Yeah, so you need to correlate those that data
and to start coming to conclusions about what's the root cause, where where is
the bottlenetwork when did this problem happen? And what is it related to?
And all of these questions are great questions that require a lot of heavy lifting
or cognitive efforts to answer. So how does it and that's where AI comes
into play. How does it integrate with visual Studio for example, like what
are the kinds of things that a developer can count on? So regarding Visual
Studio, the idea and we haven't launched our Visual Studio play and yet right
now we have a base cut plug in and the Visual Studio plug in is
end development. We just support Rider from jet Brink. But the idea is
that it integrates into both the interface of the visual studio itself, so you
can always click to see what's happening in this area of the code. It
integrates into the functions so that you can see highlights if there's something critical to
know about the specific area, and it can show you immediate feedback when you're
debugging or troubleshooting, so you can take an action and immediately see, Okay,
this action has happened, and these are the code locations that we're triggered
by my action. So it's kind of a mapping or a map between the
observability and the code. It's just where the machine learning model really comes into
play is being able to make sure it's associating with the right code, so
it's steering you to the right place. Yeah, Yeah, it's machine learning
helps with a lot of problems. It helps with a normally detection, prediction,
trend analysis, clustering, and also correlating the code to specific issues and
right, and I'm nothing. Yeah, I mean a number of times I've
been I've been handed at performance report on something and said, now, go
find the code it's causing this and fix it. You know that those are
much more difficult problems to try and get it to try and have tools and
help you get to the right association. I think make your life a heck
of a lot easier. Yes, you feel like you look at the right
place. I don't know if you are. I don't know how often this
is wrong and you're putting in the wrong place. But certainly I've gone and
fit I've gone an optimized code that made no difference to the problem whatsoever.
Yeah, and and there is a problem here because these performance records tend to
miss a lot of the context. So I got the filming a developers ask
me, I saw there's one hundred per sensipin utilization? That bad or good?
Like? Could I be happy that that that I actually managed to scale
things and parallelize them. So I'm using all of the CPU or am I
being an inefficient There are ways to answer that question, yeah, but they
require more contact or somebody is asking me, you know this process, I
see it's taking forty millisecond. Great? Is that a friend from your takeline?
We should address is it impacting a thing separation and asynchronic separation? What's
going on here? And this is exactly that type of contact that when handed
a performance report, you know, a developer would often shrunk because it's it's
very hard to contextualize it and realize what it means. Sure, And as
a result, we have what we call some sometimes these silos called you know,
the performance expert guys who who know their data dog and graphs and and
you know whatever or two of the d're using and they're great at authorizing that.
But in my mind, this should be democratized with by using these types
of our technologies lack ours like other technologies in our in the market that make
it very accessible for developers, So I don't need to know about graphs and
and plus one the felly and and P ninety five and metingons and what I
can or cannot do about that in order to understand the significance of the of
the data point. Well, you know, often we have exactly the situation
with profilers are complicated enough that you tend to have a team who specializes in
using it. But it would be nice to have everything, you know open
telemeratary city sets is up to the place where we're always telemetrying everything. So
just to be told, hey, this software is not particularly this chunkle codes
ow particularly fast, but it doesn't run very often, so it doesn't matter.
That's fine. As you know, the old forty millisecond one is great.
You know, if you're running something one it's forty mile seconds is awesome.
If you're running a billion times forty miles, is that that good?
Exactly? And you know what this is something I was talking to somebody who
actually works and someone who actually works in an observability company, ironic as it
did, and he told me, look, I manage the king of developers,
and my number one issue is that I see them spending so many cycles
just optimizing for the wrong thing. They go and micro optimize the heck out
of a piece of code that gets called once in a blue moone and does
this set up process that nobody cares if it takes forty minutes or sixte this
other piece of code that's right there. That's kind of every set in mill
second you and you add there will have kind of a ripple effect across every
microservice service and nicolusten because I don't know it's decoding some string or something like
that, and they don't realize it, so they don't And an extra thought
as they add that on the code addition will change his name. So it's
that kind of this on end between you know, what some people might know
about the code, but and what everybody should know about the code. In
harder to to make a confident you're a good profile in getting you down to
here is frequently called code that needs to be faster. That will make a
difference in everybody's lives if it's if it goes quicker. Yeah, but think
about profiling. Profiling is also not continuous. That's something that's usually kind of
the interval thing. And yeast will work it's also constructive tests, so you're
often testing against bad data, right, You're you're building good tests is hard
too, so it's like I have highly optimized this for this scenario that will
never happen, But boy it goes fast when that thing that never happens happens.
Exactly did the did the name digma? Is that kind of like a
play on agma, Like it's not dogma, it's stigma. Uh, that's
a good interpretation the but and it's not that farm. When I was thinking
about the name, I'm mirabue origin and the word and Hebrew for paradilm is
paradigma. I just remember and we got them because for me it's kind of
sable. Right, Wow, that's cool. I this core idea that how
your code random production always appears beside your code. I'm very much enamored of
this. This is a healthy thing that if you are all, every time
you look at code that's been out in the wild, you also see what
happened that this is what it looks like in a while, Because just that
gardening aspect of as your group grew me through the code, you could see
something that would make just draw your attention long enough to make the small optimizations
that might make a difference. It doesn't become a big optim zation ritual just
becomes gardening. And I think that it also goes hand in hand with developer
responsibility is becoming different than they used to. The code ownership is growing,
you know, and and this is something I think we're seeing across the industry.
Developers are doing more and owning more. It's not like it's no longer
a handover process. You mentioned before the QA team from twenty years ago,
where it was Okay, I'm done, you guys take it from here,
and then it's kind of like yeah, and then they do their QA opposite
their OPS and and kind of somehow this tack makes its well way to production.
So continuous means that everybody's doing a little bit more. And developers today
do some QUA under code right, They're doing at testing, they're they're they're
aware of at least of the deployment aspects of it, so they know how
to kind of what resources to require and so on, and how where they
wish to deploy it, what they need from an authorization or in a different
perspective that are more holistic about their code and how to use it and as
a result they become they own it much more. And the question is,
how can you as a developer be expected to own your code when you don't
have the data to do it? Like, how can I ask you?
You know, Richard, it is now your responsibility to own this feature that
you developed it. This is yours. If if this breaks, it's on
your head. And then on the other hand, the moment you released it,
you know nothing about what's going with it. How will I know when
it broke? Yeah? Yeah, So so being aware and involved in those
things is critical in my mind to being Yeah, I just love the idea
that you're always reminded that your code is being used by others. Yeah,
Like, that's that's very That's going to keep you in the right head space
certainly for sure. And and we think about the negative or we mentioned the
negative, but there is a lot of positive feedback as well. Oh yeah,
this, you know, people are using this. I'll give you an
example. We one of the things that we added and thinking about was finding
scaling issues. That's not not not rocket spines, but there's something that's hard
for somebody to do manually, which is basically correlate let's say concurrency was performance,
and say, you know what, whenever this code is being called uh
with the concurrency of let's say eight request per second, uh, this is
how it performs to request per second, this is how it performs. And
and this is how it performs. And we can start seeing the trend and
tell you the scale factor of this code is is nuts or horrible? Or
we can say after after x amount, there's a lot in or and it
breaks down company causes problems. Yeah, and that's that's important to know as
a negative impact. But then we add the positive feedback as well. People
are using this code. Yeah, this code slaps you know if you actually
I've discovered it will it's one of the most performance scalable areas in the code
so far because you you've done your job right. So if in my mind,
if if you don't also provide positive feedback, it becomes that looking for
trouble sure paradigm where yeah where Yeah, I'm not going to glance in there
because I'm afraid what I'm going to find. Versus this is actually giving me
good feedback about the things that I do. And when I improve things,
then I feel good about it because I can see it as well. So
what's next for Digma. Yeah, so we're not launched yet. We're going
to launch officially in more August, but until then we're running a closed data
So anybody who's interested in more joining at the close beta UM is more than
welcome. We love develop our feedback. This is what we're basing our own
I know feature set on UM and we'd love to have more developers get their
hands on the product and tell us what they like and what they don't.
Awesome, I've already signed up. I can't wait. Yeah, that's great,
Ronie, Thank you very much. It's it's a great, great concept
and I'm looking forward to seeing the execution. It looks great. Thank you.
It was really great being on the show. You bet. Yeah,
and we'll talk to you next time on dot net rocks. Dot net Rocks
is brought to you by Franklin's Net and produced by Pop Studios, a full
service audio, video and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com. Visit our
website at dt n et r ocks dot com for RSS feeds, downloads,
mobile apps, comments, and access to the full archives, going back to
show number one, recorded in September two thousand and two, and make sure
you check out our sponsors. They keep us in business. Now go write
some code. See you next time. We got Van do