Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month.
Speaker 1: We'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. We're back dot net rocks. That's right, nineteen
Speaker 1: twenty nine. I'm Carl Franklin, Robert Campbell. April Joho is
Speaker 1: here with us. We'll talk to her in just a minute.
Speaker 1: But uh, you know we're coming into the holiday season, Richard.
Speaker 1: Oh yes, and I'm wondering, you know, are you gonna
Speaker 1: you're gonna do some geek outs?
Speaker 2: Oh? I've been right been writing my brains out.
Speaker 1: Yeah, have you thought about any toys you might want?
Speaker 2: We just published the Toy Show on run As Radio,
Speaker 2: which is like Christmas for cissid Bins. It's we've done
Speaker 2: at like six years in a row now because sisms
Speaker 2: are impossible to buy.
Speaker 1: For right, Yeah, of course.
Speaker 2: So it's a Joey Snow and Rick Claus because having
Speaker 2: claws and snow on a show about Christmas toys just
Speaker 2: sort of makes sense.
Speaker 1: That's just going to be over the top, just sort.
Speaker 2: Of worked out that way weirdly enough.
Speaker 1: Well, I have a Christmas present for you, my friend,
Speaker 1: oh oh, that you are not going to believe. And
Speaker 1: you know you and I are very hard to buy for, yeah,
Speaker 1: without a doubt. And so Kelly got this gift for
Speaker 1: me and I was like, oh, yeah, Richard needs one
Speaker 1: of these.
Speaker 2: So what have you done?
Speaker 1: We'll wait and see after the holidays. What happened? First?
Speaker 1: Before we get going, let's roll the crazy music for
Speaker 1: better no framework possible?
Speaker 2: All right, man?
Speaker 1: What have got? Well, as you know, I do this
Speaker 1: other podcast with Patrick Hines and Duyne Laflotte called Security
Speaker 1: This Week, and we we basically talk about security issues
Speaker 1: but through the lens of current events, with a whole
Speaker 1: bunch of dad jokes thrown in there. So we laugh
Speaker 1: a lot. But you know, you have to sort of
Speaker 1: spice up this content because it's very dull.
Speaker 2: It can be.
Speaker 1: Security can be very dry, and when.
Speaker 2: It's not dull, it's terrifying, right, Like.
Speaker 1: That's sort of your choices, Yeah, yeah, and terrifying it is,
Speaker 1: and so you know, we have to laugh and that's why.
Speaker 1: But anyway, we decided to open a Discord channel and
Speaker 1: it has become very popular. Not only are people asking
Speaker 1: questions and interacting and stuff and giving us suggestions for stories,
Speaker 1: but they're also learning a lot from Attrick and Dwayne,
Speaker 1: Like they're going to be doing sort of training in
Speaker 1: Discord that you couldn't get anywhere else. You know, these
Speaker 1: guys are just like real pros. So I wanted to
Speaker 1: give you the Discord Channel. This being episode nineteen twenty nine.
Speaker 1: If you go to nineteen twenty nine dot pwoppwop dot me,
Speaker 1: that'll bring you to the Discord channel for security this week.
Speaker 1: And you should should you know, if you're interested in security,
Speaker 1: is a good thing to do. It's a good community.
Speaker 2: Absolutely cool man.
Speaker 1: And it being nineteen twenty nine, we can't talk about
Speaker 1: that year without touching on the Wall Street crash.
Speaker 2: Yeah, that was a big one.
Speaker 1: That was a big thing in nineteen twenty nine. What
Speaker 1: was what was your favorite event?
Speaker 2: It was also the first time as Zeppelin flew around
Speaker 2: the world.
Speaker 1: Wow yeah, wow, wow, bad timing. You know.
Speaker 2: I find the titled a machine That'll fly you all
Speaker 2: the way around the world, and then I mean, it's
Speaker 2: not Mark crash was bad. It was a twelve percent drop. Yeah,
Speaker 2: but you know they call that the trigger of the
Speaker 2: Great Depression. Yep, mostly because they had a tough time
Speaker 2: figuring out what to do after that.
Speaker 1: There really wasn't enough money in the system to support
Speaker 1: that kind of drop, right.
Speaker 2: Yep, and it had a little cascading event. Yeah, good fun.
Speaker 2: Nineteen twenty nine.
Speaker 1: Right, good fun. All right, who's talking to us today?
Speaker 2: Richard gradukommadov a show eighteen sixty five, the one we
Speaker 2: did with our friend April back in September of twenty three,
Speaker 2: so a little over a year ago. We were talking
Speaker 2: about Azure and GitHub and our friend Mark wan Sall
Speaker 2: had this comed He said, I always love listening to
Speaker 2: April talking about DevOps, and now the talk is moving
Speaker 2: away from DevOps and towards platform engineering, which might be
Speaker 2: an interesting Donna Rocks Tappen's episode, Oh maybe I do
Speaker 2: definitely do platform engineering on run Ass Radio. A few
Speaker 2: years ago, Spotify donating a tool called Backstage. It's at
Speaker 2: backstage dot io to the Cloud Native Foundation, which builds
Speaker 2: developer portals. So this whole idea of being able to
Speaker 2: divide cloud resources to developers sort of self service with governance.
Speaker 2: While this looks promising from a corporate standards point of view,
Speaker 2: I wonder if the balance of power moves too much
Speaker 2: in favor of option away from developer agility. Always interesting times.
Speaker 2: I don't know mark giving smart Developers don't want administrator
Speaker 2: passwords because then it could be their fault.
Speaker 1: Right.
Speaker 2: The whole point about the portal approach is that if
Speaker 2: you do harm with what you instantiate through the portal,
Speaker 2: that's on the people who organize the portal, not on you.
Speaker 2: You have or should be living within constraints, so you
Speaker 2: know you should push back on what you're capable of
Speaker 2: doing if it's actually an impediment. But creating these sort
Speaker 2: of guard rails so that you control costs, like you
Speaker 2: limit the number of dumb things that happen. They're really important,
Speaker 2: and you know you don't want to find out the
Speaker 2: end of the month the ACCID at least been one
Speaker 2: hundred thousand dollars because you'll let some stuff up forgot
Speaker 2: to turn it off. That shouldn't be possible through these portals.
Speaker 2: So you know, save yourself some pain, use the portal
Speaker 2: and push on it. What does and do the job.
Speaker 2: Good advice, Richer, not that I have strong opinions about
Speaker 2: these things. Yeah, so Mark, thank you so much your
Speaker 2: comment and a copy of music Coby is on its
Speaker 2: way to you, and if you'd like a copy of
Speaker 2: music co buy. I write a comment on the website
Speaker 2: at don at Rocks dot com on the facebooks. We
Speaker 2: publish every show there, and you comment there and everybody
Speaker 2: in the show. We'll send your copy of music go by.
Speaker 1: And you can further contact us on a variety of
Speaker 1: social media platforms other than Facebook. We've both been on
Speaker 1: ex Twitter for a number of years. That's what I'm
Speaker 1: calling it now ex Twitter. It seems like it's everybody's
Speaker 1: ex now used to be Twitter. But we're also on
Speaker 1: Blue Sky of course. I'm Carl Franklin b Sky's Social
Speaker 1: and that's social, and you're Rich Campbell. I'm Rich Campbell
Speaker 1: dot best Guide on Social and also I'm Masdon. I'm
Speaker 1: Carl Franklin at tech cub.
Speaker 2: Dot Social, and I'm Rich Campbell at Master.
Speaker 1: So there you go. So get in touch with us
Speaker 1: one way or another for any reason. But if you
Speaker 1: ask a question or have a comment and Richard reads it,
Speaker 1: we'll send you a copy of music to code buy
Speaker 1: for sure.
Speaker 2: And by the way, I did put out on four
Speaker 2: on the X and the Blue Skies and the Threads
Speaker 2: and the Massodons that I was working on the geek
Speaker 2: outs last weekend. And I guess which one I got
Speaker 2: the most feedback on. I'm thinking Blue Sky is Blue Sky?
Speaker 1: Yeah, yeah, yeah, I'm getting more engagement there than anywhere
Speaker 1: else too.
Speaker 2: I got feedback on all of them, to be honest,
Speaker 2: So I'm very flattered, like that was nice. People love
Speaker 2: the geek out. So I got a long list of
Speaker 2: things you'll when we actually published a meal here, I'm
Speaker 2: going to mention your name if you asked a question.
Speaker 1: Very cool.
Speaker 2: But yeah, the Blue Sky response was swift and thorough excellent.
Speaker 2: All right, So let's bring back to dot net rocks.
Speaker 2: April Yoho.
Speaker 1: So. She is a senior developer advocate and DevOps practicely
Speaker 1: at GitHub, specializing in application transformation and DevOps ways of working.
Speaker 1: Her focus is to take customers on a journey from
Speaker 1: legacy technology to server lists and containers where code comes first,
Speaker 1: while enabling them to take full advantage of DevOps practices.
Speaker 1: In you spare time, April spends time outdoors hiking, skiing,
Speaker 1: or scuba diving. That's where your nickname comes from, that
Speaker 1: you got when you were nine, right, and you're also
Speaker 1: a triathlete competing in iron Man and half iron Man triathlons.
Speaker 1: So if I could sum it up, don't with her,
Speaker 1: She'll kick your ass. Nice Welcome back, April.
Speaker 3: Thank you, Carl. I think that's the best TLDR intro
Speaker 3: I've ever had in my entire life.
Speaker 1: Very cool. Huh ForWords, that's all you need to know,
Speaker 1: right down to it.
Speaker 2: That's too funny. How you doing. You've been adventuring?
Speaker 1: Yeah, how you doing? What's going on?
Speaker 3: I'm good. I've been traveling around the world for work.
Speaker 3: Some pleasure, a little bit of pleasure here and there,
Speaker 3: but mostly just traveling around the world going to customer events,
Speaker 3: first party events. We just had Get up Universe, what
Speaker 3: was that a month and a half ago? Get up
Speaker 3: Constellation in South Africa, Get Up Constellation in India. Yeah,
Speaker 3: it's been busy. And then we just had a night
Speaker 3: was that last week in Chicago? Som hm, it's been
Speaker 3: a busy bee.
Speaker 2: Yeah.
Speaker 1: I got a little story for you. So I'm working
Speaker 1: with a customer and we started out with a big
Speaker 1: GitHub repo and everything's working great, and then they say, yeah,
Speaker 1: we're gonna move over to Azure dev ops and I'm
Speaker 1: like why. They say, well, a lot of our other
Speaker 1: products are over there in the customers and you know,
Speaker 1: and this and that they want them us to move.
Speaker 1: So we're trying to move and it was painful, like, oh,
Speaker 1: I didn't know I could add a new file to
Speaker 1: my project and that, you know, the source control just
Speaker 1: wouldn't pick it up what I added it to the too,
Speaker 1: and I sinked and everything. No, it's just not there.
Speaker 1: And when we had to configure it, like by default,
Speaker 1: you have to configure it so that you can do that.
Speaker 1: So now we're moving all the way back to get hub.
Speaker 1: Screw that. Yeah, I don't know why you would have left.
Speaker 1: I wasn't my decision.
Speaker 3: Well, you know, sometimes we have to learn by our mistakes, Carl,
Speaker 3: we all grow up, right.
Speaker 1: Yeah, yeah, well just to say it wasn't my decision.
Speaker 1: And I'm the one that pushed them towards GitHub in
Speaker 1: the first place, because that's that's my home base.
Speaker 2: Sure, welcome cloth Work.
Speaker 3: Welcome back, Thank you. We love having you on GitHub.
Speaker 1: It's all about the act. Oh, I have plenty of
Speaker 1: reposts on GitHub. It's just through this one customer.
Speaker 3: Yes you do.
Speaker 1: But what's new in GitHub in twenty twenty five?
Speaker 3: What is new? Well, it's been the year of AI.
Speaker 3: You haven't heard. AI is everywhere, absolutely everywhere. So at
Speaker 3: Universe we made quite a few announcements. Do you want
Speaker 3: me to run through them?
Speaker 2: Yeah? Please?
Speaker 1: Sure? Sure?
Speaker 3: So I think I think actually probably the good headline
Speaker 3: of AI. There's a couple things I think are good headlines.
Speaker 3: One is AI is really end to end with you
Speaker 3: on GitHub. Now, we're really building it into the start
Speaker 3: of an issue, even in discussions, into your pull requests,
Speaker 3: before your poll request, even in your IDEs, and then
Speaker 3: all the way through to remediation. So we're really seeing
Speaker 3: a full DevOps life cycle with AI end to end,
Speaker 3: not just with copilot workspace, but copilot chat and having
Speaker 3: get up copilt with you wherever you go. That's been
Speaker 3: pretty cool. The big thing that people have also shouted
Speaker 3: about is having the option of different models. So we've
Speaker 3: done a lot with multi multi modality, multi models. However
Speaker 3: we call it these days, there's a big fancy term.
Speaker 2: Because your original was open AI, right, The.
Speaker 3: Original was open ai and we still have that in place,
Speaker 3: but we've moved away from that to different models. So
Speaker 3: we announced about four or five other models, plus the
Speaker 3: actual GitHub model site as well. So you can choose
Speaker 3: your model, you can play with it, you can have
Speaker 3: a look and go right, what works, what doesn't work,
Speaker 3: how does it respond? And people really want the choice,
Speaker 3: so you can go shopping for models now when you're
Speaker 3: writing your code.
Speaker 2: Right, I'm just surprised that they care. Does it really
Speaker 2: make that much of a difference.
Speaker 3: It does, And you know, it's actually funny you say that.
Speaker 3: I wrote an article for the dot net blog at
Speaker 3: Microsoft several months ago when get hub models got released
Speaker 3: and they're like, yeah, we want to showcase the get
Speaker 3: hub models features and functionality and dot net I said, okay, great,
Speaker 3: it wasn't there so you could do it in c sharp,
Speaker 3: Python or JavaScript, and they did release capability in c
Speaker 3: sharp and yeah, it made a huge difference. And actually,
Speaker 3: if you go into getub copilot now and say what
Speaker 3: is the best model to use for C sharp or
Speaker 3: you know, even testing or whatever, it will give you
Speaker 3: three or four different options. And I've gone into the
Speaker 3: GitHub models playground and started playing with the different models
Speaker 3: and seeing what the outputs are like. It's a ton
Speaker 3: of fun. But yeah, it will definitely differ on type
Speaker 3: of language you're using. If you whether use an infrastructure's code,
Speaker 3: you know, anything C Sharp related or Go Lang, Python,
Speaker 3: et cetera, the models are all different. Do you want
Speaker 3: to use different models for visuals? Visualization? Absolutely?
Speaker 1: One of my favorite features of large language models. It's
Speaker 1: is its ability to remember what we've talked about right,
Speaker 1: well done the context? And I'm wondering if you're if
Speaker 1: you have to switch models for different parts of your application,
Speaker 1: do they share the context or does each of them
Speaker 1: have their own context?
Speaker 3: You know, I haven't because we've just released it and
Speaker 3: a lot of it's in preview. I haven't died deep
Speaker 3: enough to really answer that. So what I've done with
Speaker 3: the models is taken the same task and compared like
Speaker 3: for like's, if I ask it to write x unit
Speaker 3: tests in my C shark code, one model is going
Speaker 3: to differ from another one. Whereas if I say, write
Speaker 3: write some ex unit tests, or if I give another
Speaker 3: model the task of make my C shark code more secure,
Speaker 3: it's going to give you complete different answers. So I
Speaker 3: like doing like for like comparison, same thing. When we
Speaker 3: compare the usability of AI to a human. If it
Speaker 3: takes me five hours to write a unit test, hypothetically,
Speaker 3: how long does it take with copilot five minutes or less?
Speaker 2: You guys are the ones that coin the term copilot.
Speaker 2: Clearly are using it differently. Now, like why are there
Speaker 2: multian I get multiple models because they're between Well, why
Speaker 2: are there multiple copilots? Like you already talked about copilot workspace,
Speaker 2: copilot chat.
Speaker 3: Yeah, so when So let's back this up. So there's
Speaker 3: Getthub copilot, which is the original copilot, and then we
Speaker 3: started increasing features and functionality in it. So with that
Speaker 3: we started, well we being Getthub not me, I have
Speaker 3: nothing to do with branding, started differentiating the types of
Speaker 3: use cases for copilots, so copilot chat because you can
Speaker 3: chat with it, you can have conversation with it in
Speaker 3: your editor, in your ID. Then we started looking at
Speaker 3: copilot workspace, which is an end to end driven thing.
Speaker 3: I have no idea how they name these things, but
Speaker 3: we've basically tacked on another differentiator and copilot in its
Speaker 3: different use cases. And then Microsoft took Copilot and put
Speaker 3: it on everything and rebranded three sixty five recently to
Speaker 3: copilot again.
Speaker 2: Well, sometimes it's three sixty five copilots. Sometimes this copilot
Speaker 2: for three sixty five.
Speaker 3: But yeah, it's let's take this back to the naming
Speaker 3: convention at Microsoft and the marketing folks like you had
Speaker 3: Team Foundation Server you had as your DevOps. Like the
Speaker 3: naming conventions and the branding. I not to comment on.
Speaker 3: It is tough. It's hard. There's a lot of products.
Speaker 1: I get it. I imagine they like hire a new
Speaker 1: executive when they come in the first thing and say, okay,
Speaker 1: we're going to change the names of these things. Who's
Speaker 1: with me?
Speaker 3: He's like, let's change the icons and the names. Let's
Speaker 3: confuse everyone because I like the pictures. I like knowing
Speaker 3: what does the picture look like, what's the icon that
Speaker 3: I'm looking for that day? And then when they change it,
Speaker 3: I'm lost.
Speaker 2: Yeah right, I'm very lost. You can change the nail
Speaker 2: you want, but if you change the icon, we're doomed.
Speaker 3: Yeah, exactly, exactly.
Speaker 2: Name. We're not going to worry about. It's going to
Speaker 2: be fine.
Speaker 1: Okay.
Speaker 2: So I mean that's three different quote unquote co pilots, Right,
Speaker 2: but I guess they just arrive at different places for you.
Speaker 3: Yeah, they have different features and functionality. So the copilot
Speaker 3: chat is the chat in your ID. So whether you're
Speaker 3: in VS code or this is your rubber duck, this
Speaker 3: is your rubber duck one thousand percent, and they're all
Speaker 3: your rubber ducks actually, but this is chat, This is conversational,
Speaker 3: giving it the context and then you know, this is
Speaker 3: what I probably used ninety nine point nine percent of
Speaker 3: my time doing.
Speaker 2: Is is chat.
Speaker 3: So I opened up my ID, I asked them about
Speaker 3: my code base, how to fix my code, Let's fix
Speaker 3: the legacy code. Convert code from c sharp to JavaScript.
Speaker 3: If you're feeling feisty that day, you know, you could
Speaker 3: do whatever you want.
Speaker 2: Yeah, I would have gotten to Ruby on rails, but whatever,
Speaker 2: you know, Okay, you know, to each their own.
Speaker 1: Are you.
Speaker 2: Would have you done with my friend Richard Campbell. I
Speaker 2: just remember that guy sitting in the corner. Whenever we
Speaker 2: were battling on a problem like this, you know, we rails.
Speaker 2: It would have been fine. It's like, yeah, we would
Speaker 2: have gone away for six months and then what that was?
Speaker 2: Ruby Buddha, wasn't it problem?
Speaker 1: Yeah? He was like, ah, I have the answer Ruby
Speaker 1: on rails every problem, every problem is solved.
Speaker 3: Yes, It's kind of like how Kupernetti solves everything, the
Speaker 3: Ruby on rails for code and Kupernettes for everything else.
Speaker 1: Yeah.
Speaker 2: Yeah, you know the best way to know it's not
Speaker 2: a solve problem is just to look at how many
Speaker 2: products have the word Kubernetes in them. A solve problem,
Speaker 2: there'd be one, there's not. There's dozens, so okay.
Speaker 3: More than that now.
Speaker 2: Yeah. But I feel the same way about the copilots,
Speaker 2: like we're still feeling around for the perfect interface. Like
Speaker 2: I appreciate your view on chat. That's just this idea
Speaker 2: of this is where I come in to a project
Speaker 2: I haven't touched in three months, and I start with
Speaker 2: chat saying, okay, what the hell was I thinking? Just
Speaker 2: that it can start presenting some information about this code base.
Speaker 3: And it's there to chats, there to conversation lies. I
Speaker 3: think with the new models as too, it's skewed the
Speaker 3: lines quite a bit. So copilot chat was very much
Speaker 3: iteration and context, and then with the new models you
Speaker 3: can give it full sentences and paragraphs and you can
Speaker 3: go from you know, the slash explain command, the slash test, command,
Speaker 3: slash help to how do I execute this class? And
Speaker 3: oh yeah, and explain it to me in Dutch and
Speaker 3: it will. It's pretty fantastic I have. That's been my
Speaker 3: new party trick is every country I've visited I've used,
Speaker 3: I've spoken to co pilot in whatever native language I'm mean.
Speaker 3: So that's been exciting because you never know how it's
Speaker 3: going to respond, and it's actually been it's been really good.
Speaker 3: It's been spot on.
Speaker 1: You speak Dutch a.
Speaker 3: Little bit, but I'm better in German. And please, let's
Speaker 3: not test. That's the end of my day to day.
Speaker 3: My brain cells stopped working.
Speaker 2: Yeah, that's not nice.
Speaker 3: That's that's not nice. I think Richard's seen me or
Speaker 3: heard me speak Dutch before in our life potentially.
Speaker 1: Yeah, what we've been out and about what's Dutch for? Beer?
Speaker 3: Beera via Germans, beer, Dutches, beak. The hard languages to
Speaker 3: learn at the same time because they sound similar but
Speaker 3: are pronounce.
Speaker 1: It's usually where you start though, right, because beer, beer,
Speaker 1: donka whiskey. Yeah, all right, now that I've completely derailed
Speaker 1: the conversation, let's get back to give up nice.
Speaker 2: Now it's co pilot chat, really for studio code or
Speaker 2: studio or does that matter?
Speaker 3: So all the new features are coming out Visual Studio Code.
Speaker 3: Why it is the flagship product at Microsoft and the
Speaker 3: vs CO team is hot on this, and it's also
Speaker 3: the most widely used ID. Now for all the dot
Speaker 3: net community, They're going to say, well, what about us
Speaker 3: in Visual Studio there is development in there.
Speaker 2: Yeah, I'm gonna grab onto that hole. Did you just
Speaker 2: call Visual Studio Code the code editor and ID?
Speaker 1: Is that what she said?
Speaker 3: I don't know what she said, probably maybe yeah.
Speaker 1: And also the flagship ID. So I thought flagship didn't
Speaker 1: mean most popular but original or large, largest or whatever.
Speaker 3: Can we totally erase all that?
Speaker 1: And started, No, no, no, that's all right. You know,
Speaker 1: you know what we could define flagship is the biggest
Speaker 1: on disc. You know that it is Visual Studio.
Speaker 3: It's it's definitely our leader in ID technologies out in
Speaker 3: the world, and the vs COD team is hot on it.
Speaker 3: They're very good at developing the extension. So the Visual
Speaker 3: Studio team develops a lot of the extensions for Visual
Speaker 3: Studio and then for Intelligay and all of those products.
Speaker 3: Those guys, those folks are responsible for the engineering behind
Speaker 3: that so we give them access to the APIs to
Speaker 3: do what they need to do, but it's on them
Speaker 3: to develop. But yeah, vscode is one of the most
Speaker 3: popular IDs, and it's open source, so there's lots of
Speaker 3: great things to say about it. But yes, you get
Speaker 3: every dot net developer that's like, well, what about visual Studio,
Speaker 3: and I'm like, it's there. I'll be honest, I haven't
Speaker 3: done the demo in visual Studio in a while. It's
Speaker 3: been a long time. It's a heavyweight application on my machine,
Speaker 3: and most of the time I'm using a get Hub
Speaker 3: code space, which is vs code in the cloud, in
Speaker 3: the secure environment.
Speaker 2: So selfishly, yeah, yeah, no, I don't know how many
Speaker 2: new users coming to visual Studio, but I know there's
Speaker 2: a lot of existing users in the visual Studio space.
Speaker 2: And it's this is a recognition that it's as much
Speaker 2: a project management tool as it is also a coding environment,
Speaker 2: and and so you know, you don't move away from
Speaker 2: it easily, certainly, but I do seem to live in
Speaker 2: both certain projects I function in studio and other projects
Speaker 2: I function in code.
Speaker 3: Absolutely. I think anyone that's working in visual Studio is
Speaker 3: crossing oader vs Code a lot, but it's you know,
Speaker 3: it's it's VS code is an enabler for anyone that
Speaker 3: is still learning to code. You have to think of
Speaker 3: it as you know, you have university students, they're all
Speaker 3: most of the university kids are learning Python. The kids
Speaker 3: they're adults, but most kids in school, eight nine, ten
Speaker 3: year olds are learning Python. People learning Python for research
Speaker 3: and data in school. So VS code is a great
Speaker 3: enabler as an ID. And I still have customers that
Speaker 3: don't use anything other than Notepad plus plus and I
Speaker 3: only want to start that argument.
Speaker 2: But too many features in Visual Studio code apparently, well.
Speaker 3: It's not enterprise level apparently, is what they've said.
Speaker 2: And no Pad plus plus is.
Speaker 3: Yes, that was a great That was a great argument
Speaker 3: we had with their security team. When you know, you
Speaker 3: want to talk about developer productivity, don't let them use
Speaker 3: NOE pad plus plus. They just didn't want to take
Speaker 3: the time to procure and go through that process of
Speaker 3: vetting the product. And a free product, yes, and if
Speaker 3: it yeah, that's yes.
Speaker 1: Yes, I don't think money was the issue there. No,
Speaker 1: it was not money.
Speaker 2: The learning curve, yes, such as that actually is. But
Speaker 2: in reality, of course, is that chat shows up in
Speaker 2: either place. There's plugins for both. Like wherever you work,
Speaker 2: these tools are going to come to you yes and
Speaker 2: again conversations about code, which is really interesting because half
Speaker 2: the time we're still formulating what the heck we're thinking
Speaker 2: about our code, and just to rubber duck, it helps.
Speaker 3: It is and the single paint of glass experience that
Speaker 3: you get in Visual Studio code is hands down my
Speaker 3: favorite experience. And when I say single paint of glass experience,
Speaker 3: when you start using the other GitHub extensions like poor
Speaker 3: requests and actions, you can see all of your automation.
Speaker 3: With a poor request, you can use the code review
Speaker 3: feature that we've just released at Universe, so it's part
Speaker 3: of copilot. Before you even stage your changes in your ID,
Speaker 3: you can use code review with copilot. So is that
Speaker 3: is one hundred percent of rubberduct scenario, or your junior
Speaker 3: developer want to understand how to write better code, or
Speaker 3: you're like me, I live and work somewhere separate from
Speaker 3: the rest of my team, so I'm working my morning
Speaker 3: time nine am ten am. I can check my own
Speaker 3: poor request with co Pilot, and then you can also
Speaker 3: check it on stage changes, and then you can do
Speaker 3: a code review once you've submitted your poor request. So
Speaker 3: there's kind of three different places. Well, i'd say too,
Speaker 3: before the poor request and then after the poor request,
Speaker 3: and that helps improve code quality massively.
Speaker 1: Great.
Speaker 2: Now, I mean it's still traditional code reviews too, but
Speaker 2: this sounds like the code review I do before sitting
Speaker 2: with a senior to go through a review, just get
Speaker 2: yourself into shape.
Speaker 3: Yeah, and I think it's also a great way to
Speaker 3: just check yourself because so often and we're rushed, we
Speaker 3: are frustrated, or it's again it's a context switch. You
Speaker 3: get pulled out of your ID into a meeting, or
Speaker 3: somebody taps on your shoulder, or the dog needs to
Speaker 3: go out, or you have screaming kids at home, or
Speaker 3: whatever the scenario is. You get stopped from whatever it
Speaker 3: is you're doing. You lose your flow, and then you know,
Speaker 3: you scape your code and honestly code that you're talking about.
Speaker 3: Any kind of repoll you pulled up three months ago,
Speaker 3: Why did I write something the way I did three
Speaker 3: months ago? Yeah, no idea, no clue, not sure what
Speaker 3: my brain cells were thinking at that time. So the
Speaker 3: ability to review what I did before I submitted is great.
Speaker 3: Also helps me from making just stupid, silly mistakes. The
Speaker 3: humans are the problems, right, Yeah, we like to put
Speaker 3: passwords in places that shouldn't be there, and we like
Speaker 3: to push buttons and misspell things and do.
Speaker 2: Silly things, and so the review might catch a few
Speaker 2: more of those.
Speaker 3: It has caught all of mine today.
Speaker 1: Well, the name co pilot really applies to that, because
Speaker 1: that is like having someone looking over your shoulder and yeah,
Speaker 1: you know, before you commit this, you might want to
Speaker 1: look at these little issues here. Yeah. I like that.
Speaker 2: Now, that's separate from the tool that helps write the
Speaker 2: pr right, that actually summarizes the poll requests and stuff like.
Speaker 1: That's.
Speaker 3: Yes, it's still part of the copilot licensing, but it's
Speaker 3: a separate, different step in in the development process.
Speaker 2: Right, But I just appreciate it writes far better polar
Speaker 2: request statements than I do.
Speaker 3: Oh absolutely well. It actually lists out the files for you. Yeah,
Speaker 3: it lists out the files, references them, and summarizes them.
Speaker 3: And you know, often I'll put up a pull request
Speaker 3: out of sheer frustration, be like, please, God work, you know,
Speaker 3: it's it's pretty ugly. My commits are really ugly sometimes.
Speaker 3: But you're rush, You're frustrated. It's your like eightieth attempt
Speaker 3: at getting this thing to work.
Speaker 1: I got to admit I've put in commits with the
Speaker 1: comment was fixed a few things that didn't work before.
Speaker 2: Yeah, oh great, and then I finally find in this
Speaker 2: four of those in a row, follows by half af
Speaker 2: ass right like yes, yes, yeah, help help by doom right,
Speaker 2: tried this again. I think the big one is you're
Speaker 2: often you're flailing around with a problem and you're just hack.
Speaker 2: You know, your your fence posting, your hacking it cod
Speaker 2: in different places. And one of the things I like
Speaker 2: about that summarizer is it shows me all those like
Speaker 2: why is there a file change in that file? Oh right, yeah,
Speaker 2: when I was flailing at that thing, maybe that change shouldn't.
Speaker 3: Stay revert revert revert. And you know, it's also things
Speaker 3: like we talked about DevOps right, and you know what's
Speaker 3: the phrase, gosh, I wish my brain sales would work tonight.
Speaker 3: Short lived feature branches right, commit early and often. Yeah,
Speaker 3: and that's a good way to make sure you're committing
Speaker 3: the right size pull request for your features.
Speaker 2: Yeah, don't stay over in that branch too long. Short
Speaker 2: lived branch like, don't also, just.
Speaker 1: Right, I'm working with another developer on this project, and
Speaker 1: he's working in a totally different space than I'm working
Speaker 1: on and you know, we don't branch. We just you know,
Speaker 1: haven't needed to, haven't needed to, and if you don't
Speaker 1: need to, don't.
Speaker 3: Yeah, I disagree with you, Carl, because what if you
Speaker 3: screw something up, You're screwing up your your single source
Speaker 3: of truth.
Speaker 1: Well yeah, well I just roll back for that. You are,
Speaker 1: if I screw something up.
Speaker 3: Then it won't build your buddy.
Speaker 1: But right, but I'm working on my code, he's working
Speaker 1: on his, and we don't overlap. So if I screw
Speaker 1: up my code and if I break the build, I'm
Speaker 1: a jerk.
Speaker 3: But but what if you bring in a third person?
Speaker 2: Yeah, the real problem is when you roll back, and
Speaker 2: so you got to push back his work. Yeah, yes,
Speaker 2: but then he can haven't had to do that.
Speaker 1: But you know what, though, it's a very probably a rare,
Speaker 1: more rare scenario the way I'm working with this particular
Speaker 1: you're hit the magic number two. Yeah. Any more than
Speaker 1: that we would have to be branching and merging probably, definitely.
Speaker 2: It's all a question of chance of collision.
Speaker 1: We also you know, text each other, right, So if
Speaker 1: he's going to make a change, he says, hey, I'm
Speaker 1: I'm going to make a change. Just have him out
Speaker 1: for an hour. Okay, no problem. So so we avoid
Speaker 1: we avoid merged conflicts like.
Speaker 2: The plague nice.
Speaker 3: You know, there's a great gitub feature for that, merge
Speaker 3: Cues's say, I'm sure how to avoid a merge bomb?
Speaker 3: Use a mergeque.
Speaker 1: Well, you know, an SMS is working just fine for
Speaker 1: the two of us. Just one kind of mergequeue.
Speaker 3: Yes, yes, have you ever been on a merge train?
Speaker 1: Yeah? I took one to New Jersey once from and.
Speaker 3: So this is this is before my GitHub days. And
Speaker 3: actually in getthub you can use the mergeque feature and
Speaker 3: a lot of our customers absolutely love it because they're like,
Speaker 3: you get merge bombs all the time, how do we
Speaker 3: prevent it? Yeah, look at merge cues. I'm like, oh,
Speaker 3: this is great. I was actually working in Azure dev
Speaker 3: ops on a customer project and we were on a
Speaker 3: mission as a team to close as many prs as possible,
Speaker 3: and we had some merge bomb issues. So we put
Speaker 3: an a merged train in Azure DevOps and it was
Speaker 3: probably the most fun slash hysterical slash frustrating moment of
Speaker 3: poll requests going through at once. But yeah, merge bombs
Speaker 3: are no fun.
Speaker 1: So tell me about merged cues.
Speaker 3: Well, I think I just summed to that you can
Speaker 3: set it up so that being said, with policy and so.
Speaker 1: Basically multiple merges can happen in the right order.
Speaker 3: Correct, you can or you can prioritize them. Pretty fancy stuff, isn't.
Speaker 2: There also ability to sort of detect this might be
Speaker 2: a collision here, so let's pull it off onto a
Speaker 2: branch like So just a way to like branching policies.
Speaker 3: Yeah, yeah, that's another feature for carl.
Speaker 1: You know, when I get into my next project that
Speaker 1: has more than two developers, I would be definitely using
Speaker 1: this stuff.
Speaker 3: Well you know, it's so I'm gonna something that might
Speaker 3: rock the boat with people that are out there listening.
Speaker 3: And I'm going to say this to you, Carla's my
Speaker 3: friendly sage advice for my many years doing demos. When
Speaker 3: when we as business as tech professionals are doing a demo,
Speaker 3: we should always use best practice. Here's why, because someone
Speaker 3: in the audience will do exactly as we did and
Speaker 3: it'll be simple, and that's why we like teaper demo simple,
Speaker 3: and they will pick up that bad habit. And so
Speaker 3: often I've been with someone in the industry it's like, oh,
Speaker 3: this is just a demo, it doesn't matter. Like well,
Speaker 3: people are learning from us, it does matter. And I
Speaker 3: was working on a very simple it was literally a
Speaker 3: vanilla website. It was for Microsoft, and someone had put
Speaker 3: a YAMO file at the They exposed the yamo file
Speaker 3: externally and they're like, yeah, can you not put this
Speaker 3: in your blog? And I'm like, so I didn't. I
Speaker 3: had to like kindly call out best practices about calling
Speaker 3: out that team or that person. But it's those things
Speaker 3: that are super critical when we're doing demos. Always use
Speaker 3: best practices because someone to greed up on that, or
Speaker 3: someone will go, oh, wow, what's emerge cue or wow,
Speaker 3: what kind of policies can be put in place? Because
Speaker 3: a two person projects quickly becomes a three person ten
Speaker 3: person and using the and then you know even better,
Speaker 3: template all your reposts so you don't have to think
Speaker 3: about this. You can figure it, create a template so
Speaker 3: every repository has all the best practices built in, and
Speaker 3: then you can do better. And then you're showing people
Speaker 3: to do better and you're making a difference.
Speaker 2: In this world.
Speaker 3: I totally agree, one pull request at a time.
Speaker 1: Yes, where should break? Yeah, let's take a break. We'll
Speaker 1: be right back after these very important messages. And as
Speaker 1: a reminder, if you don't want to hear these messages,
Speaker 1: you can get an ad free feed by becoming a
Speaker 1: patron and Patreon dot dot and Rocks dot com. It's
Speaker 1: only five bucks a month. We'll be right back, and
Speaker 1: we're back. It's dotting at Rocks. I'm Carl Franklin, Averagar
Speaker 1: Cambell and that's April Yoho, and we're talking GitHub and
Speaker 1: went down a little rabbit hole about best practices and
Speaker 1: shame on you if you're not using him.
Speaker 2: Should we talk about GitHub Spark because that was another
Speaker 2: one of the announcements out of Universe this year. Right,
Speaker 2: this is cool.
Speaker 3: You should talk about Spark. Spark is awesome. I did
Speaker 3: a session yesterday for getub Winterfest and I was showing
Speaker 3: off the new stuff we announced at Universe, and I
Speaker 3: was like, oh, I'll build something with Spark. So Spark
Speaker 3: is very simply when you go to it now, it's
Speaker 3: in previews, you explain what you want to do, and again,
Speaker 3: giving the AI as much context as possible is ideal.
Speaker 3: So I actually built two apps without writing one bit
Speaker 3: of code. So the first app, I wanted to build
Speaker 3: a pac Man game, and I told it what colors
Speaker 3: I want to use, how many levels I wanted to have,
Speaker 3: and then it spat out something that kind of almost
Speaker 3: vaguely looked like a pac Man game. I could iterate it,
Speaker 3: and then it spat out a different version and it
Speaker 3: was much better. I built another app that just gave
Speaker 3: me a dashboard of my metrics on GitHub, so actions usage,
Speaker 3: copilot usage, and it was really simple. But I just
Speaker 3: told it what I wanted in a paragraph with some detail,
Speaker 3: and it's spat it out in a couple of minutes.
Speaker 3: So it's given people that are non developers the ability
Speaker 3: to write applications.
Speaker 2: Is HUE mean, none of the hood. It's writing code, right,
Speaker 2: So I mean, do you have access to that code
Speaker 2: if you want to learn you know.
Speaker 3: Funnily enough, I haven't played that far into it yet,
Speaker 3: but you could. It's it's pretty much on the surface
Speaker 3: at the moment. So the aim is you're not a
Speaker 3: developer or you're not very technical, you could be a teacher,
Speaker 3: or you could be in business somewhere and you need
Speaker 3: to do a thing and you want a dashboard. Spark
Speaker 3: will build it for you. Look get into repositories. It
Speaker 3: is really meant to be I'm not a coding type
Speaker 3: programmer and i need to do a thing, and it's
Speaker 3: pretty cool like that. That's good.
Speaker 2: So it's a no code solution exactly.
Speaker 3: It goes beyond power apps, beyond low code. It is
Speaker 3: no code. I haven't actually looked to see if you
Speaker 3: can see the source code. I think you can. I
Speaker 3: think you can modify it. I think. However, because I'm
Speaker 3: on preview access, I don't want to. I don't know
Speaker 3: it right the early days, I'm literally just playing with
Speaker 3: it and just learning how to give it the context
Speaker 3: and give it that example of what I want, and
Speaker 3: then I go to iterate it and yeah, it's just
Speaker 3: fun to spit out games and build stuff without writing
Speaker 3: any code, just to see what would happen.
Speaker 2: Yeah, writing better prompts. And somehow it's sort of evolved
Speaker 2: with gethub models as well. I don't know that we've
Speaker 2: talked about gethub models at all.
Speaker 3: It is a little bit tied into gehub Models. We
Speaker 3: haven't gone too far into that publicly in terms of
Speaker 3: what we're doing that get hub Models, let's call it
Speaker 3: a different aspect at the moment. So it is using
Speaker 3: some model selection on the back end, so you do
Speaker 3: get to choose your different models, but it's still really
Speaker 3: really limited early doors. Whereas gethub Models gives you and
Speaker 3: I want to say, thirty models to play with and
Speaker 3: you can compare them. And that's a very very different
Speaker 3: scenario because you can ask it programming questions. You can
Speaker 3: ask it for almost any technical question, or you can
Speaker 3: give it some code and it will process it and
Speaker 3: you compare two different models next to each other. So,
Speaker 3: like I was talking about the dot net reference earlier,
Speaker 3: it didn't support dot net initially. It does now, and
Speaker 3: that is definitely a lot more of a technical solution
Speaker 3: because you can hook into the API and get access
Speaker 3: and have secure area to play with it, whereas Spark
Speaker 3: is very much like you're using plain English or plain
Speaker 3: language to tell the model what you want and it
Speaker 3: will build it for you.
Speaker 2: Okay to me. So get up Models female almost feels
Speaker 2: like AI studio, and that sends that this is a
Speaker 2: place to build generative apps. Spark leans on Models for
Speaker 2: some of that language part, but it's generating different code there.
Speaker 2: Models is interesting under its own. I think it's more
Speaker 2: mature than Spark. Spark is kind of brand new.
Speaker 3: Spark is absolutely brand new. Models has been out for
Speaker 3: several months, and it's more language based, so you can
Speaker 3: customize it to the language you work with. Where's Spark is?
Speaker 3: You know the two things.
Speaker 2: I'd pretty much under that.
Speaker 3: It's all under the hood. You know, I could probably
Speaker 3: pull up what I built yesterday and have a look
Speaker 3: at I haven't. I just wanted to show I've used
Speaker 3: plain English and built a thing. I didn't get into
Speaker 3: the details yet, and I haven't, to be honest, I
Speaker 3: haven't really had a chance to play with Spark enough.
Speaker 2: It's only been a month.
Speaker 3: It's only been a month, and you know, so only
Speaker 3: so many hours in the day, and so we need
Speaker 3: choice to play.
Speaker 2: With well, and it's one thing to make a pack
Speaker 2: band game. How does it do with forms over data?
Speaker 1: Right?
Speaker 2: Like just whipping out a quick It pulled.
Speaker 3: Some of the data for my repo out and gave
Speaker 3: me a little dashboard and I say a little dashboard.
Speaker 3: It was It was nice. It gave me some basic
Speaker 3: metrics and it was pretty cool, but I want to
Speaker 3: actually play with it and get more of a deep
Speaker 3: dive into it. I just need I think that's what
Speaker 3: Christmas is going to be for for me. I play
Speaker 3: your spark a lot.
Speaker 2: More GitHub sweaters and gethub models.
Speaker 1: You Yes, that's my sweater is awesome. Yeah. If you
Speaker 1: don't know what, thank you.
Speaker 3: It's the latest from you know, you know.
Speaker 1: We're talking about. Go see April's bio on the dot
Speaker 1: net rocks website and there's a picture we're in the
Speaker 1: GitHub sweater.
Speaker 2: Christmas sweater. All right, we have AI just nod out
Speaker 2: of this conversation. Are there other aspects that have been
Speaker 2: evolving at getthub? I mean, once upon a time it
Speaker 2: was about source control? Hotel still does that.
Speaker 3: Actually, there's there's two things that I'm excited about. I
Speaker 3: think the biggest thing, and I would say it's probably
Speaker 3: bigger than AI in a lot of ways, is we've
Speaker 3: just released data residency for the EU. That that's a
Speaker 3: huge one. We have more regions that are going to
Speaker 3: be coming down the pipeline at some point, but the
Speaker 3: EU has been the most highly requested region to get
Speaker 3: data residency one EU law. Second, here in the UK
Speaker 3: we have Brexit issues, so I like to call them.
Speaker 3: So data residency is a hot topic for US, which
Speaker 3: has prevented a lot of people from consuming gethub just
Speaker 3: because we're what EU contracts are really specific around data residency,
Speaker 3: so it's it's very much a data protected environment and
Speaker 3: it brings in the authentication and EMU process for end
Speaker 3: user access into that, so it's it's given people what
Speaker 3: they've wanted. So that's a pretty big step for US.
Speaker 2: And with more regions coming. And when you say EU,
Speaker 2: is that mean, I'm guessing it's like the Asia Azure
Speaker 2: data center in Ireland just as a guess.
Speaker 3: Yeah, it'll be Europe, so it will cover off. I
Speaker 3: don't know how they've actually well I kind of know
Speaker 3: how they've carved up the data. But the Amsterdam region,
Speaker 3: which is Europe West, is the primary data center region
Speaker 3: in Azure, and then North Europe is Dublin. It's a
Speaker 3: secondary one technically, right, but those are the two major ones.
Speaker 3: And then there are other countries that have data centers
Speaker 3: in Azure, but the primary Europe regions are Europe West
Speaker 3: in Europe.
Speaker 2: So far, yeah, I know, I know that Microsoft went
Speaker 2: to the trouble abuilding the Germany a specific one for them, France.
Speaker 3: And Switzerland even though, but Switzerland's literally Switzerland on their own.
Speaker 3: The UK has their own, but yeah, it's a lot
Speaker 3: of the countries are getting their own data centers just
Speaker 3: because of residency.
Speaker 2: Anything to you know, keep the customers happy, you need.
Speaker 3: To do absolutely absolutely. I know that in the UK
Speaker 3: they've invested millions and millions of pounds to skill up
Speaker 3: the tech industry here in the UK, and they're doing
Speaker 3: something similar in the other countries where they put in
Speaker 3: data centers. There's also a major AI skilling initiative. So
Speaker 3: the EU data residency thing is a hot topic for
Speaker 3: us and for us to release that, that's great. That
Speaker 3: will just keep evolving over time. And the other thing
Speaker 3: I've really enjoyed that we released our actions performance metrics.
Speaker 3: So as a DevOps person, we like observability, we like
Speaker 3: knowing how to improve things for the next cycle. So
Speaker 3: it's great, we build a thing, but how is it impacting?
Speaker 3: Is it being utilized? Are we you know? Are we
Speaker 3: you know Carl likes to break his build with his
Speaker 3: buddy over there, But how much compute is I mean, yeah,
Speaker 3: we all break builds.
Speaker 1: There we go.
Speaker 3: I'm just picking on Carl today. It's been a while,
Speaker 3: so I thought i'd pick on him. But seriously, like,
Speaker 3: if Karl's working on this project with his friend, how
Speaker 3: much consumption using in GitHub actions are they?
Speaker 1: You know?
Speaker 3: And often when we are using CICD to deploy things,
Speaker 3: we have very inefficient pipelines, Our tests are running too long,
Speaker 3: or stuff is just you know, if his buddy has
Speaker 3: to wait an hour for the pipeline to run, why
Speaker 3: can we get that down to twenty minutes fifteen minutes?
Speaker 3: So the action's performance measures.
Speaker 2: Yeah, analyzing that stuff is a nuisance, right, It's not
Speaker 2: like it is doable, but it is kind of go
Speaker 2: to a log, show what step it was on and
Speaker 2: how long it's spent. It like you've got to do
Speaker 2: a lot of mining to find that where were we
Speaker 2: spending our time?
Speaker 3: Well you did, and actually the new performance metrics makes
Speaker 3: it easier. So it gives you a dashboard, gives you
Speaker 3: some high level metrics, and then you can sift through
Speaker 3: the data and go, right, well, this one's taking an
Speaker 3: hour to run. What's our runtime over? You know an hour?
Speaker 3: Carl and his and his buddy can go look at
Speaker 3: that data and then drill into it, so it's a
Speaker 3: lot more apparent from the surface from the ten thousand
Speaker 3: foot view.
Speaker 2: Well, I noticed you blame testing right off the bat,
Speaker 2: so that's fair.
Speaker 3: Testing does take a while sometimes you know it's worth it.
Speaker 2: But I'm with you, and definitely it was one of
Speaker 2: the things I put a lot of energy into, you know,
Speaker 2: splitting a set of web tests across multiple instances so
Speaker 2: they ran simultaneously to shorten that cycle down. But it's
Speaker 2: not and that's not trivial to do, but you know,
Speaker 2: you only do it when we were at a point
Speaker 2: where it's like it was a weekend and we wanted
Speaker 2: to get it down to fifteen minutes, and we got
Speaker 2: it down to the idea was you had enough time
Speaker 2: to go and get a coffee and by the time
Speaker 2: you got back all of yours right, yeah, well so
Speaker 2: that your head was still in the game, right, like
Speaker 2: you hadn't started on something else. That's you got the
Speaker 2: feedback or delay.
Speaker 1: The rest of the big theme in our discussions is
Speaker 1: you know, if you if the time between you know,
Speaker 1: builds or or whatever it is, c ICD publishing is
Speaker 1: too long you you're thinking about something else and you've
Speaker 1: moved on.
Speaker 2: Yeah, and you know the classic one literally was this
Speaker 2: is strangely but it was a weekend. It's like you
Speaker 2: did the push on Friday. On Monday, I got the
Speaker 2: report and you could get it to anybody because you
Speaker 2: had no clue. Like at that point it didn't matter.
Speaker 2: Anybody had to pick it up again. But yeah, getting
Speaker 2: it down to fifteen minutes with that sort of magic number,
Speaker 2: but it meant harnessing a lot of hardware. You know,
Speaker 2: the productivity went through the roof because people didn't get
Speaker 2: off the thread. You very quar The remediations were really
Speaker 2: fast when it was that short. It paid for itself
Speaker 2: pretty fast.
Speaker 3: Absolutely, And I think as we see customers consuming a
Speaker 3: lot of actions and if you automate the life out
Speaker 3: of your repository, and not just with CICD, but you know,
Speaker 3: when you open up an issue kicks off a bunch
Speaker 3: of actions, et cetera, and tasks and automation, you have
Speaker 3: to be efficient with how you utilize them. Otherwise you're
Speaker 3: not saving any time. And yeah, you do, you do
Speaker 3: increase your billy. So with any process, observability and reporting
Speaker 3: is crucial, but it's such a pain in the butt. However,
Speaker 3: the new performance metrics feature is really cool. So I'm
Speaker 3: biased because I love actions, but it's cool feature. So yeah,
Speaker 3: that's those are those are the most notable things. There's
Speaker 3: been other things around enterprise capability as well. Huge push
Speaker 3: on enterprise, so not just source control anymore.
Speaker 2: Because you don't think of gethub as enterprise product, right,
Speaker 2: It's always been that scrappy upstart that's sort of a
Speaker 2: happy place for open source to live. But let's face it,
Speaker 2: nights because a few enterprises that use GitHub these days.
Speaker 2: One of them Nay, Microsoft, Yes, they.
Speaker 3: Well they don't all eat well, they're not entirely on guble.
Speaker 3: They still use Azure develops a bit, but we won't.
Speaker 1: Oh sure, yeah, but is gethub running an Azure?
Speaker 3: Is Gethub running an Azure? Well we have runners in Azure,
Speaker 3: code spaces sits in Azure. But no, we have stuff
Speaker 3: in different places. I'm pretty sure we have that documented somewhere.
Speaker 3: So I entirely an Azure.
Speaker 2: Sure it's more complicated than that.
Speaker 3: Yeah, that's above my pay grade.
Speaker 2: What is the explanation for enterprise cloud?
Speaker 3: What is that? What do you mean the explanation like
Speaker 3: why we have it?
Speaker 1: Explain yourselves? What is it?
Speaker 2: I think I'm thinking a lot of folks that listen
Speaker 2: to the show have been using gihub in a very
Speaker 2: traditional way, the way that it has always been, and
Speaker 2: maybe haven't been and maybe it's throughout their organization now,
Speaker 2: but again it's kind of piecemeal. Does Enterprise Cloud kind
Speaker 2: of organize things for them? Does it lift that up?
Speaker 2: Give us a little more governance?
Speaker 3: It gives us a lot of governance. There is quite
Speaker 3: a bit of governments built into the platform. I think
Speaker 3: the one thing you have to think about when using GitHub,
Speaker 3: if you've been using azur DevOps or get lab, you
Speaker 3: can't always think of where you've come from. So often
Speaker 3: I'll work with people like, yeah, we came from get
Speaker 3: lab and I can't find how to do X. So
Speaker 3: often it's there, just in a very different place, in
Speaker 3: a different way. And that was a big change I
Speaker 3: had to make when I was working purely with az
Speaker 3: your DevOps was how to do things a little differently.
Speaker 3: But yeah, we have a huge push on governance and
Speaker 3: we want our customers to scale, whether they're startups or
Speaker 3: large enterprises, and there's a huge amount of time and effort.
Speaker 3: And that's where the EU Data residency came in because
Speaker 3: our enterprise customers are screaming for it. You know, I
Speaker 3: don't have the existing stat but at one point they're
Speaker 3: over seventy thousand enterprise customers using GitHub. That was probably
Speaker 3: a year, year and a half ago, so it's probably
Speaker 3: more now eighty ninety thousand or one hundred thousand or
Speaker 3: some insane number. But you know, enterprises also help drive features,
Speaker 3: We'll be honest, that help open source projects and help
Speaker 3: community projects, right because you know, enterprises can help, you know,
Speaker 3: put in the requests and they utilize it, and sometimes
Speaker 3: there are biggest users of the new features as well
Speaker 3: to give feedback.
Speaker 2: Yeah, help push you guys forward too. And you know,
Speaker 2: we've had an ongoing conversation here about enterprises playing well
Speaker 2: in the open source community. I still feel like it's
Speaker 2: too hard for an enterprise to even know what open
Speaker 2: source libraries they're dependent on and how dependent they are
Speaker 2: on them. I spent enough time with CFOs and I've
Speaker 2: always resisted being one to know they would write a
Speaker 2: check a year for this stuff, just spend it.
Speaker 1: Well.
Speaker 2: What they don't want to do is have one hundred
Speaker 2: requests or a thousand requests to support different projects that
Speaker 2: they're not interested in that And I've never seen a
Speaker 2: dashboard at an enterprise level that said, given we allocated
Speaker 2: ten thousand dollars for this, what projects should we spend?
Speaker 1: S Bomb dependency graphs?
Speaker 2: Yeah, yeah, I mean it's I still feel like the
Speaker 2: ass bomb.
Speaker 1: You need a graph. You need to see the better
Speaker 1: right as bombs cloud or something.
Speaker 2: Yeah, well on graph just from a security perspective of, Hey,
Speaker 2: this project's got to meet you know this owens. Our
Speaker 2: project's got a major exploit in it? How many of
Speaker 2: our apps used that?
Speaker 3: Like?
Speaker 2: That's not It's still not an easy question to answer.
Speaker 1: But it's screaming for an AI solution, isn't it?
Speaker 2: Well?
Speaker 3: You know, funnily enough, we have a solution for that
Speaker 3: that courtse we do, right, But no, we do have
Speaker 3: dependent on in one of our security features of GitHub
Speaker 3: Advanced Security, and it does scan all the dependencies in
Speaker 3: your repository and gives you report opens a poor request
Speaker 3: and gives you a suggestive fix and gives you the
Speaker 3: information because managing those things is terrible. I have worked
Speaker 3: with a lot of customers that use the s bomb
Speaker 3: feature to export and know what they're consuming, how they're
Speaker 3: consuming it, and they've made it part of their development
Speaker 3: cycle to remediate now and it's easier and less time
Speaker 3: consuming to remediate those dependencies.
Speaker 2: Right.
Speaker 3: And there are some great customers consuming I mean most
Speaker 3: customers are consuming open source. I have not spoken to
Speaker 3: one enterprise customer that does not consume any form of
Speaker 3: open source.
Speaker 2: If you're not consuming open source, you're lying to yourself
Speaker 2: like it's there, you're just not paying attention to it.
Speaker 2: But I'm getting putting the enterprise architect hat on where Okay,
Speaker 2: we have a dependency on this library. We don't know
Speaker 2: exactly how many projects use it, Like we're going to
Speaker 2: figure out a way to fix this and then want
Speaker 2: to propagate it across all of them, like I need
Speaker 2: that macroscopic view. I've hung out with enough of these
Speaker 2: folks to know they've got a thousand apps and they're like, okay,
Speaker 2: give me the landscape. How many of these have this
Speaker 2: dependency and how are they different? Can we roll them
Speaker 2: across all of them quickly? We don't have to light
Speaker 2: each team up. You know half those apps have no
Speaker 2: team anymore.
Speaker 3: Yeah, very true, very true.
Speaker 2: You know, how do we rehabilitate all that. So I'm
Speaker 2: hoping that that there is that higher level view like
Speaker 2: I get. I look at dependent on a project by
Speaker 2: project basis, and it does a good job from.
Speaker 3: The from the enterprise management side, there's a huge there's
Speaker 3: a way to export the s BAWM mount from the
Speaker 3: organization side. So if you haven't managed at your organizational level,
Speaker 3: you can pull that s BAM out and get that
Speaker 3: reporting out if you want. And actually another good way
Speaker 3: to do it at the organizational level is export out
Speaker 3: to a dashboard which you can get within githup. But
Speaker 3: I have a lot of people doing it through power BI.
Speaker 3: So if you have good data skills there you.
Speaker 2: Go all right, so you just export it out do
Speaker 2: your own analysis.
Speaker 3: Yeah, yeah, if you want to.
Speaker 2: Yeah, no, it's a solution.
Speaker 3: And then but we do have we do have some dashboards,
Speaker 3: we do have some dashbouds.
Speaker 2: But then it's and then it's to put you. Of course,
Speaker 2: you'd know if you had a high dependency in this,
Speaker 2: because every project would line up with depend about it
Speaker 2: once exactly.
Speaker 3: It's like a Christmas street. It's literally red, yellow, green.
Speaker 2: Yeah, big explosion of red all over the place.
Speaker 3: Exactly exactly, well, at least it's Christmas.
Speaker 2: Themed, although often with those it has a remediation already,
Speaker 2: it does.
Speaker 3: They have a remediation. They give you the.
Speaker 2: Poorest, accept the pr and let the builds run and
Speaker 2: hope nothing breaks. But I, you know, again and at
Speaker 2: a senior level, when this came down, I would want
Speaker 2: to lock everything, try one, like, there's other way. This
Speaker 2: remediation fails. We just broke a hundred apps, right, I
Speaker 2: would rather be vulnerable with ninety nine of them while
Speaker 2: we're trying to fix one and when we got to
Speaker 2: fix and fix the rest.
Speaker 3: Yes, what you can do, you can granuarize that.
Speaker 1: There's another problem that is maybe a little harder to detect,
Speaker 1: and that is if you're using a tool or something
Speaker 1: that works and it compiles, but then there's an exploit
Speaker 1: posted and a CVE against it, you know, and you
Speaker 1: might not know that just just looking at it, but
Speaker 1: that means that needs to be updated. So you know,
Speaker 1: getting current versions of things is a constant whack a mole, right,
Speaker 1: yeah it is. And so does the depend about sort
Speaker 1: of look at those, does it look for cvees against.
Speaker 3: Yes, so it pulls out the latest CVE updates, and
Speaker 3: then there's one that if there's an exploit that you know,
Speaker 3: we work with security experts across the globe, you they
Speaker 3: can also report them in to us. But there the
Speaker 3: updates are pretty good, pretty well up to date, I've
Speaker 3: not seen very many missed to be honest with you,
Speaker 3: it's been a really solid product. It's been. It picks
Speaker 3: up a lot of stuff that I didn't even know existed,
Speaker 3: even in like one of my top debo repositories, really
Speaker 3: simple code. It must have twelve thirteen depends.
Speaker 1: On word press plug chance. This week, word press plug
Speaker 1: ins seem to I'll find out be attacked the most
Speaker 1: from just bad developers.
Speaker 2: Well, you know, word press is the Internet explorer of
Speaker 2: this age, right Like it's the most hacked thing because
Speaker 2: it's used in so many places.
Speaker 1: It's the plugins that are the problem. That word Press
Speaker 1: itself is and it's pretty pretty good, but pretty robotic.
Speaker 1: But people write these plugins for stupid stuff and then
Speaker 1: they just don't understand security and they leave holes.
Speaker 2: Well, they think they're living in a happy little community,
Speaker 2: and then that happy little community gets invaded by black
Speaker 2: hats and it's not so happy. Anymore. I still still
Speaker 2: want to get back to this contribution side of things.
Speaker 2: I think these tools would be awesome, like if I
Speaker 2: could keep track of the pull requests that my team
Speaker 2: had made into those open source librarries. So it's you know,
Speaker 2: part of our overall corporate giving structure is, hey, we're
Speaker 2: we allocate a day a month for you to contribute
Speaker 2: to these open source projects on our dime. Right, we'll
Speaker 2: pay you keep working, but you know, automating all that
Speaker 2: capability to go. One of the ways we contributed is
Speaker 2: we all we have resources onto those projects too, as
Speaker 2: well as hopefully some cash for the other for the
Speaker 2: those maintainers that then often don't get a lot of love.
Speaker 3: There's money involved in this hold on.
Speaker 1: I'm going to check.
Speaker 2: Not that much money. Goodness knows, no, I think you know.
Speaker 3: It's it's something that I don't I'll be honest. I
Speaker 3: work with enterprise licensing so much. I'm pretty sure we
Speaker 3: open up de pendabot for open source projects right and
Speaker 3: under the advanced security piece for public repositories. I'm ninety
Speaker 3: nine point nine percent sure of that. However, someone can
Speaker 3: correct me if I'm wrong. But we we wanted to
Speaker 3: help the open source community a lot with that and
Speaker 3: that credibility. But I think it's the private repositories where
Speaker 3: it's a paid for option. I don't touch money. That's
Speaker 3: really like the summer, you're better off.
Speaker 2: It's a whole other conversation to have. And when we
Speaker 2: can't have today, Oh shucks.
Speaker 1: So what's next for you? What's in your inbox?
Speaker 3: Uh?
Speaker 2: Yeah, we're keeping you sleeping upon us.
Speaker 3: Yeah yeah, no. I actually it's content development right now.
Speaker 3: I'm I'm home for a little bit. It's getting content out.
Speaker 3: We have a lot of people and you know, we've
Speaker 3: talked about it today. All the co pilot features, all
Speaker 3: the enterprise features, people just are not aware of and
Speaker 3: to us, you know, when you're doing it day and
Speaker 3: day out, it seems like we're quite transparent with these features.
Speaker 3: But the reality is we don't have enough repeating content.
Speaker 3: So you guys were talking about all the social platforms earlier.
Speaker 3: So it's a lot of litmus testing with Instagram, TikTok
Speaker 3: and blue sky Now and LinkedIn, And for me, it's
Speaker 3: going to be some content creation on how to use
Speaker 3: this stuff, and then I don't know, we'll see what
Speaker 3: happens in twenty twenty five. I'm just you know, I'm
Speaker 3: just enjoying being in one country for a few weeks.
Speaker 2: Weird.
Speaker 1: Yeah, right, is there? Where do you go scuba diving
Speaker 1: in the UK?
Speaker 3: Well, it depends either I go up to Scotland or
Speaker 3: I go down to the south coast or the northeast.
Speaker 2: Right now, still, that's still all dry suit, right. That
Speaker 2: water's cold.
Speaker 3: Oh, it's I don't I don't dive in anything but
Speaker 3: a drysuit. It's cold. I think water temperature a few
Speaker 3: weeks ago in the UK was like seven degrees in
Speaker 3: one of the quarries I was in.
Speaker 2: Wow.
Speaker 3: Ouch, Yeah, it's it's it's spring fed, so it's always
Speaker 3: cold at the bottom.
Speaker 2: Yeah. So I'm living by the ocean here. This is
Speaker 2: the ocean I grew up near, and it's ten degrees
Speaker 2: pretty much all year round. You have a few minutes
Speaker 2: before you start to lose coordination.
Speaker 1: Coldest water I ever felt was the Saint Lawrence River
Speaker 1: and it was summertime.
Speaker 2: That's cold.
Speaker 1: And I waded out into the Saint Lawrence. After about
Speaker 1: ten seconds my bones froze. Yeah, it's basically what I
Speaker 1: thought was happening. Yeah, all right.
Speaker 3: Yeah, it's been in four degree water, which is thirty
Speaker 3: thirty nine forty degrees fahrenheit, and that is yeah, soul crushing,
Speaker 3: soul crushing.
Speaker 1: All right, April, I'm sure there's a lot more we
Speaker 1: could talk about, but will you come back when you
Speaker 1: have more to say?
Speaker 3: I will absolutely come back for you.
Speaker 1: Guys. Well, thank you again, thank you, thank you for listening,
Speaker 1: and we'll see you next time on dot net rocks.
Speaker 4: Dot net Rocks is brought to you by Franklin's Net
Speaker 4: and produced by Pop Studios, a full service audio, video
Speaker 4: and post production facility located physically in New London, Connecticut,
Speaker 4: and of course in the cloud online at pwop dot com.
Speaker 4: Visit our website at d O T N E t
Speaker 4: R O c k S dot com for RSS feeds, downloads,
Speaker 4: mobile apps, comments, and access to the full archives going
Speaker 4: back to show number one, recorded in September two thousand
Speaker 4: 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.
Speaker 4: Tree Middle Vans Day, summer time that means home.
Speaker 1: Then my Texas in line read