- Go 1.22.3 & 1.22.10 released
- Proposals
- Accepted: add binary.Append function
- Likely accept: new `go telemetry` subcommand
- Likely decline: Notify about new major versions of dependencies
- Packt book bundle
- Interview with Jamie Tanna
Creators & Guests
What is Cup o' Go?
Stay up to date with the Go community in about 15 minutes per week
This show is sponsored by you. Stick around until after the news to learn more about that.
Speaker 2:123.
Speaker 1:This is Guppa Go for May 10, 2024. Keep up to date with the important happenings in the Go community in about 15 minutes per week. I'm Jonathan Hall.
Speaker 2:And I'm your keyboardist, Shayne Heman. Woo hoo.
Speaker 3:How are
Speaker 1:you doing? Do you have mother's day in Israel?
Speaker 2:We have family day. But my mother, strongly claims that it's still, Mother's Day. And whenever we try to complain, she's like, yeah, who packed your sandwiches?
Speaker 1:You're right. Alright.
Speaker 2:Is it
Speaker 1:mother's day? Happy mother's day or family's day or whatever you happen to celebrate in your country. I know it's not exactly the same everywhere, but, in the US and here in Europe, it was last weekend.
Speaker 2:Happy mother's day to all mothers, especially those who are gophers or raise gophers.
Speaker 1:Hi, mom. The show is for you.
Speaker 3:Yeah. Alright.
Speaker 1:There's a
Speaker 2:record of show. Deal with, with the mom hacker, thing. I really like that one. Anyway, let's talk about Go.
Speaker 1:Let's talk about Go. So last week, we talked about Go 122.3 and 121.10 that were to be released on Tuesday. They have been, and they contain some important security fixes. The first one, if you're using Mac, you should upgrade yesterday because there's some arbitrary code execution that could happen during build on Darwin. So the details I don't understand.
Speaker 1:It's related to Seego and some version of Apple ID blah blah blah. Just upgrade.
Speaker 2:Obviously, not something that impacts Jonathan No. Who's using Linux, by the way. But all in all fairness, a lot of, build machines online are moving to being, like, Darwin as well, like ARM and stuff like that. Your GitHub runner might be like, your DevOps guy might have upgraded it to be Darwin under the hood and you don't know. So double check.
Speaker 1:Double check. Something that affects potentially everybody though, there's a potential for a DOS attack, I guess. There's a malformed DNS responses, that can cause an infinite loop. So if you use DNS, yes, that means you you should update. So just everybody should update.
Speaker 2:Yeah. And and go to the back, you know, the back of the wall and reset the counter on days it's since it's been DNS. Alright. It's never I never got to use the second, number, the second digit. It's always single digits since it was DNS.
Speaker 2:Just because I don't work weekends, like Maybe
Speaker 1:if you would use binary, you could get to set to to 2 digits that way. For sure.
Speaker 2:But what if I need to append something to a binary? I don't know. That's a bit
Speaker 1:No. That'll never happen. Wait a minute. What's this proposal we see here? So I I think we talked about this or something very similar to it, many months ago.
Speaker 1:But this proposal has just been accepted, to add an append function to the encoding binary, set of interfaces. The the idea is to be able to append to binary streams without doing extra allocations. So when you when you call it so this is an alternative to like an IO writer. An IO writer, you write, something to to something arbitrary. But by using a pen, you can do it using the pre allocated memory of the thing you're writing to if there's enough space there for the thing you want to write.
Speaker 1:So that's that's the whole idea. There's a related proposal which I don't think we're gonna go into details on about doing the same for text writing. That's in the comment phase right now. It's not accepted yet, but I expect it will be or something very similar. But I think this is cool.
Speaker 1:This is gonna help improve performance, reduce garbage collection pressure, and, I think they're gonna update a whole bunch of standard library stuff at the same time.
Speaker 2:That's cool. So so is this change basically just for the people who write standard libraries or am I, as a, like, normal developer, should I worry about this? Like, should I try to understand this package? If you
Speaker 1:are writing serialization code, writing raw JSON or your own custom format or XML or something like that, then this might affect you.
Speaker 2:So, like, Liav from Luna we had was, like, been on the hunt for the most efficient way to serialize JSON. He might Yeah. Want to, like, do these binary appends of instead of, like, allocating and then serializing. This is a bit of a tangent, but I just did something like this at work. Mhmm.
Speaker 2:But I didn't Rust not in Go, but, like, whatever. We had a super horrible Python code that did a ton of hashing and then just took the first few letters because that's what it cared about, but it allocated the whole string and then just sliced off a few of the letters. And then when I reimplemented that, like, tiny bit of code in Rust, I could, like, do that optimization, and the impact was huge. It was, like, 5, it was, like, 20% decrease in run time. Just, like, compared to allocating the whole thing and just doing, like, binary appends.
Speaker 2:So this could be really useful for, you know, the super high performance, you know, you're writing a few bits here and there. I assume people will randomly use it only if they, like, did some profile guided optimization. Right? Like, they
Speaker 1:Probably.
Speaker 2:Found a found a red spot in the code and, like, okay, let's try to remove allocations. Let's try to improve the performance of this specific code piece. Indeed. Cool. I think for most for
Speaker 1:most people, this will just sort of magically mean a slight improvements in performance. If you use the libraries that take advantage of this, things like, well, this is for for, binary encoding. So there's not nearly as ubiquitous as JSON or XML or something like that, which the other proposal which will probably be accepted would affect. That one would impact you if you're using JSON encoding or XML or YAML or all those sorts of things.
Speaker 2:Cool. A bit of a blast from the past. Do you remember us talking about Go telemetry in the toolchain? I do. Yes.
Speaker 2:For those who didn't, listen to those episodes, what is Go telemetry?
Speaker 1:It is the option to opt in to sending some not private data about the way you use your Go installation to the Go team. So they can learn important things like, how many people use ARM 64 on Windows and how many people use particular libraries or whatever. There's a various large number of things that could be to potentially telemetry. Is that a is that a verb?
Speaker 2:I don't think it it is now. It's a pretty good one. Telematarized.
Speaker 1:There we go.
Speaker 2:So there's a new proposal which I really liked. Very simple. Just adding a command to the Go toolchain called Go telemetry. In the same way, you can do go build, go run, you could do go telemetry. It has a few sub commands, very obvious ones, on, local, and off, which do what you would expect them to do.
Speaker 2:On turns it on, local turns it on, but doesn't upload data to the Go team. Just enables, you know, local telemetry collection. Off turns off this behavior completely. And you can see the configuration with Go config, just like what mode is on right now, when did it start, where is the telemetry saved. And finally, go telemetry clean, which like removes all the local telemetry data in case you wanna reset it or clear up some storage or whatever.
Speaker 2:There is already a package under the x, you know, a prefix called X telemetry, CMD Go telemetry, which does a 100% exactly the same thing, with one difference. The Go telemetry package that exists right now has support for Go telemetry view. Have you ever, seen this? No. So I'm gonna share my screen right now.
Speaker 2:This is gonna I'll I'll ask you to describe it because it's not gonna carry well over, audio. But this is what pops up when you run Go telemetry view. Right? So it's running in local host, for me right now. It's a web page, and it allows me to inspect the counters that are collected by the Go tool chain.
Speaker 2:So there's VSC go, there's some stuff here, there's some reports on different days, charts. Right? The first one was immediately interesting to me, activation latency. Yeah. And you can see, like, most days it takes less than 5 seconds, which is red, but this week it took one second, which is green.
Speaker 2:Duration, number of inputs, like there's some installations, Go Please has some Go PLS has some telemetries here. It's all in very pretty charts. The main one that was interesting to me is the Go PLS, completion latency. Like, how long, did, GoPLS take to to auto complete something for me with, like, red, orange, green, blue like, you know, green being the good part. It also shows how little I program and go on this machine, which is a bit unfortunate.
Speaker 2:But I mostly work on my it's like a recording machine and the work machine are a bit different. Cool. So, yeah, really cool report. And unfortunately, the Go telemetry command in the, like, Go tool chain doesn't include this report because it depends on JavaScript. So you're going to be able to turn it on and turn it off.
Speaker 2:Maybe I should, like, take a screenshot of the report or something just so we can put it in the channel. But you're not gonna be able to view the data unless you install the separate packet. I was wondering what do you think about that because it feels, again, a bit like not all the way right with with the telemetry decisions again. Like I'm I'm gonna turn on telemetry, but I won't be able to see what it does.
Speaker 1:Well, I I I so first off, I fully support the proposal. I think making the the tool a little more accessible and installed by default is a is an improvement. With or without the view, I I support the proposal. And if we do it without the view, there's always the option to add view again later as a separate proposal. Right?
Speaker 1:So, I I support the proposal. I think it's a good idea. It is unfortunate that the Vue isn't included in the proposal and the reason is because, it depends on on JavaScript.
Speaker 2:So you can't really work around that. Right? You can't have the tool and then separately once you run Vue have like, oh, do you wanna install the relevant dependencies as well? It's like an extension. The and when you get there, it's just like, go install the separate package.
Speaker 2:Right? I'm I'm wondering if there's, like, maybe a JSON view or a super simple HTML view that doesn't require JavaScript, just some HTML templating that's already in the standard library. Yeah. That's a good question. Work in.
Speaker 1:Good question.
Speaker 2:I don't know. Anyway, I I upvoted this, proposal, and it seems like a, likely accept. It's in the final comment period now. This period started yesterday. So if you have an opinion, now is the time.
Speaker 2:It'll probably get accepted, like, next week if I'm Probably. There's no objections here. Everybody agrees It's correct. And there's one new proposal.
Speaker 1:So this next proposal is both interesting and likely decline and new. It's a whole bunch of things all at once. It's we're wearing so many hats. So first, what's the proposal? The proposal is to make the go command, at various points notify you when dependency you have has a new major version available.
Speaker 1:So let's say you're using, Labstech echo version 3, which is by now really old. It would say, by the way, Labstech echo version 4 is out now. You know, the v 4 module is available. You might wanna consider upgrading. That's the gist of the proposal.
Speaker 1:What's interesting about this proposal in my mind is that it's old. It came it was proposed in July of 2020 and it was only recently added to the meeting minutes, for the weekly review. Part of that's because the meeting, the weekly review meeting is newer than the proposal is. So they're starting to pull in some old issues to to get them, work through the system. It's also a likely decline.
Speaker 1:Can you imagine why this would be a likely decline?
Speaker 2:First of all, I wouldn't want the Go tool to notify me on anything that is, like, critical. Just, like, stay out of my way. The real reason is I think there's no there are packages that I remember using, that used major versions, you know, like candy. They would release a new major version every 2 weeks, and that's up to the maintainers to do so. Right?
Speaker 2:Like, it's a bit uncomfortable, but it can happen. And there are some reasons there are some scenarios in which it makes sense. And then, you know, the Go tool, like, spits out these warnings. Every 2 weeks, you have to maintain them just because someone else decides to, you know, publish a new major version. I just don't want people to be able to, you know, shove input shove output into my Go commands.
Speaker 2:It also doesn't help that upgrading isn't necessarily important. Right? Someone, like, upload the new version of their library. But if their previous version is okay, like, why would I upgrade? Sure.
Speaker 2:Doesn't make any sense.
Speaker 1:Yep. So you you hit the nail on the head twice. There's another couple relevant points, to mention. So first, yes, there was a long discussion about maybe this could be a warning rather than error, but then Russ pops in as well. Actually, the definition of a warning for our purposes is something that you may or may not care about, and this definitely fits that category of things for just for reasons you mentioned.
Speaker 1:The other is there are libraries that just kinda throw major versions around like candy, and somebody points out Stripe Go, which is on v 78 right now. Oh, my god.
Speaker 2:And, you know, by the way, if authors want people to upgrade, they can issue a slash deprecated comment, which is, like, sort of officially supported whatever.
Speaker 1:And that is exactly the other point I was gonna make, that that Russ points out too in this thread is that there is already a mechanism Oh, really? To deprecate old versions.
Speaker 2:Russ and I are on the same wavelength today.
Speaker 1:You must have had a chat with him before you got on the call this morning.
Speaker 2:Oh, I wish. Alright. So it's gonna get declined, but, you know, it every few months or so brush up on your, dependencies. I'm gonna go out on a thing here and say, by the way, don't do that. Like, so many companies, GitHub with Dependabot, Orca you know, I'm gonna shout out my own company or like Orca Security with ShiftLeft Security.
Speaker 2:And so many companies are indeed, like, make sure your dependencies are upgraded where it's important, which is like Yeah. Security or license issues or s bombs or stuff like that. So many companies are are hungry for your money to solve this issue for you. You probably don't need, to do it, like, on your own inside the, like, language ecosystem. Because you already have so many other ecosystems.
Speaker 2:Even if you're just using, like, Go, you probably have like Docker and blah blah blah and you're hosting on a specific thing and someone you're like the other libraries might have, you know, JavaScript dependencies in them if they are importing the the telemetry, ex telemetry thing like we said. It's so hard to I think it's actually literally impossible to actually go over your entire dependency tree and figure out what's going on there, all the way down. So it doesn't make, sense. Just pay someone to do it for you. It's not the core of your thing.
Speaker 2:It's just the context of your thing. And hey, if you're paying Orca to do it, that's fine as well. But I'm just I'm already totally veering off, subject. So I'm glad it's gonna get declined, because it's also complicated to implement. Right?
Speaker 2:Which major suddenly people are can I update my major version, like, as a library maintainer? Should I publish a it's gonna cause some people to never publish a new major version, because they don't wanna appear in a in a warning. Right? Doesn't make sense anyway.
Speaker 1:Well, that pretty well wraps it up for proposals this week. One last thing to talk about before we move on from the news. There put a couple blog posts, from Jamie Tanna about OAPI Code Gen, which we wanna shout out because, he's gonna be our guest on the interview coming up in just a few minutes. So stick around for that. The first one is just a blog post about creating a more sustainable model for OAPI Code Gen.
Speaker 1:I think that refers to like a business model. TLDR, they're looking for sponsors and they're moving to their own organization. OAPI Cogener is the company's own organization. Two blog posts linked to the show notes, about that. So if you are a user of OpenAPI or are thinking about using using open API, these blog posts are gonna be very relevant to you as well the interview coming up in just a few minutes.
Speaker 1:So stick around for that. Welcome to the intermission or ad break or whatever you wanna call this. So I had to leave, so I'm running solo today. Just a few quick things before we jump over to our interview with, Jamie Tena about open API. First, if you're a new listener, thanks so much for joining.
Speaker 1:Would you share this podcast with your friends, with your colleagues? Leave a review on iTunes or wherever you listen to your podcast. I don't even remember if it's called iTunes anymore. Apple changes branding every now and then. But leave a review.
Speaker 1:Leave a rating. Share with your friends and your colleagues. And, talk to us directly if you like. We can always be reached by email at news at cupogo.dev or just head over to cupago.dev to the website and you can see pictures of us. You can buy swag if you'd like a cupago cup or a t shirt or a hoodie or stickers or even a wireless charger.
Speaker 1:We've sold one wireless charger. So check that out. You can also find all past episodes and the complete show notes so you have links to all the articles and resources we talk about in the show. One other resource we haven't talked about in the show that I wanted to shout out today is the publisher, Pact, is doing a Go programming language bundle right now. You can pay what you want to get a whole bunch of Go books.
Speaker 1:It looks like there's 17 Go books, for $18 or more. You can pay more if you want to. And you get all these ebooks, for that that low price, including one from previous co host and previous guest on the show, Adelina Simeon. She wrote the book, Test Driven Development Go. And that book is included.
Speaker 1:So if you've been thinking about buying that book, but you just weren't quite sure it was worth the cover price, by the way, it totally is. Now for $18, you can get that book and 16 others for a low price. This is not sponsored at all. I just am excited to share about books. So that's a resource to check out.
Speaker 1:You can also sponsor us on Patreon. We mentioned at the top of the show that this show is sponsored by you, the listener. We don't make any money from this. We're I wouldn't say losing money, but it costs us money to produce the show. We pay for an editor.
Speaker 1:We pay for hosting fees, etcetera. So if you wanna help support the show, you can support us on Patreon. Again, kapago.dev is a place to go. There's a link to Patreon there, and you can help support us financially, for a very low fee. And if you're not interested or not able to support us financially, that's cool too.
Speaker 1:Join us on Slack. You can, support us. Show us your support just by being involved. We're on the the go for Slack in the cup of go channel, cup dash o dash go. There are, as I'm recording this, 370 other cup of gofers on there.
Speaker 1:Come join us and, join the chat. We we have some interesting conversations on there about the news and about other government edit things. So I think that wraps it up for now. Stick around for the interview with Jamie Taha.
Speaker 2:Yo, Jonathan. Hi, Shai. Did you get what I sent you in the post?
Speaker 1:I don't even need to answer that. I can hardly see how this is going.
Speaker 2:If you didn't get what I sent you in the post, maybe we should, you know, agree on some standard to talk about getting things in the post. Well, I don't wanna get a head. Let's just delete that old idea, patch things up, and we can start. Maybe someone can help us. Oh, hey, Jamie.
Speaker 2:Hey. Thank you. Thank you.
Speaker 1:Yeah. Ladies and gentlemen, this is Shy. He'll be here all week.
Speaker 2:Hearing, like, crickets in the audio. Mic feedback. For sure. For sure. Welcome, Jaime, to be interviewed on the show.
Speaker 2:We're really excited to have you, longtime listener, first time caller, like in Frasier. Yeah. Yeah. How about you tell the people about yourself?
Speaker 3:Yeah. Hey. Thanks for having me. So as you mentioned, I've been listening to Cupid Go since the first one dropped, And it has literally been in my weekly rotation ever since. I'm a senior software engineer at Elastic.
Speaker 3:I work in our engineering productivity team. And I have been involved in, Go stuff for about 2 and a bit years. When I joined Deliveroo, I joined into a team with Go. And, since then, I've just, like, fallen in love with the language. Don't want to use anything else.
Speaker 3:Pregrudgingly have to. Yeah. Go is, my favorite.
Speaker 2:Nice. What did you come from? Like, what was your previous, programming main driver?
Speaker 3:For the rest of my career, it's mostly been Java. So a lot of Spring Boot applications. See, I like Java. I definitely did at the time. Some of it was yeah.
Speaker 3:I just I found it quite good. One of the things then coming to Go and being able to use, like, Neovim and not have to click around and things not have to having to use a big editor has just like revolutionized my life. And I'm someone with ADHD, and I've definitely found it as like an additional context switching of so, like, certainly scripting locally, in my batch scripts in VIM. But then if I'm writing code, I'd have to open up IntelliJ and try and remember how some of the things worked. And even though it had like a VIM mode, it wasn't as good as real VIM.
Speaker 3:And so I really found like the ergonomics less nice, especially coming to Go where everything's blazing fast. I can use the same editor I want for everything. Nice.
Speaker 2:So we already mentioned this on the show, so I just wanna jump into it. There's 2 new big things about OpenAPI Gen. Super exciting this week, and I really wanna jump into them and talk about the sponsorship thing and and open source. It's a huge interesting conversation. But I wanna be fair to maybe people on the on the podcast I was about to say on the call who are listening to the podcast, who may have not gotten my joke.
Speaker 2:You know, my amazing, amazing joke from the intro of this interview.
Speaker 1:So They could just retry, you
Speaker 2:know. In one minute I get it. What is, OpenAPI and what is OpenAPI Cogen?
Speaker 3:Sure. Yeah. So, as mentioned, I am one of the maintainers of a Go command line tool and library called OAPI Cogen. OAPI Cogen transforms OpenAPI specifications to Go code, whether client or server or just plain models. And for those that aren't aware of OpenAPI, it's a well defined standard for what does my restful API look like?
Speaker 3:So it allows you to define all the models that your API uses, what endpoints you've got, provides like a really nice contract between, consumer and producer. And because in a lot of cases, you can write it upfront and you know what your contract is gonna be, hopefully, you can then structure that in, a JSON or YAML format that then other tools can use. For people who've used things like protobuf and gRPC, it's similar. It's, in some ways, a little bit more painful because of the different versions of OpenAPI that are supported by different ecosystems. But it is a great standard, and it is so much better than having to read through someone's API docs that are different in multiple places.
Speaker 3:They've just got, like, snippets of code commands instead of, like, here's the actual structure and these are the types.
Speaker 2:Cool. So the project is open source. Right? And everybody can use it. It's actually been, it's not that old.
Speaker 2:Right? It started, like, 5 years ago ish.
Speaker 3:Which I would say is fairly old.
Speaker 1:As Go projects go, it kind of is, I suppose.
Speaker 2:Yeah. But it is very, I would say, favorable. Like, people use it, people start it. It has a active community. It has companies that depend on it.
Speaker 2:Right?
Speaker 3:It does. Yes. Yeah. So I've recently been looking, I can't remember which site, but the number of sites where you can try and get insights into the companies who are starring or interacting with your repo. And all of the company names, like, you will know them.
Speaker 3:They are very big tech companies. Like, that's pretty cool that we have users. If you look at, like, the GitHub or the package site, But you will be able to see a number of people using it, but there are also a whole host of companies using it internally that, naturally you're not gonna see on, GitHub or package. Dev.
Speaker 1:I'm curious why another, I mean, big fat quotes, I suppose, code generator for OpenAPI. Because aren't there many? I mean, if Swagger comes to mind and I'm I'm sure there are others. What made you decide that that your version needed to be created?
Speaker 3:So, 2 part answers. The first one, as you mentioned is Swagger. So this is something that, actually, may also be confusing to people. So Swagger has been retroactively named, OpenAPI 2 and was a previous standard for, defining your contracts. Then OpenAPI 3 and 3.1, have come out and have since changed things.
Speaker 3:And so there are a number of places where people have Swagger tooling, including company what the company SmartBear, who produce a load of tooling under the name Swagger, but that do OpenAPI 3 as well, which is very confusing. And there are very big, generators out there. So there's things like OPI gen openapigenerator.tech, which is the most common one, which was a multi platform one. So with a single generator, you can spit out code for all of the different ecosystems. They have a templating language or templating engine.
Speaker 3:You can write your own templates. And that that works quite well. But one of the problems is it's written in Java, which means that for teams who are predominantly working in Go, you now also have to install Java into your environment. Your CI pipelines now need a little bit extra stuff. The other thing was that when, Martin, my co maintainer, who started the project 5 years ago.
Speaker 3:So Martin had been working on basically this implementation across multiple companies. And at least the previous two times he'd started it, he just done it closed source. It was just internal to the company. When he started at DeepMap, and started writing the implementation, it was like, wait, wait, wait. Can we make this open source?
Speaker 3:Because, a, I don't wanna have to keep rewriting it. But also, like, it is a very positive thing for the company. Looking back, DeepMap is associated with OPI Cogen. DeepMap since being acquired by NVIDIA. So NVIDIA are now associated with that, and that's pretty cool.
Speaker 3:So, yeah, the main thing was, none of the cogenerators that were around 5 years ago spat out idiomatic Go and were purely written in Go, purely focused on Go. So in recent years, we've had things like, Ogen and Humor, which have come out, which are, again, Go focused tools. At the time, there wasn't really anything like that. So Martin wanted to have something that really worked for the Go ecosystem instead of trying to merge across multiple things.
Speaker 2:I remember using the, like, open API generator dot techone in my previous company at Greco where we have this huge talk about how we created we started with protobuf, actually. That was our source of truth. But from that, we generated open API. And from that open API, we tried to generate, many things. And the main thing we wanted to get working in the Go space was go mock server.
Speaker 2:Because the actual back end implementation was go protobuf, but we really wanted to we did that with, like, you know, GoKit and stuff like that. But we really wanted to just quickly whip up some mock servers for the front end team so they could work. It was such a pain to, make the Java app work and even once you figured out the, like, magic spells you had to do to spit out code, the code was so that we just ended up generating Python servers instead, because that was a bit even if the code that they generated wasn't so great, you know, it's in a language that's not that great to begin with, so you don't really care about all the weird stuff they did. I'm wondering, looking back, if I had that tool at the time. It was, like, early 2020.
Speaker 2:So I think it was pretty much when the tool was, announced. If I if I opted to use that, if my all of my mock servers were in Go as well, and that would have been a happy camper.
Speaker 3:So speaking of that, probably wouldn't have been around at the time, but there was a tool, was this tool called Stoplight Prism. So Stoplight are an API, developer tooling company. And Prism is an excellent tool. So it's written in TypeScript, and it takes an open API spec and it will spin up a mock server for you. But one of the really, really nice things about it is it can auto generate data.
Speaker 3:So as well as, like, selling out some stuff, or using things from your, like, examples within the spec, it will also say, okay, you have said that this field can be just a string, so it's going to return you any string. And one of the things, when I was, I remember this at Deliveroo was really nice. Was you said it's any string and therefore it will return you things with emojis and it will include spaces. And you will then realize that, oh, actually we don't just mean any string. We mean a very specific set of strings.
Speaker 3:And that was really interesting because, that also narrows things down because for your consumers and for you as a producer, you actually understand better what should my contract be rather than just, oh, yeah. It's a string.
Speaker 1:So it's kind of a form of of, inadvertent fuzz testing.
Speaker 3:Yes. Yeah. Exactly.
Speaker 2:That and publishing your app to users, Like, giving them the HTML form. And they're like, why are you typing in Hebrew? Wait. You shouldn't you shouldn't put commas in this field. That breaks everything.
Speaker 2:It's a CSV in the back end. What are you doing? The bet honestly, in honors of by the way, I think this interview comes out today. So it might if not, we will add this up. In honor of mother's day, my mom is the best fuzz tester slash pen tester you've ever seen.
Speaker 2:No matter what HTML form you give her, she'll just figure it out a way to input everything backwards, put the month and the date, you know, and the day and the day and the month, and the year and the password, and and, like, show password, try to paste stuff into it, click the submit button 3 times really fast. It's like the best fuzz tester you ever seen. So happy mother's day to all the fuzz testers out there as well. I wanna link this conversation we're having to, you know, for long time listeners like yourself. Recently, we had, Quobix on the show, Dave Shapley, who's also working on a lot of API tooling.
Speaker 2:And I couldn't, fail to notice that one of his libraries was mentioned in the plans for if you're gonna sponsor if you're gonna get enough traction behind the sponsorship, a thing that, you'll do with the lib open API support. So first of all, I wanna talk about the differences in angles about what you're doing and what Dave is doing, what Jobyxt is doing. So Jobyxt, is doing some tooling that, you know, if you have a API spec, allows you to lint it and allows you to, like, test it and verify it and stuff like that. He just recently released a doctor. It's gonna be like his closed source SaaS thing.
Speaker 2:I really recommend, by the way, listeners, if you're into APIs, check it out. It's really cool. But he's, like, sort of working at it from the outside. You already have your system. You already have your spec, and you wanna improve it.
Speaker 2:Your angle is almost entirely opposite. You have the spec, but now you wanna write the code behind it.
Speaker 3:Yes. So first of all, like, David's been awesome work. I've been working with him on a few bits in the open source world. So one of the things I've also worked on as part of this is trying to write so while you're writing your implementation of your server, how do you actually know that your specification matches the implementation? Because, say, you can generate all the code, but if your implementation doesn't return the fields that you say you're going to, you're not gonna catch that at generation time.
Speaker 3:So I wrote a library which basically wraps KinOpenAPI, which is the library that OAPI Cogent uses under the hood of OpenAPI, basically checks, like, does that all work? Does the response, much properly? Now, one of the things with Kinopen API, a long standing issue, in the open API ecosystem at large is the fact that OpenAPI 3.1 has been out for at least 3 years. So many ecosystems don't support it yet. So Kinopen API doesn't, which means a large swathe of the Go ecosystem doesn't.
Speaker 3:It's also not supported in a lot of Java places in a lot of, the Ruby libraries. So we we've already got, like, a huge scale of things can't support it. And so with this library, one of the things I was looking at was, oh, this new lib open API was, like, just launched. And it was, like, within the month or so that David announced it, then added a validator. We can basically do similar stuff where it can look at incoming request or response, and it can validate whether it matches the spec.
Speaker 3:And so looking at that, yeah, Dave's work is incredible. And we want to add that to OPR code gen. As you mentioned, one of the things is, it is difficult, to try and add that in because so much more code base already expects the kin types, because you can use OPR code gen as a library as well. We can't introduce that without a breaking change. So we have to do some fun to try and make it work, in parallel instead of as a broken change.
Speaker 3:And then as you say, it's a slightly different angle, from our tools. So the way API Code Jam works is commonly referred to as design first or schema first. And the idea is you write your OpenAPI spec upfront. So you say this endpoint should have these things. It should require this header and load of fields in the request body.
Speaker 3:And it returns this response. A lot of people prefer writing that or generating their spec because A, they don't want to write any more YAML than they can avoid. But also, I think it's just, yeah, people find it harder to do the design. They prefer jumping straight to the code, whereas I absolutely love doing that design up front and actually thinking, like, what do I expect to happen here?
Speaker 2:I think the approach of of this, schema first is really good. It's worked for me a lot of times in the past. But like you said, writing the actual schema is a pain. The format is not super obvious, and you have to put the models, you know, at the bottom. It's sort of reminiscent to a lot of, discussions I know Jonathan is having about TDD, where every every Monday Thursday, you'll see him, getting wrapped up in some flame more on LinkedIn.
Speaker 2:When someone says, like, you know, some LinkedIn influencer, I don't know if there's a name. Linfluencers are like, oh, TDD sucks because I can't think about the test ahead of time. So, obviously, it doesn't work. And what what if the test is wrong? Then I'm doubly stupid.
Speaker 2:Blah blah blah blah. And then, Jonathan's, like, putting them into place with some, like, a snarky comment. Me? Snarky? But it is our Jonathan?
Speaker 2:What, Jonathan? Our Jonathan? No. But for real, the the thing is it is slightly more difficult to think about the spec ahead of time. It but it obviously, at least for me, super obviously, is worth it.
Speaker 2:One thing that I've done that, helped me do schema first more is write out the schema in, like, natural language and let, LLMs take care of the generate the JSON or YAML or whatever for me because that's the painful part. Right? So I already have, like, a series of prompts I wrote somewhere that's like, okay, please generate the correct, spec. Right? Now please add the description fields.
Speaker 2:Alright. Now take all the things that look the same and put them in the models below to don't repeat yourself. Blah blah blah blah blah. And it works out, It saves, like, 90% of the pain. If you actually do wanna think about the spec ahead of time and it's just writing out the open API stuff, that's a pain.
Speaker 2:I can definitely suggest that as a quick crux to get you over it. And then combined with your 2 I can just imagine the sort of, like, powerhouse of using LLMs to write the spec, using Dave's thing to validate whatever bullshit the LLMs sped out because it's probably wrong in some places. If it if it's even valid at all, And then using, you know, OAIgen to generate the service and idiomatic go, and then, you know, taking a deep breath and just implementing the business logic and everything else is perfect. And using wiretap to validate it and it's like, oh, and and what you you mentioned the stoplight prism or other fuzzers to, like, oh, shit. I didn't support emojis and I didn't support Hebrew and I didn't support Chinese.
Speaker 2:I need to take all that stuff out because this is an email field and not, like, just any string. It's a lot of tooling and it does require a setup, but, you know, you do it once for your company or your team and the returns on investment are are are so clear.
Speaker 1:I'd like to offer a a small cautionary tale based on my experience with I think it was Swagger 2. This is many years ago. 2016 or 17. I was tasked with adding the open API spec. Is it I don't remember.
Speaker 1:It was it was a tool from swagger. I'm pretty sure that would like look at go doc comments and turn them into an open API spec. So I was, tasked to add all of this to an existing API. It was a nightmare. I mean, that that is what convinced me that doing the design first makes sense.
Speaker 1:I mean, for one for one thing, it was just really difficult to to to document some of these things. Many of the endpoints were completely like rest bastardized things. Like for for example, rather than using content type headers to indicate whether it was a JPEG or a GIF, they looked at file extensions. And there's no way to specify that in an open API because, of course, there's not because that's stupid. And and and it was just one.
Speaker 1:It was a really simple example to explain. There were lots of other examples where like a field would would be this or that or something else. And there was no way to express that in open API because you should never freaking do that sort of stupid thing. And if you do your design first, you'll avoid this sort of pitfalls and traps. So I I'm a big advocate of design first.
Speaker 2:There's no tooling that can help you around not, you know, using a a spec or a library and just not knowing what you're doing. No amount of linters, generators, testers, and whatever could, help you, you know, instead of just reading the documentation and the spec once and learning how they work. You're like, no, there's a string here. I'll use it for whatever. They're like, sort of greedy lazy approach of I'll just make the thing work and then build my own stuff on top of it instead of learning what's the best practice.
Speaker 2:There's no I I'm sure that even in 2024 open API 3.1 with all the tooling you've just mentioned, people could still make that mistake.
Speaker 1:They can, but I, you know, I think it's like it's a lot like TDD that it the tool doesn't solve the problem, but it can help you be aware of the problem sooner.
Speaker 3:Yep. Absolutely. And I think the other problem is, like, yes, it's nice to write things from scratch. But chances are most of our work as engineers is gonna be existing code and trying to retrofit some of these best practices, even just like perhaps the conversation about updating dependencies. Like, okay, there's a breaking change in one of our deep dependencies.
Speaker 3:How much of our code base is that gonna mess up? If you're trying to retrofit, like, large scale documentation, that's difficult. And then what if you also have API standards that then it's like, oh, do we now have to, like, migrate to new endpoints? What happens to all the clients that are calling this? And, yeah, so delivery, one of the things, spent some time doing is retrofitting open API to some existing rails more words.
Speaker 3:That was partly so, I actually understood what my contract was, because we're doing some integration between Go and, Rails. But also, like, it was useful to have, through that process. We got a few blog posts out of it, learn about some cool tooling, but it's hard. And, then you have to be continuously checking that the spec is in sync with the implementation. And, again, that stands tooling.
Speaker 3:And, yes, people can be, engineers hopefully should be well versed enough to do that. But guarantee there aren't. I've been working on OpenAPI things for years, and I'm still very regularly looking things up or being surprised by things. There was something that recently came up on OPI Code Jam where someone had flagged a bug, where we weren't supporting, I think it was the Keycloak API, spec properly. I was like, oh, yeah.
Speaker 3:That looks like a bug. And, oh, vacuum by Dave, is also trying to have a problem. And so I reported to Dave. Dave was like, nope. This this is actually a problem, with the spec.
Speaker 3:It's things that I've worked on OpenAPI for years. And there are still so many edge cases, so many things that if if we're expecting someone who hasn't even worked on API that much to know how to do things perfectly off the bat, let alone also thinking about like, how should I do versioning? That's a slightly controversial topic, down to like dotjpeg.png. It makes sense. Like, content negotiation is hard.
Speaker 3:I have several blog posts on that, and doing it right and explaining that to people is hard. So sometimes you wanna go for the quick win that isn't necessarily as good. Mhmm.
Speaker 2:So what was the bug? I'm I'm really interested in what the Keycloak messed up in their spec.
Speaker 3:So it was they had, a duplicated path parameter. So it's something like slash clients, then in curly brackets, client name, something else, and then client name again. Oh. The thing that was there was the assumption that we can just reuse that definition. As Dave said, that can cause confusion, and can cause problems.
Speaker 3:So it's best to avoid doing that.
Speaker 2:It's it's funny that you mentioned it because I I one of my developers in my previous company wrote the same bug, but in our generator, the result was nondeterministic, which path is gonna pick. So it sometimes sent it to the wrong API and he was like, he was going crazy. He he was he would build like the the pod. Right? He write the command.
Speaker 2:It was random. It worked like 3 times and then he had the demo. He, like, generated the pod, wrote it. Nothing worked. I was like, sorry.
Speaker 2:I'll take it offline. I'll debug it. Looking at the logs, he's not even seeing his API. Right? Added the log print, rebuilt it.
Speaker 2:It works. Deleting the log print, rebuilt it. It didn't work. He was like, go insane, then I just like, I I stepped in. I tried to help him.
Speaker 2:We, like, pair a program then on it. And I I was like, wait. These paths are the same. He's like, no. It's, like, 2 different variables.
Speaker 2:I'm, no. It's not. Like, just change the name to be, like, underscore, it was like a Slack message. It was a Slack underscore message in the path parameter. Just the second one, edit in underscore, boom, solved.
Speaker 2:So I do wanna talk about the blog because you mentioned it and, you know, saying a few blog posts when talking about your absolutely amazing piece of the Internet, is not doing it justice. Like, oh my god, there are so many things here. What is up with all this, content? We will get to open API support. I really wanna talk about it, but just can you give us a minute about about this amazing sub, I I wanna call it, like, subsection subcontinent of the Internet called jvt.me?
Speaker 3:I mean, I could talk about it for hours, so I'll try and compress it into a minute. So as of, this recording, I'm currently up to 979 blog posts on my website. I've been blogging for several years. You would hope from that number.
Speaker 2:In I'd like 15 minutes ago. How did you get?
Speaker 3:So, one of the things I've been doing is, fairly early on in my career, I thought I coined it. I didn't, regardless of the point. I do a thing called documentation. So I write blog posts as a form of documentation. So if I fix a bug, anything or some awkward, combination of parameters or, This is something that I couldn't find any documentation for.
Speaker 3:I will write that documentation on my blog, even if it is just for me in the future. The number of times I refer back to my own blog posts for how do I do that thing is incredible. As I mentioned, I've got ADHD. And I absolutely see this as a lot of the superpower with ADHD because I no longer have to remember how to do all the things. I just need to remember that I've written about it.
Speaker 3:So one of my recent posts was around Go 120 two's, new routing. And I was playing around with it and was like, why is it not working? Why do I keep getting a 4 zero four? Because I'm working like my tool chain is go 122. Like, what's going on?
Speaker 3:Everything should be working. And it was because I haven't updated the go directive in my go dot mod to 122.
Speaker 1:I thought it was because you had too many spaces. That would never mind anybody. Inside joke from a previous episode, by the way, for anyone who doesn't get it.
Speaker 3:Yeah. So because I've hit that, I wrote a blog post. And I every so often get a hit on my site to that blog post. So someone else has hit that issue. And it's a great way for me to write about things that I can come back to in the future.
Speaker 3:Like, as of the last 24 hours, I've had at least 1400 hits. And that's not bad. Not at all. And, yeah, so I find my blog really useful because I can write things. I use it for, like, little things like that documentation, which I don't really expect other people to read, but it's useful if they can.
Speaker 3:Then I do write posts that I absolutely want other people to read, for instance, ones that I'm talking about. I also do a thing called week notes. So at the end of each week, I write blog posts just to be like, what happened this week? I find it as a nice, like, cathartic end to the week because I get to consider, like, what sort of things happened. Every so often, I will read it back.
Speaker 3:And it'll be really interesting, like, for instance, in 2020, during the height of the pandemic, it's really interesting, just like reading what life was like then, what sort of things I was worried about. And I won't talk about everything, but it's like, I was trying to deal with the chef pipelines at work. That's just like big loop, but it doesn't really matter in the grand scheme of things now.
Speaker 1:Mhmm.
Speaker 3:But it was important to me at that point in time.
Speaker 2:I really like the blog. I've I've been following it for a while, actually. I think I in the same in the same way you mentioned, like, I searched for a thing and and came across your blog, and it solved something for me recently. I put it on the Slack channel. I don't remember what post it was, but it was literally I had a problem.
Speaker 2:I looked it up on Google. It was your site. It was like, this looks familiar. And I was like, Jamie Dennagh, wait. This sounds familiar.
Speaker 2:And I was like, oh, he's the guy from the Slack channel. And it it really did work for me. I am I'm super hopeful that, people with or without, AGGs. I don't have AGGs. Not that not that I know of.
Speaker 2:But we'll take a look at your, site and be inspired to, write more and publish more and feel comfortable, sharing stuff. Not everything on your site is super polished. You know, medium blog posts went to a 1,000 generative AI editors and rewrites and whatever. Some of them are just personal. Many of them are technical, and a lot of them are interesting.
Speaker 2:And I really recommend, you know, adding it if you're, like, a weekly listener and you're putting, I don't know, 20 minutes of your time or hour of your time if you're listening to the interviews as well into the show. Honestly, take 5 minutes off us and add them to JB's blog as well. I it it's really cool, like, looking what you're working on and seeing all this stuff. And keep writing, man. I assume this talk is gonna be in the at least in the week notes.
Speaker 2:So if you can somehow wangjangle it to be the post number a1000,
Speaker 1:I would really I do
Speaker 2:that with Jira tickets at work. I, like, open 5 bullshit subtasks tickets, and then I'll get like issue number a1000 assigned to me. One of the most interesting blog posts very recently from yesterday, is creating a sustainable mode model for OpenAPI Cogent. So we've talked about this project a lot. Companies are using it.
Speaker 2:Sounds like basically the perfect tool train for combined with the Dave's stuff. Basically the perfect tool train to writing restful web applications, which is super relevant for a lot of people doing Go. And you wanna change your work on it from, like, just free open source on the weekends to something a bit more sustainable. What's your plans and how can our listeners get involved?
Speaker 3:Yeah. So my time on the project has, like, waxed and waned as generally like projects do. So when I got involved with the project while I was at Deliveroo, I was working on it a lot because internally, we have a number of services using it, and that was my main focus. In the last, like, year and a bit, my primary focus, so those that can't see me, I'm wearing a t shirt with the dependency management data project logo on it. This is one of the projects that I've been working on and has sucked up a lot of my open source time.
Speaker 3:And so RPR Cogen has naturally, lost a bit of time because there is only so much time in the day. And I I find that already hard enough, alongside also trying to balance big open source projects, life stuff and everything. So it's difficult. One of the things I have been finding recently is I will do most of my maintenance, like responding to issues and community management and everything at, like, 9:30 at night. So just before I go to bed, which isn't a good recipe for everyone because, a, I am probably not gonna reply as not that I'm rude, I would hope, but I'm definitely not gonna reply as nicely as I could do if I was arrested and it was, like, my morning and I was having a nice time.
Speaker 3:It's usually a bit of guilt that I haven't looked at issues in a while, which really help out. And so, I know there are some very big companies using the project. So at least my last two companies are using it. I know of, as I say, very big names that are using it. Open source is great and I love it.
Speaker 3:And I love the fact that there isn't a paywall to use in the project because the project wouldn't have existed if people had to pay, start using it. That's not what I'm saying. What I'm trying to get to is trying to make the maintenance more sustainable because I've had times where we've had, like, 6 months between a release because life has just been too busy and there just isn't time. And, like, I love the open source contributions like our community share with us. And they're commonly fixing bugs for themselves and for others and doing a good chunk of our work for us.
Speaker 3:But there's still time that is required to actually review the changes to make sure they fit within some of the approaches of the project.
Speaker 1:One of
Speaker 3:the problems is that we support loads of different routers and frameworks, which means that when there's a fix in one of them, I also have to go and double check, does this apply to all the other places? That then adds a bit extra burden. There's also I can't remember who said it. There's a saying that's roughly like a no is for now, a yes is forever. And when you're taking on contribution, a feature or beer, I am now gonna be on the hook for maintaining that and keeping that live until maybe another breaking change, which
Speaker 1:It reminds me of a less politically correct way to say that programming is like sex.
Speaker 2:One mistake and you're supporting it for years. Yes.
Speaker 3:The sort of thing like, I wanna be cautious with what we're taking on. Only so many hours. There's so many dependencies.
Speaker 2:That makes a ton of sense. I think everybody's listening. You know, either are doing Go code or coding for money or have done in the past or looking to get into it. There are very few hobbyists who do code just as a hobby. There are.
Speaker 2:But, you know, if you do it just as a hobby, then you do something else to pay the bills. And everybody can relay to there's just only so many hours in the day. If companies are really relying on it, then it does make sense for them to support the work that you and your co maintainers are doing. So are you going to do consultation? Do you expect, sponsorships?
Speaker 2:If the if we have listeners at, you know, the huge companies you mentioned, you know, they know that they're using this library or, you know, they're going into their Go mod right now and getting starstruck. Oh, my God. Jamie from the podcast is in my Go mod. How can they help? What's the call to action here?
Speaker 3:The call to action is sponsorship would be great. So in the post and the discussion on GitHub, there's some links out to places that you can sponsor the work. So I will caveat this with, you will be sponsoring my time on the work. I'm the only maintainer that is looking for sponsorship. So although we will also add sponsorship for the project, it will be going to be so
Speaker 2:you
Speaker 3:may as well just send the money straight to me. That'd be great. But yeah, so I'm looking to get sponsorship for my time to help allocate time better. So for instance, I may take more holiday days to correspond with here's a load of money that pays for a full day's work. And then it can take a holiday or an unpaid day in order to do work.
Speaker 3:At some point in the future, maybe consultancy, maybe some other means. There's lots of other models that work. But for now, looking at, companies to send sponsorship to the project to help out with that ongoing, stuff would be awesome. In fact, I've already had one company, that haven't yet sent through, but they are in the process of sponsoring $150 a month, which is awesome. I love that I've already had, like, I think it was just over 12 hours after publishing the post.
Speaker 3:That's pretty cool. So hopefully, there will be some other people out there that can talk about it, with their team also, as an additional call to action. It's not just me that needs sponsorship. Like, you have so many dependencies, fewer in the Go ecosystem, but still you have so many dependencies, so many people doing work for free. Please consider paying them.
Speaker 3:It is maintain a month with GitHub, have a look at their stories, talk to your company about sustainable stuff because I guarantee you would not be a company without the free work of so many, like, lovely people. Yeah.
Speaker 2:So, you know, it's people who got into programming in the last 4 ish years, I'd say, maybe even 8 ish years. You know, they got into a zero interest rate industry where if you worked on open source, you were guaranteed a carrot at the end of the treadmill because some company would see your open source contribution and would definitely hire you for more money because there was so many was so much investor money flowing around the the economy and whatever. This is not a economics podcast. I don't wanna get too deep in the weeds here, but money was cheap. So you could do work for free with sort of the quote unquote guarantee that you will get, rewarded financially, if not directly through sponsorships.
Speaker 2:So somewhere along the line, someone would see your contributions. Oh, you look like a pretty good programmer. Why don't you hop on my team? And because you have open source experience, I'll I'll give you more money because you're a better Kent. Well, this still holds true today, and I think it's a really good way to upscale and a really good way to network and a really good way to get your name out there at some level of, you know, beyond junior mid developer.
Speaker 2:You just need to get paid for your for the work you're doing, especially if you wanna invest more time into it. It just makes sense. So I really hope, you know, if you use OAPI, Cogen at your company, the link is in the show notes, and I would strongly, recommend you consider it maybe with your CFO. It's also good for publicity. Right?
Speaker 2:Whenever I see a company's like, oh, we're sponsoring stuff on GitHub. I'm like, oh, they they care about developers, not just their developers. And usually that indicates that they'll be willing to, you know, pay, a few more dollars to do training, and they'll care about work life balance, and they'll give you good keyboards and good screens, and they're, like, care about engineering well-being, and they're reminded towards that and not the words. How many lines of code did you write today? Go back to the to the hamster wheel, whatever.
Speaker 2:It just shows something about the culture of the engineering in a company, I think. So it it while it does support Jamie, it definitely supports the developer brand of the company you're working at as well. Something that took a lot of hits recently in many companies. So one last time, the link is in the show notes. If you wanna support Jamie's work that we've been talking about, this is super new, just released, yesterday, so don't feel like you've missed the train or something.
Speaker 2:This is the time to get on that train and be one of the first, supporters.
Speaker 1:Shall we move to our stumper question? Are you ready? Awesome. Are you ready? So this isn't really that much of a stumper question, unlike a previous quote season.
Speaker 1:But, question is, you haven't always been a Go developer, I'm assuming. At some point, you were learning Go. What was the biggest surprise or the biggest challenge when you started learning Go?
Speaker 3:So I've actually read a blog post about learning Go. Of course.
Speaker 2:What Jamie? Only 1.
Speaker 3:But in fact, that ignores the point that I think about a year or 2 before that, I did play with Go. So during the pandemic, there was a digital meetup with someone sharing about go. And I was like, oh, that's cool. Like people are talking about go. I'll play around with trying to build like a REST API.
Speaker 3:And at the time, I think I chose chi as the router. I was like, why do I have to write so much code to do like basic stuff? Like, why is there so much just work? Yeah. And I was coming from JavaScript background where magic was everywhere.
Speaker 3:So you would annotate a type and it would get injected from a request body or a header, and you would just return a type like a struct, and it would coerce that into JSON instead of whereas we have to actually, do some of that management. So I think really the big one was there was less magic, which I do like. I do like that. It was definitely a little bit of a learning curve when I was getting started. And in particular, one of the companies I interviewed with before I joined Deliveroo, in the technical part of the interview, I was asked to implement some concurrency stuff.
Speaker 3:And I was told, oh, well, you're not always gonna be able to, like, import a library that has, like, a concurrent map. Just
Speaker 1:like that.
Speaker 3:And I was a bit like, I don't think that's quite true. Like, you're a very mature engineering organization. You will have a library that does this. Okay. Argument's sake.
Speaker 3:But at least to that point, like, I had just imported a concurrent map from the Java Central Library and having to implement it from scratch was a lot different. And I was like, I'm never going to need to know this. The amount of time I spend wrangling new texts in my current work is far too high. And it is interesting that, I used to enjoy that there was load of magic behind the scenes doing stuff. And now I'm very used to it being a bit more explicit.
Speaker 3:Or if there is magic, like, you have to spend some time trying to make it work.
Speaker 1:You have to learn the incantation. You can't just rely on someone else's shirt.
Speaker 2:You were confused by simplicity. That's what you're saying. Yeah. That's a good thing to be confused by, I think. So you mentioned your t shirt.
Speaker 2:If you go to our Slack channel, you'll see I think we did a selfie, so we'll probably share it there. But it it says dependency management data. Is this another project you're involved in? Should people know about it?
Speaker 3:Yes. So this is my other big project at the moment. And it's set of open source tooling that allows you to get a load of insight into your dependencies. So the URL is dmddot tanna.dev.
Speaker 2:And Link is in the show notes. Don't worry about it. People are, like, walking in beautiful gardens we saw on the on the channel. They're typing out, wait, wait, wait, putting the podcast on a 1.5 speed. Don't worry about it.
Speaker 2:It's a show notes, guys.
Speaker 3:But yeah. So dependency management data is a set of tooling that gives you insight into your dependencies. So, for instance, have you ever wondered, like, how many of my teams are using our API Code Jam? How many teams are using Gorilla Mux? Which teams are going to be affected by the Stripe client bumping their version yet again?
Speaker 3:How many teams have done so much work to do? And so as part of that, it analyzes a load of things and then consumes data from other sources. It's all free and open source. Is I've honestly found it game changing, for the work that I do.
Speaker 2:So relevant in your in in a big ish company, not like a team of 3 people?
Speaker 3:Yes. Yeah. In a small company where, you know, all the code is probably less important, but it does give you insights into things like where are we using dependencies that are deprecated or are we using things that, for instance, the project doesn't perform any code review? So you've got potentially issues like the exit utils backdoor could be happening in your code base.
Speaker 2:Cool. So if you're worried about dependency management, go check that out. We just talked about the proposal that got rejected where the Go tool would report about packages that are deprecated or stuff like that. So like we said, the tool chain is not gonna do it for you because that's outside the scope of the language. But if you want something close to go, that Jamie's working on, check out dependency management data.
Speaker 1:Thanks, Jamie. It's been a pleasure. Thanks for being a a long time listener. Thanks for being a a first time guest. We appreciate it.
Speaker 2:Thanks a lot for jumping on, man.
Speaker 1:Thanks very much for having me. You've been great.
Speaker 2:We we just need we just need one more, like, open API guy on the show, and we could, like, build an open API Megatron
Speaker 1:that's like Big match.
Speaker 2:1 person operating the arms, one of the legs, one of the lasers. And finally finally, we could build out that pet store API that we've been with no mistakes. Thanks a lot, Jamie.
Speaker 1:Awesome. Thanks, mate.