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