Speaker 1: How'd you like to listen to dot NetRocks 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, we'll get
you that and a special dot NetRocks patron mug. Sign
up now at Patreon dot dot NetRocks dot com.
Speaker 2: Hey Carl and Richard here with your twenty twenty four
DC schedule.
Speaker 1: We'll be at as many NDC conferences as possible this year,
and you should consider attending no matter what. The Copenhagen
Developers Festival happens August twenty sixth through the thirtieth. Tickets
at Cphdevfest dot com.
Speaker 2: Ndcporto is happening October fourteenth through the eighteenth. Tickets at
Ndcporto dot com.
Speaker 1: We'll see you there, we hope. Welcome back. It's dot
net Rox. I'm Carl Franklin and Amateur Campbell and we're
here with Mark Rendell. We're going to introduce him in
a minute, but first I want to check him in
by Buddy Richard. You ready for dev Intersection Well, and
this show publishes.
Speaker 2: We will be most of the way through the show,
I think we'll be close to doing like the closing
session and stuff as we usually do. Right, Yeah, yeah, yeah, No,
we got our got our act together, got a new
version of a generative AI show, which has been an
adventure to put together. Boy boy, there are a lot
of AI conferences right now. Yeah, I know it's little nuts.
Speaker 1: But still dev intersection with all your favorite Microsoft people
and YE speakers.
Speaker 2: The Hanselman's and the Hunters and all that good stuff.
Speaker 3: Yeah.
Speaker 1: The Scott's, Yeah, the major Scott and the lesser Scott's.
Speaker 2: They're all vps. Now I mean this, there's one Guthrie
but he's not there. But you know he's on sabbatical.
What's up with that? Yeah?
Speaker 1: What is that with that? What does Scott Guphery do
on sabbatical? Does he read tech manuals? Does he create
a few more patents? No, he's got teenage boys. I
think he's got other things to worry about. Yeah, that's good.
All right, Well let's jump into better note of framework.
Roll the crazy music.
Speaker 2: Awesome? Alight, do you go?
Speaker 1: So this was our clickbait story on security this week.
Speaker 2: But it's not clickbait if it's true.
Speaker 1: Yeah, I know, but that's what we call him.
Speaker 2: We called it.
Speaker 1: The last story is always the one people want to
hear about the most, you know, so we let them
slog through all the other stories and then we spring
it on them. So here it is. You're you're not
going to believe this. Researchers find sequel injection to bypass
Airport TSA security checks.
Speaker 2: Nice.
Speaker 1: So what this means is there is a vulnerability where
somebody could use SEQL injection when they bought a ticket,
and that ticket could give them status as crew, right,
and then they could walk right on, go right up
into the you know, the bulkhead seats or whatever, sit
down and enjoy all of the crew you know amenities.
Speaker 2: Not that there's not many of crew amenities, but yeah,
you're definitely gonna have access to more seats.
Speaker 1: Yeah.
Speaker 2: The bigger one here is that you know, you can
go to the crew line at the TSA. Yeah, yeah,
and they that's a very cursorly view. And you don't
have to be dressed as crew, I mean, you don't
have to be working on that flight, right, but if
you are crew, you get a special pass and you
get all sorts of amenities. Yeah, interesting. Yeah, they normally
check ID, So I wonder if you actually try to
do that, if if when you got to the line,
they're like, where's your ID?
Speaker 1: Now that's just you know, raining on my parade here, Richard.
Speaker 2: I still love that that, you know, sequel injection attacks.
Speaker 1: Yeah, sequel injection. I thought we were done with this.
Speaker 3: Nah.
Speaker 2: No, still like it's number one or number two in
the O ausp tense.
Speaker 1: Oh of course, yeah, yeah, still still it was it's
like sixteen years ago we learned about this.
Speaker 2: Yeah, yeah, it's been it's been decades, and it's just
a you know, sanitize your inputs. Bobby Tables is out there.
Speaker 1: And Bobby Tables you got to watch out for him.
All right, That's what I got. Who's talking to us today?
Speaker 2: Richard grabbed a comment off a show eighteen eighty eight,
the one we did with Steve Smith talking about modular monoliths,
and I know we're going to talk about simplicity with Mark,
So I thought this conversation just tied in so well
with that whole problem space, because that's the show that
Smith did focused on, you know, simplifying a monolith, tearing
out pieces to optimize them. That kind of thing that
whole idea that you don't have to go totally micro services.
You can just do what you need to do. And
Mark had this comedy. He said it was a different Mark,
not our gas card. He said. From an application level,
I agree with Steve's point of view that we to
start with a monolith and then split off whatever needs
to be spun into its own services as the need arises.
From a hosting point of view, though the reality is
most businesses unfortunately, when you start down one technical direction,
regardless of what it is, you're likely to keep going
down that forever because temporary solutions become permanently yep. For example,
moving from something like app service to Kubernetes is a
huge jump and it'll be hard to get business buy
in for what the need arises from it. Yeah, and
I found you can use something like Kubernetes as a
service from the onset, but with very minimal setup thanks
to manage the services like as your Kubernetes services, which
gives you the flexibility to about resilience and scalability and
everything else as the need arises without having to overhaul
the entire system architecture. And I appreciate the thinking Mark,
because my workaround would be to stay in app service,
but then to spin off the problem service as a
logic app right right, that just you know, make it
a servilest component. It just gets called the same and
you can keep it in the security context. But I'm
not going to argue with you about moving from app
service to Kubernetes. That's a huge lift. But that's the
all micro services mantras to do that huge lift, and
I don't think people want to do it. So the
fact that we can spin off bits into servilest components
and deal with their performance issues or their behavior issues
separately is the simple workaround rather than looking at the
big wall of climbing up Kubernetties.
Speaker 1: Yeah, that's why we have modular monoliths, so you can
break off the pieces and need broken off.
Speaker 2: Right, and you could break them off in less painful ways. Yeah,
I mean, you could even spin it up as a
separate app service, but I wouldn't.
Speaker 1: Nope, I wouldn't either.
Speaker 2: So Mark, thank you so much for your comment, and
a copy of music co Buy is on its way
to you. And if you'd like a copy of music Code,
I write a comment on the website at dot at
rocks dot com or on the facebooks. We publish every
show there, and if you comment there and everyone on
the show, we'll send you copy of music.
Speaker 1: To go buy. And you can follow us on x
Twitter if you want. That's we've been there for years.
But the cool kids are hanging out at mastadon. I'm
at Carl Franklin at tech Hubs Social.
Speaker 2: And I'm Rich Campbell at macedon dot social.
Speaker 1: Send us a tute. It's another way that you can
get a copy of music to code buy. Absolutely all right,
so let's bring back Rendel Mark Rendel. He is one
of our favorite guests. He's the founder of Rendall Labs,
which provides consulting services and workshops to dot net development
teams across all industries. His particular obsessions are API design
and development, performance observability, and code based modernization. He also
uses skills acquired during a few years as a professional
stand up comic to deliver entertaining and informative talks at
conferences around the world, and recently learned to play bass
so he could join tech parity band The Line Breakers.
Speaker 3: Hey dude, hi man.
Speaker 1: Congratulations, Welcome to the world of music for no money.
Speaker 3: Thank you, thank you so much. I am loving it.
Speaker 1: It's been a while, It has been a while.
Speaker 2: You did the parity band thing for a while there, Carl.
But did you actually get into trouble with that? Was
that back before parody was like accept the use? Oh okay,
well yeah, here's the story.
Speaker 1: So Don Box and Ted Pattison and George Bullock and
a couple other people started this band called ban On
the Runtime, and band On the Runtime was parodies of
C sharp to well known music, right, so fifty ways
to send a message, you know, that kind of stuff, right,
And so the Microsoft lawyers had a problem with it
because parody law says you can parody a song by
you know, changing the words like weird al does like
because I'm fat, I'm fat ham on hole week, right,
But you can't parody something like C sharp using a
song that's not covered by parody law. So you can't
change the words to parody something else. We weren't actually
poking fun at the songs. We're using the songs to
poke fun at dot net. And they, the lawyers kind
of put the kabash. It seems very sus well, but
the law is the law. So they basically went to
Paul Simon, for example, and they said how much would
it cost for the band to play you know this
at a you know, Microsoft event, and he wanted like
two hundred and fifty grand. So that's the law. Yeah,
you have to get permission.
Speaker 2: The law is subject to interpretation. I think those lawyers
interpreted it very oddly.
Speaker 3: Microsoft lawyers interpret things as badly as possible. Don't.
Speaker 1: But you know, they are Microsoft. And if it was
just me doing it, who cares? Because go ahead, I
don't have two hundred and fifty thousand dollars, you know,
but Microsoft, Yeah, might be a problem.
Speaker 3: Yeah, And you know, all we are doing. We provide
the entertainment conference parties and it's like there's a couple
hundred people there and they're all drunk. And yeah, we
don't parody any specic. The closest we have to parodying
a specific technology I think is JavaScript, which was one
in itself, and JavaScript isn't even a language, it's it's
a well, it's a standard. I suppose I was going
to say something meaner, but I went.
Speaker 1: But no.
Speaker 3: Line Breakers their bassist used to be Don Sign really,
creator of F sharp and then he had to he
got pulled into gitub next, the kind of Microsoft Research
equivalent at gitub, but he was still at Microsoft Research
and still sort of the benevolent dictator for life of
f sharp and he just could not fit in conferences
as well as all of that, and so then they
were without bassist. And then I said to Dylan Beattie,
how hard is bass because he's certainly got four strings?
Speaker 1: Can it be?
Speaker 3: And he went as, actually not, it's much much easier
than guitar, And so he lent me one, and I
took it home and I plugged in, plugged it into
my computer with a sort of six point five to
USB cable, and got Rocksmith Plus and tried playing a
few things, and I think within five minutes of sitting down,
I had learned to play seven nation army okay. And
so it's not I mean, it's not an easy instrument.
And if there are any basis out there going oh no,
not this again, it is definitely not an easy instrument.
I've got one to like jazz and funk and disco
and those sorts of things, but the learning curve is
extremely shallow at first, so it's very very encouraging.
Speaker 1: Yeah, right, you can play Smoke on the Water just
by going but.
Speaker 3: Club but chugging basslines.
Speaker 1: However, of them bass you know, it's easier because you
don't have chords and and all of that, but it
is more difficult because to play bass really well you
have to have a great tone by the way, yes,
and also you have to have saw like bass player.
You just to be able to play a couple of notes,
isn't playing bass? You know, you really have to. It
takes a while before before the funk or the saul
comes out.
Speaker 3: Yeah, and just getting in the pocket like right on
the b and just giving tone to the drums.
Speaker 1: But you don't have chords, but they don't have chords.
That's your jack app story and.
Speaker 3: Seeking nobody as.
Speaker 2: There are a few very extraordinary bases that nine essential.
Speaker 1: So what's on your mind? Randall?
Speaker 2: What have you been up to?
Speaker 3: I was at the Copenhagen Developer Festival last week. Rich
was there and it was absolutely brilliant and I had
a new locknote talk that I did which is called
the Albatross Project. But they also asked me to do
the free meet up the Tuesday night before the festival started.
And I had a talk that i'd submitted for Copenhagen
that they rejected because I just do lockmotes for in
DC now apparently, but they said, you can do that
talk at the meetup if you want. And the talk
was called how simple is as simple as possible? And
this is both of these talks, they're related. So the
talk is a sort of technical can you do this?
Can you do that? How can you keep things simple?
And then the Albatross project is the opposite of the
Phoenix project nice, and it's about a development director who
doesn't deliver anything for thirty five years because he keeps
trying to stay on the cutting edge. And yeah, and
I just after I did the talk version of it,
at which there was one slide where the slide popped
up on the screen and somebody immediately got up and
walked out.
Speaker 2: He knew it was a right slide.
Speaker 3: So I'm kind of like, yeah, this is working.
Speaker 1: You don't think like his wife was in labor or
you know.
Speaker 3: Is no probably a React developer, Ora Angular or View
because those were the three there were three JavaScript framework
logos on the slide.
Speaker 1: Anything where you're like, hey, where you go?
Speaker 3: I hadn't said anything because we were actually having a
technical issue at the time. And yeah, I mean it
is possible it was the technical issue that you sent
him out there, just kind of like, I'm not waiting
around while these people turn the screen back on or whatever.
But yes, it's I kind of I feel like I
owe people an apology to a certain extent, because in
my forties I did a lot of bouncing around the
world telling people how to contain the rize things and
do micro services and event driven things and Kubernettes and
all that sort of stuff. And now in my fifties,
I'm kind of wishing most people would stop. And so
that's my mission at the moment, and that's I'm going
to be trying to get this talk into as many
things as possible next year and start pushing at it
because we've just made everything, everything just so complicated in
the name of efficiency, in the name of standardization.
Speaker 1: Potential future scalability. That's the big one.
Speaker 3: Yes, absolutely, But also you hear the term DX developer
experience and developer experience, I feel like that should be
an important thing in terms of your ID, your code editor,
your command line tooling, that sort of thing. But if
you're getting to a point where the improved developer experience
that you get from sort of CICD and microservice deployments
and rollouts and all that sort of thing is actually
getting in the way of delivering a good user experience
because of the increased latencies that you get or the
fifteen megabytes of JavaScript that a webpage has to download
before it becomes interactive. Then there's some thing wrong with that.
We have had priorities completely the wrong way round.
Speaker 1: Yeah.
Speaker 2: One of the ways to keep that stuff fast is
to keep it simple.
Speaker 3: Absolutely, Yeah.
Speaker 1: And so yeah, it's been my mantra, you know, do
the simplest thing that works ever since I got started
in software. That's been you know, stapled to my forehead.
Speaker 3: Yeah. I wish I could say the same of myself,
but at least, you know, I'm realizing it now and
attempting to share some of that.
Speaker 2: Well. I think part of this is we wanted to
believe that if we, you know, embedded ourselves in this architecture,
like if we understood all the pieces that gradually software
would be easier in that space. I just don't feel
like it ever got there.
Speaker 3: No, No, I mean I think it did at a
particular point. I think espn net mvc pretty simple, was
relatively simple, and the idea of the pipeline. So what
we kind of picked off with o win based on
things like Python WSGI and Ruby's rack middleware, and then
o win obviously kind of got rolled into asp net
core and that was nice and simple. It was like,
do this, then do this, then do this, then do this.
But then I think the problem is that as developers
we think that if we're not changing the way we
do things, if we're not evolving, then we are failing
in some way. There's this whole thing about continuous learning,
and so people kind of go, well, there's somebody says microservices,
So I need to learn microservices. Now I know microservices.
Why have I learned it if I'm not going to
use it? And then they end up breaking something with
like two dozen end points down into twelve micro services
and you're just like, no, I should.
Speaker 1: Have learned that from doctor card, right, absolutely.
Speaker 3: Yeah.
Speaker 2: Well, I was like the argument that my service makes
a lot of sense when the team is huge, that
it creates a level of granularity that you can have
a lot of people working in parallel and then have
your fights over integration rather than fights over coding. Yeah,
but most teams aren't that big.
Speaker 3: No, they're really not. But I think a lot of
the time, people who don't necessarily have a lot of
different job experiences within the industry, they think that they're
in a big department because there's like one hundred and
twenty developers, all right, And then you're kind of like no, no, no, no, no, no,
go and take a big Netflix or Uber or Microsoft
or your average financial institution. I worked at Morgan Stanley
and I think I was one of ten thousand developers
working at Morgan Stanley. So yeah, that and the other
thing then is when you're at that scale and your
team within that maybe a lot larger and a lot
more different people on it. You may have a sort
of architect leading the design of the system, and you
have testers and DevOps people and all those kinds of things,
and so what they call a micro service can well
be bigger than the entire thing that other people are
trying to break down into micro services. And so yeah,
there's this dissonance from people not actually realizing what scale
they're at because it feels big to them.
Speaker 2: They just haven't been exposed to the other things. What
about the cloud native concept? Is this where you fall
on that we should define it first.
Speaker 3: Yes, So cloud native is essentially building apps that are
designed to run in the cloud and leverage I think,
you know, like the the term twelve factor apps has
kind of fallen out of use a lot. I think
a Roku introduced that idea, and I think a Roku
was one of the first cloud native style platforms, way
before Kubernettes and containers and all that sort of thing
came along, and it was build your app so that
it consumes services that are provided for you and can
be deployed by doing a Git push or whatever else.
And you're not worried about infrastructure. You're not worried about
VM size, CPU core count, all those sorts of things,
because you're just.
Speaker 2: No updating machines, just million new instances in rolling.
Speaker 3: Across totally totally. And then you have things on top
of that around reliability, which obviously you know poly in
dot net. But when you're building for the cloud, you
have to build for partition, You have to build for
things that are likely to you know, things in the
cloud go down for two seconds and then come back
up again. Because somebody did a push and it just happened,
and so you have to that. You know, you can't
just go, oh no, the database is gone. You have
to go, well, I'll try again in a second, then
in two seconds, then in four seconds. Obviously with that
weird fuzzing thing that changes those numbers into something not
quite surround.
Speaker 2: But maybe that's what's happened is people misconstrued being cloud
native with products like Kubernetes.
Speaker 3: That's the thing cloud. So you have cloud Native, which
is a concept and an idea and an abstract that
you can aim for, and then you have the Cloud
Native Computing Foundation, which is attempting to be for cloud
computing what the Linux Foundation is for Linux. And you know,
Kubernettes is often called the operating system of the cloud,
and there's going to be people going often called by whom,
But so they have projects that go through kind of
incubator and preview and then stable and ready for everybody
to use. And so people feel like if they are
going to be cloud native, then they should go down
that like it's a checklist almost and go are we
running on Kubernetes, Are we using a service mesh? Are
we using a document database, Are we using event sourcing
and all these things that they have projects for, And
you can be cloud native. You can build you could
build I don't, please don't, but you could build an
asp dot net web forms app that was cloud native
that covered all those things. Just with the various rules
and all this sort of stuff, there's nothing stopping you
from pushing an asp net where it forms app into
an Azero app service in a VM or something or
a VM or yeah.
Speaker 1: And that just proves the point that just because you
have checked off all the boxes doesn't mean using the
rate technology for the job.
Speaker 2: Well. Absolutely, And you haven't talked about the customer requirements
anywhere along the path here.
Speaker 3: Nobody's asking about that. The customer's kind of going. What
I would really like is for the page to load
in less than four hundred milliseconds, And which is the
something limit. It's like, four hundred milliseconds is the point
at which people go that with subality limits. And we've
actually gotten to this point now. This is one of
the conversations I was having with people where four hundred
milliseconds feels unattainable. And have you guys watched the Spotify
documentary thing on Netflix playlist or something that's called. So
it's about the guy who started Spotify. It's like six
episodes and they're each done from a different perspective, a
different person's point of view. But Daniel Lek, the guy
who started Spotify, his sole focus to get it launched,
in tech terms, was that when you click the play
button on a song, it should start playing like immediately.
And he was aiming for that four hundred millisecond point
and he got it. And that was in two thousand
and one. And now we're here with an internet that
is several orders of magnitude faster, We've got five G
on our phones, we've got gigabit plus internet at affordable
prices for a lot of people. And we're still saying
that's really tricky. We can do it in like one
point four seconds if you're in a fast connection, And yeah,
we've we've lost lost sight of the ball, and we
need to examine ourselves as industry and say, well, what
are we doing and why are we doing it?
Speaker 2: And is there anything what are we doing for those
one point four seconds? Exactly what are you up to?
Speaker 3: And so yeah, and like I say, the talk covers
this from infrastructure from back end, from front end, from
programming language and all these different things, and yeah, frontend,
it's it is honestly quite a simple answer. We are
downloading a shedload of JavaScript which the browser then has
to pass and jit and do all those sorts of things.
And before we do all of that, people can't scroll
a blog. And you're like, it's a blog. The only
thing on it that needs to be interactive is the
comments and maybe a like button or a share button.
Even the share buttons are just links. But no, I
see people sort of writing blogs with nuts dot js.
Speaker 1: Are you still bolished? And blazer server, Mark.
Speaker 3: I really like blazer server for internal things, for where
you have a very definite upper limit on the number
of concurrent connections that you can have, and it's like
in the thousands or maybe tens of thousands, and you
can scale up for that and everything. Once you scale
blazer server beyond a single instance, then obviously it becomes trickier.
So if you've got like messages and one person sends
it on one instance, that now has to bounce through
something like a reddish pubsub or something so that the
other instances can pick it up. But it's still very simple. Actually,
I've been playing with so blazerin dot net eight and
you have the server side rendering, and so it will
render pages on the server and it will return them,
so you can have a site that works with search
engines just as much as anything else, just like Razor pages.
And then it will download the Blazer web assembly runtime
in the background, and it will download your natively compiled
Blazer application in the background, and then silently without the
user even noticing that's anything, that anything has happened, the
next time they navigate, it won't make a request to
the server. It will do it locally.
Speaker 1: It's like magic, except that it doesn't work.
Speaker 3: It's they'll get there.
Speaker 1: I've done I've done tests and I recently did another
one and we go from service side rendered directly to
web assembly. There isn't any server rendering in between while
web assembly is downloading. And that's been a problem ever
since they released that, and it's still a problem. Well,
but they'll get there.
Speaker 3: I'm just going to keep my fingers crossed for for
dot netline. But no I did. I ran into some
issues with it myself and have started looking at an
alternative thing, which is HTMX, which is that X stand
for so essentially this is a push back against things
like React and Angular and so forth, where it's kind
of what you actually want to do, what you actually
want to achieve is when the user clicks something or
interacts with something in some way, you want to make
a call to a server and then you want to
make a change to the dom of your current page
right and insert a div and with some stuff in
it or something and so works, which is how Blazer
server works. And HTMX is kind of let's let's just
lean into that as far as possible, and we'll just
use HTML attributes on elements and we'll say, okay, so
on this element, when the user clicks, we are going
to make a request to this endpoint on our server,
which is going to return a fragment of HTML, and
then we're going to insert that HTML into the page
at this point, or we're going to replace an existing
element with that HTML. And for I think like ninety
percent of use cases, that actually covers most of the
things you want to do. It will do your comment
form at the bottom of your blog. It will do
your like buttons and an updated view of how many
likes you've got, and all those sorts of things, but
without a huge JavaScript run time doing shadow dom things
and observing signals. They seem to be going on about
signals over in JavaScript land at the moment. That's very
fighting for them. And yeah, so.
Speaker 1: That's sort of like the evolution of ajax, isn't it.
Speaker 3: Yeah, yeah, it is, and it's kind of it's that
the plumbing. I feel like it's a shame we had
to go all the way round SPA to get back
to the point where we're going. Here's a really sensible
evolution of ajax.
Speaker 2: Just refill a div tag for me, would you please? Right?
Speaker 3: So I built a site when I was learning the base,
and it's called fret Badger, which is partly because I like,
it's not a mollusk. If I ever start another company,
it's just going to be called not a Mollusk limited.
What do you do? Definitely not a mollusk. So yeah,
you can you can hire hijack the domain for me
and then blackmail me. But no, So frat Badger. I
wanted to learn the threat board, and I wanted to
learn scales and modes for jazz and arpeggios and that
sort of thing, and.
Speaker 1: So I see chart behind you.
Speaker 3: Yes, exactly. I've got the bas chart on the wall
which has got all the modes and everything else. And
it's basically just if you want to play up this scale,
and you've got the major scale, the minor scale, pentatomics, blues,
all these different things. And I was my base teacher
was pushing me to learn music theory, and I got
really into it because it's it's maths, it's rules, and
it's logical, and so I thought, well, the best.
Speaker 2: Way there's one of the many reasons that musicians and
developers go work so well together.
Speaker 3: Yeah, yeah, And I thought, so if I can encode
all this information about music theory into C sharp and
some data structures, then that would be a good way
to learn it. And also it would be a fun
site to build. And so it's just an asp net
Core MVC app at the moment, but it does have
this thing so you can have like you choose your
freat ball and you say, okay, so I want the
standard base threat board, standard tuning, and I want the
C major scale, and it will show you the little
dots to show you where to put your fingers. But
then when I was doing jazz, it was kind of
it would be really good if I could have like
four or five of them on the screen at once,
and so I added in nothing. But every time you
add a new threatboard, it reloads the entire page and
then it scrolled back to the top. And so I
was looking for a way to make it kind of
more smoothly interactive. And so that's what I was looking
at the Blazer server side plus WASM for. But as
Carl says, there are some issues. But then I saw
HTMX and I'm kind of like, that is exactly what
I want. And the beautiful thing is it works really
really well with esp net core because we have partials
and so we can just go, when this request comes in,
just render this partial. So yeah, it's and it's that
sort of thing. The key thing with HTMX though, is
the entire library is fourteen point six killer bytes minified
and chesipped, which is tiny.
Speaker 1: It's less than your logo graphic button.
Speaker 2: Radius is bigger than that.
Speaker 3: Yeah, yeah, you know, it's like that thing where when
Windows seven came out, the desktop wallpaper was took up
more disk space than the whole of Windows three point one,
like and what is it doing that? So yeah, it's that,
and you know it's They provide documentation and guidance on
how to use Alpine js, which is again a very
lightweight JavaScript framework, kind of like a miniature alternative to
jQuery for the things that jQuery did that didn't then
get built into JavaScript fifteen or twenty sixteen or whatever.
So if you do need, I have one thing where
I wrote custom JavaScript, which is, once you've got your
C major scale up on the threat board, if you
click one of the c's, it will fade the others
that aren't part of that arpeggio. And so it's kind
of like going, so you do this, and then that's
your second, and your third, and your fourth and so on.
And that's twenty lines of chavascript, which isn't even worth
minifying at that point. I think it's actually still hard
coded into the h into the layout dot c shtml
and so yeah, just that little bits of JavaScript here
and there to do a couple of things in the browser,
and then HTMX for everything else. And it's it's working
really well. I'm going to be pushing it live soon.
Speaker 1: It's great. Before we take a break, I just want
to mention that I had written I don't know four
or five years ago this tool. I have a guitar
that has a role in GK pickup GK three pickup,
which is a split pickup, so it goes right in
between the bridge and your first pickup of the guitar.
And it has six individual pickups for each string and
those go through a role in processor and then you
can process each string individually. So another thing I can
do is map it to MIDI. So what I have
is I have something that pulls up the MIDI from
your guitar and figures out where your fingers are on
the front board and shows it to you on the screen.
Not only that, but then I put a service between it,
so somebody could log in in Texas and I'm playing
in my place and I can be teaching them, and
as I play, the dots show up where my fingers are.
Not only that, I got to chord charts and chord
names based on the music theory of it. So if
you're interested in that codebase, I'll gladly send it to you.
Speaker 3: I would love to see that. Yeah, that sounds amazing.
So yeah, and I feel compelled to ask did you
write that using events hourcing or DDD? Is how many.
Speaker 1: It was very simple, all right, So we're going to
take a quick break and we'll be right back with
more with Mark Rendell. Stay tuned. Did you know that
you can work with AWS directly from your ide Aws
provides toolkits for visual Studio, Visual Studio code, and jet
Brains rider Learn more at Aws dot Amazon dot com,
slash net slash tools. You know it's common for business
application to contain fifteen percent repetitive code just because of
metaprogramming limitations in the C Sharp language. Why write boilerplate
manually when a machine could generate it for you? Enter Metaalama,
the code generation and verification toolkit for C Sharp. Their
C Sharp to c sharp template language is simply amazing
logging caching memento observable. If it's repetitive, Metaalama can automate it.
Visit Metalama dot net today and learn to automate your
code patterns with their free edition. Remember it's Metaalama with
one L Meta la Ma dot Net. Attention dot net
developers looking for the ultimate SDK to handle electronic document
processing Meet TX text Control. Txtext Controls, your go to
solution for seamless PDF generation, secure electronic signatures and efficient
digital forms processing all within your dot net applications. Empower
your products with robust document management capabilities, boost productivity, and
deliver top notch solutions to your clients. Trusted by developers worldwide,
including me and Richard. Txtext Control is the SDK that
makes a difference. Check look out demos dot textcontrol dot
com for live online demos and see it in action.
And we're back. I'm Carl Franklin. That's my friend Richard
Campbell and Mark Rendel's here, and we're talking about simplicity. Simplicity.
And by the way, I need to remind you that
if you don't want to hear the ads, you can
become a five dollars a month patron of dot net
rocks and get an ad free feed. Go to Patreon
dot dot NetRocks dot com. Okay, so I guess you
were talking about HTMX and.
Speaker 3: So yeah, and HTMX is one example of simplification. People. Actually,
I'm starting to see projects popping up that are pushing
back against this complexity that we've created. And there are
other examples as well.
Speaker 2: There we are.
Speaker 3: You don't need to run a coubonet. So the comment
that you read at the start of the show from
the other Mark and he were saying, how Aks and
eks the sort of managed Kubernetes are super easy to run.
They're really not they really they're easier.
Speaker 2: They're easy. Err, it's only because you've been traumatized by
trying to run Kubernetes by head.
Speaker 3: I mean, yeah, never ever, ever try to run your
own Kubernetes cluster, unless maybe you just want to build
one with five Raspberry pies just for giggles. But no.
So let's take a zero as an example, just because
it's the one that I know best. But Microsoft support
a version of Kubernetes I think for four versions for
minor versions. So I think we're on like one point
twenty one at the moment I get confused with version numbers,
and so they will still be supporting twenty and nineteen
and eighteen. But as soon as twenty two comes along,
if you're still on eighteen, you need to upgrade. And
Kubernetes versions land three monthly or six monthly, I'm not sure, so.
Speaker 2: It means every year then you're probably agreeing so.
Speaker 3: But you are at least once a year going to
have to upgrade your Kubernettes cluster. And if you do it,
if you do the upgrade the minimum number of times possible,
then you're doing a I mean, Kubernett's versioning is a
whole thing anyway, because those are not minor versions, they
are major versions. A lot of the time they remove APIs,
they deprecate APIs, and yet somehow we're still on one
point something. And so if you want to minimize the
number of times you have to do this, you're going
to be going from like one dot eighteen to one
dot twenty two. That's a lot of jump. That's a
lot of things that in an enterprise environment, you're going
to have people going over pages and pages and pages
of release notes to make sure that you're not going
to break anything. Or you upgrade every time the new
version becomes available, which is going to take less time
per upgrade, but potentially more time overall. And then it's
not enough to just be running in Kubernetes. You have
to have your service mesh, you have to have your sidecars,
you have to have your your sort of various load
balances and all these kinds of things, and nobody's managing
that for you. Microsoft doesn't Microft hasn't blessed a service
mesh because they can't because people want different things. So
it's it's simpler, but it is by no means simple.
And then you look at you type container into the
creator new thing in the Azure portal, and actually the
first thing that pops up is container app and that
is simple. So that is build. You write your DOCA
file or you know, in my case, right click in
the solution explorer in jet Brain's rider and say add
docer file and it just generates it for you with
all the right best practices, and then do Docker build,
and then do Docker push to your as your container registry,
and then just deploy the thing. And underneath it all
it's running on a massive Kubernetes.
Speaker 2: Cluster you want to have to own.
Speaker 3: Yes, Microsoft are taking care of everything. They're taking care
of the service smash, the upgrade cycle, the stability and
resilience and all those sorts of things.
Speaker 2: Well, and arguably, if you decide it isn't running well
in container apps and want to move to your own
manage infrastructure, you're already there exactly.
Speaker 3: Yeah. And equally, now you can take a container and
you can push that towards your app service where you
used to push web things to, which is also very
nice and much easier than saying copy locally and all.
Speaker 2: These various things.
Speaker 3: So yeah, you know, on that side, there's that simplicity.
And again it's taken us a long time to get there.
Speaker 2: And this is Microsoft figuring out what people actually willing
to use, right like.
Speaker 3: Yeah, yeah, and you know, you know, the reason you
don't get straight from A to Z is because you
can't see zed until you've gone through B, C, D, E,
F and everything else. Yeah, and you don't know what
it looks like. And it's very difficult to find out
that something's a bad idea without trying it.
Speaker 2: Yeah, and without well, and you always have the few
folks they get it that they're willing to put the
time in their their customer is tolerant of it, and
they can do this complexity. But then a whole bunch
of others just like Nope, not doing it. And then
you you know that in the end they have to
you know, Microsoft looks and goes, well, we're just not
getting enough adoption here. What if we did this, like
they are just kind of hurling it at the wall. Yeah,
by a bit, and eventually they stumble on to these
approaches that are simple enough.
Speaker 3: And you know it's the big thing has been serverless
and still is serverless for a lot of the talks
I'm seeing and that sort of thing, which is containers
under the hood. It's containers under the hood. But the
again I'm going to talk about a Zoo functions but
equally applies to a ws lander and another Servilus platforms.
What you end up with then is vendor lock in, right,
because your triggers you've got like blob stories triggers, and
there's your Q triggers and service bus triggers and event
hub triggers and all these different things, and so you're
locking yourself into that. But with as your container apps,
you can use Dapper, which is an abstraction over so
you go, I need a cash or I need a
pub sub and then that could be reddis it could
be as your service bus, it could be men cash
d or Varnish, you know whatever. The different things are
fusion cash and in your container description you just go,
this needs a cash, give it a cash, and then
you use the Dapper API, which will one just as well.
You can use Dappa with containers running in amazons. D
A p R Yes, d A p R naming definitely
an issue at first, and Microsoft.
Speaker 2: Well, Plus there is the other product called Dapper d
A p p e R right, which is the.
Speaker 1: Which is a wrapper around Adeo dot net.
Speaker 3: Yeah, it's the kind of incredibly lightweight mapping from data
readers to CEP objects.
Speaker 2: I have nothing bad to say about either one, but
they've got nothing to do with each other except when
you say their names entirely unrelated.
Speaker 3: But yeah, d a PR stands for Distributed Application platform something.
But DAPPA is great, and it's I think dapper play is.
I would put that in my simple column. It's kind
of I need a cash. I need a way that
I can say cash this data, now give it back,
and I shouldn't have to care about out whether that's
reddis or another solution or just memory. I should be
able to say cash it, give it back, and then
worry about how that actually happens at deployment time. And again,
you can use dapper in Kubernetes, but you don't have to.
You can use dapper in other environments as well, and so,
and I just want to push people in that direction.
Speaker 2: I've well, and what I appreciate this is that you're
still giving us access to all of this complexity without
making it complicated.
Speaker 3: Yeah.
Speaker 2: Right, you're not saying no containers, You're saying containers that
don't make you want to stab yourself.
Speaker 3: Well, I mean containers. Containers are absolutely the simplest way
of deploying an application. Sure, you know you need a
Linux dependency like lib zip or something like that, Just
don't make me edit apt get in the docer file
and you've got it. Yeah, it's that, it's that original thing.
If it works on my machine, I'm going to ship
my machine. Yeah. And so yeah, containers I think are
the simplest unit of deployment we've come up with yet.
And it's just a matter of where do you run them?
And do you need to run your Kubernetes cluster.
Speaker 2: Yeah, And you know we're we're not complaining about containers.
We're complaining about the orchestrators totally.
Speaker 3: Yeah. Management and the assumption that because sort of Facebook
and Netflix and Uber are using something that it's the
right solution for your company.
Speaker 2: Right, You're not them.
Speaker 3: You're not them, And they have armies of engineers whose
only job is to maintain those that infrastructure.
Speaker 2: And test new versions and roll them out and all
of that sort of stuff, and all that stuff if
you need it, but if you don't. At the same time,
you don't want to cut yourself off from the possibility
that you might become one of these things.
Speaker 3: Oh yeah, yeah. But if everything's just docophiles and containers,
and at some point you go, actually, you know, it
would be a lot cheaper when you get to the
point where you're spending so much on as you're container apps,
that you could not only run your own cubernettes cluster,
but employ somebody full time to keep an eye on
it and do the upgrades and everything. That's the point
at which you switch.
Speaker 2: Certainly on the run as side of things. For me,
I'm having conversations with folks who are like, no, we
repatriated this because we already run a twenty four to
seven knock and it was we were committed to doing
these things in this workload. Now that we truly understood
the shape of it in the cloud made more sense
running at home. Yes, but that's a big lift, right, Like,
it's not a small things.
Speaker 3: Really, and the same thing goes I mean, I was
complaining about people downloading fifteen megabytes of JavaScript or WASM
or whatever to run something in the browser. There are
legitimate use cases for that. Adobe now have inside the
network Photoshop and light Room as WASM compiled browser apps, right, So,
and yeah, you know, if you want to edit photos
and clean up red eye using AI algorithms, and you
want to do it in your browser, then you need
to download all that PLASM and that sort of thing,
because you can't have somebody doing a round trip every
time they make a change with a multi megabyte image
file uncompressed.
Speaker 2: Arguably, you're still stopping about you're still talking about the
simplest case. In this case. The simplest case is stick
the whole thing in a ASIM file and stuff for
the download overhead.
Speaker 3: It's that as simple as possible. And thinking about what
that means for you for this project that you're working
on today, it.
Speaker 2: Feels like you're just pressing against the defiles that we're
choosing complexity we don't need.
Speaker 3: Yes, yeah, and I think that, and it's not I'm
absolutely not blaming developers in isolation for this, because I
think that the IT department, there were CTOs out there,
there were CIOs and they're going to their own conferences
and being sold this stuff by people with very very
effective marketing machines, and then they come back and go weak.
Speaker 2: And motivation is not involving keeping things simple.
Speaker 3: Yeah, And they come back and they go, we have
to adopt this because it's the next big thing, and
not doing proper kind of cost benefit analysis and those
things to work out whether it actually is the right thing.
Speaker 1: Something just occurred to me about Blazer server. I remember
having customers say they didn't like blazer server because if
the connection goes down, like they get that what I
call the transparent veil of death. Oh yeah, you know
you have screens of death. This is a transparent so
it turns slightly transparent or translucent translucent, and you know
you have to press the reload buttons. So apparently in
that net nine that is becoming much less frequent, Like
the whole automatic reconnection thing is just going to happen.
Speaker 3: And I believe that they can make that acceptable to everybody,
certainly to the real tech guys. So instead of it
going slightly transparent, don't change the UI at all, right,
just but it's frozen and it doesn't update and then
just change the cursor to a spinning beach ball and
everybody will be happy.
Speaker 2: Everybody will know what's happening.
Speaker 3: Yeah, it's like to say.
Speaker 1: The UI and spin beach ball, and then when it
comes back.
Speaker 2: Why do they need to build a new view of that?
Speaker 1: You know?
Speaker 2: Yeah, that's the thing we trust you can you can
be very subtle. I think it also indicates that possibly
we will recover the veil. Doesn't give you a sense
you're going to recover no veils, like call tech support. Yeah,
what does this mean?
Speaker 3: It's gone it's gone wrong.
Speaker 2: We have pulled the sheet over the body drug.
Speaker 3: But it does it makes sense in a context where
you do have to hit control R or F five
or whatever to refresh the page to get it to reload.
But once they've got that reconnect and heal process working
properly and smoothly, then so.
Speaker 1: Anyway, I haven't checked it out in that NET nine,
but I hear that it's a major feature upgrade of Blazer.
There aren't very many.
Speaker 2: Fewer veils is a good one. Yeah, that'll make people
happier without a doubt.
Speaker 1: Yeah.
Speaker 3: The other thing that I talk about at the end
of the talk is is process. How we went from
kind of s S A d M and prints to
and all the waterfall things. And then there was extreme programming.
But extreme programming generally only works when you've got Kent
Beck and Ward Cunningham and extream programmers and you know,
some of the greatest programmers who've ever lived, all in
a room together, going how are we going to build this?
So you can't do that on your average team of
developers hired off of LinkedIn. And so then we got Agile,
which was trying to make it so that we could
where you get a scrum master and a product owner.
And I've worked on multiple teams that called themselves agile
and said they were doing scrum, that didn't have a
scrum master, had a scrum master who was just a
project manager anyway and wasn't really doing the scrum mastery things,
and in an awful lot of cases, no product owner
at all. Yeah, agile is is agile ish scrum butt.
Speaker 1: And yeah scrum, but we don't do this except.
Speaker 3: And then you see the scaled Agile framework for enterprise
and the lean scaled Agile framework for enterprise, and the
lean one is like for small to medium enterprises and
it seems it's like the London Underground Tube map. It's
just all the different things. And then when I'm sitting
I'm sort of working on the new version of threat Badger,
which is going to look exactly the same as the
old version. I'm also working on another thing. I just
use can ban board. I have a backlog column and
a ready to do column, and a doing column and
a done column when it's just me because I considered
the testing and everything part of that, but you because
it will put uat and everything in there. And the
real issue that came along with scrum was you have
your backlog grooming sessions, which are like weekly regardless of
how many weeks you have in a sprint. Then you
have your sprint planning session, and then you have your
daily stand ups, which everyone tries to keep to fifteen minutes,
but a lot of the time they run, you know,
upwards of half an hour. And then you have your
your retrospective and your demo and your sprint review. And
if you're doing two week sprints, you've got ten days
and you're spending like twenty percent of that in the
various meetings, which means you're not building anything you're not
shipping anything, you're not delivering anything, and where's the value.
And if you are a small team of six or
eight developers, and you are, if you're homogeneous, if you
all know the domain and all the different technologies and
all this sort of thing, then anyone can take any
ticket from the ready to do column and say I'm
doing this, and you can prioritize them just by moving
them up and down. And you don't get into this
thing and ah story points and T shirt sizes and
all that stuff, and it's just kind of you don't
have to do all that stuff. You can just put
a board up and put some stories on it and
move them across and just keep shipping and delivering.
Speaker 1: One step up from a notepad totally pretty much.
Speaker 3: Yeah, you know.
Speaker 2: When you mentioned the cam member in the first thing,
it's just a way to visualize where we're stuck.
Speaker 1: That's right.
Speaker 2: That everybody can see that. You don't have to have
a meeting. Nobody has to memorize, like you see it
every day and you see it when it don.
Speaker 3: Sticks yes, and you know people can kind of go,
that was there yesterday, why is it still there today?
I'll go and ask him rather than having a stand up.
The idea that you set aside fifteen minutes in the morning,
I think it appeals to developers is like, all right,
so I have to talk to people for fifteen minutes,
but then yeah, I get th headphones on, getting motivated
to be a low Yeah, it's another it's that developer
experience thing.
Speaker 2: Again.
Speaker 3: We don't like talking to each other, so just contain
it to work things. But no, you should be getting.
Speaker 1: Out of the way, have a couple of cups of coffee.
Speaker 2: Show has just been about containers, right, It's just that.
Speaker 3: Can contain the complexity. So yeah, So, like I say,
I'm going to be doing that that talk. That's my
my sort of tech talk for the next year at least.
And oh, I would like to shout out Alex Russell.
I think slightly late is his sort of handle on
various media and everything. So and he worked on the
Chrome browser for a long time, on the jamscript, run
time v eight, that sort of thing. And he is
like the little Dutch boy with his finger in the
in the dam saying please please stop using all these
JavaScript frameworks and everything. And so I was some of
the inspiration for the talk came from reading his blog
posts as well, so shout out to him.
Speaker 2: Great infrequently noted is his blood.
Speaker 3: There we go, that's the one.
Speaker 2: Yeah, yeah, I'll throw it, including the show notes. I've
read it before. He's he is quite brilliant.
Speaker 3: He is. He is a very very smart guy and
we should listen to him.
Speaker 1: Not wrong. Yeah, so you got this talk. Where are
you going to be delivering that in the upcoming months?
Speaker 3: So next year it's probably going to be at the
NDC conferences, go to conferences possibly dev Ox. DeVos have
started asking me to come and do things now because
I've been doing all these you know how JavaScript happened
and the Albatross project and programming as great as mistakes,
so they're not tech specific and so I'm getting to
go and do other conferences and meet entirely new audiences,
which is wonderful. One. I'm really enjoying it. And also
my kids are at that age now where I can
do more traveling and speaking engagements, and I'm really looking
forward to getting into it.
Speaker 1: Yeah, there's a couple of conferences in Sweden in Stockholm
that happened every year. You have Sam and sweet Toob.
Speaker 3: Yes, i will definitely try and get to dev some
I've done that a couple of times. That's always a
good conference. But yes, if anyone's listening to this and
would like me to come to your your massive conference
with three thousand attendees, but even if you would just
like me to pop over and talk to a meetup
or a user group or something, then get in touch
and we'll see what we can do.
Speaker 2: Check out the render lads link is on the show notes.
Speaker 1: Just grab a busfair a sandwich in a hostel.
Speaker 3: Yeah, that'll do me. Wake outch have base will travel.
Speaker 2: Yeah, there you go.
Speaker 1: Mark. It's always a pleasure talking to you. You always
bring something interesting to the table and this is no difference.
Speaker 3: So thank you, thank you for having me on again.
It's it's really great talking with you guys.
Speaker 1: All right, we'll talk to you next time. I'm dot
net Rucks. 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 d O t N E t
R O c k S 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 you got jed middle vansported the
s