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